doc: removed protocol/ directory

While it was used during the first years of development, today
it is way more easy to access protocol documents via the IETF
web site.

Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>

205 files changed, 0 insertions, 270483 deletions

diff --git a/doc/protocol/draft-SP800-52.pdf b/doc/protocol/draft-SP800-52.pdf
deleted file mode 100644
index 39223f5421..0000000000
--- a/doc/protocol/draft-SP800-52.pdf
+++ /dev/null
diff --git a/doc/protocol/draft-babu-serv-cert-trans-from-proxy-00.txt b/doc/protocol/draft-babu-serv-cert-trans-from-proxy-00.txt
deleted file mode 100644
index a860e8786e..0000000000
--- a/doc/protocol/draft-babu-serv-cert-trans-from-proxy-00.txt
+++ /dev/null
@@ -1,381 +0,0 @@
-
-Network Working Group                                       Babu Neelam
-Internet-Draft                                              Independent
-Intended status: Standards Track                        August 19, 2007
-Expires: February 15, 2008
-
-
-        TLS extension for Proxies to transfer Server certificate
-                 draft-babu-serv-cert-trans-from-proxy-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on January 10, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   Intercepting transparent proxies splice the client-Server connection
-   into two connections: Client-Proxy connection, Proxy-server 
-   connection. On Client-Proxy connection, proxy sends it's certificate
-   to the client. As client is generally (in such a scenario) 
-   pre-configured to accept proxy's certificate, client accepts and 
-   proceeds further with the connection. On Proxy-Server connection, 
-   server sends its certificate to the proxy. Proxy typically doesn't 
-   possess the information (like MX domain name in case of SMTP)    
-   required to validate the certificate. The certificate validation is
-   at times very complex & hence it is better to offload this 
-   reponsibility to the original client itself.
-
-   This document addresses this issue by extending TLS to let proxy 
-   send server's certificate to the client for validation and suggests
-   how client can indicate certificate validation result to the proxy.
-
-Requirements Language
-
-   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 [RFC2119].
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  Mechanism Overview . . . . . . . . . . . . . . . . . . . . . .  2
-   3.  Need Server certificate extension. . . . . . . . . . . . . . .  2
-   4.  Handshake message to transfer server certificate . . . . . . .  3
-   5.  various scenarios. . . . . . . . . . . . . . . . . . . . . . .  4
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  6
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   Intellectual Property and Copyright Statements . . . . . . . . . .  7
-
-
-1.  Introduction
-
-   Today, intercepting transparent proxies are very common in
-   applications (say SMTP, HTTP) using [TLS]. In SMTP, these 
-   intercepting proxies may provide functionality like anti-virus 
-   scanning, anti-spam scanning. HTTP intercepting proxies may provide
-   functionality like anti-virus scanning, URL filtering etc. 
-
-        Client ---- Transparent Proxy -------- Server
-
-   This document defines a way for proxy to send original server's 
-   certificate to the original client and suggests how client can 
-   indicate certificate validation result to the proxy. The mechanism
-   makes use of TLS extension framework defined in [RFC4366] and defines
-   a new TLS handshake message type.
-
-   The clients supporting this extension receive certificates of 
-   intercepting proxy (if interception happens) as well as the original
-   server. So clients should be capable of handling validations on both
-   the certificates.
-
-2.  Mechanism Overview
-
-   This extension defines
-      - A new extension type (need_server_certificate) for extended 
-        client hellos defined in [RFC4366].
-      - A new handshake message (Orig_server_certificate)
-
-3. Need Server certificate extension
-
-   Who should send this extension ?
-      - A client which is configured to request the original server
-        certificate for validation includes an extension of type 
-        "need_server_certificate" in (extended) client hello. 
-      - It is possible that there could be more than one proxy 
-        between client and server:
-
-            Client --- P1 --- P2 ------ Server
-
-        In such a scenario, P1 also includes "need_server_certificate"
-        in (extended) client hello in its connection to P2, unless it 
-        has the knowledge that it is the last proxy between client and
-        server. If a proxy is configured that it is the edge proxy in 
-        client's trust domain, then it need not send this extension.
-
-   How should a receiver respond to this ?
-      - If a proxy intercepts the connection, it SHOULD respond back to
-        the client with "need_server_certificate" extension. 
-      - When there are no intercepting proxies, a server receives this
-        extension. A server which understands this extension should 
-        ignore this. It is not clear from [RFC4366] what a server does
-        when it receives an extension which it doesn't understand. 
-        This item is TBD.
-      - If a proxy which doesn't have the capability to validate server
-        certificate or is configured to offload this responsibility to 
-        the original client doesn't receive "need_server_certificate" 
-        extension, it should return a fatal error like handshake failure
-        or insufficient security (TBD).
-
-   When a proxy responds with "need_server_certificate" extension to the
-   client, proxy MUST send the its certificate as well as the original 
-   server certificate to the client (discussed in section 4).
-   
-
-   How should client handle ServerHello?
-      - If the client receives "need server_certificate" extension in 
-        ServerHello, it MUST expect the nexthop proxy certificate as 
-        well as the original server certificate. Client MUST perform 
-        validations on both proxy certificate as well as original server
-        certificate. If a client doesn't receive server certificate, it 
-        MUST abort the connection.
-      - If the client doesn't receive "need_server_certificate" 
-        extention in SerVerHello, client MUST assume that there is no 
-        proxy in between and MUST perform server certificate validations
-        on the received certificate. 
-
-   The "extension_data" field of this extension in both clientHello as 
-   well as ServerHello SHALL be empty.
-
-   Note on backward compatibility: Suppose a client supports this 
-   extension, but a intercepting proxy or the actual server doesn't 
-   understand extended hello or "need_server_certificate", client 
-   MUST proceed with the connection and MUST perform server certificate 
-   validations on the received certificate. By validating this way, 
-   clientcan deny connections from any proxies (because certificate 
-   validation fails) which do not support this mechanism, but still 
-   accept connections from server which do not support this.
-
-4. Handshake message to transfer server certificate
-
-   This docuemnt suggests the use of a new handshake message, 
-   "orig_server_certificate" to transfer the original server's 
-   certificate to the client. The new handshake message structure 
-   therefore becomes:
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), certificate_url(21), certificate_status(22),
-          orig_server_certificate(23),
-          (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case certificate_url:     CertificateURL;
-              case certificate_status:  CertificateStatus;
-              case orig_server_certificate: Certificate; /*new*/
-          } body;
-      } Handshake;
-
-   The structure of Certificate is defined in [RFC4346].
-
-   If proxy responded to the client with "need_server_certificate" 
-   extension, this message MUST be sent immediately after the 
-   "Certificate" handshake message in Client-Proxy connection.
-
-   The client MUST perform validations on the received proxy 
-   certificate as well as the server certificate. If either proxy or
-   server certificate is not valid, client should respond with 
-   certificate related error messages defined in [RFC4346]. On 
-   reception of such an error, proxy MUST close the Proxy-Server 
-   connection.
-   
-   It should be noted that proxy transparency is lost at TLS layer 
-   due to the fact that client is sent both proxy as well as original
-   server certificate for validation. Though transparency is not 
-   possible at TLS layer, application protocols can still remain 
-   transparent to the proxy operation.
-
-5. various scenarios
-
-   Client, Proxy understand this extension. 
-
-     Client                   Proxy                 Server
-
-     ClientHelo
-     (with 
-      "need_orig_server") -->   
-                             ClientHelo
-                             (with 
-                             "need_orig_server")--->
-                                                  ServerHelo
-                                                (without 
-                                                "need_orig_server")
-                                                  Certificate
-                                                  ServerkeyExchange
-                                            <---  ServerhelloDone
-                             ServerHelo
-                             (with "need_orig_server")
-                             Certificate
-                             orig_server_certificate
-                             ServerkeyExchange
-                         <-- ServerHelloDone
-      ClientKeyExchange
-      CertificateVerify
-      [ChangeCipherSpec]
-      [Finished]         -->
-                             [ChangeCipherSpec]
-                         <-- [Finished]
-                             [ChangeCipherSpec]
-                             [Finished]      -->
-                                                [ChangeCipherSpec]
-                                            <-- [Finished]
-                                  
-
-   
-   Client understands this extension. Proxy doesn't. In this case, 
-   certificate validation fails on the received proxy certificate.
-
-
-     Client                   Proxy                 Server
-
-     ClientHelo
-     (with 
-      "need_orig_server") -->   
-                             ServerHelo
-                             (without "need_orig_server")
-                             Certificate
-                             orig_server_certificate
-                             ServerkeyExchange
-                         <-- ServerHelloDone
-     Certificate error
-                                  
-
-
-   Client doesn;t understand this extension, but proxy is configured
-   to offload original server certificate responsibility to the 
-   original client:
-
-     Client                   Proxy                 Server
-
-     ClientHelo
-     (with 
-      "need_orig_server") -->   
-                             Fatal Error
-
-   TBD: Two proxies between client and server. Client as well as two
-   proxies undertsand this extension.
-
-6.  IANA Considerations
-
-   This document (if approved) requests IANA to allocate 
-   "need-server_certificate" TLS extension and 
-   "Orig_server_certificate" handhsake message.
-
-   Note to RFC Editor: this section may be removed on publication as an
-   RFC.
-
-7.  Security Considerations
-
-   Though this extension equips clients with an ability to validate
-   original server certificate as well as it's nexthop, it doesn't 
-   provide a mechanism to transmit certficates of any proxies between
-   the first proxy and the original server. It is assumed that client
-   trusts the first proxy to either not allow any other proxies in 
-   between or to allow only a proxy which is in the trusted domain.
-
-8.  Normative References
-
-   [RFC4346] The Transport Layer Security (TLS) Protocol Version 1.1.
-             T.Dierks, E. Rescorla. April 2006. 
-   [RFC4366] Transport Layer Security (TLS) Extensions. 
-             S. Blake-Wilson, M.Nystrom, D. Hopwood, J. Mikkelsen,
-             T. Wright. April 2006. 
-   [RFC2818] HTTP Over TLS. E. Rescorla. May 2000. 
-   [RFC3207] SMTP Service Extension for Secure SMTP over Transport 
-             Layer Security. P. Hoffman. February 2002.
-
-Author's Address
-
-   Babu Neelam
-   Intoto Software India Private Ltd.
-   8-3-1111/2, kesava nagar colony,
-   sriniagar colony main road,
-   punjagutta,
-   Hyderabad,
-   India.
-
-   Email: babun@intoto.com
-
-   Comments are solicited and should be addressed to the working 
-   group's mailing list at ietf-http-wg@w3.org and/or the author(s).
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
diff --git a/doc/protocol/draft-badra-ecdhe-tls-psk-00.txt b/doc/protocol/draft-badra-ecdhe-tls-psk-00.txt
deleted file mode 100644
index 23d12cec3c..0000000000
--- a/doc/protocol/draft-badra-ecdhe-tls-psk-00.txt
+++ /dev/null
@@ -1,281 +0,0 @@
-
- 
-
-Internet Engineering Task Force                                M. Badra 
-INTERNET DRAFT                                         LIMOS Laboratory 
-Updates: 4785, 4279 
- 
-Expires: November 2007                                        July 2007 
-    
-                      ECDHE_PSK Ciphersuites for TLS 
-                    <draft-badra-ecdhe-tls-psk-00.txt> 
-    
-    
-Status 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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  
-    
-   This Internet-Draft will expire on November 2007. 
-    
-Copyright Notice 
-    
-   Copyright (C) The IETF Trust (2007). 
-    
-Abstract 
-    
-   This document updates RFC 4785 and RFC 4279 and specifies a set of 
-   ciphersuites that use an Elliptic Curve Diffie-Hellman exchange 
-   authenticated with a pre-shared key. These ciphersuites provides 
-   Perfect Forward Secrecy. It specifies as well one authentication-
-   only ciphersuites (with no encryption). This ciphersuite is useful 
-   when authentication and integrity protection is desired, but 
-   confidentiality is not needed or not permitted. 
-    
-   The reader is expected to become familiar with RFC 4785 and RFC 4279 
-   prior to studying this document. 
-    
-
-Badra                    Expires November 2007                 [Page 1] 
- 
-Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007 
- 
- 
-1. Introduction 
-    
-   RFC 4279 specifies ciphersuites for supporting TLS using pre-shared 
-   symmetric keys and they (a) use only symmetric key operations for 
-   authentication, (b) use a Diffie-Hellman exchange  authenticated 
-   with a pre-shared key, or (c) combines public key authentication of 
-   the server with pre-shared key authentication of the client. 
-    
-   RFC 4785 specifies authentication-only ciphersuites (with no 
-   encryption).  
-    
-   This document specifies a set of ciphersuites that use an Elliptic 
-   Curve Diffie-Hellman exchange authenticated with a pre-shared key. 
-   These ciphersuites provides Perfect Forward Secrecy. It specifies as 
-   well one authentication-only ciphersuites (with no encryption). This 
-   ciphersuite is useful when authentication and integrity protection 
-   is desired, but confidentiality is not needed or not permitted. 
-    
-2. Updating RFC4279 
-    
-   The new ciphersuites proposed here match the ciphersuites defined in 
-   [RFC4279], except that they use an Elliptic Curve Diffie-Hellman 
-   exchange [RFC4492] authenticated with a pre-shared key. They are 
-   defined as follow: 
-    
-   CipherSuite                          Key Exchange  Cipher       Hash 
-    
-   TLS_ECDHE_PSK_WITH_RC4_128_SHA       ECDHE_PSK     RC4_128       SHA 
-   TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA  ECDHE_PSK     3DES_EDE_CBC  SHA 
-   TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA   ECDHE_PSK     AES_128_CBC   SHA 
-   TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA   ECDHE_PSK     AES_256_CBC   SHA 
-    
-   When these ciphersuites are used, the ServerKeyExchange and 
-   ClientKeyExchange messages also include the Diffie-Hellman 
-   parameters.  The PSK identity and identity hint fields have the same 
-   meaning as in the previous section (note that the ServerKeyExchange 
-   message is always sent, even if no PSK identity hint is provided). 
-    
-   The format of the ServerKeyExchange and ClientKeyExchange messages 
-   is shown below. 
-    
-      struct { 
-          select (KeyExchangeAlgorithm) { 
-              /* other cases for rsa, diffie_hellman, etc. */ 
-              case ec_diffie_hellman_psk:  /* NEW */ 
-                  opaque psk_identity_hint<0..2^16-1>; 
-                  ServerECDHParams params; 
-          }; 
-      } ServerKeyExchange; 
-    
-
-Badra                    Expires November 2007                 [Page 2] 
- 
-Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007 
- 
- 
-      struct { 
-          select (KeyExchangeAlgorithm) { 
-              /* other cases for rsa, diffie_hellman, etc. */ 
-              case ec_diffie_hellman_psk:   /* NEW */ 
-                  opaque psk_identity<0..2^16-1>; 
-                  ClientECDiffieHellmanPublic public; 
-          } exchange_keys; 
-      } ClientKeyExchange; 
-    
-   The premaster secret is formed as follows. First, perform the 
-   Elliptic Curve Diffie-Hellman computation in the same way as for 
-   other Diffie-Hellman-based ciphersuites in [TLS1.0] or [TLS1.1]. Let 
-   Z be the value produced by this computation.  Concatenate a uint16 
-   containing the length of Z (in octets), Z itself, a uint16 
-   containing the length of the PSK (in octets), and the PSK itself. 
-    
-   This corresponds to the general structure for the premaster secrets 
-   (see Note 1 in Section 2 in RFC 4279) in [RFC4279], with 
-   "other_secret" containing Z: 
-    
-       struct { 
-           opaque other_secret<0..2^16-1>; 
-           opaque psk<0..2^16-1>; 
-       }; 
-    
-   Here "other_secret" comes from the Elliptic Curve Diffie-Hellman 
-   exchange (ECDHE_PSK). 
-    
-3. Updating RFC4785 
-    
-   The new ciphersuite proposed here match the ciphersuites defined in 
-   [RFC4785], except that it uses an Elliptic Curve Diffie-Hellman 
-   exchange authenticated with a pre-shared key  
-    
-      CipherSuite                     Key Exchange   Cipher      Hash 
-    
-      TLS_ECDHE_PSK_WITH_NULL_SHA     ECDHE_PSK      NULL        SHA 
-    
-4. Security Considerations 
-    
-   The security considerations described throughout [TLS1.0], 
-   [TLSv1.1], RFC 4785 and RFC 4279 apply here as well. 
-    
-5. IANA Considerations  
-    
-   This document defines the following new ciphersuites, whose values 
-   are to be assigned from the TLS Cipher Suite registry defined in 
-   [TLS1.1]. 
-    
-   CipherSuite   TLS_ECDHE_PSK_WITH_RC4_128_SHA       = { 0xXX, 0xXX }; 
-
-Badra                    Expires November 2007                 [Page 3] 
- 
-Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007 
- 
- 
-   CipherSuite   TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA  = { 0xXX, 0xXX }; 
-   CipherSuite   TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA   = { 0xXX, 0xXX }; 
-   CipherSuite   TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA   = { 0xXX, 0xXX }; 
-   CipherSuite   TLS_ECDHE_PSK_WITH_NULL_SHA          = { 0xXX, 0xXX }; 
-    
-6. References 
-    
-    
-6.1. Normative References 
-    
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997.  
-    
-   [TLS1.0]  T., Dierks, C., Allen, "The TLS Protocol Version 1.0",  
-             RFC 2246, January 1999. 
-    
-   [TLS1.1]  Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",  
-             RFC 4346, April 200P. 
-    
-   [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 4279, December  
-             2005. 
-    
-   [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK)  
-             Ciphersuites with NULL Encryption for Transport Layer  
-             Security (TLS)", RFC 4785, January 2007. 
-    
-   [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,  
-             Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher  
-             Suites for Transport Layer Security (TLS)", RFC 4492, May  
-             2006. 
-    
-Acknowledgements  
-    
-   The authors would like to thank Bodo Moeller for comments on the 
-   document. 
-    
-Author's Addresses 
-    
-   Mohamad Badra 
-   LIMOS Laboratory - UMR (6158), CNRS 
-   France                    Email: badra@isima.fr 
-    
-   Full Copyright Statement 
-    
-   Copyright (C) The IETF Trust (2007). 
-    
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Badra                    Expires November 2007                 [Page 4] 
- 
-Internet-Draft       ECDHE_PSK Ciphersuites for TLS           July 2007 
- 
- 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-    
-   Intellectual Property 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Acknowledgement 
-    
-   Funding for the RFC Editor function is provided by the IETF 
-   Administrative Support Activity (IASA). 
-
-
-
-
-
-
-
-
-
-
-
-
-
-Badra                    Expires November 2007                 [Page 5] 
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-hajjeh-mtls-00.txt b/doc/protocol/draft-badra-hajjeh-mtls-00.txt
deleted file mode 100644
index 27dc30e944..0000000000
--- a/doc/protocol/draft-badra-hajjeh-mtls-00.txt
+++ /dev/null
@@ -1,325 +0,0 @@
-
-Internet Engineering Task Force                                M. Badra 
-INTERNET DRAFT                                               ENST Paris 
-                                                              I. Hajjeh 
-                                                              ESRGroups 
-Expires: March 2006                                    October 10, 2005 
-    
-                             TLS Multiplexing  
-                     <draft-badra-hajjeh-mtls-00.txt> 
-    
-    
-Status 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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  
-    
-   This Internet-Draft will expire on March 10, 2006. 
-    
-Copyright Notice 
-    
-   Copyright (C) The Internet Society (2005).  
-    
-Abstract 
-    
-   TLS is the famous protocol that provides authentication and data 
-   protection for communication between two entities. However, missing 
-   from the protocol is a way to multiplex application data over the 
-   same TLS session. 
-    
-   This document defines a new TLS sub-protocol called MTLS running 
-   over TLS (or DTLS) Record protocol. The MTLS design provides 
-   application multiplexing over a single TLS session. Instead of 
-   associating a TLS connection with each application, MTLS allows 
- 
-Badra & Hajjeh               Expires March 2006                [Page 1] 
-INTERNET-DRAFT                TLS Multiplexing             October 2005 
- 
- 
-   several applications to protect their exchanges over a single TLS 
-   session. 
-    
-1 Introduction 
-    
-   SMTP over TLS [SMTPTLS], HTTP over TLS [HTTPTLS], POP over TLS and 
-   IMAP over TLS [POPTLS] are examples of securing, respectively, SMTP, 
-   HTTP, POP and IMAP data exchanges using the TLS protocol [TLS]. 
-    
-   TLS ([TLS], [TLSv1.1]) is the most deployed security protocol for 
-   securing exchanges, authenticating entities and for generating and 
-   distributing cryptographic keys. However, what is missing from the 
-   protocol is the way to multiplex application data over the same TLS 
-   session. 
-    
-   Actually, TLS (or DTLS [DTLS]) clients and servers MUST establish a 
-   TLS (or DTLS) session for each application they want to run over TCP 
-   (or UDP). However, some applications may agree or be configured to 
-   use the same security policies or parameters (f.g. authentication 
-   method and cipher_suite) and then to share one and only one TLS 
-   session to protect their exchanges. In this way, this document 
-   extends TLS to allow an application multiplexing functionality over 
-   TLS. 
-    
-   The document motivations included: 
-    
-   o   TLS is application protocol-independent. Higher-level protocol  
-       can operate on top of the TLS protocol transparently. 
-    
-   o   TLS is a modular nature protocol. Since TLS is developed in four  
-       independent protocols, the approach defined in this document can  
-       be added by extending the TLS protocol and with a total  
-       reuse of pre-existing TLS infrastructures and implementations. 
-    
-   o   It provides a secure VPN tunnel over a transport layer. 
-    
-   o   Establishing a single session for a number of applications 
-       reduces resource consumption, latency and messages flow that are  
-       associated with executing simultaneous TLS sessions. 
-    
-   o   TLS can not forbid an intruder to analyze the traffic and cannot  
-       protect data from inference. Thus, the intruder can know the  
-       type of application data transmitted through the TLS session.  
-       However, the extension defined in this document allows, by its  
-       design, data protection against inference. 
-    
-1.2 Requirements language 
-    
-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
-   are to be interpreted as described in RFC-2119. 
-    
-Badra & Hajjeh               Expires March 2006                [Page 2] 
-INTERNET-DRAFT                TLS Multiplexing             October 2005 
- 
- 
-2 TLS multiplexing overview and considerations 
-    
-   This document defines a new TLS sub-protocol called Multiplexing TLS 
-   (MTLS) to handle data multiplexing, and it specifies the content 
-   type mtls(26) for this sub-protocol. 
-    
-   MTLS communication can take place over TCP or UDP. The default port 
-   is TBC, but other ports can be used. 
-    
-2.1 Handshake 
-    
-   Based on the TLS Extensions [TLSExt], a client and a server can, in 
-   an ordinary TLS handshake, negotiate the future use of MTLS. If the 
-   client does attempt to initiate a TLS connection using MTLS with a 
-   server that does not support it, it will be automatically alerted. 
-   For servers aware of MTLS but not wishing to use it, it will 
-   gracefully revert to an ordinary TLS handshake or stop the 
-   negotiation. 
-    
-   The negotiation starts usually with the client determining whether 
-   the server is capable of and willing to use MTLS or not. In order to 
-   allow a TLS client to negotiate the application multiplexing 
-   functionality, a new extension type SHOULD be added to the Extended 
-   Client and Extended Server Hello messages. 
-    
-   This document defines an extension of type 
-   "application_layer_protocol". The "extension_data" field of this 
-   extension contains a "data_multiplexing", where: 
-    
-       Struct { 
-              ApplicationLayerProtocol alp_list<0..2^20-1>; 
-           } data_multiplexing; 
-    
-       struct { 
-              ApplicationpProtocolName apn; 
-              select (Version) 
-                 case { 3, 1 }:// TLS Version 1.0 
-                   TCPPort tcp_port; 
-                 case { 3, 2 }:// TLS Version 1.1 
-                   TCPPort tcp_port; 
-                 case { 254, 255 }:// Datagram TLS Version 1.0 
-                   UDPPort udp_port; 
-           } ApplicationLayerProtocol; 
-    
-       opaque TCPPort[2]; 
-       opaque UDPPort[2]; 
-       Opaque ApplicationpProtocolName<1..16>; 
-    
-   tcp_port (respectively udp_port) is the application port number at 
-   the server side. The client MUST use as destination ports, the TCP 
-   (respectively UDP) port numbers that are assigned by IANA. 
-Badra & Hajjeh               Expires March 2006                [Page 3] 
-INTERNET-DRAFT                TLS Multiplexing             October 2005 
- 
- 
-   Application layer running on unreliable links MUST be negotiated in 
-   a separate session using the DTLS Handshake [DTLS]. 
-    
-   Note: if the server agrees, the client SHOULD establish a single TLS 
-   (respectively DTLS) session for all applications it wishes to run 
-   over TCP (respectively UDP). In this case, the client SHOULD send a 
-   data multiplexing extension containing "ALL" as 
-   ApplicationpProtocolName value and "NULL" as TCPPort (or UDPPort) 
-   value. If the server is not able to negotiate such session, it 
-   replays with a list of applications (names and ports) it can accept 
-   to run through a single TLS session, falls back on an ordinary TLS 
-   handshake or stops the negotiation. 
-    
-  2.1.1. Multi-connections during application session 
-    
-   Once the establishment is complete, the client MAY open many 
-   connections related to an arbitrary application over the secure 
-   session. In this case, the application client MUST locally reserve a 
-   port number for each connection. Next, the client application sends 
-   its request to the MTLS client which is listening on the TBC port 
-   number. This latter will check if it has an established secure 
-   session with the requested hostname (the server). If then it checks 
-   if the application protocol name has been accepted to run over MTLS, 
-   before sends the request to the MTLS server. 
-    
-2.2 MTLS sub-protocol 
-    
-   The structure of MTLS packet is described below. The first 8 bytes 
-   of the packet represent the source and the destination ports of the 
-   connexion, and the length contains the length of the MTLS data. 
-    
-   enum { 
-        change_cipher_spec(20), alert(21), handshake(22),  
-        application_data(23), mtls(26), (255) 
-     } ContentType; 
-    
-   struct { 
-          uint32 SourcePort 
-          uint32 DestinationPort 
-          uint16 length; 
-          opaque data[MTLSPlaintext.length]; 
-       } MTLSPlaintext; 
-    
-   The TLS Record Layer receives data from MTLS, supposes it as 
-   uninterpreted data and applies the fragmentation and the 
-   cryptographic operations on it, as defined in [TLS]. 
-    
-   Note: multiple MTLS fragments MAY be coalesced into a single 
-   TLSPlaintext record. 
-    
-Badra & Hajjeh               Expires March 2006                [Page 4] 
-INTERNET-DRAFT                TLS Multiplexing             October 2005 
- 
- 
-   Received data is decrypted, verified, decompressed, and reassembled, 
-   then delivered to MTLS sub-protocol. Next, the MTLS sends data to 
-   the appropriate application using the source and destination port 
-   numbers and the length value. 
-    
-Security Considerations 
-    
-   Security issues are discussed throughout this document, and in 
-   [TLS], [TLSv1.1], [DTLS] and [TLSEXT] documents. 
-    
-   If a fatal error related to a connexion of an arbitrary application 
-   is occurred, the secure session MUST NOT be resumed. 
-    
-IANA Considerations  
-    
-   This document requires IANA to allocate the TBC TCP and UDP port 
-   numbers. 
-    
-Acknowledgment 
-    
-   This document defined TLS Multiplexing for applications running over 
-   IP. Beyond that definition, generic options may be added to future 
-   versions of the current document. 
-    
-References 
-    
-   [TLS]      Dierks, T., et. al., "The TLS Protocol Version 1.0", RFC 
-              2246, January 1999. 
-    
-   [TLSExt]   Blake-Wilson, S., et. al., "Transport Layer Security  
-             (TLS) Extensions", RFC 3546, June 2003. 
-    
-   [DTLS]     Rescorla, E., Modadugu, N., "Datagram Transport Layer  
-              Security", draft-rescorla-dtls-05.txt, June 2004. 
-    
-   [TLSv1.1]  Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",  
-              draft-ietf-tls-rfc2246-bis-13.txt, June 2005 
-    
-   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over  
-              TLS", RFC 2487, January 1999. 
-    
-   [HTTPTLS]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 
-    
-   [POPTLS]   Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC   
-              2595, June 1999. 
-    
-Author's Addresses 
-    
-   Mohamad Badra 
-   ENST Paris 
-   France                    Email: Mohamad.Badra@enst.fr 
- 
-Badra & Hajjeh               Expires March 2006                [Page 5] 
-INTERNET-DRAFT                TLS Multiplexing             October 2005 
- 
-    
-   Ibrahim Hajjeh 
-   ESRGroups, Security WG 
-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
-    
-   Intellectual Property Statement 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights. 
-   Information on the IETF's procedures with respect to rights in IETF 
-   Documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Disclaimer of Validity 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-   Copyright Statement 
-    
-   Copyright (C) The Internet Society (2004). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   Acknowledgment 
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-Badra & Hajjeh               Expires March 2006                [Page 6] 
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-hajjeh-mtls-01.txt b/doc/protocol/draft-badra-hajjeh-mtls-01.txt
deleted file mode 100644
index 247806d18f..0000000000
--- a/doc/protocol/draft-badra-hajjeh-mtls-01.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
- 
-
-Internet Engineering Task Force                                M. Badra 
-INTERNET DRAFT                                               ENST Paris 
-                                                              I. Hajjeh 
-                                                              ESRGroups 
-Expires: December 2006                                    June 15, 2006 
-    
-                           MTLS: TLS Multiplexing 
-                      <draft-badra-hajjeh-mtls-01.txt> 
-    
-    
-Status 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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  
-    
-   This Internet-Draft will expire on November 20, 2006. 
-    
-Copyright Notice 
-    
-   Copyright (C) The Internet Society (2006). All Rights Reserved. 
-    
-Abstract 
-    
-   The Transport Layer Security (TLS) standard provides connection 
-   security with mutual authentication, data confidentiality and 
-   integrity, key generation and distribution, and security parameters 
-   negotiation. However, missing from the protocol is a way to 
-   multiplex application data over a single TLS session. 
-    
-   This document defines MTLS, a new TLS sub-protocol running over TLS 
-   (or DTLS) Record protocol. The MTLS design provides application 
-   multiplexing over a single TLS (or DTLS) session. Therefore, instead 
-   of associating a TLS connection with each application, MTLS allows 
-
-
-Badra & Hajjeh            Expires December 2006                [Page 1] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-   several applications to protect their exchanges over a single TLS 
-   session. 
-    
-1 Introduction 
-    
-   SMTP over TLS [SMTPTLS], HTTP over TLS [HTTPTLS], POP over TLS and 
-   IMAP over TLS [POPTLS] are examples of securing, respectively, SMTP, 
-   HTTP, POP and IMAP data exchanges using the TLS protocol [TLS]. 
-    
-   TLS ([TLS], [TLSv1.1] and [DTLS]) is the most deployed security 
-   protocol for securing exchanges, authenticating entities and for 
-   generating and distributing cryptographic keys. However, what is 
-   missing from the protocol is the way to multiplex application data 
-   over the same TLS session. 
-    
-   Actually, TLS (or DTLS) clients and servers MUST establish a TLS (or 
-   DTLS) session for each application they want to run over a transport 
-   layer. However, some applications may agree or be configured to use 
-   the same security policies or parameters (e.g. authentication method 
-   and cipher_suite) and then to share a single TLS session to protect 
-   their exchanges. In this way, this document extends TLS to allow 
-   application multiplexing over TLS. 
-    
-   The document motivations included: 
-    
-   o   TLS is application protocol-independent. Higher-level protocol  
-       can operate on top of the TLS protocol transparently. 
-    
-   o   TLS is a protocol of a modular nature. Since TLS is developed in  
-       four independent protocols, the approach defined in this  
-       document can be added by extending the TLS protocol and with a  
-       total reuse of pre-existing TLS infrastructures and  
-       implementations. 
-    
-   o   It provides a secure VPN tunnel over a transport layer. Unlike   
-       "ssh-connection" [SSHCON], MTLS can run over unreliable  
-        transport protocols, such as UDP. 
-    
-   o   Establishing a single session for a number of applications  
-       -instead of establishing a session per application- reduces  
-       resource consumption, latency and messages flow that are 
-       associated with executing simultaneous TLS sessions. 
-    
-   o   TLS can not forbid an intruder to analyze the traffic and cannot  
-       protect data from inference. Thus, the intruder can know the  
-       type of application data transmitted through the TLS session.  
-       However, the extension defined in this document allows, by its  
-       design, data protection against inference. 
-    
-
-
-Badra & Hajjeh            Expires December 2006                [Page 2] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-1.2 Requirements language 
-    
-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
-   are to be interpreted as described in RFC-2119. 
-    
-2 TLS multiplexing overview and considerations 
-    
-   This document defines a new TLS sub-protocol called Multiplexing TLS 
-   (MTLS) to handle data multiplexing, and it specifies the content 
-   type mtls(TBD). It extends also TLS with a new extension type 
-   allowing the negotiation of data multiplexing features. 
-    
-2.1 Handshake 
-    
-   Based on the TLS Extensions [TLSExt], a client and a server can, in 
-   an ordinary TLS handshake, negotiate the future use of MTLS. If the 
-   client does attempt to initiate a TLS connection using MTLS with a 
-   server that does not support it, it will be automatically alerted. 
-   For servers aware of MTLS but not wishing to use it, it will 
-   gracefully revert to an ordinary TLS handshake or stop the 
-   negotiation. 
-    
-   The negotiation usually starts with the client determining whether 
-   the server is capable of and willing to use MTLS or not. In order to 
-   allow a TLS client to negotiate the application multiplexing 
-   functionality, a new extension type SHOULD be added to the Extended 
-   Client and Extended Server Hello messages. 
-    
-   This document defines an extension of type 
-   "application_layer_protocol". The "extension_data" field of this 
-   extension contains a "data_multiplexing", where: 
-    
-       Struct { 
-              ApplicationLayerProtocol alp_list<0..2^22-1>; 
-           } data_multiplexing; 
-    
-       struct { 
-              SenderChannelID sender_channel_id; 
-              ReceiverChannelID receiver_channel_id; 
-              uint32 max_packet_length; 
-              ApplicationpProtocolName apn; 
-           } ApplicationLayerProtocol; 
-    
-       opaque SenderChannelID [2]; 
-       opaque ReceiverChannelID [2]; 
-       Opaque ApplicationpProtocolName<1..2^4>; 
-    
-   Each channel has its identifier, which is composed of two parts 
-   (sender_channel_id and receiver_channel_id) generated respectively 
-   by the sender and the receiver. During the Handshake phase, the 
-
-Badra & Hajjeh            Expires December 2006                [Page 3] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-   sender generates the sender_channel_id's value and initializes the 
-   receiver_channel_id to empty field, in which the receiver replies 
-   with a generated receiver_channel_id. 
-    
-   The sender (respectively the receiver) initializes its 
-   max_packet_length with the data length (in octets), specifying how 
-   many bytes the receiver (respectively the sender) can maximally send 
-   on the channel. Each end of the channel establishes a 'receive 
-   buffer' and a 'send buffer'. 
-    
-   How the negotiation of options within an extension is handled is up 
-   to the definition of that extension. Implementations of this 
-   document MAY allow the server to respond with the intersection 
-   between what the client and the server support. However, the server 
-   MAY reply with all the applications it supports, but in this case 
-   the server MUST support at least one application requested by the 
-   client. The sender_channel_id, receiver_channel_id and the 
-   max_packet_size MUST be omitted from the server response for each 
-   application not requested by the client. 
-    
-   Note: if the server (receiver) agrees, the client (sender) SHOULD 
-   establish a single TLS (respectively DTLS) session for all 
-   applications it wishes to run over a single TLS session. In this 
-   case, the sender SHOULD send a data multiplexing extension 
-   containing "ALL" as ApplicationpProtocolName value. The 
-   sender_channel_id, the receiver_channel_id and the max_packet_length 
-   fields SHOULD be omitted. If the receiver is able to negotiate such 
-   a session, it will reply with a list of applications it can accept 
-   to run through a single TLS session. The receiver_channel_id, the 
-   sender_channel_id and the max_packet_length fields SHOULD be 
-   omitted. 
-    
-   However, the client MAY indicate to the server its support of the 
-   data multiplexing extension without determining the application 
-   types it wishes to multiplex. In this case, the client sends an 
-   empty data multiplexing extension. If the server is able of and 
-   willing to use the data multiplexing extension, it MUST reply with 
-   an empty extension of the same type. Once the Handshake is complete, 
-   the client and the server SHOULD establish and manage many 
-   application channels using the requests/responses defined below. 
-    
-  2.1.1. Opening and closing connections 
-    
-   Once the Handshake is complete, the two entities can start data 
-   multiplexing using a set of requests/responses defined below. All 
-   requests/requests will pass through MTLS layer and are formatted 
-   into MTLS packets, depending on each request/response. 
-    
-
-
-
-Badra & Hajjeh            Expires December 2006                [Page 4] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-   The sender MAY request the opening of many channels. For each 
-   request, the MTLS layer MUST generate and send the following 
-   request: 
-    
-       struct { 
-              uint8 type; 
-              SenderChannelID sender_channel_id; 
-              uint32 max_packet_length;// of the sender of this packet 
-              ApplicationpProtocolName apn; 
-           } RequestEstablishmentChannel; 
-    
-   The field "type" specifies the MTLS packet type (types are 
-   summarized below), max_packet_length and the sender_channel_id are 
-   used as previously described. 
-    
-   The receiver decides whether it can open the channel, and replies 
-   with one of the following messages: 
-    
-       struct { 
-              uint8 type; 
-              SenderChannelID sender_channel_id; 
-              ReceiverChannelID receiver_channel_id; 
-              uint32 max_packet_length; 
-           } RequestEstablishmentSuccess; 
-    
-       struct { 
-              uint8 type; 
-              SenderChannelID sender_channel_id; 
-              opaque error<0..2^16>; 
-           } RequestEchecChannel; 
-    
-   The field "error" conveys a description of the error. 
-    
-   The following packet MAY be sent to notify the receiver that the 
-   sender will not send any more data on this channel and that any data 
-   received after a closure request will be ignored. The sender of the 
-   closure request MAY close its 'receive buffer' without waiting for 
-   the receiver's response. However, the receiver MUST respond with a 
-   confirmation of the closure and close down the channel immediately, 
-   discarding any pending writes. 
-    
-       struct { 
-              uint8 type; 
-              SenderChannelID sender_channel_id; 
-              ReceiverChannelID receiver_channel_id; 
-           } CloseChannel; 
-    
-    
-    
-    
-
-Badra & Hajjeh            Expires December 2006                [Page 5] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-       struct { 
-              uint8 type; 
-              SenderChannelID sender_channel_id; 
-              ReceiverChannelID receiver_channel_id; 
-           } ConfirmationCloseChannel; 
-    
-2.2 MTLS sub-protocol 
-    
-   The structure of the MTLS packet is described below. The channel_id 
-   value depends on the originator of the packet; for received 
-   (respectively submitted) packets, it conveys the sender_channel_id 
-   (respectively receiver_channel_id). The length conveys the data 
-   length of the current packet. 
-    
-   Each entity maintains its max_packet_length that is originally 
-   initialized (during the channel establishment or during the 
-   handshake phase) to a value not bigger than the maximum size of this 
-   entity's 'receive buffer'. For each received packet, the entity MUST 
-   subtract the packet's length from the max_packet_length. The result 
-   is always positive since the packet's length is always less than or 
-   equal to the current max_packet_length. 
-    
-   The free space of the 'receive buffer' MAY increase in length. 
-   Consequently, the entity MUST inform the other end about this 
-   increase, allowing the other entity to send packet with length 
-   bigger than the old max_packet_length but smaller or equal than the 
-   new value. 
-    
-   The entity MAY indicate this increase using either data or 
-   Acknowledgment packets. In the first case, the entity MUST set the 
-   max_packet_length_changed to 1 and extra_length set to the extra 
-   free space. In the second case, the entity only needs to send the 
-   length of the extra free space. 
-    
-   If the length of the 'receive buffer' does not change, 
-   Acknowledgment packet will never be sent. However, the entity MAY 
-   send data packet but in this case, it MUST set the 
-   max_packet_length_changed to 0 and MUST consequently remove the 
-   extra_length field from the packet header. 
-    
-   In the case where the 'receive buffer' of an entity fills up, the 
-   other entity MUST wait for an Acknowledgment or a data packet with 
-   packet_length_changed set to 1, before sending any more 
-   MTLSPlaintext packets. 
-    
-    
-    
-    
-    
-    
-
-Badra & Hajjeh            Expires December 2006                [Page 6] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-     struct { 
-              uint8 type; 
-              uint16 channel_id; 
-              uint8 max_packet_length_changed; 
-              uint32 extra_length; // omitted if the value of the 
-                                   // max_packet_length_changed is 0 
-              uint32 length; 
-              opaque data[MTLSPlaintext.length]; 
-           } MTLSPlaintext; 
-      
-     struct { 
-              uint8 type; 
-              uint16 channel_id; // of the receiver of that packet 
-              uint32 extra_length; 
-           } Acknowledgment; 
-    
-   The TLS Record Layer receives data from MTLS, supposes it as 
-   uninterpreted data and applies the fragmentation and the 
-   cryptographic operations on it, as defined in [TLS]. 
-    
-   Note: multiple MTLS fragments MAY be coalesced into a single 
-   TLSPlaintext record. 
-    
-   Received data is decrypted, verified, decompressed, and reassembled, 
-   then delivered to MTLS sub-protocol. Next, the MTLS sends data to 
-   the appropriate application using the channel identifier and the 
-   length value. 
-    
-2.3 MTLS Message Types 
-    
-                RequestEstablishmentChannel        0x01 
-                RequestEstablishmentSuccess        0x02 
-                RequestEchecChannel                0x03 
-                CloseChannel                       0x04 
-                ConfirmationCloseChannel           0x05 
-                MTLSPlaintext                      0x06 
-                Acknowledgment                     0x07 
-    
-Security Considerations 
-    
-   Security issues are discussed throughout this document, and in 
-   [TLS], [TLSv1.1], [DTLS] and [TLSEXT] documents. 
-    
-   If a fatal error related to a channel or a connection of an 
-   arbitrary application occurs, the secure session MUST NOT be 
-   resumed. 
-    
-    
-    
-
-
-Badra & Hajjeh            Expires December 2006                [Page 7] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-IANA Considerations  
-    
-   This section provides guidance to the IANA regarding registration of 
-   values related to the TLS protocol. 
-    
-   There are name spaces that require registration: the mtls content 
-   type, the data_multiplexing extension, and the MTLS message types. 
-    
-    
-References 
-    
-   [TLS]      Dierks, T., et. al., "The TLS Protocol Version 1.0", RFC 
-              2246, January 1999. 
-    
-   [TLSExt]   Blake-Wilson, S., et. al., "Transport Layer Security  
-             (TLS) Extensions", RFC 4346, April 2006. 
-    
-   [DTLS]     Rescorla, E., Modadugu, N., "Datagram Transport Layer  
-              Security", RFC 4347, April 2006. 
-    
-   [TLSv1.1]  Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",  
-              RFC 4346, April 200P. 
-    
-   [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over  
-              TLS", RFC 2487, January 1999. 
-    
-   [HTTPTLS]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 
-    
-   [POPTLS]   Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC   
-              2595, June 1999. 
-    
-   [SSHCON]   Lonvick, C., "SSH Connection Protocol", RFC 4254, January  
-              2005. 
-    
-Author's Addresses 
-    
-   Mohamad Badra 
-   ENST Paris 
-   France                    Email: Mohamad.Badra@enst.fr 
-    
-   Ibrahim Hajjeh 
-   ESRGroups, Security WG 
-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
-    
-
-
-
-
-
-
-
-Badra & Hajjeh            Expires December 2006                [Page 8] 
- 
-Internet-Draft              TLS Multiplexing                  June 2006 
- 
- 
-   Intellectual Property Statement 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights. 
-   Information on the IETF's procedures with respect to rights in IETF 
-   Documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Disclaimer of Validity 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-   Copyright Statement 
-    
-   Copyright (C) The Internet Society (2006). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   Acknowledgment 
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-Badra & Hajjeh            Expires December 2006                [Page 9] 
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-hajjeh-mtls-03.txt b/doc/protocol/draft-badra-hajjeh-mtls-03.txt
deleted file mode 100644
index a4b3fe5036..0000000000
--- a/doc/protocol/draft-badra-hajjeh-mtls-03.txt
+++ /dev/null
@@ -1,504 +0,0 @@
- 
-
-TLS Working Group                                              M. Badra 
-Internet-Draft                                         LIMOS Laboratory 
-Intended status: Standards Track                              I. Hajjeh 
-Expires:  April 27, 2008                                      ESRGroups 
-                                                       October 25, 2007 
-    
-    
-                           MTLS: TLS Multiplexing 
-                      <draft-badra-hajjeh-mtls-03.txt> 
-    
-Status of this Memo 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts.  
-    
-   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   
-    
-   This Internet-Draft will expire on April 27, 2008. 
-    
-Copyright Notice  
-    
-   Copyright (C) The IETF Trust (2007).  
-    
-Abstract 
-    
-   The Transport Layer Security (TLS) standard provides connection 
-   security with mutual authentication, data confidentiality and 
-   integrity, key generation and distribution, and security parameters 
-   negotiation. However, missing from the protocol is a way to 
-   multiplex application data over a single TLS session. 
-    
-   This document defines MTLS, a new TLS sub-protocol running over TLS 
-   (or DTLS) Record protocol. The MTLS design provides application 
-   multiplexing over a single TLS (or DTLS) session. Therefore, instead 
-   of associating a TLS connection with each application, MTLS allows 
-
-
-Badra & Hajjeh            Expires April 2008                   [Page 1] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-   several applications to protect their exchanges over a single TLS 
-   session. 
-    
-1. Introduction 
-    
-   HTTP over TLS [HTTPTLS], POP over TLS and IMAP over TLS [POPTLS] are 
-   examples of securing, respectively HTTP, POP and IMAP data exchanges 
-   using the TLS protocol [TLS]. 
-    
-   TLS ([TLS], [DTLS]) is the most deployed security protocol for 
-   securing exchanges, for authenticating entities and for generating 
-   and distributing cryptographic keys. However, what is missing from 
-   the protocol is the way to multiplex application data over the same 
-   TLS session. 
-    
-   Actually, TLS (or DTLS) clients and servers MUST establish a TLS (or 
-   DTLS) session for each application they want to run over a transport 
-   layer. However, some applications may agree or be configured to use 
-   the same security policies or parameters (e.g. authentication method 
-   and cipher_suite) and then to share a single TLS session to protect 
-   their exchanges. In this way, this document extends TLS to allow 
-   application multiplexing over TLS. 
-    
-   The document motivations included: 
-    
-   o   TLS is application protocol-independent. Higher-level protocol  
-       can operate on top of the TLS protocol transparently. 
-    
-   o   TLS is a protocol of a modular nature. Since TLS is developed in  
-       four independent protocols, the approach defined in this  
-       document can be added by extending the TLS protocol and with a  
-       total reuse of pre-existing TLS infrastructures and  
-       implementations. 
-    
-   o   It provides a secure VPN tunnel over a transport layer. Unlike   
-       "ssh-connection" [SSHCON], MTLS can run over unreliable  
-        transport protocols, such as UDP. 
-    
-   o   Establishing a single session for a number of applications  
-       -instead of establishing a session per application- reduces  
-       resource consumption, latency and messages flow that are 
-       associated with executing simultaneous TLS sessions. 
-    
-   o   TLS can not forbid an intruder to analyze the traffic and cannot  
-       protect data from inference. Thus, the intruder can know the  
-       type of application data transmitted through the TLS session.  
-       However, the extension defined in this document allows, by its  
-       design, data protection against inference. 
-    
-    
-    
-
-Badra & Hajjeh            Expires April 2008                   [Page 2] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-1.2. Requirements language 
-    
-   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 [KEYWORDS]. 
-    
-2. TLS multiplexing overview and considerations 
-    
-   This document defines a new TLS sub-protocol called Multiplexing TLS 
-   (MTLS) to handle data multiplexing, and it specifies the content 
-   type mtls(TBA). It extends also TLS with a new extension type (TBA) 
-   allowing the negotiation of data multiplexing features. 
-    
-2.1. Handshake 
-    
-   This document defines an extension of type "data_multiplexing". The 
-   "extension_data" field of this extension is zero-length. 
-    
-   Based on the TLS Extensions [TLSEXT], a client and a server can, in 
-   an ordinary TLS handshake, negotiate the future use of MTLS. If the 
-   client does attempt to initiate a TLS connection using MTLS with a 
-   server that does not support it, it will be automatically alerted. 
-   For servers aware of MTLS but not wishing to use it, it will 
-   gracefully revert to an ordinary TLS handshake or stop the 
-   negotiation. 
-    
-   The negotiation usually starts with the client determining whether 
-   the server is capable of and willing to use MTLS or not. In order to 
-   allow a TLS client to negotiate the application multiplexing 
-   functionality, a new extension type SHOULD be added to the Extended 
-   Client and Extended Server Hello messages. 
-    
-   If the server is able of and willing to use the "data_multiplexing" 
-   extension, it MUST reply with an empty extension of the same type. 
-   Once the Handshake is complete, the client and the server SHOULD 
-   establish and manage many application channels using the 
-   requests/responses defined below. 
-    
-2.1.1. Opening and closing connections 
-    
-   Once the Handshake is complete, both the client and the server can 
-   start data multiplexing using a set of requests/responses defined 
-   below. All requests/requests will pass through MTLS layer and are 
-   formatted into MTLS packets, depending on each request/response. 
-    
-   The sender MAY request the opening of many channels. For each 
-   channel, the MTLS layer generates and sends the following request: 
-    
-    
-    
-    
-
-Badra & Hajjeh            Expires April 2008                   [Page 3] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-       struct { 
-              uint8 type; 
-              opaque sender_channel_id[2]; 
-              uint32 sender_window_length; 
-              uint32 sender_max_packet_length; 
-              opaque source_address_machine<4..7>; 
-              opaque source_port[2]; 
-              opaque destination_address_machine<4..7>; 
-              opaque destination_port[2]; 
-           } RequestEstablishmentChannel; 
-    
-   The field "type" specifies the MTLS packet type (types are 
-   summarized below), the "max_packet_length" and the 
-   "sender_channel_id" are used as described below. The 
-   "source_address_machine" MAY carry either the numeric IP address or 
-   the domain name of the host from where the application originates 
-   the data multiplexing request and the "port" is the port on the host 
-   from where the connection originated. 
-    
-   The sender initializes its "window_length" with the data length (in 
-   octets), specifying how many bytes the receiver can maximally send 
-   on the channel before receiving a new window length (available free 
-   space). Each end of the channel establishes a "receive buffer" and a 
-   "send buffer". 
-    
-   The sender initializes its "max_packet_length" with the data length 
-   (in octets), specifying the maximal packet's length in octets the 
-   receiver can send on the channel. 
-    
-   The "destination_address_machine" and "destination_port" specify the 
-   TCP/IP host and port where the recipient should connect the channel. 
-   The "destination_address_machine" MAY be either a domain name or a 
-   numeric IP address. 
-    
-   The receiver decides whether it can open the channel, and replies 
-   with one of the following messages: 
-    
-       struct { 
-              uint8 type; 
-              opaque sender_channel_id[2]; 
-              opaque receiver_channel_id[2]; 
-              uint32 receiver_window_length; 
-              uint32 max_packet_length; 
-           } RequestEstablishmentSuccess; 
-    
-       struct { 
-              uint8 type; 
-              opaque sender_channel_id[2]; 
-              opaque error<0..2^16>; 
-           } RequestEchecChannel; 
-    
-
-Badra & Hajjeh            Expires April 2008                   [Page 4] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-   The field "error" conveys a description of the error. 
-    
-   If an error occurs at the MTLS layer, the established secure session 
-   is still valid and no alert of any type is sent by the TLS Record. 
-    
-   Each MTLS channel has its identifier computed as:  
-    
-             channel_id = sender_channel_id" + "receiver_channel_id 
-    
-   Where "+" indicates concatenation. 
-    
-   The following packet MAY be sent to notify the receiver that the 
-   sender will not send any more data on this channel and that any data 
-   received after a closure request will be ignored. The sender of the 
-   closure request MAY close its "receive buffer" without waiting for 
-   the receiver's response. However, the receiver MUST respond with a 
-   confirmation of the closure and close down the channel immediately, 
-   discarding any pending writes. 
-    
-       struct { 
-              uint8 type; 
-              opaque channel_id[4]; 
-           } CloseChannel; 
-    
-       struct { 
-              uint8 type; 
-              opaque channel_id[4]; 
-           } ConfirmationCloseChannel; 
-    
-2.2. MTLS sub-protocol 
-    
-   The structure of the MTLS packet is described below. The 
-   "sender_channel_id" and "receiver_channel_id" are the same gererated 
-   during the connection establishment. The length conveys the data 
-   length of the current packet. 
-    
-   Each entity maintains its "max_packet_length" (that is originally 
-   initialized during the connection establishment) to a value not 
-   bigger than the maximum size of this entity's "receive buffer". For 
-   each received packet, the entity MUST subtract the packet's length 
-   from the "max_packet_length". The result is always positive since 
-   the packet's length is always less than or equal to the current 
-   "max_packet_length". 
-    
-   The free space of the "receive buffer" MAY increase in length. 
-   Consequently, the entity MUST inform the other end about this 
-   increase, allowing the other entity to send packet with length 
-   bigger than the old "max_packet_length" but smaller or equal than 
-   the new value. 
-    
-
-
-Badra & Hajjeh            Expires April 2008                   [Page 5] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-   The entity MAY indicate this increase by sending an Acknowledgment 
-   packet. The Acknowledgment packet carries the available free space 
-   ("free_space" field in octets) the receiver of that packet can send 
-   on the channel before receiving a new window length. 
-    
-   If the length of the "receive buffer" does not change, 
-   Acknowledgment packet will never be sent. 
-    
-   In the case where the "receive buffer" of an entity fills up, the 
-   other entity MUST wait for an Acknowledgment packet before sending 
-   any more MTLSPlaintext packets. 
-    
-      struct { 
-              uint8 type; 
-              opaque channel_id[4]; 
-              uint32 length; 
-              opaque data[MTLSPlaintext.length]; 
-            } MTLSPlaintext; 
-    
-      struct { 
-              uint8 type; 
-              opaque channel_id[4]; 
-              uint32 free_space; 
-           } Acknowledgment; 
-    
-   The TLS Record Layer receives data from MTLS, supposes it as 
-   uninterpreted data and applies the fragmentation and the 
-   cryptographic operations on it, as defined in [TLS]. The type is set 
-   to mtls(TBA). 
-    
-   Note: multiple MTLS fragments MAY be coalesced into a single 
-   TLSPlaintext record. 
-    
-   Received data is decrypted, verified, decompressed, and reassembled, 
-   then delivered to MTLS sub-protocol. Next, the MTLS sends data to 
-   the appropriate application using the channel identifier and the 
-   length value. 
-    
-      enum { 
-            change_cipher_spec(20), alert(21), handshake(22), 
-            application_data(23), mtls(TBA), (255) 
-          } ContentType; 
-    
-2.3. MTLS Message Types 
-    
-   Additional message types can be supported by MTLS. 
-    
-                RequestEstablishmentChannel        0x01 
-                RequestEstablishmentSuccess        0x02 
-                RequestEchecChannel                0x03 
-                CloseChannel                       0x04 
-
-Badra & Hajjeh            Expires April 2008                   [Page 6] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-                ConfirmationCloseChannel           0x05 
-                MTLSPlaintext                      0x06 
-                Acknowledgment                     0x07 
-    
-3. Security Considerations 
-    
-   Security issues are discussed throughout this document, and in 
-   [TLS], [DTLS] and [TLSEXT] documents. 
-    
-   If a fatal error related to any channel or a connection of an 
-   arbitrary application occurs, the secure session MUST NOT be 
-   resumed. This is logic since the Record protocol does not 
-   distinguish between the MTLS channels. However, if an error occurs 
-   at the MTLS layer, both parties immediately close the related 
-   channels, but not the TLS session (no alert of any type is sent by 
-   the TLS Record). 
-    
-4. IANA Considerations  
-    
-   This section provides guidance to the IANA regarding registration of 
-   values related to the TLS protocol. 
-    
-   There are name spaces that require registration: the mtls content 
-   type, the data_multiplexing extension, and the MTLS message types. 
-    
-5. References 
-    
-5.1. Normative References 
-    
-   [TLS]      Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",  
-              RFC 4346, April 200P. 
-    
-   [TLSEXT]   Blake-Wilson, S., et. al., "Transport Layer Security  
-             (TLS) Extensions", RFC 4346, April 2006. 
-    
-   [DTLS]     Rescorla, E., Modadugu, N., "Datagram Transport Layer  
-              Security", RFC 4347, April 2006. 
-    
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 
-              Requirement Levels", RFC 2119, March 1997. 
-    
-5.2. Informative References 
-    
-   [HTTPTLS]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 
-    
-   [POPTLS]   Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC   
-              2595, June 1999. 
-    
-   [SSHCON]   Lonvick, C., "SSH Connection Protocol", RFC 4254, January  
-              2005. 
-    
-
-Badra & Hajjeh            Expires April 2008                   [Page 7] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-Author's Addresses 
-    
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France                    Email: badra@isima.fr 
-    
-   Ibrahim Hajjeh 
-   ESRGroups, Security WG 
-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
-    
-Full Copyright Statement  
-        
-   Copyright (C) The IETF Trust (2007).   
-    
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-    
-   Intellectual Property   
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such might 
-   or might not be available; nor does it represent that it has made 
-   any independent effort to identify any such rights. Information on 
-   the procedures with respect to rights in RFC documents can be found 
-   in BCP 78 and BCP 79.  
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.   
-    
-
-Badra & Hajjeh            Expires April 2008                   [Page 8] 
- 
-Internet-Draft             TLS Multiplexing                October 2007 
- 
-   Acknowledgement   
-    
-   Funding for the RFC Editor function is provided by the IETF 
-   Administrative Support Activity (IASA). 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Badra & Hajjeh            Expires April 2008                   [Page 9] 
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-tls-express-00.txt b/doc/protocol/draft-badra-tls-express-00.txt
deleted file mode 100644
index 947eb495c0..0000000000
--- a/doc/protocol/draft-badra-tls-express-00.txt
+++ /dev/null
@@ -1,277 +0,0 @@
-Internet Engineering Task Force                                M. Badra 
-INTERNET DRAFT                                           A. Serhrouchni 
-Expires December 2004                                          P. Urien 
-                                                           ENST Telecom 
-                                                              June 2004 
- 
- 
-                                TLS Express 
-                     <draft-badra-tls-express-00.txt> 
-    
-    
-Status of this Memo 
-    
-   By submitting this Internet-Draft, I certify that any applicable 
-   patent or other IPR claims of which I am aware have been disclosed, 
-   or will be disclosed, and any of which I become aware will be 
-   disclosed, in accordance with RFC 3668. 
-    
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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 (2004).  All Rights Reserved. 
-    
-Abstract 
-    
-   This document defines a new extension that may be used to add Pre 
-   Shared Key authentication functionality to TLS. It is based on the 
-   TLS abbreviated handshake and it provides the ability to share a 
-   session key for data encryption. 
-
-
-
-
-
-
-
-Badra, et. al.     Informational - Expires December 2004       [Page 1] 
- 
-INTERNET-DRAFT                  TLS express                   June 2004 
- 
-1. Introduction 
-    
-   [TLSEXT] describes extensions that MAY be used to add functionality 
-   to Transport Layer Security (TLS). It provides both generic 
-   extension mechanisms for the TLS handshake client and server hellos, 
-   and specific extensions using these generic mechanisms.  
-    
-   In this document, we propose a new extension to add pre shared key 
-   functionality to TLS handshake protocol. It is based on [PIMRC] and 
-   uses the TLS session resume logic. It provides the client and the 
-   server the ability to share a session key for data encryption and to 
-   authenticate each other by sending a correct finished message, 
-   parties thus prove that they know the correct pre shared key.  
-    
-1.1. Requirements language 
-    
-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
-   are to be interpreted as described in RFC-2119. 
-    
-2. Extension Type 
-    
-   The TLS extensions [TLSEXT] specify extensions using the following 
-   generic mechanism: 
-    
-       struct { 
-           ExtensionType extension_type; 
-           opaque extension_data<0.. 2^16-1>; 
-          } Extension; 
-    
-   where "extension_type" identifies the particular extension type, and 
-   "extension_data" contains information specific to the particular 
-   extension type. 
-    
-       enum { 
-           server_name(0), max_fragment_length(1), 
-           client_certificate_url(2), trusted_ca_keys(3), 
-           truncated_hmac(4), status_request(5), srp(6), cert_type(7), 
-           ticket_identity(8), (65535) 
-           } ExtensionType; 
-    
-   A new value, "ticket_identity(8)", has been added to the enumerated 
-   ExtensionType defined in [TLSEXT]. This value is used as the 
-   extension number for the extensions in the client hello message. 
-   This new extension type will be used for shared key type 
-   negotiation. 
-    
-   The "extension_data" field of the ticket extension SHALL contain: 
-    
-         opaque ticket_to_enter<1..2^16-1> 
-    
-
-
-Badra, et. al.           Expires - December 2004               [Page 2] 
- 
-INTERNET-DRAFT                  TLS express                   June 2004 
- 
-   where ticket_to_enter is the shared key identifier and/or data 
-   related to the shared key. 
-    
-   Note that the secret key MAY be delivered by a trusted third party. 
-   In [PIMRC], we gave a method for this topic. By the way, the secret 
-   MAY be also issued directly by the server. Kerberos [KERBEROS] is a 
-   particular example for this issue. 
-    
-2.1. Handshake 
-    
-   In order to indicate the support of the shared key type, the client 
-   will include an extension of type "ticket_identity" to the extended 
-   client hello message. 
-    
-   When the server receives an extended client hello containing the 
-   "ticket_identity" extension, it checks its ticket_identity's 
-   database for a match. If a match is found, the server calculates the 
-   finished and waits for the client one.  
-    
-   If the server understood the client hello extension but does not 
-   recognize the ticket identity, it SHOULD send a "decode_error" 
-   alert. Alternatively and like in [TLSSRP], if the server wishes to 
-   hide the fact that the ticket_identity does not have a match, the 
-   server MAY simulate the protocol as if a ticket existed, but then 
-   reject the client's finished message with a bad_record_mac alert, as 
-   if the shared key was incorrect. 
-    
-   The handshake exchange is given in the following diagram: 
-    
-         ClientHello            --------> 
-      (ticket_identity)                    ServerHello 
-                                           ChangeCipherSpec 
-                                <--------  Finished 
-         ChangeCipherSpec 
-         Finished               --------> 
-    
-3. Security considerations 
-    
-   The server MUST stock the shared key in a secure and protected 
-   manner in order to prevent attackers from retrieving its value. 
-    
-4. IANA Considerations 
-    
-   To be continued. 
-    
-    
-    
-    
-    
-    
-    
-Badra, et. al.           Expires - December 2004               [Page 3] 
- 
-INTERNET-DRAFT                  TLS express                   June 2004 
- 
-5. References 
-    
-5.1  Normative References 
-    
-   [TLSEXT]  Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J.  
-             and Wright, T., "Transport Layer Security (TLS)  
-             Extensions", RFC 3546, June 2003  
-    
-   [KERBEROS]Kohl J. and C. Neuman, "The Kerberos Network   
-             Authentication Service (V5)", RFC 1510, September 1993. 
-    
-5.2  Informative References 
-    
-   [TLSSRP]  Taylor, D., Wu, T., Mavroyanopoulos, N., and Perrin,  
-             T., "Using SRP for TLS Authentication", 
-             draft-ietf-tls-srp-07.txt, Internet Draft (work in  
-             progress), June 2004. 
-    
-   [PIMRC]   Badra, M., and Serhrouchni, A., "A new secure session   
-             exchange key protocol for wireless communications", the 
-             14 IEEE Proceedings on Personal, Indoor and Mobile Radio 
-             Communications, PIMRC 2003, Volume: 3, 7-10 Sept. 2003,  
-             Pages:2765 - 2769. An extracted text could be found at  
-             http://www.infres.enst.fr/~badra/pimrc2003.pdf 
-    
-6. Author's Addresses 
-    
-   Mohamad Badra 
-   ENST 
-   46 rue Barrault 
-   75634 Paris               Phone: NA 
-   France                    Email: Mohamad.Badra@enst.fr 
-    
-   Ahmed Serhrouchni 
-   ENST 
-   46 rue Barrault 
-   75634 Paris               Phone: NA 
-   France                    Email: Ahmed.Serhrouchni@enst.fr 
-    
-   Pascal Urien 
-   ENST 
-   46 rue Barrault 
-   75634 Paris               Phone: NA 
-   France                    Email: Pascal.Urien@enst.fr 
-    
-    
-    
-    
-    
-    
-    
-Badra, et. al.           Expires - December 2004               [Page 4] 
- 
-INTERNET-DRAFT                  TLS express                   June 2004 
- 
-   Intellectual Property Statement 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights. 
-   Information on the IETF's procedures with respect to rights in IETF 
-   Documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard. Please address the information to the IETF at  
-   ietf-ipr@ietf.org. 
-    
-   Disclaimer of Validity 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-   Copyright Statement 
-    
-   Copyright (C) The Internet Society (2004). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   Acknowledgment 
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
- 
-
-
-
-
-
-
-
-Badra, et. al.           Expires - December 2004               [Page 5] 
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-tls-key-exchange-00.txt b/doc/protocol/draft-badra-tls-key-exchange-00.txt
deleted file mode 100644
index 76f8148835..0000000000
--- a/doc/protocol/draft-badra-tls-key-exchange-00.txt
+++ /dev/null
@@ -1,556 +0,0 @@
-Internet Engineering Task Force                                M. Badra 
-INTERNET DRAFT                                             O. Cherkaoui 
-                                                        UQAM University 
-                                                              I. Hajjeh 
-Expires: 8, February 2004                                A. Serhrouchni 
-                                                            ENST, Paris 
-                                                        August, 10 2004 
- 
- 
-            Pre-Shared-Key key Exchange methods for TLS  
-               <draft-badra-tls-key-exchange-00.txt> 
-    
-    
-Status of this Memo 
-    
-   By submitting this Internet-Draft, I certify that any applicable 
-   patent or other IPR claims of which I am aware have been disclosed, 
-   or will be disclosed, and any of which I become aware will be 
-   disclosed, in accordance with RFC 3668. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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. 
-    
-   This Internet-Draft will expire on February 8, 2005. 
-    
-Copyright Notice 
-    
-   Copyright (C) The Internet Society (2004).  All Rights Reserved. 
-    
-Abstract 
-    
-   This document specifies new key exchange methods for Transport Layer 
-   Security protocol to support authentication based on pre installed 
-   key and to allow anonymous exchanges, identity protection And 
-   Perfect Forward Secrecy. 
-    
-    
-    
-    
-
-
-Badra, et. al.           Expires February 2005                 [Page 1]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-1. Introduction 
-    
-   Transport Layer Security (TLS) [TLS] is an authentication protocol 
-   that establishes a secure channel, as well as mutual authentication, 
-   protected cipher suite negotiation and key exchange between two 
-   entities. TLS handshake uses certificates and PKI for mutual 
-   authentication and key exchange. In many cases, a TLS public-key-
-   based handshake is unnecessary; especially for closed environments 
-   or for clients pre-configured. This document specifies how to 
-   establish a TLS session using symmetric keys. 
-    
-   Although several Internet Draft authors ([TLSPSK], [TLSSK], 
-   [TSLEXP], etc) propose the pre shared key mechanism, none of them 
-   provides neither anonymous exchanges and identity protection against 
-   eavesdropping nor Perfect Forward Secrecy (PFS). On the other hand,  
-   some approaches like [ISATLS], propose a radical change to the TLS 
-   protocol. Other like [SPTLS], propose Password-based cipher suite 
-   for TLS Handshake scheme. 
-    
-   This document specifies new key exchange methods for TLS for pre 
-   shared key. The advantageous use of the pre shared key regarding the 
-   Public Key Infrastructure (PKI) based certificates is that the pre 
-   shared key reduces the cryptographic operations, the messages load 
-   and the number of round trips. 
-    
-1.1. Requirements language 
-    
-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
-   are to be interpreted as described in RFC-2119. 
-    
-2. Changes to the TLS Handshake protocol 
-    
-   TLS [TLS] defines the client key exchange message that is always 
-   sent by the client. With this message [TLS], the premaster secret is 
-   set, either though direct transmission of the RSA-encrypted secret, 
-   or by the transmission of Diffie-Hellman parameters which will allow 
-   each side to agree upon the same premaster secret. The structure of 
-   this message depends on which key exchange method has been selected. 
-   The actual TLS standard defines two methods using RSA or  
-   Diffie_Hellman algorithms. 
-    
-   The rest of this document describes the changes to the handshake 
-   messages contents when the pre shared key is being used. 
-    
-2.1. Client Hello 
-    
-   In order to negotiate and to signal to the server that the client 
-   wishes to use a pre_shared_key key exchange method, the client MAY 
-   include an extension of type "psk_key_exchange (9)" in the extended 
-   client hello, such is defined in [TLSEXT]. The "extension_data" 
-
-
-Badra, et. al.           Expires - February 2005               [Page 2]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-   field of the psk key exchange extension SHALL contain 
-   "PSKKeyExchangeMethod" where: 
-    
-        struct {  
-          PSKMethod psk_methods_list<0..2^16-1>;  
-        } PSKKeyExchangeMethod;  
-        
-        struct {  
-          MethodType method_type;  
-            Select (method_type) {  
-             case rsa_psk : RSAPSK  
-             case diffie_hellman_psk : DHPSK  
-            } method;  
-        } PSKMethod;  
-        
-        enum { rsa_psk(0), diffie_hellmen_psk(1), (255) } MethodType;  
-        
-   Here, "PSKKeyExchangeMethod" provides a list of PSK key exchange  
-   methods that the client supports.  
-    
-2.3. Server Key Exchange 
-    
-   The format of ServerKeyExchange is as follow: 
-    
-        struct { 
-            select (KeyExchangeAlgorithm) { 
-             case diffie_hellman: 
-                ServerDHParams params; 
-                Signature signed_params; 
-             case rsa: 
-                ServerRSAParams params; 
-                Signature signed_params; 
-             case rsa_psk: /*NEW/ 
-                ServerRSAParamsPSK params; 
-                Signature signed_params; /*optional/ 
-             case diffie_hellman_psk: /*NEW/ 
-                ServerDHParamsPSK params; 
-                Signature signed_params;/*optional/ 
-            }; 
-        } ServerKeyExchange; 
-    
-   rsa_psk and diffie_hellman_psk cases are respectively identical to 
-   rsa and diffie_hellman cases that are definied in [TLS]. 
-    
-   Note that because the pre_shared_key SHOULD protect entities against 
-   man-in-the-middle attack (see section 2.4), the server MAY not sign 
-   its Diffie_Hellman parameters and thus the signed_params field MAY 
-   be omitted. For more information, see security considerations 
-   section. 
-    
-
-
-Badra, et. al.           Expires - February 2005               [Page 3]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-2.2. Client Key Exchange  
-    
-   This document adds two new key exchange methods to the enumerated 
-   KeyExchangeAlgorithm originally defined in [TLS]. 
-    
-        enum { 
-          rsa, diffie_hellman, rsa_psk, diffie_hellman_psk 
-        } KeyExchangeAlgorithm; 
-    
-   Thus, the structure of the client key exchange becomes as follow: 
-    
-        struct { 
-         select (KeyEchangeAlgorithm){ 
-          case rsa: EncryptedPreMasterSecret; 
-          case diffie_hellman: ClientDiffieHellmanPublic; 
-          case rsa_psk: EncryptPreMasterSecretPSK; /*NEW/ 
-          case diffie_hellman_psk: ClientDiffieHellmanPublicPSK; /*NEW/ 
-          } exchange_key; 
-        } ClientKeyExchange; 
-    
-  2.2.1. rsa_psk encrypted premaster secret message 
-    
-   If rsa_psk is being used for key agreement, the client generates a 
-   30-byte random value, concatenates it with the pre shared key 
-   identity, encrypts the result (premaster secret) using the server 
-   public key and sends it in an encrypted premaster secret message. 
-    
-   Structure of the premaster secret: 
-    
-       struct { 
-         ProtocolVersion client_version; 
-         opaque random[30]; 
-         opaque psk_identity<1..2^16-1>; 
-         opaque pad[16-psk_identity.length]; 
-       } PreMasterSecret; 
-    
-       struct { public-key-encrypted PreMasterSecret pre_master_secret; 
-       } EncryptedPreMasterSecretPSK; 
-    
-   For interoperation issues, this document uses the same definition 
-   used in [TLSSRP]. Thus, the psk_identity SHALL be UTF-8 encoded 
-   Unicode, where the psk_identity is the pre shared key identifier. 
-    
-   If the psk_identity is less than 16 bytes in length, the premaster 
-   secret will be padded to obtain 46 bytes. For example, if the 
-   psk_identity length is 13 bytes, then the last three bytes of the 
-   premaster secret will be 0x03 0x03 0x03. This mechanism will allow 
-   the server to extract the psk_identity from the premaster secret. 
-    
-    
-
-
-Badra, et. al.           Expires - February 2005               [Page 4]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-  2.2.2. diffie_hellman_psk encrypted premaster secret message  
-    
-   Because the client does not use any certificate, its value Yc needs 
-   to be sent. As a result, the case implicit MAY be omitted. 
-    
-        struct { 
-            select (PublicValueEncoding) { 
-             case implicit: struct { }; 
-             case explicit: opaque dh_Yc<1..2^16-1>; 
-            } dh_public; 
-            opaque psk_identity<1..2^16-1>; 
-        } ClientDiffieHellmanPublicPSK; 
-    
-             dh_Yc 
-                 The client's Diffie-Hellman public value (Yc). 
-    
-             psk_identity 
-                 The pre shared key identifier. 
-    
-   The psk_identity helps the client to indicate which key it wants to 
-   use and the server to retrieve the corresponding pre shared key 
-   value, if exists. When using a Diffie-Hellman based key exchange 
-   method, the psk_identity is sent in the clear. 
-    
-2.4. Computing the master secret 
-    
-   This document uses the same mechanism defined in [TLS] for keys 
-   computation and calculation, except the master secret key. It 
-   generates the master secret by applying the PRF on the premaster 
-   secret XOR pre_shared_key value instead of the premaster secret: 
-    
-   master_secret = PRF(pre_master_secret XOR pre_shared_key, 
-                       "master_secret", 
-                       ClientHello.random + ServerHello.random)[0..47]; 
-    
-   As a result, if the server uses a static private key and if this key 
-   is compromised, the intruder must have the pre_shared_key to decrypt 
-   old sessions. 
-    
-   On the other hand, if either the client or the server calculates an 
-   incorrect premaster_secret XOR pre_shared_key value, the finished 
-   messages will fail to decrypt properly and the other party will 
-   return a bad_record_mac alert. This MAY happen when the server does 
-   not send its certificate and that a man-in-the-middle intercepts the 
-   session exchanges and sends its public key instead of the server 
-   public key. 
-    
-    
-    
-    
-
-
-Badra, et. al.           Expires - February 2005               [Page 5]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-2.5. Error Alerts 
-    
-   Three new TLS error alerts are defined by this document (This  
-   section is inspired by [TLSSRP]): 
-    
-   a) "unknown_psk_key_exchange" (integer) - this alert MAY be sent by 
-      a server that does not support any PSK key exchange methods sent 
-      by the client.  This alert is always a warning. Upon receiving 
-      this alert, the client MAY send a new hello message on the same 
-      connection using another TLS authentication methods. 
-    
-   b) "unknown_psk_identity" (integer) - this alert MAY be sent by a 
-      server that receives an unknown ticket identity.  This alert is 
-      always fatal. 
-    
-   c) "missing_psk_identity" (integer) - this alert MAY be sent by a 
-      server that would like to select an offered PSK key exchange 
-      method, if the MethodType extension is absent from the client's 
-      hello message.  This alert is always a warning. Upon receiving 
-      this alert, the client MAY send a new hello message on the same 
-      connection, this time including the MethodType extension. 
-    
-2.6. Handshake 
-    
-   In order to indicate the support of the shared key type, the client 
-   adds the extension "psk_key_exchange (9)" to its extended hello 
-   message. 
-    
-   When the server receives an extended client hello message, it 
-   replies by its hello that contains the following attributes: 
-   Protocol Version, Random, Session ID, Cipher Suite, and Compression 
-   Method. 
-    
-   If the server is able to agree on a key exchange method using the 
-   pre shared key, it will send its server key exchange message that 
-   contains the selected method. In this case, the Certificate message 
-   MAY be omitted from the response. 
-    
-   If the server does not support any PSK key exchange methods sent by 
-   the client, the server MAY abort the handshake with a 
-   unknown_key_exchange alert. 
-    
-   Now the server will send the server hello done message, indicating 
-   that the hello-message phase of the handshake is completed. 
-    
-   The client send its client key exchange message. The content of this 
-   message depends on the method selected between the client hello and 
-   the server key exchange messages. 
-    
-    
-    
-Badra, et. al.           Expires - February 2005               [Page 6]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-   The handshake exchange is given in the following diagram: 
-    
-            ClientHello         --------> 
-            (MethodType)                     ServerHello 
-                                             Certificate* 
-                                             ServerKeyExchange 
-                                <--------    ServerHelloDone 
-            ClientKeyExchange 
-            ChangeCipherSpec 
-            Finished            --------> 
-                                             ChangeCipherSpec 
-                                <--------    Finished 
-    
-      * Indicates an optional message which is not always sent. 
-    
-3. Security considerations 
-    
-   The server MUST stock the shared key in a secure and protected 
-   manner in order to prevent attackers from retrieving its value. 
-    
-   During the handshake phase, the server MAY send its certificate. The 
-   certificate's use protects entities against man-in-the-middle 
-   attack. 
-    
-   If the server certificate is omitted, the client and the server 
-   authenticate each other via the finished messages. In fact, the 
-   finished value is computed using the master_secret calculated during 
-   the establishment session and the pre shared key. Thus, if the 
-   client is intercepted by a bogus server, this later will be 
-   detectable by the client during the finished phase. As a result, no 
-   third party can calculate the same finished value without having the 
-   correct pre_shared_key. Instead, the third party MAY discover the 
-   pre shared key identity sent in the client key exchange message. 
-    
-   When using a Diffie-Hellman based PSK key exchange method, the 
-   client sends its psk_identity in the clear. In order to avoid this 
-   issue, the client could first open a conventional anonymous and then 
-   renegotiate a PSK key exchange method with the handshake protected 
-   by the first connection. Another solution MAY be done using the 
-   pseudonym management. 
-    
-3.1. Key management with non-human support 
-    
-   In the case where the client does not enter his credentials manually 
-   during the session establishment and that he does not need to 
-   remember them, then he can stock them on a secure token (e.g. 
-   smartcard) or in a local file. In this case, the server and the 
-   client MAY update the pre shared key value after each session has 
-   been formed. In this case, the both MAY add a seed to their 
-   credentials entries. By this method, the client's support and the 
-
-
-Badra, et. al.           Expires - February 2005               [Page 7]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-   server calculate the seed and update the pre shared key as following 
-   (in the session i): 
-    
-       seed(0) is a random on 16 bytes. 
-    
-       seed(i) = P_MD5(seed(i-1) XOR psk_identity, 
-                       "seed" +  
-                       ClientHello.random + ServerHello.random)[0..16]; 
-    
-       psk(i) = PRF(psk(i-1) XOR premaster secret(i), "pre shared key", 
-                    ServerHello.random + ClientHello.random)[0..48]; 
-    
-   With this mechanism, the psk_identity remains unchanged. However, 
-   when the client connect to the server, it sends the seed (seed(i-1) 
-   for session i) instead of the psk_identity. The rest of the protocol 
-   is unchangeable. This SHALL ensure, among other, PFS and anonymity. 
-    
-4. IANA Considerations 
-    
-   To be specified. 
-    
-5. Acknowledgment  
-    
-   This document has been inspired by [TLS], [TLSSRP] and [TLSPSK]. 
-   Thus, it reused extracts of these documents. 
-    
-6. References 
-    
-6.1. Normative References 
-    
-   [TLSEXT]  Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J. 
-             and Wright, T., "Transport Layer Security (TLS) 
-             Extensions", RFC 3546, June 2003. 
-    
-   [TLS]     Dierks, T., and Allen, C., "The TLS Protocol Version 1.0", 
-             RFC 2246, November 1998. 
-    
-   [ISATLS]  Hajjeh, I., and Serhrouchni, A., "ISAKMP Handshake for 
-             SSL/TLS", IEEE GLOBECOM'03, Vol. 3, San Francisco, USA, 
-             1-5 December 2003, Pages: 1481-1485. 
-    
-   [SPTLS]   Steiner, Michael, et. al., "Secure Password-Based Cipher 
-             Suite for TLS", ACM Transaction on Information and System 
-             Security, Vol. 4, No. 2, May 2001, Pages 134-157. 
-    
-6.2.  Informative References 
-    
-   [TLSSRP]  Taylor, D., Wu, T., Mavroyanopoulos, N., and Perrin, 
-             T., "Using SRP for TLS Authentication", 
-             draft-ietf-tls-srp-07.txt, Internet Draft (work in 
-             progress), June 2004. 
-Badra, et. al.           Expires - February 2005               [Page 8]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-   [TLSPSK]  Eronen, P., and Tschofenig, H., "Pre-Shared Key 
-             Ciphersuites for Transport Layer Security (TLS)", 
-             draft-eronen-tls-psk-00.txt, Internet Draft (work in 
-             progress), August 2004. 
-    
-   [TLSSK]   Gutmann, P.,"Use of Shared Keys in the TLS Protocol", 
-             draft-ietf-tls-sharedkeys-02.txt, Internet Draft  
-             (expired), October 2003. 
-    
-   [TSLEXP]  Badra, M., Serhrouchni, A., and Urien, P., "TLS Express", 
-             draft-badra-tls-express-00.txt, Internet Draft (work in 
-             progress), June 2004. 
-    
-6. Author's Addresses 
-    
-   Mohamad Badra 
-   ENST Telecom 
-   46 rue Barrault 
-   75634 Paris               Phone: NA 
-   France                    Email: Mohamad.Badra@enst.fr 
-    
-   Omar Cherkaoui 
-   UQAM University 
-   Montreal (Quebec)         Phone: NA 
-   Canada                    Email: cherkaoui.omar@uqam.ca 
-    
-   Ibrahim Hajjeh 
-   ENST Telecom 
-   46 rue Barrault 
-   75634 Paris               Phone: NA 
-   France                    Email: Ibrahim.Hajjeh@enst.fr 
-    
-   Ahmed Serhrouchni 
-   ENST Telecom 
-   46 rue Barrault 
-   75634 Paris               Phone: NA 
-   France                    Email: Ahmed.Serhrouchni@enst.fr 
-    
-   Intellectual Property Statement 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights. 
-   Information on the IETF's procedures with respect to rights in IETF 
-   Documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-Badra, et. al.           Expires - February 2005               [Page 9]
- 
-INTERNET-DRAFT        PSK key Exchange methods for TLS      August 2004 
- 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard. Please address the information to the IETF at  
-   ietf-ipr@ietf.org. 
-    
-   Disclaimer of Validity 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-   Copyright Statement 
-    
-   Copyright (C) The Internet Society (2004). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   Acknowledgment 
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Badra, et. al.           Expires - February 2005              [Page 10]
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-tls-password-00.txt b/doc/protocol/draft-badra-tls-password-00.txt
deleted file mode 100644
index 3900bf6335..0000000000
--- a/doc/protocol/draft-badra-tls-password-00.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
-
-
-Internet Engineering Task Force                                M. Badra 
-INTERNET DRAFT                                         LIMOS Laboratory 
-April 19, 2007                                    Expires: October 2007 
-    
-    
-          Password Ciphersuites for Transport Layer Security (TLS) 
-                      <draft-badra-tls-password-00.txt> 
-    
-    
-Status 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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  
-    
-   This Internet-Draft will expire on October 19, 2007. 
-    
-Copyright Notice 
-    
-   Copyright (C) The IETF Trust (2007). 
-    
-Abstract 
-    
-   This document specifies a set of new ciphersuites for the Transport 
-   Layer Security (TLS) protocol to support TLS client authentication 
-   based on passwords. These ciphersuites provide client credential 
-   protection. 
-    
-
-
-
-
-
- 
- 
-Badra                     Expires October 2007                 [Page 1] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-1 Introduction 
-    
-   TLS defines several ciphersuites providing authentication, data 
-   protection and session key exchange between two communicating 
-   entities. TLS uses public key certificates [TLS], Kerberos [KERB] or 
-   preshared key [PSK] for authentication. This document describes how 
-   to use passwords, shared in advance among the communicating parties, 
-   to authenticate the TLS clients. 
-    
-1.2 Requirements language and Terminologies 
-    
-   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 [KEYWORDS]. 
-    
-2. Password Key Exchange Algorithm 
-    
-   This document specifies a set of ciphersuites for TLS to make use of 
-   existing password databases (e.g. AAA databases) to support client 
-   password-based authentication. These ciphersuites reuse existing key 
-   exchange algorithms as well as existing MAC, stream and bloc ciphers 
-   algorithms from [TLS] and [TLSCTR], [TLSECC], [TLSAES] and [TLSCAM]. 
-   Their names include the text "PWD" to refer to the client 
-   authentication using passwords. An example is shown below. 
-    
-    CipherSuite                        Key Exchange   Cipher       Hash 
-    
-    TLS_PWD_RSA_WITH_AES_128_CBC_SHA   RSA            AES_128_CBC  SHA 
-    
-   Currently, a set of password authentication modes are available, 
-   such as One-time password, pin mode, Token. Some of these modes 
-   require multiple exchanges (round-trips) between the client and the 
-   server. This document treats currently password authentication modes 
-   which don't require more than one round-trip. 
-    
-2.1. Extending the client key exchange message 
-    
-   TLS defines the client key exchange message, which is used to convey 
-   the premaster secret. This secret is usually set; either through a 
-   direct transmission of the RSA-encrypted secret, or by the 
-   transmission of Diffie-Hellman parameters which will allow each side 
-   to agree upon the same premaster secret. The structure of this 
-   message depends on which key exchange method has been selected. The 
-   actual TLS specifications define several methods using usually RSA, 
-   Diffie_Hellman or PSK algorithms. 
-    
-   This document extends the client key exchange message with three new 
-   key exchange methods as following. It is described as following: 
-
- 
- 
-Badra                     Expires October 2007                 [Page 2] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-    
-        struct { 
-            select (KeyExchangeAlgorithm) { 
-            /* cases rsa, DH [TLS], ec_diffie_hellman [TLSECC]) */ 
-               case pwd_rsa: /* NEW */ 
-                 EncryptedPreMasterSecret; 
-                 EncryptedPWD; 
-               case pwd_dh: /* NEW */ 
-                 ClientDiffieHellmanPublic; 
-                 EncryptedPWD; 
-               case pwd_ec_diffie_hellman: /* NEW */ 
-                 ClientECDiffieHellmanPublic; 
-                 EncryptedPWD; 
-             } exchange_keys; 
-        } ClientKeyExchange; 
-    
-2.1.1. Cases pwd_rsa, pwd_dh and pwd_ec_diffie_hellman 
-    
-   If pwd_rsa is being used for key agreement, the client generates a 
-   48-byte random value (premaster secret), encrypts it using the 
-   server public key sent in the server key exchange message or in the 
-   server certificate. This is the same as in the RSA key exchange 
-   method. In the case of stream cipher encryption, the client 
-   generates a fresh random value and concatenates it to its username 
-   and password. Therefore, the client symmetrically encrypts the 
-   result using the client_write_key. The cipher algorithm is the same 
-   selected by the server in the ServerHello.cipher_suite. The result 
-   of the above operations called the EncryptedPWD, structured as 
-   follow. In the case of block cipher encryption, the client uses an 
-   explicit IV and adds padding value to force the length of the 
-   plaintext to be an integral multiple of the block cipher's block 
-   length, as it is described in section 6.2.3.2 of [TLS1.1]. 
-    
-        struct { 
-           uint16 length; 
-           select (CipherSpec.cipher_type) { 
-             case stream:  
-                   stream-ciphered struct { 
-                      opaque fresh_random<16..2^16-1>; 
-                      opaque login<1..2^16-1>; 
-                      opaque password<1..2^16-1>; 
-                  }; 
-             case block: 
-                   block-ciphered struct { 
-                      opaque IV[CipherSpec.block_length]; 
-                      opaque login<1..2^16-1>; 
-                      opaque password<1..2^16-1>; 
-                      uint8 padding[EncryptedPWD.padding_length]; 
-
- 
- 
-Badra                     Expires October 2007                 [Page 3] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-                      uint8 padding_length; 
-                  };    
-            } EncryptedPWD; 
-    
-   fresh_random  
-     A vector contains at least 16 bytes. 
-    
-   length 
-     The length (in bytes) of the EncryptedPWD structure. 
-    
-   padding 
-     Padding that is added to force the length of the EncryptedPWD 
-     structure to be an integral multiple of the block cipher's block  
-     length. The padding MAY be any length up to 255 bytes, as long as  
-     it results in the EncryptedPWD.length being an integral  
-     multiple of the block length. Lengths longer than necessary might  
-     be desirable to frustrate attacks on a protocol that are based on  
-     analysis of the lengths of exchanged messages. Each uint8 in the  
-     padding data vector MUST be filled with the padding length value.  
-     The receiver MUST check this padding and SHOULD use the  
-     bad_record_mac alert to indicate padding errors. 
-    
-   padding_length 
-     The padding length MUST be such that the total size of the 
-     EncryptedPWD structure is a multiple of the cipher's block  
-     length. Legal values range from zero to 255, inclusive. This 
-     length specifies the length of the padding field exclusive of the 
-     padding_length field itself. 
-    
-   Implementations of this document MUST ensure that all policies being 
-   applied on the PSK encoding (section 5 of [PSK]) are applied on the 
-   password encoding as well. 
-    
-   Editor note: is it more secure to don't send the password on the 
-   wire and instead of that, mix it with the premaster secret, and use 
-   the result as an input for the key derivation function to implicitly 
-   authenticate the client? 
-    
-   The client concatenates the EncryptedPreMasterSecret and the 
-   EncryptedPWD values before sending the result to the server through 
-   the client key exchange message. 
-    
-   Upon receipt of this message, the server decrypts the 
-   EncryptedPreMasterSecret using its private key and therefore 
-   computes the master_secret and derives the same client_write_key. 
-   Next, the server symmetrically decrypts the EncryptedPWD to retrieve 
-   the client username and the password in clear text. The server then 
-   checks its database for a match. If a match is found, the server 
-
- 
- 
-Badra                     Expires October 2007                 [Page 4] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-   sends its change cipher spec message and proceeds directly to 
-   finished message. If no match is found, the server MUST send a fatal 
-   alert, results in the immediate termination of the connection. 
-    
-   If the server does not recognize the login, it MAY respond with an 
-   "unknown_login" alert message. Alternatively, if the server wishes 
-   to hide the fact that the login was not known, it MAY continue the 
-   protocol as if the login existed but the key was incorrect: that is, 
-   respond with a "decrypt_error" alert. 
-    
-        Client                                               Server 
-        ------                                               ------ 
-     
-        ClientHello             --------> 
-                                                        ServerHello 
-                                                       Certificate* 
-                                                 ServerKeyExchange* 
-                                <--------           ServerHelloDone 
-        ClientKeyExchange 
-        ChangeCipherSpec 
-        Finished                --------> 
-                                                   ChangeCipherSpec 
-                                <--------                  Finished 
-        Application Data                           Application Data 
-        Attribute Value Pairs                 Attribute Value Pairs 
-        Type Length Value       <=======>         Type Length Value 
-    
-   The pwd_dh case is similar to pwd_rsa, except that the 
-   EncryptedPreMasterSecret is replaced with the parameter 
-   ClientDiffieHellmanPublic. 
-    
-   The pwd_ec_diffie_hellman case is similar to pwd_rsa, except that 
-   the EncryptedPreMasterSecret is replaced with the parameter 
-   ClientECDiffieHellmanPublic. 
-    
-3. Security Considerations 
-    
-   The security considerations described throughout [TLS], [DTLS], and 
-   [TLS1.1] apply here as well. 
-    
-4. IANA Considerations 
-    
-   This section provides guidance to the IANA regarding registration of 
-   values related to the client based-password authentication. 
-    
-   Note: For implementation and deployment facilities, it is helpful to 
-   reserve a specific registry sub-range (minor, major) for identity 
-   protection ciphersuites. 
-
- 
- 
-Badra                     Expires October 2007                 [Page 5] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-    
-   CipherSuite TLS_PWD_ITH_RC4_128_MD5                  ={ 0xXX,0xXX }; 
-   CipherSuite TLS PWD_RSA WITH_RC4_128_SHA             ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_RSA_WITH_IDEA_CBC_SHA            ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_RSA_WITH_DES_CBC_SHA             ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_RSA_WITH_3DES_EDE_CBC_SHA        ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_DSS_WITH_DES_CBC_SHA          ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_DSS_WITH_3DES_EDE_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_RSA_WITH_DES_CBC_SHA          ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_RSA_WITH_3DES_EDE_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_DSS_WITH_DES_CBC_SHA         ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_DSS_WITH_3DES_EDE_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_RSA_WITH_DES_CBC_SHA         ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_RSA_WITH_3DES_EDE_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_128_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_256_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_RSA_WITH_AES_128_CBC_SHA         ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_DSS_WITH_AES_128_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS PWD_DH_RSA_WITH_AES_128_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_DSS_WITH_AES_128_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_RSA_WITH_AES_128_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_RSA_WITH_AES_256_CBC_SHA         ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_DSS_WITH_AES_256_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DH_RSA_WITH_AES_256_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_DSS_WITH_AES_256_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_DHE_RSA_WITH_AES_256_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_ECDSA_WITH_RC4_128_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_128_CBC_SHA  ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_256_CBC_SHA  ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_RC4_128_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_RSA_WITH_RC4_128_SHA        ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_RSA_WITH_3DES_EDE_CBC_SHA   ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_128_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_256_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDHE_RSA_WITH_RC4_128_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA  ={ 0xXX,0xXX }; 
-
- 
- 
-Badra                     Expires October 2007                 [Page 6] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-   CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_128_CBC_SHA   ={ 0xXX,0xXX }; 
-   CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_256_CBC_SHA   ={ 0xXX,0xXX }; 
-    
-   This document also defines a new TLS alert message, 
-   unknown_login(TBD). 
-    
-5. References 
-    
-5.1. Normative References 
-    
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",  
-              RFC 2246, January 1999. 
-    
-   [TLS1.1]   Dierks, T. and E. Rescorla, "The TLS Protocol Version  
-              1.1", RFC 4346, April 2006. 
-    
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 
-              Requirement Levels", RFC 2119, March 1997. 
-    
-   [PSK]      Eronen, P. (Ed.) and H. Tschofenig (Ed.), "Pre-Shared Key  
-              Ciphersuites for Transport Layer Security (TLS)",  
-              RFC 4279, December 2005. 
-    
-   [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia  
-              Cipher Suites to Transport Layer Security (TLS)",  
-              RFC 4132, July 2005. 
-    
-   [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)  
-              Ciphersuites for Transport Layer Security (TLS)",  
-              RFC 3268, June 2002. 
-    
-   [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,  
-              Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher  
-              Suites for Transport Layer Security (TLS)", RFC 4492, May  
-              2006 
-    
-   [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher  
-              Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work  
-              in progress), June 2006. 
-    
-5.2. Informative References 
-    
-   [KERB]     Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 
-              Suites to Transport Layer Security (TLS)", RFC 2712, 
-              October 1999.  
-    
-    
-
-
- 
- 
-Badra                     Expires October 2007                 [Page 7] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-Author's Addresses 
-    
-   Mohamad Badra 
-   LIMOS Laboratory - UMR (6158), CNRS 
-   France             Email: badra@isima.fr 
-    
-Full Copyright Statement 
-    
-   Copyright (C) The IETF Trust (2007). 
-    
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-    
-Intellectual Property 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-Acknowledgment 
-
- 
- 
-Badra                     Expires October 2007                 [Page 8] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-    
-   Funding for the RFC Editor function is provided by the IETF 
-   Administrative Support Activity (IASA). 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                     Expires October 2007                 [Page 9] 
- 
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-tls-password-ext-00.txt b/doc/protocol/draft-badra-tls-password-ext-00.txt
deleted file mode 100644
index a33aee974a..0000000000
--- a/doc/protocol/draft-badra-tls-password-ext-00.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-Internet Engineering Task Force                                M. Badra 
-INTERNET DRAFT                                         LIMOS Laboratory 
-April 19, 2007                                    Expires: October 2007 
-    
-    
-              Password Extension for TLS Client Authentication 
-                    <draft-badra-tls-password-ext-00.txt> 
-    
-    
-Status 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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  
-    
-   This Internet-Draft will expire on October 19, 2007. 
-    
-Copyright Notice 
-    
-   Copyright (C) The IETF Trust (2007).  
-    
-Abstract 
-    
-   This document specifies a new TLS extension and a new TLS message 
-   providing TLS client authentication using passwords. It provides 
-   client credential protection. 
-    
-
-
-
-
-
-
- 
- 
-Badra                     Expires October 2007                 [Page 1] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-1 Introduction 
-    
-   This document defines a new extension and a new TLS message to the 
-   TLS protocol to enable TLS client authentication using passwords. It 
-   provides client credential protection. 
-    
-1.2 Requirements language and Terminologies 
-    
-   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 [KEYWORDS]. 
-    
-2. Password Extension 
-    
-   In order to negotiate the use of client password-based 
-   authentication, clients MAY include an extension of type "password" 
-   in the extended client hello. The "extension_data" field of this 
-   extension SHALL be empty. The extension_type field is to be assigned 
-   by IANA. 
-    
-   For servers aware of the password extension but not wishing to use 
-   it, it will gracefully revert to an ordinary TLS handshake or stop 
-   the negotiation. 
-    
-   Servers that receive an extended hello containing a "password" 
-   extension MAY agree to authenticate the client using passwords by 
-   including an extension of type "password", with empty 
-   "extension_data", in the extended server hello. The 
-   CertificateRequest payload is omitted from the server response. 
-    
-   Clients return a response along with their credentials by sending a 
-   "EncryptedPassword" message immediately after the 
-   "ClientKeyExchange" message. The encrypted password message is sent 
-   symmetrically encrypted with the key client_write_key and the cipher 
-   algorithm selected by the server in the ServerHello.cipher_suite. 
-   The Certificate and CertificateVerify payloads are omitted from the 
-   client response. 
-    
-2.1. Encrypted Password 
-    
-   When this message will be sent: 
-    
-   The client MUST send this message immediately after the client key 
-   exchange message. 
-    
-    
-    
-    
-
- 
- 
-Badra                     Expires October 2007                 [Page 2] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-    
-   Structure of this message: 
-    
-        struct { 
-           uint16 length; 
-           select (CipherSpec.cipher_type) { 
-             case stream:  
-                   stream-ciphered struct { 
-                      opaque fresh_random<16..2^16-1>; 
-                      opaque login<1..2^16-1>; 
-                      opaque password<1..2^16-1>; 
-                  }; 
-             case block: 
-                   block-ciphered struct { 
-                      opaque IV[CipherSpec.block_length]; 
-                      opaque login<1..2^16-1>; 
-                      opaque password<1..2^16-1>; 
-                      uint8 padding[EncryptedPassword.padding_length]; 
-                      uint8 padding_length; 
-                  };    
-            } EncryptedPassword; 
-    
-   fresh_random  
-     A vector contains at least 16 bytes. 
-    
-   length 
-     The length (in bytes) of the EncryptedPassword structure. 
-    
-   padding 
-     Padding that is added to force the length of the EncryptedPassword  
-     structure to be an integral multiple of the block cipher's block  
-     length. The padding MAY be any length up to 255 bytes, as long as  
-     it results in the EncryptedPassword.length being an integral  
-     multiple of the block length. Lengths longer than necessary might  
-     be desirable to frustrate attacks on a protocol that are based on  
-     analysis of the lengths of exchanged messages. Each uint8 in the  
-     padding data vector MUST be filled with the padding length value.  
-     The receiver MUST check this padding and SHOULD use the  
-     bad_record_mac alert to indicate padding errors. 
-    
-   padding_length 
-     The padding length MUST be such that the total size of the 
-     EncryptedPassword structure is a multiple of the cipher's block  
-     length. Legal values range from zero to 255, inclusive. This 
-     length specifies the length of the padding field exclusive of the 
-     padding_length field itself. 
-    
-
-
- 
- 
-Badra                     Expires October 2007                 [Page 3] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-   BulkCipherAlgorithm.null (e.g. TLS_RSA_WITH_NULL_MD5 and 
-   RSA_WITH_NULL_SHA) MUST NOT be negotiated when password extension is 
-   deployed, as it provides no more protection than an unsecured 
-   connection. 
-    
-   Implementations of this document MUST ensure that all policies being 
-   applied on the PSK encoding (section 5 of [PSK]) are applied on the 
-   password encoding as well. 
-    
-   Editor note: is it more secure to don't send the password on the 
-   wire and instead of that, mix it with the premaster secret, and use 
-   the result as an input for the key derivation function to implicitly 
-   authenticate the client? 
-    
-   Upon receipt of this message, the server symmetrically decrypts the 
-   EncryptedPassword using the same key as the client to retrieve the 
-   username and the password in clear text. The server then checks its 
-   database for a match. If a match is found, the server sends its 
-   change cipher spec message and proceeds directly to finished 
-   message. If no match is found, the server MUST send a fatal alert, 
-   results in the immediate termination of the connection. 
-    
-   If the server does not recognize the login, it MAY respond with an 
-   "unknown_login" alert message. Alternatively, if the server wishes 
-   to hide the fact that the login was not known, it MAY continue the 
-   protocol as if the login existed but the key was incorrect: that is, 
-   respond with a "decrypt_error" alert. 
-    
-        Client                                               Server 
-        ------                                               ------ 
-     
-        ClientHello             --------> 
-                                                        ServerHello 
-                                                       Certificate* 
-                                                 ServerKeyExchange* 
-                                <--------           ServerHelloDone 
-        ClientKeyExchange 
-        EncryptedPassword 
-        ChangeCipherSpec 
-        Finished                --------> 
-                                                   ChangeCipherSpec 
-                                <--------                  Finished 
-        Application Data                           Application Data 
-        Attribute Value Pairs                 Attribute Value Pairs 
-        Type Length Value       <=======>         Type Length Value 
-    
-3. Security Considerations 
-    
-
- 
- 
-Badra                     Expires October 2007                 [Page 4] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-   The security considerations described throughout [TLS], [DTLS], and 
-   [TLS1.1] apply here as well. 
-    
-4. IANA Considerations 
-    
-   This document defines a new TLS extension "password", assigned the 
-   value TBD from the TLS ExtensionType registry defined in [TLSEXT]. 
-    
-   This document also defines a new TLS alert message, 
-   unknown_login(TBD). 
-    
-   This document defines a new handshake message, encrypted password, 
-   whose value is to be allocated from the TLS HandshakeType registry 
-   defined in [TLS]. 
-    
-5. References 
-    
-5.1. Normative References 
-    
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",  
-              RFC 2246, January 1999. 
-    
-   [TLSExt]   Blake-Wilson, S., et. al., "Transport Layer Security TLS)  
-              Extensions", RFC 4346, April 2006. 
-    
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 
-              Requirement Levels", RFC 2119, March 1997. 
-    
-   [PSK]      Eronen, P. (Ed.) and H. Tschofenig (Ed.), "Pre-Shared Key  
-              Ciphersuites for Transport Layer Security (TLS)",  
-              RFC 4279, December 2005. 
-    
-   [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia  
-              Cipher Suites to Transport Layer Security (TLS)",  
-              RFC 4132, July 2005. 
-    
-   [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)  
-              Ciphersuites for Transport Layer Security (TLS)",  
-              RFC 3268, June 2002. 
-    
-   [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,  
-              Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher  
-              Suites for Transport Layer Security (TLS)", RFC 4492, May  
-              2006 
-    
-   [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher  
-              Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work  
-              in progress), June 2006. 
-
- 
- 
-Badra                     Expires October 2007                 [Page 5] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-    
-5.2. Informative References 
-    
-   [KERB]     Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 
-              Suites to Transport Layer Security (TLS)", RFC 2712, 
-              October 1999.  
-    
-Author's Addresses 
-    
-   Mohamad Badra 
-   LIMOS Laboratory - UMR (6158), CNRS 
-   France             Email: badra@isima.fr 
-    
-Full Copyright Statement 
-    
-   Copyright (C) The IETF Trust (2007). 
-    
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-    
-Intellectual Property 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-
- 
- 
-Badra                     Expires October 2007                 [Page 6] 
- 
-Internet-draft        Password Ciphersuites for TLS          April 2007 
- 
- 
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-Acknowledgment 
-    
-   Funding for the RFC Editor function is provided by the IETF 
-   Administrative Support Activity (IASA). 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                     Expires October 2007                 [Page 7] 
- 
\ No newline at end of file
diff --git a/doc/protocol/draft-badra-tls-password-ext-01.txt b/doc/protocol/draft-badra-tls-password-ext-01.txt
deleted file mode 100644
index eb7c0e78b8..0000000000
--- a/doc/protocol/draft-badra-tls-password-ext-01.txt
+++ /dev/null
@@ -1,431 +0,0 @@
-TLS Working Group                                         Mohamad Badra 
-Internet Draft                                         LIMOS Laboratory 
-Intended status: Standards Track                      February 24, 2008 
-Expires: August 2008 
-                                    
- 
-                                      
-           Password Extension for the TLS Client Authentication 
-                    draft-badra-tls-password-ext-01.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on August 24, 2008. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2008). 
-
-Abstract 
-
-   This document specifies a new Transport Layer Security (TLS) 
-   extension and a new TLS message providing TLS client authentication 
-   using passwords.  It provides client credential protection. 
-
-
-
- 
- 
- 
-Badra                  Expires August 24, 2008                 [Page 1] 
-
-Internet-Draft        Password Extension for TLS          February 2008 
-    
-
-Table of Contents 
-
-    
-   1. Introduction...................................................3 
-      1.1. Conventions used in this document.........................3 
-   2. Password Extension.............................................3 
-      2.1. Encrypted Password........................................3 
-   3. Conformance Requirements.......................................6 
-      3.1. Requirements for Management Interfaces....................6 
-   4. Security Considerations........................................6 
-   5. IANA Considerations............................................6 
-   6. References.....................................................7 
-      6.1. Normative References......................................7 
-      6.2. Informative References....................................7 
-   Author's Addresses................................................7 
-   Intellectual Property Statement...................................7 
-   Disclaimer of Validity............................................8 
-    
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
- 
-
-
-
-
- 
- 
-Badra                  Expires August 24, 2008                 [Page 2] 
-
-Internet-Draft        Password Extension for TLS          February 2008 
-    
-
-1. Introduction 
-
-   This document defines a new extension and a new TLS message to the 
-   Transport Layer Security (TLS) protocol to enable TLS client 
-   authentication using passwords.  It provides client credential 
-   protection.  
-
-1.1. 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 [RFC2119]. 
-
-2. Password Extension 
-
-   In order to negotiate the use of client password-based 
-   authentication, clients MAY include an extension of type "password" 
-   in the extended client hello.  The "extension_data" field of this 
-   extension SHALL be empty.  The extension_type field is to be assigned 
-   by IANA.  
-
-   For servers aware of the password extension but not wishing to use 
-   it, it will gracefully revert to an ordinary TLS handshake or stop 
-   the negotiation.  
-
-   Servers that receive an extended hello containing a "password" 
-   extension MAY agree to authenticate the client using passwords by 
-   including an extension of type "password", with empty 
-   "extension_data", in the extended server hello.  The 
-   CertificateRequest payload is omitted from the server response. 
-
-   Clients return a response along with their credentials by sending a 
-   "EncryptedPassword" message immediately after the "ClientKeyExchange" 
-   message.  The encrypted password message is sent symmetrically 
-   encrypted with the key client_write_key and the cipher algorithm 
-   selected by the server in the ServerHello.cipher_suite. 
-
-   The Certificate and CertificateVerify payloads are omitted from the 
-   client response. 
-
-2.1. Encrypted Password 
-
-   When this message will be sent:  
-
-   The client MUST send this message immediately after the client key 
-   exchange message.  
-
- 
- 
-Badra                  Expires August 24, 2008                 [Page 3] 
-
-Internet-Draft        Password Extension for TLS          February 2008 
-    
-
-   Structure of this message:  
-
-        struct {  
-              uint16 length;  
-              select (CipherSpec.cipher_type) {  
-                case stream:   
-                      stream-ciphered struct {  
-                         opaque fresh_random<16..2^16-1>;  
-                         opaque username<1..2^16-1>;  
-                         opaque password<1..2^16-1>;  
-                     };  
-                case block:  
-                      block-ciphered struct {  
-                         opaque IV[CipherSpec.block_length];  
-                         opaque username<1..2^16-1>;  
-                         opaque password<1..2^16-1>;  
-                         uint8 adding[EncryptedPassword.padding_length];  
-                         uint8 padding_length;  
-                     };     
-               } EncryptedPassword;  
-
-   fresh_random  
-
-   A vector contains at least 16 bytes random value.  It is RECOMMENDED 
-   that implementations provide functionality for generating this 
-   random, taking [RFC4086] into account. 
-
-   length  
-
-     The length (in bytes) of the EncryptedPassword structure.  
-
-   padding  
-
-     Padding that is added to force the length of the EncryptedPassword 
-     structure to be an integral multiple of the block cipher's block 
-     length.  The padding MAY be any length up to 255 bytes, as long as 
-     it results in the EncryptedPassword.length being an integral 
-     multiple of the block length.  Lengths longer than necessary might 
-     be desirable to frustrate attacks on a protocol that are based on 
-     analysis of the lengths of exchanged messages.  Each uint8 in the 
-     padding data vector MUST be filled with the padding length value.  
-     The receiver MUST check this padding and SHOULD use the 
-     bad_record_mac alert to indicate padding errors.  
-
-    
-
-    
- 
- 
-Badra                  Expires August 24, 2008                 [Page 4] 
-
-Internet-Draft        Password Extension for TLS          February 2008 
-    
-
-   padding_length 
-
-     The padding length MUST be such that the total size of the 
-     EncryptedPassword structure is a multiple of the cipher's block 
-     length.  Legal values range from zero to 255, inclusive.  This 
-     length specifies the length of the padding field exclusive of the 
-     padding_length field itself.  
-
-   BulkCipherAlgorithm.null (e.g.  TLS_RSA_WITH_NULL_MD5 and 
-   RSA_WITH_NULL_SHA) MUST NOT be negotiated when password extension is 
-   deployed, as it provides no more protection than an unsecured 
-   connection.  
-
-   Upon receipt of this message, the server symmetrically decrypts the 
-   EncryptedPassword using the same key as the client to retrieve the 
-   username and the password in clear text.  
-
-   Next, the server will then check the authentication database to see 
-   if the received username/password and those stored in the database 
-   match.  If a match is found, the server sends its change cipher spec 
-   message and proceeds directly to finished message.  If no match is 
-   found, the server MUST send a fatal alert, results in the immediate 
-   termination of the connection. 
-
-   This documents doesn't specify how exactly the server checks the 
-   username/password for a match.  However, the server MAY consider 
-   using of an AAA or RADIUS infrastructures.  In this case, the server 
-   calls into the local AAA client, which in turn contacts the AAA 
-   server.  The client's credentials (username and password) are 
-   validated at the AAA server, which in turn responds to the AAA client 
-   with an accept/reject message. 
-
-        Client                                               Server  
-        ------                                               ------  
-        ExtendedClientHello     -------->  
-                                                ExtendedServerHello  
-                                                        Certificate 
-                                                 ServerKeyExchange*  
-                                <--------           ServerHelloDone  
-        ClientKeyExchange  
-        EncryptedPassword  
-        ChangeCipherSpec  
-        Finished                -------->  
-                                                   ChangeCipherSpec  
-                                <--------                  Finished 
-    
-
- 
- 
-Badra                  Expires August 24, 2008                 [Page 5] 
-
-Internet-Draft        Password Extension for TLS          February 2008 
-    
-
-3. Conformance Requirements 
-
-   This document does not specify how the server stores the password and 
-   the username, or how exactly it verifies the password and the 
-   username it receives.  It is RECOMMENDED that before looking up the 
-   password, the server processes the username with a SASLprep profile 
-   [RFC4013] appropriate for the username in question. 
-
-3.1. Requirements for Management Interfaces 
-
-   In the absence of an application profile specification specifying 
-   otherwise, a management interface for entering the password and/or 
-   the username MUST support the following: 
-
-      o   Entering usernames consisting of up to 128 printable Unicode 
-          characters. 
-
-      o   Entering passwords up to 64 octets in length as ASCII strings  
-          and in hexadecimal encoding.  The management interface MAY  
-          accept other encodings if the algorithm for translating the  
-          encoding to a binary string is specified.  
-
-4. Security Considerations 
-
-   The security considerations described throughout [RFC4346] and 
-   [RFC4366] apply here as well. 
-
-5. IANA Considerations 
-
-   This document defines a new TLS extension "password", assigned the 
-   value to be allocated from the TLS ExtensionType registry defined in 
-   [RFC4366]. 
-
-   This document defines a new handshake message, encrypted password, 
-   whose value is to be allocated from the TLS HandshakeType registry 
-   defined in [RFC4346]. 
-
-    
-
-    
-
-    
-
-
-
-
-
- 
- 
-Badra                  Expires August 24, 2008                 [Page 6] 
-
-Internet-Draft        Password Extension for TLS          February 2008 
-    
-
-6. References 
-
-6.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 
-             "Randomness Requirements for Security", BCP 106, RFC 4086, 
-             June 2005. 
-
-   [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 
-             (TLS) Protocol 1.1", RFC 4346, April 2006. 
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 
-             and T. Wright, "Transport Layer Security (TLS) Extensions", 
-             RFC 4366, April 2006. 
-
-6.2. Informative References 
-
-   [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 
-             and Passwords", RFC 4013, February 2005. 
-
-    
-
-Author's Addresses 
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-       
-   Email: badra@isima.fr 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
- 
- 
-Badra                  Expires August 24, 2008                 [Page 7] 
-
-Internet-Draft        Password Extension for TLS          February 2008 
-    
-
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2008). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                  Expires August 24, 2008                 [Page 8] 
-
diff --git a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-00.txt b/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-00.txt
deleted file mode 100644
index c0eb4c19c4..0000000000
--- a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-00.txt
+++ /dev/null
@@ -1,539 +0,0 @@
-TLS Working Group                                         Mohamad Badra 
-Internet Draft                                         LIMOS Laboratory 
-Intended status: Standards Track                         March 29, 2008 
-Expires: September 2008 
-                                    
- 
-                                      
-         Pre-Shared Key Cipher Suites for Transport Layer Security        
-               with SHA-256/384 and AES Galois Counter Mode  
-                draft-badra-tls-psk-new-mac-aes-gcm-00.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on September 29, 2008. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2008). 
-
-Abstract 
-
-   RFC 4279 and RFC 4785 describe pre-shared key cipher suites for 
-   Transport Layer Security (TLS).  However, all those cipher suites 
-   use SHA-1 as their MAC algorithm.  This document describes a set of 
-   cipher suites for TLS/DTLS which uses stronger digest algorithms 
-
- 
- 
- 
-Badra                 Expires September 29, 2008               [Page 1] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-   (i.e. SHA-256 or SHA-384) and another which uses AES in Galois 
-   Counter Mode (GCM). 
-
-Table of Contents 
-
-    
-   1. Introduction...................................................3 
-      1.1. Conventions used in this document.........................3 
-   2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..3 
-   3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4 
-      3.1. PSK Key Exchange Algorithm with SHA-256/384...............4 
-      3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5 
-      3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5 
-   4. TLS Versions...................................................6 
-   5. Security Considerations........................................6 
-      5.1. Counter Reuse with GCM....................................6 
-      5.2. Recommendations for Multiple Encryption Processors........6 
-   6. IANA Considerations............................................7 
-   7. Acknowledgments................................................8 
-   8. References.....................................................8 
-      8.1. Normative References......................................8 
-      8.2. Informative References....................................9 
-   Author's Addresses................................................9 
-   Intellectual Property Statement..................................10 
-   Disclaimer of Validity...........................................10 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 2] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-1. Introduction 
-
-   This document describes the use of AES [AES] in Galois Counter Mode 
-   (GCM) [GCM] (AES-GCM) with various pre-shared key (PSK) key exchange 
-   mechanisms ([RFC4279] and [RFC4785]) as a ciphersuite for Transport 
-   Layer Security (TLS).  AES-GCM is not only efficient and secure, but 
-   hardware implementations can achieve high speeds with low cost and 
-   low latency, because the mode can be pipelined. 
-
-   This document also specifies PSK cipher suites for TLS which replace 
-   SHA-256 and SHA-384 rather than SHA-1. RFC 4279 [RFC4279] and RFC 
-   4785 [RFC4785] describe pre-shared key (PSK) cipher suites for TLS.  
-   However, all of the RFC 4279 and the RFC 4785 suites use HMAC-SHA1 
-   as their MAC algorithm.  Due to recent analytic work on SHA-1 
-   [Wang05], the IETF is gradually moving away from SHA-1 and towards 
-   stronger hash algorithms. 
-
-   [I-D.ietf-tls-ecc-new-mac] and [I-D.ietf-tls-rsa-aes-gcm] provide 
-   support for GCM with other key establishment methods. 
-
-1.1. 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 [RFC2119]. 
-
-2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM 
-
-   The following eight cipher suites use the new authenticated 
-   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode 
-   (GCM) [GCM]: 
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-
-   These cipher suites use authenticated encryption with additional 
-   data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in 
-   RFC 5116.  The "nonce" input to the AEAD algorithm SHALL be 12 bytes 
-   long, and is "partially implicit" (see Section 3.2.1 of RFC 5116).  
-   Part of the nonce is generated as part of the handshake process and 
-   is static for the entire session and part is carried in each packet. 
- 
- 
-Badra                 Expires September 29, 2008               [Page 3] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-                struct { 
-                   opaque salt[4]; 
-                   opaque explicit_nonce_part[8]; 
-                } GCMNonce. 
-
-   The salt value is either the client_write_IV if the client is 
-   sending or the server_write_IV if the server is sending.  These IVs 
-   SHALL be 4 bytes long.  Therefore, for all the algorithms defined in 
-   this section, SecurityParameters.fixed_iv_length=4. 
-
-   The explicit_nonce_part is chosen by the sender and included in the 
-   packet.  Each value of the explicit_nonce_part MUST be distinct from 
-   all other values, for any fixed key.  Failure to meet this 
-   uniqueness requirement can significantly degrade security.  The 
-   explicit_nonce_part is carried in the IV field of the 
-   GenericAEADCipher structure.  Therefore, for all the algorithms 
-   defined in this section, SecurityParameters.record_iv_length=8. 
-
-   In the case of TLS the counter MAY be the 64-bit sequence number.  
-   In the case of Datagram TLS [RFC4347] the counter MAY be formed from 
-   the concatenation of the 16-bit epoch with the 48-bit sequence 
-   number. 
-
-   The PRF algorithms SHALL be as follows: 
-
-   For ciphersuites ending in _SHA256 the hash function is SHA256. 
-
-   For ciphersuites ending in _SHA384 the hash function is SHA384. 
-
-3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384 
-
-   The cipher suites described in this section use AES [AES] in CBC 
-   [CBC] mode with an HMAC-based MAC. 
-
-3.1. PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
-
-   The above six cipher suites are the same as the corresponding cipher 
-   suites in RFC 4279 and RFC 4785 (TLS_PSK_WITH_AES_128_CBC_SHA, 
-   TLS_PSK_WITH_AES_256_CBC_SHA, and TLS_PSK_WITH_NULL_SHA) except for 
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 4] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-   the hash and PRF algorithms, which are SHA-256 and SHA-384 [SHS] as 
-   follows. 
-
-   Cipher Suite                             MAC             PRF 
-   ------------                             ---             --- 
-   TLS_PSK_WITH_AES_128_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_AES_128_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
-   TLS_PSK_WITH_AES_256_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_AES_256_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
-   TLS_PSK_WITH_NULL_SHA256                 HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_NULL_SHA384                 HMAC-SHA-384    P_SHA-384 
-
-3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
-
-   The above six cipher suites are the same as the corresponding cipher 
-   suites in RFC 4279 and RFC 4785 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA, 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA, and TLS_DHE_PSK_WITH_NULL_SHA) 
-   except for the hash and PRF algorithms, which are SHA-256 and SHA-
-   384 [SHS] as follows. 
-
-   Cipher Suite                             MAC             PRF 
-   ------------                             ---             --- 
-   TLS_DHE_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_DHE_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-
-3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384    = {0xXX,0xXX}; 
-
-   The above four cipher suites are the same as the corresponding 
-   cipher suites in RFC 4279 and RFC 4785 
-   (TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_PSK_WITH_AES_256_CBC_SHA, 
-   and TLS_RSA_PSK_WITH_NULL_SHA) except for the hash and PRF 
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows. 
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 5] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-   Cipher Suite                             MAC             PRF 
-   ------------                             ---             --- 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-   TLS_RSA_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_RSA_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-
-4. TLS Versions 
-
-   Because these cipher suites depend on features available only in TLS 
-   1.2 (PRF flexibility and combined authenticated encryption cipher 
-   modes), they MUST NOT be negotiated by older versions of TLS. 
-   Clients MUST NOT offer these cipher suites if they do not offer TLS 
-   1.2 or later.  Servers which select an earlier version of TLS MUST 
-   NOT select one of these cipher suites.  Because TLS has no way for 
-   the client to indicate that it supports TLS 1.2 but not earlier, a 
-   non-compliant server might potentially negotiate TLS 1.1 or earlier 
-   and select one of the cipher suites in this document.  Clients MUST 
-   check the TLS version and generate a fatal "illegal_parameter" alert 
-   if they detect an incorrect version. 
-
-5. Security Considerations 
-
-   The security considerations in [I-D.ietf-tls-rfc4346-bis], RFC 4279 
-   and RFC 4785 apply to this document as well.  The remainder of this 
-   section describes security considerations specific to the cipher 
-   suites described in this document. 
-
-5.1. Counter Reuse with GCM 
-
-   AES-GCM is only secure if the counter is never reused.  The IV 
-   construction algorithm above is designed to ensure that this cannot 
-   happen. 
-
-5.2. Recommendations for Multiple Encryption Processors 
-
-   If multiple cryptographic processors are in use by the sender, then 
-   the sender MUST ensure that, for a particular key, each value of the 
-   explicit_nonce_part used with that key is distinct.  In this case 
-   each encryption processor SHOULD include in the explicit_nonce_part 
-   a fixed value that is distinct for each processor.  The recommended 
-   format is 
-
-        explicit_nonce_part = FixedDistinct || Variable 
-
-   where the FixedDistinct field is distinct for each encryption 
-   processor, but is fixed for a given processor, and the Variable 
- 
- 
-Badra                 Expires September 29, 2008               [Page 6] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-   field is distinct for each distinct nonce used by a particular 
-   encryption processor.  When this method is used, the FixedDistinct 
-   fields used by the different processors MUST have the same length. 
-
-   In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common 
-   part of the nonce (it is fixed, and it is common across all 
-   encryption processors), the FixedDistinct field exactly corresponds 
-   to the Fixed-Distinct field, and the Variable field corresponds to 
-   the Counter field, and the explicit part exactly corresponds to the 
-
-   explicit_nonce_part. 
-
-   For clarity, we provide an example for TLS in which there are two 
-   distinct encryption processors, each of which uses a one-byte 
-   FixedDistinct field: 
-
-          Salt          = eedc68dc 
-          FixedDistinct = 01      (for the first encryption processor) 
-          FixedDistinct = 02      (for the second encryption processor) 
-
-   The GCMnonces generated by the first encryption processor, and their 
-   corresponding explicit_nonce_parts, are: 
-
-          GCMNonce                    explicit_nonce_part 
-          ------------------------    -------------------- 
-          eedc68dc0100000000000000    0100000000000000 
-          eedc68dc0100000000000001    0100000000000001 
-          eedc68dc0100000000000002    0100000000000002 
-          ... 
-
-   The GCMnonces generated by the second encryption processor, and 
-   their corresponding explicit_nonce_parts, are 
-
-          GCMNonce                    explicit_nonce_part 
-          ------------------------    -------------------- 
-          eedc68dc0200000000000000    0200000000000000 
-          eedc68dc0200000000000001    0200000000000001 
-          eedc68dc0200000000000002    0200000000000002 
-          ... 
-
-6. IANA Considerations 
-
-   IANA has assigned the following values for the cipher suites defined 
-   in this document: 
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
- 
- 
-Badra                 Expires September 29, 2008               [Page 7] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};    
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-
-7. Acknowledgments 
-
-   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and [I-
-   D.ietf-tls-rsa-aes-gcm]. 
-
-8. References 
-
-8.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [I-D.ietf-tls-rfc4346-bis] 
-             Dierks, T. and E. Rescorla, "The Transport Layer Security 
-             (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-
-             10, work in progress, March 2008. 
-
-   [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 
-             Encryption", RFC 5116, January 2008.  
-
-   [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005.  
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 8] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-   [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 
-             Ciphersuites with NULL Encryption for Transport Layer 
-             Security (TLS)", RFC 4785, January 2007. 
-
-   [AES]     National Institute of Standards and Technology, 
-             "Specification for the Advanced Encryption Standard 
-             (AES)", FIPS 197, November 2001. 
-
-   [SHS]     National Institute of Standards and Technology, "Secure 
-             Hash Standard", FIPS 180-2, August 2002. 
-
-   [CBC]     National Institute of Standards and Technology, 
-             "Recommendation for Block Cipher Modes of Operation - 
-             Methods and Techniques", SP 800-38A, December 2001. 
-
-   [GCM]     National Institute of Standards and Technology, 
-             "Recommendation for Block Cipher Modes of Operation: 
-             Galois;/Counter Mode (GCM) for Confidentiality and 
-             Authentication", SP 800-38D, November 2007. 
-
-8.2. Informative References 
-
-   [Wang05]  Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 
-             Full SHA-1", CRYPTO 2005, August 2005. 
-
-   [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 
-             Security", RFC 4347, April 2006. 
-
-   [I-D.ietf-tls-ecc-new-mac] 
-             Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-             256/384 and AES Galois Counter  Mode", draft-ietf-tls-ecc-
-             new-mac-04 (work in progress), February 2008. 
-
-   [I-D.ietf-tls-rsa-aes-gcm] 
-             Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES-
-             GCM Cipher Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02 
-             (work in progress), February 2008. 
-
-Author's Addresses 
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-    
-   Email: badra@isima.fr 
-    
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 9] 
-
-Internet-Draft     ECDHE_PSK Cipher Suites for TLS           March 2008 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2008). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
- 
- 
-Badra                 Expires September 29, 2008              [Page 10] 
-
diff --git a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-01.txt b/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-01.txt
deleted file mode 100644
index d97fe10b77..0000000000
--- a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-01.txt
+++ /dev/null
@@ -1,539 +0,0 @@
-TLS Working Group                                         Mohamad Badra 
-Internet Draft                                         LIMOS Laboratory 
-Intended status: Standards Track                         March 29, 2008 
-Expires: September 2008 
-                                    
- 
-                                      
-         Pre-Shared Key Cipher Suites for Transport Layer Security        
-               with SHA-256/384 and AES Galois Counter Mode  
-                draft-badra-tls-psk-new-mac-aes-gcm-01.txt 
-
-
-Status of this Memo                      
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on September 29, 2008. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2008). 
-
-Abstract 
-
-   RFC 4279 and RFC 4785 describe pre-shared key cipher suites for 
-   Transport Layer Security (TLS).  However, all those cipher suites 
-   use SHA-1 as their MAC algorithm.  This document describes a set of 
-   cipher suites for TLS/DTLS which uses stronger digest algorithms 
-
- 
- 
- 
-Badra                 Expires September 29, 2008               [Page 1] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-   (i.e. SHA-256 or SHA-384) and another which uses AES in Galois 
-   Counter Mode (GCM). 
-
-Table of Contents 
-
-    
-   1. Introduction...................................................3 
-      1.1. Conventions used in this document.........................3 
-   2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..3 
-   3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4 
-      3.1. PSK Key Exchange Algorithm with SHA-256/384...............4 
-      3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5 
-      3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5 
-   4. TLS Versions...................................................6 
-   5. Security Considerations........................................6 
-      5.1. Counter Reuse with GCM....................................6 
-      5.2. Recommendations for Multiple Encryption Processors........6 
-   6. IANA Considerations............................................7 
-   7. Acknowledgments................................................8 
-   8. References.....................................................8 
-      8.1. Normative References......................................8 
-      8.2. Informative References....................................9 
-   Author's Addresses................................................9 
-   Intellectual Property Statement..................................10 
-   Disclaimer of Validity...........................................10 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 2] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-1. Introduction 
-
-   This document describes the use of AES [AES] in Galois Counter Mode 
-   (GCM) [GCM] (AES-GCM) with various pre-shared key (PSK) key exchange 
-   mechanisms ([RFC4279] and [RFC4785]) as a ciphersuite for Transport 
-   Layer Security (TLS).  AES-GCM is not only efficient and secure, but 
-   hardware implementations can achieve high speeds with low cost and 
-   low latency, because the mode can be pipelined. 
-
-   This document also specifies PSK cipher suites for TLS which replace 
-   SHA-256 and SHA-384 rather than SHA-1. RFC 4279 [RFC4279] and RFC 
-   4785 [RFC4785] describe pre-shared key (PSK) cipher suites for TLS.  
-   However, all of the RFC 4279 and the RFC 4785 suites use HMAC-SHA1 
-   as their MAC algorithm.  Due to recent analytic work on SHA-1 
-   [Wang05], the IETF is gradually moving away from SHA-1 and towards 
-   stronger hash algorithms. 
-
-   [I-D.ietf-tls-ecc-new-mac] and [I-D.ietf-tls-rsa-aes-gcm] provide 
-   support for GCM with other key establishment methods. 
-
-1.1. 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 [RFC2119]. 
-
-2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM 
-
-   The following eight cipher suites use the new authenticated 
-   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode 
-   (GCM) [GCM]: 
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-
-   These cipher suites use authenticated encryption with additional 
-   data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in 
-   RFC 5116.  The "nonce" input to the AEAD algorithm SHALL be 12 bytes 
-   long, and is "partially implicit" (see Section 3.2.1 of RFC 5116).  
-   Part of the nonce is generated as part of the handshake process and 
-   is static for the entire session and part is carried in each packet. 
- 
- 
-Badra                 Expires September 29, 2008               [Page 3] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-                struct { 
-                   opaque salt[4]; 
-                   opaque explicit_nonce_part[8]; 
-                } GCMNonce. 
-
-   The salt value is either the client_write_IV if the client is 
-   sending or the server_write_IV if the server is sending.  These IVs 
-   SHALL be 4 bytes long.  Therefore, for all the algorithms defined in 
-   this section, SecurityParameters.fixed_iv_length=4. 
-
-   The explicit_nonce_part is chosen by the sender and included in the 
-   packet.  Each value of the explicit_nonce_part MUST be distinct from 
-   all other values, for any fixed key.  Failure to meet this 
-   uniqueness requirement can significantly degrade security.  The 
-   explicit_nonce_part is carried in the IV field of the 
-   GenericAEADCipher structure.  Therefore, for all the algorithms 
-   defined in this section, SecurityParameters.record_iv_length=8. 
-
-   In the case of TLS the counter MAY be the 64-bit sequence number.  
-   In the case of Datagram TLS [RFC4347] the counter MAY be formed from 
-   the concatenation of the 16-bit epoch with the 48-bit sequence 
-   number. 
-
-   The PRF algorithms SHALL be as follows: 
-
-   For ciphersuites ending in _SHA256 the hash function is SHA256. 
-
-   For ciphersuites ending in _SHA384 the hash function is SHA384. 
-
-3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384 
-
-   The cipher suites described in this section use AES [AES] in CBC 
-   [CBC] mode with an HMAC-based MAC. 
-
-3.1. PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
-
-   The above six cipher suites are the same as the corresponding cipher 
-   suites in RFC 4279 and RFC 4785 (TLS_PSK_WITH_AES_128_CBC_SHA, 
-   TLS_PSK_WITH_AES_256_CBC_SHA, and TLS_PSK_WITH_NULL_SHA) except for 
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 4] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-   the hash and PRF algorithms, which are SHA-256 and SHA-384 [SHS] as 
-   follows. 
-
-   Cipher Suite                             MAC             PRF 
-   ------------                             ---             --- 
-   TLS_PSK_WITH_AES_128_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_AES_128_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
-   TLS_PSK_WITH_AES_256_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_AES_256_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
-   TLS_PSK_WITH_NULL_SHA256                 HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_NULL_SHA384                 HMAC-SHA-384    P_SHA-384 
-
-3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
-
-   The above six cipher suites are the same as the corresponding cipher 
-   suites in RFC 4279 and RFC 4785 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA, 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA, and TLS_DHE_PSK_WITH_NULL_SHA) 
-   except for the hash and PRF algorithms, which are SHA-256 and SHA-
-   384 [SHS] as follows. 
-
-   Cipher Suite                             MAC             PRF 
-   ------------                             ---             --- 
-   TLS_DHE_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_DHE_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-
-3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384    = {0xXX,0xXX}; 
-
-   The above four cipher suites are the same as the corresponding 
-   cipher suites in RFC 4279 and RFC 4785 
-   (TLS_RSA_PSK_WITH_AES_128_CBC_SHA, TLS_RSA_PSK_WITH_AES_256_CBC_SHA, 
-   and TLS_RSA_PSK_WITH_NULL_SHA) except for the hash and PRF 
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows. 
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 5] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-   Cipher Suite                             MAC             PRF 
-   ------------                             ---             --- 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-   TLS_RSA_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_RSA_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-
-4. TLS Versions 
-
-   Because these cipher suites depend on features available only in TLS 
-   1.2 (PRF flexibility and combined authenticated encryption cipher 
-   modes), they MUST NOT be negotiated by older versions of TLS. 
-   Clients MUST NOT offer these cipher suites if they do not offer TLS 
-   1.2 or later.  Servers which select an earlier version of TLS MUST 
-   NOT select one of these cipher suites.  Because TLS has no way for 
-   the client to indicate that it supports TLS 1.2 but not earlier, a 
-   non-compliant server might potentially negotiate TLS 1.1 or earlier 
-   and select one of the cipher suites in this document.  Clients MUST 
-   check the TLS version and generate a fatal "illegal_parameter" alert 
-   if they detect an incorrect version. 
-
-5. Security Considerations 
-
-   The security considerations in [I-D.ietf-tls-rfc4346-bis], RFC 4279 
-   and RFC 4785 apply to this document as well.  The remainder of this 
-   section describes security considerations specific to the cipher 
-   suites described in this document. 
-
-5.1. Counter Reuse with GCM 
-
-   AES-GCM is only secure if the counter is never reused.  The IV 
-   construction algorithm above is designed to ensure that this cannot 
-   happen. 
-
-5.2. Recommendations for Multiple Encryption Processors 
-
-   If multiple cryptographic processors are in use by the sender, then 
-   the sender MUST ensure that, for a particular key, each value of the 
-   explicit_nonce_part used with that key is distinct.  In this case 
-   each encryption processor SHOULD include in the explicit_nonce_part 
-   a fixed value that is distinct for each processor.  The recommended 
-   format is 
-
-        explicit_nonce_part = FixedDistinct || Variable 
-
-   where the FixedDistinct field is distinct for each encryption 
-   processor, but is fixed for a given processor, and the Variable 
- 
- 
-Badra                 Expires September 29, 2008               [Page 6] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-   field is distinct for each distinct nonce used by a particular 
-   encryption processor.  When this method is used, the FixedDistinct 
-   fields used by the different processors MUST have the same length. 
-
-   In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common 
-   part of the nonce (it is fixed, and it is common across all 
-   encryption processors), the FixedDistinct field exactly corresponds 
-   to the Fixed-Distinct field, and the Variable field corresponds to 
-   the Counter field, and the explicit part exactly corresponds to the 
-
-   explicit_nonce_part. 
-
-   For clarity, we provide an example for TLS in which there are two 
-   distinct encryption processors, each of which uses a one-byte 
-   FixedDistinct field: 
-
-          Salt          = eedc68dc 
-          FixedDistinct = 01      (for the first encryption processor) 
-          FixedDistinct = 02      (for the second encryption processor) 
-
-   The GCMnonces generated by the first encryption processor, and their 
-   corresponding explicit_nonce_parts, are: 
-
-          GCMNonce                    explicit_nonce_part 
-          ------------------------    -------------------- 
-          eedc68dc0100000000000000    0100000000000000 
-          eedc68dc0100000000000001    0100000000000001 
-          eedc68dc0100000000000002    0100000000000002 
-          ... 
-
-   The GCMnonces generated by the second encryption processor, and 
-   their corresponding explicit_nonce_parts, are 
-
-          GCMNonce                    explicit_nonce_part 
-          ------------------------    -------------------- 
-          eedc68dc0200000000000000    0200000000000000 
-          eedc68dc0200000000000001    0200000000000001 
-          eedc68dc0200000000000002    0200000000000002 
-          ... 
-
-6. IANA Considerations 
-
-   IANA has assigned the following values for the cipher suites defined 
-   in this document: 
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
- 
- 
-Badra                 Expires September 29, 2008               [Page 7] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};    
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-
-7. Acknowledgments 
-
-   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and [I-
-   D.ietf-tls-rsa-aes-gcm]. 
-
-8. References 
-
-8.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [I-D.ietf-tls-rfc4346-bis] 
-             Dierks, T. and E. Rescorla, "The Transport Layer Security 
-             (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-
-             10, work in progress, March 2008. 
-
-   [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 
-             Encryption", RFC 5116, January 2008.  
-
-   [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005.  
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 8] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-   [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 
-             Ciphersuites with NULL Encryption for Transport Layer 
-             Security (TLS)", RFC 4785, January 2007. 
-
-   [AES]     National Institute of Standards and Technology, 
-             "Specification for the Advanced Encryption Standard 
-             (AES)", FIPS 197, November 2001. 
-
-   [SHS]     National Institute of Standards and Technology, "Secure 
-             Hash Standard", FIPS 180-2, August 2002. 
-
-   [CBC]     National Institute of Standards and Technology, 
-             "Recommendation for Block Cipher Modes of Operation - 
-             Methods and Techniques", SP 800-38A, December 2001. 
-
-   [GCM]     National Institute of Standards and Technology, 
-             "Recommendation for Block Cipher Modes of Operation: 
-             Galois;/Counter Mode (GCM) for Confidentiality and 
-             Authentication", SP 800-38D, November 2007. 
-
-8.2. Informative References 
-
-   [Wang05]  Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 
-             Full SHA-1", CRYPTO 2005, August 2005. 
-
-   [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 
-             Security", RFC 4347, April 2006. 
-
-   [I-D.ietf-tls-ecc-new-mac] 
-             Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-             256/384 and AES Galois Counter  Mode", draft-ietf-tls-ecc-
-             new-mac-04 (work in progress), February 2008. 
-
-   [I-D.ietf-tls-rsa-aes-gcm] 
-             Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES-
-             GCM Cipher Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02 
-             (work in progress), February 2008. 
-
-Author's Addresses 
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-    
-   Email: badra@isima.fr 
-    
-
- 
- 
-Badra                 Expires September 29, 2008               [Page 9] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             March 2008 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2008). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
- 
- 
-Badra                 Expires September 29, 2008              [Page 10] 
-
diff --git a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-02.txt b/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-02.txt
deleted file mode 100644
index 91d2cb8ea4..0000000000
--- a/doc/protocol/draft-badra-tls-psk-new-mac-aes-gcm-02.txt
+++ /dev/null
@@ -1,485 +0,0 @@
-TLS Working Group                                         Mohamad Badra 
-Internet Draft                                         LIMOS Laboratory 
-Intended status: Standards Track                         April 30, 2008 
-Expires: October 2008 
-                                    
- 
-                                      
-   Pre-Shared Key Cipher Suites for Transport Layer Security (TLS) with 
-                  SHA-256/384 and AES Galois Counter Mode  
-                draft-badra-tls-psk-new-mac-aes-gcm-02.txt 
-
-
-Status of this Memo                      
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on October 30, 2008. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2008). 
-
-Abstract 
-
-   RFC 4279 and RFC 4785 describe pre-shared key cipher suites for 
-   Transport Layer Security (TLS).  However, all those cipher suites 
-   use SHA-1 as their MAC algorithm.  This document describes a set of 
-   cipher suites for TLS/DTLS which uses stronger digest algorithms 
-
- 
- 
- 
-Badra                  Expires October 30, 2008                [Page 1] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-   (i.e., SHA-256 or SHA-384) and another which uses the Advanced 
-   Encryption Standard (AES) in Galois Counter Mode (GCM). 
-
-Table of Contents 
-
-    
-   1. Introduction...................................................3 
-      1.1. Conventions used in this document.........................3 
-   2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM..3 
-   3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384.........4 
-      3.1. PSK Key Exchange Algorithm with SHA-256/384...............4 
-      3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384...........5 
-      3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384...........5 
-   4. Security Considerations........................................5 
-   5. IANA Considerations............................................6 
-   6. Acknowledgments................................................6 
-   7. References.....................................................6 
-      7.1. Normative References......................................6 
-      7.2. Informative References....................................7 
-   Author's Addresses................................................8 
-   Full Copyright Statement..........................................8 
-   Intellectual Property.............................................8 
-   Acknowledgment....................................................9 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                  Expires October 30, 2008                [Page 2] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-1. Introduction 
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated 
-   encryption with additional data (AEAD) cipher modes [RFC5116]. This 
-   document describes the use of Advanced Encryption Standard (AES) 
-   [AES] in Galois Counter Mode (GCM) [GCM] (AES-GCM) with various pre-
-   shared key (PSK) key exchange mechanisms ([RFC4279] and [RFC4785]) 
-   as a cipher suite for Transport Layer Security (TLS).  
-
-   This document also specifies PSK cipher suites for TLS which replace 
-   SHA-1 by SHA-256 or SHA-384.  RFC 4279 [RFC4279] and RFC 4785 
-   [RFC4785] describe PSK cipher suites for TLS.  However, all of the 
-   RFC 4279 and the RFC 4785 cipher suites use HMAC-SHA1 as their MAC 
-   algorithm.  Due to recent analytic work on SHA-1 [Wang05], the IETF 
-   is gradually moving away from SHA-1 and towards stronger hash 
-   algorithms. 
-
-   ECC based cipher suites with SHA-256/384 and AES-GCM are defined in 
-   [I-D.ietf-tls-ecc-new-mac]; RSA, DSS and Diffie-Hellman based cipher 
-   suites are specified in [I-D.ietf-tls-rsa-aes-gcm].  The reader is 
-   expected to become familiar with these two memos prior to studying 
-   this document. 
-
-1.1. 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 [RFC2119]. 
-
-2. PSK, DHE_PSK and RSA_PSK Key Exchange Algorithms with AES-GCM 
-
-   The following eight cipher suites use the new authenticated 
-   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode 
-   (GCM) [GCM].  The cipher suites with DHE_PSK key exchange algorithm 
-   (TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 and 
-   TLS_DHE_PSK_WITH_AES_128_GCM_SHA348) provide Perfect Forward Secrecy 
-   (PFS). 
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-
- 
- 
-Badra                  Expires October 30, 2008                [Page 3] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-   These cipher suites use authenticated encryption with additional 
-   data (AEAD) algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM 
-   described in RFC 5116.  GCM is used as described in [I-D.ietf-tls-
-   rsa-aes-gcm]. 
-
-   The PSK, DHE_PSK and RSA_PSK key exchanges are performed as defined 
-   in [RFC4279]. 
-
-   The PRF algorithms SHALL be as follows: 
-
-       For cipher suites ending with _SHA256, the PRF is the TLS PRF  
-       [I-D.ietf-tls-rfc4346-bis] with SHA-256 as the hash function. 
-
-       For cipher suites ending with _SHA384, the PRF is the TLS PRF  
-       [I-D.ietf-tls-rfc4346-bis] with SHA-384 as the hash function. 
-
-   Implementations MUST send TLS Alert bad_record_mac for all types of 
-   failures encountered in processing the AES-GCM algorithm. 
-
-3. PSK, DHE_PSK and RSA_PSK Key Exchange with SHA-256/384 
-
-   The cipher suites described in this section use AES [AES] in CBC 
-   [CBC] mode with an HMAC-based MAC. 
-
-3.1. PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
-
-   The above six cipher suites are the same as the corresponding cipher 
-   suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" in 
-   place of "_SHA256" or "_SHA384"), except for the hash and PRF 
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows. 
-
-   CipherSuite                              MAC             PRF 
-   ------------                             ---             --- 
-   TLS_PSK_WITH_AES_128_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_AES_128_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
-   TLS_PSK_WITH_AES_256_CBC_SHA256          HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_AES_256_CBC_SHA384          HMAC-SHA-384    P_SHA-384 
-   TLS_PSK_WITH_NULL_SHA256                 HMAC-SHA-256    P_SHA-256 
-   TLS_PSK_WITH_NULL_SHA384                 HMAC-SHA-384    P_SHA-384 
-
- 
- 
-Badra                  Expires October 30, 2008                [Page 4] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-3.2. DHE_PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
-
-   The above six cipher suites are the same as the corresponding cipher 
-   suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" in 
-   place of "_SHA256" or "_SHA384"), except for the hash and PRF 
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows. 
-
-   CipherSuite                              MAC             PRF 
-   ------------                             ---             --- 
-   TLS_DHE_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_DHE_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_DHE_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-
-3.3. RSA_PSK Key Exchange Algorithm with SHA-256/384 
-
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256    = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384    = {0xXX,0xXX}; 
-
-   The above four cipher suites are the same as the corresponding 
-   cipher suites in RFC 4279 and RFC 4785 (with names ending in "_SHA" 
-   in place of "_SHA256" or "_SHA384"), except for the hash and PRF 
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows. 
-
-   CipherSuite                              MAC             PRF 
-   ------------                             ---             --- 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-   TLS_RSA_PSK_WITH_AES_256_CBC_SHA256      HMAC-SHA-256    P_SHA-256 
-   TLS_RSA_PSK_WITH_AES_256_CBC_SHA384      HMAC-SHA-384    P_SHA-384 
-
-4. Security Considerations 
-
-   The security considerations in RFC 4279, RFC 4758, and [I-D.ietf-
-   tls-rsa-aes-gcm] apply to this document as well.  In addition, as 
-   described in [I-D.ietf-tls-rsa-aes-gcm], these cipher suites may 
-   only be used with TLS 1.2 or greater. 
-
- 
- 
-Badra                  Expires October 30, 2008                [Page 5] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-5. IANA Considerations 
-
-   IANA has assigned the following values for the cipher suites defined 
-   in this document: 
-
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_258_GCM_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_GCM_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_GCM_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_GCM_SHA384  = {0xXX,0xXX};    
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA256      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384      = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA256             = {0xXX,0xXX}; 
-      CipherSuite TLS_PSK_WITH_NULL_SHA384             = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX};   
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA256         = {0xXX,0xXX};     
-      CipherSuite TLS_DHE_PSK_WITH_NULL_SHA384         = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA384  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA256  = {0xXX,0xXX}; 
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA384  = {0xXX,0xXX}; 
-
-6. Acknowledgments 
-
-   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and [I-
-   D.ietf-tls-rsa-aes-gcm]. 
-
-7. References 
-
-7.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [I-D.ietf-tls-rfc4346-bis] 
-             Dierks, T. and E. Rescorla, "The Transport Layer Security 
-             (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-
-             10, work in progress, March 2008. 
-
- 
- 
-Badra                  Expires October 30, 2008                [Page 6] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-   [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 
-             Encryption", RFC 5116, January 2008.  
-
-   [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005.  
-
-   [RFC4785] Blumenthal, U., Goel, P., "Pre-Shared Key (PSK) 
-             Ciphersuites with NULL Encryption for Transport Layer 
-             Security (TLS)", RFC 4785, January 2007. 
-
-   [AES]     National Institute of Standards and Technology, 
-             "Specification for the Advanced Encryption Standard 
-             (AES)", FIPS 197, November 2001. 
-
-   [SHS]     National Institute of Standards and Technology, "Secure 
-             Hash Standard", FIPS 180-2, August 2002. 
-
-   [CBC]     National Institute of Standards and Technology, 
-             "Recommendation for Block Cipher Modes of Operation - 
-             Methods and Techniques", SP 800-38A, December 2001. 
-
-   [GCM]     National Institute of Standards and Technology, 
-             "Recommendation for Block Cipher Modes of Operation: 
-             Galois;/Counter Mode (GCM) for Confidentiality and 
-             Authentication", SP 800-38D, November 2007. 
-
-7.2. Informative References 
-
-   [Wang05]  Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 
-             Full SHA-1", CRYPTO 2005, August 2005. 
-
-   [I-D.ietf-tls-ecc-new-mac] 
-             Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-             256/384 and AES Galois Counter  Mode", draft-ietf-tls-ecc-
-             new-mac-06 (work in progress), April 2008. 
-
-   [I-D.ietf-tls-rsa-aes-gcm] 
-             Salowey, J., A. Choudhury, and C. McGrew, "RSA based AES-
-             GCM Cipher Suites for TLS", draft-ietf-tls-rsa-aes-gcm-03 
-             (work in progress), April 2008. 
-
-
-
-
-
-
- 
- 
-Badra                  Expires October 30, 2008                [Page 7] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-Author's Addresses 
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-    
-   Email: badra@isima.fr 
-    
-
-Full Copyright Statement 
-
-   Copyright (C) The IETF Trust (2008). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-
-Intellectual Property 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
- 
- 
-Badra                  Expires October 30, 2008                [Page 8] 
-
-Internet-Draft       TLS PSK New MAC and AES-GCM             April 2008 
-    
-
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is provided by the IETF 
-   Administrative Support Activity (IASA). 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                  Expires October 30, 2008                [Page 9] 
-
diff --git a/doc/protocol/draft-benaloh-pct-00.txt b/doc/protocol/draft-benaloh-pct-00.txt
deleted file mode 100644
index 9d6dd35110..0000000000
--- a/doc/protocol/draft-benaloh-pct-00.txt
+++ /dev/null
@@ -1,1684 +0,0 @@
-Internet Draft					    Josh Benaloh
-						    Butler Lampson
-						    Daniel Simon
-						    Terence Spies
-						    Bennet Yee
-						    Microsoft Corp.
-						    October 1995
-
-	    The Private Communication Technology Protocol
-		     <draft-benaloh-pct-00.txt>
-
-1. Status of this Memo
-
-This document is an Internet-Draft.  Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas,
-and its working groups. Note that other groups may also distribute
-working documents as Internet-Drafts.
-
-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".
-
-To learn the current status of any Internet-Draft, please check the
-"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-Directories on ds.internic.net (US East Coast), nic.nordu.net
-(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-This Internet-Draft expires 27 March 1996.
-
-
-2. Abstract
-
-This document specifies Version 1 of the Private Communication
-Technology (PCT) protocol, a security protocol that provides privacy
-over the Internet.  Like SSL (see [1]), the protocol is intended to
-prevent eavesdropping on communications in client/server applications,
-with servers always being authenticated and clients being
-authenticated at the server's option.  However, this protocol corrects
-or improves on several weaknesses of SSL.
-
-
-3. Introduction
-
-The Private Communication Technology (PCT) Protocol is designed to
-provide privacy between two communicating applications (a client and a
-server), and to authenticate the server and (optionally) the client.
-PCT assumes a reliable transport protocol (e.g. TCP) for data
-transmission and reception.
-
-The PCT Protocol is application protocol-independent.  A "higher
-level" application protocol (e.g. HTTP, FTP, TELNET, etc.) can layer
-on top of the PCT Protocol transparently.  The PCT Protocol begins
-with a handshake phase that negotiates an encryption algorithm and
-(symmetric) session key as well as authenticating a server to the
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 1]
-Internet Draft              The PCT Protocol               November 1995
-
-
-client (and, optionally, vice versa), based on certified asymmetric
-public keys. Once transmission of application protocol data begins,
-all data is encrypted using the session key negotiated during the
-handshake.
-
-It should be noted that the PCT protocol does not specify any details
-about verification of certificates with respect to certification
-authorities, revocation lists, and so on.  Rather, it is assumed that
-protocol implementations have access to a "black box" which is capable
-of ruling on the validity of received certificates in a manner
-satisfactory to the implementation's user.  Such a ruling may, for
-instance, involve remote consultation with a trusted service, or even
-with the actual user through a text or graphic interface.
-
-In addition to encryption and authentication, the PCT protocol
-verifies the integrity of messages using a hash function-based message
-authentication code (MAC).
-
-The PCT protocol's record format is compatible with that of SSL (see
-[1]).  Servers implementing both protocols can distinguish between PCT
-and SSL clients because the version number field occurs in the same
-position in the first handshake message in both protocols.  In PCT,
-the most significant bit of the protocol version number is set to one.
-
-The PCT protocol differs from SSL chiefly in the design of its
-handshake phase, which differs from SSL's in a number of respects:
-
-- The round and message structures are considerably shorter and
-  simpler: a reconnected session without client authentication
-  requires only one message in each direction, and no other type of
-  connection requires more than two messages in each direction.
-
-- Negotiation for the choice of cryptographic algorithms and formats
-  to use in a session has been extended to cover more protocol
-  characteristics and to allow different characteristics to be
-  negotiated independently.  The PCT client and server negotiate, in
-  addition to a cipher type and server certificate type, a hash
-  function type and a key exchange type.  If client authentication is
-  requested, a client certificate type and signature type are also 
-  negotiated.
-
-- Message authentication has been revamped so that it now uses
-  different keys from the encryption keys.  Thus, message
-  authentication keys may be much longer (and message authentication
-  therefore much more secure) than the encryption keys, which may be
-  weak or even non-existent.  
-
-- A security hole in SSL's client authentication has been repaired;
-  the PCT client's authentication challenge response now depends on
-  the type of cipher negotiated for the session.  SSL's client
-  authentication is independent of the cipher strength used in the
-  session and also of whether the authentication is being performed
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 2]
-Internet Draft              The PCT Protocol               November 1995
-
-
-  for a reconnection of an old session or for a new one.  As a result,
-  a "man-in-the-middle" attacker who has obtained the session key for
-  a session using weak cryptography can use this broken session to
-  authenticate as the client in a session using strong cryptography.
-  If, for example, the server normally restricts certain sensitive
-  functions to high-security sessions, then this security hole allows 
-  intruders to circumvent the restriction.
-
-- A "verify-prelude" field has been added to the handshake phase,
-  with which the client and server can check that the cipher type
-  (and other) negotiations carried out in the clear have not been
-  tampered with.  (SSL version 3 uses a similar mechanism, but its
-  complete version 2 compatibility negates its security function,
-  by allowing adversaries simply to alter version numbers as well
-  as cipher types.)
-
-
-
-4. PCT Record Protocol Specification
-
-4.1 PCT Record Header Format
-
-For compatibility with SSL, the PCT protocol uses the same basic
-record format as SSL.  In PCT, all data sent is encapsulated in a
-record, an object which is composed of a header and some non-zero
-amount of data.  Each record header contains a two- or three-byte
-length code.  If the most significant bit is set in the first byte of
-the record length code then the record has no padding and the total
-header length is two bytes; otherwise the record has padding and the
-total header length is three bytes. The record header is transmitted
-before the data portion of the record.
-
-Note that in the long header case (three bytes total), the second most
-significant bit in the first byte has special meaning.  When zero, the
-record being sent is a data record.  When one, the record being sent
-is a security escape, and the first byte of the record is an
-ESCAPE_TYPE_CODE that indicates the type of escape.  (Currently, the
-two examples of security escapes are the "out-of-band data" escape and
-the "redo handshake" escape.)  In either case, the length code
-describes how much data is in the record as transmitted; this may be
-greater than the amount of data after decryption, particularly if
-padding was used.
-
-The record length code does not include the number of bytes consumed
-by the record header (two or three). For the two-byte header, the
-record length is computed by (using a "C"-like notation):
-
-RECORD_LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1],
-
-where byte[0] represents the first byte received and byte[1] the
-second byte received. When the three-byte header is used, the record
-length is computed as follows (using a "C"-like notation):
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 3]
-Internet Draft              The PCT Protocol               November 1995
-
-
-RECORD_LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
-IS_ESCAPE = (byte[0] & 0x40) != 0;
-PADDING_LENGTH = byte[2];
-
-The record header defines a value called PADDING_LENGTH. The
-PADDING_LENGTH value specifies how many bytes of data were appended
-to the original record by the sender. The padding data is used to
-make the record length a multiple of the block cipher's block size
-when a block cipher is used for encryption.
-
-The sender of a "padded" record appends the padding data to the end of
-its normal data and then encrypts the total amount (which is now a
-multiple of the block cipher's block size).  The actual value of the
-padding data is unimportant, but the encrypted form of it must be
-transmitted for the receiver to decrypt the record properly.  Once the
-total amount being transmitted is known the header can be properly
-constructed with the PADDING value set appropriately.
-
-The receiver of a padded record uses the PADDING_LENGTH value from the
-header when determining the length of the ACTUAL_DATA in the data
-record (see section 4.2).
-
-
-4.2 PCT Record Data Format
-
-The format of the data portion of an encrypted PCT record is slightly
-different from that of SSL.  However, not only is the record header
-format identical in both protocols, but the first handshake message
-sent in each direction is also sent in the clear, and contains a
-version number field in the same location in both protocols.  (In PCT
-protocol handshake messages, the most significant bit of this field is
-1.)  Hence, PCT is still compatible with SSL, in the sense that PCT
-handshake messages can be recognized and distinguished from SSL
-handshake messages by examination of the version number.
-
-The PCT record is composed of two fields (transmitted and received in
-the order shown):
-
-ENCRYPTED_DATA[N+PADDING_LENGTH]
-MAC_DATA[MAC_LENGTH]
-
-The ENCRYPTED_DATA field contains an encryption of the concatenation
-of ACTUAL_DATA (the N bytes of actual data being transmitted) and
-PADDING_DATA (the use of which is explained below).  The MAC_DATA
-field contains the "Message Authentication Code" (MAC).
-
-PCT handshake records are sent in the clear, and no MAC is used.
-Consequently PADDING_LENGTH will be zero and MAC_LENGTH will be zero.
-For non-handshake data records, the sender appends a PADDING_DATA
-field containing arbitrary data, so that N + PADDING_LENGTH is the
-appropriate length for the cipher being used to encrypt the data.  (In
-the case where a block cipher is used, PADDING_LENGTH must be the
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 4]
-Internet Draft              The PCT Protocol               November 1995
-
-
-minimum value such that the length of the concatenation of ACTUAL_DATA
-and PADDING_DATA is an exact multiple of the cipher's block size.
-Otherwise, PADDING_LENGTH is zero.)
-
-MAC_DATA is computed as follows:
-
-MAC_DATA := Hash( MAC_KEY, Hash( ACTUAL_DATA, PADDING_DATA, 
-SEQUENCE_NUMBER ) )
-
-If the client is sending the record, then the MAC_KEY is the
-CLIENT_MAC_KEY; if the server is sending the record, then the MAC_KEY
-is the SERVER_MAC_KEY.  (The details of the derivation of these keys
-are given in section 5.3.1.)  The selection of the hash function used
-to compute MAC_DATA is discussed in sections 5.2.1 and 5.2.2.  The
-parameters of the inner invocation of the hash function are input into
-the hash function in the order shown above, with SEQUENCE_NUMBER
-represented in network byte order or "big endian" order.  If the
-length of MAC_KEY is not an exact multiple of eight bits, then MAC_KEY
-is considered, for the purposes of MAC computation, to have (fewer
-than eight) zero bits appended to it, to create a string of an
-integral number of bytes for input into the MAC hash function.
-
-The SEQUENCE_NUMBER is a counter which is incremented by both the
-sender and the receiver. For each transmission direction, a pair of
-counters is kept (one by the sender, one by the receiver).  Before the
-first (handshake) record is sent or received in a PCT connection all
-sequence numbers are initialized to zero (except in the case of a
-restarting connection with a token-based exchange type, in which case
-the entire cipher state is preserved; see section 5.2.2).  The
-sender's sender-to-receiver sequence number is incremented after every
-record sent, and the receiver's sender-to-receiver sequence number is
-incremented after every record received.  Sequence numbers are 32-bit
-unsigned quantities, and may not increment past 0xFFFFFFFF.  (See
-section 4.3.2.)
-
-The receiver of a record (whether PCT client or server) first uses the
-sender's WRITE_KEY to decrypt the concatenated ACTUAL_DATA and
-PADDING_DATA fields, then uses the sender's MAC_KEY, the ACTUAL_DATA,
-the PADDING_DATA, and the expected value of the sequence number as
-input into the MAC_DATA function described above (the hash function
-algorithm used is determined the same way for the receiver as for the
-sender).  The computed MAC_DATA must agree bit for bit with the
-transmitted MAC_DATA.  If the two are not identical, then an
-INTEGRITY_CHECK_FAILED error occurs, and it is recommended that the
-record be treated as though it contained no data.  (See section 5.4.)
-The same error occurs if N + PADDING_LENGTH is not correct for the
-block cipher used.
-
-The PCT Record Layer is used for all PCT communications, including
-handshake messages, security escapes and application data transfers.
-The PCT Record Layer is used by both the client and the server at all
-times.
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 5]
-Internet Draft              The PCT Protocol               November 1995
-
-
-For a two-byte header, the maximum record length is 32767 bytes.  For
-a three-byte header, the maximum record length is 16383 bytes.  The
-PCT Handshake Protocol messages are constrained to fit in a single PCT
-Record Protocol record.  Application protocol messages are allowed to
-consume multiple PCT Record Protocol records.
-
-
-4.3 Security Escapes
-
-4.3.1 Out-Of-Band Data
-
-PCT, like SSL, supports the transmission and reception of "out-of-band
-data".  Out of band data is normally defined at the TCP/IP protocol
-level, but because of PCT's privacy enhancements and support for block
-ciphers, this becomes difficult to support.
-
-To send out-of-band data, the sender sends an escape record whose body
-contains a single byte of data which is the ESCAPE_TYPE_CODE value
-PCT_ET_OOB_DATA.  The record following the escape record will be
-interpreted as "out-of-band" data and will only be made available to
-the receiver through an unspecified mechanism that is different from
-the receiver's normal data reception method.  The escape record and
-the transmitted data record are transmitted normally (i.e. encryption,
-MAC computations, and block cipher padding remain in effect).
-
-Note that the escape record and the associated data record are sent
-using normal TCP sending mechanisms, not using the "out of band"
-mechanisms.  Note also that a "Redo Handshake" escape record (see
-below) and its associated handshake messages may be interposed between
-an "Out-of-Band Data" escape record and its associated data record.
-In such a case, the first non-escape, non-handshake record following
-the "Out-of-Band Data" escape record is treated as out-of-band data.
-
-4.3.2  Redo Handshake
-
-PCT allows either the client or the server to request, at any time
-after the handshake phase has been completed for a connection, that
-another handshake phase be performed for that connection.  For
-example, either party is required to request another handshake phase
-rather than allow its sequence number to "wrap" beyond 0xFFFFFFFF.  In
-addition, it is recommended that implementations enforce limits on the
-duration of both connections and sessions, with respect to the total
-number of bytes sent, the number of records sent, the actual time
-elapsed since the beginning of the connection or session, and, in the
-case of sessions, the number of reconnections made.  These limits
-serve to ensure that keys are not used more or longer than it is safe
-to do so; hence the limits may depend on the type and strength of
-cipher, key exchange and authentication used, and may, at the
-implementer's discretion, include indications from the application as
-to the sensitivity of the data being transmitted or received.
-
-To request a new handshake phase for this connection, the sender
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 6]
-Internet Draft              The PCT Protocol               November 1995
-
-
-(client or server) sends an escape record whose body contains a single
-byte of data which is the ESCAPE_TYPE_CODE value PCT_ET_REDO_CONN.
-The escape record is transmitted normally (i.e.  encryption, MAC
-computations, and block cipher padding remain in effect).
-
-There are several cases to consider to ensure that the message
-pipeline gets flushed and to enable handshake messages to be
-distinguished from data records.  The following rules ensure that the
-first messages in the redone handshake are always immediately preceded
-by a "Redo Handshake" escape message.
-
-If the client initiates the "Redo Handshake", it sends the "Redo
-Handshake" escape message immediately followed by a normal
-CLIENT_HELLO message; the server, on receiving the "Redo Handshake"
-escape message, may be in one of two states.  If the last message it
-sent was a "Redo Handshake" escape message, then it simply waits for
-the CLIENT_HELLO message; otherwise, it sends a "Redo Handshake"
-escape message in response, and then waits for the CLIENT_HELLO
-message.
-
-If the server initiates the "Redo Handshake", then the server sends
-the "Redo Handshake" escape message and simply waits for a "Redo
-Handshake" escape message in response; this "Redo Handshake" should be
-immediately followed by a normal CLIENT_HELLO message.  The client, on
-receiving the server's "Redo Handshake" escape message, may be in one
-of two states.  If the last two messages it sent were a "Redo 
-Handshake" escape message followed by a CLIENT_HELLO message, then it
-simply waits for a SERVER_HELLO message; otherwise, it sends a "Redo
-Handshake" escape message in response, followed by a CLIENT_HELLO
-message, and then waits for a SERVER_HELLO message.
-
-In all cases, the sender of the "Redo Handshake" escape message
-continues to process incoming messages, but may not send any
-non-handshake messages until the new handshake completes.
-
-The handshake phase that follows the "Redo Handshake" escape message 
-is a normal one in most respects; the client may request the 
-reconnection of an old session or request that a new session be 
-initiated, and the server, on receiving a reconnection request, can 
-accept the reconnection or demand that a new session be initiated 
-instead.  If a new session is being established, then the server must 
-request client authentication if and only if client authentication 
-was requested during the previous session.  Otherwise, client 
-authentication is optional.  Both parties must verify that the 
-specifications negotiated previously in the session (cipher type, key 
-exchange type, certificate type, hash function type, client 
-certificate type, and signature type), as well as any certificates 
-exchanged, are identical to those found in the new handshake phase.  
-A mismatch results in a SPECS_MISMATCH or BAD_CERTIFICATE error (see 
-section 5.4.)  This ensures that the security properties of the 
-communication channel do not change.
-
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 7]
-Internet Draft              The PCT Protocol               November 1995
-
-
-5. PCT Handshake Protocol Specification
-
-5.1 PCT Handshake Protocol Flow
-
-The PCT Handshake Protocol is used to negotiate security enhancements
-to data sent using the PCT Record Protocol.  The security enhancements
-consist of authentication, symmetric encryption, and message
-integrity.  Symmetric encryption is facilitated using a "Key Exchange
-Algorithm".  PCT version 1 supports RSA {TM} -based key exchange (see
-[13]), Diffie-Hellman key exchange, and FORTEZZA token key exchange.
-
-The PCT Handshake Protocol consists of four messages, sent
-respectively by the client, then server, then client, then server, in
-that order.  (Moreover, under certain circumstances, the last two
-messages are omitted.)  The messages are named, in order,
-CLIENT_HELLO, SERVER_HELLO, CLIENT_MASTER_KEY, and SERVER_VERIFY.
-
-The general contents of the messages depend upon two criteria: whether
-the connection being made is a reconnection (a continuation of a
-previous session) or a new session and whether the client is to be
-authenticated.  (The server is always authenticated.)  The first
-criterion is determined by the client and server together; the
-CLIENT_HELLO will have different contents depending on whether a new
-session is being initiated or an old one continued, and the
-SERVER_HELLO message will either confirm a requested continuation of
-an old session, or require that a new session be initiated.  The
-second criterion is determined by the server, whose SERVER_HELLO may
-contain a demand for authentication of the client.  If the server does
-not require client authentication, and the reconnection of an old
-session is requested by the client and accepted by the server, then
-the CLIENT_MASTER_KEY and SERVER_VERIFY messages are unnecessary, and
-are omitted.
-
-The CLIENT_HELLO message contains a random authentication challenge
-to the server and a request for the type and level of cryptography
-and certification to be used for the session.  If the client is
-attempting to continue an old session, then it also supplies that
-session's ID.
-
-In the case of a new session, the SERVER_HELLO message contains a
-certificate and a random connection identifier; this identifier
-doubles as an authentication challenge to the client if the server
-desires client authentication.  The CLIENT_MASTER_KEY message sent by
-the client in response includes the master key for the session (from
-which session keys are derived), encrypted using the public key from
-the server's certificate, as well as a certificate and response to the
-server's authentication challenge, if requested.  To ensure that
-previous unencrypted handshake messages were not tampered with, their
-keyed hash is included with the CLIENT_MASTER_KEY message.  Finally,
-the server sends a SERVER_VERIFY message which includes a response to
-the client's challenge and a random session id for the session.
-
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 8]
-Internet Draft              The PCT Protocol               November 1995
-
-
-If the server accepts the old session id, then the SERVER_HELLO
-message contains a response to the client's challenge, and a random
-connection identifier which again doubles as a random challenge to the
-client, if the server requires client authentication.  If no client
-authentication is requested, the handshake is finished (although an
-authentication of the client is implicit in the MAC included with the
-client's first data message).  Otherwise, the subsequent
-CLIENT_MASTER_KEY message contains the client's response, and the
-SERVER_VERIFY message simply signals to the client to continue.
-
-For a new session, the handshake phase has the following form (items
-in square brackets are included only if client authentication is
-required):
-
-Client					Server
-------					------
-
-CLIENT_HELLO:
-client challenge;
-client's cipher, hash,
-    server-certificate,
-    and key-exchange 
-    specification lists
-
-					SERVER_HELLO:
-					connection id/server challenge;
-					server's cipher, hash,
-					    server-certificate,
-					    and key-exchange
-					    specification choices;
-					server certificate
-					[; server's signature-type
-					    and client-certificate
-					    specification lists]
-
-CLIENT_MASTER_KEY:
-master key, encrypted with
-    server's public key;
-authentication of previous two
-    messages
-[; client's signature-type and
-    client-certificate
-    specification choices;
-client's certificate;
-client's challenge response]
-
-					SERVER_VERIFY:
-					session id;
-					server's challenge response
-
-
-For a reconnection of an old session, the handshake phase has the
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                 [Page 9]
-Internet Draft              The PCT Protocol               November 1995
-
-
-following form (items in square brackets are included if client
-authentication is required):
-
-Client					Server
-------					------
-
-CLIENT_HELLO:
-client challenge;
-session id;
-client's cipher, hash,
-    server-certificate,
-    and key-exchange 
-    specification lists
-
-					SERVER_HELLO:
-					connection id/server challenge;
-					old session's cipher, hash,
-					    server-certificate,
-					    and key-exchange
-					    specification choices;
-					server's challenge response
-					[; server's signature-type
-					    and client-certificate
-					    specification lists]
-
-[CLIENT_MASTER_KEY:
-client's certificate;
-client's challenge response]
-
-
-					[SERVER_VERIFY]
-
-
-Note that the protocol is asymmetric between client and server.  The
-client authenticates the server because only the server can decrypt
-the master key which is encrypted with the server's public key, and
-the server's challenge response depends on knowing that master key.
-The server authenticates the client because the client signs its
-challenge response with its public key.  The reason for the asymmetry
-is that when there is no client authentication there is no client
-public key, so the client must choose the master key and encrypt it
-with the server public key to hide it from everyone except the server.
-
-Usually the client can safely send data on the underlying transport
-immediately following the CLIENT_MASTER_KEY message, without waiting
-for the SERVER_VERIFY; we call this "initial data".  Sending initial
-data is good because it means that PCT adds only one round trip; it is
-not possible to do better without exposing the server to a replay
-attack.  However, it is unwise to send initial data if for some reason
-it is important for the client to be sure of being in contact with the
-correct server before sending any data.
-
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 10]
-Internet Draft              The PCT Protocol               November 1995
-
-
-5.2 PCT Handshake Protocol Messages
-
-The PCT Handshake Protocol messages are sent using the PCT Record
-Protocol and consist of a single byte message type code, followed by
-some data.  The client and server exchange messages as described
-above, sending either one or two messages each.  Once the handshake
-has been completed successfully, the client sends its first actual
-data.
-
-Handshake protocol messages are sent in the clear, with the exception
-of the key-exchange-related fields in the CLIENT_MASTER_KEY message,
-some of which involve (public-key) encryption.
-
-The following notation is used for PCT messages:
-
-char MSG_EXAMPLE
-char FIELD1
-char FIELD2
-char THING_LENGTH_MSB
-char THING_LENGTH_LSB
-char THING_DATA[(MSB << 8)|LSB];
-...
-
-This notation defines the data in the protocol message, including the
-message type code. The order is presented top to bottom, with the
-topmost element being transmitted first.
-
-For the "THING_DATA" entry, the MSB and LSB values are actually
-THING_LENGTH_MSB and THING_LENGTH_LSB (respectively) and define the
-number of bytes of data actually present in the message. For example,
-if THING_LENGTH_MSB were one and THING_LENGTH_LSB were four then the
-THING_DATA array would be exactly 260 bytes long.  This shorthand is
-used below.  Occasionally, a "THING_DATA" field is referred to as
-"THING", with the word "DATA" omitted.
-
-The names of message elements have prefixes that identify the messages
-in which they appear; these prefixes are sometimes omitted in the text
-when the containing messages are obvious.
-
-Length codes are unsigned values, and when the MSB and LSB are
-combined the result is an unsigned value.  Length values are in bytes.
-
-
-5.2.1 CLIENT_HELLO (Sent in the clear)
-
-char CH_MSG_CLIENT_HELLO
-char CH_CLIENT_VERSION_MSB
-char CH_CLIENT_VERSION_LSB
-char CH_PAD
-char CH_SESSION_ID_DATA[32]
-char CH_CHALLENGE_DATA[32]
-char CH_OFFSET_MSB
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 11]
-Internet Draft              The PCT Protocol               November 1995
-
-
-char CH_OFFSET_LSB
-char CH_CIPHER_SPECS_LENGTH_MSB
-char CH_CIPHER_SPECS_LENGTH_LSB
-char CH_HASH_SPECS_LENGTH_MSB
-char CH_HASH_SPECS_LENGTH_LSB
-char CH_CERT_SPECS_LENGTH_MSB
-char CH_CERT_SPECS_LENGTH_LSB
-char CH_EXCH_SPECS_LENGTH_MSB
-char CH_EXCH_SPECS_LENGTH_LSB
-char CH_KEY_ARG_LENGTH_MSB
-char CH_KEY_ARG_LENGTH_LSB
-char CH_CIPHER_SPECS_DATA[(MSB << 8)|LSB]
-char CH_HASH_SPECS_DATA[(MSB << 8)|LSB]
-char CH_CERT_SPECS_DATA[(MSB << 8)|LSB]
-char CH_EXCH_SPECS_DATA[(MSB << 8)|LSB]
-char CH_KEY_ARG_DATA[(MSB << 8)|LSB]
-
-When a client first connects to a server it is required to send the
-CLIENT_HELLO message.  The server is expecting this message from the
-client as its first message. It is an ILLEGAL_MESSAGE error for a
-client to send anything else as its first message.  The CLIENT_HELLO
-message begins with the PCT version number, and two fixed-length
-fields followed by an offset to the variable length data.  The
-CH_OFFSET field contains the number of bytes used by the various
-fields (currently only length fields) that follow the offset field and
-precede the variable-length fields.  For PCT version 1, this offset
-value is always PCT_CH_OFFSET_V1, i.e., ten.  However, inclusion of
-this field will allow future versions to be compatible with version 1,
-even if the number of these fields changes: a version 1 server should
-be able to find all the PCT version 1 fields in a higher-version
-CLIENT_HELLO message.  The CH_PAD field may contain any value.
-
-The CLIENT_HELLO message includes a string of random bytes used as
-challenge data from the client.  Also, if the client finds a session
-identifier in its cache for the server, then that session-identifier
-data is sent.  Otherwise, the special PCT_SESSION_ID_NONE value is
-used.  In either case, the client specifies in CIPHER_SPECS_DATA,
-HASH_SPECS_DATA, CERT_SPECS_DATA, and EXCH_SPECS_DATA its preferred
-choices of symmetric cipher, key lengths, hash function, certificate,
-and asymmetric key exchange algorithm.  However, if a session
-identifier is sent, then these choices are only relevant in the case
-where the server cannot recognize the session identifier, and a new
-session must therefore be initiated.  If the server recognizes the
-session, then these fields are ignored by the server.
-
-The CHALLENGE_DATA field contains 32 bytes of random bits, to be used
-to authenticate the server.  The CHALLENGE_DATA should be
-cryptographically random, in the same sense as the MASTER_KEY (see
-section 5.3.1).
-
-The CIPHER_SPECS_DATA field contains a list of possible symmetric
-ciphers supported by the client, in order of (the client's)
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 12]
-Internet Draft              The PCT Protocol               November 1995
-
-
-preference.  Each element in the list is a four-byte field, of which
-the first two bytes contain a code representing a cipher type, the
-third byte contains the encryption key length in bits (0-255), and the
-fourth byte contains the MAC key length in bits, minus 64 (values
-0-255, representing lengths 64-319; this encoding enforces the
-requirement that the MAC key length be at least 64 bits).  The entire
-list's length in bytes (four times the number of elements) is placed
-in CIPHER_SPECS_LENGTH.
-
-The HASH_SPECS_DATA field contains a list of possible hash functions
-supported by the client, in order of (the client's) preference.  The
-server will choose one of these to be used for computing MACs and
-deriving keys.  Each element in the list is a two-byte field
-containing a code representing a hash function choice.  The entire
-length of the list (twice the number of elements) is placed in
-HASH_SPECS_LENGTH.
-
-The CERT_SPECS_DATA field contains a list of possible certificate
-formats supported by the client, in order of (the client's)
-preference.  Each element in the list is a two-byte field containing a
-code representing a certificate format.  The entire length of the list
-(twice the number of elements) is placed in CERT_SPECS_LENGTH.
-
-The EXCH_SPECS_DATA field contains a list of possible asymmetric key
-exchange algorithms supported by the client, in order of (the
-client's) preference.  Each element in the list is a two-byte field
-containing a code representing a key exchange algorithm type.  The
-entire length of the list (twice the number of elements) is placed in
-EXCH_SPECS_LENGTH.
-
-The KEY_ARG_DATA field contains an initialization vector to be used in
-a reconnected session when the cipher type is a block cipher (any
-cipher type except PCT_CIPHER_RC4, and any key exchange type except
-PCT_EXCH_RSA_PKCS1_TOKEN_RC4).  If a new session is being requested
-(i.e., the value of CH_SESSION_ID_DATA is PCT_SESSION_ID_NONE), then
-KEY_ARG_LENGTH must be zero.
-
-The CLIENT_HELLO message must be the first message sent by the client
-to the server.  After the message is sent the client waits for a
-SERVER_HELLO message.  Any other message returned by the server (other
-than ERROR) generates the PCT_ERR_ILLEGAL_MESSAGE error.
-
-The server, on receiving a CLIENT_HELLO message, checks the version
-number and the offset field to determine where the variable-length
-data fields start.  (The OFFSET value should be at least
-PCT_CH_OFFSET_V1.)  The server then checks whether there is a non-null
-SESSION_ID field, and if so, whether it recognizes the SESSION_ID.  In
-that case, the server responds with a SERVER_HELLO message containing
-a non-zero RESTART_SESSION_OK field, and the appropriate value (see
-below) in the RESPONSE and CONNECTION_ID fields.  Otherwise, it checks
-whether the CIPHER_SPECS, HASH_SPECS, CERT_SPECS and EXCH_SPECS lists
-in the CLIENT_HELLO message each contain at least one type supported
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 13]
-Internet Draft              The PCT Protocol               November 1995
-
-
-by the server.  If so, then the server sends a SERVER_HELLO message to
-the client as described below; otherwise, the server detects a
-SPECS_MISMATCH error.
-
-5.2.2 SERVER_HELLO (Sent in the clear)
-
-char SH_MSG_SERVER_HELLO
-char SH_PAD
-char SH_SERVER_VERSION_MSB
-char SH_SERVER_VERSION_LSB
-char SH_RESTART_SESSION_OK
-char SH_CLIENT_AUTH_REQ
-char SH_CIPHER_SPECS_DATA[4]
-char SH_HASH_SPECS_DATA[2]
-char SH_CERT_SPECS_DATA[2]
-char SH_EXCH_SPECS_DATA[2]
-char SH_CONNECTION_ID_DATA[32]
-char SH_CERTIFICATE_LENGTH_MSB
-char SH_CERTIFICATE_LENGTH_LSB
-char SH_CLIENT_CERT_SPECS_LENGTH_MSB
-char SH_CLIENT_CERT_SPECS_LENGTH_LSB
-char SH_CLIENT_SIG_SPECS_LENGTH_MSB
-char SH_CLIENT_SIG_SPECS_LENGTH_LSB
-char SH_RESPONSE_LENGTH_MSB
-char SH_RESPONSE_LENGTH_LSB
-char SH_CERTIFICATE_DATA[(MSB << 8)|LSB]
-char SH_CLIENT_CERT_SPECS_DATA[(MSB << 8)|LSB]
-char SH_CLIENT_SIG_SPECS_DATA[(MSB << 8)|LSB]
-char SH_RESPONSE_DATA[(MSB << 8)|LSB]
-
-The server sends this message after receiving the client's
-CLIENT_HELLO message.  The PCT version number in SH_SERVER_VERSION is
-always the maximum protocol version that the server supports; the
-remainder of the message and all subsequent messages will conform to
-the format specified by the protocol version corresponding to the
-minimum of the client and server protocol version numbers.  Unless
-there is an error, the server always returns a random value 32 bytes
-in length in the CONNECTION_ID field.  This value doubles as challenge
-data if the server requests client authentication, and should
-therefore be random in the same sense as the challenge data in the
-CLIENT_HELLO message.  The SH_PAD field may contain any value.
-
-There are two cases for RESTART_SESSION_OK.  In the first case, the
-server returns a zero RESTART_SESSION_OK flag because the CLIENT_HELLO
-message did not contain a session id or because the one it contained
-is unrecognized by the server.  In this case, the server must behave
-as follows:
-
-The server selects any choice with which it is compatible, from each
-of the CH_CIPHER_SPECS, CH_HASH_SPECS, CH_CERT_SPECS and CH_EXCH_SPECS
-lists supplied in the CLIENT_HELLO message.  (These values are
-returned to the client in the SH_CIPHER_SPECS_DATA,
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 14]
-Internet Draft              The PCT Protocol               November 1995
-
-
-SH_HASH_SPECS_DATA, SH_CERT_SPECS_DATA, and SH_EXCH_SPECS_DATA fields,
-respectively.)  The certificate of the type specified in
-SH_CERT_SPECS_DATA and SH_EXCH_SPECS_DATA is placed in the
-CERTIFICATE_DATA field.  The SH_RESPONSE_DATA field is empty, and its
-length is zero.
-
-In the second case, the server returns a non-zero RESTART_SESSION_OK
-flag because the CLIENT_HELLO message contained a session-identifier
-known by the server (i.e. in the server's session-identifier cache).
-In this case, the server must behave as follows:
-
-The server omits the CERTIFICATE_DATA field (with CERTIFICATE_LENGTH
-set to zero), and sets the CIPHER_SPECS_DATA, HASH_SPECS_DATA,
-CERT_SPECS_DATA and EXCH_SPECS_DATA values to the values stored along
-with the session identifier.  There are two subcases: (1) If the
-SH_EXCH_SPECS_DATA does not refer to a TOKEN type, then the
-CLIENT_MAC, SERVER_MAC, CLIENT_WRITE, and SERVER_WRITE keys are
-rederived using the MASTER_KEY from the old session, as well as the
-CONNECTION_ID and CH_CHALLENGE values from the SERVER_HELLO and
-CLIENT_HELLO messages, respectively, for this connection.  (2) If the
-SH_EXCH_SPECS_DATA refers to a TOKEN type, then the keys from the
-on-going session are reused.  In order to obtain fresh key material or
-change the sequence number, TOKEN implementations must use the redo
-handshake mechanism (PCT_ET_REDO_CONN security escape).  When this
-mechanism is used with a TOKEN exchange type, the client must send
-PCT_SESSION_ID_NONE in the CH_SESSION_ID_DATA field of the subsequent
-CLIENT_HELLO message.
-
-The RESPONSE_DATA is constructed by computing the function
-
-Hash( SERVER_MAC_KEY, Hash( "sr", CH_CHALLENGE_DATA, 
-SH_CONNECTION_ID_DATA, CH_SESSION_ID_DATA ) ).
-
-The CH_CHALLENGE_DATA and CH_SESSION_ID_DATA values are found in the
-CLIENT_HELLO message for this connection.  The SH_CONNECTION_ID_DATA
-value is from this SERVER_HELLO message.  The SERVER_MAC_KEY is the
-one rederived for this connection as described in section 5.3.1.  If
-the length of SERVER_MAC_KEY is not an exact multiple of eight bits,
-then SERVER_MAC_KEY is considered, for the purposes of MAC
-computation, to have (fewer than eight) zero bits appended to it, to
-create a string of an integral number of bytes for input into the MAC
-hash function.  The hash function choice used is determined by the
-SH_HASH_SPECS_DATA field in this SERVER_HELLO message.  The values are
-input into the interior invocation of the hash function in the exact
-order specified above, with the string in quotation marks representing
-actual ASCII text.
-
-In both reconnection cases, if the server requires client
-authentication, then the CLIENT_AUTH_REQ field is set to a non-zero
-value.  Also, a list of (client) certificate types acceptable to the
-server, in order of (the server's) preference, is placed in the
-CLIENT_CERT_SPECS_DATA field, and a list of (client's) signature
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 15]
-Internet Draft              The PCT Protocol               November 1995
-
-
-algorithms supported by the server, in order of (the server's)
-preference, is placed in the CLIENT_SIG_SPECS_DATA field.  The
-certificate type values in the list are from the same set of two byte
-codes used for the CERT_SPECS list appearing in the CLIENT_HELLO
-message, and the signature algorithm type codes are also two bytes
-long.  (See section 5.3.4 and 5.3.5 below.)  The lengths of the lists
-in bytes (twice the number of elements) are placed in the
-CLIENT_CERT_SPECS_LENGTH and CLIENT_SIG_SPECS_LENGTH fields.  If no
-client authentication is required, then these length fields, as well
-as the CLIENT_AUTH_REQ field, are set to zero, and the corresponding
-data fields are empty.
-
-When the client receives a SERVER_HELLO message, it checks whether the
-server has accepted a reconnection of an old session or is
-establishing a new session.  If a new session is being initiated, and
-client authentication is requested, then the client checks whether it
-is compatible with any of the certificate and signature types listed
-in the CLIENT_CERT_SPECS and CLIENT_SIG_SPECS lists.  (Note that the
-server can make client authentication optional for the client simply
-by including PCT_CERT_NONE and PCT_SIG_NONE as a "last resort".)  If
-the client can provide a compatible certificate, then it sends a
-CLIENT_MASTER_KEY message as described below; otherwise, it generates
-a SPECS_MISMATCH error.
-
-If the session is an old one, then the client establishes the new
-CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY and SERVER_MAC_KEY
-according to the cipher-specific rules described below in section
-5.3.1.  The client then checks the contents of the RESPONSE_DATA field
-in the SERVER_HELLO message for correctness.  If the response matches
-the value calculated by the client (exactly as described above for the
-server), then the handshake is finished, and the client begins sending
-data; otherwise, a SERVER_AUTH_FAILED error occurs.
-
-
-5.2.3 CLIENT_MASTER_KEY (sent in the clear, except for encrypted keys)
-
-char CMK_MSG_CLIENT_MASTER_KEY
-char CMK_PAD
-char CMK_CLIENT_CERT_SPECS_DATA[2]
-char CMK_CLIENT_SIG_SPECS_DATA[2]
-char CMK_CLEAR_KEY_LENGTH_MSB
-char CMK_CLEAR_KEY_LENGTH_LSB
-char CMK_ENCRYPTED_KEY_LENGTH_MSB
-char CMK_ENCRYPTED_KEY_LENGTH_LSB
-char CMK_KEY_ARG_LENGTH_MSB
-char CMK_KEY_ARG_LENGTH_LSB
-char CMK_VERIFY_PRELUDE_LENGTH_MSB
-char CMK_VERIFY_PRELUDE_LENGTH_LSB
-char CMK_CLIENT_CERT_LENGTH_MSB
-char CMK_CLIENT_CERT_LENGTH_LSB
-char CMK_RESPONSE_LENGTH_MSB
-char CMK_RESPONSE_LENGTH_LSB
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 16]
-Internet Draft              The PCT Protocol               November 1995
-
-
-char CMK_CLEAR_KEY_DATA[(MSB << 8)|LSB]
-char CMK_ENCRYPTED_KEY_DATA[(MSB << 8)|LSB]
-char CMK_KEY_ARG_DATA[(MSB << 8)|LSB]
-char CMK_VERIFY_PRELUDE_DATA[(MSB << 8)|LSB]
-char CMK_CLIENT_CERT_DATA[(MSB << 8)|LSB]
-char CMK_RESPONSE_DATA[(MSB << 8)|LSB]
-
-The client sends this message after receiving the SERVER_HELLO message
-from the server if a new session is being started or if client
-authentication has been requested.  If no client authentication has
-been requested in the SERVER_HELLO message and an old session is being
-reconnected (i.e., if the CLIENT_AUTH_REQ field is zero and the
-RESTART_SESSION_OK field is nonzero), then the CLIENT_MASTER_KEY
-message is not sent.
-
-For TOKEN exchange types, both client and server (re)set the sequence
-numbers to zero when this message is sent/received.
-
-The contents of the CLEAR_KEY_DATA, ENCRYPTED_KEY_DATA, and
-KEY_ARG_DATA fields depend on the contents of the SH_CIPHER_SPECS_DATA
-and SH_EXCH_SPECS_DATA fields in the preceding SERVER_HELLO message.
-These will be described for each possible choice of these values in
-section 5.3.1 and 5.3.2, along with how the various keys
-(CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY, and
-SERVER_MAC_KEY) are derived in each case.  The CMK_PAD field may
-contain any value.
-
-The CMK_VERIFY_PRELUDE_DATA field contains the value
-
-Hash( CLIENT_MAC_KEY, Hash( "cvp", CLIENT_HELLO, SERVER_HELLO ) ).
-
-If the length of CLIENT_MAC_KEY is not an exact multiple of eight
-bits, then CLIENT_MAC_KEY is considered, for the purposes of MAC
-computation, to have (fewer than eight) zero bits appended to it, to
-create a string of an integral number of bytes for input into the MAC
-hash function.  The hash function used is the one specified in
-SH_HASH_SPECS_DATA.  The parameters are input into the hash function
-in the order presented above, with the strings in quotation marks
-representing ASCII text.  Note that the client need only keep a
-"running hash" of all the values passed in these first two messages as
-they appear, then hash the result using the CLIENT_MAC_KEY when
-generated, to compute the value of VERIFY_PRELUDE.
-
-If SH_CLIENT_AUTH_REQ is zero, then CMK_CLIENT_CERT_SPECS_DATA and
-CMK_CLIENT_SIG_SPECS_DATA are both zero, and the CMK_CLIENT_CERT and
-CMK_RESPONSE_DATA fields are empty.  Otherwise, the CMK_RESPONSE_DATA
-field contains the client's authentication response, and the
-CMK_CLIENT_CERT_SPECS_DATA and CMK_CLIENT_SIG_SPECS_DATA fields
-contain the client's choices from the SH_CLIENT_CERT_SPECS_DATA and
-SH_CLIENT_SIG_SPECS_DATA lists, respectively.  The
-CMK_CLIENT_CERT_DATA field contains the client's certificate, which
-must match the certificate type specified in the
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 17]
-Internet Draft              The PCT Protocol               November 1995
-
-
-CMK_CLIENT_CERT_SPECS_DATA field.  Also, the public key in the
-certificate must be a signature key of the type specified in
-CMK_CLIENT_SIG_SPECS_DATA, which in turn must match one of the types
-in the SH_CLIENT_SIG_SPECS_DATA list.
-
-CMK_RESPONSE_DATA is simply a digital signature, using the private
-signature key associated with the public key in the client's
-certificate, of the value in the CMK_VERIFY_PRELUDE_DATA field.  The
-signature algorithm is determined by the CMK_CLIENT_SIG_SPECS_DATA
-field.  (Note that the signature algorithm may itself require that a
-hash function be applied to the data being signed, apart from the one
-used to compute the value in CMK_VERIFY_PRELUDE_DATA.)
-
-Upon receiving a CLIENT_MASTER_KEY message, the server performs the
-cipher-specific functions described in section 5.3 to establish the
-new CLIENT_WRITE_KEY, SERVER_WRITE_KEY, CLIENT_MAC_KEY and
-SERVER_MAC_KEY.  The server then checks the VERIFY_PRELUDE_DATA value,
-the client certificate, and the client response for correctness and
-validity (the latter two only if client authentication had been
-requested).  The checks of the VERIFY_PRELUDE_DATA and RESPONSE_DATA
-are performed by recomputing their correct value, and comparing with
-the values received.  The certificate is verified using whatever
-mechanism has been implemented to validate certificates, and the
-signature in the RESPONSE_DATA field is verified using the
-verification algorithm associated with the signature scheme being
-used.  If all of these values pass their checks, then the server sends
-the SERVER_VERIFY message; otherwise, an error occurs
-(INTEGRITY_CHECK_FAILED, BAD_CERTIFICATE, or CLIENT_AUTH_FAILED,
-respectively).
-
-5.2.4 SERVER_VERIFY (Sent in the clear)
-
-char SV_MSG_SERVER_VERIFY
-char SV_PAD
-char SV_SESSION_ID_DATA[32]
-char SV_RESPONSE_LENGTH_MSB
-char SV_RESPONSE_LENGTH_LSB
-char SV_RESPONSE_DATA[(MSB << 8)|LSB]
-
-The server sends this message upon receiving a valid CLIENT_MASTER_KEY
-message from the client.  The SV_PAD field may contain any value.  If
-an old session is being reconnected, then the RESPONSE_DATA field is
-empty, its length is zero, and the SESSION_ID_DATA field may contain
-any value.  Otherwise, the SV_SESSION_ID_DATA field contains a value
-32 bytes in length, which should be generated randomly (in the same
-sense as the CHALLENGE_DATA field in the CLIENT_HELLO message).  The
-value PCT_SESSION_ID_NONE should not be used as a SV_SESSION_ID_DATA
-value.  The contents of the SV_RESPONSE_DATA field are constructed by
-computing the function
-
-Hash( SERVER_MAC_KEY, Hash( "sr", CH_CHALLENGE_DATA, 
-SH_CONNECTION_ID_DATA, SV_SESSION_ID_DATA ) ).
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 18]
-Internet Draft              The PCT Protocol               November 1995
-
-
-The CH_CHALLENGE_DATA and SH_CONNECTION_ID_DATA values, the choice of
-hash function used, and the value of SERVER_MAC_KEY are determined by
-the CLIENT_HELLO, SERVER_HELLO, SERVER_HELLO and CLIENT_MASTER_KEY
-messages, respectively, immediately preceding the SERVER_VERIFY
-message.  The values are input into the interior invocation of the
-hash function in the exact order specified above, with the string in
-quotation marks representing actual ASCII text.  If the length of
-SERVER_MAC_KEY is not an exact multiple of eight bits, then
-SERVER_MAC_KEY is considered, for the purposes of MAC computation, to
-have (fewer than eight) zero bits appended to it, to create a string
-of an integral number of bytes for intput into the MAC hash function.
-
-When the client receives this message, it verifies the correctness of
-the response data, by computing the hash value as described above and
-comparing it with the one received.  If it is correct, then the client
-proceeds with the first data record transmission; otherwise, a
-SERVER_AUTH_FAILED error occurs.  An implementation may choose to send
-initial data immediately after the CLIENT_MASTER_KEY message, without
-waiting for the SERVER_VERIFY message to arrive, if verifying the
-server's identity before sending it any data is unimportant.
-
-
-5.3  Algorithm and Certificate Types
-
-5.3.1  Key Exchange Algorithms
-
-PCT version 1 permits the following key exchange types:
-
-PCT_EXCH_RSA_PKCS1
-PCT_EXCH_RSA_PKCS1_TOKEN_DES
-PCT_EXCH_RSA_PKCS1_TOKEN_DES3
-PCT_EXCH_RSA_PKCS1_TOKEN_RC2
-PCT_EXCH_RSA_PKCS1_TOKEN_RC4
-PCT_EXCH_DH_PKCS3
-PCT_EXCH_DH_PKCS3_TOKEN_DES
-PCT_EXCH_DH_PKCS3_TOKEN_DES3
-PCT_EXCH_FORTEZZA_TOKEN
-
-Note that the token-based key exchange types specify cipher as well
-(including, implicitly, the FORTEZZA key exchange type); if one of
-these is chosen, then its choice of cipher overrides whatever choice
-of cipher appears in the SH_CIPHER_SPECS_DATA field of the
-SERVER_HELLO message.
-
-For the PCT_EXCH_RSA_PKCS1 key exchange type, a MASTER_KEY value is
-generated by the client, which should be random in the following
-strong sense: attackers must not be able to predict any of the bits in
-the MASTER_KEY.  It is recommended that the bits used be either truly
-random and uniformly generated (using some random physical process) or
-else generated using a cryptographically secure pseudorandom number
-generator, which was in turn seeded with a truly random and uniformly
-generated seed.  This MASTER_KEY value is encrypted using the server's
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 19]
-Internet Draft              The PCT Protocol               November 1995
-
-
-public encryption key, as obtained from the server's certificate in
-the SH_CERTIFICATE_DATA field of the SERVER_HELLO message.  The
-encryption must follow the RSA PKCS#1 standard format (see [2]), block
-type 2.  This encryption is sent to the server in the
-CMK_ENCRYPTED_KEY_DATA field of the CLIENT_MASTER_KEY message, and is
-decrypted by the server to obtain the MASTER_KEY.
-
-For the PCT_EXCH_DH_PKCS3 key exchange type, a random private value x
-(generated in the same way as the MASTER_KEY above) and corresponding
-public value y are generated by the client following RSA PKCS#3
-standard format (see [3]). The value y is then sent to the server in
-the CMK_ENCRYPTED_KEY_DATA field of the CLIENT_MASTER_KEY message.
-The client's private value x, along with the public value y' included
-in the server's certificate in the SH_CERTIFICATE_DATA field of the
-SERVER_HELLO message, is used to generate the MASTER_KEY.  The server
-uses its private value, x', along with the y value sent by the client,
-to obtain the same MASTER_KEY value.
-
-For the various TOKEN key exchange types, all the key material is
-contained in the CMK_ENCRYPTED_KEY_DATA field, but the format of the
-data is defined by the token implementation, or by other future
-documents.
-
-The length of the MASTER_KEY depends on the key exchange type.  For
-the PCT_EXCH_RSA_PKCS1 and PCT_EXCH_DH_PKCS3 exchange types, the
-MASTER_KEY is a 128-bit value.  The CLIENT_WRITE_KEY and
-SERVER_WRITE_KEY are computed as follows:
-
-CLIENT_WRITE_KEY_i = Hash( i, "cw", MASTER_KEY, "cw"^i, 
-SH_CONNECTION_ID_DATA, "cw"^i, SH_CERTIFICATE_DATA,"cw"^i, 
-CH_CHALLENGE_DATA, "cw"^i )
-
-SERVER_WRITE_KEY_i = Hash( i, "svw", MASTER_KEY, "svw"^i, 
-SH_CONNECTION_ID_DATA, "svw"^i, CH_CHALLENGE_DATA, "svw"^i )
-
-The values in quotation marks are treated as (sequences of) ASCII
-characters; "x"^i denotes i copies of the string "x" concatenated
-together.  The function "Hash" is the one determined by the value of
-SH_HASH_SPECS_DATA.  The parameters are input into the hash function
-in the order presented above; the variable i is input as a single-byte
-unsigned integer.  The WRITE_KEYs (i.e., CLIENT_WRITE_KEY and
-SERVER_WRITE_KEY) are obtained by concatenating WRITE_KEY_1 through
-WRITE_KEY_m, where m is the negotiated encryption key length (the
-value in the third byte of the SH_CIPHER_SPECS_DATA field) divided by
-the hash output length, in bits, rounded up to the nearest integer.
-This resulting string is then truncated if necessary (by removing bits
-from the end) to produce a string of the correct length.
-
-The CLIENT_MAC_KEY and SERVER_MAC_KEY are computed as follows:
-
-CLIENT_MAC_KEY_i = Hash( i, MASTER_KEY, "cmac"^i, 
-SH_CONNECTION_ID_DATA, "cmac"^i, SH_CERTIFICATE_DATA, "cmac"^i, 
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 20]
-Internet Draft              The PCT Protocol               November 1995
-
-
-CH_CHALLENGE_DATA, "cmac"^i )
-
-SERVER_MAC_KEY_i = Hash( i, MASTER_KEY, "svmac"^i, 
-SH_CONNECTION_ID_DATA, "svmac"^i, CH_CHALLENGE_DATA, "svmac"^i )
-
-The values in quotation marks are treated as (sequences of) ASCII
-characters; "x"^i denotes i copies of the string "x" concatenated
-together.  The function "Hash" is the one determined by the value of
-SH_HASH_SPECS_DATA.  The parameters are input into the hash function
-in the order presented above; the variable i is input as a single-byte
-unsigned integer.  The MAC_KEYs (ie., CLIENT_MAC_KEY and
-SERVER_MAC_KEY) are obtained by concatenating MAC_KEY_1 through
-MAC_KEY_m, where m is the negotiated MAC key length (64 plus the value
-in the fourth byte of the SH_CIPHER_SPECS_DATA field) divided by the
-hash output length, in bits, rounded up to the nearest integer.  This
-resulting string is then truncated if necessary (by removing bits from
-the end) to produce a string of the correct length.
-
-Note that tokens which are capable of deriving keys using "keyed
-hashes", as described above, are free to use the PCT_EXCH_RSA_PKCS1
-or PCT_EXCH_DH_PKCS3 key exchange type to exchange the MASTER_KEY,
-and then to derive the rest of the keys normally.  The TOKEN key
-exchange types are for tokens that cannot do such keyed-hash key
-derivation, and can only use an exchanged key for bulk encryption
-(of, for example, other keys).  Such tokens can exchange multiple
-keys by using an initially exchanged MASTER_KEY to encrypt other
-keys, as described above.
-
-5.3.2  Cipher Types
-
-PCT version 1 permits the following cipher types to be specified:
-
-PCT_CIPHER_DES
-PCT_CIPHER_IDEA
-PCT_CIPHER_RC2
-PCT_CIPHER_RC4
-PCT_CIPHER_DES_112
-PCT_CIPHER_DES_168
-
-Each of these types is denoted by a two-byte code, and is followed in
-CIPHER_SPECS_DATA fields by two one-byte length specifications, as
-described in section 5.2.1.  An encryption length specification of
-zero associated with any cipher denotes the choice of no encryption; a
-key exchange is performed in such cases solely to share keys for MAC
-computation.  The MAC key length must always be at least 64 bits (see
-section 5.2.1).
-
-The CLEAR_KEY_DATA field is used only when encryption keys of length
-less than the standard length for the specified cipher are used;
-otherwise, the field is empty.  When a key length is specified which
-is less than the standard key length for the specified cipher, then
-keys of the specified length are derived normally as described in
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 21]
-Internet Draft              The PCT Protocol               November 1995
-
-
-section 5.3.1, and then "expanded" to derive standard-length keys.
-The expansion proceeds as follows:
-
-1.  Assign to d the result of dividing the standard key length for 
-the cipher, in bits, by the output length of the hash function, in 
-bits, rounded up to the nearest integer.
-
-2.  Divide CLEAR_KEY_DATA sequentially into d equal subsegments.
-(Note that the length of the CLEAR_KEY_DATA field must therefore be a
-multiple of d bytes, and that no two of its d equal parts, when so
-divided, may be identical.)  Denote these subsegments CLEAR_KEY_DATA_1
-through CLEAR_KEY_DATA_d.
-
-3.  Compute the d hash values
-
-STANDARD_LENGTH_KEY_i := Hash( i, "sl"^i, WRITE_KEY, "sl"^i, 
-CLEAR_KEY_DATA_i ).
-
-The values in quotation marks are treated as (sequences of) ASCII
-characters; "x"^i denotes i copies of the string "x" concatenated
-together.  The function "Hash" is the one determined by the value of
-SH_HASH_SPECS_DATA.  The parameters are input into the hash function
-in the order presented above; the variable i is input as a
-single-byte unsigned integer.  The WRITE_KEY is the encryption key
-(CLIENT_WRITE_KEY or SERVER_WRITE_KEY) being expanded to standard
-length. If the length of the WRITE_KEY is not an exact number of
-bytes, then its final byte is padded with zeroes to increase its
-length to an exact number of bytes.
-
-4.  Concatenate STANDARD_LENGTH_KEY_1 through STANDARD_LENGTH_KEY_d,
-and then truncate as necessary (by removing bits from the end) to
-produce the STANDARD_LENGTH_KEY which is actually used for encryption.
-
-The KEY_ARG_DATA field contains a random eight-byte value to be used
-as an initialization vector (IV) for the first encrypted message when
-a block cipher (any cipher except RC4) is used.  The IV for the first
-block encrypted in any subsequent encrypted message is simply the last
-encrypted block of the previous message.  The KEY_ARG_DATA field is
-empty when cipher type PCT_CIPHER_RC4 (or key exchange type
-PCT_EXCH_RSA_PKCS1_TOKEN_RC4) is used.
-
-PCT_CIPHER_DES denotes DES (see [4]).  Its standard key length is 56
-bits.  PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168 denote ciphers in
-which the input is first encrypted under DES with a first key, then
-"decrypted" under DES with a second key, then encrypted under DES with
-a third key.  For PCT_CIPHER_DES_112, the first and third keys are
-identical, and correspond to the initial 56 bits of the 112-bit
-WRITE_KEY.  The second key corresponds to the final 56 bits of the
-WRITE_KEY.  For PCT_CIPHER_DES_168, the three keys are distinct, and
-correspond to the first, second, and third 56-bit subsegments of the
-WRITE_KEY.  All three of these DES-based cipher types have 64-bit data
-blocks and are used with cipher block chaining (CBC).
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 22]
-Internet Draft              The PCT Protocol               November 1995
-
-
-The standard key lengths for PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168
-are 112 bits and 168 bits, respectively.  If a key length less than
-the standard length is specified for one of these ciphers (or for
-PCT_CIPHER_DES), then the WRITE_KEY is expanded to the standard length
-as described above.
-
-Note that before use, each 56-bit DES key must be "adjusted" to add
-eight parity bits to form an eight-byte DES key (see [4]).  Similarly,
-if the specified WRITE_KEY length is less than its corresponding
-standard length, then each WRITE_KEY is expanded to the standard
-length using CLEAR_KEY_DATA as described above, to produce one, two,
-or three keys of 56 bits each, which are then each "adjusted" by
-adding parity bits to form an eight-byte key.
-
-PCT_CIPHER_IDEA denotes the IDEA block cipher (see [5]), with 64-bit
-data blocks and cipher block chaining.  This cipher has a standard key
-length of 128 bits.
-
-PCT_CIPHER_RC2 denotes the RC2 block cipher, with 64-bit blocks and
-cipher block chaining.  Like IDEA, this cipher has a standard key
-length of 128 bits.
-
-PCT_CIPHER_RC4 denotes the RC4 stream cipher.  Like the IDEA and RC2
-block ciphers, this cipher has a standard key length of 128 bits.
-
-5.3.3  Hash Types
-
-PCT version 1 permits the following hash function types to be
-specified:
-
-PCT_HASH_MD5
-PCT_HASH_MD5_TRUNC_64
-PCT_HASH_SHA
-PCT_HASH_SHA_TRUNC_80
-PCT_HASH_DES_DM
-
-PCT_CIPHER_MD5 denotes the MD5 hash function (see [6]), with 128-bit
-output.  PCT_CIPHER_MD5_TRUNC_64 denotes the MD5 hash function, with
-its 128-bit output truncated to 64 bits.  PCT_HASH_SHA denotes the
-Secure Hash Algorithm (see [7]), with 160-bit output.
-PCT_HASH_SHA_TRUNC_80 denotes the Secure Hash Algorithm, with its
-160-bit output truncated to 80 bits.  PCT_HASH_DES_DM denotes the
-DES-based Davies-Meyer hash algorithm (see [8]), with 64-bit output.
-
-
-5.3.4  Certificate Types
-
-PCT version 1 permits the following certificate types to be specified:
-
-PCT_CERT_NONE
-PCT_CERT_X509
-PCT_CERT_PKCS7
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 23]
-Internet Draft              The PCT Protocol               November 1995
-
-
-These types apply equally to the client's and server's certificates.
-PCT_CERT_NONE denotes that no certificate is necessary; this type can
-be included by, say, the server as a choice, thereby making
-authentication optional for the client.  PCT_CERT_X509 denotes a
-CCITT X.509 standard-conformant certificate (see [9]).
-PCT_CERT_PKCS7 denotes an RSA PKCS#7 standard-conformant certificate
-(see [10]).
-
-
-5.3.5  Signature Types
-
-PCT version 1 permits the following signature key types to be
-specified:
-
-PCT_SIG_NONE
-PCT_SIG_RSA_MD5
-PCT_SIG_RSA_SHA
-PCT_SIG_DSA_SHA
-
-PCT_SIG_NONE denotes that no signature is necessary; this type can be
-included by the server as a choice, thereby making authentication
-optional for the client.  PCT_SIG_RSA_MD5 denotes the signature scheme
-consisting of hashing the data to be signed using the MD5 hash
-algorithm, and then performing an RSA private-key signature function
-(the inverse of RSA encryption) on the result.  The signature must
-conform to RSA PKCS#1, block type 1 (see [2]).  PCT_SIG_RSA_SHA
-denotes the same signature scheme with SHA substituted for MD5.
-PCT_SIG_DSA_SHA denotes the signature scheme consisting of hashing the
-data to be signed using the SHA hash algorithm, then computing a
-signature of the resulting value using the Digital Signature Algorithm
-(DSA; see [11]).
-
-
-5.4 Errors
-
-Error handling in the PCT protocol is very simple.  When an error is
-detected during the handshake phase, the detecting party sends a
-message to the other party indicating the error so that both parties
-will know about it, and then closes the connection.  If a party
-detects an error after it has sent its last handshake message, the
-detecting party simply closes the connection without sending an error
-message.  In the second case there are only two possible errors, and
-the party that does not detect the error can distinguish them as
-follows: if the server sees an aborted connection and the most recent
-message it sent the client was a handshake message, then the error was
-SERVER_AUTH_FAILED; otherwise, the error was INTEGRITY_CHECK_FAILED.
-
-Receiving an error message also causes the receiving party to close
-the connection.  Servers and clients should not make any further use
-of any keys, challenges, connection identifiers, or session
-identifiers associated with such an aborted connection.
-
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 24]
-Internet Draft              The PCT Protocol               November 1995
-
-
-It is recommended that implementations perform some kind of alert or
-logging function when errors are generated to facilitate monitoring of
-various types of attack on the system.
-
-
-The message sent in the event of a handshake-phase error has the
-following form:
-
-char MSG_ERROR
-char ERROR_CODE_MSB
-char ERROR_CODE_LSB
-char ERROR_INFO_LENGTH_MSB
-char ERROR_INFO_LENGTH_LSB
-char ERROR_INFO_DATA[(MSB << 8)|LSB]
-
-The ERROR_INFO_LENGTH field is zero except in the case of the
-SPECS_MISMATCH error message, which has a six-byte ERROR_INFO_DATA
-field.
-
-The PCT Handshake Protocol defines the following errors:
-
-PCT_ERR_BAD_CERTIFICATE
-
-This error occurs when the client receives a SERVER_HELLO message in
-which the certificate is invalid, either because one or more of the
-signatures in the certificate is invalid, or because the identity or
-attributes on the certificate are in some way incorrect.
-
-PCT_ERR_CLIENT_AUTH_FAILED
-
-This error occurs when the server receives a CLIENT_MASTER_KEY message
-from the client in which the client's authentication response is
-incorrect.  The certificate may be invalid, the signature may be
-invalid, or the contents of the signed response may be incorrect.
-
-PCT_ERR_ILLEGAL_MESSAGE
-
-This error occurs under a number of circumstances.  For example, it
-occurs when an unrecognized security escape code is received, when an
-unrecognized handshake message is encountered, or when the value of
-CH_OFFSET is to large for its CLIENT_HELLO message.
-
-PCT_ERR_INTEGRITY_CHECK_FAILED
-
-This error occurs when either the client or the server receives a
-message in which the MAC_DATA is incorrect.  It is also recommended
-that the record be treated as if it contained no data, in order to
-ensure that applications do not receive and process invalid data
-before learning that it has failed its integrity check.
-
-This error also occurs when the VERIFY_PRELUDE_DATA value sent by the
-client in the CLIENT_MASTER_KEY message (during the handshake phase)
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 25]
-Internet Draft              The PCT Protocol               November 1995
-
-
-is incorrect.  In this case, an error message is sent.
-
-PCT_ERR_SERVER_AUTH_FAILED
-
-This error occurs when the client receives a SERVER_HELLO or
-SERVER_VERIFY message in which the authentication response is
-incorrect.
-
-PCT_ERR_SPECS_MISMATCH
-
-This error occurs when a server cannot find a cipher, hash function,
-certificate type, or key exchange algorithm it supports in the lists
-supplied by the client in the CLIENT_HELLO message.  It also occurs
-when the client cannot find a certificate or signature type it
-supports in the list supplied by the server in a SERVER_HELLO message
-that requests client authentication.  (Note that the client or server
-can select the "NONE" option as the last resort for any security
-feature it wishes to make optional.  For example, the server can make
-client authentication optional for the client by passing a list of
-certificate and signature types, each list containing the "NONE" type
-as the last entry.)  This error may also occur as a result of a
-mismatch in cipher specifications or client authentication requests
-between the initial specifications and those that resulted from a redo
-handshake sequence.
-
-The error message for this error includes a six-byte informational
-field, defined as follows:
-
-char SPECS_MISMATCH_CIPHER
-char SPECS_MISMATCH_HASH
-char SPECS_MISMATCH_CERT
-char SPECS_MISMATCH_EXCH
-char SPECS_MISMATCH_CLIENT_CERT
-char SPECS_MISMATCH_CLIENT_SIG
-
-Each field is set to a non-zero value if and only if the corresponding
-list resulted in a mismatch.  For example, if and only if the
-SPECS_MISMATCH error message is being sent because server failed to
-find a certificate type it supports in the list supplied by the client
-in the CH_CERT_SPECS_DATA field, then the SPECS_MISMATCH_CERT field in
-the error message would be non-zero.
-
-5.5  Constants
-
-Following is a list of constant values used in the PCT protocol
-version 1.
-
-5.5.1  Message type codes
-
-These codes are each placed in the first byte of the corresponding
-PCT handshake phase message.
-
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 26]
-Internet Draft              The PCT Protocol               November 1995
-
-
-PCT_MSG_CLIENT_HELLO 		:=	0x01
-PCT_MSG_SERVER_HELLO 		:=	0x02
-PCT_MSG_CLIENT_MASTER_KEY 	:=	0x03
-PCT_MSG_SERVER_VERIFY 		:=	0x04
-PCT_MSG_ERROR			:=	0x05
-
-5.5.2  Specification Type Codes
-
-These are codes used to specify types of cipher, key exchange, hash
-function, certificate, and digital signature in the protocol.
-
-PCT_EXCH_RSA_PKCS1		:=	0x0001
-PCT_EXCH_RSA_PKCS1_TOKEN_DES	:=	0x0002
-PCT_EXCH_RSA_PKCS1_TOKEN_DES3	:=	0x0003
-PCT_EXCH_RSA_PKCS1_TOKEN_RC2	:=	0x0004
-PCT_EXCH_RSA_PKCS1_TOKEN_RC4	:=	0x0005
-PCT_EXCH_DH_PKCS3		:=	0x0006
-PCT_EXCH_DH_PKCS3_TOKEN_DES 	:=	0x0007
-PCT_EXCH_DH_PKCS3_TOKEN_DES3 	:=	0x0008
-PCT_EXCH_FORTEZZA_TOKEN		:=	0x0009
-
-PCT_CIPHER_DES 		:=	0x0001
-PCT_CIPHER_IDEA		:=	0x0002
-PCT_CIPHER_RC2 		:=	0x0003
-PCT_CIPHER_RC4 		:=	0x0004
-PCT_CIPHER_DES_112	:=	0x0005
-PCT_CIPHER_DES_168	:=	0x0006
-
-PCT_HASH_MD5 		:=	0x0001
-PCT_HASH_MD5_TRUNC_64 	:=	0x0002
-PCT_HASH_SHA 		:=	0x0003
-PCT_HASH_SHA_TRUNC_80 	:=	0x0004
-PCT_HASH_DES_DM 	:=	0x0005
-
-PCT_CERT_NONE 		:=	0x0000
-PCT_CERT_X509 		:=	0x0001
-PCT_CERT_PKCS7 		:=	0x0002
-
-PCT_SIG_NONE 		:=	0x0000
-PCT_SIG_RSA_MD5 	:=	0x0001
-PCT_SIG_RSA_SHA 	:=	0x0002
-PCT_SIG_DSA_SHA 	:=	0x0003
-
-5.5.3  Error Codes
-
-These codes are used to identify errors, when they occur, in error
-messages.
-
-PCT_ERR_BAD_CERTIFICATE		:=	0x0001
-PCT_ERR_CLIENT_AUTH_FAILED	:=	0x0002
-PCT_ERR_ILLEGAL_MESSAGE		:=	0x0003
-PCT_ERR_INTEGRITY_CHECK_FAILED	:=	0x0004
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 27]
-Internet Draft              The PCT Protocol               November 1995
-
-
-PCT_ERR_SERVER_AUTH_FAILED	:=	0x0005
-PCT_ERR_SPECS_MISMATCH		:=	0x0006
-
-5.5.4  Miscellaneous Codes
-
-These include escape type codes, version numbers, and assorted
-constants associated with the PCT protocol.
-
-PCT_SESSION_ID_NONE		:=	0x00 (32 bytes of zeros)
-
-PCT_ET_OOB_DATA 		:= 	0x01
-PCT_ET_REDO_CONN		:=	0x02
-
-PCT_VERSION_1			:=	0x8001
-
-PCT_CH_OFFSET_V1		:=	0x000A
-
-PCT_MAX_RECORD_LENGTH_2_BYTE_HEADER :=	32767
-PCT_MAX_RECORD_LENGTH_3_BYTE_HEADER :=	16383
-
-
-6. Security Considerations
-
-This entire document is about security.
-
-
-References
-
-[1]  K. Hickman and T. Elgamal.  The SSL Protocol.  Internet-draft,
-June 1995.
-
-[2]  RSA Laboratories, "PKCS #1: RSA Encryption Standard", Version
-1.5, November 1993.
-
-[3]  RSA Laboratories, "PKCS #3: "Diffie-Hellman Key-Agreement
-Standard", Version 1.4, November 1993.
-
-[4]  NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of
-Standards, US Department of Commerce, Jan. 1977.
-
-[5]  X. Lai, "On the Design and Security of Block Ciphers", ETH Series
-in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
-
-[6]  R. Rivest, RFC 1321: "The MD5 Message Digest Algorithm", April
-1992.
-
-[7]  NIST FIPS PUB 180-1, "Secure Hash Standard", National Institute
-of Standards and Technology, US Department of Commerce, Apr. 1995.
-
-[8]  ISO/IEC 9797, "Data Cryptographic Techniques--Data Integrity
-Mechanism Using a Cryptographic Check Function Employing a Block
-Cipher Algorithm", 1989.
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 28]
-Internet Draft              The PCT Protocol               November 1995
-
-
-[9]  CCITT. Recommendation X.509: "The Directory - Authentication
-Framework". 1988.
-
-[10]  RSA Laboratories, "PKCS #7: Cryptographc Message Syntax
-Standard", Version 1.5, November 1993.
-
-[11]  NIST FIPS PUB 186, "Digital Signature Standard", National
-Institute of Standards and Technology, US Department of Commerce, May
-1994.
-
-[12]  B. Schneier, "Applied Cryptography: Protocols, Algorithms, and
-Source Code in C", John Wiley & Sons, Inc., 1994.
-
-[13]  R.L. Rivest, A. Shamir, L. Adelman, "A Method for Obtaining
-Digital Signatures and Public Key Cryptosystems" MIT Laboratory for
-Computer Science and Department of Mathematics, S.L. Graham,
-R.L. Rivest ed. Communications of the ACM, February 1978 (Vol 21,
-No. 2) pages 120-126.
-
-Patent Statement
-
-This version of the PCT protocol relies on the use of patented public
-key encryption technology for authentication and encryption. The
-Internet Standards Process as defined in RFC 1310 requires a written
-statement from the Patent holder that a license will be made
-available to applicants under reasonable terms and conditions prior
-to approving a specification as a Proposed, Draft or Internet
-Standard.
-
-See existing RFCs, including RFC 1170, that discuss known public key
-cryptography patents and licensing terms and conditions.
-
-The Internet Society, Internet Architecture Board, Internet
-Engineering Steering Group and the Corporation for National Research
-Initiatives take no position on the validity or scope of the patents
-and patent applications, nor on the appropriateness of the terms of
-the assurance. The Internet Society and other groups mentioned above
-have not made any determination as to any other intellectual property
-rights which may apply to the practice of this standard. Any further
-consideration of these matters is the user's own responsibility.
-
-Author's Address
-
-Josh Benaloh/Butler Lampson/Daniel R. Simon/Terence Spies/Bennet Yee
-Microsoft Corp.
-One Microsoft Way
-Redmond WA 98052
-USA
-
-pct@microsoft.com
-
-This Internet-Draft expires 27 March 1996.
-
-
-Benaloh/Lampson/Simon/Spies/Yee                                [Page 29]
-
-
diff --git a/doc/protocol/draft-benaloh-pct-01.txt b/doc/protocol/draft-benaloh-pct-01.txt
deleted file mode 100644
index f9e61ba096..0000000000
--- a/doc/protocol/draft-benaloh-pct-01.txt
+++ /dev/null
@@ -1,2649 +0,0 @@
-
-Internet Draft				    Daniel Simon
-						    Microsoft Corp.
-						    April 1996
-
-	    The Private Communication Technology Protocol
-		     <draft-benaloh-pct-01.txt>
-
-1. Status of this Memo
-
-This document is an Internet-Draft.  Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas,
-and its working groups. Note that other groups may also distribute
-working documents as Internet-Drafts.
-
-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".
-
-To learn the current status of any Internet-Draft, please check the
-"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
-Directories on ds.internic.net (US East Coast), nic.nordu.net
-(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-This Internet-Draft expires 10 October 1996.
-
-
-2. Abstract
-
-This document specifies Version 2 of the Private Communication
-Technology (PCT) protocol, a security protocol that provides privacy
-over the Internet.  The protocol is intended to prevent eavesdropping 
-on connection-based communications in client/server applications, 
-with at least one of the two always being authenticated, and each 
-having the option of requiring authentication of the other.  PCT is 
-somewhat similar to SSL ([1]); however, PCT version 1 corrects
-or improves on several weaknesses of SSL, and version 2 also adds a 
-number of new features.  PCT version 2 is fully compatible with PCT 
-version 1.
-
-
-3. Introduction
-
-The Private Communication Technology (PCT) Protocol is designed to
-provide privacy between two communicating applications (a client and a
-server), and to authenticate at least one of the two (typically the
-server) to the other.  The PCT Protocol is application 
-protocol-independent.  A "higher level" application protocol (e.g. 
-HTTP, FTP, TELNET, etc.) can layer on top of the PCT Protocol 
-transparently.
-
-In the PCT protocol, all data is transmitted in the form of 
-variable-length records, each of which has a record header.  These
-records are used to transmit both PCT protocol messages (including
-handshake, error, and key management messages) and application data
-messages.  Exchanges of records between a client and server are 
-grouped into "connections", which are in turn grouped into "sessions".  
-Every PCT connection belongs to some particular session.
-
-Every PCT protocol connection begins with a handshake phase, during 
-which a sequence of handshake messages (comprising the PCT Handshake 
-Protocol) are exchanged, which negotiate a (symmetric) session key 
-for the connection, as well as performing the requested 
-authentications based on certified asymmetric public (signature or 
-key exchange) keys (or on previously shared private "password" keys).  
-Once transmission of application protocol data messages begins in a 
-connection, all data (including error and key management messages) is 
-encrypted using encryption keys derived from a "master key" exchanged 
-during some handshake phase of the connection's session, as well as 
-from the handshake messages that began the connection.  In addition 
-to encryption and authentication, the PCT protocol verifies the 
-integrity of messages using a hash function-based message 
-authentication code (MAC).
-
-PCT assumes a reliable transport protocol (e.g. TCP) for PCT record 
-transmission and reception during the handshake phase (and 
-afterwards as well in version 1); however, use of datagram records 
-in version 2 makes it possible for individual records to be sent 
-independently (as "datagrams"), with neither order nor eventual 
-delivery guaranteed.  
-
-It should be noted that the PCT protocol does not specify any details
-about verification of identities or certificates with respect to 
-account administrators, certification authorities, revocation lists, 
-and so on.  Rather, it is assumed that protocol implementations have 
-access to a "black box" which is capable of ruling on the validity of 
-received identities and certificates in a manner satisfactory to the 
-implementation's user.  Such a ruling may, for instance, involve 
-remote consultation with a trusted service, or even with the actual 
-user through a text or graphic interface.
-
-The PCT protocol's compatibility with, and differences from, SSL 
-([1]) are outlined in the specification of PCT version 1 ([2]).  
-PCT version 2 is fully compatible with PCT version 1, in that an 
-implementation of version 1 is a valid (though less feature-rich) 
-implementation of version 2.  If either the client or server (or 
-both) identifies itself during the handshake phase as using PCT 
-version 1, then the session conforms to the PCT version 1 
-specification, and features introduced in version 2 are not available.
-PCT version 1 compatibility details are given in section 8.
-
-PCT version 2 is different from PCT version 1 in the following 
-respects:
-
-- PCT version 2 has a revised record format which allows handshake 
-  records, error records and data records, as well as "key management" 
-  and "datagram" records (two new record types) to be explicitly 
-  recognized and distinguished from each other based on header 
-  information.  Record headers can also indicate continuations of 
-  previous records, allowing protocol messages of any type to span 
-  multiple records, just as user data already does in PCT version 1.  
-  Finally, encapsulating user data in a new "data message" format 
-  allows the invocation (using assigned data message types) of 
-  intermediate processing, such as compression/decompression,
-
-- PCT version 2 "datagram" records are independently decryptable, 
-  allowing encrypted data to be sent securely across unreliable 
-  transports, where neither delivery nor correct order are 
-  guaranteed.
-
-- PCT version 2 "key management" records allow encryption and/or
-  message authentication keys to be temporarily changed within a 
-  session, to support the transport of pre-encrypted data.
-
-- PCT version 2 adds a "closing connection" key management message to 
-  ensure that connections aren't prematurely closed by someone 
-  unauthorized to do so.
-
-- PCT version 2 message authentication is altered to include record
-  headers.
-
-- The handshake phase of PCT version 2 allows a wider, more symmetrical
-  variety of authentication options:  either client or server or both 
-  may be authenticated, each by means of either a key exchange or 
-  signature public key and certificate.  
-
-- PCT version 2 allows a new "private" authentication type, in which 
-  authentication is based on a previously shared identity-associated
-  private key, rather than a certified public key.
-
-
-4. PCT Record Protocol Specification
-
-4.1 Notation
-
-The following notation is used in this specification to represent
-data field formats in various protocol messages:
-
-char MSG_EXAMPLE
-char FIELD1
-char FIELD2
-char THING_LENGTH[2]
-char ANOTHER_THING_LENGTH[4]
-char THING_DATA[([0] << 8)|[1]]
-char ANOTHER_THING_DATA[([0]<<24)|([1]<<16)|([2]<<8)|[3]]
-...
-
-The order is presented top to bottom, with the topmost field being 
-transmitted first.  The "FIELD1" and "FIELD2" fields are each one 
-byte long; the "THING_LENGTH" and "ANOTHER_THING_LENGTH" fields have 
-lengths of two and four bytes, respectively, as indicated by the 
-numbers in square brackets following the field labels.  Their bytes 
-are indexed by their offset from the beginning of the field, starting 
-with THING_LENGTH[0] and ANOTHER_THING_LENGTH[0], which are the
-first bytes transmitted in their respective fields.
-
-In the "THING_DATA" and "ANOTHER_THING_DATA" entries, the values in
-square brackets indicate byte offset indices in THING_LENGTH and
-ANOTHER_THING_LENGTH, respectively.  As presented above, the notation 
-refers to combining the bytes of the LENGTH field in order to form an 
-unsigned integer, with the bytes arranged in decreasing order of 
-significance.  This integer defines the number of bytes of data in 
-the corresponding DATA field.  For example, if THING_LENGTH[0] were 
-one and THING_LENGTH[1] were four then the THING_DATA array would be 
-exactly 260 bytes long.  And if the values of the four bytes of 
-ANOTHER_THING_LENGTH were zero, one, two and four, respectively, then 
-ANOTHER_THING_DATA would be exactly 66,052 bytes long.  This 
-shorthand form is used throughout the specification; occasionally, a 
-"THING_DATA" field is referred to as "THING", with the word "DATA" 
-omitted.
-
-Individual bits within a data field are denoted as follows:
-
-LEAST_SIGNIFICANT_BIT       := 0x0001
-NEXT_LEAST_SIG_BIT          := 0x0002
-THIRD_LEAST_SIG_BIT         := 0x0004
-...
-
-These bit identifiers correspond to the least, second-least and 
-third-least significant bits (in that order) in a two-byte data 
-field.  The associated hexadecimal values consist of all zero bits
-except for the identified bit.
-
-Computations involving a hash function (sometimes iterated) are 
-denoted as follows:
-
-COMPUTATION_RESULT_i = Hash( "ASCII string hash input 1"^i, 
-HASH_INPUT_2, HASH_INPUT_3^i, Hash( "ASCII string hash input 4",
-HASH_INPUT_5, i ) )
-
-The values in quotation marks are treated as (sequences of) ASCII
-characters; "x"^i (or VARIABLE^i) denotes i copies of the string 
-"x" (or variable VARIABLE, respectively) concatenated together.  The 
-parameters are input into the hash function in the order presented; 
-the variable i, wherever it appears as an input value, is input as a 
-single-byte unsigned integer.  If any input has a length which is not
-an integral number of bytes, then (fewer than eight) zero bits are
-appended to its last byte to produce an input which is an integral 
-number of bytes.  The value of COMPUTATION_RESULT is obtained by 
-concatenating the COMPUTATION_RESULT_i values in order, for values of 
-i in a specified range.  (If no subscript i is present in the 
-specified formula, then the implied range includes only the value 1.)  
-If the resulting value requires truncation, then the truncation is 
-performed by removing bits from the end to obtain a string of the 
-required length.
-
-In the case of elements of specifically named records or messages, 
-the names of record or message elements have prefixes that identify 
-the messages in which they appear.  These prefixes are sometimes 
-omitted in the text when the containing messages are obvious, or 
-when the same elements have more than one possible prefix.
-
-
-4.2 PCT Record Format
-
-4.2.1 Record header format
-
-A PCT record consists of a four-byte header followed by a 
-variable-length body.  The maximum length of the body is 32763 
-bytes. 
-
-The PCT record header formats differ in versions 1 and 2.  The 
-version 2 record header will be described in this section; its 
-compatibility with the version 1 header (which is described fully 
-in [2]) is explained in section 8.
-
-The PCT version 2 record header has the following structure:
-
-char RH_RECORD_LENGTH[2]
-char RH_RECORD_TYPE[2]
-
-RECORD_LENGTH is an unsigned integer representing the length of the
-(cleartext) data following the length field in the record header
-(including the RH_RECORD_TYPE field and the subsequent record body).
-The first (most significant) bit of the first (most significant) 
-byte of this field is set to one, for backward compatibility reasons
-(see section 9); this bit must be reset to zero to obtain the
-correct unsigned integer value.  Note that if encryption expands the 
-length of the data, the length of the (fully or partially encrypted) 
-record body plus RH_RECORD_TYPE field will not match the value in 
-RECORD_LENGTH; the effect of each cipher on data length is described 
-in section 6.1.5.
-
-RECORD_TYPE is a two-byte field indicating the type of contents in the 
-record, and in particular, how the record should be processed.  PCT 
-version 2 defines a number of record type values for specific record 
-types; other record types are used to identify PCT version 1 (or 
-SSL version 2 or 3) connections, for appropriate processing.  These 
-are RT_VERSION_1_CH, RT_VERSION_1_SH, RT_SSL_VERSION_2_CH, 
-RT_SSL_VERSION_2_SH and RT_SSL_VERSION_3, respectively.  (Note that 
-type RT_SSL_VERSION_3 is defined only on the first, or most 
-significant, byte; the second, or least significant byte can have 
-any value.)  The normal PCT version 2 record types are RT_HANDSHAKE, 
-RT_DATAGRAM, RT_KEY_MGMT, RT_ERROR, and RT_USER_DATA; their 
-associated record data formats are described in section 4.3.  All
-other defined record types are reserved, and must never be used.
-One of them, RT_CD_RESERVED, is also explicitly defined to preclude 
-use in future versions.
-
-
-4.3 PCT Record Body Formats
-
-4.3.1 Handshake Record Body Format
-
-PCT version 2 Handshake records (those with RECORD_TYPE 
-RT_HANDSHAKE) have a very simple body format:
-
-char HS_MSG_TYPE[2]
-char HS_RECORD_FLAGS[2]
-char HS_HANDSHAKE_DATA[RH_RECORD_LENGTH - 6]
-
-The possible HS_MSG_TYPE values are HS_CLIENT_HELLO,
-HS_SERVER_HELLO, HS_CLIENT_MASTER_KEY, HS_SERVER_VERIFY, and
-HS_CLIENT_VERIFY.  HS_RECORD_FLAGS is a two-byte field containing 
-informational flags about the handshake record.  The only two flags 
-defined in PCT version 2 are the last (least significant) two bits 
-of HS_RECORD_FLAGS:
-
-HS_FLAG_TO_BE_CONTD         :=  0x0001
-HS_FLAG_CONTINUATION        :=  0x0002
-
-The last (least significant) bit, HS_FLAG_TO_BE_CONTD, indicates 
-when set that the next record received of the same type is to be 
-considered a continuation of the current one.  The 
-second-least-significant bit, HS_FLAG_CONTINUATION, indicates when 
-set that the record is to be considered a continuation of the 
-previous record received of the same type.  (For PCT version 1 
-compatibility reasons, a CLIENT_HELLO message must not be continued 
-over more than one handshake record.)  The remaining flag bits are 
-reserved, and must be set to zero.  
-
-The HS_HANDSHAKE_DATA field contains data from a PCT handshake 
-message; the structure of these messages is described in section 
-5.2.  Note that a single handshake message may stretch across more 
-than one handshake record; in that case the appropriate flags are set 
-in the record header.  (A restriction on how a handshake message is
-fragmented among records is given in section 5.2.)
-
-4.3.2 Datagram Records
-
-A datagram record is an independently decryptable data record; its
-enclosed data message can be decrypted, and its MAC checked, 
-regardless of whether previous records were delivered in order (or 
-at all).  Datagrams can hence be used if the underlying transport
-does not guarantee in-order delivery of records; for example, it 
-makes possible the transmission of "out-of-band" data for rapid 
-delivery in a TCP connection.
-
-The format of PCT version 2 datagram records is as follows: 
-
-char DG_ENCRYPTED_KEY_LENGTH[2]
-char DG_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
-char DG_ENCRYPTED_DATA[ENCRYPTED_LENGTH]
-char DG_MAC_DATA[MAC_LENGTH]
-
-The DG_ENCRYPTED_KEY_DATA field contains the key information necessary
-to perform decryption and MAC verification of the datagram record; its
-contents are described in section 6.1.3.  The DG_ENCRYPTED_DATA field 
-contains an encryption of ACTUAL_DATA (consisting of the ACTUAL_LENGTH
-bytes of the datagram's enclosed data message).  The DG_MAC_DATA field 
-contains the "Message Authentication Code" (MAC); its contents are 
-described in section 7.3.  Note that ACTUAL_LENGTH can be calculated 
-directly as RECORD_LENGTH - ENCRYPTED_KEY_LENGTH - MAC_LENGTH - 4.  The 
-length of the encrypted datagram record body plus RH_RECORD_TYPE field
-may be greater than RECORD_LENGTH, as a result of expansion during 
-encryption; see section 6.1.5.
-
-
-4.3.3  Other Record Types
-
-The bodies of PCT version 2 key management, error and user data 
-records (those with RECORD_TYPE RT_KEY_MGMT, RT_ERROR and 
-RT_USER_DATA, respectively) contain encrypted data, in the following 
-data format:
-
-char DT_ENCRYPTED_DATA[ENCRYPTED_LENGTH]
-char DT_MAC_DATA[MAC_LENGTH]
-
-The ENCRYPTED_DATA field contains an encryption of ACTUAL_DATA 
-(consisting of the ACTUAL_LENGTH bytes of the enclosed data message). 
-The MAC_DATA field contains the "Message Authentication Code" (MAC);
-its contents are described in section 7.3.  ACTUAL_LENGTH can be 
-calculated directly as RECORD_LENGTH - MAC_LENGTH - 2.
-
-
-4.4 Key Management Messages
-
-Key management messages have the following format:
-
-char KM_KEY_MGMT_TYPE[2]
-char KM_NEW_HASH_TYPE[2]
-char KM_NEW_CIPHER_TYPE[4]
-char KM_WRITE_KEY_LENGTH[2]
-char KM_WRITE_KEY_DATA[([0] << 8)|[1]]
-
-There are four possible values of KM_KEY_MGMT_TYPE:
-KM_TYPE_FIXED_KEY (setting up the transmission of pre-encrypted data), 
-KM_TYPE_RESUME_KEY (used to end transmission of pre-encrypted data), 
-KM_TYPE_REDO_HANDSHAKE (triggering a new run of the handshake 
-protocol), and KM_TYPE_CLOSE_CONN (preceding the closure of a 
-connection).
-
-4.4.1 Preencrypted data
-
-A KM_KEY_MGMT_TYPE value of KM_TYPE_FIXED_KEY indicates that the key 
-management message contains a fixed encryption key with which 
-subsequent data records will be encrypted until further notice.  
-Using this type of key management message, a client or server can 
-send data that has been pre-encrypted and stored in encrypted form.  
-Note that pre-encrypted data can be pre-MAC'd as well.  (See section 
-7.3.)  Note also that a key management message of this type must not 
-be sent unless both client and server have indicated support for the 
-pre-encrypted data feature during the handshake phase associated with 
-this connection; see sections 5.2.1 and 5.2.2.
-
-In a message of type KM_TYPE_FIXED_KEY, KM_NEW_CIPHER_TYPE contains a 
-cipher type code, and KM_NEW_HASH_TYPE contains a hash function type 
-code (see sections 6.2 and 6.3, respectively).  These types must be
-supported by the receiver of this message, as indicated in during the 
-handshake phase for this connection.  (See sections 5.2.1 and 5.2.2.)  
-The fixed encryption key (WRITE_KEY) is sent in the field 
-KM_WRITE_KEY_DATA. 
-
-Note that the encryption and MAC calculation used for the key 
-management message itself, and for subsequent non-data records, are 
-not altered.  However, subsequent data records in the same direction 
-are encrypted using the WRITE_KEY sent in the KM_WRITE_KEY_DATA 
-field, until a key management message of type KM_TYPE_FIXED_KEY or 
-KM_TYPE_RESUME_KEY is sent and received, or until the connection 
-closes.  (Note that pre-encrypted data is not "nested"; a 
-KM_TYPE_FIXED_KEY message is treated as a KM_TYPE_RESUME_KEY message 
-immediately followed by a KM_TYPE_FIXED_KEY message.)  
-
-4.4.2 Restoring original key
-
-A key management message of type KM_TYPE_RESUME_KEY restores the value 
-of the encryption key used for data records transmitted in the same 
-direction to the value originally negotiated during the handshake 
-phase of the current connection.  This key is used until the 
-connection closes, or until a key management message of type 
-KM_TYPE_FIXED_KEY or KM_TYPE_REDO_HANDSHAKE is received.  
-
-In this message, the KM_CIPHER_TYPE and KM_HASH_TYPE messages are set 
-to their original values negotiated during the handshake phase for 
-the current connection.  (See section 5.2.2.)  The remaining data 
-fields are empty, and their length is zero.
-
-
-4.4.3 Closing connection
-
-If both client and server indicated support for the "closing 
-connection" feature during the handshake phase of the current 
-connection (see sections 5.2.1 and 5.2.2), then the connection is 
-"closure-monitored", and closure of a connection is handled in a 
-special way.  Whenever a client or server is about to close a 
-closure-monitored connection without an error, at any point following 
-the completion of the handshake phase of the protocol, an exchange of 
-key management messages of type KM_TYPE_CLOSE_CONN is initiated 
-first.  In both messages, the KM_NEW_CIPHER_TYPE and KM_NEW_HASH_TYPE 
-fields contain the current cipher and hash types, respectively, and 
-the remaining data fields are empty, with length zero.  The sender of 
-one of these messages simply waits for a message of the same type to 
-be received in reply, then closes the connection; a receiver of such 
-a message who has not yet sent one replies with a message of the same 
-type, then closes the connection.  A closure-monitored connection 
-closed without an error before receipt of a message of this type 
-results in a CONN_BROKEN error (see section 4.6).
-
-
-4.4.4  Redo handshake
-
-If both client and server indicated support for the "redo handshake" 
-feature during the handshake phase of the current connection (see 
-sections 5.2.1 and 5.2.2), then the connection is "redo-enabled", and 
-either the client or the server may request, at any time after the 
-handshake phase has been completed for a connection, that another 
-handshake phase be performed for that connection.  For example, 
-either party may request another handshake phase instead of closing 
-the connection in order to avoid allowing a sequence number to "wrap" 
-beyond 0xFFFFFFFF (see section 7.3).  In addition, it is recommended 
-that implementations enforce limits on the duration of both 
-connections and sessions, with respect to the total number of bytes 
-sent, the number of records sent, the actual time elapsed since the 
-beginning of the connection or session, and, in the case of sessions, 
-the number of reconnections made.  These limits serve to ensure that 
-keys are not used more or longer than it is safe to do so; hence the 
-limits may depend on the type and strength of cipher, key exchange and 
-authentication used, and may, at the implementer's discretion, include 
-indications from the application as to the sensitivity of the data 
-being transmitted or received.  They may be enforced using closure of 
-the connection or (in a redo-enabled connection) "redo handshake" key 
-management messages.
-
-To request a new handshake phase for the current connection, the 
-sender (client or server) sends a key management message of type 
-KM_TYPE_REDO_HANDSHAKE.  The KM_NEW_CIPHER_TYPE and KM_NEW_HASH_TYPE
-fields contain the current cipher and hash types, respectively, and
-the remaining data fields are empty, with length zero.
-
-There are several cases to consider to ensure that messages are 
-dealt with in the correct order.  The following rules ensure that the
-first messages in the redone handshake are always immediately preceded
-by a "redo handshake" key management message.
-
-If the client initiates the "redo handshake", it sends the "redo 
-handshake" message immediately followed by a normal CLIENT_HELLO 
-handshake message; the server, on receiving the "redo handshake" 
-message, may be in one of two states.  If the last message it sent 
-was a "redo handshake" message, then it simply waits for the 
-CLIENT_HELLO message; otherwise, it sends a "redo handshake" message 
-in response, and then waits for the CLIENT_HELLO message. 
-
-If the server initiates the "redo handshake", then the server sends 
-the "redo handshake" message and simply waits for a "Redo Handshake" 
-message in response; this "redo handshake" message should be 
-immediately followed by a normal CLIENT_HELLO handshake message. The 
-client, on receiving the server's "redo handshake" message, may be in 
-one of two states.  If the last two messages it sent were a "redo 
-handshake" message followed by a CLIENT_HELLO message, then it simply 
-waits for a SERVER_HELLO handshake message; otherwise, it sends a 
-"redo handshake" message in response, followed by a CLIENT_HELLO 
-message, and then waits for a SERVER_HELLO message.
-
-In all cases, the sender of the "redo handshake" message continues to 
-process incoming messages, but may not send any non-handshake messages 
-until the new handshake completes.  If the connection is 
-closure-monitored (see section 4.4.3), then the sending of an 
-unprovoked "closing connection" key management message between the 
-sending of a "redo handshake" message and the completion of the 
-subsequent handshake is not permitted.  However, in such connections 
-the sender of a "redo handshake" message must be prepared to receive a
-"closing connection" message instead of a "redo handshake" message; in 
-this case the sender responds with a "closing connection" message and 
-closes the connection.
-
-The handshake phase that follows a "redo handshake" message exchange 
-is a normal one in most respects; the client may request the 
-reconnection of an old session or request that a new session be 
-initiated, and the server, on receiving a reconnection request, can 
-accept the reconnection or demand that a new session be initiated 
-instead.  If a new session is being established, then both client and 
-server must request the same type of authentication requested in the 
-previous session; if one or the other was not authenticated in the 
-previous session, then requesting authentication from the 
-non-authenticated party in the new handshake phase is permitted.  Both
-parties must verify that the specifications negotiated previously in 
-the session (cipher type, key exchange type, certificate type and 
-certifier, hash function type, signature types, and so on), as well as 
-any certificates exchanged, are identical to those found in the new 
-handshake phase (with the exception of new types and certificates for 
-an authentication performed in this handshake, but not in the previous 
-one).  A mismatch results in a SPECS_MISMATCH or BAD_CERTIFICATE 
-error (see section 4.6.)  This ensures that the security properties 
-of the communication channel do not change for the worse.
-
-
-4.5  Data messages
-
-Data messages contain user data to be delivered back to the 
-application using PCT.  Each data record or datagram record contains
-exactly one data message (corresponding to the ACTUAL_DATA field 
-in the description of these records), and data messages are never 
-continued across multiple messages.
-
-PCT version 2 Data messages have the following format:
-
-char DM_MESSAGE_TYPE[2]
-char DM_MESSAGE_DATA[MESSAGE_LENGTH]
-
-The only defined MESSAGE_TYPE in PCT version 2 is DM_TYPE_USER_DATA;
-the data in messages of this type is presented directly to the 
-application.  However, implementations of PCT can assign types to 
-other values to indicate types of preprocessing, such as particular 
-compression/decompression algorithms, to be performed before passing 
-the data in MESSAGE_DATA to the application.  Such implementations
-should allow messages to be nested in the obvious way, with each 
-preprocessing step yielding another data message of the correct 
-format, and the last step yielding a data message of type  
-DM_TYPE_USER_DATA.  The permissible message types for a particular
-connection are negotiated during the handshake phase; see sections 
-5.2.1 and 5.2.2.  An unrecognized message type results in an 
-ILLEGAL_MESSAGE error (see section 4.6).
-
-For message type DM_TYPE_USER_DATA, the DM_MESSAGE_DATA field 
-contains user data to be passed to the application.  For other 
-message types, DM_MESSAGE_DATA contains data which, after the 
-preprocessing determined by the message type, yields another data 
-message.  MESSAGE_LENGTH (for the data message directly contained in
-the data or datagram record) is calculated as ACTUAL_LENGTH - 2, or 
-RECORD_LENGTH - ENCRYPTED_KEY_LENGTH - MAC_LENGTH - 6 if the message 
-is contained in a datagram record and RECORD_LENGTH - MAC_LENGTH - 4 
-if it is contained in a data record.  
-
-4.6 Error messages
-
-Error handling in the PCT protocol is very simple.  When an error is
-detected before a connection is closed, the detecting party sends a
-message to the other party indicating the error so that both parties
-will know about it, and then closes the connection.  In the case of
-closure-monitored connections (see section 4.4.3), the error message
-replaces the "closing connection" key management message.  Receiving 
-an error message also causes the receiving party to close the 
-connection.  (No "closing connection" message is ever sent in reply to 
-an error message before closure.)  
-
-Servers and clients should not make any further use of any keys, 
-challenges, connection identifiers, or session identifiers associated 
-with a connection aborted due to an error.  It is recommended that 
-implementations perform some kind of alert or logging function when 
-errors are generated to facilitate monitoring of various types of 
-attack on the system.
-
-Error messages have the following format:
-
-char ER_ERROR_TYPE[2]
-char ER_ERROR_INFO_LENGTH[2]
-char ER_ERROR_INFO_DATA[([0] << 8)|[1]]
-
-The ERROR_INFO_LENGTH field is zero except in the case of the
-SPECS_MISMATCH error message, which has a two-byte ERROR_INFO_DATA
-field.  Note that when an error message is sent before the end of
-the handshake phase of the protocol, the record containing it is left 
-unencrypted, and its MAC is omitted.
-
-The following errors are defined in PCT version 2:
-
-PCT_ERR_BAD_CERTIFICATE
-
-This error occurs when the client or server receives a handshake 
-message in which a key-exchange public key certificate is invalid, 
-either because one or more of the signatures in the certificate is 
-invalid, or because the identity or attributes on the certificate 
-are in some way incorrect.
-
-PCT_ERR_CLIENT_AUTH_FAILED
-
-This error occurs when the server receives a CLIENT_MASTER_KEY or
-CLENT_VERIFY message from the client in which the client's 
-authentication response is incorrect.  The certificate may be 
-invalid, the signature may be invalid, or the contents of the signed 
-response may be incorrect.
-
-PCT_ERR_CONN_BROKEN
-
-This error occurs when a closure-monitored connection (see section
-4.4.3) is closed without an error message or a "closing connection" 
-key management message having been received.  Since this error only
-occurs after a connection has been closed, no error message is sent.
-
-PCT_ERR_ILLEGAL_MESSAGE
-
-This error occurs under a number of circumstances.  For example, it
-occurs when an unrecognized handshake message is encountered, or when 
-the value of CH_OFFSET is to large for its CLIENT_HELLO message.
-
-PCT_ERR_INTEGRITY_CHECK_FAILED
-
-This error occurs when either the client or the server receives a
-record in which the MAC_DATA is incorrect.  It is also recommended
-that such a record be treated as if had not been received, in order 
-to ensure that applications do not receive and process invalid data
-before learning that it has failed its integrity check.  
-
-PCT_ERR_SERVER_AUTH_FAILED
-
-This error occurs when the client receives a SERVER_HELLO or
-SERVER_VERIFY message in which the authentication response is
-incorrect.
-
-PCT_ERR_SPECS_MISMATCH
-
-This error occurs when a server cannot find a cipher, hash function,
-certificate type, or key exchange algorithm it supports in the lists
-supplied by the client in the CLIENT_HELLO message.  This error may 
-also occur as a result of a mismatch in cipher specifications or 
-client authentication requests between the initial specifications and 
-those that resulted from a redo handshake sequence.
-
-The error message for this error includes a two-byte informational
-field, with eight flags defined as follows:
-
-SPECS_MISMATCH_CIPHER           = 0x0001
-SPECS_MISMATCH_HASH             = 0x0002
-SPECS_MISMATCH_EXCH             = 0x0004
-SPECS_MISMATCH_SIG              = 0x0008
-SPECS_MISMATCH_CERT             = 0x0010
-SPECS_MISMATCH_CERTIFIER        = 0x0020
-SPECS_MISMATCH_COMBINATION      = 0x0040
-
-Each flag is set if and only if the corresponding list resulted in 
-a mismatch.  For example, if and only if the SPECS_MISMATCH error 
-message is being sent because server failed to find a certificate 
-type it supports in the list supplied by the client in the 
-CH_CERT_LIST_DATA field, then the SPECS_MISMATCH_CERT flag in
-the error message would be non-zero.  The SPECS_MISMATCH_COMBINATION
-flag indicates that while there were matches found in each
-individual category, all available certificates were incompatible
-with all the type entries in at least one of the relevant lists
-(CH_CERT_LIST_DATA, CH_CERTIFIER_LIST_DATA, CH_EXCH_LIST_DATA and 
-CH_SIG_LIST_DATA).
-
-
-5. PCT Handshake Phase
-
-5.1 PCT handshake protocol overview
-
-5.1.1  PCT handshake protocol introduction
-
-The PCT Handshake Protocol (version 2) is performed during the 
-handshake phase at the start of every connection, and is used to 
-negotiate security enhancements (authentication, symmetric 
-encryption, and message integrity) to data sent during the rest of 
-the connection.
-
-The version 2 PCT Handshake Protocol consists of five messages, sent
-respectively by the client, then server, then client, then server, 
-then client, in that order.  (Moreover, under certain circumstances, 
-some or all of the last three messages are omitted.)  The messages 
-are named, in order, CLIENT_HELLO, SERVER_HELLO, CLIENT_MASTER_KEY, 
-SERVER_VERIFY, and CLIENT_VERIFY.
-
-The general contents of these messages depend upon two criteria:  
-how/if a "master key" for the session is to be exchanged, and how/if 
-each of the client and server are to be authenticated.  At least one 
-of the two must be authenticated by some means; authentication of 
-either--or both--may be based on either a key exchange, a digital 
-signature, or (for one of the two) a previously shared "password" 
-key, or, in the case of a connection in the same session as a 
-previous one, on a "master key" shared previously in the session.  
-
-The first criterion is determined by the client and server together:
-first, the CLIENT_HELLO message may contain a request to "reconnect" 
-using a previously shared master key from a particular session (in 
-which case no new key exchange is necessary).  The SERVER_HELLO 
-message will either confirm a requested continuation of the session 
-through the new connection, or require that a new session be 
-initiated, with a new key exchange.  PCT version 2 supports 
-RSA {TM} -based key exchange (see [14], [3]), Diffie-Hellman key 
-exchange (see [4], [15]) and FORTEZZA KEA token key exchange.  The 
-chosen key exchange is used by client and server in the case of a new 
-session to obtain a new shared master key.  This master key is used to 
-derive keys for encryption and message integrity (or "message 
-authentication") for the connection and for other connections 
-associated with the same session.  Note that key exchanges have an 
-implicit associated direction, with a master key being, in effect, 
-sent from one party to the other (literally in the case of RSA key 
-exchange, and more metaphorically in the case of 
-Diffie-Hellman/FORTEZZA KEA key exchange).  Hence a direction must 
-also be chosen for the exchange.  In fact, the parties may agree to 
-perform two key exchanges, one in each direction; in that case, the 
-master key for the session is computed using both of the sent keys.  
-In this document, the term "encrypted master key" refers either to an 
-RSA-encrypted master key, or to the second (typically uncertified) 
-Diffie-Hellman/FORTEZZA KEA public value sent in a Diffie-Hellman or 
-FORTEZZA KEA key exchange.  The key exchange is said to be directed 
-towards the receiver of this encrypted master key.
-
-The second criterion is determined in a similar fashion:  if the
-connection is the first of a new session, then the client may request 
-authentication of the server by key exchange, or by digital signature, 
-or by private password, or by any one of a specified subset of these 
-options.  The client also offers the server a choice among the client 
-authentication options (from among these choices) available.  The 
-server, in turn, selects a preferred authentication method if a choice 
-is offered, and may make a similar request from among the client 
-authentication options offered.  All these authentications are "linked"
-to the key exchange performed during the handshake, so that not only
-the identity of the authenticated party, but also that party's 
-association to the handshake's key exchange as performed, is verified.
-
-If no key exchange is performed, then both client and server are
-authenticated using the shared master key for the reconnected session,
-rather than any of the methods described above.
-
-In addition to key exchange and authentication, the handshake protocol
-performs two other tasks:  negotiation of cryptographic parameters, 
-and handshake verification.  The first is accomplished by the 
-CLIENT_HELLO and SERVER_HELLO messages.  The CLIENT_HELLO includes a
-list of codes for acceptable types of symmetric cipher and 
-cryptographic hash function for use during the session, as well as
-key exchange and signature algorithms, certificate types and 
-certifiers, and authentication methods acceptable for use during the 
-handshake protocol.  The server responds in the SERVER_HELLO message 
-with its choices from among these lists of acceptable types.  The 
-second task is performed during the first authentication; it is based 
-on a cryptographic hash of all the handshake message data passed up to 
-that point.  Verification of this authenticated hash value by its 
-receiver assures that the handshake was not tampered with in transit.  
-
-
-5.1.2  PCT handshake authentication
-
-The four types of authentication permissible in PCT version 2 are
-key-exchange, digital signature, private password, and reconnection.
-Each follows a particular protocol flow, which is essentially 
-independent of which party is being authenticated (except regarding
-the assignment of roles to the client and server).  In each case, 
-client and server both issue random challenges (in the CLIENT_HELLO 
-and SERVER_HELLO messages, respectively); these challenges, and
-all information exchanged up to and including the completion of 
-the key exchange(s), are incorporated into an authentication 
-response by the party being authenticated (the "responder", as 
-opposed to the "challenger", to whom the response is sent).  Hence 
-the authentication response cannot be sent until the sending of both 
-challenges, as well as the key exchange(s), have been completed 
-(although it may appear in the last message which contributes to one 
-of these).
-
-In key-exchange-based authentication, the responder sends a certified 
-public key, which the authenticating party (the "challenger") uses to 
-send a master key.  In the case of Diffie-Hellman/FORTEZZA KEA key 
-exchange, the challenger's value is normally randomly chosen, whereas 
-the responder's is fixed and certified; the master key computed by 
-the challenger can also be derived using the responder's private key 
-and the challenger's sent value.  In the case of RSA key exchange, the 
-master key is randomly chosen at the time of the key exchange by the 
-challenger and encrypted using the responder's certified public key.  
-The responder then combines the received master key (which may first 
-be combined with another sent master key, in the case of two-way key 
-exchange) with all handshake message data sent so far, including both 
-challenges and all of the key exchange data, to compute a response.  
-This response is in the form of a keyed hash, which is verified by the
-challenger to confirm that the responder could derive the master key
-correctly, and therefore holds the correct private key.  (A keyed hash
-is simply the application of a cryptographic hash function to a key 
-and some other input data; the assumed properties of the hash function 
-make the function result for any other data input infeasible to 
-compute for anyone not possessing the key.)
-
-A key-exchange-based authentication therefore has the following 
-message flow:
-
-Challenger              Responder
-----------              ---------
-
-Challenger's            Responder's
-Challenge               Challenge
-
-			[Certified public        
-			key-exchange key]
-
-Random encrypted 
-master key/public
-Diffie-Hellman value
-
-			Keyed hash response
-
-
-The challenges always appear in the CLIENT_HELLO and SERVER_HELLO
-messages.  The certified key may not need to be sent, if the 
-responder already possesses it (perhaps from a previous session).
-				    
-In signature-based authentication, the responder simply sends a 
-certified digital signature public key, accompanied by a digital
-signature, using the associated private key, of a cryptographic hash 
-of all handshake messages up to the one being sent.  (Note that this 
-value is therefore derived from the completed key exchange, as well
-as both challenges).  The challenger verifies the signature using
-the responder's certified public key.  A signature-based 
-authentication has the following message flow:
-
-Challenger              Responder
-----------              ---------
-
-Challenger's            Responder's
-Challenge               Challenge
-
-	Key Exchange(s)
-
-			Certified public
-			signature key,
-			signature response
-
-Again, the challenge messages always appear in the CLIENT_HELLO and 
-SERVER_HELLO messages.  The public key certificate may not be 
-necessary, but is sent regardless, since it can accompany the 
-digital signature in the same message, and therefore has no cost in 
-extra messages.  A certificate-identifying code may be used in its
-place if understood by both parties; see section 6.4.
-
-Password-based authentication is similar to signature-based 
-authentication; the exchanged master key is combined with the
-shared password and all the handshake message data sent so far,
-including the identity of the responder, the exchanged master key 
-and both challenges, to produce a keyed hash response which is sent 
-by the responder and verified by the challenger. 
-
-A special case of this authentication is a doubly-certified 
-Diffie-Hellman key exchange, in which one party  is authenticated by 
-certified Diffie-Hellman key-exchange public key, and the challenger's 
-sent value is not random but rather another certified Diffie-Hellman 
-public key.  In this case, the challenger's identity is represented 
-by the certificate for the public value sent, and the exchanged 
-master key received by the responder is also treated simultaneously 
-as the challenger's password.  (If both parties are to be 
-authenticated by certified Diffie-Hellman key exchange, then each 
-sends a randomly chosen public value to the other, and the final 
-master key is obtained by combining the two keys exchanged.) 
-
-It is recommended that shared private keys used for password-based
-authentication be machine-generated and cryptographically random in 
-the same sense as the master key (see section 6.1.3).  However, 
-because the distribution of password-style shared private keys is
-outside the scope of this protocol, and is therefore vulnerable to 
-possible insecure implementations, the following constraints on 
-password-based authentication are imposed:  
-
-1.  Only one of the client and server, not both, may be 
-authenticated using password-based authentication.
-
-2.  Password-based authentication may only be used if the other party 
-is also authenticated, using either key exchange- or signature-based 
-authentication.
-
-3.  If the other party is authenticated using signature-based 
-authentication, then the password-based authentication response must 
-be sent only after the other party's authentication response has been 
-sent and verified.
-
-These constraints protect poorly chosen password-style shared private 
-keys from off-line brute force attacks.  However, even a well-chosen
-shared private key is vulnerable if not kept strictly confidential
-by both parties sharing it.  Implementations must therefore ensure 
-this confidentiality.  Poorly-chosen or poorly-guarded passwords are
-of course still vulnerable to other attacks.
-
-A password-based authentication has the following message flow:
-
-Challenger              Responder
-----------              ---------
-
-Challenger's            Responder's
-Challenge               Challenge
-
-	Key Exchange(s)
-
-			responder's identity/
-			certified D-H public
-			value, keyed hash response
-
-
-Finally, in the case of authentication based on a master key exchanged
-earlier in the session, the response is computed from both challenges,
-the shared master key, and the session identifier.  (The client's 
-response is in fact implicit; by computing a correct MAC for its first
-data message, the client demonstrates its possession of the session's
-master key.)  This authentication has the following flow:
-
-Challenger              Responder
-----------              ---------
-
-Challenger's            Responder's
-Challenge               Challenge
-
-			keyed hash response
-
-
-5.1.3  Handshake key exchange
-
-In the full handshake protocol, authentications are interleaved with 
-at least one key exchange (and with each other, if both client and 
-server are being authenticated).  The interleaving is designed to 
-compress the authentications and key exchange(s) into as few 
-messages as possible.  For example, a client has the option of 
-sending an encrypted public key and/or (possibly certified) 
-key-exchange public key in the CLIENT_HELLO message, along with its 
-challenge.  The latter allows the client to "receive" a 
-client-directed key exchange, while the former initiates a 
-server-directed key exchange.  However, the client may not have the 
-server's key-exchange public key, and may not anticipate a request for 
-a client-directed key exchange; hence, sending of the encrypted master 
-key and/or client key-exchange certificate may be postponed to the 
-CLIENT_MASTER_KEY message.
-
-In general, each possible key exchange has a "regular" and "quick"
-flow.  A client-directed key exchange may occur beginning in the
-CLIENT_MASTER_KEY message, when the client sends a (possibly 
-certified) key-exchange public key, then continues in the 
-SERVER_VERIFY message with the server sending an encrypted master 
-key.  In the quick version, the client may (or may not) send the 
-(certified) public key in the CLIENT_HELLO message, and the server, 
-upon receiving it (or having received it at some time in the past) 
-sends an encrypted master key in the SERVER_HELLO message.  Similarly, 
-normal server-directed key exchange begins in the SERVER_HELLO message
-with a (possibly certified) key-exchange public key, and continues 
-with an encrypted master key in the following CLIENT_MASTER_KEY 
-message.  In the quick version, the client, having received the 
-server's public key previously, sends an encrypted master key 
-immediately, in the CLIENT_HELLO message.
-
-5.1.4  PCT Handshake Protocol flow
-
-The contents of PCT version 2 handshake protocol can be summarized as
-follows:
-
-The CLIENT_HELLO message contains a random authentication challenge
-to the server and a request for the type and level of cryptography,
-certification, authentication and (if necessary) digital signature
-to be used for the session, if it is to be a new one.  If the client 
-is attempting to continue an old session, then it also supplies that 
-session's identifier.  The client can also send a "quick 
-certificate", in anticipation of a client authentication request from 
-the server, and even a "quick master key", if the client already has 
-a satisfactory server's key-exchange public key.
-
-If the server accepts the old session identifier, then the 
-SERVER_HELLO message contains a response to the client's challenge, 
-and a random connection identifier which doubles as a random challenge
-to the client.  The handshake is then finished (although an 
-authentication of the client is implicit in the MAC included with the 
-client's first data message).  
-
-In the case of a new session, the SERVER_HELLO message contains a
-random connection identifier; this identifier doubles as an 
-authentication challenge to the client if the server desires client 
-authentication.  The server also responds with its choices for type 
-and level of cryptography, certification, authentication and (if 
-necessary) digital signature (from among those offered by the 
-client).  In addition, the server sends a certificate for the type of 
-authentication requested by the client (if any), and sends a "quick 
-master key" and/or "quick response" in response to the client's 
-"quick certificate" and/or "quick master key", respectively, if 
-appropriate.  In the latter case, the response may require an
-accompanying digital signature public-key certificate or "identity
-indicator" (directing the client to the correct shared password), 
-and the handshake protocol completes at this point if no client 
-authentication is required.  
-
-The CLIENT_MASTER_KEY message sent by the client (assuming that it
-is necessary) includes a (possibly certified) key-exchange public key, 
-if requested by the server.  It also contains an encrypted master key,
-if the server sent a key-exchange public key, and an authentication 
-response (accompanied by an identity indicator or digital signature 
-public key certificate, if appropriate) if client authentication by 
-signature or password was requested, and the key exchange has been 
-completed.  If the server's authentication response has also been 
-received (or was not required), then the handshake protocol completes 
-at this point.
-
-The SERVER_VERIFY message sent next by the server, if necessary, 
-contains an encrypted master key sent to the client, if requested,
-and/or an authentication response (possibly accompanied by a digital
-signature public key certificate or identity indicator) to the 
-encrypted master key sent in the previous message.  Unless the former 
-requires an authentication response, the protocol completes at this
-point.
-
-Finally, the CLIENT_VERIFY message, if needed, contains the client's 
-authentication response to the key exchange completed by the 
-encrypted master key sent in the SERVER_VERIFY message. 
-
-Usually the client or server can safely begin sending data records 
-on the underlying transport immediately following its own last 
-handshake message, without waiting for a response even if one is 
-expected.  In most instances, therefore, PCT adds only a single
-round-trip to the connection's setup cost.  Sometimes the cost is
-even less; for instance, a server can begin sending data immediately
-after sending the SERVER_HELLO message if the client initiated a 
-quick server-directed key exchange and only server authentication
-is required, or if a successful reconnection of an established 
-session has occurred (note that in this case the client cannot send 
-data until receiving the SERVER_HELLO message containing the server's 
-challenge).
-
-
-5.2  PCT Handshake messages
-
-PCT version 2 Handshake messages are sent in handshake records, whose
-format is described in section 4.3.1.  These records are sent in the 
-clear (unencrypted), although some of the key-exchange-related fields 
-involve (public-key) encryption.  A single handshake message may span
-across more than one handshake record; however, only data fields 
-associated with four-byte length fields may do so.  These fields are 
-always the last ones in a message; the remaining ones (including all 
-length fields) must be contained within the first handshake record 
-used for the handshake message.  (Note that for PCT version 1 
-compatibility reasions, the CLIENT_HELLO message has no such fields.)
-
-5.2.1 CLIENT_HELLO 
-
-char CH_SESSION_ID_DATA[30]
-char CH_CHALLENGE_DATA[30]
-char CH_CLIENT_VERSION[2]
-char CH_OFFSET[2]
-char CH_CIPHER_LIST_LENGTH[2]
-char CH_HASH_LIST_LENGTH[2]
-char CH_CERT_LIST_LENGTH[2]
-char CH_EXCH_LIST_LENGTH[2]
-char CH_KEY_ARG_LENGTH[2]
-char CH_MSG_LIST_LENGTH[2]
-char CH_SIG_LIST_LENGTH[2]
-char CH_CERTIFIER_LIST_LENGTH[2]
-char CH_QUICK_PUBLIC_VALUE_LENGTH[2]
-char CH_QUICK_SERVER_PUBLIC_VALUE_LENGTH[2]
-char CH_QUICK_ENCRYPTED_KEY_LENGTH[2]
-char CH_AUTH_OPTIONS[2]
-char CH_CIPHER_LIST_DATA[([0] << 8)|[1]]
-char CH_HASH_LIST_DATA[([0] << 8)|[1]]
-char CH_CERT_LIST_DATA[([0] << 8)|[1]]
-char CH_EXCH_LIST_DATA[([0] << 8)|[1]]
-char CH_KEY_ARG_DATA[([0] << 8)|[1]]
-char CH_MSG_LIST_DATA[([0] << 8)|[1]]
-char CH_SIG_LIST_DATA[([0] << 8)|[1]]
-char CH_CERTIFIER_LIST_DATA[([0] << 8)|[1]]
-char CH_QUICK_PUBLIC_VALUE_DATA[([1] << 8)|[1]]
-char CH_QUICK_SERVER_PUBLIC_VALUE_DATA[([0] << 8)|[1]]
-char CH_QUICK_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
-
-When a client first connects to a server it is required to send the
-CLIENT_HELLO message.  The server is expecting this message from the
-client as its first message. It is an ILLEGAL_MESSAGE error for a
-client to send anything else as its first message.  The CLIENT_HELLO
-message begins with two fixed-length fields followed by a two-byte 
-version number and an offset to the variable length data.  The 
-version number field CH_CLIENT_VERSION is always set to 
-PCT_VERSION_V2 in PCT version 2.  The CH_OFFSET field contains the 
-number of bytes used by the various fields (length fields plus the 
-AUTH_OPTIONS field) that follow the offset field and precede the 
-variable-length fields.  For PCT version 2, this offset value is 
-always PCT_CH_OFFSET_V2, i.e., 24.  However, inclusion of this field 
-will allow future versions to be compatible with version 2, even if 
-the number of these fields changes, just as inclusion of this field 
-helps make PCT version 2 CLIENT_HELLO messages understandable to PCT 
-version 1 servers.
-
-The CH_CHALLENGE_DATA field is a string of 30 bytes of random bits, to
-be used as authentication challenge data from the client.  The 
-CHALLENGE_DATA should be cryptographically random, in the same sense 
-as the MASTER_KEY (see section 6.1.3).  If the client finds a 
-session identifier in its cache for the server, then that 
-session-identifier data is sent in the field CH_SESSION_ID_DATA.  
-Otherwise, the special PCT_SESSION_ID_NONE value is used.  In either 
-case, the client specifies in CIPHER_LIST_DATA, HASH_LIST_DATA,
-EXCH_LIST_DATA and SIG_LIST_DATA its preferred choices of symmetric 
-cipher, key lengths, hash function, asymmetric key exchange algorithm
-and digital signature algorithm.  However, if a session identifier is 
-sent, then these choices are only relevant in the case where the 
-server cannot recognize the session identifier, and a new session 
-must therefore be initiated.  If the server recognizes the session, 
-then these fields are ignored by the server.  Similarly, if the 
-client requires server authentication in the event of a new session 
-initiation, then the CERT_LIST_DATA and CERTIFIER_LIST_DATA lists 
-contain the client's preferred choices of certificate type and 
-certifier; otherwise, these lists are empty, and their length is 
-zero.  Finally, the MSG_LIST_DATA list contains a list of data
-message types (other than the DM_TYPE_USER_DATA) supported by the 
-client; if the client supplies a session identifier and the server
-recognizes it, then this list is ignored, and the list negotiated
-previously in the session is used instead.
-
-The AUTH_OPTIONS field contains the values of twelve flags that 
-determine the flow of the remainder of the protocol if a new session 
-is being initiated.  The flags are associated with the twelve 
-low-order bits of the AUTH_OPTIONS field, and are named, in order 
-(from least to most significant bit), as follows:
-
-CH_DEMAND_KEY_EXCH_SEND     :=  0x0001
-CH_DEMAND_AUTH_KEY_EXCH     :=  0x0002
-CH_DEMAND_AUTH_SIG          :=  0x0004 
-CH_DEMAND_AUTH_PASSWORD     :=  0x0008 
-CH_OFFER_KEY_EXCH_RECEIVE   :=  0x0010
-CH_OFFER_AUTH_KEY_EXCH      :=  0x0020
-CH_OFFER_AUTH_SIG           :=  0x0040 
-CH_OFFER_AUTH_PASSWORD      :=  0x0080
-CH_REQUEST_RECONNECT        :=  0x0100
-CH_REQUEST_CLOSURE_MON      :=  0x0200
-CH_REQUEST_REDO_ENABLE      :=  0x0400
-CH_OFFER_CERTIFIER_TRYOUT   :=  0x0800
-
-If the CH_DEMAND_KEY_EXCH_SEND flag is set to one, then the client
-requires that the server accept an encrypted master key from the 
-client as part of the key exchange.  If the CH_OFFER_KEY_EXCH_RECEIVE 
-flag is set to one, then the client is willing to receive an encrypted 
-master key from the server as part of the key exchange.  If both flags
-are set, then both conditions hold; the client requires that the 
-server receive a key exchange, and will also accept one, at the 
-server's option.  In the case of uncertified Diffie-Hellman/FORTEZZA 
-KEA key exchange, the flags simply refer to the "receiver" sending the 
-public value first, followed by the "sender"; in other cases, the 
-holder of the private key associated with the RSA public key or 
-certified Diffie-Hellman/FORTEZZA KEA public value is always the 
-"receiver".  (Doubly certified Diffie-Hellman/FORTEZZA KEA key 
-exchange is discussed in section 5.1.2.)  Note that both client and 
-server are assumed willing to be the (possibly sole) sender of an 
-encrypted master key; hence, even if the CH_DEMAND_KEY_EXCH_SEND flag 
-is set to zero, and the CH_OFFER_KEY_EXCH_RECEIVE flag is set to one, 
-the client has neither ruled out being the sender, nor demanded to be 
-the receiver, of an encrypted master key.  
-
-The six AUTH flags refer to types of authentication:  the client
-requires the server to authenticate by one of the means for which the
-associated CH_DEMAND_AUTH flag is set to one, and offers to 
-authenticate itself, at the server's option, by any of the means for 
-which the associated CH_OFFER_AUTH flag is set to one.  (The
-abbreviations "KEY_EXCH", "SIG" and "PASSWORD" stand for 
-key-exchange-based, digital signature-based and shared password-based
-authentication, respectively.)  The settings of the flags must be
-consistent with at least one key exchange and one authentication 
-occurring; i.e., at least one of the six authentication flags and at 
-least one of the two key exchange flags must be set to one.  Moreover,
-the constraints on password-based authentication must be obeyed.  (See
-sections 5.1.2 and 7.2.)
-
-The CH_REQUEST_RECONNECT flag indicates, when set to one, that the 
-client is requesting that the current connection be part of an 
-existing session; in this case, the CH_SESSION_ID field must contain
-that session's identifier.  The CH_REQUEST_CLOSURE_MON flag 
-indicates, when set to one, that the client wishes the current session 
-to be closure-monitored (see section 4.4.3).  The 
-CH_REQUEST_REDO_ENABLE flag indicates, when set to one, that the 
-client wishes the current session to be redo-enabled (see section 
-4.4.4).  Finally, the CH_OFFER_CERTIFIER_TRYOUT flag indicates, when
-set to one, that the list of acceptable certifiers in 
-CH_CERTIFIER_LIST is not exhaustive (see below).
- 
-The CIPHER_LIST_DATA field contains a list of possible symmetric
-ciphers supported by the client, in order of (the client's)
-preference.  Each element in the list is a four-byte field, of which
-the first two bytes contain a code representing a cipher type, the
-third byte contains the encryption key length in bits (0-255), and the
-fourth byte contains the MAC key length in bits, minus 64 (values
-0-255, representing lengths 64-319; this encoding enforces the
-requirement that the MAC key length be at least 64 bits).  The entire
-list's length in bytes (four times the number of elements) is placed
-in CIPHER_LIST_LENGTH.
-
-The HASH_LIST_DATA field contains a list of possible hash functions
-supported by the client, in order of (the client's) preference.  The
-server will choose one of these to be used for computing MACs and
-deriving keys.  Each element in the list is a two-byte field
-containing a code representing a hash function choice.  The entire
-length of the list (twice the number of elements) is placed in
-HASH_LIST_LENGTH.
-
-The CERT_LIST_DATA field contains a list of possible certificate
-formats supported by the client, in order of (the client's)
-preference.  Each element in the list is a two-byte field containing a
-code representing a certificate format.  The entire length of the list
-(twice the number of elements) is placed in CERT_LIST_LENGTH.
-
-The EXCH_LIST_DATA field contains a list of possible asymmetric key
-exchange algorithms supported by the client, in order of (the
-client's) preference.  Each element in the list is a two-byte field
-containing a code representing a key exchange algorithm type.  The 
-entire length of the list (twice the number of elements) is placed 
-in EXCH_LIST_LENGTH.
-
-The KEY_ARG_DATA field contains an initialization vector to be used in
-a reconnected session when the cipher type is a block cipher (see 
-section 6.1.5).  If a new session is being requested (i.e., if the 
-CH_REQUEST_RECONNECT flag is set to zero), then KEY_ARG_LENGTH must 
-be zero.
-
-The MSG_LIST_DATA field contains a list of data message types (other
-than DM_TYPE_USER_DATA) supported by the client.  Each element in the
-list is a two-byte field containing a code representing a data message
-type.  The entire length of the list (twice the number of elements) is
-placed in MSG_LIST_LENGTH.
-
-The SIG_LIST_DATA field contains a list of possible signature 
-algorithms supported by the client, in order of (the client's) 
-preference.  Each element in the list is a two-byte field containing 
-a code representing a signature algorithm type.  The entire length 
-of the list (twice the number of elements) is placed in 
-SIG_LIST_LENGTH.
-
-The CERTIFIER_LIST_DATA field contains a list of identifiers of 
-possible certificate sources recognized by the client, in order of 
-(the client's) preference.  Each element in the list is a 
-zero-delimited string.  The entire length of the list is placed in 
-CERTIFIER_LIST_LENGTH.  A client may indicate, by setting the 
-CH_OFFER_CERTIFIER_TRYOUT flag to one, that the certifier list does
-not imply rejection of all other certifiers; for example, the client
-may provide an abbreviated (or even empty) certifier list to avoid 
-constructing an exhaustive list of accepted certifiers, or may lack 
-a naming convention for certifiers known to be compatible with that 
-of the server.  The client may still in that case reject a 
-certificate offered by the server.
-
-The CH_QUICK_PUBLIC_VALUE_DATA field may, at the client's option, 
-contain a (possibly certified) key-exchange public key.  If the 
-field is non-empty, then the CH_OFFER_KEY_EXCH_RECEIVE flag must 
-be set to one.  If the CH_OFFER_AUTH_KEY_EXCH flag is also set to 
-one, then the CH_QUICK_PUBLIC_VALUE_DATA field, if non-empty, 
-contains a certificate (including key-exchange public key); otherwise 
-the field, if non-empty, contains an uncertified key exchange public 
-value.  The exact format of this field is described in section 
-6.1.2.  If the client expects the server to demand client 
-authentication by key exchange, then this public key/certificate may 
-expedite the expected key exchange/authentication; however, the server
-may still indicate in the subsequent SERVER_HELLO message that a 
-public key or certificate of another type (or from a different 
-certifier) is required.
-
-The CH_QUICK_SERVER_PUBLIC_VALUE_DATA and CH_QUICK_ENCRYPTED_KEY_DATA 
-fields may, at the client's option, contain, respectively, the public
-value from a key-exchange public key certificate attributed to the 
-server, and an encrypted master key (or Diffie-Hellman/FORTEZZA KEA 
-public value) decryptable by the holder of the private key associated 
-with the certified key-exchange public key.  The format of these 
-fields is described in section 6.1.2.  If the client already 
-possesses a certified key-exchange public key belonging to the server,
-then use of these fields will expedite the resulting key exchange.  
-However, in unusual circumstances, the server may still "disavow" the 
-key exchange--that is, refuse to receive it, and offer only some 
-other key exchange type, direction or certificate.  (For example, the 
-public key used by the client may be incorrect or out-of-date.)  Note 
-that if these fields are used by the client, then the 
-CH_REQUEST_KEY_EXCH_SEND flag must be set to one.  
-
-The server, on receiving a CLIENT_HELLO message, checks the version
-number and the offset field to determine where the variable-length
-data fields start.  (The OFFSET value should be at least
-PCT_CH_OFFSET_V2 for versions 2 and higher.)  The server then checks 
-whether the CH_REQUEST_RECONNECT flag is set to one, and if so, 
-whether it recognizes the SESSION_ID.  In that case, the server 
-responds with a SERVER_HELLO message with the SH_ACCEPT_RECONNECT 
-flag set, and the appropriate values (see below) in the RESPONSE and 
-CONNECTION_ID fields.  
-
-Otherwise, it examines the CIPHER_LIST and HASH_LIST lists in the 
-CLIENT_HELLO message to select a cipher and hash function.  The 
-server also examines the AUTH_OPTIONS flags and CERT_LIST, 
-CERTIFIER_LIST, SIG_LIST and EXCH_LIST lists to select a key 
-exchange type and direction(s) and an authentication combination for 
-itself (including authentication type, certificate type and 
-certifier) which is acceptable to both the client and the server, if 
-one or more of the CH_DEMAND_AUTH flags were set.  Finally, the 
-server examines the same lists to choose a sublist from each with 
-which it is compatible, if it requires client authentication as well.  
-If such selections are possible, then the server sends a SERVER_HELLO 
-message to the client as described below; otherwise, the server 
-detects a SPECS_MISMATCH error.   The server also examines the quick
-key-exchange public value (if sent) for compatibility, and/or 
-decrypts the quick encrypted master key, if possible.
-
-
-5.2.2 SERVER_HELLO  
-
-char SH_SERVER_VERSION[2]
-char SH_AUTH_OPTIONS[2]
-char SH_CIPHER_SPECS_DATA[4]
-char SH_HASH_SPECS_DATA[2]
-char SH_EXCH_SPECS_DATA[2]
-char SH_CONNECTION_ID_DATA[30]
-char SH_SESSION_ID_DATA[30]
-char SH_ALT_CIPHER_LIST_LENGTH[2]
-char SH_ALT_HASH_LIST_LENGTH[2]
-char SH_MSG_LIST_LENGTH[2]
-char SH_EXCH_LIST_LENGTH[2]
-char SH_CERT_LIST_LENGTH[2]
-char SH_SIG_LIST_LENGTH[2]
-char SH_QUICK_ENCRYPTED_KEY_LENGTH[2]
-char SH_RESPONSE_LENGTH[2]
-char SH_CERTIFIER_LIST_LENGTH[4]
-char SH_PUBLIC_VALUE_LENGTH[4]
-char SH_SIG_CERT_LENGTH[4]
-char SH_ALT_CIPHER_LIST_DATA[([0] << 8)|[1]]
-char SH_ALT_HASH_LIST_DATA[([0] << 8)|[1]]
-char SH_MSG_LIST_DATA[([0] << 8)|[1]]
-char SH_EXCH_LIST_DATA[([0] << 8)|[1]]
-char SH_CERT_LIST_DATA[([0] << 8)|[1]]
-char SH_SIG_LIST_DATA[([0] << 8)|[1]]
-char SH_QUICK_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
-char SH_RESPONSE_DATA[([0] << 8)|[1]]
-char SH_CERTIFIER_LIST_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-char SH_PUBLIC_VALUE_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-char SH_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-
-The server sends this message after receiving the client's
-CLIENT_HELLO message.  The PCT version number in SH_SERVER_VERSION 
-is always the maximum protocol version that the server supports; the 
-remainder of the SERVER_HELLO message and all subsequent messages 
-will conform to the format specified by the protocol version 
-corresponding to the minimum of the client and server protocol 
-version numbers, as indicated by the CH_CLIENT_VERSION and 
-SH_SERVER_VERSION fields.  Unless there is an error, the server always 
-returns a random value 30 bytes in length in the CONNECTION_ID field.  
-This value doubles as challenge data if the server requests client 
-authentication, and should therefore be random in the same sense as 
-the challenge data in the CLIENT_HELLO message.
-
-The SH_AUTH_OPTIONS field contains twelve flags, associated with the
-twelve low-order bits of the SH_AUTH_OPTIONS field; they are named,
-in order (from least to most significant bit), as follows:
-
-SH_ACCEDE_KEY_EXCH_RECEIVE  :=  0x0001
-SH_ACCEDE_AUTH_KEY_EXCH     :=  0x0002
-SH_ACCEDE_AUTH_SIG          :=  0x0004 
-SH_ACCEDE_AUTH_PASSWORD     :=  0x0008 
-SH_ACCEPT_KEY_EXCH_SEND     :=  0x0010
-SH_ACCEPT_AUTH_KEY_EXCH     :=  0x0020
-SH_ACCEPT_AUTH_SIG          :=  0x0040 
-SH_ACCEPT_AUTH_PASSWORD     :=  0x0080
-SH_ACCEPT_RECONNECT         :=  0x0100
-SH_ACCEPT_CLOSURE_MON       :=  0x0200
-SH_ACCEPT_REDO_ENABLE       :=  0x0400
-SH_OFFER_CERTIFIER_TRYOUT   :=  0x0800
-
-The SH_ACCEPT_CLOSURE_MON flag is set to one if and only if the 
-CH_REQUEST_CLOSURE_MON flag is set to one, and the server also 
-prefers the current connection to be closure-monitored (see section
-4.4.3).  The SH_ACCEPT_REDO_ENABLE flag is set to one if and only if
-the CH_REQUEST_REDO_ENABLE flag is set to one, and the server also
-prefers the current connection to be redo-enabled (see section 4.4.4).
-
-If the server recognizes the contents of the CH_SESSION_ID_DATA 
-field of the CLIENT_HELLO message as session identifier for a session
-for which the master key is still available to the server, then the
-SH_ACCEPT_RECONNECT flag in the SH_AUTH_OPTIONS field is set to one.
-Also, the SH_SESSION_ID_DATA field echoes the CH_SESSION_ID_DATA 
-field.  Moreover, the server sets the CIPHER_SPECS_DATA and 
-HASH_SPECS_DATA fields to the values stored along with the session 
-identifier.  There are two subcases:  (1) If the SH_EXCH_SPECS_DATA 
-value does not refer to a TOKEN type (see section 6.1), then the 
-CLIENT_MAC, SERVER_MAC, CLIENT_WRITE, and SERVER_WRITE keys are 
-rederived using the MASTER_KEY from the old session, as well as the 
-CONNECTION_ID and CH_CHALLENGE values from the SERVER_HELLO and 
-CLIENT_HELLO messages, respectively, for this connection.  (2) If the 
-SH_EXCH_SPECS_DATA refers to a TOKEN type, then the keys from the 
-ongoing session continue to be used.  In order to obtain fresh key 
-material or reset the sequence number, TOKEN implementations must use 
-the redo handshake mechanism (KM_REDO_HANDSHAKE key management 
-message), or else not request (or not accept) reconnections of an 
-established session.  When this mechanism is used with a TOKEN 
-exchange type, the client must set the CH_REQUEST_RECONNECT flag to
-one and send PCT_SESSION_ID_NONE in the CH_SESSION_ID_DATA field of 
-the subsequent CLIENT_HELLO message.  (See section 4.4.4.)
-
-In the case of a reconnection, all the remaining data fields are 
-empty except for SH_RESPONSE_DATA, whose contents are described in 
-section 7.2.  Also, all of the flags in SH_AUTH_OPTIONS are set to 
-zero except SH_ACCEPT_RECONNECT and possibly SH_ACCEPT_CLOSURE_MON 
-and/or SH_ACCEPT_REDO_ENABLE.
-       
-If the server does not recognize the session identifier provided by
-the client (or if the CH_REQUEST_RECONNECT flag was set to zero), 
-then the server sets the SH_ACCEPT_RECONNECT flag to zero in the 
-SH_AUTH_OPTIONS field.  A unique session identifier (which must not 
-equal PCT_SESSION_ID_NONE) is also placed in the SH_SESSION_ID_DATA 
-field; this value need not be cryptographically random, but values 
-should not be used repeatedly (a continually increasing counter, for 
-instance, would be sufficient).  The server then selects any choice 
-with which it is compatible, from each of the CH_CIPHER_LIST, 
-CH_HASH_LIST and CH_EXCH_LIST lists supplied in the CLIENT_HELLO 
-message.  (These values are returned to the client in the 
-SH_CIPHER_SPECS_DATA, SH_HASH_SPECS_DATA and SH_EXCH_SPECS_DATA 
-fields, respectively.)  If no cipher type (respectively, hash type, 
-key exchange type) from the CH_CIPHER_LIST (respectively, 
-CH_HASH_LIST, CH_EXCH_LIST) is acceptable to the server, then a 
-SPECS_MISMATCH error occurs.
-
-Alternate cipher and hash types from CH_CIPHER_LIST and CH_HASH_LIST, 
-respectively, with which the server is compatible may be placed in the 
-SH_ALT_CIPHER_LIST and SH_ALT_HASH_LIST lists (whose formats are 
-identical to those of CH_CIPHER_LIST and CH_HASH_LIST, respectively); 
-these lists can then be used by the client in determining whether 
-pre-encrypted, pre-MAC'd data will be understandable to the server.  
-(Filling these lists is optional for the server; an empty list simply 
-means that the client has no assurance that the server supports any 
-cipher or hash type other than the one selected for the session.)  
-Finally, the SH_MSG_LIST list contains a list of those data message 
-types from CH_MSG_LIST which the server also supports; the format of 
-the two message type lists is identical.
-
-The server also examines the CH_AUTH_OPTIONS flags to select server 
-authentication and key exchange options acceptable to both (as 
-indicated by the CH_AUTH_OPTIONS flags and the server's own 
-requirements/compatibilities), and to offer a set of acceptable
-client authentication options.  In particular, these must include a 
-server authentication type if any of the CH_DEMAND_AUTH flags is set 
-to one, at least one client authentication type if client 
-authentication is required by the server, and a key exchange 
-direction (or two) acceptable to both client and server, as indicated 
-by the CH_DEMAND_KEY_EXCH_SEND and CH_OFFER_KEY_EXCH_RECEIVE flags 
-and the server's own requirements.  (The restrictions on 
-password-based authentication must also be obeyed; see section 5.1.2.)
-If no such set of types is available that is acceptable to both client
-and server, then a SPECS_MISMATCH error occurs.  If at least one such 
-set of types is found, then the server sets the associated flags in 
-SH_AUTH_OPTIONS (at most one SH_ACCEDE_AUTH flag and at least one 
-SH_ACCEDE/ACCEPT_KEY_EXCH flag); these determine the type of server 
-authentication to be performed, if any, and the direction of the key 
-exchange(s), as well as the set of client authentication options 
-acceptable to the server.  The type of the key exchange(s) (they must 
-both be of the same type, if there are two) is selected by the server,
-and indicated by the code in the SH_EXCH_SPECS field.
-
-If the server requires client authentication, then the server also
-selects those choices from the CH_SIG_LIST, CH_CERT_LIST and 
-CH_CERTIFIER_LIST lists that are also acceptable 
-CH_OFFER_CERTIFIER_TRYOUT is set to one).  These server-selected 
-lists are placed in the SH_SIG_LIST_DATA, SH_CERT_LIST_DATA and 
-SH_CERTIFIER_LIST_DATA fields, respectively; their format is 
-identical to those of the corresponding fields in the CLIENT_HELLO 
-message.  If the server does not require client authentication, then 
-the SH_SIG_LIST, SH_CERT_LIST and SH_CERTIFIER_LIST fields are 
-empty, and their length is zero.  The server may also, like the 
-client, demand certificate-based authentication but set the 
-SH_OFFER_CERTIFIER_TRYOUT flag to one.  In this case, the server 
-simply reserves the right to reject certificates from unacceptable 
-certifiers, and its list of acceptable ones is not assumed 
-exhaustive.
-
-If the SH_ACCEDE_KEY_EXCH_RECEIVE flag is set to one and the
-CH_QUICK_SERVER_CERT field is either empty or contains an 
-incorrect public value, then the SH_PUBLIC_VALUE_DATA field contains 
-a (possibly certified) key-exchange public key of a type compatible 
-with the chosen key exchange type specified in the 
-SH_EXCH_SPECS_DATA field.  If, moreover, the 
-SH_ACCEDE_AUTH_KEY_EXCH flag is set to one, then the key-exchange 
-public key is contained in a certificate whose type and certifier 
-are found in the CH_CERT_LIST and CH_CERTIFIER_LIST lists, 
-respectively (if CH_CERTIFIER_LIST is non-empty).  Otherwise, the 
-public key is uncertified.  The format of the SH_PUBLIC_VALUE_DATA
-field is described in section 6.1.2.  If the 
-SH_ACCEDE_KEY_EXCH_RECEIVE flag is set to zero, then the 
-SH_PUBLIC_VALUE_DATA field is empty, and its length is zero.
-
-If the client sent an acceptable key-exchange public key certificate
-in the CH_QUICK_PUBLIC_VALUE field of the CLIENT_HELLO message, then 
-the server responds with an RSA-encrypted master key (or randomly 
-chosen Diffie-Hellman/FORTEZZA KEA public value) in the 
-SH_QUICK_ENCRYPTED_KEY field of the SERVER_HELLO message.  (The 
-format of this field is described in section 6.1.2.)
-
-If the client sent an acceptable certified server key-exchange 
-public key and encrypted master key in the CH_QUICK_SERVER_CERT and 
-CH_QUICK_ENCRYPTED_KEY fields of the CLIENT_HELLO message, and if the 
-SH_ACCEPT_KEY_EXCH_SEND flag in the SH_AUTH_OPTIONS field is set to
-zero, then the key exchange is completed, and the server must place an
-authentication response, constructed as described in section 7.2, in 
-SH_RESPONSE_DATA if one of the CH_DEMAND_AUTH flags is set to one.  If 
-the SH_ACCEDE_AUTH_SIG flag is set to one, then the SH_SIG_CERT_DATA 
-field contains a certified digital signature public key acceptable to 
-the client (as indicated by the CH_SIG_LIST, CH_CERT_LIST and 
-CH_CERTIFIER_LIST lists), in the format of a PUBLIC_VALUE field of
-type PV_CERTIFICATE (see section 6.1.2).  If the 
-SH_ACCEDE_AUTH_PASSWORD flag is set to one, then an identity indicator 
-(such as an account identifier or, in the case of doubly certified 
-Diffie-Hellman key exchange, a certificate for the Diffie-Hellman 
-public value supplied by the server in the key exchange) is placed in 
-the SH_SIG_CERT_DATA field.  Otherwise the SH_SIG_CERT_DATA field is 
-empty, and its length is zero.  
-
-When the client receives a SERVER_HELLO message, it checks whether the
-server has accepted a reconnection of an old session or is
-establishing a new session.  If the session is an old one, then the 
-client establishes the new CLIENT_WRITE_KEY, SERVER_WRITE_KEY, 
-CLIENT_MAC_KEY and SERVER_MAC_KEY according to the cipher-specific 
-rules described in section 6.1.4.  The client then checks the 
-contents of the RESPONSE_DATA field in the SERVER_HELLO message for 
-correctness.  If the response exactly matches the value calculated by 
-the client (following the procedures in sections 7.1 and 7.2), then 
-the handshake is finished, and the client proceeds to the 
-CLIENT_MASTER_KEY messsage, if necessary, or else begins sending 
-data; otherwise, a SERVER_AUTH_FAILED error occurs.
-
-If a new session is being initiated, the client records the chosen
-cipher, hash, key exchange and signature types, and the lists of
-alternate cipher and hash types and supported data message types.
-If certificate-based client authentication is required the client 
-checks the list of certificate types and certifiers to see if it has
-a satisfactory certificate; lack of one results in a SPECS_MISMATCH
-error.  If an acceptable quick encrypted master key was sent, the 
-client decrypts the master key for use in obtaining a MAC_KEY and 
-WRITE_KEY for each transmission direction as described in section 
-6.1.4.  Finally, if a non-empty RESPONSE_DATA field was included, then
-the client checks it for correctness.   If it exactly matches the 
-value calculated by the client (following the procedures in sections 
-7.1 and 7.2), then the client proceeds to the CLIENT_MASTER_KEY 
-handshake message (or, if the handshake is completed, begins sending 
-data); otherwise, a SERVER_AUTH_FAILED error occurs.
-
-
-5.2.3 CLIENT_MASTER_KEY 
-
-char CMK_ENCRYPTED_KEY_LENGTH[2]
-char CMK_RESPONSE_LENGTH[2]
-char CMK_SIG_CERT_LENGTH[4]
-char CMK_PUBLIC_VALUE_LENGTH[4]
-char CMK_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
-char CMK_RESPONSE_DATA[([0] << 8)|[1]]
-char CMK_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-char CMK_PUBLIC_VALUE_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-
-The client sends this message after receiving the SERVER_HELLO message
-from the server if not all the key exchanges and authentications (as
-indicated by the SH_AUTH_OPTIONS field) have yet been completed.
-
-If SH_ACCEPT_AUTH_SIG is set to one, and no other client 
-authentication option is both acceptable to the server and preferred
-by the client, then CMK_SIG_CERT_DATA contains a certified digital 
-signature public key acceptable to the server (as indicated by the 
-(SH_CERT_LIST, SH_CERTIFIER_LIST and SH_SIG_LIST lists), in the form 
-of a PUBLIC_VALUE field of type PV_CERTIFICATE (see section 6.1.2).  
-If SH_ACCEPT_AUTH_PASSWORD is set to one, then CMK_SIG_CERT_DATA 
-contains an identity indicator (such as an account identifier, or, in 
-the case of doubly certified Diffie-Hellman key exchange, a 
-certificate for the Diffie-Hellman public value supplied by the 
-server in the key exchange).  Otherwise the CMK_SIG_CERT_DATA field 
-is empty, and its length is zero.
-
-If SH_ACCEPT_KEY_EXCH_SEND is set to one, and an acceptable 
-encrypted master key has not already been sent in the 
-SH_QUICK_ENCRYPTED_KEY field of the SERVER_HELLO message, then 
-CMK_PUBLIC_VALUE_DATA contains an RSA key exchange public key or 
-Diffie-Hellman/FORTEZZA KEA public value.  If 
-SH_ACCEPT_AUTH_KEY_EXCH is set to one, and no other client 
-authentication option is both acceptable to the server and preferred
-by the client, then this public value is contained in a certificate 
-acceptable to the server (as indicated by the SH_EXCH_SPECS_DATA 
-field and the SH_CERT_LIST and SH_CERTIFIER_LIST lists); otherwise, 
-the value is uncertified.  If the SH_ACCEPT_KEY_EXCH_SEND flag is set 
-to zero, or if an acceptable encrypted master key was sent in the 
-SERVER_HELLO message, then CMK_PUBLIC_VALUE_DATA is empty.  
-
-If SH_ACCEDE_KEY_EXCH_RECEIVE is set to one, and if 
-SH_PUBLIC_VALUE_DATA was not empty (indicating that the contents of 
-the CH_QUICK_ENCRYPTED_KEY field in the CLIENT_HELLO message were 
-either absent or not acceptable), then CMK_ENCRYPTED_KEY contains an 
-RSA-encrypted master key (or randomly chosen Diffie-Hellman/FORTEZZA 
-KEA public value); see section 6.1.2.  If SH_ACCEDE_KEY_EXCH_RECEIVE 
-is set to one, or if SH_PUBLIC_VALUE_DATA is empty, then 
-CMK_ENCRYPTED_KEY is empty, with length zero.
-
-If all key exchanges are completed by the sending of the 
-CLIENT_MASTER_KEY message, and if one of the SH_ACCEPT_AUTH flags is 
-set to one, then the contents of the CMK_RESPONSE field are as 
-described in section 7.2; otherwise, this field is empty, and its 
-length is zero.
-
-Upon receiving a CLIENT_MASTER_KEY message, the server verifies the
-certificates and/or authentication response, if they are required; 
-errors in any of these result in a BAD_CERTIFICATE or 
-CLIENT_AUTH_FAILED error, respectively.  If an encrypted master key 
-was sent, the server decrypts the master key for use in obtaining a 
-MAC_KEY and WRITE_KEY for each transmission direction as described in
-section 6.1.4.  The server then proceeds to the SERVER_VERIFY 
-message, if necessary, or else begins transmitting data.
-
-
-5.2.4 SERVER_VERIFY 
-
-char SV_ENCRYPTED_KEY_LENGTH[2]
-char SV_RESPONSE_LENGTH[2]
-char SV_SIG_CERT_LENGTH[4]
-char SV_ENCRYPTED_KEY_DATA[([0] << 8)|[1]]
-char SV_RESPONSE_DATA[([0] << 8)|[1]]
-char SV_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-
-The server sends this message upon receiving a valid CLIENT_MASTER_KEY
-message from the client, if not all key exchanges and authentications
-have been completed.
-
-If SH_SIG_CERT_DATA was empty, and either SH_ACCEDE_AUTH_SIG or 
-SH_ACCEDE_AUTH_PASSWORD is set to one, then the SV_SIG_CERT_DATA 
-field must not be empty.  If SH_ACCEDE_AUTH_SIG is set to one, 
-then SV_SIG_CERT_DATA must contains a certified digital signature 
-public key acceptable to the client (as indicated by the 
-(CH_SIG_LIST, CH_CERT_LIST and CH_CERTIFIER_LIST lists), in the form
-of a PUBLIC_VALUE field of type PV_CERTIFICATE (see section 6.1.2).  
-If SH_ACCEPT_AUTH_PASSWORD is set to one, then SV_SIG_CERT_DATA 
-contains an identity indicator (such as an account identifier, or, in 
-the case of doubly certified Diffie-Hellman key exchange, a 
-certificate for the Diffie-Hellman public value supplied  by the 
-server in the key exchange).  Otherwise the SV_SIG_CERT_DATA field is 
-empty, and its length is zero.
-
-If SH_ACCEPT_KEY_EXCH_SEND is set to one, and if 
-CMK_PUBLIC_VALUE_DATA was not empty (indicating that the contents of 
-the SH_QUICK_ENCRYPTED_KEY field in the SERVER_HELLO message were 
-either absent or not acceptable), then SV_ENCRYPTED_KEY contains an 
-RSA-encrypted master key (or randomly chosen Diffie-Hellman/FORTEZZA 
-KEA public value).  The format of this field is described in section
-6.1.2.  If SH_ACCEPT_KEY_EXCH_SEND is set to one, or if 
-CMK_PUBLIC_VALUE is empty, then SV_ENCRYPTED_KEY is empty, with 
-length zero.
-
-If one of the SH_ACCEPT_AUTH flags is set to one, then the contents 
-of the SV_RESPONSE field are as described in section 7.2; otherwise, 
-this field is empty, and its length is zero.
-
-Upon receiving the SERVER_VERIFY message, the client verifies the
-certificates and/or authentication response, if they are required; 
-errors in any of these result in a BAD_CERTIFICATE or 
-SERVER_AUTH_FAILED error, respectively.  If an encrypted master key 
-was sent, the client decrypts the master key for use in obtaining a 
-MAC_KEY and WRITE_KEY for each transmission direction as described 
-in section 6.1.4.  The client then proceeds to the CLIENT_VERIFY 
-message, if necessary, or else begins transmitting data.
-
-
-5.2.5 CLIENT_VERIFY 
-
-char CV_RESPONSE_LENGTH[2]
-char CV_SIG_CERT_LENGTH[4]
-char CV_RESPONSE_DATA[([0] << 8)|[1]]
-char CV_SIG_CERT_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-
-The client sends this message upon receiving a valid SERVER_VERIFY
-message from the client, if client authentication has not been 
-completed.  This message is never necessary unless 
-SH_ACCEPT_KEY_EXCH_SEND was set to one.
-
-If either SH_ACCEDE_AUTH_SIG or SH_ACCEDE_AUTH_PASSWORD is set to one, 
-then the CV_SIG_CERT_DATA  field must not be empty.  If 
-SH_ACCEDE_AUTH_SIG is set to one, then CV_SIG_CERT_DATA must contain
-a certified digital signature public key acceptable to the server (as 
-indicated by the (SH_SIG_LIST, SH_CERT_LIST and SH_CERTIFIER_LIST 
-lists), in the form of a PUBLIC_VALUE field of type PV_CERTIFICATE 
-(see section 6.1.2).  If SH_ACCEPT_AUTH_PASSWORD is set to one, then 
-CV_SIG_CERT_DATA contains an identity indicator (such as an account 
-identifier, or, in the case of doubly certified Diffie-Hellman key 
-exchange, a certificate for the Diffie-Hellman public value supplied 
-by the server in the key exchange).  Otherwise the CV_SIG_CERT_DATA 
-field is empty, and its length is zero.  The contents of the 
-CV_RESPONSE field are as described in section 7.2.
-
-Upon receiving the CLIENT_VERIFY message, the server verifies the
-certificate, if required, and the authentication response; errors in 
-either of these result in a BAD_CERTIFICATE or CLIENT_AUTH_FAILED 
-error, respectively.  The server may then begin transmitting data.
-
-
-6.  Algorithm and Certificate Types
-
-6.1  Key exchange algorithms
-
-6.1.1  Key exchange algorithm types
-
-PCT version 2 permits the following key exchange types:
-
-PCT_EXCH_RSA_PKCS1
-PCT_EXCH_RSA_PKCS1_TOKEN_DES
-PCT_EXCH_RSA_PKCS1_TOKEN_DES3
-PCT_EXCH_RSA_PKCS1_TOKEN_RC2
-PCT_EXCH_RSA_PKCS1_TOKEN_RC4
-PCT_EXCH_DH_PKCS3
-PCT_EXCH_DH_PKCS3_TOKEN_DES
-PCT_EXCH_DH_PKCS3_TOKEN_DES3
-PCT_EXCH_FORTEZZA_TOKEN
-
-Note that the token-based key exchange types (those types whose 
-labels contain the word TOKEN) specify cipher as well (including, 
-implicitly, the FORTEZZA KEA key exchange type); if one of these is 
-chosen, then its choice of cipher overrides whatever choice of 
-cipher appears in the SH_CIPHER_SPECS_DATA field of the SERVER_HELLO 
-message.
-
-These key exchanges may use the (QUICK_)PUBLIC_VALUE field in any 
-handshake message, as well as the (QUICK_)ENCRYPTED_KEY field in the 
-subsequent handshake message.  The (first) public value sent is said 
-to be sent by (or previously obtained from) the "receiver", and the 
-second value by the "sender".  If the sender is the client, then the 
-key exchange is said to be "server-directed"; if the sender is the 
-server, then it is said to be "client-directed".
-
-
-6.1.2  Key exchange field formats
-
-The format of the (QUICK_)PUBLIC_VALUE field in any handshake 
-message in which it appears is as follows:
-
-char PV_PUBLIC_VALUE_TYPE[2]
-char PV_USER_INFO_LENGTH[4]
-char PV_PARAMETER_1_LENGTH[2]
-char PV_PARAMETER_2_LENGTH[2]
-char PV_USER_INFO_DATA[([0] << 24)|([1] << 16)|([2] << 8)|[3]]
-char PV_PARAMETER_1_DATA[([0] << 8)|[1]]
-char PV_PARAMETER_2_DATA[([0] << 8)|[1]]
-
-There are five permissible values for PUBLIC_VALUE_TYPE.  If 
-PV_TYPE_CERTIFICATE is specified, then a certificate of a type 
-acceptable to the key exchange sender (as indicated by the 
-CH_CERT_LIST in the CLIENT_HELLO message, or the SH_CERT_LIST list, 
-in the SERVER_HELLO message, as appropriate) appears in the
-PV_USER_INFO field, and both PV_PARAMETER fields are empty, with 
-length zero.  (The PV_PARAMETER_1_LENGTH field contains the
-two-byte certificate type code identifying the type of the 
-certificate sent; this field is not, however, interpreted as the 
-length of the PV_PARAMETER_1_LENGTH field, which is still empty;
-see section 6.4.)  If PV_TYPE_PKCS_TOKEN is specified, then the 
-PV_USER_INFO field contains a PKCS-format public key of the type 
-(RSA or Diffie-Hellman) indicated by the SH_EXCH_SPECS field in the 
-SERVER_HELLO message.  If PV_TYPE_KEA is specified, then the 
-PV_USER_INFO field contains a KEA public value exactly as generated 
-by the FORTEZZA token, and both PV_PARAMETER fields are empty, with 
-length zero.  If PV_TYPE_EPHEMERAL_RSA is specified, then 
-PV_USER_INFO contains the RSA modulus from the RSA public value 
-being sent; PV_PARAMETER_1 contains the associated RSA exponent; and 
-PV_PARAMETER_2 is empty, with length zero.  If PV_TYPE_EPHEMERAL_DH 
-is specified, then PV_USER_INFO contains the actual Diffie-Hellman 
-public value; PV_PARAMETER_1 contains the generator used to 
-construct it; and PV_PARAMETER_2 contains the prime modulus used to 
-construct it.  For both EPHEMERAL public value types, the values in 
-all fields are represented with the most significant byte first, and 
-in descending order, with the least significant byte last.
-
-The (QUICK_)ENCRYPTED_KEY_DATA field in any handshake message in
-which it appears has the following format:
-
-char EK_ENCRYPTED_KEY_1_LENGTH[2]
-char EK_ENCRYPTED_KEY_2_LENGTH[2]
-char EK_ENCRYPTED_KEY_3_LENGTH[2]
-char EK_KEY_ARG_LENGTH[2]
-char EK_ENCRYPTED_KEY_1_DATA[([0] << 8)|[1]]
-char EK_ENCRYPTED_KEY_2_DATA[([0] << 8)|[1]]
-char EK_ENCRYPTED_KEY_3_DATA[([0] << 8)|[1]]
-char EK_KEY_ARG_DATA[([0] << 8)|[1]]
-
-Details of the use of these subfields is described below.
-
-
-6.1.3  Master key exchange 
-
-For the PCT_EXCH_RSA_PKCS1 key exchange type, a MASTER_KEY value is
-generated by the sender, which should be random in the following
-strong sense: attackers must not be able to predict any of the bits in
-the MASTER_KEY.  It is recommended that the bits used be either truly
-random and uniformly generated (using some random physical process) or
-else generated using a cryptographically secure pseudorandom number
-generator, which was in turn seeded with a truly random and uniformly
-generated seed.  This MASTER_KEY value is encrypted using the 
-receiver's (possibly certified) public encryption key, as obtained 
-from the (QUICK_)PUBLIC_VALUE_DATA field of some handshake message 
-(or possibly some time earlier, if the key is certified).  The 
-encryption must follow the RSA PKCS#1 standard format (see [3]), 
-block type 2.  This encryption is sent to the server in the 
-EK_ENCRYPTED_KEY_1_DATA subfield in the (QUICK_)ENCRYPTED_KEY_DATA 
-field of the handshake message following the one containing the public
-value used (or the sender's first  handshake message, if the public 
-key was obtained at an earlier time).  The encrypted key is decrypted 
-by the receiver to obtain the MASTER_KEY.  If two key exchanges of 
-this type are performed (one in each direction), then the MASTER_KEY 
-value is simply the concatenation of the two values, in the order in 
-which they were sent.  Use of the ENCRYPTED_KEY_2_DATA subfield is
-described in section 6.1.5; the ENCRYPTED_KEY_3_DATA subfield is left
-empty, with length zero.
-
-For the PCT_EXCH_DH_PKCS3 key exchange type, a random private value x
-(generated in the same way as the MASTER_KEY above) and corresponding
-public value y are generated by the sender following RSA PKCS#3
-standard format (see [4]). The value y is then sent to the receiver 
-in the EK_ENCRYPTED_KEY_1_DATA subfield of the 
-(QUICK_)ENCRYPTED_KEY_DATA field of some handshake message.  The 
-sender's private value x, along with the (possibly certified) public 
-value y' included in the (QUICK_)PUBLIC_VALUE_DATA field of the 
-previous handshake message (or possibly obtained earlier), is used to 
-generate the MASTER_KEY.  The receiver uses its private value, x', 
-along with the y value sent by the sender, to obtain the same 
-MASTER_KEY value.  If two key exchanges of this type are performed 
-(one in each direction), then the MASTER_KEY is simply the 
-concatenation of the two values, in the order in which they were sent.
-Use of the ENCRYPTED_KEY_2_DATA subfield is described in section 
-6.1.5; the ENCRYPTED_KEY_3_DATA subfield is left empty, with length 
-zero.
-
-For the various TOKEN key exchange types, an encrypted 
-CLIENT_WRITE_KEY is contained in the ENCRYPTED_KEY_1_DATA subfield, 
-and an encrypted SERVER_WRITE_KEY is contained in the 
-ENCRYPTED_KEY_2_DATA subfield of the (QUICK_)ENCRYPTED_KEY field.
-The format of the data is defined by the token implementation.  For 
-example, in the case of FORTEZZA tokens, the ENCRYPTED_KEY_1_DATA 
-subfield (like the (QUICK_)PUBLIC_VALUE field sent before it, or 
-obtained earlier), contains a KEA public value generated by the token 
-for key exchange.  The result is a CLIENT_WRITE_KEY shared by sender 
-and receiver, which is used, along with the initialization vector in
-the accompanying EK_KEY_ARG_DATA field, if needed (see section 
-6.1.5), to encrypt the SERVER_WRITE_KEY sent in the 
-ENCRYPTED_KEY_2_DATA subfield.  In all token types, this shared 
-encryption key is used to encrypt a 128-bit MASTER_KEY value for 
-MAC_KEY derivation (as described below).  This MASTER_KEY is sent in 
-the EK_ENCYRYPTED_KEY_3_DATA field of the ENCRYPTED_KEY_DATA subfield 
-accompanying the encryption key material, and uses the initialization 
-vector in the accompanying EK_KEY_ARG_DATA field, if needed (see 
-section 6.1.5).
-
-The length of the MASTER_KEY depends on the key exchange type, and on
-how many key exchanges were performed.  It is 128 bits if one RSA 
-key exchange was performed, and 256 bits if two exchanges were 
-performed and the results concatenated.  For Diffie-Hellman key
-exchange, it is the length of the receiver's public value if one key
-exchange was performed, and the sum of the lengths of each receiver's 
-public value if two key exchanges were performed.  For token-based 
-key exchange types, the MASTER_KEY (which is only relevant for MAC 
-derivation) is 128 bits long.
-
-
-6.1.4  Key derivation
-
-The CLIENT_WRITE_KEY_SEED and SERVER_WRITE_KEY_SEED are used (for 
-non-token key exchange types) to compute the CLIENT_WRITE_KEY and
-SERVER_WRITE_KEY, respectively.  They are computed as follows:
-
-CLIENT_WRITE_KEY_SEED_i = Hash( i, "cw", MASTER_KEY, "cw"^i, 
-SH_CONNECTION_ID_DATA, "cw"^i, SH_SESSION_ID_DATA,"cw"^i, 
-CH_CHALLENGE_DATA, "cw"^i )
-
-SERVER_WRITE_KEY_SEED_i = Hash( i, "svw", MASTER_KEY, "svw"^i, 
-SH_CONNECTION_ID_DATA, "svw"^i, CH_CHALLENGE_DATA, "svw"^i )
-
-The function "Hash" is the one determined by the value of
-SH_HASH_SPECS_DATA (see section 5.2.2).  The value of i ranges from 
-1 to m, where m is the negotiated encryption key length (the value in 
-the third byte of the SH_CIPHER_SPECS_DATA field) divided by the hash 
-output length, in bits, rounded up to the nearest integer.  This 
-resulting string is then truncated if necessary to produce a string 
-of the correct length.
-
-When a token key exchange type is used, no WRITE_KEY_SEED values are
-computed, and the client and server WRITE_KEY values are defined by 
-the specific key exchange method for the token.  For example, the 
-encryption keys exchanged in the KEA key exchange process described 
-in section 6.1.3 become the CLIENT_WRITE_KEY and SERVER_WRITE_KEY for 
-the session.
-
-The CLIENT_MAC_KEY_SEED and SERVER_MAC_KEY_SEED are always computed 
-as follows:
-
-CLIENT_MAC_KEY_SEED_i = Hash( i, MASTER_KEY, "cmac"^i, 
-SH_CONNECTION_ID_DATA, "cmac"^i, SH_SESSION_ID_DATA, "cmac"^i, 
-CH_CHALLENGE_DATA, "cmac"^i )
-
-SERVER_MAC_KEY_SEED_i = Hash( i, MASTER_KEY, "svmac"^i, 
-SH_CONNECTION_ID_DATA, "svmac"^i, CH_CHALLENGE_DATA, "svmac"^i )
-
-The function "Hash" is the one determined by the value of
-SH_HASH_SPECS_DATA (see section 5.2.2).  The value of i ranges from
-1 through m, where m is the negotiated MAC key length (64 plus the 
-value in the fourth byte of the SH_CIPHER_SPECS_DATA field) divided 
-by the hash output length, in bits, rounded up to the nearest integer.
-The resulting string is then truncated if necessary to produce a 
-string (CLIENT_MAC_KEY_SEED or SERVER_MAC_KEY_SEED) of the correct 
-MAC_KEY length.  This string is then padded, by repeatedly appending 
-the byte PCT_MAC_KEY_PAD_BYTE , until it is the standard key length 
-for the hash function used in MAC computation (each hash function has 
-an associated standard MAC key length; see section 6.3).  This final 
-result is the MAC_KEY (CLIENT_MAC_KEY or SERVER_MAC_KEY).
- 
-Note that tokens which are capable of deriving keys using "keyed
-hashes", as described above, are free to use the PCT_EXCH_RSA_PKCS1
-or PCT_EXCH_DH_PKCS3 key exchange type to exchange the MASTER_KEY,
-and then to derive the rest of the keys normally.  The TOKEN key
-exchange types are for tokens that cannot do such keyed-hash key
-derivation, and can only use an exchanged key for bulk encryption
-(of, for example, the MASTER_KEY value used for MAC_KEY derivation).
-Such tokens can exchange multiple keys by using an initially 
-exchanged encryption key to encrypt other keys, as described above.
-
-Key derivation for datagram records is somewhat different from normal
-key derivation.  In a datagram record, the necessary key information 
-is contained in the DG_ENCRYPTED_KEY field at the beginning of a 
-datagram record.  Its ENCRYPTED_KEY_1_DATA subfield contains a 
-16-byte random value, which should be cryptographically random in the 
-same sense as the MASTER_KEY (see section 6.1.3).  This value is used 
-to generate the new WRITE_KEY (in the case of non-token key exchange 
-types) and the MAC_KEY for the datagram.  These are generated by 
-computing a temporary MASTER_KEY as follows:
-
-TEMP_MASTER_KEY_i = Hash( i, MASTER_KEY, "tmk"^i, 
-ENCRYPTED_KEY_1_DATA )
-
-The function "Hash" is the one determined by the value of
-SH_HASH_SPECS_DATA in the most recent SERVER_HELLO handshake message
-for this connection (see section 5.2.2).  The value of i ranges from
-1 through m, where m is 128 divided by the hash output length, in 
-bits, rounded up to the nearest integer.  The resulting concatenated
-string is then truncated if necessary to produce a 128-bit string.  
-The new WRITE_KEYs (in the case of non-token key exchange types) and 
-new MAC_KEYs are then computed normally, except that MASTER_KEY is 
-replaced with TEMP_MASTER_KEY.
-
-If the current keys were generated using a token-type key exchange, 
-then the DG_ENCRYPTED_KEY_2_DATA subfield contains the key information 
-necessary to decrypt the datagram, encrypted in a manner that the 
-token can decrypt.  (Note that the token type must support this type 
-of context-independent encryption of keys; otherwise, this type of key 
-management message is not permitted.)  For example, when FORTEZZA 
-tokens are used, the DG_ENCRYPTED_KEY_2_DATA subfield contains the 
-WRITE_KEY encrypted, as a key, using the current WRITE_KEY.  
-
-The DG_KEY_ARG_DATA subfield contains an arbitrary initialization 
-vector, whose use is also explained in section 6.1.5, if a block 
-cipher is being used; otherwise, the field is empty, and its length is
-zero.
-
-6.1.5  Key expansion and cipher use
-
-Every cipher has an associated standard key length (see section 6.2).
-When a non-token key exchange type has been used, and encryption keys 
-of standard length for the specified cipher have been specified in 
-the SH_CIPHER_SPECS field, then the values of CLIENT_WRITE_KEY and 
-SERVER_WRITE_KEY are simply CLIENT_WRITE_KEY_SEED and 
-SERVER_WRITE_KEY_SEED, respectively, and the ENCRYPTED_KEY_2_DATA
-subfield accompanying the encrypted master key(s) is empty.  
-Otherwise, the EK_ENCRYPTED_KEY_2_DATA subfield(s) accompanying the 
-encrypted master key(s) in the key exchange(s) contain(s) random 
-"salt" for encryption key derivation.  (The salt should be 
-cryptographically random in the same sense as the MASTER_KEY; see 
-section 6.1.3.)  If only one key exchange occurred, then the salt data
-used (which we will call CLEAR_KEY_DATA) is just the value in the 
-ENCRYPTED_KEY_2_DATA subfield accompanying the encrypted master key; 
-if two key exchanges are used, then both EK_ENCRYPTED_KEY_2_DATA 
-fields accompanying the encrypted master keys contain this random 
-data, and CLEAR_KEY_DATA is their concatenation, in the order in which 
-they were sent.  When a key length is specified which is less than the 
-standard key length for the specified cipher, then keys of the 
-specified length are derived normally as described in section 6.1.4, 
-and then "expanded" to derive standard-length keys.  The expansion 
-proceeds as follows:
-
-1.  Assign to d the result of dividing the standard key length for 
-the cipher, in bits, by the output length of the hash function, in 
-bits, rounded up to the nearest integer.
-
-2.  Divide CLEAR_KEY_DATA sequentially into d equal subsegments.
-(Note that the length of the CLEAR_KEY_DATA field must therefore be a
-multiple of d bytes, and that no two of its d equal parts, when so
-divided, may be identical.)  Denote these subsegments CLEAR_KEY_DATA_1
-through CLEAR_KEY_DATA_d.
-
-3.  Compute the d hash values
-
-WRITE_KEY_i := Hash( i, "sl"^i, WRITE_KEY_SEED, "sl"^i, 
-CLEAR_KEY_DATA_i ).
-
-The function "Hash" is the one determined by the value of
-SH_HASH_SPECS_DATA.  The WRITE_KEY_SEED is the encryption key seed 
-value (CLIENT_WRITE_KEY_SEED or SERVER_WRITE_KEY_SEED) being expanded 
-to standard length. 
-
-4.  Concatenate WRITE_KEY_1 through WRITE_LENGTH_KEY_d, and then 
-truncate as necessary to produce the WRITE_KEY which is actually used 
-for encryption.
-
-The EK_KEY_ARG_DATA subfield accompanying the (last) encrypted master 
-key contains a random eight-byte value to be used as an initialization 
-vector (IV) for the first encrypted message when a block cipher (any 
-cipher except RC4) is used.  The IV for the first block encrypted in 
-any subsequent encrypted message is simply the last encrypted block 
-of the previous message.  The EK_KEY_ARG_DATA subfield is empty when 
-cipher type PCT_CIPHER_RC4 (or key exchange type 
-PCT_EXCH_RSA_PKCS1_TOKEN_RC4) is used.
-
-The use of a block cipher also may cause the data length to increase
-during encryption, because the ciphertext produced by block ciphers
-must always be an integer multiple of the cipher's block size.  Hence 
-when a block cipher is used, the length of the (fully or partially)
-encrypted record must be computed from the RH_RECORD_LENGTH value in 
-the record header.  ENCRYPTED_LENGTH, the length of the encrypted 
-portion of a record, is computed as the smallest multiple of the 
-cipher's block size that is at least ACTUAL_LENGTH, where 
-ACTUAL_LENGTH, the length of the encrypted data before encryption, is 
-computed as RH_RECORD_LENGTH minus the lengths of the unencrypted 
-portions of the record body (RH_RECORD_LENGTH - MAC_LENGTH - 
-DG_ENCRYPTED_KEY_LENGTH - 4 in the case of a datagram record, and 
-RH_RECORD_LENGTH - MAC_LENGTH - 2 in the case of other encrypted record 
-types).  If a block cipher is not used for encryption, then the length 
-of the encrypted data is unchanged by encryption, and the length of the 
-record body is therefore simply RH_RECORD_LENGTH.  Otherwise, the 
-length of the entire encrypted record body is ENCRYPTED_LENGTH + 
-DG_MAC_LENGTH + DG_ENCRYPTED_KEY_LENGTH + 2 in the case of datagram
-records, and ENCRYPTED_LENGTH + MAC_LENGTH for other encrypted 
-record types.
-
-
-6.2  Cipher Types
-
-PCT version 2 permits the following cipher types to be specified:
-
-PCT_CIPHER_DES
-PCT_CIPHER_IDEA
-PCT_CIPHER_RC2
-PCT_CIPHER_RC4
-PCT_CIPHER_DES_112
-PCT_CIPHER_DES_168
-
-Each of these types is denoted by a two-byte code, and is followed in
-CIPHER_SPECS_DATA fields by two one-byte length specifications, as
-described in section 5.2.1.  An encryption length specification of
-zero associated with any cipher denotes the choice of no encryption; a
-key exchange is performed in such cases solely to share keys for MAC
-computation.
-
-PCT_CIPHER_DES denotes DES (see [5]).  Its standard key length is 56
-bits.  PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168 denote ciphers in
-which the input is first encrypted under DES with a first key, then
-"decrypted" under DES with a second key, then encrypted under DES with
-a third key.  For PCT_CIPHER_DES_112, the first and third keys are
-identical, and correspond to the initial 56 bits of the 112-bit
-WRITE_KEY.  The second key corresponds to the final 56 bits of the
-WRITE_KEY.  For PCT_CIPHER_DES_168, the three keys are distinct, and
-correspond to the first, second, and third 56-bit subsegments of the
-WRITE_KEY.  All three of these DES-based cipher types have 64-bit data
-blocks and are used with cipher block chaining (CBC).
-
-The standard key lengths for PCT_CIPHER_DES_112 and PCT_CIPHER_DES_168
-are 112 bits and 168 bits, respectively.  If a key length less than
-the standard length is specified for one of these ciphers (or for
-PCT_CIPHER_DES), then the WRITE_KEY_SEED is calculated, then expanded 
-to the standard length as described above.
-
-Note that before use, each 56-bit DES key must be "adjusted" to add
-eight parity bits to form an eight-byte DES key (see [5]).  Similarly,
-if the specified WRITE_KEY length is less than its corresponding
-standard length, then each WRITE_KEY_SEED is expanded to the standard
-length using CLEAR_KEY_DATA as described above, to produce one, two,
-or three keys of 56 bits each, which are then each "adjusted" by
-adding parity bits to form an eight-byte key.
-
-PCT_CIPHER_IDEA denotes the IDEA block cipher (see [6]), with 64-bit
-data blocks and cipher block chaining.  This cipher has a standard key
-length of 128 bits.
-
-PCT_CIPHER_RC2 denotes the RC2 block cipher, with 64-bit blocks and
-cipher block chaining.  Like IDEA, this cipher has a standard key
-length of 128 bits.
-
-PCT_CIPHER_RC4 denotes the RC4 stream cipher.  Like the IDEA and RC2
-block ciphers, this cipher has a standard key length of 128 bits.
-
-6.3  Hash Types
-
-PCT version 2 permits the following hash function types to be
-specified:
-
-PCT_HASH_MD5
-PCT_HASH_MD5_TRUNC_64
-PCT_HASH_SHA
-PCT_HASH_SHA_TRUNC_80
-
-The "truncated" hash types (PCT_HASH_MD5_TRUNC_64 and 
-PCT_HASH_SHA_TRUNC_80) are identical to their non-truncated versions
-(PCT_HASH_MD5 and PCT_HASH_SHA, respectively), with the following
-exception:  when used in the second ("outer") iteration of a MAC
-or authentication response, their output is truncated to half its 
-normal length.  (Hence the resulting MAC or authentication response 
-is also only half the normal length of the hash function's output.)
-  
-PCT_HASH_MD5 denotes the MD5 hash function (see [7]), with 128-bit
-output.  (Hence PCT_HASH_MD5_TRUNC_64 has 64-bit output in the cases
-described above.)  PCT_HASH_SHA denotes the Secure Hash Algorithm 
-(see [8]), with 160-bit output.  (Hence PCT_HASH_SHA_TRUNC_80 has
-80-bit output in the cases described above.)  The standard MAC key length
-for all of the above hash functions is 512 bits.
-
-
-6.4  Certificate Types
-
-PCT version 2 permits the following certificate types to be specified:
-
-PCT_CERT_X509
-PCT_CERT_PKCS7
-PCT_CERT_PRIVATE
-
-THese types apply equally to the client's and server's certificates.
-PCT_CERT_X509 denotes a CCITT X.509 standard-conformant certificate 
-(see [10]).  PCT_CERT_PKCS7 denotes an RSA PKCS#7 standard-conformant 
-certificate (see [11]).  PCT_CERT_PRIVATE denotes a private format 
-understood by both the client and server; for instance, it may refer 
-to an account identifier using which a certificate lookup can be 
-performed on some agreed-upon certificate database.
-
-
-6.5  Signature Types
-
-PCT version 2 permits the following signature key types to be
-specified:
-
-PCT_SIG_RSA_MD5
-PCT_SIG_RSA_SHA
-PCT_SIG_DSA_SHA
-
-PCT_SIG_RSA_MD5 denotes the signature scheme consisting of hashing 
-the data to be signed using the MD5 hash algorithm, and then 
-performing an RSA private-key signature function (the inverse of RSA 
-encryption) on the result.  The signature must conform to RSA PKCS#1, 
-block type 1 (see [3]).  PCT_SIG_RSA_SHA denotes the same signature 
-scheme with SHA substituted for MD5.  PCT_SIG_DSA_SHA denotes the 
-signature scheme consisting of hashing the data to be signed using 
-the SHA hash algorithm, then computing a signature of the resulting 
-value using the Digital Signature Algorithm (DSA; see [12]).
-
-7.  Response and verification formats
-
-7.1  Prelude verification
-
-In order to guard against alteration of handshake messages before the
-master key has been exchanged (and MACs therefore made possible), a
-"prelude verification" is incorporated into every authentication 
-response.  Basically, the prelude verification is a cryptographic hash 
-of all handshake messages up to and including the one in which the 
-first authentication response is included (with the response field
-itself omitted).  
-
-Whichever message contains it, the prelude verification value is 
-computed as:
-
-VERIFY_PRELUDE_DATA = Hash( "vpd", CLIENT_HELLO, SERVER_HELLO , 
-CLIENT_MASTER_KEY, SERVER_VERIFY, CLIENT_VERIFY ) ).
-
-For the purposes of this computation, the handshake messages are 
-assumed to contain their associated message headers (i.e., their 
-HS_MSG_TYPE and HS_RECORD_FLAGS fields) and record headers.  Also, the 
-message in which the first non-empty RESPONSE_DATA field is sent is 
-assumed for this computation not to include its RESPONSE_DATA field 
-(although its correct length is included), and subsequent messages in 
-the handshake are assumed to be empty, zero-length values.
-
-The hash function used is the one specified in SH_HASH_SPECS_DATA.  
-Note that the client and server need only keep a "running hash" of all 
-the values passed in each handshake message as they appear, 
-terminating at the appropriate point to compute the value of 
-VERIFY_PRELUDE_DATA.
-
-
-7.2  Authentication responses
-
-The format of an authentication response depends on the type of 
-authentication required.  Because each type of authentication 
-response may be sent in one of several possible handshake messages
-(and by either party), the formats are described separately 
-here, and apply wherever the authentication response (RESPONSE_DATA)
-field is non-empty.
-
-In the case of key exchange-based authentication, the contents of the
-RESPONSE_DATA field are computed as follows:
-
-RESPONSE_DATA = Hash( MAC_KEY, Hash( "ke", VERIFY_PRELUDE_DATA ) ).
-
-In the case of digital signature-based authentication, the contents
-of the RESPONSE_DATA field are computed as follows: 
-
-RESPONSE_DATA = Signature( VERIFY_PRELUDE_DATA ).
-
-In the case of private "password"-based authentication, the contents
-of the RESPONSE_DATA field are computed as follows: 
-
-RESPONSE_DATA = Hash( MAC_KEY, Hash( "ppw", IDENTITY, PASSWORD, 
-VERIFY_PRELUDE_DATA ) ).
-
-Finally, in the case of authentication of a reconnection of a
-previously established session, the contents of the RESPONSE_DATA 
-field are computed as follows:
-
-RESPONSE_DATA = Hash( MAC_KEY, Hash( "recon", VERIFY_PRELUDE_DATA ) ).
-
-The computation of the VERIFY_PRELUDE_DATA value is described in 
-section 7.1.  The MAC_KEY is the CLIENT_MAC_KEY if the field is in 
-the CLIENT_MASTER_KEY or CLIENT_VERIFY message, and SERVER_MAC_KEY if 
-the field is in the SERVER_HELLO or SERVER_VERIFY message.  (The 
-origin of these MAC keys is described in section 6.1.4.)  
-The hash function choice used is determined by the 
-SH_HASH_SPECS_DATA field in this SERVER_HELLO message.  
-
-When a digital signature is used, the signature algorithm is 
-determined by the type of signature public key found in the 
-certificate passed in the SIG_CERT_DATA field accompanying the 
-RESPONSE_DATA field.  (Note that the signature algorithm may itself 
-require that a hash function be applied to the data being signed, 
-apart from the one used to compute the value in VERIFY_PRELUDE_DATA.)
-
-When a private password is used, IDENTITY is the identity of the
-client or server being authenticated (the contents of the 
-SIG_CERT_DATA field accompanying the response), and PASSWORD is the
-shared private key used in the authentication.  (Note that the same 
-shared password can in principle be used to authenticate either the 
-client to the server or vice versa, although not both simultaneously.)  
-In the case of a doubly certified Diffie-Hellman key exchange, the 
-password is simply the response sender's MAC key generated as a result 
-of the key exchange; it is considered equivalent to a password because 
-it does not change from connection to connection or from session to 
-session.
-
-
-7.3  Message Authentication Codes
-
-All PCT version 2 records which are encrypted also include a message 
-authentication code (MAC).  This value allows the receiver to verify
-that the record containing it has originated with the correct party,
-and has not been inserted or tampered with by someone else in 
-transit.
-
-The basic PCT MAC is in the form of a keyed hash of the encrypted
-data; that is, a MAC function based on a cryptographic hash function 
-is computed on the encrypted data and the sender's MAC key.  (The 
-derivation of MAC keys is described in section 6.1.)  The 
-cryptographic hash function used is determined by the code contained 
-in the SH_HASH_SPECS_DATA field in the most recent SERVER_HELLO 
-message sent during a successful handshake phase this session.  A 
-list of cryptographic hash functions permitted in PCT version 2, and 
-their associated codes and output lengths, is given in section 6.3.  
-The MAC is placed in the MAC_DATA field of the record in which it is
-found; its length (MAC_LENGTH) is the output length of the hash 
-function used.
-
-The MAC value is computed differently for datagram records and for
-other records.  In datagram records, the MAC is computed as follows:
-
-DG_MAC_DATA = Hash( MAC_KEY, Hash( RECORD_HEADER_DATA, 
-DG_ENCRYPTED_KEY_LENGTH, DG_ENCRYPTED_KEY_DATA, DG_ENCRYPTED_DATA ) )
-
-If the client is sending the record, then the MAC_KEY is the
-CLIENT_MAC_KEY; if the server is sending the record, then the MAC_KEY
-is the SERVER_MAC_KEY.  (The derivation of these keys is described 
-in section 6.1.)  RECORD_HEADER_DATA contains the four-byte contents 
-of the datagram record's record header, as described in section 4.2.1.  
-
-For other records containing MACs, the MAC is computed as follows:
-
-DT_MAC_DATA = Hash( MAC_KEY, Hash( DATA_TYPE, RECORD_HEADER_DATA, 
-DT_ENCRYPTED_DATA, SEQUENCE_NUMBER ) )
-
-If the client is sending the record, then the MAC_KEY is the
-CLIENT_MAC_KEY; if the server is sending the record, then the MAC_KEY
-is the SERVER_MAC_KEY.  (The details of the derivation of these keys
-are given in section 6.1.4.)  The value of DATA_TYPE is either the 
-empty string, or the four-byte ASCII string "pecd" if the record 
-contains pre-encrypted data (see section 4.4.1).  RECORD_HEADER_DATA 
-contains the four-byte contents of the record header described in 
-section 4.2.1.
-
-SEQUENCE_NUMBER is the value (represented in network byte order, or 
-"big endian" order) of a counter which is incremented by both the 
-sender and the receiver.  For each transmission direction, a pair 
-of counters is kept (one by the sender, one by the receiver).  
-Before the first (handshake) record is sent or received in a PCT 
-connection all sequence number counters are initialized to zero 
-(except in the case of a restarting connection with a token-based 
-exchange type, in which case the entire cipher state is preserved; 
-see section 5.2.2).  The sender's sender-to-receiver sequence 
-number is incremented after every record sent, and the receiver's 
-sender-to-receiver sequence number is incremented after every record 
-received.  (Note that this increment occurs regardless of whether or 
-not a record is, or has, a continuation record.)  Sequence number 
-counters are 32-bit unsigned quantities, and may not increment past 
-0xFFFFFFFF.  (See section 4.4.4.)
-
-MACs for pre-encrypted data can be (mostly) precomputed as well.
-The inner invocation of the hash function in the computation of 
-DT_MAC_DATA contains information that will be known at encryption 
-time, assuming non-datagram transmission and receiver support for 
-the hash function chosen by the sender for MAC calculation.  Hence, 
-the output of this inner invocation of the hash function can be 
-stored along with the pre-encrypted data, and the MAC calculated 
-efficiently at transmission time using the normal MAC_KEY, the 
-pre-calculated hash value, and the hash function used in the 
-pre-calculation.  A separate sequence number is used for MACs in 
-pre-encrypted data records until a KM_TYPE_RESUME_KEY message or 
-another KM_TYPE_FIXED_KEY message is sent and received.  This 
-sequence number begins at zero for the first data record sent and 
-received after the KM_TYPE_FIXED_KEY message, and is incremented for 
-each data record sent.  Replays of non-pre-encrypted data as 
-pre-encrypted data are prevented by the DATA_TYPE value "pecd", which
-cannot correspond to a record header prefix, in the MAC computation.
-
-In addition to the special sequence number for pre-encrypted data, 
-the normal sequence number for the same transmission direction 
-continues to increment normally as pre-encrypted data messages are 
-sent and received.  This original sequence number is returned to use,
-thus incremented, when the next key management message of type 
-KM_TYPE_RESUME_KEY or KM_TYPE_FIXED_KEY is sent and received.
-
-The receiver of an encrypted record containing a MAC uses the
-appropriate MAC_KEY and the received value of ENCRYPTED_DATA to 
-compute the correct value of MAC_DATA.  The computed MAC_DATA must 
-agree bit for bit with the transmitted MAC_DATA.  If the two are not 
-identical, then an INTEGRITY_CHECK_FAILED error occurs, and it is 
-recommended that the record be treated as though it had not been 
-received.  (See section 4.6.)
-
-
-8.  Constants
-
-Following is a list of constant values used in the PCT protocol
-version 1.
-
-8.1  Record and message type codes
-
-These codes are each placed in the record or message type fields of
-PCT records and messages.
-
-RT_HANDSHAKE                :=  0x0301
-RT_KEY_MGMT                 :=  0x0302
-RT_DATAGRAM                 :=  0x0303
-RT_ERROR                    :=  0x0304
-RT_USER_DATA                :=  0x0305
-RT_PCT_VERSION_1_CH         :=  0x0180
-RT_PCT_VERSION_1_SH         :=  0x0280
-RT_SSL_VERSION_2_CH         :=  0x0100
-RT_SSL_VERSION_3_CH         :=  0x00**
-RT_CD_RESERVED              :=  0x6364
-RT_KR_RESERVED              :=  0x6B72
-RT_ESCROW                   :=  0x0310
-
-HS_CLIENT_HELLO                 :=      0x0000
-HS_SERVER_HELLO                 :=      0x0001
-HS_CLIENT_MASTER_KEY            :=      0x0002
-HS_SERVER_VERIFY                :=      0x0003
-HS_CLIENT_VERIFY                :=      0x0004
-
-KM_TYPE_FIXED_KEY       :=  0x0001
-KM_TYPE_RESUME_KEY      :=  0x0002
-KM_TYPE_REDO_HANDSHAKE  :=  0x0003
-KM_TYPE_CLOSE_CONN      :=  0x0004
-
-DM_TYPE_USER_DATA       :=  0x0000
-
-PV_TYPE_CERTIFICATE     :=  0x0001
-PV_TYPE_PKCS_TOKEN      :=  0x0002
-PV_TYPE_KEA             :=  0x0003
-PV_TYPE_EPHEMERAL_RSA   :=  0x0004
-PV_TYPE_EPHEMERAL_DH    :=  0x0005
-
-EW_TYPE_MASTER_KEY      :=  0x0001
-EW_TYPE_WRITE_KEYS      :=  0x0002
-
-8.2  Specification Type Codes
-
-These are codes used to specify types of cipher, key exchange, hash
-function, certificate, and digital signature in the protocol.
-
-PCT_EXCH_RSA_PKCS1              :=      0x0001
-PCT_EXCH_RSA_PKCS1_TOKEN_DES    :=      0x0002
-PCT_EXCH_RSA_PKCS1_TOKEN_DES3   :=      0x0003
-PCT_EXCH_RSA_PKCS1_TOKEN_RC2    :=      0x0004
-PCT_EXCH_RSA_PKCS1_TOKEN_RC4    :=      0x0005
-PCT_EXCH_DH_PKCS3               :=      0x0006
-PCT_EXCH_DH_PKCS3_TOKEN_DES     :=      0x0007
-PCT_EXCH_DH_PKCS3_TOKEN_DES3    :=      0x0008
-PCT_EXCH_FORTEZZA_TOKEN         :=      0x0009
-
-PCT_CIPHER_DES          :=      0x0001
-PCT_CIPHER_IDEA         :=      0x0002
-PCT_CIPHER_RC2          :=      0x0003
-PCT_CIPHER_RC4          :=      0x0004
-PCT_CIPHER_DES_112      :=      0x0005
-PCT_CIPHER_DES_168      :=      0x0006
-
-PCT_HASH_MD5            :=      0x0001
-PCT_HASH_MD5_TRUNC_64   :=      0x0002
-PCT_HASH_SHA            :=      0x0003
-PCT_HASH_SHA_TRUNC_80   :=      0x0004
-PCT_HASH_DES_DM         :=      0x0005
-
-PCT_CERT_NONE           :=      0x0000
-PCT_CERT_X509           :=      0x0001
-PCT_CERT_PKCS7          :=      0x0002
-PCT_CERT_PRIVATE    	:=	  0x0003
-
-PCT_SIG_NONE            :=      0x0000
-PCT_SIG_RSA_MD5         :=      0x0001
-PCT_SIG_RSA_SHA         :=      0x0002
-PCT_SIG_DSA_SHA         :=      0x0003
-
-8.3  Error Codes
-
-These codes are used to identify errors, when they occur, in error
-messages.
-
-PCT_ERR_BAD_CERTIFICATE         :=      0x0001
-PCT_ERR_CLIENT_AUTH_FAILED      :=      0x0002
-PCT_ERR_ILLEGAL_MESSAGE         :=      0x0003
-PCT_ERR_INTEGRITY_CHECK_FAILED  :=      0x0004
-PCT_ERR_SERVER_AUTH_FAILED      :=      0x0005
-PCT_ERR_SPECS_MISMATCH          :=      0x0006
-PCT_ERR_CONN_BROKEN		  :=	    0x0007
-
-8.4  Miscellaneous Codes
-
-These include PCT version 1 escape type codes, version numbers, 
-and assorted constants associated with the PCT protocol.
-
-PCT_VERSION_V2                  :=      0x0002
-
-PCT_SESSION_ID_NONE             :=      0x00 (32 bytes of zeros)
-PCT_MAC_KEY_PAD_BYTE		  :=	    0x36
-
-PCT_ET_OOB_DATA                 :=      0x01
-PCT_ET_REDO_CONN                :=      0x02
-
-PCT_CH_OFFSET_V1                :=      0x000A
-PCT_CH_OFFSET_V2                :=      0x0018
-
-PCT_MAX_RECORD_LENGTH_2_BYTE_HEADER :=  32767
-PCT_MAX_RECORD_LENGTH_3_BYTE_HEADER :=  16383
-PCT_MAX_RECORD_LENGTH_V2            :=  32763
-
-
-9.  PCT version 1 compatibility
-
-PCT version 1 is a subset of PCT version 2; however, because of 
-differing formats, connections are identified as either using version
-1 or version 2.  The identification occurs during the handshake phase;
-a value of RT_PCT_VERSION_1_CH in the RH_RECORD_TYPE field of a
-record header indicates a PCT version 1 CLIENT_HELLO message, and a 
-value of RT_PCT_VERSION_1_SH in the RH_RECORD_TYPE field of a
-record header indicates a PCT version 1 SERVER_HELLO message.  If
-the former is the first record received in a connection, it signals
-to the receiver that it is expected to be a server in a PCT version
-1 connection.  The client and server then follow the PCT version 1 
-protocol for the remainder of the connection.  If the latter is the
-response received to a PCT version 2 CLIENT_HELLO message, it signals
-to the receiver that it is expected to be a client in a PCT version 1
-type connection.  The client and server then follow the PCT version
-1 protocol for the remainder of the connection.  The PCT version 1 
-protocol is specified in [2].
-
-Note that a PCT version 1 server implementation that correctly uses
-the CH_OFFSET field to determine the location of the data fields in
-the CLIENT_HELLO message can successfully interpret a PCT version 2
-CLIENT_HELLO message, and reply with a PCT version 1 SERVER_HELLO
-message.  However, reconnections in a continued session must maintain 
-the same version as the first connection for the session.
-
-Note also that a PCT version 1 record header may have a three-byte
-record length field; this format can always be recognized by a first 
-(most significant) bit of zero in the RH_RECORD_LENGTH field.
-
-
-10. Security Considerations
-
-This entire document is about security.
-
-
-References
-
-[1]  K. Hickman and T. Elgamal.  The SSL Protocol.  Internet-draft,
-June 1995.
-
-[2]  J. Benaloh, B. Lampson, D. Simon, T. Spies and B. Yee.  The 
-PCT Protocol.  Internet Draft, October 1995.
-
-[3]  RSA Laboratories, "PKCS #1: RSA Encryption Standard", Version
-1.5, November 1993.
-
-[4]  RSA Laboratories, "PKCS #3: "Diffie-Hellman Key-Agreement
-Standard", Version 1.4, November 1993.
-
-[5]  NBS FIPS PUB 46, "Data Encryption Standard", National Bureau of
-Standards, US Department of Commerce, Jan. 1977.
-
-[6]  X. Lai, "On the Design and Security of Block Ciphers", ETH Series
-in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
-
-[7]  R. Rivest, RFC 1321: "The MD5 Message Digest Algorithm", April
-1992.
-
-[8]  NIST FIPS PUB 180-1, "Secure Hash Standard", National Institute
-of Standards and Technology, US Department of Commerce, Apr. 1995.
-
-[9]  ISO/IEC 9797, "Data Cryptographic Techniques--Data Integrity
-Mechanism Using a Cryptographic Check Function Employing a Block
-Cipher Algorithm", 1989.
-
-[10]  CCITT. Recommendation X.509: "The Directory - Authentication
-Framework". 1988.
-
-[11]  RSA Laboratories, "PKCS #7: Cryptographic Message Syntax
-Standard", Version 1.5, November 1993.
-
-[12]  NIST FIPS PUB 186, "Digital Signature Standard", National
-Institute of Standards and Technology, US Department of Commerce, May
-1994.
-
-[13]  B. Schneier, "Applied Cryptography: Protocols, Algorithms, and
-Source Code in C", John Wiley & Sons, Inc., 1994.
-
-[14]  R.L. Rivest, A. Shamir, L. Adelman, "A Method for Obtaining
-Digital Signatures and Public Key Cryptosystems", MIT Laboratory for
-Computer Science and Department of Mathematics, S.L. Graham,
-R.L. Rivest ed. Communications of the ACM, February 1978 (Vol 21,
-No. 2) pp. 120-126.
-
-[15]  W. Diffie and M.E. Hellman, "New directions in Cryptography",
-IEEE Transactions on Information Theory, November 1976 (Vol. IT-22, 
-No. 6) pp. 644-654.
-
-
-Appendix A:  Escrow Support
-
-To facilitate the escrow of keys used in PCT connections (across 
-firewalls, for instance), we describe here a protocol which can be 
-used to encapsulate PCT records, passing the encryption keys for 
-the connection to a third party.  The protocol involves a distinct 
-escrow record type (RT_ESCROW).  An escrow record header has the 
-normal format, although all flags must always be set to zero.  The 
-record itself has the following format:
-
-char EW_ESCROW_TYPE[2]
-char EW_KEY_ID[16]
-char EW_KEY_1_LENGTH[2]
-char EW_KEY_2_LENGTH[2]
-char EW_KEY_1_DATA[([0] << 8)|[1]]
-char EW_KEY_2_DATA[([0] << 8)|[1]]
-char EW_ENCLOSED_RECORD_DATA[DATA_LENGTH]
-
-The two defined escrow record types are EW_TYPE_MASTER_KEY and
-EW_TYPE_WRITE_KEYS.  In the first type, EW_KEY_1_DATA contains the
-MASTER_KEY for this session, and EW_KEY_2_DATA is empty, with length
-zero.  In the second type, EW_KEY_1_DATA contains the sender's
-WRITE_KEY, and EW_KEY_2_DATA contains the non-sender's WRITE_KEY.
-These keys are encrypted using a key and format determined by the
-EW_KEY_ID field, which contains a 16-byte identifier for the key 
-used in the encryption.  The format of the encryption, and the key
-distribution method used, are left to the implementation's discretion.
-(For example, a PCT connection between sender and escrower can be used
-to exchange a symmetric key and associated identifier; alternatively,
-a fixed key-exchange RSA public key can be designated as the escrow
-key to be used.)  ENCLOSED_RECORD_DATA holds a normal PCT record, 
-whose length can be calculated from the escrow record's header and the
-lengths of the other fields in the escrow record.  (Note that the 
-normal length limit for an escrow record thus imposes a 
-shorter-than-normal limit on the size of the encapsulated record.)
-
-In a normal connection, the first record sent after all key exchanges
-in the handshake have completed might be encapsulated in an escrow 
-record; the key(s) so escrowed would be in effect until the next 
-escrow encapsulation.  For example, in a connection between a client
-and server each operating "behind" a firewall, the client and server
-would each encapsulate their last handshake message (or first data
-message) in an escrow record, and pass it to the firewall.  Each
-firewall would receive the encapsulated record, decrypt the 
-escrowed key(s), then pass the enclosed record through itself 
-unaltered.  Thereafter, each firewall would be able to read all 
-messages passing in each direction, until a change of key occurred 
-(prompted by, say, a key management message, which would presumably 
-have to be enclosed in another escrow record).
-
-The type of escrow used depends on the level of trust between client
-or server and escrower.  If a master key is escrowed, then the 
-escrower is capable of not only decrypting but also altering messages,
-recalculating MACs accordingly.  On the other hand, if only the
-encryption keys are escrowed, then the escrower is incapable not 
-only of altering messages, but also of verifying MACs (to determine, 
-for instance, if the correct encryption key was supplied).  
-Furthermore, since the shared master key is used to derive independent
-keys for datagram messages, escrow of only encryption keys makes
-incoming datagram traffic unreadable to the escrower.
-
-
-
-Patent Statement
-
-This version of the PCT protocol relies on the use of patented public
-key encryption technology for authentication and encryption. The
-Internet Standards Process as defined in RFC 1310 requires a written
-statement from the Patent holder that a license will be made
-available to applicants under reasonable terms and conditions prior
-to approving a specification as a Proposed, Draft or Internet
-Standard.
-
-See existing RFCs, including RFC 1170, that discuss known public key
-cryptography patents and licensing terms and conditions.
-
-The Internet Society, Internet Architecture Board, Internet
-Engineering Steering Group and the Corporation for National Research
-Initiatives take no position on the validity or scope of the patents
-and patent applications, nor on the appropriateness of the terms of
-the assurance. The Internet Society and other groups mentioned above
-have not made any determination as to any other intellectual property
-rights which may apply to the practice of this standard. Any further
-consideration of these matters is the user's own responsibility.
-
-Author's Address
-
-Daniel R. Simon
-Microsoft Corp.
-One Microsoft Way
-Redmond WA 98052
-USA
-
-pct@microsoft.com
-
-This Internet-Draft expires 10 October 1996.
-
-
diff --git a/doc/protocol/draft-chudov-cryptopro-cptls-02.txt b/doc/protocol/draft-chudov-cryptopro-cptls-02.txt
deleted file mode 100644
index 360e1a462a..0000000000
--- a/doc/protocol/draft-chudov-cryptopro-cptls-02.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-Internet Draft                             Grigorij Chudov, CRYPTO-PRO
-                                          Serguei Leontiev, CRYPTO-PRO
-Expires March 8, 2006                                September 8, 2005
-Intended Category: Informational
-
-            GOST Cipher Suites for Transport Layer Security
-
-                 <draft-chudov-cryptopro-cptls-02.txt>
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 8, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-
-   This document is intended to register new cipher suites for the
-   Transport Layer Security (TLS) protocol, according to the procedure
-   specified in section A.5 of [TLS]. These cipher suites are based on
-   Russian national cryptographic standards - GOST R 34.10-94 and GOST R
-   34.10-2001 public keys, GOST 28147-89 encryption algorithm and GOST R
-   34.11-94 digest algorithm.
-
-
-
-
-Chudov, Leontiev              Informational                     [Page 1]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-Table of Contents
-
-   1     Introduction. . . . . . . . . . . . . . . . . . . . . . .  2
-   2     Proposed Ciphersuites . . . . . . . . . . . . . . . . . .  3
-   3     CipherSuite Definitions . . . . . . . . . . . . . . . . .  3
-   3.1   Key Exchange. . . . . . . . . . . . . . . . . . . . . . .  3
-   3.2   PRF, Signature and Hash . . . . . . . . . . . . . . . . .  3
-   3.3   Cipher and MAC. . . . . . . . . . . . . . . . . . . . . .  4
-   4     Data Structures and Computations. . . . . . . . . . . . .  4
-   4.1   Algorithms. . . . . . . . . . . . . . . . . . . . . . . .  4
-   4.2   Keys Calculation. . . . . . . . . . . . . . . . . . . . .  5
-   4.3   Server Certificate. . . . . . . . . . . . . . . . . . . .  5
-   4.4   Server Key Exchange . . . . . . . . . . . . . . . . . . .  5
-   4.5   Certificate Request . . . . . . . . . . . . . . . . . . .  5
-   4.6   Client Key Exchange Message . . . . . . . . . . . . . . .  5
-   4.7   Certificate Verify. . . . . . . . . . . . . . . . . . . .  7
-   4.8   Finished. . . . . . . . . . . . . . . . . . . . . . . . .  8
-   5     Security Considerations . . . . . . . . . . . . . . . . .  8
-   6     Appendix ASN.1 Modules. . . . . . . . . . . . . . . . . .  8
-   7     References. . . . . . . . . . . . . . . . . . . . . . . . 10
-   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 12
-   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 13
-
-1  Introduction
-
-
-   This document proposes the addition of new cipher suites to the
-   Transport Layer Security (TLS) protocol to support GOST R 34.11-94
-   digest, GOST 28147-89 encryption and VKO GOST R 34.10-94/2001 key
-   exchange algorithms.  The cipher suites defined here were proposed by
-   CRYPTO-PRO Company for the "Russian Cryptographic Software
-   Compatibility Agreement" community.
-
-   Algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST 28147-89 and GOST
-   R 34.11-94 have been developed by Russian Federal Agency of
-   Governmental Communication and Information (FAGCI) and "All-Russian
-   Scientific and Research Institute of Standardization". They are
-   described in [GOSTR341094], [GOSTR341001], [GOSTR3411] and
-   [GOST28147]. Algorithms VKO GOST R 34.10-94/2001 and PRF_GOSTR3411
-   are described in [CPALGS].
-
-   This document defines two configurations:
-      anonymous client - authenticated server (only server provides a
-      certificate);
-      authenticated client - authenticated server (client and server
-      exchange certificates).
-
-
-
-
-Chudov, Leontiev              Informational                     [Page 2]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-   The presentation language used here is the same as in [TLS].  Since
-   this specification extends TLS, these descriptions should be merged
-   with those in the TLS specification and any others that extend TLS.
-   This means, that enum types may not specify all possible values and
-   structures with multiple formats chosen with a select() clause may
-   not indicate all possible cases.
-
-   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].
-
-2  Proposed CipherSuites
-
-   The new cipher suites proposed here have the following definitions:
-
- CipherSuite TLS_GOST341094_WITH_GOST28147_OFB_GOST28147  = {0x00,0x80}
- CipherSuite TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147= {0x00,0x81}
- CipherSuite TLS_GOST341094_WITH_NULL_GOSTR3411           = {0x00,0x82}
- CipherSuite TLS_GOST34102001_WITH_NULL_GOSTR3411         = {0x00,0x83}
-
-   Note: The above numeric definitions for CipherSuites have not yet
-   been registered.
-
-3  CipherSuite Definitions
-
-3.1  Key exchange
-
-   The cipher suites defined here use the following key exchange
-   algorithms:
-
- CipherSuite                                     Key Exchange Algorithm
- TLS_GOST341094_WITH_GOST28147_OFB_GOST28147     VKO GOST R 34.10-94
- TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147   VKO GOST R 34.10-2001
- TLS_GOST341094_WITH_NULL_GOSTR3411              VKO GOST R 34.10-94
- TLS_GOST34102001_WITH_NULL_GOSTR3411            VKO GOST R 34.10-2001
-
-   Key derivation algorithms based on GOST R 3410-94 and GOST R
-   3410-2001 public keys (VKO GOST R 34.10-94, VKO GOST R 34.10-2001)
-   are described in [CPALGS].
-
-3.2 PRF, Signature and Hash
-
-   For a PRF, described in section 5 of [TLS], the cipher suites
-   described here use PRF_GOSTR3411 (refer to section 4.1). The same PRF
-   MUST be used for all dependent protocols, such as [EAP-TLS].
-
-   GOST R 3410-94/2001 signature is used for CertificateVerify message.
-
-
-
-
-Chudov, Leontiev              Informational                     [Page 3]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-   GOST R 34.11 digest algorithm ([GOSTR341194]) is used for
-   CertificateVerify.signature.gostR3411_hash and Finished.verify_data
-   (see sections 7.4.8 and 7.4.9 of [TLS])
-
-3.3 Cipher and MAC
-
-   The following cipher algorithm and MAC functions are used (for
-   details refer to section 4.1):
-
- CipherSuite                                  Cipher    MAC
- TLS_GOST341094_WITH_GOST28147_OFB_GOST28147   GOST28147 IMIT_GOST28147
- TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 GOST28147 IMIT_GOST28147
- TLS_GOST341094_WITH_NULL_GOSTR3411               -      HMAC_GOSTR3411
- TLS_GOST34102001_WITH_NULL_GOSTR3411             -      HMAC_GOSTR3411
-
-   For all four cipher suites, the use of MAC is slighttly different
-   from the one, described in section 6.2.3.1 of [TLS].  In [TLS], MAC
-   is calculated from the following data:
-
-     MACed_data[seq_num] = seq_num +
-                           TLSCompressed.type +
-                           TLSCompressed.version +
-                           TLSCompressed.length +
-                           TLSCompressed.fragment;
-
-   These cipher suites use the same input for first record, but for each
-   next record the input from all previous records is concatenated:
-
-     MACed_data[0] + ... + MACed_data[n]
-
-4  Data Structures and Computations
-
-4.1  Algorithms
-
-   GOST 28147-89 [GOST28147] uses 256-bit key size and 8-byte IV.
-   Cipher suites, defined here, use GOST 28147-89 as a stream cipher in
-   OFB mode with S-box from id-Gost28147-89-CryptoPro-A-ParamSet (see
-   [CPALGS]) and CryptoPro key meshing algorithm.
-
-   IMIT_GOST28147 is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4
-   bytes)
-
-   HMAC_GOSTR3411(secret, data) is based on GOST R 34.11 digest and
-   described in [CPALGS].
-
-   PRF_GOSTR3411(secret, label, seed) is based on HMAC_GOSTR3411 and
-   described in [CPALGS].
-
-
-
-
-Chudov, Leontiev              Informational                     [Page 4]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-4.2  Key Calculation
-
-   Key calculation is done according to section 6.3 of [TLS], with
-   PRF_GOSTR3411 function used instead of PRF.  The parameters are as
-   follows:
-      SecurityParameters.hash_size = 32
-      SecurityParameters.key_material_length = 32
-      SecurityParameters.IV_size = 8
-   Length of necessary key material is 144 bytes.
-
-4.3  Server Certificate
-
-   For these cipher suites this message is required and it MUST contain
-   a certificate, with a public key algorithm matching
-   ServerHello.cipher_suite.
-
-4.4  Server Key Exchange
-
-   This message MUST NOT be used in these cipher suites, because all the
-   parameters necessary are present in server certificate (see [CPPK]).
-
-4.3  Certificate Request
-
-   This message is used as described in section 7.4.4 of [TLS], and
-   extended as follows:
-
-    enum {
-        gost341094(21), gost34102001(22),(255)
-    } ClientCertificateType;
-
-   gost341094 and gost34102001 certificate types identify that the
-   server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key
-   certificates.
-
-   Note: The above numeric definitions for ClientCertificateType have
-   not yet been registered.
-
-4.6  Client Key Exchange Message
-
-   This message is used as described in section 7.4.7 of [TLS], it is
-   required for these suites, and contains DER-encoded
-   TLSGostKeyTransportBlob structure.
-
-    enum { vko_gost } KeyExchangeAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case vko_gost: TLSGostKeyTransportBlob;
-
-
-
-Chudov, Leontiev              Informational                     [Page 5]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-        } exchange_keys;
-    } ClientKeyExchange;
-
-   ASN1-syntax for this structure is:
-
-    TLSGostKeyTransportBlob ::= SEQUENCE {
-        keyBlob GostR3410-KeyTransport,
-        proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL
-    }
-
-    TLSProxyKeyTransportBlob ::= SEQUENCE {
-        keyBlob GostR3410-KeyTransport,
-        cert    OCTET STRING
-    }
-
-   GostR3410-KeyTransport is defined in [CPCMS].
-
-   keyBlob.transportParameters MUST be present.
-
-   keyBlob.transportParameters.ephemeralPublicKey MUST be present if the
-   server didn't request client certificate or client's public key
-   algorithm and parameters do not match those of the recipient. Else it
-   SHOULD be omited.
-
-      proxyKeyBlobs   - (optional) contains key exchange for secondary
-      recipients (for example, for the firewall, which audits
-      connections).
-      cert            - contains secondary recipient's certificate.
-
-   Actions of client:
-
-   First, the client generates a random 32-byte premaster_secret.
-
-   Then shared_ukm is calculated as first 8 bytes of digest of
-   concatenated client random and server random: shared_ukm =
-   GOSTR3411(client_random|server_random)[0..7]
-
-   Then client chooses a sender key.  If
-   keyBlob.transportParameters.ephemeralPublicKey is present, the
-   corresponding secret key MUST be used as a sender key.  If it is
-   missing, the secret key, corresponding to the client certificate MUST
-   be used.
-
-   Using the sender key and recipient's public key, algorithm VKO GOST R
-   34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied
-   to produce KEK.  VKO GOST R 34.10-2001 is used with shared_ukm as
-   UKM.
-
-
-
-
-Chudov, Leontiev              Informational                     [Page 6]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-   Then CryptoPro Key Wrap algorithm is applied to encrypt
-   premaster_secret and produce CEK_ENC and CEK_MAC.  Again, shared_ukm
-   is used as UKM.  keyBlob.transportParameters.encryptionParamSet is
-   used for all encryption operations.
-
-   The resulting encrypted key (CEK_ENC) is placed in
-   keyBlob.sessionEncryptedKey.encryptedKey field, it's mac (CEK_MAC) is
-   placed in keyBlob.sessionEncryptedKey.macKey field, and shared_ukm
-   (UKM) is placed in keyBlob.transportParameters.ukm field.
-
-   Actions of server:
-
-   Server MUST verify, that keyBlob.transportParameters.ukm is equal to
-   GOSTR3411(client_random|server_random)[0..7], before decrypting the
-   premaster_secret.
-
-   Server applies VKO GOST R 34.10-94 or VKO GOST R 34.10-2001,
-   (depending on the client public key type), and CryptoPro Key Unwrap
-   algorithm in the simillar manner to decrypt the premaster_secret.
-
-   Server MUST verify keyBlob.sessionEncryptedKey.macKey after
-   decrypting the premaster_secret.
-
-4.7  Certificate Verify
-
-   This message is used as described in section 7.4.8 of [TLS].  If the
-   client have sent both a client certificate and an ephemeral public
-   key, it MUST send a certificate verify message, as a proof of
-   possession of the private key for provided certificate.
-
-   The TLS structures are extended as follows:
-
-    enum { gost341094, gost34102001 }
-        SignatureAlgorithm;
-
-    select (SignatureAlgorithm) {
-        case gost341094:
-            digitally-signed struct {
-                opaque gost341194_hash[32];
-            };
-        case gost34102001:
-            digitally-signed struct {
-                opaque gost341194_hash[32];
-            };
-    } Signature;
-
-    CertificateVerify.signature.gostR3411_hash =
-        GOSTR3411(handshake_messages)
-
-
-
-Chudov, Leontiev              Informational                     [Page 7]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-4.8  Finished
-
-   This message is used as described in section 7.4.9 of [TLS].
-
-   Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label +
-                              GOSTR3411(handshake_messages)) [0..11]
-
-5  Security Considerations
-
-   It is RECOMMENDED that software applications verify signature values,
-   subject public keys and algorithm parameters to conform to
-   [GOSTR341001], [GOSTR341094] standards prior to their use.
-
-   Use of the same key for signature and key derivation is NOT
-   RECOMMENDED.
-
-   It is RECOMMENDED for both client and server to verify the private
-   key usage period, if this extension is present in the certificate.
-
-   The cipher suites TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 and
-   TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 proposed hereby, have
-   been analyzed by special certification laboratory of Scientific and
-   Technical Centre "ATLAS" in appropriate levels of
-   target_of_evaluation (TOE).
-
-   It is RECOMMENDED to subject the implementations of these cipher
-   suites to examination by an authorized agency with approved methods
-   of cryptographic analysis.
-
-6  Appendix ASN.1 Modules
-
-   Additional ASN.1 modules, referenced here, can be found in [CPALGS]
-   and [CPCMS].
-
-
-6.1  Gost-CryptoPro-TLS
-
-Gost-CryptoPro-TLS
-    { iso(1) member-body(2) ru(643) rans(2)
-      cryptopro(2) other(1) modules(1) gost-CryptoPro-TLS(16) 1 }
-DEFINITIONS ::=
-BEGIN
--- EXPORTS All --
--- The types and values defined in this module are exported for
--- use in the other ASN.1 modules contained within the Russian
--- Cryptography "GOST" & "GOST R" Specifications, and for the use
--- of other applications which will use them to access Russian
--- Cryptography services. Other applications may use them for
-
-
-
-Chudov, Leontiev              Informational                     [Page 8]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
--- their own purposes, but this will not constrain extensions and
--- modifications needed to maintain or improve the Russian
--- Cryptography service.
-    IMPORTS
-        Certificate,
-        AlgorithmIdentifier
-        FROM PKIX1Explicit88 {iso(1) identified-organization(3)
-        dod(6) internet(1) security(5) mechanisms(5) pkix(7)
-        id-mod(0) id-pkix1-explicit-88(1)}
-        id-CryptoPro-algorithms, gostR3410-EncryptionSyntax
-        FROM Cryptographic-Gost-Useful-Definitions
-            { iso(1) member-body(2) ru(643) rans(2)
-              cryptopro(2) other(1) modules(1)
-              cryptographic-Gost-Useful-Definitions(0) 1 }
-        GostR3410-KeyTransport
-        FROM GostR3410-EncryptionSyntax
-             gostR3410-EncryptionSyntax
-    ;
-    id-PRF-GostR3411-94 OBJECT IDENTIFIER ::=
-        { id-CryptoPro-algorithms prf-gostr3411-94(23) }
-    TLSProxyKeyTransportBlob ::=
-        SEQUENCE {
-            keyBlob GostR3410-KeyTransport,
-            cert    OCTET STRING
-        }
-    TLSGostKeyTransportBlob ::=
-        SEQUENCE {
-            keyBlob GostR3410-KeyTransport,
-            proxyKeyBlobs SEQUENCE OF
-                TLSProxyKeyTransportBlob OPTIONAL
-        }
-    TLSGostSrvKeyExchange ::=
-        SEQUENCE OF
-            OCTET STRING (CONSTRAINED BY {Certificate})
-    TLSGostExtensionHashHMACSelect ::=
-        SEQUENCE {
-            hashAlgorithm AlgorithmIdentifier,
-            hmacAlgorithm AlgorithmIdentifier,
-            prfAlgorithm AlgorithmIdentifier
-        }
-    TLSGostExtensionHashHMACSelectClient ::=
-        SEQUENCE OF
-            TLSGostExtensionHashHMACSelect
-    TLSGostExtensionHashHMACSelectServer ::=
-        TLSGostExtensionHashHMACSelect
-
-END -- Gost-CryptoPro-TLS
-
-
-
-
-Chudov, Leontiev              Informational                     [Page 9]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-7  References
-
-   Normative references:
-
-
-   [CPALGS]      V. Popov, I. Kurepkin, S. Leontiev, "Additional crypto-
-                 graphic algorithms for use with GOST 28147-89, GOST R
-                 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 algo-
-                 rithms.", September 2005, draft-popov-cryptopro-
-                 cpalgs-04.txt
-
-   [CPPK]        S. Leontiev, D. Shefanovskij, "Algorithms and Identi-
-                 fiers for the Internet X.509 Public Key Infrastructure
-                 Certificates and Certificate Revocation List (CRL),
-                 corresponding to the algorithms GOST R 34.10-94, GOST R
-                 34.10-2001, GOST R 34.11-94", September 2005, draft-
-                 ietf-pkix-gost-cppk-03.txt
-
-   [CPCMS]       S. Leontiev, G. Chudov, "Using the GOST 28147-89, GOST
-                 R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algo-
-                 rithms with the Cryptographic Message Syntax (CMS)",
-                 September 2005, draft-ietf-smime-gost-05.txt
-
-   [GOST28147]   "Cryptographic Protection for Data Processing System",
-                 GOST 28147-89, Gosudarstvennyi Standard of USSR, Gov-
-                 ernment Committee of the USSR for Standards, 1989. (In
-                 Russian);
-
-   [GOSTR341094] "Information technology. Cryptographic Data Security.
-                 Produce and check procedures of Electronic Digital Sig-
-                 natures based on Asymmetric Cryptographic Algorithm.",
-                 GOST R 34.10-94, Gosudarstvennyi Standard of Russian
-                 Federation, Government Committee of the Russia for
-                 Standards, 1994. (In Russian);
-
-   [GOSTR341001] "Information technology. Cryptographic Data Secu-
-                 rity.Signature and verification processes of [elec-
-                 tronic] digital signature.", GOST R 34.10-2001, Gosu-
-                 darstvennyi Standard of Russian Federation, Government
-                 Committee of the Russia for Standards, 2001. (In Rus-
-                 sian);
-
-   [GOSTR341194] "Information technology. Cryptographic Data Security.
-                 Hashing function.", GOST R 34.10-94, Gosudarstvennyi
-                 Standard of Russian Federation, Government Committee of
-                 the Russia for Standards, 1994. (In Russian);
-
-
-
-
-
-Chudov, Leontiev              Informational                    [Page 10]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-   [TLS]         The TLS Protocol Version 1.0.  T.  Dierks, C.  Allen.
-                 January 1999, RFC 2246.
-
-   Informative references:
-
-
-   [RFC 2119]    Bradner, S., "Key Words for Use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [Schneier95]  B.  Schneier, Applied cryptography, second edition,
-                 John Wiley & Sons, Inc., 1995;
-
-   [TLSEXT]      Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
-                 J. and T. Wright, "Transport Layer Security (TLS)
-                 Extensions", RFC 3546, June 2003.
-
-   [X.660]       ITU-T Recommendation X.660 Information Technology -
-                 ASN.1 encoding rules: Specification of Basic Encoding
-                 Rules (BER), Canonical Encoding Rules (CER) and Distin-
-                 guished Encoding Rules (DER), 1997.
-
-   [EAP-TLS]     B. Aboba, D. Simon, "PPP EAP TLS Authentication Proto-
-                 col", RFC 2716, October 1999.
-
-
-Acknowledgments
-
-   This document was created in accordance with "Russian Cryptographic
-   Software Compatibility Agreement", signed by FGUE STC "Atlas",
-   CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI),
-   Cryptocom, R-Alpha.  The aim of this agreement is to achieve mutual
-   compatibility of the products and solutions.
-
-   The authors wish to thank:
-
-      Microsoft Corporation Russia for provided information about
-      company products and solutions, and also for technical consulting
-      in PKI.
-
-      RSA Security Russia and Demos Co Ltd for active colaboration and
-      critical help in creation of this document.
-
-      NIP Informzachita for compatibility testing of the proposed data
-      formats while incorporating them into company products.
-
-      Citrix Inc for help in compatibility testing Citrix products for
-      Microsoft Windows.
-
-
-
-
-Chudov, Leontiev              Informational                    [Page 11]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-      Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and
-      Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative,
-      creating this document.
-
-   This document is based on a contribution of CRYPTO-PRO company.  Any
-   substantial use of the text from this document must acknowledge
-   CRYPTO-PRO.  CRYPTO-PRO requests that all material mentioning or
-   referencing this document identify this as "CRYPTO-PRO CPTLS".
-
-Author's Addresses
-
-   Grigorij Chudov
-   CRYPTO-PRO
-   38, Obraztsova,
-   Moscow, 127018, Russian Federation
-   EMail: chudov@cryptopro.ru
-
-   Serguei Leontiev
-   CRYPTO-PRO
-   38, Obraztsova,
-   Moscow, 127018, Russian Federation
-   EMail: lse@cryptopro.ru
-
-   Alexandr Afanasiev
-   Factor-TS
-   office 711, 14, Presnenskij val,
-   Moscow, 123557, Russian Federation
-   EMail: afa1@factor-ts.ru
-
-   Nikolaj Nikishin
-   Infotecs GmbH
-   p/b 35, 80-5, Leningradskij prospekt,
-   Moscow, 125315, Russian Federation
-   EMail: nikishin@infotecs.ru
-
-   Boleslav Izotov
-   FGUE STC "Atlas"
-   38, Obraztsova,
-   Moscow, 127018, Russian Federation
-   EMail: izotov@nii.voskhod.ru
-
-   Elena Minaeva
-   MD PREI
-   build 3, 6A, Vtoroj Troitskij per.,
-   Moscow, Russian Federation
-   EMail: evminaeva@mail.ru
-
-   Serguei Murugov
-
-
-
-Chudov, Leontiev              Informational                    [Page 12]
-
-Internet-Draft         GOST Cipher Suites for TLS         September 2005
-
-
-   R-Alpha
-   4/1, Raspletina,
-   Moscow, 123060, Russian Federation
-   EMail: msm@top-cross.ru
-
-   Igor Ustinov
-   Cryptocom
-   office 239, 51, Leninskij prospekt,
-   Moscow, 119991, Russian Federation
-   EMail: igus@cryptocom.ru
-
-   Anatolij Erkin
-   SPRCIS (SPbRCZI)
-   1, Obrucheva,
-   St.Petersburg, 195220, Russian Federation
-   EMail: erkin@nevsky.net
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Chudov, Leontiev              Informational                    [Page 13]
-
diff --git a/doc/protocol/draft-eronen-tls-psk-00.txt b/doc/protocol/draft-eronen-tls-psk-00.txt
deleted file mode 100644
index 8a3811083b..0000000000
--- a/doc/protocol/draft-eronen-tls-psk-00.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-Network Working Group                                          P. Eronen
-Internet-Draft                                                     Nokia
-Expires: August 6, 2004                                    H. Tschofenig
-                                                                 Siemens
-                                                        February 6, 2004
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-                      draft-eronen-tls-psk-00.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 6, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   This document specifies new ciphersuites for the Transport Layer
-   Security (TLS) protocol to support authentication based on pre-shared
-   keys. These pre-shared keys are symmetric keys, shared in advance
-   among the communicating parties, and do not require any public key
-   operations.
-
-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 [KEYWORDS].
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 1]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-1. Introduction
-
-   Usually TLS uses public key certificates [TLS] or Kerberos [TLS-KRB]
-   for authentication. This document describes how to use symmetric keys
-   (later called pre-shared keys or PSKs), shared in advance among the
-   communicating parties, to establish a TLS connection.
-
-   There are basically two reasons why one might want to do this:
-
-   o  First, TLS may be used in performance-constrained environments
-      where the CPU power needed for public key operations is not
-      available.
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view. For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-   This document specifies a number of new ciphersuites for TLS. These
-   ciphersuites use a new authentication and key exchange algorithm for
-   PSKs, and re-use existing cipher and MAC algorithms from [TLS] and
-   [TLS-AES].
-
-1.1 Applicability statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers. Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid PKIs, another possibility worth
-   considering is to use self-signed certificates with public key
-   fingerprints.  Instead of manually configuring a shared secret in,
-   for instance, some configuration file, a fingerprint (hash) of the
-   other party's public key (or certificate) could be placed there
-   instead.
-
-   It is also possible to use SRP for shared secret authentication
-   [TLS-SRP]. However, SRP requires more computational resources and may
-   have some IPR issues. However, it does provide protection against
-   dictionary attacks.
-
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 2]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-2. Protocol
-
-   It is assumed that the reader is familiar with ordinary TLS
-   handshake, shown below. The elements in parenthesis are not included
-   in PSK-based ciphersuites.
-
-      Client                                               Server
-      ------                                               ------
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                                ServerKeyExchange
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK-based ciphersuites in the
-   ClientHello message. The following ciphersuites are defined in this
-   document:
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA        = { 0x00, 0xTBD };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA   = { 0x00, 0xTBD };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA    = { 0x00, 0xTBD };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA    = { 0x00, 0xTBD };
-
-   Note that this document defines only a new authentication and key
-   exchange algorithm; see [TLS] and [TLS-AES] for description of the
-   cipher and MAC algorithms.
-
-   If the TLS server also wants to use pre-shared keys, it selects one
-   of the PSK ciphersuites, places the selected ciphersuite in the
-   ServerHello message, and includes an appropriate ServerKeyExchange
-   message (see below). The Certificate and CertificateRequest payloads
-   are omitted from the response.
-
-   Both clients and servers may have pre-shared keys with several
-   different parties. The client indicates which key to use by including
-   a "PSK identity" in the ClientKeyExchange message (note that unlike
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 3]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-   in [TLS-SHAREDKEYS], the session_id field in ClientHello message
-   keeps its usual meaning). To help the client in selecting which
-   identity to use, the server can provide a "PSK identity hint" in the
-   ServerKeyExchange message (note that if no hint is provided, a
-   ServerKeyExchange message is still sent).
-
-   This document does not specify the format of the PSK identity or PSK
-   identity hint; neither is specified how exactly the client uses the
-   hint (if it uses it at all). The parties have to agree on the
-   identities when the shared secret is configured (however, see Section
-   4 for related security considerations).
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                  ServerDHParams params;
-                  Signature signed_params;
-              case rsa:
-                  ServerRSAParams params;
-                  Signature signed_params;
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case psk: opaque psk_identity<0..2^16-1>;  /* NEW */
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows: concatenate 24 zero
-   octets, followed by SHA-1 hash [FIPS180-2] of the PSK itself,
-   followed by 4 zero octets.
-
-      Note: This effectively means that only the HMAC-SHA1 part of the
-      TLS PRF is used, and the HMAC-MD5 part is not used. See
-      [Krawczyk20040113] for a more detailed rationale. The PSK is first
-      hashed so that PSKs longer than 24 octets can be used; this is
-      similar to what is done in [HMAC] if the key length is longer than
-      the hash block size.
-
-   If the server does not recognize the PSK identity, it SHOULD respond
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 4]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-   with a decrypt_error alert message. This alert is also sent if
-   validating the Finished message fails. The use of the same alert
-   message makes it more difficult to find out which PSK identities are
-   known to the server.
-
-3. IANA considerations
-
-   This document does not define any new namespaces to be managed by
-   IANA. It does require assignment of several new ciphersuite numbers,
-   but it is unclear how this is done, since the TLS spec does not say
-   who is responsible for assigning them :-)
-
-4. Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-   The ciphersuites defined in this document do not provide Perfect
-   Forward Secrecy (PFS). That is, if the shared secret key is somehow
-   compromised, an attacker can decrypt old conversations. (Note that
-   the most popular TLS key exchange algorithm, RSA, does not provide
-   PFS either.)
-
-   Use of a fixed shared secret of limited entropy (such as a password)
-   allows an attacker to perform a brute-force or dictionary attack to
-   recover the secret. This may be either an off-line attack (against a
-   captured TLS conversation), or an on-line attack where the attacker
-   tries to connect to the server and tries different keys. Note that
-   the protocol requires the client to prove it knows the key first, so
-   just attempting to connect to a server does not reveal information
-   required for an off-line attack.  It is RECOMMENDED that
-   implementations that allow the administrator to manually configure
-   the PSK also provide a functionality for generating a new random PSK,
-   taking [RANDOMNESS] into account.
-
-   The PSK identity is sent in cleartext. While using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties. Even when
-   the identity does not reveal any information itself, reusing the same
-   identity over time may eventually allow an attacker to use traffic
-   analysis to the identify parties.  It should be noted that this is no
-   worse than client certificates, since they are also sent in
-   cleartext.
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 5]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-5. Acknowledgments
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [TLS-SHAREDKEYS]
-   and [TLS-AES]. Valuable feedback was also provided by Peter Gutmann
-   and Mika Tervonen.
-
-   When the first version of this draft was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [TLS-PASSAUTH]. However, this draft is not intended for web password
-   authentication, but rather other uses of TLS.
-
-Normative References
-
-   [KEYWORDS]
-              Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-   [TLS-AES]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites  for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RANDOMNESS]
-              Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-   [FIPS180-2]
-              National Institute of Standards and Technology,
-              "Specifications for the Secure Hash Standard",  Federal
-              Information Processing Standard (FIPS) Publication 180-2,
-              August 2002.
-
-Informative References
-
-   [TLS-SHAREDKEYS]
-              Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-              draft-ietf-tls-sharedkeys-02 (work in progress), October
-              2003.
-
-   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-              Keyed-Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [Krawczyk20040113]
-              Krawczyk, H., "Re: TLS shared keys PRF",  message on
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 6]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-              ietf-tls@lists.certicom.com mailing list 2004-01-13,
-              http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-   [TLS-KRB]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [TLS-PASSAUTH]
-              Simon, D., "Addition of Shared Key Authentication to
-              Transport Layer Security (TLS)",
-              draft-ietf-tls-passauth-00 (expired), November 1996.
-
-   [TLS-SRP]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,
-              "Using SRP for TLS Authentication", draft-ietf-tls-srp-06
-              (work in progress), January 2004.
-
-
-Authors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   EMail: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   EMail: Hannes.Tschofenig@siemens.com
-
-Appendix A. Comparison with draft-ietf-tls-sharedkeys-02 (informative)
-
-   [TLS-SHAREDKEYS] presents another way to use shared keys with TLS.
-   Instead of defining new ciphersuites, it re-uses the TLS session
-   cache and session resumption functionality.
-
-   The approach presented in this document is, in our opinion, more
-   elegant and better in line with the design of TLS. However, it does
-   probably require more changes to existing TLS implementations.
-   Nevertheless, these changes should be rather straightforward,
-   especially for implementations that already support multiple key
-   exchange algorithms and have a modular architecture.
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 7]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-   The changes required are roughly the following:
-
-   1. An API to pass psk_identities and keys around from the application
-      to the TLS library. Most likely, both push-style interface (use
-      this psk_identity and key) and callbacks (given a psk_identity,
-      fetch corresponding shared secret) would be useful.
-
-   2. An API to determine which psk_identity was used for a session.
-
-   3. PSK ciphersuite identifiers must be added to the list of supported
-      ciphersuites.
-
-   4. Processing of PSK messages in the handshake code.
-
-   The session-cache based approach probably requires the following
-   changes (depending on details of the TLS implementation):
-
-   1. Most TLS implementations do not expose an API that allows detailed
-      modification of the session cache, so some modifications are
-      required (especially if the implementation is done in some
-      reasonably type-safe language, the application cannot just use
-      some pointer tricks to access private data structures).
-
-      On the client side, we need an API to communicate session_id, key
-      and whatever is used to look up entries from the session cache
-      (for instance, some implementations use IP address and port
-      number) to the TLS implementation (and initialize other session
-      cache fields to some sensible values).
-
-      On the server side, we need to communicate session_id and key.
-      Most likely, both push-style interface (use this session_id and
-      key) and pull callbacks (given a session_id, fetch corresponding
-      shared secret) would be useful (but callbacks may require more
-      changes).
-
-   2. An API to determine which session_id was used (and to determine if
-      shared secret or normal RSA was used).
-
-   3. The session resumption code normally checks that resumed sessions
-      use the same ciphersuite as the original session. Unless a single
-      ciphersuite is hardcoded to the session cache, this code has to be
-      modified (and the session cache needs a flag indicating which
-      entries were created using ordinary handshake and which using
-      shared-secret API--unless the check is omitted for all sessions,
-      breaking TLS 1.0 rules).
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 8]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-   4. If the TLS implementation supports compression, resumed sessions
-      must use the same compression method as the original.  Either
-      compressions has to be disabled or this code modified.
-
-   5. TLS implementation should also check that the resumed session uses
-      the same protocol version; this needs changes as well, unless a
-      single version number is hardcoded.
-
-   6. The session cache code may need modifications to ensure the stored
-      entries actually stay there long enough to be useful. Currently
-      implementations are free to discard entries whenever they want.
-      However, probably most implementations would not require any
-      changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                 [Page 9]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                [Page 10]
-
-Internet-Draft          PSK Ciphersuites for TLS           February 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 6, 2004                [Page 11]
-
-
diff --git a/doc/protocol/draft-freier-ssl-version3-02.txt b/doc/protocol/draft-freier-ssl-version3-02.txt
deleted file mode 100644
index 533df80818..0000000000
--- a/doc/protocol/draft-freier-ssl-version3-02.txt
+++ /dev/null
@@ -1,3714 +0,0 @@
-Transport Layer Security Working Group                  Alan O. Freier
-INTERNET-DRAFT                                 Netscape Communications
-Expire in six months                                    Philip Karlton
-                                               Netscape Communications
-                                                        Paul C. Kocher
-                                                Independent Consultant
-                                                     November 18, 1996
-
-
-
-
-
-
-
-
-
-
-                          The SSL Protocol
-                            Version 3.0
-
-
-                  <draft-freier-ssl-version3-02.txt>
-
-
-
-
-
-
-
-Status of this memo
-
-   This document is an Internet-Draft.  Internet-Drafts are working
-   documents of the Internet Engineering Task Force (IETF), its areas,
-   and its working groups.  Note that other groups may also distribute
-   working documents as Internet- Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six
-   months and may be updated, replaced, or made obsolete 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.
-
-   To learn the current status of any Internet-Draft, please check the
-   1id-abstracts.txt listing contained in the Internet Drafts Shadow
-   Directories on ds.internic.net (US East Coast), nic.nordu.net
-   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
-   Rim).
-
-Abstract
-
-   This document specifies Version 3.0 of the Secure Sockets Layer
-   (SSL V3.0) protocol, a security protocol that provides
-   communications privacy over the Internet.  The protocol allows
-   client/server applications to communicate in a way that is designed
-   to prevent eavesdropping, tampering, or message forgery.
-
-
-Freier, Karlton, Kocher                                         [Page 1]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-Table of Contents
-           Status of this memo                                       1
-           Abstract                                                  1
-           Table of Contents                                         2
-   1.      Introduction                                              4
-   2.      Goals                                                     4
-   3.      Goals of this document                                    5
-   4.      Presentation language                                     5
-   4.1     Basic block size                                          5
-   4.2     Miscellaneous                                             6
-   4.3     Vectors                                                   6
-   4.4     Numbers                                                   7
-   4.5     Enumerateds                                               7
-   4.6     Constructed types                                         8
-   4.6.1   Variants                                                  8
-   4.7     Cryptographic attributes                                  9
-   4.8     Constants                                                10
-   5.      SSL protocol                                             10
-   5.1     Session and connection states                            10
-   5.2     Record layer                                             12
-   5.2.1   Fragmentation                                            12
-   5.2.2   Record compression and decompression                     13
-   5.2.3   Record payload protection and the CipherSpec             13
-   5.2.3.1 Null or standard stream cipher                           14
-   5.2.3.2 CBC block cipher                                         15
-   5.3     Change cipher spec protocol                              16
-   5.4     Alert protocol                                           16
-   5.4.1   Closure alerts                                           17
-   5.4.2   Error alerts                                             17
-   5.5     Handshake protocol overview                              18
-   5.6     Handshake protocol                                       20
-   5.6.1   Hello messages                                           21
-   5.6.1.1 Hello request                                            21
-   5.6.1.2 Client hello                                             21
-   5.6.1.3 Server hello                                             24
-   5.6.2   Server certificate                                       25
-   5.6.3   Server key exchange message                              25
-   5.6.4   Certificate request                                      27
-   5.6.5   Server hello done                                        27
-   5.6.6   Client certificate                                       28
-   5.6.7   Client key exchange message                              28
-   5.6.7.1 RSA encrypted premaster secret message                   28
-   5.6.7.2 FORTEZZA key exchange message                            29
-   5.6.7.3 Client Diffie-Hellman public value                       30
-   5.6.8   Certificate verify                                       30
-   5.6.9   Finished                                                 31
-   5.7     Application data protocol                                32
-   6.      Cryptographic computations                               32
-   6.1     Asymmetric cryptographic computations                    32
-   6.1.1   RSA                                                      32
-   6.1.2   Diffie-Hellman                                           33
-   6.1.3   FORTEZZA                                                 33
-
-Freier, Karlton, Kocher                                         [Page 2]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   6.2     Symmetric cryptographic calculations and the CipherSpec  33
-   6.2.1   The master secret                                        33
-   6.2.2   Converting the master secret into keys and MAC           33
-   6.2.2.1 Export key generation example                            35
-   A.      Protocol constant values                                 36
-   A.1     Reserved port assignments                                36
-   A.1.1   Record layer                                             36
-   A.2     Change cipher specs message                              37
-   A.3     Alert messages                                           37
-   A.4     Handshake protocol                                       37
-   A.4.1   Hello messages                                           38
-   A.4.2   Server authentication and key exchange messages          39
-   A.5     Client authentication and key exchange messages          40
-   A.5.1   Handshake finalization message                           41
-   A.6     The CipherSuite                                          41
-   A.7     The CipherSpec                                           42
-   B.      Glossary                                                 44
-   C.      CipherSuite definitions                                  47
-   D.      Implementation Notes                                     49
-   D.1     Temporary RSA keys                                       49
-   D.2     Random Number Generation and Seeding                     49
-   D.3     Certificates and authentication                          50
-   D.4     CipherSuites                                             50
-   D.5     FORTEZZA                                                 50
-   D.5.1   Notes on use of FORTEZZA hardware                        50
-   D.5.2   FORTEZZA Ciphersuites                                    51
-   D.5.3   FORTEZZA Session resumption                              51
-   E.      Version 2.0 Backward Compatibility                       52
-   E.1     Version 2 client hello                                   52
-   E.2     Avoiding man-in-the-middle version rollback              53
-   F.      Security analysis                                        55
-   F.1     Handshake protocol                                       55
-   F.1.1   Authentication and key exchange                          55
-   F.1.1.1 Anonymous key exchange                                   55
-   F.1.1.2 RSA key exchange and authentication                      56
-   F.1.1.3 Diffie-Hellman key exchange with authentication          57
-   F.1.1.4 FORTEZZA                                                 57
-   F.1.2   Version rollback attacks                                 57
-   F.1.3   Detecting attacks against the handshake protocol         58
-   F.1.4   Resuming sessions                                        58
-   F.1.5   MD5 and SHA                                              58
-   F.2     Protecting application data                              59
-   F.3     Final notes                                              59
-   G.      Patent Statement                                         60
-           References                                               61
-           Authors                                                  62
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                         [Page 3]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-1. Introduction
-
-   The primary goal of the SSL Protocol is to provide privacy and
-   reliability between two communicating applications.  The protocol
-   is composed of two layers.  At the lowest level, layered on top of
-   some reliable transport protocol (e.g., TCP[TCP]), is the SSL
-   Record Protocol.  The SSL Record Protocol is used for encapsulation
-   of various higher level protocols.  One such encapsulated protocol,
-   the SSL Handshake Protocol, allows the server and client to
-   authenticate each other and to negotiate an encryption algorithm
-   and cryptographic keys before the application protocol transmits or
-   receives its first byte of data.  One advantage of SSL is that it
-   is application protocol independent.  A higher level protocol can
-   layer on top of the SSL Protocol transparently.  The SSL protocol
-   provides connection security that has three basic properties:
-
-   -     The connection is private.  Encryption is used after an
-         initial handshake to define a secret key.  Symmetric
-         cryptography is used for data encryption (e.g., DES[DES],
-         RC4[RC4], etc.)
-   -     The peer's identity can be authenticated using asymmetric, or
-         public key, cryptography (e.g., RSA[RSA], DSS[DSS], etc.).
-   -     The connection is reliable.  Message transport includes a
-         message integrity check using a keyed MAC.  Secure hash
-         functions (e.g., SHA, MD5, etc.) are used for MAC
-         computations.
-
-2. Goals
-
-   The goals of SSL Protocol v3.0, in order of their priority,
-   are:
-     1. Cryptographic security
-                       SSL should be used to establish a secure
-                       connection between two parties.
-     2. Interoperability
-                       Independent programmers should be able to
-                       develop applications utilizing SSL 3.0 that
-                       will then be able to successfully exchange
-                       cryptographic parameters without knowledge of
-                       one another's code.
-
-   Note:          It is not the case that all instances of SSL (even
-                  in the same application domain) will be able to
-                  successfully connect.  For instance, if the server
-                  supports a particular hardware token, and the client
-                  does not have access to such a token, then the
-                  connection will not succeed.
-
-     3. Extensibility  SSL seeks to provide a framework into which new
-                       public key and bulk encryption methods can be
-                       incorporated as necessary.  This will also
-                       accomplish two sub-goals: to prevent the need
-
-Freier, Karlton, Kocher                                         [Page 4]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                       to create a new protocol (and risking the
-                       introduction of possible new weaknesses) and to
-                       avoid the need to implement an entire new
-                       security library.
-     4. Relative efficiency
-                       Cryptographic operations tend to be highly CPU
-                       intensive, particularly public key operations.
-                       For this reason, the SSL protocol has
-                       incorporated an optional session caching scheme
-                       to reduce the number of connections that need
-                       to be established from scratch.  Additionally,
-                       care has been taken to reduce network activity.
-
-3. Goals of this document
-
-   The SSL Protocol Version 3.0 Specification is intended primarily
-   for readers who will be implementing the protocol and those doing
-   cryptographic analysis of it.  The spec has been written with this
-   in mind, and it is intended to reflect the needs of those two
-   groups.  For that reason, many of the algorithm-dependent data
-   structures and rules are included in the body of the text (as
-   opposed to in an Appendix), providing easier access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation.  The following very basic and somewhat casually
-   defined presentation syntax will be used.  The syntax draws from
-   several sources in its structure.  Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels.
-   The purpose of this presentation language is to document SSL only,
-   not to have general application beyond that particular goal.
-
-4.1 Basic block size
-
-   The representation of all data items is explicitly specified.  The
-   basic data block size is one byte (i.e. 8 bits).  Multiple byte
-   data items are concatenations of bytes, from left to right, from
-   top to bottom.  From the bytestream a multi-byte item (a numeric in
-   the example) is formed (using C notation) by:
-
-     value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ...
-     | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-Freier, Karlton, Kocher                                         [Page 5]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-4.2 Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3 Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements.  The size of the vector may be specified at documentation
-   time or left unspecified until runtime.  In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector.  The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-     T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T.  The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-     opaque Datum[3];      /* three uninterpreted bytes */
-     Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable length vectors are defined by specifying a subrange of
-   legal lengths, inclusively, using the notation <floor..ceiling>.
-   When encoded, the actual length precedes the vector's contents in
-   the byte stream.  The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length.  A variable length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-     T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque.  It can never be empty.
-   The actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4).  On the other hand,
-   longer can represent up to 800 bytes of data, or 400 uint16
-   elements, and it may be empty.  Its encoding will include a two
-   byte actual length field prepended to the vector.
-
-     opaque mandatory<300..400>;
-           /* length field is 2 bytes, cannot be empty */
-     uint16 longer<0..800>;
-           /* zero to 400 16-bit unsigned integers */
-
-Freier, Karlton, Kocher                                         [Page 6]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-4.4 Numbers
-
-   The basic numeric data type is an unsigned byte (uint8).  All
-   larger numeric data types are formed from fixed length series of
-   bytes concatenated as described in Section 4.1 and are also
-   unsigned.  The following numeric types are predefined.
-
-     uint8 uint16[2];
-     uint8 uint24[3];
-     uint8 uint32[4];
-     uint8 uint64[8];
-
-4.5 Enumerateds
-
-   An additional sparse data type is available called enum.  A field
-   of type enum can only assume the values declared in the definition.
-   Each definition is a different type.  Only enumerateds of the same
-   type may be assigned or compared.  Every element of an enumerated
-   must be assigned a value, as demonstrated in the following example.
-   Since the elements of the enumerated are not ordered, they can be
-   assigned any unique value, in any order.
-
-     enum { e1(v1), e2(v2), ... , en(vn), [[(n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value.  The following definition would
-   cause one byte to be used to carry fields of type Color.
-
-     enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-     enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type.  In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue.  Such
-   qualification is not required if the target of the assignment is
-   well specified.
-
-     Color color = Color.blue;     /* overspecified, legal */
-     Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external
-   representation, the numerical information may be omitted.
-
-     enum { low, medium, high } Amount;
-
-
-
-Freier, Karlton, Kocher                                         [Page 7]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-4.6 Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience.  Each specification declares a new, unique type.  The
-   syntax for definition is much like that of C.
-
-   struct {
-       T1 f1;
-       T2 f2;
-       ...
-       Tn fn;
-   } [[T]];
-
-   The fields within a structure may be qualified using the type's
-   name using a syntax much like that available for enumerateds.  For
-   example, T.f2 refers to the second field of the previous
-   declaration.  Structure definitions may be embedded.
-
-4.6.1 Variants
-
-   Defined structures may have variants based on some knowledge that
-   is available within the environment.  The selector must be an
-   enumerated type that defines the possible variants the structure
-   defines.  There must be a case arm for every element of the
-   enumeration declared in the select.  The body of the variant
-   structure may be given a label for reference.  The mechanism by
-   which the variant is selected at runtime is not prescribed by the
-   presentation language.
-
-     struct {
-         T1 f1;
-         T2 f2;
-          ....
-         Tn fn;
-         select (E) {
-             case e1: Te1;
-             case e2: Te2;
-                 ....
-             case en: Ten;
-         } [[fv]];
-     } [[Tv]];
-
-   For example
-
-     enum { apple, orange } VariantTag;
-     struct {
-         uint16 number;
-         opaque string<0..10>; /* variable length */
-     } V1;
-
-
-
-
-Freier, Karlton, Kocher                                         [Page 8]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     struct {
-         uint32 number;
-         opaque string[10];    /* fixed length */
-     } V2;
-     struct {
-         select (VariantTag) { /* value of selector is implicit */
-             case apple: V1;   /* VariantBody, tag = apple */
-             case orange: V2;  /* VariantBody, tag = orange */
-         } variant_body;       /* optional label on variant */
-     } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a
-   value for the selector prior to the type.  For example, a
-
-     orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7 Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively.  A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification.  Cryptographic
-   keys are implied by the current session state (see Section 5.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm.  In RSA signing, a 36-byte structure of two
-   hashes (one SHA and one MD5) is signed (encrypted with the private
-   key).  In DSS, the 20 bytes of the SHA hash are run directly
-   through the Digital Signing Algorithm with no additional hashing.
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with
-   an identical amount of output generated from a
-   cryptographically-secure keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext.  Because it is unlikely that the plaintext
-   (whatever data is to be sent) will break neatly into the necessary
-   block size (usually 64 bits), it is necessary to pad out the end of
-   short blocks with some regular pattern, usually all zeroes.
-
-   In public key encryption, one-way functions with secret "trapdoors"
-   are used to encrypt the outgoing data.  Data encrypted with the
-   public key of a given key pair can only be decrypted with the
-   private key, and vice-versa.  In the following example:
-
-
-
-
-Freier, Karlton, Kocher                                         [Page 9]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     stream-ciphered struct {
-         uint8 field1;
-         uint8 field2;
-         digitally-signed opaque hash[20];
-     } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher.
-
-4.8 Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values.  No
-   fields of a multi-element structure or vector may be elided.
-
-   For example,
-     struct {
-         uint8 f1;
-         uint8 f2;
-     } Example1;
-
-     Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */
-
-5. SSL protocol
-
-   SSL is a layered protocol.  At each layer, messages may include
-   fields for length, description, and content.  SSL takes messages to
-   be transmitted, fragments the data into manageable blocks,
-   optionally compresses the data, applies a MAC, encrypts, and
-   transmits the result.  Received data is decrypted, verified,
-   decompressed, and reassembled, then delivered to higher level
-   clients.
-
-5.1 Session and connection states
-
-   An SSL session is stateful.  It is the responsibility of the SSL
-   Handshake protocol to coordinate the states of the client and
-   server, thereby allowing the protocol state machines of each to
-   operate consistently, despite the fact that the state is not
-   exactly parallel.  Logically the state is represented twice, once
-   as the current operating state, and (during the handshake protocol)
-   again as the pending state.  Additionally, separate read and write
-   states are maintained.  When the client or server receives a change
-   cipher spec message, it copies the pending read state into the
-   current read state.  When the client or server sends a change
-   cipher spec message, it copies the pending write state into the
-   current write state.  When the handshake negotiation is complete,
-   the client and server exchange change cipher spec messages (see
-   Section 5.3), and they then communicate using the newly agreed-upon
-   cipher spec.
-
-Freier, Karlton, Kocher                                        [Page 10]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   An SSL session may include multiple secure connections; in
-   addition, parties may have multiple simultaneous sessions.
-
-   The session state includes the following elements:
-
-     session identifier
-                       An arbitrary byte sequence chosen by the server
-                       to identify an active or resumable session
-                       state.
-     peer certificate  X509.v3[X509] certificate of the peer.  This
-                       element of the state may be null.
-     compression method
-                       The algorithm used to compress data prior to
-                       encryption.
-     cipher spec       Specifies the bulk data encryption algorithm
-                       (such as null, DES, etc.) and a MAC algorithm
-                       (such as MD5 or SHA).  It also defines
-                       cryptographic attributes such as the hash_size.
-                       (See Appendix A.7 for formal definition)
-     master secret     48-byte secret shared between the client and
-                       server.
-     is resumable      A flag indicating whether the session can be
-                       used to initiate new connections.
-
-   The connection state includes the following elements:
-
-     server and client random
-                       Byte sequences that are chosen by the server
-                       and client for each connection.
-     server write MAC secret
-                       The secret used in MAC operations on data
-                       written by the server
-     client write MAC secret
-                       The secret used in MAC operations on data
-                       written by the client.
-     server write key  The bulk cipher key for data encrypted by the
-                       server and decrypted by the client.
-     client write key  The bulk cipher key for data encrypted by the
-                       client and decrypted by the server.
-     initialization vectors
-                       When a block cipher in CBC mode is used, an
-                       initialization vector (IV) is maintained for
-                       each key.  This field is first initialized by
-                       the SSL handshake protocol.  Thereafter the
-                       final ciphertext block from each record is
-                       preserved for use with the following record.
-     sequence numbers  Each party maintains separate sequence numbers
-                       for transmitted and received messages for each
-                       connection.  When a party sends or receives a
-                       change cipher spec message, the appropriate
-                       sequence number is set to zero.  Sequence
-
-
-Freier, Karlton, Kocher                                        [Page 11]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                       numbers are of type uint64 and may not exceed
-                       2^64-1.
-
-5.2 Record layer
-
-   The SSL Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-5.2.1 Fragmentation
-
-   The record layer fragments information blocks into SSLPlaintext
-   records of 2^14 bytes or less.  Client message boundaries are not
-   preserved in the record layer (i.e., multiple client messages of
-   the same ContentType may be coalesced into a single SSLPlaintext
-   record).
-
-     struct {
-         uint8 major, minor;
-     } ProtocolVersion;
-
-     enum {
-         change_cipher_spec(20), alert(21), handshake(22),
-         application_data(23), (255)
-     } ContentType;
-
-     struct {
-         ContentType type;
-         ProtocolVersion version;
-         uint16 length;
-         opaque fragment[SSLPlaintext.length];
-     } SSLPlaintext;
-
-     type              The higher level protocol used to process the
-                       enclosed fragment.
-     version           The version of protocol being employed.  This
-                       document describes SSL Version 3.0 (See
-                       Appendix A.1.1).
-     length            The length (in bytes) of the following
-                       SSLPlaintext.fragment.  The length should not
-                       exceed 2^14.
-     fragment          The application data.  This data is transparent
-                       and treated as an independent block to be dealt
-                       with by the higher level protocol specified by
-                       the type field.
-
-   Note:          Data of different SSL Record layer content types may
-                  be interleaved.  Application data is generally of
-                  lower precedence for transmission than other content
-                  types.
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 12]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-5.2.2 Record compression and decompression
-
-   All records are compressed using the compression algorithm defined
-   in the current session state.  There is always an active
-   compression algorithm, however initially it is defined as
-   CompressionMethod.null.  The compression algorithm translates an
-   SSLPlaintext structure into an SSLCompressed structure.
-   Compression functions erase their state information whenever the
-   CipherSpec is replaced.
-
-   Note:          The CipherSpec is part of the session state
-                  described in Section 5.1.  References to fields of
-                  the CipherSpec are made throughout this document
-                  using presentation syntax.  A more complete
-                  description of the CipherSpec is shown in Appendix
-                  A.7.
-
-   Compression must be lossless and may not increase the content
-   length by more than 1024 bytes.  If the decompression function
-   encounters an SSLCompressed.fragment that would decompress to a
-   length in excess of 2^14 bytes, it should issue a fatal
-   decompression_failure alert (Section 5.4.2).
-
-     struct {
-         ContentType type;       /* same as SSLPlaintext.type */
-         ProtocolVersion version;/* same as SSLPlaintext.version */
-         uint16 length;
-         opaque fragment[SSLCompressed.length];
-     } SSLCompressed;
-
-     length            The length (in bytes) of the following
-                       SSLCompressed.fragment.  The length
-                       should not exceed 2^14 + 1024.
-     fragment          The compressed form of
-                       SSLPlaintext.fragment.
-
-   Note:          A CompressionMethod.null operation is an identity
-                  operation; no fields are altered.
-                  (See Appendix A.4.1)
-
-   Implementation note:
-                   Decompression functions are responsible for
-                   ensuring that messages cannot cause internal buffer
-                   overflows.
-
-5.2.3 Record payload protection and the CipherSpec
-
-   All records are protected using the encryption and MAC algorithms
-   defined in the current CipherSpec.  There is always an active
-   CipherSpec, however initially it is SSL_NULL_WITH_NULL_NULL, which
-   does not provide any security.
-
-
-Freier, Karlton, Kocher                                        [Page 13]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Once the handshake is complete, the two parties have shared secrets
-   which are used to encrypt records and compute keyed message
-   authentication codes (MACs) on their contents.  The techniques used
-   to perform the encryption and MAC operations are defined by the
-   CipherSpec and constrained by CipherSpec.cipher_type.  The
-   encryption and MAC functions translate an SSLCompressed structure
-   into an SSLCiphertext.  The decryption functions reverse the
-   process.  Transmissions also include a sequence number so that
-   missing, altered, or extra messages are detectable.
-
-     struct {
-         ContentType type;
-         ProtocolVersion version;
-         uint16 length;
-         select (CipherSpec.cipher_type) {
-             case stream: GenericStreamCipher;
-             case block: GenericBlockCipher;
-         } fragment;
-     } SSLCiphertext;
-
-     type              The type field is identical to
-                       SSLCompressed.type.
-     version           The version field is identical to
-                       SSLCompressed.version.
-     length            The length (in bytes) of the following
-                       SSLCiphertext.fragment.  The length may
-                       not exceed 2^14 + 2048.
-     fragment          The encrypted form of
-                       SSLCompressed.fragment, including the
-                       MAC.
-
-5.2.3.1 Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.7) convert SSLCompressed.fragment structures to and from stream
-   SSLCiphertext.fragment structures.
-
-     stream-ciphered struct {
-         opaque content[SSLCompressed.length];
-         opaque MAC[CipherSpec.hash_size];
-     } GenericStreamCipher;
-
-   The MAC is generated as:
-
-     hash(MAC_write_secret + pad_2 +
-          hash(MAC_write_secret + pad_1 + seq_num +
-               SSLCompressed.type + SSLCompressed.length +
-               SSLCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-
-
-Freier, Karlton, Kocher                                        [Page 14]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     pad_1             The character 0x36 repeated 48 times for MD5
-                       or 40 times for SHA.
-     pad_2             The character 0x5c repeated 48 times for MD5
-                       or 40 times for SHA.
-     seq_num           The sequence number for this message.
-     hash              Hashing algorithm derived from the cipher
-                       suite.
-
-   Note that the MAC is computed before encryption.  The stream cipher
-   encrypts the entire block, including the MAC.  For stream ciphers
-   that do not use a synchronization vector (such as RC4), the stream
-   cipher state from the end of one record is simply used on the
-   subsequent packet.  If the CipherSuite is SSL_NULL_WITH_NULL_NULL,
-   encryption consists of the identity operation (i.e., the data is
-   not encrypted and the MAC size is zero implying that no MAC is
-   used).  SSLCiphertext.length is SSLCompressed.length plus
-   CipherSpec.hash_size.
-
-5.2.3.2 CBC block cipher
-
-   For block ciphers (such as RC2 or DES), the encryption and MAC
-   functions convert SSLCompressed.fragment structures to and from
-   block SSLCiphertext.fragment structures.
-
-     block-ciphered struct {
-         opaque content[SSLCompressed.length];
-         opaque MAC[CipherSpec.hash_size];
-         uint8 padding[GenericBlockCipher.padding_length];
-         uint8 padding_length;
-     } GenericBlockCipher;
-
-   The MAC is generated as described in Section 5.2.3.1.
-
-     padding           Padding that is added to force the length of
-                       the plaintext to be a multiple of the block
-                       cipher's block length.
-     padding_length    The length of the padding must be less than the
-                       cipher's block length and may be zero.  The
-                       padding length should be such that the total
-                       size of the GenericBlockCipher structure is a
-                       multiple of the cipher's block length.
-
-   The encrypted data length (SSLCiphertext.length) is one more than
-   the sum of SSLCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
-   Note:          With CBC block chaining the initialization vector
-                  (IV) for the first record is provided by the
-                  handshake protocol.  The IV for subsequent records
-                  is the last ciphertext block from the previous
-                  record.
-
-
-Freier, Karlton, Kocher                                        [Page 15]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-5.3 Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies.  The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the
-   pending) CipherSpec.  The message consists of a single byte of
-   value 1.
-
-     struct {
-         enum { change_cipher_spec(1), (255) } type;
-     } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and
-   server to notify the receiving party that subsequent records will
-   be protected under the just-negotiated CipherSpec and keys.
-   Reception of this message causes the receiver to copy the read
-   pending state into the read current state.  The client sends a
-   change cipher spec message following handshake key exchange and
-   certificate verify messages (if any), and the server sends one
-   after successfully processing the key exchange message it received
-   from the client.  An unexpected change cipher spec message should
-   generate an unexpected_message alert (Section 5.4.2).  When
-   resuming a previous session, the change cipher spec message is sent
-   after the hello messages.
-
-5.4 Alert protocol
-
-   One of the content types supported by the SSL Record layer is the
-   alert type.  Alert messages convey the severity of the message and
-   a description of the alert.  Alert messages with a level of fatal
-   result in the immediate termination of the connection.  In this
-   case, other connections corresponding to the session may continue,
-   but the session identifier must be invalidated, preventing the
-   failed session from being used to establish new connections.  Like
-   other messages, alert messages are encrypted and compressed, as
-   specified by the current connection state.
-
-     enum { warning(1), fatal(2), (255) } AlertLevel;
-
-     enum {
-         close_notify(0),
-         unexpected_message(10),
-         bad_record_mac(20),
-         decompression_failure(30),
-         handshake_failure(40),
-         no_certificate(41),
-         bad_certificate(42),
-         unsupported_certificate(43),
-         certificate_revoked(44),
-         certificate_expired(45),
-         certificate_unknown(46),
-
-
-Freier, Karlton, Kocher                                        [Page 16]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-         illegal_parameter (47)
-         (255)
-     } AlertDescription;
-
-     struct {
-         AlertLevel level;
-         AlertDescription description;
-     } Alert;
-
-5.4.1 Closure alerts
-
-   The client and the server must share knowledge that the connection
-   is ending in order to avoid a truncation attack.  Either party may
-   initiate the exchange of closing messages.
-
-     close_notify      This message notifies the recipient that the
-                       sender will not send any more messages on this
-                       connection.  The session becomes unresumable if
-                       any connection is terminated without proper
-                       close_notify messages with level equal to
-                       warning.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Each party is required to send a close_notify alert before closing
-   the write side of the connection.  It is required that the other
-   party respond with a close_notify alert of its own and close down
-   the connection immediately, discarding any pending writes.  It is
-   not required for the initiator of the close to wait for the
-   responding close_notify alert before closing the read side of the
-   connection.
-
-   NB: It is assumed that closing a connection reliably delivers
-   pending data before destroying the transport.
-
-
-5.4.2 Error alerts
-
-   Error handling in the SSL Handshake protocol is very simple.  When
-   an error is detected, the detecting party sends a message to the
-   other party.  Upon transmission or receipt of an fatal alert
-   message, both parties immediately close the connection.  Servers
-   and clients are required to forget any session-identifiers, keys,
-   and secrets associated with a failed connection.  The following
-   error alerts are defined:
-
-     unexpected_message
-                       An inappropriate message was received.  This
-                       alert is always fatal and should never be
-                       observed in communication between proper
-                       implementations.
-
-Freier, Karlton, Kocher                                        [Page 17]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     bad_record_mac    This alert is returned if a record is received
-                       with an incorrect MAC.  This message is always
-                       fatal.
-     decompression_failure
-                       The decompression function received improper
-                       input (e.g. data that would expand to excessive
-                       length).  This message is always fatal.
-     handshake_failure Reception of a handshake_failure alert message
-                       indicates that the sender was unable to
-                       negotiate an acceptable set of security
-                       parameters given the options available.  This
-                       is a fatal error.
-     no_certificate    A no_certificate alert message may be sent in
-                       response to a certification request if no
-                       appropriate certificate is available.
-     bad_certificate   A certificate was corrupt, contained signatures
-                       that did not verify correctly, etc.
-     unsupported_certificate
-                       A certificate was of an unsupported type.
-     certificate_revoked
-                       A certificate was revoked by its signer.
-     certificate_expired
-                       A certificate has expired or is not currently
-                       valid.
-     certificate_unknown
-                       Some other (unspecified) issue arose in
-                       processing the certificate, rendering it
-                       unacceptable.
-     illegal_parameter A field in the handshake was out of range or
-                       inconsistent with other fields.  This is always
-                       fatal.
-
-5.5 Handshake protocol overview
-
-   The cryptographic parameters of the session state are produced by
-   the SSL Handshake Protocol, which operates on top of the SSL Record
-   Layer.  When a SSL client and server first start communicating,
-   they agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.  These processes are
-   performed in the handshake protocol, which can be summarized as
-   follows: The client sends a client hello message to which the
-   server must respond with a server hello message, or else a fatal
-   error will occur and the connection will fail.  The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server.  The client hello and
-   server hello establish the following attributes: Protocol Version,
-   Session ID, Cipher Suite, and Compression Method.  Additionally,
-   two random values are generated and exchanged: ClientHello.random
-   and ServerHello.random.
-
-
-
-Freier, Karlton, Kocher                                        [Page 18]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated.  Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only).  If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected.  Now
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete.  The server
-   will then wait for a client response.  If the server has sent a
-   certificate request Message, the client must send either the
-   certificate message or a no_certificate alert.  The client key
-   exchange message is now sent, and the content of that message will
-   depend on the public key algorithm selected between the client
-   hello and the server hello.  If the client has sent a certificate
-   with signing ability, a digitally-signed certificate verify message
-   is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current
-   Cipher Spec.  The client then immediately sends the finished
-   message under the new algorithms, keys, and secrets.  In response,
-   the server will send its own change cipher spec message, transfer
-   the pending to the current Cipher Spec, and send its finished
-   message under the new Cipher Spec.  At this point, the handshake is
-   complete and the client and server may begin to exchange
-   application layer data.  (See flow chart below.)
-
-   Client                                                Server
-
-   ClientHello                   -------->
-                                                    ServerHello
-                                                   Certificate*
-                                             ServerKeyExchange*
-                                            CertificateRequest*
-                                 <--------      ServerHelloDone
-   Certificate*
-   ClientKeyExchange
-   CertificateVerify*
-   [ChangeCipherSpec]
-   Finished                      -------->
-                                             [ChangeCipherSpec]
-                                 <--------             Finished
-   Application Data              <------->     Application Data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-   Note:          To help avoid pipeline stalls, ChangeCipherSpec is
-                  an independent SSL Protocol content type, and is not
-                  actually an SSL handshake message.
-
-
-
-Freier, Karlton, Kocher                                        [Page 19]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session
-   to be resumed.  The server then checks its session cache for a
-   match.  If a match is found, and the server is willing to
-   re-establish the connection under the specified session state, it
-   will send a ServerHello with the same Session ID value.  At this
-   point, both client and server must send change cipher spec messages
-   and proceed directly to finished messages.  Once the
-   re-establishment is complete, the client and server may begin to
-   exchange application layer data.  (See flow chart below.) If a
-   Session ID match is not found, the server generates a new session
-   ID and the SSL client and server perform a full handshake.
-
-   Client                                                Server
-
-   ClientHello                   -------->
-                                                    ServerHello
-                                           [change cipher spec]
-                                 <--------             Finished
-   change cipher spec
-   Finished                      -------->
-   Application Data              <------->     Application Data
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-5.6 Handshake protocol
-
-   The SSL Handshake Protocol is one of the defined higher level
-   clients of the SSL Record Protocol.  This protocol is used to
-   negotiate the secure attributes of a session.  Handshake messages
-   are supplied to the SSL Record Layer, where they are encapsulated
-   within one or more SSLPlaintext structures, which are processed and
-   transmitted as specified by the current active session state.
-
-     enum {
-         hello_request(0), client_hello(1), server_hello(2),
-         certificate(11), server_key_exchange (12),
-         certificate_request(13), server_hello_done(14),
-         certificate_verify(15), client_key_exchange(16),
-         finished(20), (255)
-     } HandshakeType;
-
-     struct {
-         HandshakeType msg_type;    /* handshake type */
-         uint24 length;             /* bytes in message */
-         select (HandshakeType) {
-             case hello_request: HelloRequest;
-             case client_hello: ClientHello;
-
-Freier, Karlton, Kocher                                        [Page 20]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-             case server_hello: ServerHello;
-             case certificate: Certificate;
-             case server_key_exchange: ServerKeyExchange;
-             case certificate_request: CertificateRequest;
-             case server_hello_done: ServerHelloDone;
-             case certificate_verify: CertificateVerify;
-             case client_key_exchange: ClientKeyExchange;
-             case finished: Finished;
-         } body;
-     } Handshake;
-
-   The handshake protocol messages are presented in the order they
-   must be sent; sending handshake messages in an unexpected order
-   results in a fatal error.
-
-5.6.1 Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server.  When a new session
-   begins, the CipherSpec encryption, hash, and compression algorithms
-   are initialized to null.  The current CipherSpec is used for
-   renegotiation messages.
-
-5.6.1.1 Hello request
-
-   The hello request message may be sent by the server at any time,
-   but will be ignored by the client if the handshake protocol is
-   already underway.  It is a simple notification that the client
-   should begin the negotiation process anew by sending a client hello
-   message when convenient.
-
-   Note:          Since handshake messages are intended to have
-                  transmission precedence over application data, it is
-                  expected that the negotiation begin in no more than
-                  one or two times the transmission time of a maximum
-                  length application data message.
-
-   After sending a hello request, servers should not repeat the
-   request until the subsequent handshake negotiation is complete.  A
-   client that receives a hello request while in a handshake
-   negotiation state should simply ignore the message.
-
-   The structure of a hello request message is as follows:
-
-     struct { } HelloRequest;
-
-5.6.1.2 Client hello
-
-   When a client first connects to a server it is required to send the
-   client hello as its first message.  The client can also send a
-   client hello in response to a hello request or on its own
-   initiative in order to renegotiate the security parameters in an
-
-Freier, Karlton, Kocher                                        [Page 21]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   existing connection.  The client hello message includes a random
-   structure, which is used later in the protocol.
-
-   struct {
-       uint32 gmt_unix_time;
-       opaque random_bytes[28];
-   } Random;
-
-     gmt_unix_time     The current time and date in standard UNIX
-                       32-bit format according to the sender's
-                       internal clock.  Clocks are not required to be
-                       set correctly by the basic SSL Protocol; higher
-                       level or application protocols may define
-                       additional requirements.
-     random_bytes      28 bytes generated by a secure random number
-                       generator.
-
-   The client hello message includes a variable length session
-   identifier.  If not empty, the value identifies a session between
-   the same client and server whose security parameters the client
-   wishes to reuse.  The session identifier may be from an earlier
-   connection, this connection, or another currently active
-   connection.  The second option is useful if the client only wishes
-   to update the random structures and derived values of a connection,
-   while the third option makes it possible to establish several
-   simultaneous independent secure connections without repeating the
-   full handshake protocol.  The actual contents of the SessionID are
-   defined by the server.
-
-     opaque SessionID<0..32>;
-
-   Warning:       Servers must not place confidential information in
-                  session identifiers or let the contents of fake
-                  session identifiers cause any breach of security.
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (first choice first).  Each CipherSuite defines both a
-   key exchange algorithm and a CipherSpec.  The server will select a
-   cipher suite or, if no acceptable choices are presented, return a
-   handshake failure alert and close the connection.
-
-     uint8 CipherSuite[2];  /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms
-   supported by the client, ordered according to the client's
-   preference.  If the server supports none of those specified by the
-   client, the session must fail.
-
-     enum { null(0), (255) } CompressionMethod;
-
-
-Freier, Karlton, Kocher                                        [Page 22]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Issue:         Which compression methods to support is under
-                  investigation.
-
-   The structure of the client hello is as follows.
-     struct {
-         ProtocolVersion client_version;
-         Random random;
-         SessionID session_id;
-         CipherSuite cipher_suites<2..2^16-1>;
-         CompressionMethod compression_methods<1..2^8-1>;
-     } ClientHello;
-
-     client_version    The version of the SSL protocol by which the
-                       client wishes to communicate during this
-                       session.  This should be the most recent
-                       (highest valued) version supported by the
-                       client.  For this version of the specification,
-                       the version will be 3.0 (See Appendix E for
-                       details about backward compatibility).
-     random            A client-generated random structure.
-     session_id        The ID of a session the client wishes to use
-                       for this connection.  This field should be
-                       empty if no session_id is available or the
-                       client wishes to generate new security
-                       parameters.
-     cipher_suites     This is a list of the cryptographic options
-                       supported by the client, sorted with the
-                       client's first preference first.  If the
-                       session_id field is not empty (implying a
-                       session resumption request) this vector must
-                       include at least the cipher_suite from that
-                       session.  Values are defined in Appendix A.6.
-     compression_methods
-                       This is a list of the compression methods
-                       supported by the client, sorted by client
-                       preference.  If the session_id field is not
-                       empty (implying a session resumption request)
-                       this vector must include at least the
-                       compression_method from that session.  All
-                       implementations must support
-                       CompressionMethod.null.
-
-   After sending the client hello message, the client waits for a
-   server hello message.  Any other handshake message returned by the
-   server except for a hello request is treated as a fatal error.
-
-   Implementation note:
-                  Application data may not be sent before a finished
-                  message has been sent.  Transmitted application data
-                  is known to be insecure until a valid finished
-                  message has been received.  This absolute
-
-
-Freier, Karlton, Kocher                                        [Page 23]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                  restriction is relaxed if there is a current,
-                  non-null encryption on this connection.
-
-   Forward compatibility note:
-                  In the interests of forward compatibility, it is
-                  permitted for a client hello message to include
-                  extra data after the compression methods.  This data
-                  must be included in the handshake hashes, but must
-                  otherwise be ignored.
-
-5.6.1.3 Server hello
-
-   The server processes the client hello message and responds with
-   either a handshake_failure alert or server hello message.
-
-     struct {
-         ProtocolVersion server_version;
-         Random random;
-         SessionID session_id;
-         CipherSuite cipher_suite;
-         CompressionMethod compression_method;
-     } ServerHello;
-
-     server_version    This field will contain the lower of that
-                       suggested by the client in the client hello and
-                       the highest supported by the server.  For this
-                       version of the specification, the version will
-                       be 3.0 (See Appendix E for details about
-                       backward compatibility).
-     random            This structure is generated by the server and
-                       must be different from (and independent of)
-                       ClientHello.random.
-     session_id        This is the identity of the session
-                       corresponding to this connection.  If the
-                       ClientHello.session_id was non-empty, the
-                       server will look in its session cache for a
-                       match.  If a match is found and the server is
-                       willing to establish the new connection using
-                       the specified session state, the server will
-                       respond with the same value as was supplied by
-                       the client.  This indicates a resumed session
-                       and dictates that the parties must proceed
-                       directly to the finished messages.  Otherwise
-                       this field will contain a different value
-                       identifying the new session.  The server may
-                       return an empty session_id to indicate that the
-                       session will not be cached and therefore cannot
-                       be resumed.
-     cipher_suite      The single cipher suite selected by the server
-                       from the list in ClientHello.cipher_suites.
-                       For resumed sessions this field is the value
-                       from the state of the session being resumed.
-
-Freier, Karlton, Kocher                                        [Page 24]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     compression_method
-                       The single compression algorithm selected by
-                       the server from the list in
-                       ClientHello.compression_methods.  For resumed
-                       sessions this field is the value from the
-                       resumed session state.
-
-5.6.2 Server certificate
-
-   If the server is to be authenticated (which is generally the case),
-   the server sends its certificate immediately following the server
-   hello message.  The certificate type must be appropriate for the
-   selected cipher suite's key exchange algorithm, and is generally an
-   X.509.v3 certificate (or a modified X.509 certificate in the case
-   of FORTEZZA(tm) [FOR]).  The same message type will be used for the
-   client's response to a certificate request message.
-
-     opaque ASN.1Cert<1..2^24-1>;
-     struct {
-         ASN.1Cert certificate_list<1..2^24-1>;
-     } Certificate;
-
-     certificate_list  This is a sequence (chain) of X.509.v3
-                       certificates, ordered with the sender's
-                       certificate first followed by any certificate
-                       authority certificates proceeding sequentially
-                       upward.
-
-   Note:          PKCS #7 [PKCS7] is not used as the format for the
-                  certificate vector because PKCS #6 [PKCS6] extended
-                  certificates are not used.  Also PKCS #7 defines a
-                  SET rather than a SEQUENCE, making the task of
-                  parsing the list more difficult.
-
-5.6.3 Server key exchange message
-
-   The server key exchange message is sent by the server if it has no
-   certificate, has a certificate only used for signing (e.g., DSS
-   [DSS] certificates, signing-only RSA [RSA] certificates), or
-   FORTEZZA KEA key exchange is used.  This message is not used if the
-   server certificate contains Diffie-Hellman [DH1] parameters.
-
-   Note:          According to current US export law, RSA moduli
-                  larger than 512 bits may not be used for key
-                  exchange in software exported from the US.  With
-                  this message, larger RSA keys may be used as
-                  signature-only certificates to sign temporary
-                  shorter RSA keys for key exchange.
-
-     enum { rsa, diffie_hellman, fortezza_kea }
-            KeyExchangeAlgorithm;
-
-
-Freier, Karlton, Kocher                                        [Page 25]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     struct {
-         opaque rsa_modulus<1..2^16-1>;
-         opaque rsa_exponent<1..2^16-1>;
-     } ServerRSAParams;
-
-     rsa_modulus       The modulus of the server's temporary RSA key.
-     rsa_exponent      The public exponent of the server's temporary
-                       RSA key.
-
-     struct {
-         opaque dh_p<1..2^16-1>;
-         opaque dh_g<1..2^16-1>;
-         opaque dh_Ys<1..2^16-1>;
-     } ServerDHParams;     /* Ephemeral DH parameters */
-
-     dh_p              The prime modulus used for the Diffie-Hellman
-                       operation.
-     dh_g              The generator used for the Diffie-Hellman
-                       operation.
-     dh_Ys             The server's Diffie-Hellman public value
-                       (gX mod p).
-
-     struct {
-         opaque r_s [128];
-     } ServerFortezzaParams;
-
-     r_s               Server random number for FORTEZZA KEA (Key
-                       Exchange Algorithm).
-
-     struct {
-         select (KeyExchangeAlgorithm) {
-             case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-             case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-             case fortezza_kea:
-                 ServerFortezzaParams params;
-         };
-     } ServerKeyExchange;
-
-     params            The server's key exchange parameters.
-     signed_params     A hash of the corresponding params value, with
-                       the signature appropriate to that hash applied.
-     md5_hash          MD5(ClientHello.random + ServerHello.random +
-                           ServerParams);
-     sha_hash          SHA(ClientHello.random + ServerHello.random +
-                           ServerParams);
-
-     enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-Freier, Karlton, Kocher                                        [Page 26]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     digitally-signed struct {
-         select(SignatureAlgorithm) {
-             case anonymous: struct { };
-             case rsa:
-                 opaque md5_hash[16];
-                 opaque sha_hash[20];
-             case dsa:
-                 opaque sha_hash[20];
-         };
-     } Signature;
-
-
-5.6.4 Certificate request
-
-   A non-anonymous server can optionally request a certificate from
-   the client, if appropriate for the selected cipher suite.
-
-     enum {
-         rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-         rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20),
-         (255)
-     } ClientCertificateType;
-
-     opaque DistinguishedName<1..2^16-1>;
-
-     struct {
-         ClientCertificateType certificate_types<1..2^8-1>;
-         DistinguishedName certificate_authorities<3..2^16-1>;
-     } CertificateRequest;
-
-     certificate_types This field is a list of the types of
-                       certificates requested, sorted in order of the
-                       server's preference.
-     certificate_authorities
-                       A list of the distinguished names of acceptable
-                       certificate authorities.
-
-   Note:          DistinguishedName is derived from [X509].
-
-   Note:          It is a fatal handshake_failure alert for an
-                  anonymous server to request client identification.
-
-5.6.5 Server hello done
-
-   The server hello done message is sent by the server to indicate the
-   end of the server hello and associated messages.  After sending
-   this message the server will wait for a client response.
-
-     struct { } ServerHelloDone;
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 27]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Upon receipt of the server hello done message the client should
-   verify that the server provided a valid certificate if required and
-   check that the server hello parameters are acceptable.
-
-5.6.6 Client certificate
-
-   This is the first message the client can send after receiving a
-   server hello done message.  This message is only sent if the server
-   requests a certificate.  If no suitable certificate is available,
-   the client should send a no_certificate alert instead.  This alert
-   is only a warning, however the server may respond with a fatal
-   handshake failure alert if client authentication is required.
-   Client certificates are sent using the Certificate defined in
-   Section 5.6.2.
-
-   Note:          Client Diffie-Hellman certificates must match the
-                  server specified Diffie-Hellman parameters.
-
-5.6.7 Client key exchange message
-
-   The choice of messages depends on which public key algorithm(s) has
-   (have) been selected.  See Section 5.6.3 for the
-   KeyExchangeAlgorithm definition.
-
-     struct {
-         select (KeyExchangeAlgorithm) {
-             case rsa: EncryptedPreMasterSecret;
-             case diffie_hellman: ClientDiffieHellmanPublic;
-             case fortezza_kea: FortezzaKeys;
-         } exchange_keys;
-     } ClientKeyExchange;
-
-   The information to select the appropriate record structure is in
-   the pending session state (see Section 5.1).
-
-5.6.7.1 RSA encrypted premaster secret message
-
-   If RSA is being used for key agreement and authentication, the
-   client generates a 48-byte pre-master secret, encrypts it under the
-   public key from the server's certificate or temporary RSA key from
-   a server key exchange message, and sends the result in an encrypted
-   premaster secret message.
-
-     struct {
-         ProtocolVersion client_version;
-         opaque random[46];
-     } PreMasterSecret;
-
-     client_version    The latest (newest) version supported by the
-                       client.  This is used to detect version
-                       roll-back attacks.
-     random            46 securely-generated random bytes.
-
-Freier, Karlton, Kocher                                        [Page 28]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     struct {
-         public-key-encrypted PreMasterSecret pre_master_secret;
-     } EncryptedPreMasterSecret;
-
-     pre_master_secret This random value is generated by the client
-                       and is used to generate the master secret, as
-                       specified in Section 6.1.
-
-5.6.7.2 FORTEZZA key exchange message
-
-   Under FORTEZZA, the client derives a Token Encryption Key (TEK)
-   using the FORTEZZA Key Exchange Algorithm (KEA).  The client's KEA
-   calculation uses the public key in the server's certificate along
-   with private parameters in the client's token.  The client sends
-   public parameters needed for the server to generate the TEK, using
-   its own private parameters.  The client generates session keys,
-   wraps them using the TEK, and sends the results to the server.  The
-   client generates IV's for the session keys and TEK and sends them
-   also.  The client generates a random 48-byte premaster secret,
-   encrypts it using the TEK, and sends the result:
-
-     struct {
-         opaque y_c<0..128>;
-         opaque r_c[128];
-         opaque y_signature[40];
-         opaque wrapped_client_write_key[12];
-         opaque wrapped_server_write_key[12];
-         opaque client_write_iv[24];
-         opaque server_write_iv[24];
-         opaque master_secret_iv[24];
-         block-ciphered opaque encrypted_pre_master_secret[48];
-     } FortezzaKeys;
-
-     y_signature       y_signature is the signature of the KEA public
-                       key, signed with the client's DSS private key.
-     y_c               The client's Yc value (public key) for the KEA
-                       calculation.  If the client has sent a
-                       certificate, and its KEA public key is
-                       suitable, this value must be empty since the
-                       certificate already contains this value.  If
-                       the client sent a certificate without a
-                       suitable public key, y_c is used and
-                       y_signature is the KEA public key signed with
-                       the client's DSS private key.  For this value
-                       to be used, it must be between 64 and 128
-                       bytes.
-     r_c               The client's Rc value for the KEA calculation.
-     wrapped_client_write_key
-                       This is the client's write key, wrapped by the
-                       TEK.
-
-
-
-Freier, Karlton, Kocher                                        [Page 29]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     wrapped_server_write_key
-                       This is the server's write key, wrapped by the
-                       TEK.
-     client_write_iv   The IV for the client write key.
-     server_write_iv   The IV for the server write key.
-     master_secret_iv  This is the IV for the TEK used to encrypt the
-                       pre-master secret.
-     pre_master_secret A random value, generated by the client and
-                       used to generate the master secret, as
-                       specified in Section 6.1.  In the the above
-                       structure, it is encrypted using the TEK.
-
-5.6.7.3 Client Diffie-Hellman public value
-
-   This structure conveys the client's Diffie-Hellman public value
-   (Yc) if it was not already included in the client's certificate.
-   The encoding used for Yc is determined by the enumerated
-   PublicValueEncoding.
-
-     enum { implicit, explicit } PublicValueEncoding;
-
-     implicit          If the client certificate already contains the
-                       public value, then it is implicit and Yc does
-                       not need to be sent again.
-     explicit          Yc needs to be sent.
-
-     struct {
-         select (PublicValueEncoding) {
-             case implicit: struct { };
-             case explicit: opaque dh_Yc<1..2^16-1>;
-         } dh_public;
-     } ClientDiffieHellmanPublic;
-
-     dh_Yc             The client's Diffie-Hellman public value (Yc).
-
-5.6.8 Certificate verify
-
-   This message is used to provide explicit verification of a client
-   certificate.  This message is only sent following any client
-   certificate that has signing capability (i.e. all certificates
-   except those containing fixed Diffie-Hellman parameters).
-
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-     CertificateVerify.signature.md5_hash
-                MD5(master_secret + pad_2 +
-                    MD5(handshake_messages + master_secret + pad_1));
-     Certificate.signature.sha_hash
-                SHA(master_secret + pad_2 +
-                    SHA(handshake_messages + master_secret + pad_1));
-
-Freier, Karlton, Kocher                                        [Page 30]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     pad_1      This is identical to the pad_1 defined in
-                section 5.2.3.1.
-     pad_2      This is identical to the pad_2 defined in
-                section 5.2.3.1.
-
-   Here handshake_messages refers to all handshake messages starting
-   at client hello up to but not including this message.
-
-5.6.9 Finished
-
-   A finished message is always sent immediately after a change cipher
-   specs message to verify that the key exchange and authentication
-   processes were successful.  The finished message is the first
-   protected with the just-negotiated algorithms, keys, and secrets.
-   No acknowledgment of the finished message is required; parties may
-   begin sending encrypted data immediately after sending the finished
-   message.  Recipients of finished messages must verify that the
-   contents are correct.
-
-     enum { client(0x434C4E54), server(0x53525652) } Sender;
-
-     struct {
-         opaque md5_hash[16];
-         opaque sha_hash[20];
-     } Finished;
-
-     md5_hash       MD5(master_secret + pad2 +
-                        MD5(handshake_messages + Sender +
-                            master_secret + pad1));
-     sha_hash        SHA(master_secret + pad2 +
-                         SHA(handshake_messages + Sender +
-                             master_secret + pad1));
-
-     handshake_messages    All of the data from all handshake messages
-                           up to but not including this message.  This
-                           is only data visible at the handshake layer
-                           and does not include record layer headers.
-
-   It is a fatal error if a finished message is not preceeded by a
-   change cipher spec message at the appropriate point in the
-   handshake.
-
-   The hash contained in finished messages sent by the server
-   incorporate Sender.server; those sent by the client incorporate
-   Sender.client.  The value handshake_messages includes all handshake
-   messages starting at client hello up to, but not including, this
-   finished message.  This may be different from handshake_messages in
-   Section 5.6.8 because it would include the certificate verify
-   message (if sent).
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 31]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Note:          Change cipher spec messages are not handshake
-                  messages and are not included in the hash
-                  computations.
-
-5.7 Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current
-   connection state.  The messages are treated as transparent data to
-   the record layer.
-
-6. Cryptographic computations
-
-   The key exchange, authentication, encryption, and MAC algorithms
-   are determined by the cipher_suite selected by the server and
-   revealed in the server hello message.
-
-6.1 Asymmetric cryptographic computations
-
-   The asymmetric algorithms are used in the handshake protocol to
-   authenticate parties and to generate shared keys and secrets.
-
-   For Diffie-Hellman, RSA, and FORTEZZA, the same algorithm is used
-   to convert the pre_master_secret into the master_secret.  The
-   pre_master_secret should be deleted from memory once the
-   master_secret has been computed.
-
-     master_secret =
-       MD5(pre_master_secret + SHA('A' + pre_master_secret +
-           ClientHello.random + ServerHello.random)) +
-       MD5(pre_master_secret + SHA('BB' + pre_master_secret +
-           ClientHello.random + ServerHello.random)) +
-       MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
-           ClientHello.random + ServerHello.random));
-
-6.1.1 RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted
-   under the server's public key, and sent to the server.  The server
-   uses its private key to decrypt the pre_master_secret.  Both
-   parties then convert the pre_master_secret into the master_secret,
-   as specified above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block
-   type 1.  RSA public key encryption is performed using PKCS #1 block
-   type 2.
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 32]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-6.1.2 Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed.  The
-   negotiated key (Z) is used as the pre_master_secret, and is
-   converted into the master_secret, as specified above.
-
-   Note:          Diffie-Hellman parameters are specified by the
-                  server, and may be either ephemeral or contained
-                  within the server's certificate.
-
-6.1.3 FORTEZZA
-
-   A random 48-byte pre_master_secret is sent encrypted under the TEK
-   and its IV.  The server decrypts the pre_master_secret and converts
-   it into a master_secret, as specified above.  Bulk cipher keys and
-   IVs for encryption are generated by the client's token and
-   exchanged in the key exchange message; the master_secret is only
-   used for MAC computations.
-
-6.2 Symmetric cryptographic calculations and the CipherSpec
-
-   The technique used to encrypt and verify the integrity of SSL
-   records is specified by the currently active CipherSpec.  A typical
-   example would be to encrypt data using DES and generate
-   authentication codes using MD5.  The encryption and MAC algorithms
-   are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL
-   Handshake Protocol, indicating that no message authentication or
-   encryption is performed.  The handshake protocol is used to
-   negotiate a more secure CipherSpec and to generate cryptographic
-   keys.
-
-6.2.1 The master secret
-
-   Before secure encryption or integrity verification can be performed
-   on records, the client and server need to generate shared secret
-   information known only to themselves.  This value is a 48-byte
-   quantity called the master secret.  The master secret is used to
-   generate keys and secrets for encryption and MAC computations.
-   Some algorithms, such as FORTEZZA, may have their own procedure for
-   generating encryption keys (the master secret is used only for MAC
-   computations in FORTEZZA).
-
-6.2.2 Converting the master secret into keys and MAC secrets
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets, keys, and non-export IVs required
-   by the current CipherSpec (see Appendix A.7).  CipherSpecs require
-   a client write MAC secret, a server write MAC secret, a client
-   write key, a server write key, a client write IV, and a server
-   write IV, which are generated from the master secret in that order.
-   Unused values, such as FORTEZZA keys communicated in the
-
-
-Freier, Karlton, Kocher                                        [Page 33]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   KeyExchange message, are empty.  The following inputs are available
-   to the key definition process:
-
-       opaque MasterSecret[48]
-       ClientHello.random
-       ServerHello.random
-
-   When generating keys and MAC secrets, the master secret is used as
-   an entropy source, and the random values provide unencrypted salt
-   material and IVs for exportable ciphers.
-
-   To generate the key material, compute
-
-     key_block =
-       MD5(master_secret + SHA(`A' + master_secret +
-                               ServerHello.random +
-                               ClientHello.random)) +
-       MD5(master_secret + SHA(`BB' + master_secret +
-                               ServerHello.random +
-                               ClientHello.random)) +
-       MD5(master_secret + SHA(`CCC' + master_secret +
-                               ServerHello.random +
-                               ClientHello.random)) + [...];
-
-   until enough output has been generated.  Then the key_block is
-   partitioned as follows.
-
-     client_write_MAC_secret[CipherSpec.hash_size]
-     server_write_MAC_secret[CipherSpec.hash_size]
-     client_write_key[CipherSpec.key_material]
-     server_write_key[CipherSpec.key_material]
-     client_write_IV[CipherSpec.IV_size] /* non-export ciphers */
-     server_write_IV[CipherSpec.IV_size] /* non-export ciphers */
-
-   Any extra key_block material is discarded.
-
-   Exportable encryption algorithms (for which
-   CipherSpec.is_exportable is true) require additional processing as
-   follows to derive their final write keys:
-
-     final_client_write_key = MD5(client_write_key +
-                                  ClientHello.random +
-                                  ServerHello.random);
-     final_server_write_key = MD5(server_write_key +
-                                  ServerHello.random +
-                                  ClientHello.random);
-
-   Exportable encryption algorithms derive their IVs from the random
-   messages:
-
-     client_write_IV = MD5(ClientHello.random + ServerHello.random);
-     server_write_IV = MD5(ServerHello.random + ClientHello.random);
-
-Freier, Karlton, Kocher                                        [Page 34]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   MD5 outputs are trimmed to the appropriate size by discarding the
-   least-significant bytes.
-
-6.2.2.1 Export key generation example
-
-   SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
-   each of the two encryption keys and 16 bytes for each of the MAC
-   keys, for a total of 42 bytes of key material.  MD5 produces 16
-   bytes of output per call, so three calls to MD5 are required.  The
-   MD5 outputs are concatenated into a 48-byte key_block with the
-   first MD5 call providing bytes zero through 15, the second
-   providing bytes 16 through 31, etc.  The key_block is partitioned,
-   and the write keys are salted because this is an exportable
-   encryption algorithm.
-
-     client_write_MAC_secret = key_block[0..15]
-     server_write_MAC_secret = key_block[16..31]
-     client_write_key      = key_block[32..36]
-     server_write_key      = key_block[37..41]
-     final_client_write_key = MD5(client_write_key +
-                                  ClientHello.random +
-                                  ServerHello.random)[0..15];
-     final_server_write_key = MD5(server_write_key +
-                                  ServerHello.random +
-                                  ClientHello.random)[0..15];
-     client_write_IV = MD5(ClientHello.random +
-                           ServerHello.random)[0..7];
-     server_write_IV = MD5(ServerHello.random +
-                           ClientHello.random)[0..7];
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 35]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                            Appendix A
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1 Reserved port assignments
-
-   At the present time SSL is implemented using TCP/IP as the base
-   networking technology.  The IANA reserved the following Internet
-   Protocol [IP] port numbers for use in conjunction with SSL.
-
-     443  Reserved for use by Hypertext Transfer Protocol with
-          SSL (https).
-     465  Reserved (pending) for use by Simple Mail Transfer Protocol
-          with SSL (ssmtp).
-     563  Reserved (pending) for use by Network News Transfer
-          Protocol (snntp).
-
-A.1.1 Record layer
-
-     struct {
-         uint8 major, minor;
-     } ProtocolVersion;
-
-     ProtocolVersion version = { 3,0 };
-
-     enum {
-         change_cipher_spec(20), alert(21), handshake(22),
-         application_data(23), (255)
-     } ContentType;
-
-     struct {
-         ContentType type;
-         ProtocolVersion version;
-         uint16 length;
-         opaque fragment[SSLPlaintext.length];
-     } SSLPlaintext;
-
-     struct {
-         ContentType type;
-         ProtocolVersion version;
-         uint16 length;
-         opaque fragment[SSLCompressed.length];
-     } SSLCompressed;
-
-     struct {
-         ContentType type;
-         ProtocolVersion version;
-         uint16 length;
-         select (CipherSpec.cipher_type) {
-             case stream: GenericStreamCipher;
-
-Freier, Karlton, Kocher                                        [Page 36]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-             case block:  GenericBlockCipher;
-         } fragment;
-     } SSLCiphertext;
-
-     stream-ciphered struct {
-         opaque content[SSLCompressed.length];
-         opaque MAC[CipherSpec.hash_size];
-     } GenericStreamCipher;
-
-     block-ciphered struct {
-         opaque content[SSLCompressed.length];
-         opaque MAC[CipherSpec.hash_size];
-         uint8 padding[GenericBlockCipher.padding_length];
-         uint8 padding_length;
-     } GenericBlockCipher;
-
-A.2 Change cipher specs message
-
-     struct {
-         enum { change_cipher_spec(1), (255) } type;
-     } ChangeCipherSpec;
-
-A.3 Alert messages
-
-     enum { warning(1), fatal(2), (255) } AlertLevel;
-
-     enum {
-         close_notify(0),
-         unexpected_message(10),
-         bad_record_mac(20),
-         decompression_failure(30),
-         handshake_failure(40),
-         no_certificate(41),
-         bad_certificate(42),
-         unsupported_certificate(43),
-         certificate_revoked(44),
-         certificate_expired(45),
-         certificate_unknown(46),
-         illegal_parameter (47),
-         (255)
-     } AlertDescription;
-
-     struct {
-         AlertLevel level;
-         AlertDescription description;
-     } Alert;
-
-A.4 Handshake protocol
-
-   enum {
-       hello_request(0), client_hello(1), server_hello(2),
-       certificate(11), server_key_exchange (12),
-
-Freier, Karlton, Kocher                                        [Page 37]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-       certificate_request(13), server_done(14),
-       certificate_verify(15), client_key_exchange(16),
-       finished(20), (255)
-   } HandshakeType;
-
-     struct {
-         HandshakeType msg_type;
-         uint24 length;
-         select (HandshakeType) {
-             case hello_request: HelloRequest;
-             case client_hello: ClientHello;
-             case server_hello: ServerHello;
-             case certificate: Certificate;
-             case server_key_exchange: ServerKeyExchange;
-             case certificate_request: CertificateRequest;
-             case server_done: ServerHelloDone;
-             case certificate_verify: CertificateVerify;
-             case client_key_exchange: ClientKeyExchange;
-             case finished: Finished;
-         } body;
-     } Handshake;
-
-A.4.1 Hello messages
-
-     struct { } HelloRequest;
-
-     struct {
-         uint32 gmt_unix_time;
-         opaque random_bytes[28];
-     } Random;
-
-     opaque SessionID<0..32>;
-
-     uint8 CipherSuite[2];
-
-     enum { null(0), (255) } CompressionMethod;
-
-     struct {
-         ProtocolVersion client_version;
-         Random random;
-         SessionID session_id;
-         CipherSuite cipher_suites<0..2^16-1>;
-         CompressionMethod compression_methods<0..2^8-1>;
-     } ClientHello;
-
-     struct {
-         ProtocolVersion server_version;
-         Random random;
-         SessionID session_id;
-         CipherSuite cipher_suite;
-         CompressionMethod compression_method;
-     } ServerHello;
-
-Freier, Karlton, Kocher                                        [Page 38]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-A.4.2 Server authentication and key exchange messages
-
-     opaque ASN.1Cert<2^24-1>;
-
-     struct {
-         ASN.1Cert certificate_list<1..2^24-1>;
-     } Certificate;
-
-     enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm;
-
-     struct {
-         opaque RSA_modulus<1..2^16-1>;
-         opaque RSA_exponent<1..2^16-1>;
-     } ServerRSAParams;
-
-     struct {
-         opaque DH_p<1..2^16-1>;
-         opaque DH_g<1..2^16-1>;
-         opaque DH_Ys<1..2^16-1>;
-     } ServerDHParams;
-
-     struct {
-         opaque r_s [128]
-     } ServerFortezzaParams
-
-     struct {
-         select (KeyExchangeAlgorithm) {
-             case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-             case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-             case fortezza_kea:
-                 ServerFortezzaParams params;
-         };
-     } ServerKeyExchange;
-
-     enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-     digitally-signed struct {
-         select(SignatureAlgorithm) {
-             case anonymous: struct { };
-             case rsa:
-                 opaque md5_hash[16];
-                 opaque sha_hash[20];
-             case dsa:
-                 opaque sha_hash[20];
-         };
-     } Signature;
-
-
-
-Freier, Karlton, Kocher                                        [Page 39]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     enum {
-         RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3),
-         DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6),
-         FORTEZZA_MISSI(20), (255)
-     } CertificateType;
-
-     opaque DistinguishedName<1..2^16-1>;
-
-     struct {
-         CertificateType certificate_types<1..2^8-1>;
-         DistinguishedName certificate_authorities<3..2^16-1>;
-     } CertificateRequest;
-
-     struct { } ServerHelloDone;
-
-A.5 Client authentication and key exchange messages
-
-     struct {
-         select (KeyExchangeAlgorithm) {
-             case rsa: EncryptedPreMasterSecret;
-             case diffie_hellman: DiffieHellmanClientPublicValue;
-             case fortezza_kea: FortezzaKeys;
-         } exchange_keys;
-     } ClientKeyExchange;
-
-     struct {
-         ProtocolVersion client_version;
-         opaque random[46];
-     } PreMasterSecret;
-
-     struct {
-         public-key-encrypted PreMasterSecret pre_master_secret;
-     } EncryptedPreMasterSecret;
-
-     struct {
-         opaque y_c<0..128>;
-         opaque r_c[128];
-         opaque y_signature[40];
-         opaque wrapped_client_write_key[12];
-         opaque wrapped_server_write_key[12];
-         opaque client_write_iv[24];
-         opaque server_write_iv[24];
-         opaque master_secret_iv[24];
-         opaque encrypted_preMasterSecret[48];
-     } FortezzaKeys;
-
-     enum { implicit, explicit } PublicValueEncoding;
-
-     struct {
-         select (PublicValueEncoding) {
-             case implicit: struct {};
-             case explicit: opaque DH_Yc<1..2^16-1>;
-
-Freier, Karlton, Kocher                                        [Page 40]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-         } dh_public;
-     } ClientDiffieHellmanPublic;
-
-     struct {
-         Signature signature;
-     } CertificateVerify;
-
-A.5.1 Handshake finalization message
-
-     struct {
-         opaque md5_hash[16];
-         opaque sha_hash[20];
-     } Finished;
-
-A.6 The CipherSuite
-
-   The following values define the CipherSuite codes used in the
-   client hello and server hello messages.
-
-   A CipherSuite defines a cipher specifications supported in SSL
-   Version 3.0.
-
-     CipherSuite SSL_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server
-   provide an RSA certificate that can be used for key exchange.  The
-   server may request either an RSA or a DSS signature-capable
-   certificate in the certificate request message.
-
-     CipherSuite SSL_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-     CipherSuite SSL_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-     CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-     CipherSuite SSL_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-     CipherSuite SSL_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-     CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-     CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-     CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-     CipherSuite SSL_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-     CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for
-   server-authenticated (and optionally client-authenticated)
-   Diffie-Hellman.  DH denotes cipher suites in which the server's
-   certificate contains the Diffie-Hellman parameters signed by the
-   certificate authority (CA).  DHE denotes ephemeral Diffie-Hellman,
-   where the Diffie-Hellman parameters are signed by a DSS or RSA
-   certificate, which has been signed by the CA.  The signing
-   algorithm used is specified after the DH or DHE parameter.  In all
-   cases, the client must have the same type of certificate, and must
-   use the Diffie-Hellman parameters chosen by the server.
-
-
-
-Freier, Karlton, Kocher                                        [Page 41]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-     CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-     CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-     CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-     CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-     CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-     CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-     CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-     CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-     CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-     CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-     CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous
-   Diffie-Hellman communications in which neither party is
-   authenticated.  Note that this mode is vulnerable to
-   man-in-the-middle attacks and is therefore strongly discouraged.
-
-     CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-     CipherSuite SSL_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-     CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-     CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-     CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   The final cipher suites are for the FORTEZZA token.
-
-     CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA         = { 0X00,0X1C };
-     CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D };
-     CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA      = { 0x00,0x1E };
-
-   Note:          All cipher suites whose first byte is 0xFF are
-                  considered private and can be used for defining
-                  local/experimental algorithms.  Interoperability of
-                  such types is a local matter.
-
-   Note:          Additional cipher suites will be considered for
-                  implementation only with submission of notarized
-                  letters from two independent entities.  Netscape
-                  Communications Corp. will act as an interim
-                  registration office, until a public standards body
-                  assumes control of SSL.
-
-A.7 The CipherSpec
-
-   A cipher suite identifies a CipherSpec.  These structures are part
-   of the SSL session state.  The CipherSpec includes:
-
-     enum { stream, block } CipherType;
-
-     enum { true, false } IsExportable;
-
-
-
-Freier, Karlton, Kocher                                        [Page 42]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     enum { null, rc4, rc2, des, 3des, des40, fortezza }
-         BulkCipherAlgorithm;
-
-     enum { null, md5, sha } MACAlgorithm;
-
-     struct {
-         BulkCipherAlgorithm bulk_cipher_algorithm;
-         MACAlgorithm mac_algorithm;
-         CipherType cipher_type;
-         IsExportable is_exportable
-         uint8 hash_size;
-         uint8 key_material;
-         uint8 IV_size;
-     } CipherSpec;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 43]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                            Appendix B
-
-B. Glossary
-     application protocol An application protocol is a protocol that
-                          normally layers directly on top of the
-                          transport layer (e.g., TCP/IP).  Examples
-                          include HTTP, TELNET, FTP, and SMTP.
-     asymmetric cipher    See public key cryptography.
-     authentication       Authentication is the ability of one entity
-                          to determine the identity of another entity.
-     block cipher         A block cipher is an algorithm that operates
-                          on plaintext in groups of bits, called
-                          blocks.  64 bits is a typical block size.
-     bulk cipher          A symmetric encryption algorithm used to
-                          encrypt large quantities of data.
-     cipher block chaining
-                          Mode (CBC) CBC is a mode in which every
-                          plaintext block encrypted with the block
-                          cipher is first exclusive-ORed with the
-                          previous ciphertext block (or, in the case
-                          of the first block, with the initialization
-                          vector).
-     certificate          As part of the X.509 protocol (a.k.a. ISO
-                          Authentication framework), certificates are
-                          assigned by a trusted Certificate Authority
-                          and provide verification of a party's
-                          identity and may also supply its public key.
-     client               The application entity that initiates a
-                          connection to a server.
-     client write key     The key used to encrypt data written by the
-                          client.
-     client write MAC secret
-                          The secret data used to authenticate data
-                          written by the client.
-     connection           A connection is a transport (in the OSI
-                          layering model definition) that provides a
-                          suitable type of service.  For SSL, such
-                          connections are peer to peer relationships.
-                          The connections are transient.  Every
-                          connection is associated with one session.
-     Data Encryption Standard
-                          (DES) DES is a very widely used symmetric
-                          encryption algorithm.  DES is a block
-                          cipher.
-     Digital Signature Standard
-                          (DSS) A standard for digital signing,
-                          including the Digital Signing Algorithm,
-                          approved by the National Institute of
-                          Standards and Technology, defined in NIST
-                          FIPS PUB 186, "Digital Signature Standard,"
-                          published May, 1994 by the U.S. Dept.  of
-                          Commerce.
-
-Freier, Karlton, Kocher                                        [Page 44]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     digital signatures   Digital signatures utilize public key
-                          cryptography and one-way hash functions to
-                          produce a signature of the data that can be
-                          authenticated, and is difficult to forge or
-                          repudiate.
-     FORTEZZA             A PCMCIA card that provides both encryption
-                          and digital signing.
-     handshake            An initial negotiation between client and
-                          server that establishes the parameters of
-                          their transactions.
-     Initialization Vector
-                          (IV) When a block cipher is used in CBC
-                          mode, the initialization vector is
-                          exclusive-ORed with the first plaintext
-                          block prior to encryption.
-     IDEA                 A 64-bit block cipher designed by Xuejia Lai
-                          and James Massey.
-     Message Authentication Code
-                          (MAC) A Message Authentication Code is a
-                          one-way hash computed from a message and
-                          some secret data.  Its purpose is to detect
-                          if the message has been altered.
-     master secret        Secure secret data used for generating
-                          encryption keys, MAC secrets, and IVs.
-     MD5                  MD5 [7] is a secure hashing function that
-                          converts an arbitrarily long data stream
-                          into a digest of fixed size.
-     public key cryptography
-                          A class of cryptographic techniques
-                          employing two-key ciphers.  Messages
-                          encrypted with the public key can only be
-                          decrypted with the associated private key.
-                          Conversely, messages signed with the private
-                          key can be verified with the public key.
-     one-way hash function
-                          A one-way transformation that converts an
-                          arbitrary amount of data into a fixed-length
-                          hash.  It is computation- ally hard to
-                          reverse the transformation or to find
-                          collisions.  MD5 and SHA are examples of
-                          one-way hash functions.
-     RC2, RC4             Proprietary bulk ciphers from RSA Data
-                          Security, Inc.  (There is no good reference
-                          to these as they are unpublished works;
-                          however, see [RSADSI]).  RC2 is block cipher
-                          and RC4 is a stream cipher.
-     RSA                  A very widely used public-key algorithm that
-                          can be used for either encryption or digital
-                          signing.
-     salt                 Non-secret random data used to make export
-                          encryption keys resist precomputation
-                          attacks.
-
-Freier, Karlton, Kocher                                        [Page 45]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-     server               The server is the application entity that
-                          responds to requests for connections from
-                          clients.  The server is passive, waiting for
-                          requests from clients.
-     session              A SSL session is an association between a
-                          client and a server.  Sessions are created
-                          by the handshake protocol.  Sessions define
-                          a set of cryptographic security parameters,
-                          which can be shared among multiple
-                          connections.  Sessions are used to avoid the
-                          expensive negotiation of new security
-                          parameters for each connection.
-     session identifier   A session identifier is a value generated by
-                          a server that identifies a particular
-                          session.
-     server write key     The key used to encrypt data written by the
-                          server.
-     server write MAC secret
-                          The secret data used to authenticate data
-                          written by the server.
-     SHA                  The Secure Hash Algorithm is defined in FIPS
-                          PUB 180-1.  It produces a 20-byte output
-                          [SHA].
-     stream cipher        An encryption algorithm that converts a key
-                          into a cryptographically-strong keystream,
-                          which is then exclusive-ORed with the
-                          plaintext.
-     symmetric cipher     See bulk cipher.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 46]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                            Appendix C
-
-C. CipherSuite definitions
-
-CipherSuite                  Is         Key            Cipher       Hash
-                             Exportable Exchange
-
-SSL_NULL_WITH_NULL_NULL               * NULL           NULL         NULL
-SSL_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5
-SSL_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA
-SSL_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5
-SSL_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-SSL_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5
-SSL_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-SSL_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA
-SSL_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-SSL_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA
-SSL_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA
-SSL_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA
-SSL_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA
-SSL_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-SSL_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5
-SSL_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA
-SSL_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-SSL_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-SSL_FORTEZZA_KEA_WITH_NULL_SHA          FORTEZZA_KEA   NULL         SHA
-SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA  FORTEZZA_KEA   FORTEZZA_CBC SHA
-SSL_FORTEZZA_KEA_WITH_RC4_128_SHA       FORTEZZA_KEA   RC4_128      SHA
-
-   * Indicates IsExportable is True
-
-   Key             Description                        Key size limit
-   Exchange
-   Algorithm
-   DHE_DSS         Ephemeral DH with DSS signatures   None
-   DHE_DSS_EXPORT  Ephemeral DH with DSS signatures   DH = 512 bits
-   DHE_RSA         Ephemeral DH with RSA signatures   None
-   DHE_RSA_EXPORT  Ephemeral DH with RSA signatures   DH = 512 bits,
-                                                      RSA = none
-   DH_anon         Anonymous DH, no signatures        None
-   DH_anon_EXPORT  Anonymous DH, no signatures        DH = 512 bits
-   DH_DSS          DH with DSS-based certificates     None
-
-Freier, Karlton, Kocher                                        [Page 47]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   DH_DSS_EXPORT   DH with DSS-based certificates     DH = 512 bits
-   DH_RSA          DH with RSA-based certificates     None
-   DH_RSA_EXPORT   DH with RSA-based certificates     DH = 512 bits,
-                                                      RSA = none
-   FORTEZZA_KEA    FORTEZZA KEA. Details unpublished  N/A
-   NULL            No key exchange                    N/A
-   RSA             RSA key exchange                   None
-   RSA_EXPORT      RSA key exchange                   RSA = 512 bits
-
-     Key size limit    The key size limit gives the size of the
-                       largest public key that can be legally
-                       used for encryption in cipher suites that
-                       are exportable.
-
-   Cipher      Cipher IsExpo  Key      Exp.    Effect  IV      Block
-               Type   rtable  Material Key Mat ive Key Size    Size
-                                       erial   Bits
-                                              
-   NULL          Stream *      0       0       0       0       N/A
-   FORTEZZA_CBC  Block         NA(**)  12(**)  96(**)  20(**)  8
-   IDEA_CBC      Block         16      16      128     8       8
-   RC2_CBC_40    Block  *      5       16      40      8       8
-   RC4_40        Stream *      5       16      40      0       N/A
-   RC4_128       Stream        16      16      128     0       N/A
-   DES40_CBC     Block  *      5       8       40      8       8
-   DES_CBC       Block         8       8       56      8       8
-   3DES_EDE_CBC  Block         24      24      168     8       8
-
-   * Indicates IsExportable is true.
-   ** FORTEZZA uses its own key and IV generation algorithms.
-
-     Key Material      The number of bytes from the key_block that are
-                       used for generating the write keys.
-     Expanded Key Material
-                       The number of bytes actually fed into the
-                       encryption algorithm.
-     Effective Key Bits
-                       How much entropy material is in the key
-                       material being fed into the encryption
-                       routines.
-
-   Hash       Hash Size  Padding
-   function              Size
-   NULL       0          0
-   MD5        16         48
-   SHA        20         40
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 48]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                            Appendix D
-
-D. Implementation Notes
-
-   The SSL protocol cannot prevent many common security mistakes.
-   This section provides several recommendations to assist
-   implementers.
-
-
-D.1 Temporary RSA keys
-
-   US Export restrictions limit RSA keys used for encryption to 512
-   bits, but do not place any limit on lengths of RSA keys used for
-   signing operations.  Certificates often need to be larger than 512
-   bits, since 512-bit RSA keys are not secure enough for high-value
-   transactions or for applications requiring long-term security.
-   Some certificates are also designated signing-only, in which case
-   they cannot be used for key exchange.
-
-   When the public key in the certificate cannot be used for
-   encryption, the server signs a temporary RSA key, which is then
-   exchanged.  In exportable applications, the temporary RSA key
-   should be the maximum allowable length (i.e., 512 bits).  Because
-   512-bit RSA keys are relatively insecure, they should be changed
-   often.  For typical electronic commerce applications, it is
-   suggested that keys be changed daily or every 500 transactions, and
-   more often if possible.  Note that while it is acceptable to use
-   the same temporary key for multiple transactions, it must be signed
-   each time it is used.
-
-   RSA key generation is a time-consuming process.  In many cases, a
-   low-priority process can be assigned the task of key generation.
-   Whenever a new key is completed, the existing temporary key can be
-   replaced with the new one.
-
-D.2 Random Number Generation and Seeding
-
-   SSL requires a cryptographically-secure pseudorandom number
-   generator (PRNG).  Care must be taken in designing and seeding
-   PRNGs.  PRNGs based on secure hash operations, most notably MD5
-   and/or SHA, are acceptable, but cannot provide more security than
-   the size of the random number generator state.  (For example,
-   MD5-based PRNGs usually provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte.  For
-   example, keystroke timing values taken from a PC- compatible's 18.2
-   Hz timer provide 1 or 2 secure bits each, even though the total
-   size of the counter value is 16 bits or more.  To seed a 128-bit
-   PRNG, one would thus require approximately 100 such timer values.
-
-
-
-Freier, Karlton, Kocher                                        [Page 49]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Note:          The seeding functions in RSAREF and versions of
-                  BSAFE prior to 3.0 are order-independent.  For
-                  example, if 1000 seed bits are supplied, one at a
-                  time, in 1000 separate calls to the seed function,
-                  the PRNG will end up in a state which depends only
-                  on the number of 0 or 1 seed bits in the seed data
-                  (i.e., there are 1001 possible final states).
-                  Applications using BSAFE or RSAREF must take extra
-                  care to ensure proper seeding.
-
-D.3 Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages.  Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA).  The selection and
-   addition of trusted CAs should be done very carefully.  Users
-   should be able to view information about the certificate and root
-   CA.
-
-D.4 CipherSuites
-
-   SSL supports a range of key sizes and security levels, including
-   some which provide no or minimal security.  A proper implementation
-   will probably not support many cipher suites.  For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys.  Similarly, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent
-   man-in-the- middle attacks.  Applications should also enforce
-   minimum and maximum key sizes.  For example, certificate chains
-   containing 512-bit RSA keys or signatures are not appropriate for
-   high-security applications.
-
-D.5 FORTEZZA
-
-   This section describes implementation details for ciphersuites that
-   make use of the FORTEZZA hardware encryption system.
-
-D.5.1 Notes on use of FORTEZZA hardware
-
-   A complete explanation of all issues regarding the use of FORTEZZA
-   hardware is outside the scope of this document.  However, there are
-   a few special requirements of SSL that deserve mention.
-
-   Because SSL is a full duplex protocol, two crypto states must be
-   maintained, one for reading and one for writing.  There are also a
-   number of circumstances which can result in the crypto state in the
-   FORTEZZA card being lost.  For these reasons, it's recommended that
-   the current crypto state be saved after processing a record, and
-   loaded before processing the next.
-
-
-
-Freier, Karlton, Kocher                                        [Page 50]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   After the client generates the TEK, it also generates two MEKs,
-   for one for reading and one for writing.  After generating each of
-   these keys, the client must generate a corresponding IV and then
-   save the crypto state.  The client also uses the TEK to generate an
-   IV and encrypt the premaster secret.  All three IVs are sent to the
-   server, along with the wrapped keys and the encrypted premaster
-   secret in the client key exchange message.  At this point, the TEK
-   is no longer needed, and may be discarded.
-
-   On the server side, the server uses the master IV and the TEK to
-   decrypt the premaster secret.  It also loads the wrapped MEKs into
-   the card.  The server loads both IVs to verify that the IVs match
-   the keys.  However, since the card is unable to encrypt after
-   loading an IV, the server must generate a new IV for the server
-   write key.  This IV is discarded.
-
-   When encrypting the first encrypted record (and only that record),
-   the server adds 8 bytes of random data to the beginning of the
-   fragment.  These 8 bytes are discarded by the client after
-   decryption.  The purpose of this is to synchronize the state on the
-   client and server resulting from the different IVs.
-
-D.5.2 FORTEZZA Ciphersuites
-
-   5) FORTEZZA_NULL_WITH_NULL_SHA:
-     Uses the full FORTEZZA key exchange, including sending server and
-     client write keys and iv's.
-
-D.5.3 FORTEZZA Session resumption
-
-   There are two possibilities for FORTEZZA session restart:
-   1) Never restart a FORTEZZA session.
-   2) Restart a session with the previously negotiated keys and iv's.
-
-   Never restarting a FORTEZZA session:
-
-   Clients who never restart FORTEZZA sessions should never send
-   Session ID's which were previously used in a FORTEZZA session as
-   part of the ClientHello.  Servers who never restart FORTEZZA
-   sessions should never send a previous session id on the
-   ServerHello if the negotiated session is FORTEZZA.
-
-   Restart a session:
-
-   You cannot restart FORTEZZA on a session which has never done a
-   complete FORTEZZA key exchange (That is you cannot restart FORTEZZA
-   if the session was an RSA/RC4 session renegotiated for FORTEZZA).
-   If you wish to restart a FORTEZZA session, you must save the MEKs
-   and IVs from the initial key exchange for this session and reuse
-   them for any new connections on that session.  This is not
-   recommended, but it is possible.
-
-
-Freier, Karlton, Kocher                                        [Page 51]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                             Appendix E
-
-E. Version 2.0 Backward Compatibility
-
-   Version 3.0 clients that support Version 2.0 servers must send
-   Version 2.0 client hello messages [SSL-2].  Version 3.0 servers
-   should accept either client hello format.  The only deviations from
-   the Version 2.0 specification are the ability to specify a version
-   with a value of three and the support for more ciphering types in
-   the CipherSpec.
-
-   Warning:       The ability to send Version 2.0 client hello
-                  messages will be phased out with all due haste.
-                  Implementers should make every effort to move
-                  forward as quickly as possible.  Version 3.0
-                  provides better mechanisms for transitioning to
-                  newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0.  These are assumed to use RSA for key exchange and
-   authentication.
-
-     V2CipherSpec SSL_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-     V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-     V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-     V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                = { 0x04,0x00,0x80 };
-     V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-     V2CipherSpec SSL_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-     V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications introduced in Version 3.0 can be included in
-   Version 2.0 client hello messages using the syntax below.  Any
-   V2CipherSpec element with its first byte equal to zero will be
-   ignored by Version 2.0 servers.  Clients sending any of the above
-   V2CipherSpecs should also include the Version 3.0 equivalent (see
-   Appendix A.6):
-
-     V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite };
-
-E.1 Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model.  The true definition is still
-   assumed to be the SSL Version 2.0 specification.
-
-     uint8 V2CipherSpec[3];
-
-     struct {
-         unit8 msg_type;
-         Version version;
-         uint16 cipher_spec_length;
-
-Freier, Karlton, Kocher                                        [Page 52]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-         uint16 session_id_length;
-         uint16 challenge_length;
-         V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-         opaque session_id[V2ClientHello.session_id_length];
-         Random challenge;
-     } V2ClientHello;
-
-     msg_type          This field, in conjunction with the version
-                       field, identifies a version 2 client hello
-                       message.  The value should equal one (1).
-     version           The highest version of the protocol supported
-                       by the client (equals ProtocolVersion.version,
-                       see Appendix A.1.1).
-     cipher_spec_length
-                       This field is the total length of the field
-                       cipher_specs.  It cannot be zero and must be a
-                       multiple of the V2CipherSpec length (3).
-     session_id_length This field must have a value of either zero or
-                       16.  If zero, the client is creating a new
-                       session.  If 16, the session_id field will
-                       contain the 16 bytes of session identification.
-     challenge_length  The length in bytes of the client's challenge
-                       to the server to authenticate itself.  This
-                       value must be 32.
-     cipher_specs      This is a list of all CipherSpecs the client is
-                       willing and able to use.  There must be at
-                       least one CipherSpec acceptable to the server.
-     session_id        If this field's length is not zero, it will
-                       contain the identification for a session that
-                       the client wishes to resume.
-     challenge         The client's challenge to the server for the
-                       server to identify itself is a (nearly)
-                       arbitrary length random.  The Version 3.0
-                       server will right justify the challenge data to
-                       become the ClientHello.random data (padded with
-                       leading zeroes, if necessary), as specified in
-                       this Version 3.0 protocol.  If the length of
-                       the challenge is greater than 32 bytes, then
-                       only the last 32 bytes are used.  It is
-                       legitimate (but not necessary) for a V3 server
-                       to reject a V2 ClientHello that has fewer than
-                       16 bytes of challenge data.
-
-   Note:          Requests to resume an SSL 3.0 session should use an
-                  SSL 3.0 client hello.
-
-E.2 Avoiding man-in-the-middle version rollback
-
-   When SSL Version 3.0 clients fall back to Version 2.0 compatibility
-   mode, they use special PKCS #1 block formatting.  This is done so
-   that Version 3.0 servers will reject Version 2.0 sessions with
-   Version 3.0-capable clients.
-
-Freier, Karlton, Kocher                                        [Page 53]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-
-   When Version 3.0 clients are in Version 2.0 compatibility mode,
-   they set the right-hand (least-significant) 8 random bytes of the
-   PKCS padding (not including the terminal null of the padding) for
-   the RSA encryption of the ENCRYPTED-KEY- DATA field of the
-   CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random).
-   After decrypting the ENCRYPTED- KEY-DATA field, servers that
-   support SSL 3.0 should issue an error if these eight padding bytes
-   are 0x03.  Version 2.0 servers receiving blocks padded in this
-   manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 54]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                            Appendix F
-
-F. Security analysis
-
-   The SSL protocol is designed to establish a secure connection
-   between a client and a server communicating over an insecure
-   channel.  This document makes several traditional assumptions,
-   including that attackers have substantial computational resources
-   and cannot obtain secret information from sources outside the
-   protocol.  Attackers are assumed to have the ability to capture,
-   modify, delete, replay, and otherwise tamper with messages sent
-   over the communication channel.  This appendix outlines how SSL has
-   been designed to resist a variety of attacks.
-
-F.1 Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec
-   and generating a MasterSecret, which together comprise the primary
-   cryptographic parameters associated with a secure session.  The
-   handshake protocol can also optionally authenticate parties who
-   have certificates signed by a trusted certificate authority.
-
-F.1.1 Authentication and key exchange
-
-   SSL supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity.  Whenever the server is authenticated, the channel
-   should be secure against man-in- the-middle attacks, but completely
-   anonymous sessions are inherently vulnerable to such attacks.
-   Anonymous servers cannot authenticate clients, since the client
-   signature in the certificate verify message may require a server
-   certificate to bind the signature to a particular server.  If the
-   server is authenticated, its certificate message must provide a
-   valid certificate chain leading to an acceptable certificate
-   authority.  Similarly, authenticated clients must supply an
-   acceptable certificate to the server.  Each party is responsible
-   for verifying that the other's certificate is valid and has not
-   expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers.  The pre_master_secret will be used to generate the
-   master_secret (see Section 6.1).  The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets
-   (see Sections 5.6.9 and 6.2.2).  By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1 Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA,
-   Diffie-Hellman, or FORTEZZA for key exchange.  With anonymous RSA,
-
-Freier, Karlton, Kocher                                        [Page 55]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   the client encrypts a pre_master_secret with the server's
-   uncertified public key extracted from the server key exchange
-   message.  The result is sent in a client key exchange message.
-   Since eavesdroppers do not know the server's private key, it will
-   be infeasible for them to decode the pre_master_secret.
-
-   With Diffie-Hellman or FORTEZZA, the server's public parameters are
-   contained in the server key exchange message and the client's are
-   sent in the client key exchange message.  Eavesdroppers who do not
-   know the private values should not be able to find the
-   Diffie-Hellman result (i.e.  the pre_master_secret) or the FORTEZZA
-   token encryption key (TEK).
-
-   Warning:       Completely anonymous connections only provide
-                  protection against passive eavesdropping.  Unless an
-                  independent tamper-proof channel is used to verify
-                  that the finished messages were not replaced by an
-                  attacker, server authentication is required in
-                  environments where active man-in-the-middle attacks
-                  are a concern.
-
-F.1.1.2 RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined.  The
-   public key may be either contained in the server's certificate or
-   may be a temporary RSA key sent in a server key exchange message.
-   When temporary RSA keys are used, they are signed by the server's
-   RSA or DSS certificate.  The signature includes the current
-   ClientHello.random, so old signatures and temporary keys cannot be
-   replayed.  Servers may use a single temporary RSA key for multiple
-   negotiation sessions.
-
-   Note:          The temporary RSA key option is useful if servers
-                  need large certificates but must comply with
-                  government-imposed size limits on keys used for key
-                  exchange.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key.  By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 5.6.8).  The client
-   signs a value derived from the master_secret and all preceding
-   handshake messages.  These handshake messages include the server
-   certificate, which binds the signature to the server, and
-   ServerHello.random, which binds the signature to the current
-   handshake process.
-
-
-
-Freier, Karlton, Kocher                                        [Page 56]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-F.1.1.3 Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters.  In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie- Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange.  Note that in this case the client and
-   server will generate the same Diffie- Hellman result (i.e.,
-   pre_master_secret) every time they communicate.  To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie- Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the
-   server in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-F.1.1.4 FORTEZZA
-
-   FORTEZZA's design is classified, but at the protocol level it is
-   similar to Diffie-Hellman with fixed public values contained in
-   certificates.  The result of the key exchange process is the token
-   encryption key (TEK), which is used to wrap data encryption keys,
-   client write key, server write key, and master secret encryption
-   key.  The data encryption keys are not derived from the
-   pre_master_secret because unwrapped keys are not accessible outside
-   the token.  The encrypted pre_master_secret is sent to the server
-   in a client key exchange message.
-
-F.1.2 Version rollback attacks
-
-   Because SSL Version 3.0 includes substantial improvements over SSL
-   Version 2.0, attackers may try to make Version 3.0- capable clients
-   and servers fall back to Version 2.0.  This attack is occurring if
-   (and only if) two Version 3.0-capable parties use an SSL 2.0
-   handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for
-   Version 3.0 servers to detect the attack.  This solution is not
-   secure against attackers who can brute force the key and substitute
-   a new ENCRYPTED-KEY-DATA message containing the same key (but with
-   normal padding) before the application specified wait threshold has
-
-Freier, Karlton, Kocher                                        [Page 57]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   expired.  Parties concerned about attacks of this scale should not
-   be using 40-bit encryption keys anyway.  Altering the padding of
-   the least-significant 8 bytes of the PKCS padding does not impact
-   security, since this is essentially equivalent to increasing the
-   input block size by 8 bytes.
-
-F.1.3 Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make
-   the parties select different encryption algorithms than they would
-   normally choose.  Because many implementations will support 40-bit
-   exportable encryption and some may even support null encryption or
-   MAC algorithms, this attack is of particular concern.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages.  If this occurs, the client and server will
-   compute different values for the handshake message hashes.  As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4 Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with
-   the session's master_secret.  Provided that the master_secret has
-   not been compromised and that the secure hash operations used to
-   produce the encryption keys and MAC secrets are secure, the
-   connection should be secure and effectively independent from
-   previous connections.  Attackers cannot use known encryption keys
-   or MAC secrets to compromise the master_secret without breaking the
-   secure hash operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been
-   compromised, or that certificates may have expired or been revoked,
-   it should force a full handshake.  An upper limit of 24 hours is
-   suggested for session ID lifetimes, since an attacker who obtains a
-   master_secret may be able to impersonate the compromised party
-   until the corresponding session ID is retired.  Applications that
-   may be run in relatively insecure environments should not write
-   session IDs to stable storage.
-
-F.1.5 MD5 and SHA
-
-   SSL uses hash functions very conservatively.  Where possible, both
-   MD5 and SHA are used in tandem to ensure that non- catastrophic
-   flaws in one algorithm will not break the overall protocol.
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 58]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-F.2 Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.  FORTEZZA encryption keys are
-   generated by the token, and are not derived from the master_secret.
-
-   Outgoing data is protected with a MAC before transmission.  To
-   prevent message replay or modification attacks, the MAC is computed
-   from the MAC secret, the sequence number, the message length, the
-   message contents, and two fixed character strings.  The message
-   type field is necessary to ensure that messages intended for one
-   SSL Record Layer client are not redirected to another.  The
-   sequence number ensures that attempts to delete or reorder messages
-   will be detected.  Since sequence numbers are 64-bits long, they
-   should never overflow.  Messages from one party cannot be inserted
-   into the other's output, since they use independent MAC secrets.
-   Similarly, the server-write and client-write keys are independent
-   so stream cipher keys are used only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read.  Similarly, compromise of a MAC key can make
-   message modification attacks possible.  Because MACs are also
-   encrypted, message-alteration attacks generally require breaking
-   the encryption algorithm as well as the MAC.
-
-   Note:          MAC secrets may be larger than encryption keys, so
-                  messages can remain tamper resistant even if
-                  encryption keys are broken.
-
-F.3 Final notes
-
-   For SSL to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure.  In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used.  Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with
-   great caution.  Implementations and users must be careful when
-   deciding which certificates and certificate authorities are
-   acceptable; a dishonest certificate authority can do tremendous
-   damage.
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 59]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-                            Appendix G
-
-G. Patent Statement
-
-   This version of the SSL protocol relies on the use of patented
-   public key encryption technology for authentication and encryption.
-   The Internet Standards Process as defined in RFC 1310 requires a
-   written statement from the Patent holder that a license will be
-   made available to applicants under reasonable terms and conditions
-   prior to approving a specification as a Proposed, Draft or Internet
-   Standard.  The Massachusetts Institute of Technology has granted
-   RSA Data Security, Inc., exclusive sub-licensing rights to the
-   following patent issued in the United States:
-
-        Cryptographic Communications System and Method ("RSA"),
-   No. 4,405,829
-
-   The Board of Trustees of the Leland Stanford Junior University have
-   granted Caro-Kann Corporation, a wholly owned subsidiary
-   corporation, exclusive sub-licensing rights to the following
-   patents issued in the United States, and all of their corresponding
-   foreign patents:
-
-         Cryptographic Apparatus and Method ("Diffie-Hellman"),
-   No. 4,200,770
-
-        Public Key Cryptographic Apparatus and Method ("Hellman-
-   Merkle"), No. 4,218,582
-
-   The Internet Society, Internet Architecture Board, Internet
-   Engineering Steering Group and the Corporation for National
-   Research Initiatives take no position on the validity or scope of
-   the patents and patent applications, nor on the appropriateness of
-   the terms of the assurance.  The Internet Society and other groups
-   mentioned above have not made any determination as to any other
-   intellectual property rights which may apply to the practice of
-   this standard.  Any further consideration of these matters is the
-   user's own responsibility.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 60]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-References
-
-   [DH1] W. Diffie and M. E. Hellman, "New Directions in
-   Cryptography," IEEE Transactions on Information Theory, V.
-   IT-22, n. 6, Jun 1977, pp. 74-84.
-
-   [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions
-   To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES] ANSI X3.106, "American National Standard for
-   Information Systems-Data Link Encryption," American National
-   Standards Institute, 1983.
-
-   [DSS] NIST FIPS PUB 186, "Digital Signature Standard,"
-   National Institute of Standards and Technology, U.S.
-   Department of Commerce, 18 May 1994.
-
-   [FOR] NSA X22, Document # PD4002103-1.01, "FORTEZZA:
-   Application Implementers Guide," April 6, 1995.
-
-   [FTP] J. Postel and J. Reynolds, RFC 959: File Transfer
-   Protocol, October 1985.
-
-   [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext
-   Transfer Protocol -- HTTP/1.0, October, 1995.
-
-   [IDEA] X. Lai, "On the Design and Security of Block
-   Ciphers," ETH Series in Information Processing, v. 1,
-   Konstanz: Hartung-Gorre Verlag, 1992.
-
-   [KRAW] H. Krawczyk, IETF Draft: Keyed-MD5 for Message
-   Authentication, November 1995.
-
-   [MD2] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm.
-   April 1992.
-
-   [MD5] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm.
-   April 1992.
-
-   [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption
-   Standard," version 1.5, November 1993.
-
-   [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate
-   Syntax Standard," version 1.5, November 1993.
-
-   [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic
-   Message Syntax Standard," version 1.5, November 1993.
-
-   [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-   Obtaining Digital Signatures and Public-Key Cryptosystems,"
-   Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
-   126.
-
-Freier, Karlton, Kocher                                        [Page 61]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782
-   [SCH] B. Schneier. Applied Cryptography: Protocols,
-   Algorithms, and Source Code in C, Published by John Wiley &
-   Sons, Inc. 1994.
-
-   [SHA] NIST FIPS PUB 180-1, "Secure Hash Standard," National
-   Institute of Standards and Technology, U.S. Department of
-   Commerce, DRAFT, 31 May 1994.
-   [TCP] ISI for DARPA, RFC 793: Transport Control Protocol,
-   September 1981.
-
-   [TEL] J. Postel and J. Reynolds, RFC 854/5, May, 1993.
-   [X509] CCITT. Recommendation X.509: "The Directory -
-   Authentication Framework". 1988.
-
-   [XDR] R. Srinivansan, Sun Microsystems, RFC-1832: XDR:
-   External Data Representation Standard, August 1995.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 62]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Authors
-
-   Alan O. Freier                Paul C. Kocher
-   Netscape Communications       Independent Consultant
-   freier@netscape.com           pck@netcom.com
-
-   Philip L. Karlton
-   Netscape Communications
-   karlton@netscape.com
-
-   Other contributors
-
-   Martin Abadi                  Robert Relyea
-   Digital Equipment Corporation Netscape Communications
-   ma@pa.dec.com                 relyea@netscape.com
-
-   Taher Elgamal                 Jim Roskind
-   Netscape Communications       Netscape Communications
-   elgamal@netscape.com          jar@netscape.com
-
-   Anil Gangolli                 Micheal J. Sabin, Ph. D.
-   Netscape Communications       Consulting Engineer
-   gangolli@netscape.com         msabin@netcom.com
-
-   Kipp E.B. Hickman             Tom Weinstein
-   Netscape Communications       Netscape Communications
-   kipp@netscape.com             tomw@netscape.com
-
-   Early reviewers
-
-   Robert Baldwin                Clyde Monma
-   RSA Data Security, Inc.       Bellcore
-   baldwin@rsa.com               clyde@bellcore.com
-
-   George Cox                    Eric Murray
-   Intel Corporation             ericm@lne.com
-   cox@ibeam.jf.intel.com
-
-   Cheri Dowell                  Avi Rubin
-   Sun Microsystems              Bellcore
-   cheri@eng.sun.com             rubin@bellcore.com
-
-   Stuart Haber                  Don Stephenson
-   Bellcore                      Sun Microsystems
-   stuart@bellcore.com           don.stephenson@eng.sun.com
-
-   Burt Kaliski                  Joe Tardo
-   RSA Data Security, Inc.       General Magic
-   burt@rsa.com                  tardo@genmagic.com
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 63]
-.
-
-INTERNET-DRAFT                  SSL 3.0                November 18, 1996
-
-   Send all written communication about this document to:
-   Netscape Communications
-   466 Ellis Street 
-   Mountain View, CA 94043-4042
-   Attn: Alan Freier
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Freier, Karlton, Kocher                                        [Page 63]
-.
-
diff --git a/doc/protocol/draft-funk-tls-inner-application-extension-00.txt b/doc/protocol/draft-funk-tls-inner-application-extension-00.txt
deleted file mode 100644
index d9c056db79..0000000000
--- a/doc/protocol/draft-funk-tls-inner-application-extension-00.txt
+++ /dev/null
@@ -1,1947 +0,0 @@
-
-
-
-
-
-TLS Working Group                                             Paul Funk 
-Internet-Draft                                      Funk Software, Inc. 
-Category: Standards Track                            Simon Blake-Wilson 
-<draft-funk-tls-inner-application-extension-00.txt>    Basic Commerce &  
-                                                       Industries, Inc. 
-                                                              Ned Smith 
-                                                            Intel Corp. 
-                                                      Hannes Tschofenig 
-                                                             Siemens AG 
-                                                           October 2004 
-
-                                     
-
-                    TLS Inner Application Extension 
-                               (TLS/IA) 
-
-                                     
-
-Status of this Memo 
-
-   This document is an Internet-Draft and is subject to all provisions 
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each 
-   author represents that any applicable patent or other IPR claims of 
-   which he or she is aware have been or will be disclosed, and any of 
-   which he or she become aware will be disclosed, in accordance with 
-   RFC 3668. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 (2001 - 2004). All Rights 
-   Reserved. 
-
-Abstract 
-
-Internet-Draft                                            October 2004         
-
-
-   This document defines a new TLS extension called "Inner 
-   Application". When TLS is used with the Inner Application extension 
-   (TLS/IA), additional messages are exchanged during the TLS 
-   handshake, each of which is an encrypted sequence of Attribute-
-   Value-Pairs (AVPs) from the RADIUS/Diameter namespace. Hence, the 
-   AVPs defined in RADIUS and Diameter have the same meaning in TLS/AI; 
-   that is, each attribute code point refers to the same logical 
-   attribute in any of these protocols. Arbitrary "applications" may be 
-   implemented using the AVP exchange. Possible applications include 
-   EAP or other forms of user authentication, client integrity 
-   checking, provisioning of additional tunnels, and the like. Use of 
-   the RADIUS/Diameter namespace provides natural compatibility between 
-   TLS/IA applications and widely deployed AAA infrastructures. 
-
-   It is anticipated that TLS/IA will be used with and without 
-   subsequent protected data communication within the tunnel 
-   established by the handshake. For example, TLS/IA may be used to 
-   secure an HTTP data connection, allowing more robust password-based 
-   user authentication to occur within the TLS handshake than would 
-   otherwise be possible using mechanisms available in HTTP. TLS/IA may 
-   also be used for its handshake portion alone; for example, EAP-
-   TTLSv1 encapsulates a TLS/IA handshake in EAP as a means to mutually 
-   authenticate a client and server and establish keys for a separate 
-   data connection. 
-
-Table of Contents 
-
-1   Introduction......................................................3 
-1.1    A Bit of History..............................................4 
-1.2    Handshake-Only vs. Full TLS Usage.............................5 
-2   The InnerApplication Extension to TLS.............................5 
-2.1    TLS/IA Overview...............................................6 
-2.2    Message Exchange..............................................8 
-2.3    Master Key Permutation........................................8 
-2.3.1      Application Session Key Material.........................10 
-2.4    Session Resumption...........................................11 
-2.5    Error Termination............................................12 
-2.6    Computing Verification Data..................................12 
-2.7    TLS/IA Messages..............................................14 
-2.8    Negotiating the Inner Application Extension..................14 
-2.8.1      ClientInnerApplication...................................14 
-2.8.2      ServerInnerApplication...................................15 
-2.9    The PhaseFinished Handshake Message..........................16 
-2.10   The ApplicationPayload Handshake Message.....................16 
-2.11   The InnerApplicationFailure Alert............................16 
-3   Encapsulation of AVPs within ApplicationPayload Messages.........16 
-3.1    AVP Format...................................................17 
-3.2    AVP Sequences................................................18 
-3.3    Guidelines for Maximum Compatibility with AAA Servers........18 
-4   Tunneled Authentication within Application Phases................19 
-4.1    Implicit challenge...........................................19 
-
-
-
-Paul Funk                 expires April 2005                  [Page 2] 
-
-Internet-Draft                                            October 2004         
-
-
-4.2    Tunneled Authentication Protocols............................20 
-4.2.1      EAP ......................................................20 
-4.2.2      CHAP .....................................................21 
-4.2.3      MS-CHAP..................................................22 
-4.2.4      MS-CHAP-V2...............................................22 
-4.2.5      PAP ......................................................24 
-4.3    Performing Multiple Authentications..........................24 
-5   Example Message Sequences........................................25 
-5.1    Full Initial Handshake with Intermediate and Final Application 
-Phases 25 
-5.2    Resumed Session with Single Application Phase................26 
-5.3    Resumed Session with No Application Phase....................27 
-6   Security Considerations..........................................27 
-7   References.......................................................30 
-7.1    Normative References.........................................30 
-7.2    Informative References.......................................31 
-8   Authors' Addresses...............................................31 
-9   Intellectual Property Statement..................................32 
-    
-
-1  Introduction 
-
-   This specification defines the TLS "Inner Application" extension. 
-   The term "TLS/IA" refers to the TLS protocol when used with the 
-   Inner Application extension. 
-
-   In TLS/IA, the TLS handshake is extended to allow an arbitrary 
-   exchange of information between client and server within a protected 
-   tunnel established during the handshake but prior to its completion. 
-   The initial phase of the TLS handshake is virtually identical to 
-   that of a standard TLS handshake; subsequent phases are conducted 
-   under the confidentiality and integrity protection afforded by that 
-   initial phase. 
-
-   The primary motivation for providing such communication is to allow 
-   robust user authentication to occur as part of the handshake, in 
-   particular, user authentication that is based on password 
-   credentials, which is best conducted under the protection of an 
-   encrypted tunnel to preclude dictionary attack by eavesdroppers. For 
-   example, Extensible Authentication Protocol (EAP) may be used to 
-   authenticate using any of a wide variety of methods as part of the 
-   TLS handshake. The multi-phase approach of TLS/IA, in which a strong 
-   authentication, typically based on a server certificate, is used to 
-   protected a password-based authentication, distinguishes it from 
-   other TLS variants that rely entirely on a pre-shared key or 
-   password for security; for example [TLS-PSK]. 
-
-   The protected exchange accommodates any type of client-server 
-   application, not just authentication, though authentication may 
-   often be the prerequisite that allows other applications to proceed. 
-   For example, TLS/IA may be used to set up HTTP connections, 
-
-
-
-Paul Funk                 expires April 2005                  [Page 3] 
-
-Internet-Draft                                            October 2004         
-
-
-   establish IPsec security associations (as an alternative to IKE), 
-   obtain credentials for single sign-on, provide for client integrity 
-   verification, and so on. 
-
-   The new messages that are exchanged between client and server are 
-   encoded as sequences of Attribute-Value-Pairs (AVPs) from the 
-   RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace 
-   provides natural compatibility between TLS/IA applications and 
-   widely deployed AAA infrastructures. This namespace is extensible, 
-   allowing new AVPs and, thus, new applications to be defined as 
-   needed, either by standards bodies or by vendors wishing to define 
-   proprietary applications. 
-
-1.1  A Bit of History 
-
-   The TLS protocol has its roots in the Netscape SSL protocol, which 
-   was originally intended to secure HTTP. It provides either one-way 
-   or mutual authentication of client and server based on certificates. 
-   In its most typical use in HTTP, the client authenticates the server 
-   based on the server's certificate and establishes a tunnel through 
-   which HTTP traffic is passed.  
-
-   For the server to authenticate the client within the TLS handshake, 
-   the client must have its own certificate. In cases where the client 
-   must be authenticated without a certificate, HTTP, not TLS, 
-   mechanisms would have to be employed. For example, HTTP headers have 
-   been defined to perform user authentications. However, these 
-   mechanisms are primitive compared to other mechanisms, most notably 
-   EAP, that have been defined for contexts other than HTTP. 
-   Furthermore, any mechanisms defined for HTTP cannot be utilized when 
-   TLS is used to protect non-HTTP traffic. 
-
-   The TLS protocol has also found an important use in authentication 
-   for network access, originally within PPP for dial-up access and 
-   later for wireless and wired 802.1X access. Several EAP types have 
-   been defined that utilize TLS to perform mutual client-server 
-   authentication. The first to appear, EAP-TLS, uses the TLS handshake 
-   to authenticate both client and server based on the certificate of 
-   each.  
-
-   Subsequent protocols, such EAP-TTLSv0 and EAP-PEAP, utilize the TLS 
-   handshake to allow the client to authenticate the server based on 
-   the latter's certificate, then utilize the tunnel established by the 
-   TLS handshake to perform user authentication, typically based on 
-   password credentials. Such protocols are called "tunneled" EAP 
-   protocols. The authentication mechanism used inside the tunnel may 
-   itself be EAP, and the tunnel may also be used to convey additional 
-   information between client and server. 
-
-   TLS/IA is in effect a merger of the two types of TLS usage described 
-   above, based on the recognition that tunneled authentication would 
-
-
-
-Paul Funk                 expires April 2005                  [Page 4] 
-
-Internet-Draft                                            October 2004         
-
-
-   be useful in other contexts besides EAP. However, the tunneled 
-   protocols mentioned above are not directly compatible with a more 
-   generic use of TLS, because they utilize the tunneled data portion 
-   of TLS, thus precluding its use for other purposes such as carrying 
-   HTTP traffic. 
-
-   The TLS/IA solution to this problem is to fold the tunneled 
-   authentication into the TLS handshake itself, making the data 
-   portion of the TLS exchange available for HTTP or any other protocol 
-   or connection that needs to be secured. 
-
-1.2  Handshake-Only vs. Full TLS Usage 
-
-   It is anticipated that TLS/IA will be used with and without 
-   subsequent protected data communication within the tunnel 
-   established by the handshake.  
-
-   For example, TLS/IA may be used to secure an HTTP data connection, 
-   allowing more robust password-based user authentication to occur 
-   within the TLS handshake than would otherwise be possible using 
-   mechanisms available in HTTP.  
-
-   TLS/IA may also be used for its handshake portion alone. For 
-   example, EAP-TTLSv1 encapsulates a TLS/IA handshake in EAP as a 
-   means to mutually authenticate a client and server and establish 
-   keys for a separate data connection; no subsequent data portion is 
-   required. Another example might be use of TLS/IA directly over TCP 
-   to provide a user with credentials for single sign-on. 
-
-2  The InnerApplication Extension to TLS 
-
-   The InnerApplication extension to TLS follows the guidelines of RFC 
-   3546. The client proposes use of this extension by including a 
-   ClientInnerApplication message in its ClientHello handshake message, 
-   and the server confirms its use by including a 
-   ServerInnerApplication message in its ServerHello handshake message.  
-
-   Two new handshake messages are defined for use in TLS/IA: 
-
-   -  The PhaseFinished message. This message is similar to the 
-      standard TLS Finished message; it allows the TLS/IA handshake to 
-      operate in phases, with message and key confirmation occurring at 
-      the end of each phase. 
-
-   -  The ApplicationPayload message. This message is used to carry AVP 
-      (Attribute-Value Pair) sequences within the TLS/IA handshake, in 
-      support of client-server applications such as authentication. 
-
-   A new alert code is also defined for use in TLS/IA: 
-
-   -  The InnerApplicationFailure alert. This error alert allows either 
-
-
-
-Paul Funk                 expires April 2005                  [Page 5] 
-
-Internet-Draft                                            October 2004         
-
-
-      party to terminate the handshake due to a failure in an 
-      application implemented via AVP sequences carried in 
-      ApplicationPayload messages. 
-
-2.1  TLS/IA Overview 
-
-   In TLS/IA, the handshake is divided into phases. The first phase, 
-   called the "initial phase", is a standard TLS handshake; it is 
-   followed by zero or more "application phases". The last phase is 
-   called the "final phase"; this will be an application phase if a 
-   such a phase is present, otherwise the standard TLS handshake is 
-   both the initial and final phase. Any application phases between the 
-   initial and final phase are called "intermediate phases". 
-
-   A typical handshake consists of an initial phase and a final phase, 
-   with no intermediate phases. Intermediate phases are only necessary 
-   if interim confirmation key material generated during an application 
-   phase is desired.  
-
-   Each application phase consists of ApplicationPayload handshake 
-   messages exchanged by client and server to implement applications 
-   such as authentication, plus concluding messages for cryptographic 
-   confirmation. 
-
-   All application phases are encrypted. A new master secret and cipher 
-   spec are negotiated at the conclusion of each phase, to be applied 
-   in the subsequent phase. The master secret and cipher spec 
-   negotiated at the conclusion of the final phase are applied to the 
-   data exchange following the handshake. 
-
-   All phases prior to the final phase use PhaseFinished rather than 
-   Finished as the concluding message. The final phase concludes with 
-   the Finished message.  
-
-   Application phases may be omitted entirely only when session 
-   resumption is used, provided both client and server agree that no 
-   application phase is required. The client indicates in its 
-   ClientHello whether it is willing to omit application phases in a 
-   resumed session. 
-
-   In each application phase, the client sends the first 
-   ApplicationPayload message. ApplicationPayload messages are then 
-   traded one at a time between client and server, until the server 
-   concludes the phase by sending, in response to an ApplicationPayload 
-   message from the client, a ChangeCipherSpec and PhaseFinished 
-   sequence to conclude an intermediate phase, or a ChangeCipherSpec 
-   and Finished sequence to conclude the final phase. The client then 
-   responds with its own ChangeCipherSpec and PhaseFinished sequence, 
-   or ChangeCipherSpec and Finished sequence.  
-
-
-
-
-
-Paul Funk                 expires April 2005                  [Page 6] 
-
-Internet-Draft                                            October 2004         
-
-
-   Note that the server MUST NOT send a ChangeCipherSpec plus Finished 
-   or PhaseFinished message immediately after sending an 
-   ApplicationPayload message. It must allow the client to send an 
-   ApplicationPayload message prior to concluding the phase. Thus, 
-   within any application phase, there will be one more 
-   ApplicationPayload message sent by the client than sent by the 
-   server. 
-
-   The server determines which type of concluding message is used, 
-   either PhaseFinished or Finished, and the client MUST echo the same 
-   type of concluding message. Each PhaseFinished or Finished message 
-   provides cryptographic confirmation of the integrity of all 
-   handshake messages and keys generated from the start of the 
-   handshake through the current phase. 
-
-   Each ApplicationPayload message contains opaque data interpreted as 
-   an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence 
-   contains a typed data element. The exchanged AVPs allow client and 
-   server to implement "applications" within a secure tunnel. An 
-   application may be any procedure that someone may usefully define. A 
-   typical application might be authentication; for example, the server 
-   may authenticate the client based on password credentials using EAP. 
-   Other possible applications include distribution of keys, validating 
-   client integrity, setting up IPsec parameters, setting up SSL VPNs, 
-   and so on. 
-
-   The TLS master secret undergoes multiple permutations until a final 
-   master secret is computed at the end of the entire handshake. Each 
-   phase of the handshake results in a new master secret; the master 
-   secret for each phase is confirmed by the PhaseFinished or Finished 
-   message exchange that concludes that phase. 
-
-   The initial master secret is computed during the initial phase of 
-   the handshake, using the standard TLS-defined procedure. This 
-   initial master secret is confirmed via the first exchange of 
-   ChangeCipherSpec and PhaseFinished messages, or, in the case of a 
-   resumed session with no subsequence application phase, the exchange 
-   of ChangeCipherSpec and Finished messages. 
-
-   Each subsequent master secret for an application phase is computed 
-   using a PRF based on the current master secret, then mixing into the 
-   result any session key material generated during authentications 
-   during that phase. Each party computes a new master secret prior to 
-   the conclusion of each application phase, and uses that new master 
-   secret is to compute fresh keying material (that is, a TLS 
-   "key_block", consisting of client and server MAC secrets, write keys 
-   and IVs). The new master secret and keying material become part of 
-   the pending read and write connection states. Following standard TLS 
-   procedures, these connection states become current states upon 
-   sending or receiving ChangeCipherSpec, and are confirmed via the 
-   PhaseFinished or Finished message. 
-
-
-
-Paul Funk                 expires April 2005                  [Page 7] 
-
-Internet-Draft                                            October 2004         
-
-
-   The final master secret, computed during the final handshake phase 
-   and confirmed by an exchange of ChangeCipherSpec and Finished 
-   messages, becomes the actual TLS master secret that defines the 
-   session. This final master secret is the surviving master secret, 
-   and each prior master secrets SHOULD be discarded when a new 
-   connection state is instantiated. The final master secret is used 
-   for session resumption, as well as for any session key derivation 
-   that protocols defined over TLS may require.  
-
-2.2  Message Exchange 
-
-   Each intermediate handshake phase consists of ApplicationPayload 
-   messages sent alternately by client and server, and a concluding 
-   exchange of {ChangeCipherSpec, PhaseFinished} messages. The first 
-   and last ApplicationPayload message in each intermediate phase is 
-   sent by the client; the first {ChangeCipherSpec, PhaseFinished} 
-   message sequence is sent by the server. Thus the client begins the 
-   exchange with an ApplicationPayload message and the server 
-   determines when to conclude it by sending {ChangeCipherSpec, 
-   PhaseFinished}. When it receives the server's {ChangeCipherSpec, 
-   PhaseFinished} messages, the client sends its own {ChangeCipherSpec, 
-   PhaseFinished} messages, followed by an ApplicationPayload message 
-   to begin the next handshake phase.  
-
-   The final handshake proceeds in the same manner as the intermediate 
-   handshake, except that the Finished message is used rather than the 
-   PhaseFinished message, and the client does not send an 
-   ApplicationPayload message for the next phase because there is no 
-   next phase. 
-
-   At the start of each application handshake phase, the server MUST 
-   wait for the client's opening ApplicationPayload message before it 
-   sends its own ApplicationPayload message to the client. The client 
-   MAY NOT initiate conclusion of an application handshake phase by 
-   sending the first {ChangeCipherSpec, PhaseFinished} or 
-   {ChangeCipherSpec, Finished message} sequence; it MUST allow the 
-   server to initiate the conclusion of the phase. 
-
-2.3  Master Key Permutation 
-
-   Each permutation of the master secret from one phase to the next 
-   begins with the calculation of a preliminary 48 octet vector 
-   (pre_vector) based on the current master secret: 
-
-      pre_vector = PRF(SecurityParameters.master_secret,  
-                          "inner application preliminary vector",  
-                          SecurityParameters.server_random + 
-                          SecurityParameters.client_random) [0..48]; 
-
-   Session key material generated by applications during the current 
-   application phase are mixed into the preliminary vector by 
-
-
-
-Paul Funk                 expires April 2005                  [Page 8] 
-
-Internet-Draft                                            October 2004         
-
-
-   arithmetically adding each session key to it to compute the new 
-   master secret. The preliminary vector is treated as a 48-octet 
-   integer in big-endian order; that is, the first octet is of the 
-   highest significance. Each session key is also treated as a big-
-   endian integer of whatever size it happens to be. Arithmetic carry 
-   past the most significant octet is discarded; that is, the addition 
-   is performed modulo 2 ^ 384.  
-
-   Thus, the logical procedure for computing the next master secret 
-   (which may also be a convenient implementation procedure) is as 
-   follows: 
-
-   1  At the start of each application handshake phase, use the current 
-      master secret to compute pre_vector for the next master secret. 
-
-   2  Each time session key material is generated from an 
-      authentication or other exchange, arithmetically add that session 
-      key material to pre_vector. 
-
-   3  At the conclusion of the application handshake phase, copy the 
-      current contents of pre_vector (which now includes addition of 
-      all session key material) into the master secret, prior to 
-      computing verify_data. 
-
-   Note that the master secret is the only element of the TLS 
-   SecurityParameters that is permuted from phase to phase. The 
-   client_random, server_random, bulk_cipher_algorithm, mac_algorithm, 
-   etc. remain constant throughout all phases of the handshake. 
-
-   The purpose of using a PRF to compute a preliminary vector is to 
-   ensure that, even in the absence of session keys, the master secret 
-   is cryptographically distinct in each phase of the handshake. 
-
-   The purpose of adding session keys into the preliminary vector is to 
-   ensure that the same client entity that negotiated the original 
-   master secret also negotiated the inner authentication(s). In the 
-   absence of such mixing of keys generated from the standard TLS 
-   handshake with keys generated from inner authentication, it is 
-   possible for a hostile agent to mount a man-in-the-middle attack, 
-   acting as server to an unsuspecting client to induce it to perform 
-   an authentication with it, which it can then pass through the TLS 
-   tunnel to allow it to pose as that client. 
-
-   An application phase may include no authentications that produce a 
-   session key, may include one such authentication, or may include 
-   several. Arithmetic addition was chosen as the mixing method because 
-   it is commutative, that is, it does not depend on the order of 
-   operations. This allows multiple authentications to proceed 
-   concurrently if desired, without having to synchronize the order of 
-   master secret updates between client and server. 
-
-
-
-
-Paul Funk                 expires April 2005                  [Page 9] 
-
-Internet-Draft                                            October 2004         
-
-
-   Addition was chosen rather than XOR in order to avoid what is 
-   probably a highly unlikely problem; namely, that two separate 
-   authentications produce the same session key, which, if XORed, would 
-   mutually cancel. This might occur, for example, if two instances of 
-   an authentication method were to be applied against different forms 
-   of a user identity that turn out in a some cases to devolve to the 
-   same identity. 
-
-   Finally, it was decided that a more complex mixing mechanism for 
-   session key material, such as hashing, besides not being 
-   commutative, would not provide any additional security, due to the 
-   pseudo-random character of the preliminary vector and the powerful 
-   PRF function which is applied to create derivative secrets. 
-
-2.3.1 Application Session Key Material 
-
-   Many authentication protocols used today generate session keys that 
-   are bound to the authentication. Such keying material is normally 
-   intended for use in a subsequent data connection for encryption and 
-   validation. For example, EAP-TLS, MS-CHAP-V2 and its alter ego EAP-
-   MS-CHAP-V2 each generate session keys. 
-
-   Session keying material generated during an application phase MUST 
-   be used to permute the TLS/IA master secret between one phase and 
-   the next, and MUST NOT be used for any other purpose. Permuting the 
-   master secret based on session keying material is necessary  to 
-   preclude man-in-the-middle attacks, in which an unsuspecting client 
-   is induced to perform an authentication outside a tunnel with an 
-   attacker posing as a server; the attacker can then introduce the 
-   authentication protocol into a tunnel such as provided by TLS/IA, 
-   fooling an authentic server into believing that the attacker is the 
-   authentic user. 
-
-   By mixing keying material generated during application phase 
-   authentication into the master secret, such attacks are thwarted, 
-   since only a single client identity could both authenticate 
-   successfully and have derived the session keying material. Note that 
-   the keying material generated during authentication must be 
-   cryptographically related to the authentication and not derivable 
-   from data exchanged during authentication in order for the keying 
-   material to be useful in thwarting such attacks. 
-
-   In addition, the fact that the master secret cryptographically 
-   incorporates keying material from application phase authentications 
-   provides additional protection when the master secret is used as a 
-   basis for generating additional keys for use outside of the TLS 
-   exchange. If the master secret did not include keying material from 
-   inner authentications, an eavesdropper who somehow knew the server's 
-   private key could, in an RSA-based handshake, determine the master 
-   secret and hence would be able to compute the additional keys that 
-   are based on it. When inner authentication keying material is 
-
-
-
-Paul Funk                 expires April 2005                 [Page 10] 
-
-Internet-Draft                                            October 2004         
-
-
-   incorporated into the master secret, such an attack becomes 
-   impossible. 
-
-   The RECOMMENDED amount of keying material to mix into the master 
-   secret is 32 octets. Up to 48 octets MAY be used.  
-
-   Each authentication protocol may define how the keying material it 
-   generates is mapped to an octet sequence of some length for the 
-   purpose of TLS/IA mixing. However, for protocols which do not 
-   specify this (including the multitude of protocols that pre-date 
-   TLS/IA) the following rules are defined. The first rule that applies 
-   SHALL be the method for determining keying material: 
-
-   -  If the authentication protocol maps its keying material to the 
-      RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key 
-      [RFC2548], then the keying material for those attributes are 
-      concatenated (with MS-MPPE-Recv-Key first), the concatenated 
-      sequence is truncated to 32 octets if longer, and the result is 
-      used as keying material. (Note that this rule applies to MS-CHAP-
-      V2 and EAP-MS-CHAP-V2.) 
-
-   -  If the authentication protocol uses a pseudo-random function to 
-      generate keying material, that function is used to generate 32 
-      octets for use as keying material. 
-
-2.4  Session Resumption 
-
-   A TLS/IA initial handshake phase may be resumed using standard 
-   mechanisms defined in RFC 2246. When the initial handshake phase is 
-   resumed, client and server may not deem it necessary to exchange 
-   AVPs in one or more additional application phases, as the resumption 
-   itself may provide all the security needed. 
-
-   The client indicates within the InnerApplication extension whether 
-   it requires AVP exchange when session resumption occurs. If it 
-   indicates that it does not, then the server may at its option omit 
-   subsequent application phases and complete the resumed handshake in 
-   a single phase. 
-
-   Note that RFC 3546 specifically states that when session resumption 
-   is used, the server MUST ignore any extensions in the ClientHello. 
-   However, it is not possible to comply with this requirement for the 
-   Inner Application extension, since even in a resumed session it may 
-   be necessary to include application phases, and whether they must be 
-   included is negotiated in the extension message itself. Therefore, 
-   the RFC 3546 provision is specifically overridden for the single 
-   case of the Inner Application extension, which is considered an 
-   exception to this rule.  
-
-
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 11] 
-
-Internet-Draft                                            October 2004         
-
-
-2.5  Error Termination 
-
-   The TLS/IA handshake may be terminated by either party sending a 
-   fatal alert, following standard TLS procedures.  
-
-2.6  Computing Verification Data 
-
-   In standard TLS, the "verify_data" vector of the Finished message is 
-   computed as follows: 
-
-      PRF(master_secret, finished_label, MD5(handshake_messages) +  
-              SHA-1(handshake_messages)) [0..11]; 
-
-   This allows both parties to confirm the master secret as well as the 
-   integrity of all handshake messages that have been exchanged. 
-
-   In TLS/IA, verify_data for the initial handshake phase is computed 
-   in exactly the same manner. 
-
-   In the subsequent application phases, a slight variation of this 
-   formula is used. The data that is hashed is the hash of the 
-   handshake messages computed in the previous phase plus all handshake 
-   messages that have been exchanged since that previous hash was 
-   computed. Thus, for each application phase, the MD5 hash input to 
-   the PRF is a hash of the MD5 hash computed in the previous phase 
-   concatenated with all subsequent handshake messages through the 
-   current phase; the SHA-1 hash is computed in the same way, but using 
-   the SHA-1 hash computed for the previous phase. 
-
-   Also, the master secret used in the PRF computation in each 
-   application phase is the new master secret generated at the 
-   conclusion of that phase. 
-
-   For clarity, this is best expressed in formal notation. 
-
-   Let phases be numbered from 0, where phase 0 is the initial phase. 
-
-   Let: 
-
-      Secret[n] be the master secret determined at the conclusion of 
-      phase n. 
-
-      Messages[n] be the additional handshake messages exchanged since 
-      the hashes were computed in phase n - 1, where n > 0; or all 
-      handshake messages exchanged to date starting from ClientHello, 
-      where n = 0. 
-
-      MD5[n] be the MD5 hash of handshake message material for phase n. 
-
-      SHA-1[n] be the SHA-1 hash of handshake message material for 
-      phase n. 
-
-
-
-Paul Funk                 expires April 2005                 [Page 12] 
-
-Internet-Draft                                            October 2004         
-
-
-      PRF[n] be the verify_data generated via PRF in phase n. 
-
-   Hash computations for phase 0 are as follows: 
-
-      MD5[0] = MD5(Messages[0]) 
-
-      SHA-1[0] = SHA-1(Messages[0]) 
-
-   Hash computations for phase i, where i > 0 (i.e. application phases) 
-   are as follows: 
-
-      MD5[i] = MD5(MD5[i-1] + Messages[i]) 
-
-      SHA-1[i] = SHA-1(SHA-1[i-1] + Messages[i]) 
-
-   The PRF computation to generate verify_data for any phase i 
-   (including i = 0) is as follows: 
-
-      PRF[i] = PRF(Secret[i], finished_label, MD5[i] + SHA-1[i]) 
-      [0..11] 
-
-   Note that for phase 0, the PRF computation is identical to the 
-   standard TLS computation. Variations to the algorithm occur only in 
-   application phases, in the use of new master secrets and the 
-   inclusion of hashes of previous handshake messages as input to the 
-   hashing algorithms. 
-
-   During an application phase, the handshake messages input to the 
-   hashing algorithm include all handshake messages exchanged since the 
-   last PRF computation was performed. This will always include either 
-   one or two PhaseFinished messages from the previous phase. To see 
-   why, assume that in the previous phase the client issued its 
-   PhaseFinished message first, and the server's PhaseFinished message 
-   in response thus included the client's PhaseFinished message. This 
-   means that the server has not yet fed its PhaseFinished message into 
-   the PRF, and the client has fed neither its own PhaseFinished 
-   message nor the server's PhaseFinished response message into the 
-   PRF. Therefore these messages from the previous phase must be fed 
-   into the PhaseFinished messages along with handshake messages from 
-   the current phase into the PRF that validates the current phase. 
-
-   Note that the only handshake messages that appear in an application 
-   phase are InnerApplication messages and Finished or Phase Finished 
-   messages. ChangeCipherSpec messages are not handshake messages and 
-   are therefore never included in the hash computations. 
-
-   Note also that for TLS/IA, just as for standard TLS, client and 
-   server include a somewhat different set of handshake messages in 
-   hash computations. Therefore, both client and server must compute 
-   two PRFs for each handshake phase: one to include the verify_data 
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 13] 
-
-Internet-Draft                                            October 2004         
-
-
-   that it transmits, and one to use to check the verify_data received 
-   from the other party. 
-
-2.7  TLS/IA Messages 
-
-   All specifications of TLS/IA messages follow the usage defined in 
-   RFC 2246. 
-
-   TLS/IA defines a new TLS extension, two new handshake messages, and 
-   a new alert code. The new types and codes are (decimal): 
-
-   -  "InnerApplication" extension type:    37703 
-
-   -  "PhaseFinished" type:                    78 
-
-   -  "ApplicationPayload" type:               79 
-
-   -  "InnerApplicationFailure" code:         208 
-
-   [Note: I have not checked these types yet against types defined in 
-   RFCs or drafts. pf] 
-
-2.8  Negotiating the Inner Application Extension 
-
-   Use of the InnerApplication extension follows RFC 3546. The client 
-   proposes use of this extension by including the 
-   ClientInnerApplication message in the client_hello_extension_list of 
-   the extended ClientHello. If this message is included in the 
-   ClientHello, the server MAY accept the proposal by including the 
-   ServerInnerApplication message in the server_hello_extension_list of 
-   the extended ServerHello. If use of this extension is either not 
-   proposed by the client or not confirmed by the server, the 
-   variations to the TLS handshake described here MUST NOT be used. 
-
-2.8.1 ClientInnerApplication 
-
-   When the client wishes to propose use of the Inner Application 
-   extension, it must include ClientInnerApplication in the 
-   "extension_data" vector in the Extension structure in its extended 
-   ClientHello message, where: 
-
-   enum { 
-       not_required(0), required(1), (255) 
-   } AppPhaseOnResumption; 
-
-   struct { 
-      AppPhaseOnResumption app_phase_on_resumption; 
-   } ClientInnerApplication; 
-
-   The AppPhaseOnResumption enumeration allow client and server to 
-   negotiate an abbreviated, single-phase handshake when session 
-
-
-
-Paul Funk                 expires April 2005                 [Page 14] 
-
-Internet-Draft                                            October 2004         
-
-
-   resumption is employed. If the server is able to resume a previous 
-   session, and if the client sets app_phase_on_resumption to 
-   not_required, then the server MAY conclude the initial handshake 
-   phase with a Finished message, thus completing the handshake in a 
-   single phase. If the client sets app_phase_on_resumption to 
-   required, then the server MUST conclude the initial handshake phase 
-   with PhaseFinished, thus allowing one or more subsequent application 
-   phases to follow the initial handshake phase. 
-
-   The value of app_phase_on_resumption applies to the current 
-   handshake only. For example, it is possible for 
-   app_phase_on_resumption to have different values in two handshakes 
-   that are both resumed from the same original TLS session. 
-
-   Note that the server may initiate one or more application phases 
-   even if the client sets app_phase_on_resumption to not_required, as 
-   the server itself may have reason to proceed with one or more 
-   application phases. 
-
-   Note also that if session resumption does not occur, the 
-   app_phase_on_resumption variable is ignored, the server MUST 
-   conclude the initial phase with a PhaseFinished message and one or 
-   more application phases MUST follow the initial handshake phase. 
-
-2.8.2 ServerInnerApplication 
-
-   When the server wishes to confirm use of the Inner Application 
-   extension that has been proposed by the client, it must include 
-   ServerInnerApplication in the "extension_data" vector in the 
-   Extension structure in its extended ServerHello message, where: 
-
-   struct { 
-   } ServerInnerApplication; 
-
-   Note that the ServerInnerApplication message contains no data; 
-   however, it's presence is required to confirm use of the Inner 
-   Application extension when proposed by the client. 
-
-   If the client set app_phase_on_resumption to not_required and the 
-   server agrees and will not initiate an application phase, the server 
-   MUST NOT include ServerInnerApplication in its ServerHello and it 
-   must conclude the initial (and only) handshake phase with the 
-   Finished message. If, the server includes ServerInnerApplication, it 
-   MUST conclude the initial handshake phase with PhaseFinished, 
-   indicating that one or more application phases will follow the 
-   initial handshake phase. 
-
-
-
-
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 15] 
-
-Internet-Draft                                            October 2004         
-
-
-2.9  The PhaseFinished Handshake Message 
-
-   The PhaseFinished message concludes all handshake phases prior to 
-   the final handshake phase. It MUST be immediately preceded by a 
-   ChangeCipherSpec message. It is defined as follows: 
-
-   struct { 
-      opaque verify_data[12]; 
-   } PhaseFinished; 
-
-2.10 The ApplicationPayload Handshake Message 
-
-   The ApplicationPayload message carries an AVP sequence during an 
-   application handshake phase. It is defined as follows: 
-
-   struct { 
-      opaque avps[Handshake.length]; 
-   } ApplicationPayload; 
-
-   where Handshake.length is the 24-bit length field in the 
-   encapsulating Handshake message. 
-
-   Note that the "avps" element has its length defined in square 
-   bracket rather than angle bracket notation, implying a fixed rather 
-   than variable length vector. This avoids the having the length of 
-   the AVP sequence specified redundantly both in the encapsulating 
-   Handshake message and as a length prefix in the avps element itself. 
-
-2.11 The InnerApplicationFailure Alert 
-
-   An InnerApplicationFailure error alert may be sent by either party 
-   during an application phase. This indicates that the sending party 
-   considers the negotiation to have failed due to an application 
-   carried in the AVP sequences, for example, a failed authentication. 
-
-   The AlertLevel for an InnerApplicationFailure alert MUST be set to 
-   "fatal". 
-
-   Note that other alerts are possible during an application phase; for 
-   example, decrypt_error. The InnerApplicationFailure alert relates 
-   specifically to the failure of an application implemented via AVP 
-   sequences; for example, failure of an EAP or other authentication 
-   method, or information passed within the AVP sequence that is found 
-   unsatisfactory. 
-
-3  Encapsulation of AVPs within ApplicationPayload Messages 
-
-   During application phases of the TLS handshake, information is 
-   exchanged between client and server through the use of attribute-
-   value pairs (AVPs). This data is encrypted using the then-current 
-   cipher state established during the preceding handshake phase. 
-
-
-
-Paul Funk                 expires April 2005                 [Page 16] 
-
-Internet-Draft                                            October 2004         
-
-
-   The AVP format chosen for TLS/IA is compatible with the Diameter AVP 
-   format. This does not in any way represent a requirement that 
-   Diameter be supported by any of the devices or servers participating 
-   in the TLS/IA conversation, whether directly as client or server or 
-   indirectly as a backend authenticator. Use of this format is merely 
-   a convenience. Diameter is a superset of RADIUS and includes the 
-   RADIUS attribute namespace by definition, though it does not limit 
-   the size of an AVP as does RADIUS. RADIUS, in turn, is a widely 
-   deployed AAA protocol and attribute definitions exist for all 
-   commonly used password authentication protocols, including EAP. 
-
-   Thus, Diameter is not considered normative except as specified in 
-   this document. Specifically, the AVP Codes used in TLS/IA are 
-   semantically equivalent to those defined for Diameter, and, by 
-   extension, RADIUS.  
-
-   Use of the RADIUS/Diameter namespace allows a TLS/IA server to 
-   easily translate between AVPs it uses to communicate with clients 
-   and the protocol requirements of AAA servers that are widely 
-   deployed. Plus, it provides a well-understood mechanism to allow 
-   vendors to extend that namespace for their particular requirements. 
-
-3.1  AVP Format 
-
-   The format of an AVP is shown below. All items are in network, or 
-   big-endian, order; that is, they have most significant octet first. 
-
-    0                   1                   2                   3 
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |                           AVP Code                            | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |V M r r r r r r|                  AVP Length                   | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |                        Vendor-ID (opt)                        | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |    Data ... 
-   +-+-+-+-+-+-+-+-+ 
-
-   AVP Code 
-
-      The AVP Code is four octets and, combined with the Vendor-ID 
-      field if present, identifies the attribute uniquely. The first 
-      256 AVP numbers represent attributes defined in RADIUS. AVP 
-      numbers 256 and above are defined in Diameter. 
-
-   AVP Flags 
-
-      The AVP Flags field is one octet, and provides the receiver with 
-      information necessary to interpret the AVP.  
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 17] 
-
-Internet-Draft                                            October 2004         
-
-
-      The 'V' (Vendor-Specific) bit indicates whether the optional 
-      Vendor-ID field is present. When set to 1, the Vendor-ID field is 
-      present and the AVP Code is interpreted according to the 
-      namespace defined by the vendor indicated in the Vendor-ID field. 
-
-      The 'M' (Mandatory) bit indicates whether support of the AVP is 
-      required. If this bit is set to 0, this indicates that the AVP 
-      may be safely ignored if the receiving party does not understand 
-      or support it. If set to 1, this indicates that the receiving 
-      party must fail the negotiation if it does not understand the 
-      AVP; for a server, this would imply returning EAP-Failure, for a 
-      client, this would imply abandoning the negotiation. 
-
-      The 'r' (reserved) bits are unused and must be set to 0. 
-
-   AVP Length 
-
-      The AVP Length field is three octets, and indicates the length of 
-      this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID 
-      (if present) and Data. 
-
-   Vendor-ID 
-
-      The Vendor-ID field is present if and only if the 'V' bit is set 
-      in the AVP Flags field. It is four octets, and contains the 
-      vendor's IANA-assigned "SMI Network Management Private Enterprise 
-      Codes" [RFC1700] value. Vendors defining their own AVPs must 
-      maintain a consistent namespace for use of those AVPs within 
-      RADIUS, Diameter and TLS/IA. 
-
-      A Vendor-ID value of zero is semantically equivalent to absence 
-      of the Vendor-ID field altogether. 
-
-3.2  AVP Sequences 
-
-   Data encapsulated within the TLS Record Layer must consist entirely 
-   of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet 
-   boundary relative to the first AVP in the sequence. If an AVP is not 
-   a multiple of 4 octets, it must be padded with 0s to the next 4-
-   octet boundary. 
-
-   Note that the AVP Length does not include the padding. 
-
-3.3  Guidelines for Maximum Compatibility with AAA Servers 
-
-   When maximum compatibility with AAA servers is desired, the 
-   following guidelines for AVP usage are suggested: 
-
-   -  Non-vendor-specific AVPs should be selected from the set of 
-      attributes defined for RADIUS; that is, attributes with codes 
-      less than 256. This provides compatibility with both RADIUS and 
-
-
-
-Paul Funk                 expires April 2005                 [Page 18] 
-
-Internet-Draft                                            October 2004         
-
-
-      Diameter. 
-
-   -  Vendor-specific AVPs should be defined in terms of RADIUS. 
-      Vendor-specific RADIUS attributes translate to Diameter 
-      automatically; the reverse is not true. RADIUS vendor-specific 
-      attributes use RADIUS attribute 26 and include vendor ID, vendor-
-      specific attribute code and length; see [RFC2865] for details. 
-
-4  Tunneled Authentication within Application Phases 
-
-   TLS/IA permits user authentication information to be tunneled within 
-   an application phase between client and server, protecting the 
-   security of the authentication information against active and 
-   passive attack.  
-
-   Any type of password or other authentication may be tunneled. Also, 
-   multiple tunneled authentications may be performed. Normally, 
-   tunneled authentication is used when the client has not been issued 
-   a certificate and the TLS handshake provides only one-way 
-   authentication of the server to the client; however, in certain 
-   cases it may be desired to perform certificate authentication of the 
-   client during the initial handshake phase as well as tunneled user 
-   authentication in a subsequent application phase. 
-
-   This section establishes rules for using common authentication 
-   mechanisms within TLS/IA. Any new authentication mechanism should in 
-   general be covered by these rules if it is defined as an EAP type. 
-   Authentication mechanisms whose use within TLS/IA is not covered 
-   within this specification may require separate standardization, 
-   preferably within the standard that describes the authentication 
-   mechanism in question. 
-
-4.1  Implicit challenge 
-
-   Certain authentication protocols that use a challenge/response 
-   mechanism rely on challenge material that is not generated by the 
-   authentication server, and therefore require special handling. 
-
-   In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the 
-   Network Access Server (NAS) issues a challenge to the client, the 
-   client then hashes the challenge with the password and forwards the 
-   response to the NAS. The NAS then forwards both challenge and 
-   response to a AAA server. But because the AAA server did not itself 
-   generate the challenge, such protocols are susceptible to replay 
-   attack.  
-
-   If the client were able to create both challenge and response, 
-   anyone able to observe a CHAP or MS-CHAP exchange could pose as that 
-   user by replaying that challenge and response into a TLS/IA 
-   conversation.  
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 19] 
-
-Internet-Draft                                            October 2004         
-
-
-   To make these protocols secure in TLS/IA, it is necessary to provide 
-   a mechanism to produce a challenge that the client cannot control or 
-   predict.  
-
-   When a challenge-based authentication mechanism is used, both client 
-   and server use the TLS PRF function to generate as many octets as 
-   are required for the challenge, using the constant string "inner 
-   application challenge", based on the then-current master secret and 
-   random values established during the initial handshake phase: 
-
-      IA_challenge = PRF(SecurityParameters.master_secret, 
-                             "inner application challenge", 
-                             SecurityParameters.server_random + 
-                             SecurityParameters.client_random); 
-
-4.2  Tunneled Authentication Protocols 
-
-   This section describes the rules for tunneling specific 
-   authentication protocols within TLS/IA.  
-
-   For each protocol, the RADIUS RFC that defines the relevant 
-   attribute formats is cited. Note that these attributes are 
-   encapsulated as described in section 3.1; that is, as Diameter 
-   attributes, not as RADIUS attributes. In other words, the AVP Code, 
-   Length, Flags and optional Vendor-ID are formatted as described in 
-   section 3.1, while the Data is formatted as described by the cited 
-   RADIUS RFC. 
-
-   All tunneled authentication protocols except EAP must be initiated 
-   by the client in the first ApplicationPayload message of an 
-   application phase. EAP may be initiated by the client in the first 
-   ApplicationPayload message of an application phase; it may also be 
-   initiated by the server in any ApplicationPayload message. 
-
-   The authentication protocols described below may be performed 
-   directly by the TLS/IA server or may be forwarded to a backend AAA 
-   server. For authentication protocols that generate session keys, the 
-   backend server must return those session keys to the TLS/IA server 
-   in order to allow the protocol to succeed within TLS/IA. RADIUS or 
-   Diameter servers are suitable backend AAA servers for this purpose. 
-   RADIUS servers typically return session keys in MS-MPPE-Recv-Key and 
-   MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return 
-   session keys in the EAP-Master-Session-Key AVP [AAA-EAP]. 
-
-4.2.1 EAP 
-
-   EAP is described in [RFC3784]; RADIUS attribute formats are 
-   described in [RFC3579]. 
-
-
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 20] 
-
-Internet-Draft                                            October 2004         
-
-
-   When EAP is the tunneled authentication protocol, each tunneled EAP 
-   packet between the client and server is encapsulated in an EAP-
-   Message AVP. 
-
-   Either client or server may initiate EAP.  
-
-   The client is the first to transmit within any application phase, 
-   and it may include an EAP-Response/Identity AVP in its 
-   ApplicationPayload message to begin an EAP conversation. 
-   Alternatively, if the client does not initiate EAP the server may, 
-   by including an EAP-Request/Identity AVP in its ApplicationPayload 
-   message. 
-
-   The client's EAP-Response/Identity provides the actual username; the 
-   privacy of the user's identity is now guaranteed by the TLS 
-   encryption. This username must be a Network Access Identifier (NAI) 
-   [RFC2486]; that is, it must be in the following format: 
-
-      username@realm 
-
-   The @realm portion is optional, and is used to allow the server to 
-   forward the EAP message sequence to the appropriate server in the 
-   AAA infrastructure when necessary.  
-
-   The EAP authentication between client and server proceeds normally, 
-   as described in [RFC3784]. However, upon completion the server does 
-   not send an EAP-Success or EAP-Failure AVP. Instead, the server 
-   signals success when it concludes the application phase by issuing a 
-   Finished or PhaseFinished message, or it signals failure by issuing 
-   an InnerApplicationFailure alert. 
-
-   Note that the client may also issue an InnerApplicationFailure 
-   alert, for example, when authentication of the server fails in a 
-   method providing mutual authentication. 
-
-4.2.2 CHAP 
-
-   The CHAP algorithm is described in [RFC1994]; RADIUS attribute 
-   formats are described in [RFC2865]. 
-
-   Both client and server generate 17 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      CHAP-Challenge    [16 octets] 
-      CHAP Identifier   [1 octet] 
-
-   The client initiates CHAP by including User-Name, CHAP-Challenge and 
-   CHAP-Password AVPs in the first ApplicationPayload message in any 
-   application phase. The CHAP-Challenge value is taken from the 
-   challenge material. The CHAP-Password consists of CHAP Identifier, 
-
-
-
-Paul Funk                 expires April 2005                 [Page 21] 
-
-Internet-Draft                                            October 2004         
-
-
-   taken from the challenge material; and CHAP response, computed 
-   according to the CHAP algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the CHAP-Challenge AVP and the value of the CHAP 
-   Identifier in the CHAP-Password AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the CHAP-Challenge to determine the result of the authentication. 
-
-4.2.3 MS-CHAP 
-
-   The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute 
-   formats are described in [RFC2548]. 
-
-   Both client and server generate 9 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      MS-CHAP-Challenge [8 octets] 
-      Ident              [1 octet] 
-
-   The client initiates MS-CHAP by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload 
-   message in any application phase. The MS-CHAP-Challenge value is 
-   taken from the challenge material. The MS-CHAP-Response consists of 
-   Ident, taken from the challenge material; Flags, set according the 
-   client preferences; and LM-Response and NT-Response, computed 
-   according to the MS-CHAP algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP-Response AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the MS-CHAP-Challenge to determine the result of the authentication.  
-
-4.2.4 MS-CHAP-V2 
-
-   The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute 
-   formats are described in [RFC2548]. 
-
-   Both client and server generate 17 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      MS-CHAP-Challenge [16 octets] 
-      Ident              [1 octet] 
-
-   The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload 
-
-
-
-Paul Funk                 expires April 2005                 [Page 22] 
-
-Internet-Draft                                            October 2004         
-
-
-   message in any application phase. The MS-CHAP-Challenge value is 
-   taken from the challenge material. The MS-CHAP2-Response consists of 
-   Ident, taken from the challenge material; Flags, set to 0; Peer-
-   Challenge, set to a random value; and Response, computed according 
-   to the MS-CHAP-V2 algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP2-Response AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the MS-CHAP2-Challenge. 
-
-   If the MS-CHAP2-Challenge received from the client is correct, the 
-   server tunnels the MS-CHAP2-Success AVP to the client. 
-
-   Upon receipt of the MS-CHAP2-Success AVP, the client is able to 
-   authenticate the server. In its next InnerApplicationPayload message 
-   to the server, the client does not include any MS-CHAP-V2 AVPs. 
-   (This may result in an empty InnerApplicationPayload if no other 
-   AVPs need to be sent.) 
-
-   If the MS-CHAP2-Challenge received from the client is not correct, 
-   the server tunnels an MS-CHAP2-Error AVP to the client. This AVP 
-   contains a new Ident and a string with additional information such 
-   as error reason and whether a retry is allowed. If the error reason 
-   is an expired password and a retry is allowed, the client may 
-   proceed to change the user's password. If the error reason is not an 
-   expired password or if the client does not wish to change the user's 
-   password, it issues an InnerApplicationFailure alert. 
-
-   If the client does wish to change the password, it tunnels MS-CHAP-
-   NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server. 
-   The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge 
-   received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge AVP simply 
-   echoes the new Challenge. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP2-CPW AVP match the values it sent in 
-   the MS-CHAP2-Error AVP. If either item does not match exactly, the 
-   server must reject the client. Otherwise, it validates the MS-CHAP2-
-   CPW AVP. 
-
-   If the MS-CHAP2-CPW AVP received from the client is correct, and the 
-   server is able to change the user's password, the server tunnels the 
-   MS-CHAP2-Success AVP to the client and the negotiation proceeds as 
-   described above. 
-
-
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 23] 
-
-Internet-Draft                                            October 2004         
-
-
-   Note that additional AVPs associated with MS-CHAP-V2 may be sent by 
-   the server; for example, MS-CHAP-Domain. The server must tunnel such 
-   authentication-related AVPs along with the MS-CHAP2-Success. 
-
-4.2.5 PAP 
-
-   PAP RADIUS attribute formats are described in [RFC2865]. 
-
-   The client initiates PAP by including User-Name and User-Password 
-   AVPs in the first ApplicationPayload message in any application 
-   phase. 
-
-   In RADIUS, User-Password is padded with nulls to a multiple of 16 
-   octets, then encrypted using a shared secret and other packet 
-   information.  
-
-   A TLS/IA, however, does not RADIUS-encrypt the password since all 
-   application phase data is already encrypted. The client SHOULD, 
-   however, null-pad the password to a multiple of 16 octets, to 
-   obfuscate its length. 
-
-   Upon receipt of these AVPs from the client, the server may be able 
-   to decide whether to authenticate the client immediately, or it may 
-   need to challenge the client for more information. 
-
-   If the server wishes to issue a challenge to the client, it MUST 
-   tunnel the Reply-Message AVP to the client; this AVP normally 
-   contains a challenge prompt of some kind. It may also tunnel 
-   additional AVPs if necessary, such the Prompt AVP. Upon receipt of 
-   the Reply-Message AVPs, the client tunnels User-Name and User-
-   Password AVPs again, with the User-Password AVP containing new 
-   information in response to the challenge. This process continues 
-   until the server determines the authentication has succeeded or 
-   failed. 
-
-4.3  Performing Multiple Authentications 
-
-   In some cases, it is desirable to perform multiple user 
-   authentications. For example, a AAA/H may want first to authenticate 
-   the user by password, then by token card. 
-
-   The server may perform any number of additional user authentications 
-   using EAP, simply by issuing a EAP-Request with a new protocol type 
-   once the previous authentication has completed.. 
-
-   For example, a server wishing to perform MD5-Challenge followed by 
-   Generic Token Card would first issue an EAP-Request/MD5-Challenge 
-   AVP and receive a response. If the response is satisfactory, it 
-   would then issue EAP-Request/Generic Token Card AVP and receive a 
-   response. If that response were also satisfactory, it would consider 
-   the user authenticated. 
-
-
-
-Paul Funk                 expires April 2005                 [Page 24] 
-
-Internet-Draft                                            October 2004         
-
-
-5  Example Message Sequences 
-
-   This section presents a variety of possible TLS/IA message 
-   sequences. These examples do not attempt to exhaustively depict all 
-   possible scenarios.  
-
-   Parentheses indicate optional TLS messages. Brackets indicate 
-   optional message exchanges. Ellipsis (. . .) indicates optional 
-   repetition of preceding messages. 
-
-5.1  Full Initial Handshake with Intermediate and Final Application 
-Phases 
-
-   The diagram below depicts a full initial handshake phase followed by 
-   two application phases. 
-
-   Note that the client concludes the intermediate phase and starts the 
-   final phase in an uninterrupted sequence of three messages: 
-   ChangeCipherSpec and PhaseFinished belong to the intermediate phase, 
-   and ApplicationPayload belongs to the final phase.  
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** Initial Phase:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                       (Certificate) 
-                                                   ServerKeyExchange 
-                                                (CertificateRequest) 
-                                      <--------      ServerHelloDone 
-         (Certificate) 
-         ClientKeyExchange 
-         (CertificateVerify) 
-         ChangeCipherSpec 
-         PhaseFinished                --------> 
-                                                    ChangeCipherSpec 
-                                      <--------        PhaseFinished 
-    
-   *** Intermediate Phase: 
-         ApplicationPayload           -------->  
-    
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                                    ChangeCipherSpec 
-                                      <--------        PhaseFinished 
-
-
-
-Paul Funk                 expires April 2005                 [Page 25] 
-
-Internet-Draft                                            October 2004         
-
-
-         ChangeCipherSpec 
-         PhaseFinished 
-   *** Final Phase: 
-         ApplicationPayload           -------->  
-                                          
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                      <--------     ChangeCipherSpec 
-                                                            Finished 
-         ChangeCipherSpec 
-         Finished                     --------> 
-    
-5.2  Resumed Session with Single Application Phase 
-
-   The diagram below depicts a resumed session followed by a single 
-   application phase. 
-
-   Note that the client concludes the initial phase and starts the 
-   final phase in an uninterrupted sequence of three messages: 
-   ChangeCipherSpec and PhaseFinished belong to the initial phase, and 
-   ApplicationPayload belongs to the final phase.  
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** Initial Phase:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                    ChangeCipherSpec 
-                                      <--------        PhaseFinished 
-         ChangeCipherSpec 
-         PhaseFinished 
-   *** Final Phase: 
-         ApplicationPayload           -------->  
-                                          
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                      <--------     ChangeCipherSpec 
-                                                            Finished 
-         ChangeCipherSpec 
-         Finished                     --------> 
-
-
-
-Paul Funk                 expires April 2005                 [Page 26] 
-
-Internet-Draft                                            October 2004         
-
-
-    
-5.3  Resumed Session with No Application Phase 
-
-   The diagram below depicts a resumed session without any subsequent 
-   application phase. This will occur if the client indicates in its 
-   ClientInnerApplication message that no application phase is required 
-   and the server concurs.  
-
-   Note that this message sequence is identical to that of a standard 
-   TLS resumed session. 
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** Initial/Final Phase:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                    ChangeCipherSpec 
-                                      <--------             Finished 
-         ChangeCipherSpec 
-         Finished 
-    
-6  Security Considerations 
-
-   This document introduces a new TLS extension called "Inner 
-   Application". When TLS is used with the Inner Application extension 
-   (TLS/IA), additional messages are exchanged during the TLS 
-   handshake. Hence a number of security issues need to be taken into 
-   consideration. Since the security heavily depends on the information 
-   (called "applications") which are exchanged between the TLS client 
-   and the TLS server as part of the TLS/IA extension we try to 
-   classify them into two categories: The first category considers the 
-   case where the exchange results in the generation of keying 
-   material. This is, for example, the case with many EAP methods. EAP 
-   is one of the envisioned main "applications". The second category 
-   focuses on cases where no session key is generated. The security 
-   treatment of the latter category is discouraged since it is 
-   vulnerability to man-in-the-middle attacks if the two sessions 
-   cannot be bound to each other as shown in [MITM].  
-
-   Subsequently, we investigate a number of security issues:  
-
-   - Architecture and Trust Model 
-
-     For many of the use cases in this document we assume that three 
-     functional entities participate in the protocol exchange: TLS 
-     client, TLS server and a AAA infrastructure (typically consisting 
-     of a AAA server and possibly a AAA broker). The protocol exchange 
-     described in this document takes place between the TLS client and 
-     the TLS server. The interaction between the AAA client (which 
-     corresponds to the TLS server) and the AAA server is described in 
-
-
-
-Paul Funk                 expires April 2005                 [Page 27] 
-
-Internet-Draft                                            October 2004         
-
-
-     the respective AAA protocol documents and therefore outside the 
-     scope of this document. The trust model behind this architecture 
-     with respect to the authentication, authorization, session key 
-     establishment and key transport within the AAA infrastructure is 
-     discussed in [KEYING].  
-
-   - Authentication 
-
-     This document assumes that the TLS server is authenticated to the 
-     TLS client as part of the authentication procedure of the initial 
-     TLS Handshake. This approach is similar to the one chosen with 
-     the EAP support in IKEv2 (see [IKEv2]). Typically, public key 
-     based server authentication is used for this purpose. More 
-     interesting is the client authentication property whereby 
-     information exchanged as part of the Inner Application is used to 
-     authenticate (or authorize) the client. For example, if EAP is 
-     used as an inner application then EAP methods are used to perform 
-     authentication and key agreement between the EAP peer (most 
-     likely the TLS client) and the EAP server (i.e., AAA server).  
-
-   - Authorization  
-
-     Throughout this document it is assumed that the TLS server can be 
-     authorized by the TLS client as a legitimate server as part of 
-     the authentication procedure of the initial TLS Handshake. The 
-     entity acting as TLS client can be authorized either by the TLS 
-     server or by the AAA server (if the authorization decision is 
-     offloaded). Typically, the authenticated identity is used to 
-     compute the authorization decision but credential-based 
-     authorization mechanisms may be used as well. 
-
-   - Man-in-the-Middle Attack 
-
-     Man-in-the-middle attacks have become a concern with tunneled 
-     authentication protocols because of the discovered 
-     vulnerabilities (see [MITM]) of a missing cryptographic binding 
-     between the independent protocol sessions. This document also 
-     proposes a tunneling protocol, namely individual inner 
-     application sessions are tunneled within a previously executed 
-     session. The first protocol session in this exchange is the 
-     initial TLS Handshake. To avoid man-in-the-middle attacks a 
-     number of sections address how to establish such a cryptographic 
-     binding (see Section 2.3 and 2.6).  
-
-   - User Identity Confidentiality 
-
-     The TLS/IA extension allows splitting the authentication of the 
-     TLS server from the TLS client into two separate sessions. As one 
-     of the advantages, this provides active user identity 
-     confidentiality since the TLS client is able to authenticate the 
-     TLS server and to establish a unilateral authenticated and 
-
-
-
-Paul Funk                 expires April 2005                 [Page 28] 
-
-Internet-Draft                                            October 2004         
-
-
-     confidentiality-protected channel prior to starting the client-
-     side authentication. 
-
-   - Session Key Establishment 
-
-     TLS [RFC2246] defines how session key material produced during 
-     the TLS Handshake is generated with the help of a pseudo-random 
-     function to expand it to keying material of the desired length 
-     for later usage in the TLS Record Layer. Section 2.3 gives some 
-     guidelines with regard to the master key generation. Since the 
-     TLS/IA extension supports multiple exchanges whereby each phase 
-     concludes with a generated keying material. In addition to the 
-     keying material established as part of TLS itself, most inner 
-     applications will produce their keying material. For example, 
-     keying material established as part of an EAP method must be 
-     carried from the AAA server to the AAA client. Details are 
-     subject to the specific AAA protocol (for example, EAP usage in 
-     Diameter [AAA-EAP].  
-
-   - Denial of Service Attacks 
-
-     This document does not modify the initial TLS Handshake and as 
-     such, does not introduce new vulnerabilities with regard to DoS 
-     attacks. Since the TLS/IA extension allows to postpone the 
-     client-side authentication to a later stage in the protocol 
-     phase. As such, it allows malicious TLS clients to initiate a 
-     number of exchanges while remaining anonymous. As a consequence, 
-     state at the server is allocated and computational efforts are 
-     required at the server side. Since the TLS client cannot be 
-     stateless this is not strictly a DoS attack. 
-
-   - Confidentiality Protection and Dictionary Attack Resistance 
-
-     Similar to the user identity confidentiality property the usage 
-     of the TLS/IA extension allows to establish a unilateral 
-     authenticated tunnel which is confidentiality protected. This 
-     tunnel protects the inner application information elements to be 
-     protected against active adversaries and therefore provides 
-     resistance against dictionary attacks when password-based 
-     authentication protocols are used inside the tunnel. In general, 
-     information exchanged inside the tunnel experiences 
-     confidentiality protection.  
-
-   - Downgrading Attacks 
-
-     This document defines a new extension. The TLS client and the TLS 
-     server indicate the capability to support the TLS/IA extension as 
-     part of the client_hello_extension_list and the 
-     server_hello_extension_list payload. More details can be found in 
-     Section 2.8. To avoid downgrading attacks whereby an adversary 
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 29] 
-
-Internet-Draft                                            October 2004         
-
-
-     removes a capability from the list is avoided by the usage of the 
-     Finish or PhaseFinished message as described in Section 2.6. 
-
-7  References 
-
-7.1  Normative References 
-
-   [RFC1700]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 
-               1700, October 1994. 
-
-   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication 
-               Protocol (CHAP)", RFC 1994, August 1996. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
-               Requirement Levels", RFC 2119, March 1997. 
-
-   [RFC2246]  Dierks, T., and C. Allen, "The TLS Protocol Version 
-               1.0", RFC 2246, November 1998. 
-
-   [RFC2433]  Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", 
-               RFC 2433, October 1998. 
-
-   [RFC2486]  Aboba, B., and M. Beadles, "The Network Access 
-               Identifier", RFC 2486, January 1999. 
-
-   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 
-               RFC 2548, March 1999. 
-
-   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 
-               RFC 2759, January 2000. 
-
-   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, 
-               "Remote Authentication Dial In User Service (RADIUS)", 
-               RFC 2865, June 2000. 
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 
-               J., and T. Wright, "Transport Layer Security (TLS) 
-               Extensions", RFC 3546, June 2003. 
-
-   [RFC3579]  Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication 
-               Dial In User Service) Support For Extensible 
-               Authentication Protocol (EAP)", RFC 3579, September 
-               2003. 
-
-   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 
-               Arkko, "Diameter Base Protocol", RFC 3588, July 2003. 
-
-   [RFC3784]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 
-               H. Levkowetz, "PPP Extensible Authentication Protocol 
-               (EAP)", RFC 3784, June 2004. 
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 30] 
-
-Internet-Draft                                            October 2004         
-
-
- 
-7.2  Informative References 
-
-   [RFC1661]  Simpson, W. (Editor), "The Point-to-Point Protocol 
-               (PPP)", STD 51, RFC 1661, July 1994. 
-
-   [RFC2716]  Aboba, B., and D. Simon, "PPP EAP TLS Authentication 
-               Protocol", RFC 2716, October 1999. 
-
-   [EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS 
-               Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-
-               eap-ttls-05.txt, July 2004. 
-
-   [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 
-               and S. Josefsson, "Protected EAP Protocol (PEAP) Version 
-               2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 
-               2004. 
-
-   [TLS-PSK]  Eronen, P., and H. Tschofenig, "Pre-Shared Key 
-               Ciphersuites for Transport Layer Security (TLS)", draft-
-               ietf-tls-psk-01.txt, August 2004. 
-
-   [802.1X]   IEEE Standards for Local and Metropolitan Area Networks:  
-               Port based Network Access Control, IEEE Std 802.1X-2001, 
-               June 2001. 
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 
-               in Tunneled Authentication", 
-               http://www.saunalahti.fi/~asokan/research/mitm.html, 
-               Nokia Research Center, Finland, October 24 2002. 
-
-   [KEYING]   Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 
-               Key Management Framework", draft-ietf-eap-keying-01.txt 
-               (work in progress), October 2003. 
-
-   [IKEv2]    C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 
-               draft-ietf-ipsec-ikev2-16.txt (work in progress), 
-               September 2004. 
-
-   [AAA-EAP]  Eronen, P., Hiller, T. and G. Zorn, "Diameter Exntesible 
-               Authentication Protocol (EAP) Application", draft-ietf-
-               aaa-eap-03.txt (work in progress), October 2003. 
-
-8  Authors' Addresses 
-
-   Questions about this memo can be directed to: 
-
-      Paul Funk 
-      Funk Software, Inc. 
-      222 Third Street 
-      Cambridge, MA 02142 
-
-
-
-Paul Funk                 expires April 2005                 [Page 31] 
-
-Internet-Draft                                            October 2004         
-
-
-      USA 
-      Phone: +1 617 497-6339 
-      E-mail: paul@funk.com 
-
-      Simon Blake-Wilson 
-      Basic Commerce & Industries, Inc. 
-      96 Spadina Ave, Unit 606  
-      Toronto, Ontario M5V 2J6 
-      Canada 
-      Phone: +1 416 214-5961 
-      E-mail: sblakewilson@bcisse.com 
-
-      Ned Smith 
-      Intel Corporation 
-      MS: JF1-229 
-      2111 N.E. 25th Ave. 
-      Hillsboro, OR 97124 
-      Phone: +1 503 264-2692  
-      E-mail: ned.smith@intel.com 
-
-      Hannes Tschofenig 
-      Siemens 
-      Otto-Hahn-Ring 6 
-      Munich, Bayern  81739\ 
-      Germany 
-      Phone: +49 89 636 40390 
-      E-mail: Hannes.Tschofenig@siemens.com 
-
-9  Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-
-
-
-Paul Funk                 expires April 2005                 [Page 32] 
-
-Internet-Draft                                            October 2004         
-
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The Internet Society (2001 - 2004).  This document is 
-   subject to the rights, licenses and restrictions contained in BCP 
-   78, and except as set forth therein, the authors retain all their 
-   rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Paul Funk                 expires April 2005                 [Page 33] 
-
-
-
diff --git a/doc/protocol/draft-funk-tls-inner-application-extension-01.txt b/doc/protocol/draft-funk-tls-inner-application-extension-01.txt
deleted file mode 100644
index 39404fc40c..0000000000
--- a/doc/protocol/draft-funk-tls-inner-application-extension-01.txt
+++ /dev/null
@@ -1,1885 +0,0 @@
-
-
-
-
-TLS Working Group                                             Paul Funk 
-Internet-Draft                                      Funk Software, Inc. 
-Category: Standards Track                            Simon Blake-Wilson 
-<draft-funk-tls-inner-application-extension-01.txt>    Basic Commerce &  
-                                                       Industries, Inc. 
-                                                              Ned Smith 
-                                                            Intel Corp. 
-                                                      Hannes Tschofenig 
-                                                             Siemens AG 
-                                                        Thomas Hardjono 
-                                                          VeriSign Inc. 
-                                                          February 2005 
-
-                                     
-
-                    TLS Inner Application Extension 
-                               (TLS/IA) 
-
-                                     
-
-Status of this Memo 
-
-   This document is an Internet-Draft and is subject to all provisions 
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each 
-   author represents that any applicable patent or other IPR claims of 
-   which he or she is aware have been or will be disclosed, and any of 
-   which he or she become aware will be disclosed, in accordance with 
-   RFC 3668. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 (2001 - 2005). All Rights 
-   Reserved. 
-
-Abstract 
-
-Internet-Draft                                           February 2005         
-
-
-   This document defines a new TLS extension called "Inner 
-   Application". When TLS is used with the Inner Application extension 
-   (TLS/IA), additional messages are exchanged after completion of the 
-   TLS handshake, in effect providing an extended handshake prior to 
-   the start of upper layer data communications. Each TLS/IA message 
-   contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from 
-   the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and 
-   Diameter have the same meaning in TLS/AI; that is, each attribute 
-   code point refers to the same logical attribute in any of these 
-   protocols. Arbitrary "applications" may be implemented using the AVP 
-   exchange. Possible applications include EAP or other forms of user 
-   authentication, client integrity checking, provisioning of 
-   additional tunnels, and the like. Use of the RADIUS/Diameter 
-   namespace provides natural compatibility between TLS/IA applications 
-   and widely deployed AAA infrastructures. 
-
-   It is anticipated that TLS/IA will be used with and without 
-   subsequent protected data communication within the tunnel 
-   established by the handshake. For example, TLS/IA may be used to 
-   secure an HTTP data connection, allowing more robust password-based 
-   user authentication to occur than would otherwise be possible using 
-   mechanisms available in HTTP. TLS/IA may also be used for its 
-   handshake portion alone; for example, EAP-TTLSv1 encapsulates a 
-   TLS/IA handshake in EAP as a means to mutually authenticate a client 
-   and server and establish keys for a separate data connection. 
-
-Table of Contents 
-
-1    Introduction...................................................  3 
-1.1    A Bit of History .......................................... .. 4 
-1.2    TLS With or Without Upper Layer Data Communications..........  5 
-2    The Inner Application Extension to TLS.........................  5 
-2.1    TLS/IA Overview..............................................  7 
-2.2    Message Exchange ............................................  8 
-2.3    Inner Secret.................................................  9 
-2.3.1    Computing the Inner Secret.................................  9 
-2.3.2    Exporting the Final Inner Secret........................... 10 
-2.3.3    Application Session Key Material........................... 10 
-2.4    Session Resumption........................................... 12 
-2.5    Error Termination............................................ 12 
-2.6    Negotiating the Inner Application Extension.................. 12 
-2.7    InnerApplication Protocol.................................... 13 
-2.7.1    InnerApplicationExtension.................................. 13 
-2.7.2    InnerApplication Message................................... 14 
-2.7.3    IntermediatePhaseFinished and FinalPhaseFinished Messages.. 14 
-2.7.4    The ApplicationPayload Message ............................ 15 
-2.8    Alerts....................................................... 15 
-3    Encapsulation of AVPs within ApplicationPayload Messages....... 16 
-3.1    AVP Format................................................... 16 
-3.2    AVP Sequences................................................ 17 
-3.3    Guidelines for Maximum Compatibility with AAA Servers........ 18 
-
-
-
-Paul Funk                 expires August 2005                  [Page 2] 
-
-Internet-Draft                                           February 2005         
-
-
-4    Tunneled Authentication within Application Phases ............. 18 
-4.1    Implicit challenge........................................... 18 
-4.2    Tunneled Authentication Protocols............................ 19 
-4.2.1    EAP........................................................ 20 
-4.2.2    CHAP....................................................... 20 
-4.2.3    MS-CHAP.................................................... 21 
-4.2.4    MS-CHAP-V2................................................. 21 
-4.2.5    PAP........................................................ 23 
-4.3    Performing Multiple Authentications.......................... 23 
-5    Example Message Sequences...................................... 24 
-5.1    Full Initial Handshake with Multiple Application Phases ..... 24 
-5.2    Resumed Session with Single Application Phase................ 25 
-5.3    Resumed Session with No Application Phase.................... 26 
-6    Security Considerations........................................ 26 
-7    References .................................................... 29 
-7.1    Normative References......................................... 29 
-7.2    Informative References....................................... 30 
-8     Authors' Addresses ........................................... 30 
-9     Intellectual Property Statement............................... 31 
-    
-
-1  Introduction 
-
-   This specification defines the TLS "Inner Application" extension. 
-   The term "TLS/IA" refers to the TLS protocol when used with the 
-   Inner Application extension. 
-
-   In TLS/IA, the setup portion of TLS is extended to allow an 
-   arbitrary exchange of information between client and server within a 
-   protected tunnel established during the TLS handshake and prior to 
-   the start of upper layer TLS data communications. The TLS handshake 
-   itself is unchanged; the subsequent Inner Application exchange is 
-   conducted under the confidentiality and integrity protection 
-   afforded by the TLS handshake. 
-
-   The primary motivation for providing such communication is to allow 
-   robust user authentication to occur as part of an "extended"  
-   handshake, in particular, user authentication that is based on 
-   password credentials, which is best conducted under the protection 
-   of an encrypted tunnel to preclude dictionary attack by 
-   eavesdroppers. For example, Extensible Authentication Protocol (EAP) 
-   may be used to authenticate using any of a wide variety of methods 
-   as part of this extended handshake. The multi-layer approach of 
-   TLS/IA, in which a strong authentication, typically based on a 
-   server certificate, is used to protect a password-based 
-   authentication, distinguishes it from other TLS variants that rely 
-   entirely on a pre-shared key or password for security; for example 
-   [TLS-PSK]. 
-
-   The protected exchange accommodates any type of client-server 
-   application, not just authentication, though authentication may 
-
-
-
-Paul Funk                 expires August 2005                  [Page 3] 
-
-Internet-Draft                                           February 2005         
-
-
-   often be the prerequisite that allows other applications to proceed. 
-   For example, TLS/IA may be used to set up HTTP connections, 
-   establish IPsec security associations (as an alternative to IKE), 
-   obtain credentials for single sign-on, provide for client integrity 
-   verification, and so on. 
-
-   The new messages that are exchanged between client and server are 
-   encoded as sequences of Attribute-Value-Pairs (AVPs) from the 
-   RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace 
-   provides natural compatibility between TLS/IA applications and 
-   widely deployed AAA infrastructures. This namespace is extensible, 
-   allowing new AVPs and, thus, new applications to be defined as 
-   needed, either by standards bodies or by vendors wishing to define 
-   proprietary applications. 
-
-   The TLS/IA exchange comprises one or more "phases", each of which 
-   consists of an arbitrary number of AVP exchanges followed by a 
-   confirmation exchange. Authentications occurring in any phase must 
-   be confirmed prior to continuing to the next phase. This allows 
-   applications to implement security dependencies in which particular 
-   assurances are required prior to exchange of additional information. 
-
-1.1  A Bit of History 
-
-   The TLS protocol has its roots in the Netscape SSL protocol, which 
-   was originally intended to secure HTTP. It provides either one-way 
-   or mutual authentication of client and server based on certificates. 
-   In its most typical use in HTTP, the client authenticates the server 
-   based on the server's certificate and establishes a tunnel through 
-   which HTTP traffic is passed.  
-
-   For the server to authenticate the client within the TLS handshake, 
-   the client must have its own certificate. In cases where the client 
-   must be authenticated without a certificate, HTTP, not TLS, 
-   mechanisms would have to be employed. For example, HTTP headers have 
-   been defined to perform user authentications. However, these 
-   mechanisms are primitive compared to other mechanisms, most notably 
-   EAP, that have been defined for contexts other than HTTP. 
-   Furthermore, any mechanisms defined for HTTP cannot be utilized when 
-   TLS is used to protect non-HTTP traffic. 
-
-   The TLS protocol has also found an important use in authentication 
-   for network access, originally within PPP for dial-up access and 
-   later for wireless and wired 802.1X access. Several EAP types have 
-   been defined that utilize TLS to perform mutual client-server 
-   authentication. The first to appear, EAP-TLS, uses the TLS handshake 
-   to authenticate both client and server based on the certificate of 
-   each.  
-
-   Subsequent protocols, such EAP-TTLSv0 and EAP-PEAP, utilize the TLS 
-   handshake to allow the client to authenticate the server based on 
-
-
-
-Paul Funk                 expires August 2005                  [Page 4] 
-
-Internet-Draft                                           February 2005         
-
-
-   the latter's certificate, then utilize the tunnel established by the 
-   TLS handshake to perform user authentication, typically based on 
-   password credentials. Such protocols are called "tunneled" EAP 
-   protocols. The authentication mechanism used inside the tunnel may 
-   itself be EAP, and the tunnel may also be used to convey additional 
-   information between client and server. 
-
-   TLS/IA is in effect a merger of the two types of TLS usage described 
-   above, based on the recognition that tunneled authentication would 
-   be useful in other contexts besides EAP. However, the tunneled 
-   protocols mentioned above are not directly compatible with a more 
-   generic use of TLS, because they utilize the tunneled data portion 
-   of TLS, thus precluding its use for other purposes such as carrying 
-   HTTP traffic. 
-
-   The TLS/IA solution to this problem is to insert an additional 
-   message exchange between the TLS handshake and the subsequent data 
-   communications phase, carried in a new record type distinct from the 
-   record type that carries upper layer data. Thus, the data portion of 
-   the TLS exchange becomes available for HTTP or any other protocol or 
-   connection that needs to be secured. 
-
-1.2  TLS With or Without Upper Layer Data Communications 
-
-   It is anticipated that TLS/IA will be used with and without 
-   subsequent protected data communication within the tunnel 
-   established by the handshake.  
-
-   For example, TLS/IA may be used to secure an HTTP data connection, 
-   allowing more robust password-based user authentication to occur 
-   within the TLS/IA extended handshake than would otherwise be 
-   possible using mechanisms available in HTTP.  
-
-   TLS/IA may also be used for its handshake portion alone. For 
-   example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP 
-   as a means to mutually authenticate a client and server and 
-   establish keys for a separate data connection; no subsequent TLS 
-   data portion is required. Another example might be use of TLS/IA 
-   directly over TCP to provide a user with credentials for single 
-   sign-on. 
-
-2  The Inner Application Extension to TLS 
-
-   The Inner Application extension to TLS follows the guidelines of 
-   [RFC3546].  
-
-   A new extension type is defined for negotiating use of TLS/IA 
-
-   -  The InnerApplicationExtension extension type. The client proposes 
-      use of this extension by including a InnerApplicationExtension 
-      message in its ClientHello handshake message, and the server 
-
-
-
-Paul Funk                 expires August 2005                  [Page 5] 
-
-Internet-Draft                                           February 2005         
-
-
-      confirms its use by including a InnerApplicationExtension message 
-      in its ServerHello handshake message.  
-
-   A new record type (ContentType) is defined for use in TLS/IA: 
-
-   -  The InnerApplication record type. This record type carries all 
-      messages that implement the inner application extension. These 
-      messages will occur after the TLS handshake and prior to exchange 
-      of data. 
-
-   A new message type is defined for use within the InnerApplication 
-   record type: 
-
-   -  The InnerApplication message. This message may encapsulate any of 
-      three subtypes: 
-
-      -  The ApplicationPayload message. This message is used to carry 
-         AVP (Attribute-Value Pair) sequences within the TLS/IA 
-         extended handshake, in support of client-server applications 
-         such as authentication. 
-
-      -  The IntermediatePhaseFinished message. This message confirms 
-         session keys established during the current TLS/IA phase, and 
-         indicates that at least one additional phase is to follow. 
-
-      -  The FinalPhaseFinished message. This message confirms session 
-         keys established during the current TLS/IA phase, and 
-         indicates that no further phases are to follow. 
-
-   Two new alert codes are defined for use in TLS/IA: 
-
-   -  The InnerApplicationFailure alert. This error alert allows either 
-      party to terminate the TLS/IA extended handshake due to a failure 
-      in an application implemented via AVP sequences carried in 
-      ApplicationPayload messages. 
-
-   -  The InnerApplicationVerification alert. This error alert allows 
-      either party to terminate the TLS/IA extended handshake due to 
-      incorrect verification data in a received 
-      IntermediatePhaseFinished or FinalPhaseFinished message. 
-
-   The following new assigned numbers are used in TLS/IA: 
-
-   -  "InnerApplicationExtension" extension type:37703 
-
-   -  "InnerApplication" record type:          24 
-
-   -  "InnerApplicationFailure" alert code:   208 
-
-   -  "InnerApplicationVerification" alert code:209 
-
-
-
-
-Paul Funk                 expires August 2005                  [Page 6] 
-
-Internet-Draft                                           February 2005         
-
-
-   [Editor's note: I have not checked these types yet against types 
-   defined in RFCs or drafts. The TLS RFC specifies that new record 
-   types use the next number after ones already defined; hence I used 
-   24, though I don't know if that is already taken.] 
-
-2.1  TLS/IA Overview 
-
-   In TLS/IA, zero  or more "application phases are inserted after the 
-   TLS handshake and prior to ordinary data exchange. The last such 
-   application phase is called the "final phase"; any application 
-   phases prior to the final phase are called "intermediate phases". 
-
-   Intermediate phases are only necessary if interim confirmation of 
-   session keys generated during an application phase is desired.  
-
-   Each application phase consists of ApplicationPayload handshake 
-   messages exchanged by client and server to implement applications 
-   such as authentication, plus concluding messages for cryptographic 
-   confirmation. These messages are encapsulated in records with 
-   ContentType of InnerApplication. 
-
-   All application phases prior to the final phase use 
-   IntermediatePhaseFinished rather than FinalPhaseFinished as the 
-   concluding message. The final phase concludes with the 
-   FinalPhaseFinished message.  
-
-   Application phases may be omitted entirely only when session 
-   resumption is used, provided both client and server agree that no 
-   application phase is required. The client indicates in its 
-   ClientHello whether it is willing to omit application phases in a 
-   resumed session, and the server indicates in its ServerHello whether 
-   any application phases are to ensue. 
-
-   In each application phase, the client sends the first 
-   ApplicationPayload message. ApplicationPayload messages are then 
-   traded one at a time between client and server, until the server 
-   concludes the phase by sending, in response to an ApplicationPayload 
-   message from the client, an IntermediatePhaseFinished sequence to 
-   conclude an intermediate phase, or a FinalPhaseFinished sequence to 
-   conclude the final phase. The client then responds with its own 
-   IntermediatePhaseFinished or FinalPhaseFinished message.  
-
-   Note that the server MUST NOT send an IntermediatePhaseFinished or 
-   FinalPhaseFinished message immediately after sending an 
-   ApplicationPayload message. It must allow the client to send an 
-   ApplicationPayload message prior to concluding the phase. Thus, 
-   within any application phase, there will be one more 
-   ApplicationPayload message sent by the client than sent by the 
-   server. 
-
-
-
-
-
-Paul Funk                 expires August 2005                  [Page 7] 
-
-Internet-Draft                                           February 2005         
-
-
-   The server determines which type of concluding message is used, 
-   either IntermediatePhaseFinished or FinalPhaseFinished, and the 
-   client MUST echo the same type of concluding message. Each 
-   IntermediatePhaseFinished or FinalPhaseFinished message provides 
-   cryptographic confirmation of any session keys generated during the 
-   current and any prior applications phases. 
-
-   Each ApplicationPayload message contains opaque data interpreted as 
-   an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence 
-   contains a typed data element. The exchanged AVPs allow client and 
-   server to implement "applications" within a secure tunnel. An 
-   application may be any procedure that someone may usefully define. A 
-   typical application might be authentication; for example, the server 
-   may authenticate the client based on password credentials using EAP. 
-   Other possible applications include distribution of keys, validating 
-   client integrity, setting up IPsec parameters, setting up SSL VPNs, 
-   and so on. 
-
-   An "inner secret" is computed during each application phase that 
-   mixes the TLS master secret with any session keys that have been 
-   generated during the current and any previous application phases. At 
-   the conclusion of each application phase, a new inner secret is 
-   computed and is used to create verification data that is exchanged 
-   via the IntermediatePhaseFinished or FinalPhaseFinished messages. By 
-   mixing session keys of inner authentications with the TLS master 
-   secret, certain man-in-the-middle attacks are thwarted [MITM]. 
-
-2.2  Message Exchange 
-
-   Each intermediate application phase consists of ApplicationPayload 
-   messages sent alternately by client and server, and a concluding 
-   exchange of IntermediatePhaseFinished messages. The first and last 
-   ApplicationPayload message in each intermediate phase is sent by the 
-   client; the first IntermediatePhaseFinished message is sent by the 
-   server. Thus the client begins the exchange with an 
-   ApplicationPayload message and the server determines when to 
-   conclude it by sending IntermediatePhaseFinished. When it receives 
-   the server's IntermediatePhaseFinished message, the client sends its 
-   own IntermediatePhaseFinished  message, followed by an 
-   ApplicationPayload message to begin the next handshake phase.  
-
-   The final application proceeds in the same manner as the 
-   intermediate phase, except that the FinalPhaseFinished message is 
-   sent by the server and echoed by the client, and the client does not 
-   send an ApplicationPayload message for the next phase because there 
-   is no next phase. 
-
-   At the start of each application phase, the server MUST wait for the 
-   client's opening ApplicationPayload message before it sends its own 
-   ApplicationPayload message to the client. The client MAY NOT 
-   initiate conclusion of an application handshake phase by sending the 
-
-
-
-Paul Funk                 expires August 2005                  [Page 8] 
-
-Internet-Draft                                           February 2005         
-
-
-   first IntermediatePhaseFinished or FinalPhaseFinished message; it 
-   MUST allow the server to initiate the conclusion of the phase. 
-
-   Note that it is perfectly acceptable for either client or server to 
-   send an ApplicationPayload message containing no AVPs. The client, 
-   for example, may have no AVPs to send in its first or last 
-   ApplicationPayload message during an application phase.  
-
-2.3  Inner Secret  
-
-   The inner secret is a 48-octet value used to confirm that the 
-   endpoints of the TLS handshake are the same entities as the 
-   endpoints of the inner authentications that may have been performed 
-   during each application phase. 
-
-   The inner secret is initialized at the conclusion of the TLS 
-   handshake and permuted at the conclusion of each application phase.  
-
-   The inner secret that results from the final application phase is 
-   the final inner secret. 
-
-   When a new (non-resumed) session is negotiated, the resulting final 
-   inner secret is saved as part of the session state for use in 
-   session resumption. 
-
-2.3.1 Computing the Inner Secret 
-
-   At the conclusion of the TLS handshake, each party initializes the 
-   inner secret to: 
-
-   -  the master secret, if this is a new session 
-
-   -  the previously computed final inner secret of the original 
-      session, if this is a resumed session 
-
-   At the conclusion of each application phase, prior to computing 
-   verification data for inclusion in the IntermediatePhaseFinished or 
-   FinalPhaseFinished message, each party permutes the inner secret 
-   using a PRF that includes session keys produced during the current 
-   application phase. The value that results replaces the current inner 
-   secret and is used to compute the verification data. 
-
-      inner_secret = PRF(inner_secret,  
-                         "inner secret permutation",  
-                         SecurityParameters.server_random + 
-                         SecurityParameters.client_random +  
-                          session_key_material) [0..48]; 
-
-   session_key_material is the concatenation of session_key vectors, 
-   one for each session key generated during the current phase, where: 
-
-
-
-
-Paul Funk                 expires August 2005                  [Page 9] 
-
-Internet-Draft                                           February 2005         
-
-
-      opaque session_key<1..2^16-1>; 
-
-   In other words, each session key is prefixed by a 2-octet length to 
-   produce the session_key vector. 
-
-   Since multiple session keys may be produced during a single 
-   application phase, the following method is used to determine the 
-   order of concatenation: Each session key is treated as an unsigned 
-   big-endian numeric value, and the set of session keys is ordered 
-   from lowest to highest. The session keys are then converted to 
-   session_key vectors and concatenated in the determined order to form 
-   session_key_material. 
-
-   If no session keys were generated during the current phase, 
-   session_key_material will be null. 
-
-   Note that session_key_material itself is not a vector and therefore 
-   not prefixed with the length of the entire collection of session_key 
-   vectors. 
-
-2.3.2 Exporting the Final Inner Secret 
-
-   Note that, within TLS itself, the inner secret is used for 
-   verification only, not for encryption. However, the inner secret 
-   resulting from the final application phase may be exported for use 
-   as a key from which additional session keys may be derived for 
-   arbitrary  purposes, including encryption of data communications 
-   separate from TLS. 
-
-   An exported inner secret should not be used directly as a session 
-   key. Instead, additional keys should be derived from the inner 
-   secret, for example by using a PRF, and the client and server 
-   randoms should be incorporated into the derivation. This ensures 
-   cryptographic separation between use of the inner secret for session 
-   key confirmation and additional use of the inner secret outside 
-   TLS/IA. 
-
-   Note that for a resumed session that does not include an application 
-   phase, the final inner secret of that session is identical to that 
-   of the original session; hence, incorporation of randoms becomes 
-   critically important to ensure the cryptographic separation of the 
-   keys derived from sessions sharing a common original session. 
-
-2.3.3 Application Session Key Material 
-
-   Many authentication protocols used today generate session keys that 
-   are bound to the authentication. Such keying material is normally 
-   intended for use in a subsequent data connection for encryption and 
-   validation. For example, EAP-TLS, MS-CHAP-V2 and its alter ego EAP-
-   MS-CHAP-V2 each generate session keys. 
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 10] 
-
-Internet-Draft                                           February 2005         
-
-
-   Any session keys generated during an application phase MUST be used 
-   to permute the TLS/IA inner secret between one phase and the next, 
-   and MUST NOT be used for any other purpose.  
-
-   Each authentication protocol may define how the session key it 
-   generates is mapped to an octet sequence of some length for the 
-   purpose of TLS/IA mixing. However, for protocols which do not 
-   specify this (including the multitude of protocols that pre-date 
-   TLS/IA) the following rules are defined. The first rule that applies 
-   SHALL be the method for determining the session key: 
-
-   -  If the authentication protocol produces an MSK (as defined in 
-      [RFC3784]), the MSK is used as the session key.  Note that an MSK 
-      is 64 octets. 
-
-   -  If the authentication protocol maps its keying material to the 
-      RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key 
-      [RFC2548], then the keying material for those attributes are 
-      concatenated, with MS-MPPE-Recv-Key first  (Note that this rule 
-      applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.) 
-
-   -  If the authentication protocol uses a pseudo-random function to 
-      generate keying material, that function is used to generate 64 
-      octets for use as keying material. 
-
-   Providing verification of the binding of session keys to the TLS 
-   master secret is necessary to preclude man-in-the-middle attacks 
-   against tunneled authentication protocols, as described in [MITM]. 
-   In such an attack, an unsuspecting client is induced to perform an 
-   untunneled authentication with an attacker posing as a server; the 
-   attacker then introduces the authentication protocol into a tunneled 
-   authentication protocol, fooling an authentic server into believing 
-   that the attacker is the authentic user. 
-
-   By mixing both the TLS master secret and session keys generated 
-   during application phase authentication into the inner secret used 
-   for application phase verification, such attacks are thwarted, as it 
-   guarantees that the same client both terminated the TLS handshake 
-   and performed the application phase authentication. Note that the 
-   session keys generated during authentication must be 
-   cryptographically related to the authentication and not derivable 
-   from data exchanged during authentication in order for the keying 
-   material to be useful in thwarting such attacks. 
-
-   In addition, the fact that the inner secret cryptographically 
-   incorporates session keys from application phase authentications 
-   provides additional protection when the inner secret is exported for 
-   the purpose of generating additional keys for use outside of the TLS 
-   exchange. If such an exported secret did not include keying material 
-   from inner authentications, an eavesdropper who somehow knew the 
-   server's private key could, in an RSA-based handshake, determine the 
-
-
-
-Paul Funk                 expires August 2005                 [Page 11] 
-
-Internet-Draft                                           February 2005         
-
-
-   exported secret and hence would be able to compute the additional 
-   keys that are based on it. When inner authentication keying material 
-   is incorporated into the exported secret, such an attack becomes 
-   impossible. 
-
-2.4  Session Resumption 
-
-   A TLS/IA initial handshake phase may be resumed using standard 
-   mechanisms defined in [RFC2246]. When the TLS session is resumed, 
-   client and server may not deem it necessary to exchange AVPs in one 
-   or more additional application phases, as the resumption itself may 
-   provide all the security needed. 
-
-   The client indicates within the InnerApplicationExtension message in 
-   ClientHello whether it requires AVP exchange when session resumption 
-   occurs. If it indicates that it does not, then the server may at its 
-   option omit application phases and the two parties proceed to upper 
-   layer data communications immediately upon completion of the TLS 
-   handshake. The server indicates whether application phases are to 
-   follow the TLS handshake in its InnerApplication extension message 
-   in ServerHello. 
-
-   Note that [RFC3546] specifically states that when session resumption 
-   is used, the server MUST ignore any extensions in the ClientHello. 
-   However, it is not possible to comply with this requirement for the 
-   Inner Application extension, since even in a resumed session it may 
-   be necessary to include application phases, and whether they must be 
-   included is negotiated in the extension message itself. Therefore, 
-   the [RFC3546] provision is specifically overridden for the single 
-   case of the Inner Application extension, which is considered an 
-   exception to this rule.  
-
-   A TLS/IA session MAY NOT be resumed if an application phase resulted 
-   in failure, even though the TLS handshake itself succeeded. Both 
-   client and server MUST NOT save session state for possible future 
-   resumption unless the TLS handshake and all subsequent application 
-   phases succeed. 
-
-2.5  Error Termination 
-
-   The TLS/IA handshake may be terminated by either party sending a 
-   fatal alert, following standard TLS procedures.  
-
-2.6  Negotiating the Inner Application Extension 
-
-   Use of the InnerApplication extension follows [RFC3546]. The client 
-   proposes use of this extension by including the 
-   InnerApplicationExtension message in the client_hello_extension_list 
-   of the extended ClientHello. If this message is included in the 
-   ClientHello, the server MAY accept the proposal by including the 
-   InnerApplicationExtension message in the server_hello_extension_list 
-
-
-
-Paul Funk                 expires August 2005                 [Page 12] 
-
-Internet-Draft                                           February 2005         
-
-
-   of the extended ServerHello. If use of this extension is either not 
-   proposed by the client or not confirmed by the server, the 
-   InnerApplication record type MUST NOT be used. 
-
-2.7  InnerApplication Protocol 
-
-   All specifications of TLS/IA messages follow the usage defined in 
-   [RFC2246]. 
-
-2.7.1 InnerApplicationExtension 
-
-      enum { 
-         no(0), yes(1), (255) 
-      } AppPhaseOnResumption; 
-
-      struct { 
-         AppPhaseOnResumption app_phase_on_resumption; 
-      } InnerApplicationExtension; 
-
-   If the client wishes to propose use of the Inner Application 
-   extension, it must include the InnerApplicationExtension message in 
-   the extension_data vector in the Extension structure in its extended 
-   ClientHello message. 
-
-   If the server wishes to confirm use of the Inner Application 
-   extension that has been proposed by the client, it must include the 
-   InnerApplicationExtension message in the extension_data vector in 
-   the Extension structure in its extended ServerHello message. 
-
-   The AppPhaseOnResumption enumeration allow client and server to 
-   negotiate an abbreviated, single-phase handshake when session 
-   resumption is employed. If the client sets app_phase_on_resumption 
-   to "no", and if the server resumes the previous session, then the 
-   server MAY set app_phase_on_resumption to "no" in the 
-   InnerApplication message it sends to the client. If the server sets 
-   app_phase_on_resumption to "no", no application phases occur and the 
-   TLS connection proceeds to upper layer data exchange immediately 
-   upon conclusion of the TLS handshake. 
-
-   The server MUST set app_phase_on_resumption to "yes" if the client 
-   set app_phase_on_resumption to "yes" or if the server does not 
-   resume the session. The server MAY set app_phase_on_resumption to 
-   "yes" for a resumed session even if the client set 
-   app_phase_on_resumption to "no", as the server may have reason to 
-   proceed with one or more application phases. 
-
-   If the server sets app_phase_on_resumption to "yes" for a resumed 
-   session, then the client MUST initiate an application phase at the 
-   conclusion of the TLS handshake. 
-
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 13] 
-
-Internet-Draft                                           February 2005         
-
-
-   The value of app_phase_on_resumption applies to the current 
-   handshake only; that is, it is possible for app_phase_on_resumption 
-   to have different values in two handshakes that are both resumed 
-   from the same original TLS session. 
-
-2.7.2 InnerApplication Message 
-
-      enum { 
-         application_payload(0), intermediate_phase_finished(1), 
-         final_phase_finished(2), (255) 
-      } InnerApplicationType; 
-
-      struct { 
-         InnerApplicationType msg_type; 
-         uint24 length; 
-         select (InnerApplicationType) { 
-            case application_payload:       ApplicationPayload; 
-            case intermediate_phase_finished:
-         IntermediatePhaseFinished; 
-            case final_phase_finished:      FinalPhaseFinished; 
-            } body; 
-         } InnerApplication; 
-
-   The InnerApplication message carries any of the message types 
-   defined for the InnerApplication protocol. 
-
-2.7.3 IntermediatePhaseFinished and FinalPhaseFinished Messages 
-
-      struct { 
-         opaque verify_data[12]; 
-      } PhaseFinished; 
-
-      PhaseFinished IntermediatePhaseFinished; 
-
-      PhaseFinished FinalPhaseFinished; 
-
-      verify_data 
-         PRF(inner_secret, finished_label) [0..11]; 
-
-      finished_label 
-         when sent by the client, the string "client phase finished" 
-         when sent by the server, the string "server phase finished" 
-
-   The IntermediatePhaseFinished and FinalPhaseFinished messages have 
-   the same structure and include verification data based on the 
-   current inner secret. IntermediatePhaseFinished is sent by the 
-   server and echoed by the client to conclude an intermediate 
-   application phase, and FinalPhaseFinished is used in the same manner 
-   to conclude the final application phase. 
-
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 14] 
-
-Internet-Draft                                           February 2005         
-
-
-2.7.4 The ApplicationPayload Message 
-
-   The ApplicationPayload message carries an AVP sequence during an 
-   application handshake phase. It is defined as follows: 
-
-      struct { 
-         opaque avps[InnerApplication.length]; 
-      } ApplicationPayload; 
-
-      avps 
-         The AVP sequence, treated as an opaque sequence of octets. 
-
-      InnerApplication.length 
-         The length field in the encapsulating InnerApplication 
-      message. 
-
-   Note that the "avps" element has its length defined in square 
-   bracket rather than angle bracket notation, implying a fixed rather 
-   than variable length vector. This avoids having the length of the 
-   AVP sequence specified redundantly both in the encapsulating 
-   InnerApplication message and as a length prefix in the avps element 
-   itself. 
-
-2.8  Alerts 
-
-   Two new alert codes are defined for use during an application phase. 
-   The AlertLevel for either of these alert codes MUST be set to 
-   "fatal". 
-
-   InnerApplicationFailure  
-      An InnerApplicationFailure error alert may be sent by either 
-      party during an application phase. This indicates that the 
-      sending party considers the negotiation to have failed due to an 
-      application carried in the AVP sequences, for example, a failed 
-      authentication. 
-
-   InnerApplicationVerification  
-      An InnerApplicationVerification error alert is sent by either 
-      party during an application phase to indicate that the received 
-      IntermediatePhaseFinished or FinalPhaseFinished is invalid, that 
-      is, contains verification data that does not match what is 
-      expected. 
-
-   Note that other alerts are possible during an application phase; for 
-   example, decrypt_error. The InnerApplicationFailure alert relates 
-   specifically to the failure of an application implemented via AVP 
-   sequences; for example, failure of an EAP or other authentication 
-   method, or information passed within the AVP sequence that is found 
-   unsatisfactory. 
-
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 15] 
-
-Internet-Draft                                           February 2005         
-
-
-3  Encapsulation of AVPs within ApplicationPayload Messages 
-
-   During application phases of the TLS handshake, information is 
-   exchanged between client and server through the use of attribute-
-   value pairs (AVPs). This data is encrypted using the then-current 
-   cipher state established during the preceding handshake phase. 
-
-   The AVP format chosen for TLS/IA is compatible with the Diameter AVP 
-   format. This does not in any way represent a requirement that 
-   Diameter be supported by any of the devices or servers participating 
-   in the TLS/IA conversation, whether directly as client or server or 
-   indirectly as a backend authenticator. Use of this format is merely 
-   a convenience. Diameter is a superset of RADIUS and includes the 
-   RADIUS attribute namespace by definition, though it does not limit 
-   the size of an AVP as does RADIUS. RADIUS, in turn, is a widely 
-   deployed AAA protocol and attribute definitions exist for all 
-   commonly used password authentication protocols, including EAP. 
-
-   Thus, Diameter is not considered normative except as specified in 
-   this document. Specifically, the AVP Codes used in TLS/IA are 
-   semantically equivalent to those defined for Diameter, and, by 
-   extension, RADIUS.  
-
-   Use of the RADIUS/Diameter namespace allows a TLS/IA server to 
-   easily translate between AVPs it uses to communicate with clients 
-   and the protocol requirements of AAA servers that are widely 
-   deployed. Plus, it provides a well-understood mechanism to allow 
-   vendors to extend that namespace for their particular requirements. 
-
-3.1  AVP Format 
-
-   The format of an AVP is shown below. All items are in network, or 
-   big-endian, order; that is, they have most significant octet first. 
-
-    0                   1                   2                   3 
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |                           AVP Code                            | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |V M r r r r r r|                  AVP Length                   | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |                        Vendor-ID (opt)                        | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |    Data ... 
-   +-+-+-+-+-+-+-+-+ 
-
-   AVP Code 
-
-      The AVP Code is four octets and, combined with the Vendor-ID 
-      field if present, identifies the attribute uniquely. The first 
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 16] 
-
-Internet-Draft                                           February 2005         
-
-
-      256 AVP numbers represent attributes defined in RADIUS. AVP 
-      numbers 256 and above are defined in Diameter. 
-
-   AVP Flags 
-
-      The AVP Flags field is one octet, and provides the receiver with 
-      information necessary to interpret the AVP.  
-
-      The 'V' (Vendor-Specific) bit indicates whether the optional 
-      Vendor-ID field is present. When set to 1, the Vendor-ID field is 
-      present and the AVP Code is interpreted according to the 
-      namespace defined by the vendor indicated in the Vendor-ID field. 
-
-      The 'M' (Mandatory) bit indicates whether support of the AVP is 
-      required. When set to 0, this indicates that the AVP may be 
-      safely ignored if the receiving party does not understand or 
-      support it. When set to 1, if the receiving party does not 
-      understand or support the AVP it MUST fail the negotiation by 
-      sending an InnerApplicationFailure error alert. 
-
-      The 'r' (reserved) bits are unused and must be set to 0. 
-
-   AVP Length 
-
-      The AVP Length field is three octets, and indicates the length of 
-      this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID 
-      (if present) and Data. 
-
-   Vendor-ID 
-
-      The Vendor-ID field is present if and only if the 'V' bit is set 
-      in the AVP Flags field. It is four octets, and contains the 
-      vendor's IANA-assigned "SMI Network Management Private Enterprise 
-      Codes" [RFC1700] value. Vendors defining their own AVPs must 
-      maintain a consistent namespace for use of those AVPs within 
-      RADIUS, Diameter and TLS/IA. 
-
-      A Vendor-ID value of zero is semantically equivalent to absence 
-      of the Vendor-ID field altogether. 
-
-3.2  AVP Sequences 
-
-   Data encapsulated within the TLS Record Layer must consist entirely 
-   of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet 
-   boundary relative to the first AVP in the sequence. If an AVP is not 
-   a multiple of 4 octets, it must be padded with 0s to the next 4-
-   octet boundary. 
-
-   Note that the AVP Length does not include the padding. 
-
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 17] 
-
-Internet-Draft                                           February 2005         
-
-
-3.3  Guidelines for Maximum Compatibility with AAA Servers 
-
-   When maximum compatibility with AAA servers is desired, the 
-   following guidelines for AVP usage are suggested: 
-
-   -  Non-vendor-specific AVPs should be selected from the set of 
-      attributes defined for RADIUS; that is, attributes with codes 
-      less than 256. This provides compatibility with both RADIUS and 
-      Diameter. 
-
-   -  Vendor-specific AVPs should be defined in terms of RADIUS. 
-      Vendor-specific RADIUS attributes translate to Diameter 
-      automatically; the reverse is not true. RADIUS vendor-specific 
-      attributes use RADIUS attribute 26 and include vendor ID, vendor-
-      specific attribute code and length; see [RFC2865] for details. 
-
-4  Tunneled Authentication within Application Phases 
-
-   TLS/IA permits user authentication information to be tunneled within 
-   an application phase between client and server, protecting the 
-   security of the authentication information against active and 
-   passive attack.  
-
-   Any type of password or other authentication may be tunneled. Also, 
-   multiple tunneled authentications may be performed. Normally, 
-   tunneled authentication is used when the client has not been issued 
-   a certificate and the TLS handshake provides only one-way 
-   authentication of the server to the client; however, in certain 
-   cases it may be desired to perform certificate authentication of the 
-   client during the initial handshake phase as well as tunneled user 
-   authentication in a subsequent application phase. 
-
-   This section establishes rules for using common authentication 
-   mechanisms within TLS/IA. Any new authentication mechanism should in 
-   general be covered by these rules if it is defined as an EAP type. 
-   Authentication mechanisms whose use within TLS/IA is not covered 
-   within this specification may require separate standardization, 
-   preferably within the standard that describes the authentication 
-   mechanism in question. 
-
-4.1  Implicit challenge 
-
-   Certain authentication protocols that use a challenge/response 
-   mechanism rely on challenge material that is not generated by the 
-   authentication server, and therefore require special handling. 
-
-   In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the 
-   Network Access Server (NAS) issues a challenge to the client, the 
-   client then hashes the challenge with the password and forwards the 
-   response to the NAS. The NAS then forwards both challenge and 
-   response to a AAA server. But because the AAA server did not itself 
-
-
-
-Paul Funk                 expires August 2005                 [Page 18] 
-
-Internet-Draft                                           February 2005         
-
-
-   generate the challenge, such protocols are susceptible to replay 
-   attack.  
-
-   If the client were able to create both challenge and response, 
-   anyone able to observe a CHAP or MS-CHAP exchange could pose as that 
-   user by replaying that challenge and response into a TLS/IA 
-   conversation.  
-
-   To make these protocols secure in TLS/IA, it is necessary to provide 
-   a mechanism to produce a challenge that the client cannot control or 
-   predict.  
-
-   When a challenge-based authentication mechanism is used, both client 
-   and server use the TLS PRF function to generate as many octets as 
-   are required for the challenge, using the constant string "inner 
-   application challenge", based on the then-current master secret and 
-   random values established during the initial handshake phase: 
-
-      IA_challenge = PRF(final_inner_secret, 
-                             "inner application challenge", 
-                             SecurityParameters.server_random + 
-                             SecurityParameters.client_random); 
-
-4.2  Tunneled Authentication Protocols 
-
-   This section describes the rules for tunneling specific 
-   authentication protocols within TLS/IA.  
-
-   For each protocol, the RADIUS RFC that defines the relevant 
-   attribute formats is cited. Note that these attributes are 
-   encapsulated as described in section 3.1; that is, as Diameter 
-   attributes, not as RADIUS attributes. In other words, the AVP Code, 
-   Length, Flags and optional Vendor-ID are formatted as described in 
-   section 3.1, while the Data is formatted as described by the cited 
-   RADIUS RFC. 
-
-   All tunneled authentication protocols except EAP must be initiated 
-   by the client in the first ApplicationPayload message of an 
-   application phase. EAP may be initiated by the client in the first 
-   ApplicationPayload message of an application phase; it may also be 
-   initiated by the server in any ApplicationPayload message. 
-
-   The authentication protocols described below may be performed 
-   directly by the TLS/IA server or may be forwarded to a backend AAA 
-   server. For authentication protocols that generate session keys, the 
-   backend server must return those session keys to the TLS/IA server 
-   in order to allow the protocol to succeed within TLS/IA. RADIUS or 
-   Diameter servers are suitable backend AAA servers for this purpose. 
-   RADIUS servers typically return session keys in MS-MPPE-Recv-Key and 
-   MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return 
-   session keys in the EAP-Master-Session-Key AVP [AAA-EAP]. 
-
-
-
-Paul Funk                 expires August 2005                 [Page 19] 
-
-Internet-Draft                                           February 2005         
-
-
-4.2.1 EAP 
-
-   EAP is described in [RFC3784]; RADIUS attribute formats are 
-   described in [RFC3579]. 
-
-   When EAP is the tunneled authentication protocol, each tunneled EAP 
-   packet between the client and server is encapsulated in an EAP-
-   Message AVP. 
-
-   Either client or server may initiate EAP.  
-
-   The client is the first to transmit within any application phase, 
-   and it may include an EAP-Response/Identity AVP in its 
-   ApplicationPayload message to begin an EAP conversation. 
-   Alternatively, if the client does not initiate EAP the server may, 
-   by including an EAP-Request/Identity AVP in its ApplicationPayload 
-   message. 
-
-   The client's EAP-Response/Identity provides the actual username; the 
-   privacy of the user's identity is now guaranteed by the TLS 
-   encryption. This username must be a Network Access Identifier (NAI) 
-   [RFC2486]; that is, it must be in the following format: 
-
-      username@realm 
-
-   The @realm portion is optional, and is used to allow the server to 
-   forward the EAP message sequence to the appropriate server in the 
-   AAA infrastructure when necessary.  
-
-   The EAP authentication between client and server proceeds normally, 
-   as described in [RFC3784]. However, upon completion the server does 
-   not send an EAP-Success or EAP-Failure AVP. Instead, the server 
-   signals success when it concludes the application phase by issuing a 
-   Finished or PhaseFinished message, or it signals failure by issuing 
-   an InnerApplicationFailure alert. 
-
-   Note that the client may also issue an InnerApplicationFailure 
-   alert, for example, when authentication of the server fails in a 
-   method providing mutual authentication. 
-
-4.2.2 CHAP 
-
-   The CHAP algorithm is described in [RFC1994]; RADIUS attribute 
-   formats are described in [RFC2865]. 
-
-   Both client and server generate 17 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      CHAP-Challenge    [16 octets] 
-      CHAP Identifier   [1 octet] 
-
-
-
-Paul Funk                 expires August 2005                 [Page 20] 
-
-Internet-Draft                                           February 2005         
-
-
-   The client initiates CHAP by including User-Name, CHAP-Challenge and 
-   CHAP-Password AVPs in the first ApplicationPayload message in any 
-   application phase. The CHAP-Challenge value is taken from the 
-   challenge material. The CHAP-Password consists of CHAP Identifier, 
-   taken from the challenge material; and CHAP response, computed 
-   according to the CHAP algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the CHAP-Challenge AVP and the value of the CHAP 
-   Identifier in the CHAP-Password AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the CHAP-Challenge to determine the result of the authentication. 
-
-4.2.3 MS-CHAP 
-
-   The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute 
-   formats are described in [RFC2548]. 
-
-   Both client and server generate 9 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      MS-CHAP-Challenge [8 octets] 
-      Ident              [1 octet] 
-
-   The client initiates MS-CHAP by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload 
-   message in any application phase. The MS-CHAP-Challenge value is 
-   taken from the challenge material. The MS-CHAP-Response consists of 
-   Ident, taken from the challenge material; Flags, set according the 
-   client preferences; and LM-Response and NT-Response, computed 
-   according to the MS-CHAP algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP-Response AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the MS-CHAP-Challenge to determine the result of the authentication.  
-
-4.2.4 MS-CHAP-V2 
-
-   The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute 
-   formats are described in [RFC2548]. 
-
-   Both client and server generate 17 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 21] 
-
-Internet-Draft                                           February 2005         
-
-
-      MS-CHAP-Challenge [16 octets] 
-      Ident              [1 octet] 
-
-   The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload 
-   message in any application phase. The MS-CHAP-Challenge value is 
-   taken from the challenge material. The MS-CHAP2-Response consists of 
-   Ident, taken from the challenge material; Flags, set to 0; Peer-
-   Challenge, set to a random value; and Response, computed according 
-   to the MS-CHAP-V2 algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP2-Response AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the MS-CHAP2-Challenge. 
-
-   If the MS-CHAP2-Challenge received from the client is correct, the 
-   server tunnels the MS-CHAP2-Success AVP to the client. 
-
-   Upon receipt of the MS-CHAP2-Success AVP, the client is able to 
-   authenticate the server. In its next InnerApplicationPayload message 
-   to the server, the client does not include any MS-CHAP-V2 AVPs. 
-   (This may result in an empty InnerApplicationPayload if no other 
-   AVPs need to be sent.) 
-
-   If the MS-CHAP2-Challenge received from the client is not correct, 
-   the server tunnels an MS-CHAP2-Error AVP to the client. This AVP 
-   contains a new Ident and a string with additional information such 
-   as error reason and whether a retry is allowed. If the error reason 
-   is an expired password and a retry is allowed, the client may 
-   proceed to change the user's password. If the error reason is not an 
-   expired password or if the client does not wish to change the user's 
-   password, it issues an InnerApplicationFailure alert. 
-
-   If the client does wish to change the password, it tunnels MS-CHAP-
-   NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server. 
-   The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge 
-   received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge AVP simply 
-   echoes the new Challenge. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP2-CPW AVP match the values it sent in 
-   the MS-CHAP2-Error AVP. If either item does not match exactly, the 
-   server must reject the client. Otherwise, it validates the MS-CHAP2-
-   CPW AVP. 
-
-   If the MS-CHAP2-CPW AVP received from the client is correct, and the 
-   server is able to change the user's password, the server tunnels the 
-
-
-
-Paul Funk                 expires August 2005                 [Page 22] 
-
-Internet-Draft                                           February 2005         
-
-
-   MS-CHAP2-Success AVP to the client and the negotiation proceeds as 
-   described above. 
-
-   Note that additional AVPs associated with MS-CHAP-V2 may be sent by 
-   the server; for example, MS-CHAP-Domain. The server must tunnel such 
-   authentication-related AVPs along with the MS-CHAP2-Success. 
-
-4.2.5 PAP 
-
-   PAP RADIUS attribute formats are described in [RFC2865]. 
-
-   The client initiates PAP by including User-Name and User-Password 
-   AVPs in the first ApplicationPayload message in any application 
-   phase. 
-
-   In RADIUS, User-Password is padded with nulls to a multiple of 16 
-   octets, then encrypted using a shared secret and other packet 
-   information.  
-
-   A TLS/IA, however, does not RADIUS-encrypt the password since all 
-   application phase data is already encrypted. The client SHOULD, 
-   however, null-pad the password to a multiple of 16 octets, to 
-   obfuscate its length. 
-
-   Upon receipt of these AVPs from the client, the server may be able 
-   to decide whether to authenticate the client immediately, or it may 
-   need to challenge the client for more information. 
-
-   If the server wishes to issue a challenge to the client, it MUST 
-   tunnel the Reply-Message AVP to the client; this AVP normally 
-   contains a challenge prompt of some kind. It may also tunnel 
-   additional AVPs if necessary, such the Prompt AVP. Upon receipt of 
-   the Reply-Message AVPs, the client tunnels User-Name and User-
-   Password AVPs again, with the User-Password AVP containing new 
-   information in response to the challenge. This process continues 
-   until the server determines the authentication has succeeded or 
-   failed. 
-
-4.3  Performing Multiple Authentications 
-
-   In some cases, it is desirable to perform multiple user 
-   authentications. For example, a server may want first to 
-   authenticate the user by password, then by token card. 
-
-   The server may perform any number of additional user authentications 
-   using EAP, simply by issuing a EAP-Request with a new protocol type 
-   once the previous authentication has completed.. 
-
-   For example, a server wishing to perform MD5-Challenge followed by 
-   Generic Token Card would first issue an EAP-Request/MD5-Challenge 
-   AVP and receive a response. If the response is satisfactory, it 
-
-
-
-Paul Funk                 expires August 2005                 [Page 23] 
-
-Internet-Draft                                           February 2005         
-
-
-   would then issue EAP-Request/Generic Token Card AVP and receive a 
-   response. If that response were also satisfactory, it would consider 
-   the user authenticated. 
-
-5  Example Message Sequences 
-
-   This section presents a variety of possible TLS/IA message 
-   sequences. These examples do not attempt to exhaustively depict all 
-   possible scenarios.  
-
-   Parentheses indicate optional TLS messages. Brackets indicate 
-   optional message exchanges. Ellipsis (. . .) indicates optional 
-   repetition of preceding messages. 
-
-5.1  Full Initial Handshake with Multiple Application Phases 
-
-   The diagram below depicts a full initial handshake phase followed by 
-   two application phases. 
-
-   Note that the client concludes the intermediate phase and starts the 
-   final phase in an uninterrupted sequence of three messages: 
-   ChangeCipherSpec and PhaseFinished belong to the intermediate phase, 
-   and ApplicationPayload belongs to the final phase.  
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** TLS Handshake:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                       (Certificate) 
-                                                   ServerKeyExchange 
-                                                (CertificateRequest) 
-                                      <--------      ServerHelloDone 
-         (Certificate) 
-         ClientKeyExchange 
-         (CertificateVerify) 
-         ChangeCipherSpec 
-         Finished                     --------> 
-                                                    ChangeCipherSpec 
-                                      <--------        Finished 
-    
-   *** Intermediate Phase: 
-         ApplicationPayload           -------->  
-    
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 24] 
-
-Internet-Draft                                           February 2005         
-
-
-                                         ... 
-       ] 
-                                      <--------        
-   IntermediatePhaseFinished 
-         IntermediatePhaseFinished 
-   *** Final Phase: 
-         ApplicationPayload           -------->  
-                                          
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                      <--------   FinalPhaseFinished 
-    
-         FinalPhaseFinished           --------> 
-    
-5.2  Resumed Session with Single Application Phase 
-
-   The diagram below depicts a resumed session followed by a single 
-   application phase. 
-
-   Note that the client concludes the initial phase and starts the 
-   final phase in an uninterrupted sequence of three messages: 
-   ChangeCipherSpec and PhaseFinished belong to the initial phase, and 
-   ApplicationPayload belongs to the final phase.  
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** TLS Handshake:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                    ChangeCipherSpec 
-                                      <--------             Finished 
-         ChangeCipherSpec 
-         Finished 
-   *** Final Phase: 
-         ApplicationPayload           -------->  
-                                          
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                      <--------   FinalPhaseFinished 
-                      
-
-
-
-Paul Funk                 expires August 2005                 [Page 25] 
-
-Internet-Draft                                           February 2005         
-
-
-         FinalPhaseFinished           --------> 
-    
-5.3  Resumed Session with No Application Phase 
-
-   The diagram below depicts a resumed session without any subsequent 
-   application phase. This will occur if the client indicates in its 
-   ClientInnerApplication message that no application phase is required 
-   and the server concurs.  
-
-   Note that this message sequence is identical to that of a standard 
-   TLS resumed session. 
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** TLS Handshake:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                    ChangeCipherSpec 
-                                      <--------             Finished 
-         ChangeCipherSpec 
-         Finished                     --------> 
-    
-6  Security Considerations 
-
-   This document introduces a new TLS extension called "Inner 
-   Application". When TLS is used with the Inner Application extension 
-   (TLS/IA), additional messages are exchanged during the TLS 
-   handshake. Hence a number of security issues need to be taken into 
-   consideration. Since the security heavily depends on the information 
-   (called "applications") which are exchanged between the TLS client 
-   and the TLS server as part of the TLS/IA extension we try to 
-   classify them into two categories: The first category considers the 
-   case where the exchange results in the generation of keying 
-   material. This is, for example, the case with many EAP methods. EAP 
-   is one of the envisioned main "applications". The second category 
-   focuses on cases where no session key is generated. The security 
-   treatment of the latter category is discouraged since it is 
-   vulnerability to man-in-the-middle attacks if the two sessions 
-   cannot be bound to each other as shown in [MITM].  
-
-   Subsequently, we investigate a number of security issues:  
-
-   - Architecture and Trust Model 
-
-     For many of the use cases in this document we assume that three 
-     functional entities participate in the protocol exchange: TLS 
-     client, TLS server and a AAA infrastructure (typically consisting 
-     of a AAA server and possibly a AAA broker). The protocol exchange 
-     described in this document takes place between the TLS client and 
-     the TLS server. The interaction between the AAA client (which 
-
-
-
-Paul Funk                 expires August 2005                 [Page 26] 
-
-Internet-Draft                                           February 2005         
-
-
-     corresponds to the TLS server) and the AAA server is described in 
-     the respective AAA protocol documents and therefore outside the 
-     scope of this document. The trust model behind this architecture 
-     with respect to the authentication, authorization, session key 
-     establishment and key transport within the AAA infrastructure is 
-     discussed in [KEYING].  
-
-   - Authentication 
-
-     This document assumes that the TLS server is authenticated to the 
-     TLS client as part of the authentication procedure of the initial 
-     TLS Handshake. This approach is similar to the one chosen with 
-     the EAP support in IKEv2 (see [IKEv2]). Typically, public key 
-     based server authentication is used for this purpose. More 
-     interesting is the client authentication property whereby 
-     information exchanged as part of the Inner Application is used to 
-     authenticate (or authorize) the client. For example, if EAP is 
-     used as an inner application then EAP methods are used to perform 
-     authentication and key agreement between the EAP peer (most 
-     likely the TLS client) and the EAP server (i.e., AAA server).  
-
-   - Authorization  
-
-     Throughout this document it is assumed that the TLS server can be 
-     authorized by the TLS client as a legitimate server as part of 
-     the authentication procedure of the initial TLS Handshake. The 
-     entity acting as TLS client can be authorized either by the TLS 
-     server or by the AAA server (if the authorization decision is 
-     offloaded). Typically, the authenticated identity is used to 
-     compute the authorization decision but credential-based 
-     authorization mechanisms may be used as well. 
-
-   - Man-in-the-Middle Attack 
-
-     Man-in-the-middle attacks have become a concern with tunneled 
-     authentication protocols because of the discovered 
-     vulnerabilities (see [MITM]) of a missing cryptographic binding 
-     between the independent protocol sessions. This document also 
-     proposes a tunneling protocol, namely individual inner 
-     application sessions are tunneled within a previously executed 
-     session. The first protocol session in this exchange is the 
-     initial TLS Handshake. To avoid man-in-the-middle attacks a 
-     number of sections address how to establish such a cryptographic 
-     binding (see Section 2.3 and Error! Reference source not found.).  
-
-   - User Identity Confidentiality 
-
-     The TLS/IA extension allows splitting the authentication of the 
-     TLS server from the TLS client into two separate sessions. As one 
-     of the advantages, this provides active user identity 
-     confidentiality since the TLS client is able to authenticate the 
-
-
-
-Paul Funk                 expires August 2005                 [Page 27] 
-
-Internet-Draft                                           February 2005         
-
-
-     TLS server and to establish a unilateral authenticated and 
-     confidentiality-protected channel prior to starting the client-
-     side authentication. 
-
-   - Session Key Establishment 
-
-     TLS [RFC2246] defines how session key material produced during 
-     the TLS Handshake is generated with the help of a pseudo-random 
-     function to expand it to keying material of the desired length 
-     for later usage in the TLS Record Layer. Section 2.3 gives some 
-     guidelines with regard to the master key generation. Since the 
-     TLS/IA extension supports multiple exchanges whereby each phase 
-     concludes with a generated keying material. In addition to the 
-     keying material established as part of TLS itself, most inner 
-     applications will produce their keying material. For example, 
-     keying material established as part of an EAP method must be 
-     carried from the AAA server to the AAA client. Details are 
-     subject to the specific AAA protocol (for example, EAP usage in 
-     Diameter [AAA-EAP].  
-
-   - Denial of Service Attacks 
-
-     This document does not modify the initial TLS Handshake and as 
-     such, does not introduce new vulnerabilities with regard to DoS 
-     attacks. Since the TLS/IA extension allows to postpone the 
-     client-side authentication to a later stage in the protocol 
-     phase. As such, it allows malicious TLS clients to initiate a 
-     number of exchanges while remaining anonymous. As a consequence, 
-     state at the server is allocated and computational efforts are 
-     required at the server side. Since the TLS client cannot be 
-     stateless this is not strictly a DoS attack. 
-
-   - Confidentiality Protection and Dictionary Attack Resistance 
-
-     Similar to the user identity confidentiality property the usage 
-     of the TLS/IA extension allows to establish a unilateral 
-     authenticated tunnel which is confidentiality protected. This 
-     tunnel protects the inner application information elements to be 
-     protected against active adversaries and therefore provides 
-     resistance against dictionary attacks when password-based 
-     authentication protocols are used inside the tunnel. In general, 
-     information exchanged inside the tunnel experiences 
-     confidentiality protection.  
-
-   - Downgrading Attacks 
-
-     This document defines a new extension. The TLS client and the TLS 
-     server indicate the capability to support the TLS/IA extension as 
-     part of the client_hello_extension_list and the 
-     server_hello_extension_list payload. More details can be found in 
-     Section 2.6. To avoid downgrading attacks whereby an adversary 
-
-
-
-Paul Funk                 expires August 2005                 [Page 28] 
-
-Internet-Draft                                           February 2005         
-
-
-     removes a capability from the list is avoided by the usage of the 
-     Finish or PhaseFinished message as described in Section Error! 
-     Reference source not found.. 
-
-7  References 
-
-7.1  Normative References 
-
-   [RFC1700]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 
-               1700, October 1994. 
-
-   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication 
-               Protocol (CHAP)", RFC 1994, August 1996. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
-               Requirement Levels", RFC 2119, March 1997. 
-
-   [RFC2246]  Dierks, T., and C. Allen, "The TLS Protocol Version 
-               1.0", RFC 2246, November 1998. 
-
-   [RFC2433]  Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", 
-               RFC 2433, October 1998. 
-
-   [RFC2486]  Aboba, B., and M. Beadles, "The Network Access 
-               Identifier", RFC 2486, January 1999. 
-
-   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 
-               RFC 2548, March 1999. 
-
-   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 
-               RFC 2759, January 2000. 
-
-   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, 
-               "Remote Authentication Dial In User Service (RADIUS)", 
-               RFC 2865, June 2000. 
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 
-               J., and T. Wright, "Transport Layer Security (TLS) 
-               Extensions", RFC 3546, June 2003. 
-
-   [RFC3579]  Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication 
-               Dial In User Service) Support For Extensible 
-               Authentication Protocol (EAP)", RFC 3579, September 
-               2003. 
-
-   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 
-               Arkko, "Diameter Base Protocol", RFC 3588, July 2003. 
-
-   [RFC3784]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 
-               H. Levkowetz, "PPP Extensible Authentication Protocol 
-               (EAP)", RFC 3784, June 2004. 
-
-
-
-Paul Funk                 expires August 2005                 [Page 29] 
-
-Internet-Draft                                           February 2005         
-
-
- 
-7.2  Informative References 
-
-   [RFC1661]  Simpson, W. (Editor), "The Point-to-Point Protocol 
-               (PPP)", STD 51, RFC 1661, July 1994. 
-
-   [RFC2716]  Aboba, B., and D. Simon, "PPP EAP TLS Authentication 
-               Protocol", RFC 2716, October 1999. 
-
-   [EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS 
-               Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-
-               eap-ttls-05.txt, July 2004. 
-
-   [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 
-               and S. Josefsson, "Protected EAP Protocol (PEAP) Version 
-               2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 
-               2004. 
-
-   [TLS-PSK]  Eronen, P., and H. Tschofenig, "Pre-Shared Key 
-               Ciphersuites for Transport Layer Security (TLS)", draft-
-               ietf-tls-psk-01.txt, August 2004. 
-
-   [802.1X]   IEEE Standards for Local and Metropolitan Area Networks:  
-               Port based Network Access Control, IEEE Std 802.1X-2001, 
-               June 2001. 
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 
-               in Tunneled Authentication", 
-               http://www.saunalahti.fi/~asokan/research/mitm.html, 
-               Nokia Research Center, Finland, October 24 2002. 
-
-   [KEYING]   Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 
-               Key Management Framework", draft-ietf-eap-keying-01.txt 
-               (work in progress), October 2003. 
-
-   [IKEv2]    C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 
-               draft-ietf-ipsec-ikev2-16.txt (work in progress), 
-               September 2004. 
-
-   [AAA-EAP]  Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 
-               Authentication Protocol (EAP) Application", draft-ietf-
-               aaa-eap-03.txt (work in progress), October 2003. 
-
-8  Authors' Addresses 
-
-   Questions about this memo can be directed to: 
-
-      Paul Funk 
-      Funk Software, Inc. 
-      222 Third Street 
-      Cambridge, MA 02142 
-
-
-
-Paul Funk                 expires August 2005                 [Page 30] 
-
-Internet-Draft                                           February 2005         
-
-
-      USA 
-      Phone: +1 617 497-6339 
-      E-mail: paul@funk.com 
-
-      Simon Blake-Wilson 
-      Basic Commerce & Industries, Inc. 
-      96 Spadina Ave, Unit 606  
-      Toronto, Ontario M5V 2J6 
-      Canada 
-      Phone: +1 416 214-5961 
-      E-mail: sblakewilson@bcisse.com 
-
-      Ned Smith 
-      Intel Corporation 
-      MS: JF1-229 
-      2111 N.E. 25th Ave. 
-      Hillsboro, OR 97124 
-      USA 
-      Phone: +1 503 264-2692  
-      E-mail: ned.smith@intel.com 
-
-      Hannes Tschofenig 
-      Siemens 
-      Otto-Hahn-Ring 6 
-      Munich, Bayern  81739\ 
-      Germany 
-      Phone: +49 89 636 40390 
-      E-mail: Hannes.Tschofenig@siemens.com 
-
-      Thomas Hardjono 
-      VeriSign Inc. 
-      487 East Middlefield Road 
-      M/S MV6-2-1 
-      Mountain View, CA 94043 
-      USA 
-      Phone: +1 650 426-3204 
-      E-mail: thardjono@verisign.com 
-
-9  Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-
-
-
-Paul Funk                 expires August 2005                 [Page 31] 
-
-Internet-Draft                                           February 2005         
-
-
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The Internet Society (2001 - 2005).  This document is 
-   subject to the rights, licenses and restrictions contained in BCP 
-   78, and except as set forth therein, the authors retain all their 
-   rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Paul Funk                 expires August 2005                 [Page 32] 
-
diff --git a/doc/protocol/draft-funk-tls-inner-application-extension-02.txt b/doc/protocol/draft-funk-tls-inner-application-extension-02.txt
deleted file mode 100644
index c0b8d90e44..0000000000
--- a/doc/protocol/draft-funk-tls-inner-application-extension-02.txt
+++ /dev/null
@@ -1,1887 +0,0 @@
-
-
-
-
-
-
-TLS Working Group                                             Paul Funk 
-Internet-Draft                                         Juniper Networks 
-Category: Standards Track                            Simon Blake-Wilson 
-<draft-funk-tls-inner-application-extension-02.txt>    Basic Commerce &  
-                                                       Industries, Inc. 
-                                                              Ned Smith 
-                                                            Intel Corp. 
-                                                      Hannes Tschofenig 
-                                                             Siemens AG 
-                                                        Thomas Hardjono 
-                                                          VeriSign Inc. 
-                                                             March 2006 
-
-                                     
-
-                    TLS Inner Application Extension 
-                               (TLS/IA) 
-
-                                     
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 (2006). All Rights Reserved. 
-
-Abstract 
-
-   This document defines a new TLS extension called "Inner 
-   Application". When TLS is used with the Inner Application extension 
-
-Internet-Draft                                              March 2006         
-
-
-   (TLS/IA), additional messages are exchanged after completion of the 
-   TLS handshake, in effect providing an extended handshake prior to 
-   the start of upper layer data communications. Each TLS/IA message 
-   contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from 
-   the RADIUS/Diameter namespace. Hence, the AVPs defined in RADIUS and 
-   Diameter have the same meaning in TLS/AI; that is, each attribute 
-   code point refers to the same logical attribute in any of these 
-   protocols. Arbitrary "applications" may be implemented using the AVP 
-   exchange. Possible applications include EAP or other forms of user 
-   authentication, client integrity checking, provisioning of 
-   additional tunnels, and the like. Use of the RADIUS/Diameter 
-   namespace provides natural compatibility between TLS/IA applications 
-   and widely deployed AAA infrastructures. 
-
-   It is anticipated that TLS/IA will be used with and without 
-   subsequent protected data communication within the tunnel 
-   established by the handshake. For example, TLS/IA may be used to 
-   secure an HTTP data connection, allowing more robust password-based 
-   user authentication to occur than would otherwise be possible using 
-   mechanisms available in HTTP. TLS/IA may also be used for its 
-   handshake portion alone; for example, EAP-TTLSv1 encapsulates a 
-   TLS/IA handshake in EAP as a means to mutually authenticate a client 
-   and server and establish keys for a separate data connection. 
-
-Table of Contents 
-
-1   Introduction......................................................3 
-1.1    A Bit of History..............................................4 
-1.2    TLS With or Without Upper Layer Data Communications...........5 
-2   The Inner Application Extension to TLS............................5 
-2.1    TLS/IA Message Exchange.......................................7 
-2.2    Inner Secret..................................................9 
-2.2.1      Application Session Key Material.........................10 
-2.3    Session Resumption...........................................11 
-2.4    Error Termination............................................12 
-2.5    Negotiating the Inner Application Extension..................12 
-2.6    InnerApplication Protocol....................................12 
-2.6.1      InnerApplicationExtension................................12 
-2.6.2      InnerApplication Message.................................13 
-2.6.3      IntermediatePhaseFinished and FinalPhaseFinished Messages13 
-2.6.4      The ApplicationPayload Message...........................14 
-2.7    Alerts .......................................................14 
-3   Encapsulation of AVPs within ApplicationPayload Messages.........15 
-3.1    AVP Format...................................................15 
-3.2    AVP Sequences................................................17 
-3.3    Guidelines for Maximum Compatibility with AAA Servers........17 
-4   Tunneled Authentication within Application Phases................17 
-4.1    Implicit challenge...........................................18 
-4.2    Tunneled Authentication Protocols............................18 
-4.2.1      EAP ......................................................19 
-4.2.2      CHAP .....................................................20 
-
-
-
-Paul Funk               expires September 2006                [Page 2] 
-
-Internet-Draft                                              March 2006         
-
-
-4.2.3      MS-CHAP..................................................20 
-4.2.4      MS-CHAP-V2...............................................21 
-4.2.5      PAP ......................................................22 
-4.3    Performing Multiple Authentications..........................23 
-5   Example Message Sequences........................................23 
-5.1    Full Initial Handshake with Intermediate and Final Application 
-Phases 23 
-5.2    Resumed Session with Single Application Phase................24 
-5.3    Resumed Session with No Application Phase....................25 
-6   Security Considerations..........................................25 
-7   References.......................................................28 
-7.1    Normative References.........................................28 
-7.2    Informative References.......................................29 
-8   Authors' Addresses...............................................30 
-9   Intellectual Property Statement..................................31 
-    
-
-1  Introduction 
-
-   This specification defines the TLS "Inner Application" extension. 
-   The term "TLS/IA" refers to the TLS protocol when used with the 
-   Inner Application extension. 
-
-   In TLS/IA, the setup portion of TLS is extended to allow an 
-   arbitrary exchange of information between client and server within a 
-   protected tunnel established during the TLS handshake and prior to 
-   the start of upper layer TLS data communications. The TLS handshake 
-   itself is unchanged; the subsequent Inner Application exchange is 
-   conducted under the confidentiality and integrity protection that is 
-   afforded by the TLS handshake. 
-
-   The primary motivation for providing this facility is to allow 
-   robust user authentication to occur as part of an "extended" 
-   handshake, in particular, user authentication that is based on 
-   password credentials, which is best conducted under the protection 
-   of an encrypted tunnel to preclude dictionary attack by 
-   eavesdroppers. For example, the Extensible Authentication Protocol 
-   (EAP) may be used for authentication using any of a wide variety of 
-   methods as part of this extended handshake. The multi-layer approach 
-   of TLS/IA, in which a strong authentication, typically based on a 
-   server certificate, is used to protected a password-based 
-   authentication, distinguishes it from other TLS variants that rely 
-   entirely on a pre-shared key or password for security (such as [TLS-
-   PSK]). 
-
-   The protected exchange accommodates any type of client-server 
-   application, not just authentication, though authentication may 
-   often be the prerequisite for other applications to proceed. For 
-   example, TLS/IA may be used to set up HTTP connections, establish 
-   IPsec security associations (as an alternative to IKE), obtain 
-
-
-
-
-Paul Funk               expires September 2006                [Page 3] 
-
-Internet-Draft                                              March 2006         
-
-
-   credentials for single sign-on, provide client integrity 
-   verification, and so on. 
-
-   The new messages that are exchanged between client and server are 
-   encoded as sequences of Attribute-Value-Pairs (AVPs) from the 
-   RADIUS/Diameter namespace. Use of the RADIUS/Diameter namespace 
-   provides natural compatibility between TLS/IA applications and 
-   widely deployed AAA infrastructures. This namespace is extensible, 
-   allowing new AVPs and, thus, new applications to be defined as 
-   needed, either by standards bodies or by vendors wishing to define 
-   proprietary applications. 
-
-   The TLS/IA exchange comprises one or more "phases", each of which 
-   consists of an arbitrary number of AVP exchanges followed by a 
-   confirmation exchange. Authentications occurring in any phase must 
-   be confirmed prior to continuing to the next phase. This allows 
-   applications to implement security dependencies in which particular 
-   assurances are required prior to the exchange of additional 
-   information. 
-
-1.1  A Bit of History 
-
-   The TLS protocol has its roots in the Netscape SSL protocol, which 
-   was originally intended to protect HTTP traffic. It provides either 
-   one-way or mutual certificate-based authentication of client and 
-   server. In its most typical use in HTTP, the client authenticates 
-   the server based on the server's certificate and establishes a 
-   tunnel through which HTTP traffic is passed.  
-
-   For the server to authenticate the client within the TLS handshake, 
-   the client must have its own certificate. In cases where the client 
-   must be authenticated without a certificate, HTTP, not TLS, 
-   mechanisms would have to be employed. For example, HTTP headers have 
-   been defined to perform user authentications. However, these 
-   mechanisms are primitive compared to other mechanisms, most notably 
-   EAP, that have been defined for contexts other than HTTP. 
-   Furthermore, any mechanisms defined for HTTP cannot be utilized when 
-   TLS is used to protect non-HTTP traffic. 
-
-   The TLS protocol has also found an important use in authentication 
-   for network access, originally within PPP for dial-up access and 
-   later for wireless and wired 802.1X access. Several EAP types have 
-   been defined that utilize TLS to perform mutual client-server 
-   authentication. The first to appear, EAP-TLS, uses the TLS handshake 
-   to authenticate both client and server based on their certificates.  
-
-   Subsequently proposed protocols, such EAP-TTLSv0 and EAP-PEAP, 
-   utilize the TLS handshake to allow the client to authenticate the 
-   server based on the latter's certificate, and then use the protected 
-   channel established by the TLS handshake to perform user 
-   authentication, typically based on a password. Such protocols are 
-
-
-
-Paul Funk               expires September 2006                [Page 4] 
-
-Internet-Draft                                              March 2006         
-
-
-   called "tunneled" EAP protocols. The authentication mechanism used 
-   inside the tunnel may itself be EAP, and the tunnel may also be used 
-   to convey additional information between client and server. 
-
-   While tunneled authentication would be useful in other contexts 
-   besides EAP, the tunneled protocols mentioned above cannot be 
-   employed in a more general use of TLS, since the outermost protocol 
-   is EAP, not TLS. Furthermore, these protocols use the TLS tunnel to 
-   carry authentication exchanges, and thus preclude use of the TLS 
-   tunnel for other purposes such as carrying HTTP traffic. 
-
-   TLS/IA provides a means to perform user authentication and other 
-   message exchanges between client and server strictly within TLS. 
-   TLS/IA can thus be used both for flexible user authentication within 
-   a TLS session and as a basis for tunneled authentication within EAP.  
-
-   The TLS/IA approach is to insert an additional message exchange 
-   between the TLS handshake and the subsequent data communications 
-   phase. This message exchange is carried in a new record type, which 
-   is distinct from the record type that carries upper layer data. 
-   Thus, the data portion of the TLS exchange becomes available for 
-   HTTP or another protocol that needs to be secured. 
-
-1.2  TLS With or Without Upper Layer Data Communications 
-
-   It is anticipated that TLS/IA will be used with and without 
-   subsequent protected data communication within the tunnel 
-   established by the handshake.  
-
-   For example, TLS/IA may be used to protect an HTTP connection, 
-   allowing more robust password-based user authentication to occur 
-   within the TLS/IA extended handshake than would otherwise be 
-   possible using mechanisms available in HTTP.  
-
-   TLS/IA may also be used for its handshake portion alone. For 
-   example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP 
-   as a means to mutually authenticate a client and server and 
-   establish keys for a separate data connection; no subsequent TLS 
-   data portion is required. Another example might be the use of TLS/IA 
-   directly over TCP in order to provide a user with credentials for 
-   single sign-on. 
-
-2  The Inner Application Extension to TLS 
-
-   The Inner Application extension to TLS follows the guidelines of 
-   [RFC3546].  
-
-   A new extension type is defined for negotiating use of TLS/IA: 
-
-   -  The InnerApplicationExtension extension type. The client proposes 
-      use of this extension by including a InnerApplicationExtension 
-
-
-
-Paul Funk               expires September 2006                [Page 5] 
-
-Internet-Draft                                              March 2006         
-
-
-      message in its ClientHello handshake message, and the server 
-      confirms its use by including a InnerApplicationExtension message 
-      in its ServerHello handshake message.  
-
-   A new record type (ContentType) is defined for use in TLS/IA: 
-
-   -  The InnerApplication record type. This record type carries all 
-      messages that are exchanged after the TLS handshake and prior to 
-      exchange of data. 
-
-   A new message type is defined for use within the InnerApplication 
-   record type: 
-
-   -  The InnerApplication message. This message may encapsulate any of 
-      the three following subtypes: 
-
-       -  The ApplicationPayload message. This message is used to carry 
-         AVP (Attribute-Value Pair) sequences within the TLS/IA 
-         extended handshake, in support of client-server applications 
-         such as authentication. 
-
-       -  The IntermediatePhaseFinished message. This message confirms 
-         session keys established during the current TLS/IA phase, and 
-         indicates that at least one additional phase is to follow. 
-
-       -  The FinalPhaseFinished message. This message confirms session 
-         keys established during the current TLS/IA phase, and 
-         indicates that no further phases are to follow. 
-
-   Two new alert codes are defined for use in TLS/IA: 
-
-   -  The InnerApplicationFailure alert. This error alert allows either 
-      party to terminate the TLS/IA extended handshake due to a failure 
-      in an application implemented via AVP sequences carried in 
-      ApplicationPayload messages. 
-
-   -  The InnerApplicationVerification alert. This error alert allows 
-      either party to terminate the TLS/IA extended handshake due to 
-      incorrect verification data in a received 
-      IntermediatePhaseFinished or FinalPhaseFinished message. 
-
-   The following new assigned numbers are used in TLS/IA: 
-
-   -  "InnerApplicationExtension" extension type:      37703 
-
-   -  "InnerApplication" record type:                 24 
-
-   -  "InnerApplicationFailure" alert code:           208 
-
-   -  "InnerApplicationVerification" alert code:      209 
-
-
-
-
-Paul Funk               expires September 2006                [Page 6] 
-
-Internet-Draft                                              March 2006         
-
-
-   [Editor's note: I have not checked these types yet against types 
-   defined in RFCs or drafts. The TLS RFC specifies that new record 
-   types use the next number after ones already defined; hence I used 
-   24, though I don't know if that is already taken.] 
-
-2.1  TLS/IA Message Exchange 
-
-   In TLS/IA, zero or more "application phases are inserted after the 
-   TLS handshake and prior to ordinary data exchange. The last such 
-   application phase is called the "final phase"; any application 
-   phases prior to the final phase are called "intermediate phases". 
-
-   Intermediate phases are only necessary if interim confirmation of 
-   session keys generated during an application phase is desired.  
-
-   Each application phase consists of ApplicationPayload handshake 
-   messages exchanged by client and server to implement applications 
-   such as authentication, plus concluding messages for cryptographic 
-   confirmation. These messages are encapsulated in records with 
-   ContentType of InnerApplication. 
-
-   All application phases prior to the final phase conclude with an 
-   exchange of  IntermediatePhaseFinished messages, or conclude with a 
-   FinalPhaseFinished message from the server and an 
-   IntermediatePhaseFinished message from the client, by which the 
-   client indicates its desire to keep the handshake open for one or 
-   more additional phases. The final phase concludes with an exchange 
-   of FinalPhaseFinished messages.  
-
-   Application phases may be omitted entirely only when session 
-   resumption is used, provided both client and server agree that no 
-   application phase is required. The client indicates in its 
-   ClientHello whether it is willing to omit application phases in a 
-   resumed session, and the server indicates in its ServerHello whether 
-   any application phases are to ensue. 
-
-   In each application phase, the client sends the first 
-   ApplicationPayload message. ApplicationPayload messages are traded 
-   one at a time between client and server, until the server concludes 
-   the phase by sending, in response to an ApplicationPayload message 
-   from the client, an IntermediatePhaseFinished or FinalPhaseFinished 
-   sequence to conclude the phase. The client then responds with its 
-   own IntermediatePhaseFinished or FinalPhaseFinished message.  
-
-   The server determines which type of concluding message it wants to 
-   use, either IntermediatePhaseFinished or FinalPhaseFinished. If the 
-   server sent an IntermediatePhaseFinished, the client MUST respond 
-   with an IntermediatePhaseFinished. If the server sent a 
-   FinalPhaseFinished, the client MAY respond with a FinalPhaseFinished 
-   to complete the handshake, or MAY respond with an 
-   IntermediatePhaseFinished to cause the handshake to continue. Thus, 
-
-
-
-Paul Funk               expires September 2006                [Page 7] 
-
-Internet-Draft                                              March 2006         
-
-
-   conclusion of the entire handshake occurs only when both client and 
-   server have been satisfied. 
-
-   Note that the server MUST NOT send an IntermediatePhaseFinished or 
-   FinalPhaseFinished message immediately after sending an 
-   ApplicationPayload message. It must allow the client to send an 
-   ApplicationPayload message prior to concluding the phase. Thus, 
-   within any application phase, there will be one more 
-   ApplicationPayload message sent by the client than sent by the 
-   server. 
-
-   At the start of each application phase, the server MUST wait for the 
-   client's opening ApplicationPayload message before it sends its own 
-   ApplicationPayload message to the client. The client MUST NOT 
-   initiate conclusion of an application phase by sending the first 
-   IntermediatePhaseFinished or FinalPhaseFinished message; it MUST 
-   allow the server to initiate the conclusion of the phase. 
-
-   Each IntermediatePhaseFinished or FinalPhaseFinished message 
-   provides cryptographic confirmation of any session keys generated 
-   during the current and any prior applications phases. 
-
-   Each ApplicationPayload message contains opaque data interpreted as 
-   an AVP (Attribute-Value Pair) sequence. Each AVP in the sequence 
-   contains a typed data element. The exchanged AVPs allow client and 
-   server to implement "applications" within a secure tunnel. An 
-   application may be any procedure that someone may usefully define. A 
-   typical application might be authentication; for example, the server 
-   may authenticate the client based on password credentials using EAP. 
-   Other possible applications include distribution of keys, validating 
-   client integrity, setting up IPsec parameters, setting up SSL VPNs, 
-   and so on. 
-
-   Note that it is perfectly acceptable for either client or server to 
-   send an ApplicationPayload message containing no AVPs. The client, 
-   for example, may have no AVPs to send in its first or last 
-   ApplicationPayload message during an application phase.  
-
-   An "inner secret" is computed during each application phase that 
-   cryptographically combines the TLS master secret with any session 
-   keys that have been generated during the current and any previous 
-   application phases. At the conclusion of each application phase, a 
-   new inner secret is computed and is used to create verification data 
-   that is exchanged via the IntermediatePhaseFinished or 
-   FinalPhaseFinished messages. By mixing session keys of inner 
-   authentications with the TLS master secret, certain man-in-the-
-   middle attacks are thwarted [MITM]. 
-
-
-
-
-
-
-
-Paul Funk               expires September 2006                [Page 8] 
-
-Internet-Draft                                              March 2006         
-
-
-2.2  Inner Secret  
-
-   The inner secret is a 48-octet value used to confirm that the 
-   endpoints of the TLS handshake are the same entities as the 
-   endpoints of the inner authentications that may have been performed 
-   during each application phase. 
-
-   The inner secret is initialized to the master secret at the 
-   conclusion of the TLS handshake. At the conclusion of each 
-   application phase, prior to computing verification data for 
-   inclusion in the IntermediatePhaseFinished or FinalPhaseFinished 
-   message, each party permutes the inner secret using a PRF that 
-   includes session keys produced during the current application phase. 
-   The value that results replaces the current inner secret and is used 
-   to compute the verification data. 
-
-      inner_secret = PRF(inner_secret,  
-                         "inner secret permutation",  
-                         SecurityParameters.server_random + 
-                         SecurityParameters.client_random +  
-                          session_key_material) [0..48]; 
-
-   session_key_material is the concatenation of session_key vectors, 
-   one for each session key generated during the current phase, where: 
-
-      opaque session_key<1..2^16-1>; 
-
-   In other words, each session key is prefixed by a 2-octet length to 
-   produce the session_key vector. 
-
-   Since multiple session keys may be produced during a single 
-   application phase, the following method is used to determine the 
-   order of concatenation: Each session key is treated as an unsigned 
-   big-endian numeric value, and the set of session keys is ordered 
-   from lowest to highest. The session keys are then converted to 
-   session_key vectors and concatenated in the determined order to form 
-   session_key_material. 
-
-   If no session keys were generated during the current phase, 
-   session_key_material will be null. 
-
-   Note that session_key_material itself is not a vector and therefore 
-   not prefixed with the length of the entire collection of session_key 
-   vectors. 
-
-   Note that, within TLS itself, the inner secret is used for 
-   verification only, not for encryption. However, the inner secret 
-   resulting from the final application phase may be exported for use 
-   as a key from which additional session keys may be derived for 
-   arbitrary purposes, including encryption of data communications 
-   separate from TLS. 
-
-
-
-Paul Funk               expires September 2006                [Page 9] 
-
-Internet-Draft                                              March 2006         
-
-
-   An exported inner secret should not be used directly for any 
-   cryptographic purpose. Instead, additional keys should be derived 
-   from the inner secret, for example by using a PRF. This ensures 
-   cryptographic separation between use of the inner secret for session 
-   key confirmation and additional use of the inner secret outside 
-   TLS/IA. 
-
-2.2.1 Application Session Key Material 
-
-   Many authentication protocols used today generate session keys that 
-   are bound to the authentication. Such keying material is normally 
-   intended for use in a subsequent data connection for encryption and 
-   validation. For example, EAP-TLS, MS-CHAP-V2, and EAP-MS-CHAP-V2 
-   generate session keys. 
-
-   Any session keys generated during an application phase MUST be used 
-   to permute the TLS/IA inner secret between one phase and the next, 
-   and MUST NOT be used for any other purpose.  
-
-   Each authentication protocol may define how the session key it 
-   generates is mapped to an octet sequence of some length for the 
-   purpose of TLS/IA mixing. However, for protocols which do not 
-   specify this (including the multitude of protocols that pre-date 
-   TLS/IA) the following rules are defined. The first rule that applies 
-   SHALL be the method for determining the session key. 
-
-   -  If the authentication protocol produces an MSK (as defined in 
-      [RFC3784]), the MSK is used as the session key.  Note that an MSK 
-      is 64 octets. 
-
-   -  If the authentication protocol maps its keying material to the 
-      RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key 
-      [RFC2548], then the keying material for those attributes are 
-      concatenated, with MS-MPPE-Recv-Key first  (Note that this rule 
-      applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.) 
-
-   -  If the authentication protocol uses a pseudo-random function to 
-      generate keying material, that function is used to generate 64 
-      octets for use as keying material. 
-
-   Providing verification of the binding of session keys to the TLS 
-   master secret is necessary to preclude man-in-the-middle attacks 
-   against tunneled authentication protocols, as described in [MITM]. 
-   In such an attack, an unsuspecting client is induced to perform an 
-   untunneled authentication with an attacker posing as a server; the 
-   attacker then introduces the authentication protocol into a tunneled 
-   authentication protocol, fooling an authentic server into believing 
-   that the attacker is the authentic user. 
-
-   By mixing both the TLS master secret and session keys generated 
-   during application phase authentication into the inner secret used 
-
-
-
-Paul Funk               expires September 2006               [Page 10] 
-
-Internet-Draft                                              March 2006         
-
-
-   for application phase verification, such attacks are thwarted, as it 
-   guarantees that the same client acted as the endpoint for both the 
-   TLS handshake and the application phase authentication. Note that 
-   the session keys generated during authentication must be 
-   cryptographically bound to the authentication and not derivable from 
-   data exchanged during authentication in order for the keying 
-   material to be useful in thwarting such attacks. 
-
-   In addition, the fact that the inner secret cryptographically 
-   incorporates session keys from application phase authentications 
-   provides additional protection when the inner secret is exported for 
-   the purpose of generating additional keys for use outside of the TLS 
-   exchange. If such an exported secret did not include keying material 
-   from inner authentications, an eavesdropper who somehow knew the 
-   server's private key could, in an RSA-based handshake, determine the 
-   exported secret and hence would be able to compute the additional 
-   keys that are based on it. When inner authentication keying 
-   material, unknown to the attacker, is incorporated into the exported 
-   secret, such an attack becomes infeasible. 
-
-2.3  Session Resumption 
-
-   A TLS/IA initial handshake phase may be resumed using standard 
-   mechanisms defined in [RFC2246]. When the TLS session is resumed, 
-   client and server may not deem it necessary to exchange AVPs in one 
-   or more additional application phases, as the resumption itself may 
-   provide the necessary security. 
-
-   The client indicates within the InnerApplicationExtension message in 
-   ClientHello whether it requires AVP exchange when session resumption 
-   occurs. If it indicates that it does not, then the server may at its 
-   option omit application phases and the two parties proceed to upper 
-   layer data communications immediately upon completion of the TLS 
-   handshake. The server indicates whether application phases are to 
-   follow the TLS handshake in its InnerApplication extension message 
-   in ServerHello. 
-
-   Note that [RFC3546] specifically states that when session resumption 
-   is used, the server MUST ignore any extensions in the ClientHello. 
-   However, it is not possible to comply with this requirement for the 
-   Inner Application extension, since even in a resumed session it may 
-   be necessary to include application phases, and whether they must be 
-   included is negotiated in the extension message itself. Therefore, 
-   the [RFC3546] provision is explicitly overridden for the single case 
-   of the Inner Application extension, which is considered an exception 
-   to this rule.  
-
-   A TLS/IA session MAY NOT be resumed if an application phase resulted 
-   in failure, even though the TLS handshake itself succeeded. Both 
-   client and server MUST NOT save session state for possible future 
-
-
-
-
-Paul Funk               expires September 2006               [Page 11] 
-
-Internet-Draft                                              March 2006         
-
-
-   resumption unless the TLS handshake and all subsequent application 
-   phases have been successfully executed. 
-
-2.4  Error Termination 
-
-   The TLS/IA handshake may be terminated by either party sending a 
-   fatal alert, following standard TLS procedures.  
-
-2.5  Negotiating the Inner Application Extension 
-
-   Use of the InnerApplication extension follows [RFC3546]. The client 
-   proposes use of this extension by including the 
-   InnerApplicationExtension message in the client_hello_extension_list 
-   of the extended ClientHello. If this message is included in the 
-   ClientHello, the server MAY accept the proposal by including the 
-   InnerApplicationExtension message in the server_hello_extension_list 
-   of the extended ServerHello. If use of this extension is either not 
-   proposed by the client or not confirmed by the server, the 
-   InnerApplication record type MUST NOT be used. 
-
-2.6  InnerApplication Protocol 
-
-   All specifications of TLS/IA messages follow the usage defined in 
-   [RFC2246]. 
-
-2.6.1 InnerApplicationExtension 
-
-      enum { 
-         no(0), yes(1), (255) 
-      } AppPhaseOnResumption; 
-
-      struct { 
-         AppPhaseOnResumption app_phase_on_resumption; 
-      } InnerApplicationExtension; 
-
-   If the client wishes to propose use of the Inner Application 
-   extension, it must include the InnerApplicationExtension message in 
-   the extension_data vector in the Extension structure in its extended 
-   ClientHello message. 
-
-   If the server wishes to confirm use of the Inner Application 
-   extension that has been proposed by the client, it must include the 
-   InnerApplicationExtension message in the extension_data vector in 
-   the Extension structure in its extended ServerHello message. 
-
-   The AppPhaseOnResumption enumeration allow client and server to 
-   negotiate an abbreviated, single-phase handshake when session 
-   resumption is employed. If the client sets app_phase_on_resumption 
-   to "no", and if the server resumes the previous session, then the 
-   server MAY set app_phase_on_resumption to "no" in the 
-   InnerApplication message it sends to the client. If the server sets 
-
-
-
-Paul Funk               expires September 2006               [Page 12] 
-
-Internet-Draft                                              March 2006         
-
-
-   app_phase_on_resumption to "no", no application phases occur and the 
-   TLS connection proceeds to upper layer data exchange immediately 
-   upon conclusion of the TLS handshake. 
-
-   The server MUST set app_phase_on_resumption to "yes" if the client 
-   set app_phase_on_resumption to "yes" or if the server does not 
-   resume the session. The server MAY set app_phase_on_resumption to 
-   "yes" for a resumed session even if the client set 
-   app_phase_on_resumption to "no", as the server may have reason to 
-   proceed with one or more application phases. 
-
-   If the server sets app_phase_on_resumption to "yes" for a resumed 
-   session, then the client MUST initiate an application phase at the 
-   conclusion of the TLS handshake. 
-
-   The value of app_phase_on_resumption applies to the current 
-   handshake only; that is, it is possible for app_phase_on_resumption 
-   to have different values in two handshakes that are both resumed 
-   from the same original TLS session. 
-
-2.6.2 InnerApplication Message 
-
-      enum { 
-         application_payload(0), intermediate_phase_finished(1), 
-         final_phase_finished(2), (255) 
-      } InnerApplicationType; 
-
-      struct { 
-         InnerApplicationType msg_type; 
-         uint24 length; 
-         select (InnerApplicationType) { 
-            case application_payload:       ApplicationPayload; 
-            case intermediate_phase_finished:
-         IntermediatePhaseFinished; 
-            case final_phase_finished:      FinalPhaseFinished; 
-            } body; 
-         } InnerApplication; 
-
-   The InnerApplication message carries any of the message types 
-   defined for the InnerApplication protocol. 
-
-2.6.3 IntermediatePhaseFinished and FinalPhaseFinished Messages 
-
-      struct { 
-         opaque verify_data[12]; 
-      } PhaseFinished; 
-
-      PhaseFinished IntermediatePhaseFinished; 
-
-      PhaseFinished FinalPhaseFinished; 
-
-
-
-
-Paul Funk               expires September 2006               [Page 13] 
-
-Internet-Draft                                              March 2006         
-
-
-      verify_data 
-         PRF(inner_secret, finished_label) [0..11]; 
-
-      finished_label 
-         when sent by the client, the string "client phase finished" 
-         when sent by the server, the string "server phase finished" 
-
-   The IntermediatePhaseFinished and FinalPhaseFinished messages have 
-   the same structure and include verification data based on the 
-   current inner secret. IntermediatePhaseFinished is sent by the 
-   server and echoed by the client to conclude an intermediate 
-   application phase, and FinalPhaseFinished is used in the same manner 
-   to conclude the final application phase. 
-
-2.6.4 The ApplicationPayload Message 
-
-   The ApplicationPayload message carries an AVP sequence during an 
-   application handshake phase. It is defined as follows: 
-
-      struct { 
-         opaque avps[InnerApplication.length]; 
-      } ApplicationPayload; 
-
-      avps 
-         The AVP sequence, treated as an opaque sequence of octets. 
-
-      InnerApplication.length 
-         The length field in the encapsulating InnerApplication 
-      message. 
-
-   Note that the "avps" element has its length defined in square 
-   bracket rather than angle bracket notation, implying a fixed rather 
-   than variable length vector. This avoids having the length of the 
-   AVP sequence specified redundantly both in the encapsulating 
-   InnerApplication message and as a length prefix in the avps element 
-   itself. 
-
-2.7  Alerts 
-
-   Two new alert codes are defined for use during an application phase. 
-   The AlertLevel for either of these alert codes MUST be set to 
-   "fatal". 
-
-   InnerApplicationFailure  
-      An InnerApplicationFailure error alert may be sent by either 
-      party during an application phase. This indicates that the 
-      sending party considers the negotiation to have failed due to an 
-      application carried in the AVP sequences, for example, a failed 
-      authentication. 
-
-
-
-
-
-Paul Funk               expires September 2006               [Page 14] 
-
-Internet-Draft                                              March 2006         
-
-
-   InnerApplicationVerification  
-      An InnerApplicationVerification error alert is sent by either 
-      party during an application phase to indicate that the received 
-      IntermediatePhaseFinished or FinalPhaseFinished is invalid. 
-
-   Note that other alerts are possible during an application phase; for 
-   example, decrypt_error. The InnerApplicationFailure alert relates 
-   specifically to the failure of an application implemented via AVP 
-   sequences; for example, failure of an EAP or other authentication 
-   method, or information passed within the AVP sequence that is found 
-   unsatisfactory. 
-
-3  Encapsulation of AVPs within ApplicationPayload Messages 
-
-   During application phases of the TLS handshake, information is 
-   exchanged between client and server through the use of attribute-
-   value pairs (AVPs). This data is encrypted using the current cipher 
-   state. 
-
-   The AVP format chosen for TLS/IA is compatible with the Diameter AVP 
-   format. This does not in any way represent a requirement that 
-   Diameter be supported by any of the devices or servers participating 
-   in the TLS/IA conversation, whether directly as client or server or 
-   indirectly as a backend authenticator. Use of this format is merely 
-   a convenience. Diameter is a superset of RADIUS and includes the 
-   RADIUS attribute namespace by definition, though it does not limit 
-   the size of an AVP as does RADIUS. RADIUS, in turn, is a widely 
-   deployed AAA protocol and attribute definitions exist for the 
-   encapsulation of EAP as well as all commonly used non-EAP password 
-   authentication protocols. 
-
-   Thus, Diameter is not considered normative except as specified in 
-   this document. Specifically, the AVP Codes used in TLS/IA are 
-   semantically equivalent to those defined for Diameter, and, by 
-   extension, RADIUS.  
-
-   Use of the RADIUS/Diameter namespace allows a TLS/IA server to 
-   translate between AVPs it uses to communicate with clients and the 
-   protocol requirements of AAA servers that are widely deployed. 
-   Additionally, it provides a well-understood mechanism to allow 
-   vendors to extend that namespace for their particular requirements. 
-
-3.1  AVP Format 
-
-   The format of an AVP is shown below. All items are in network, or 
-   big-endian, order; that is, they have most significant octet first. 
-
-
-
-
-
-
-
-
-Paul Funk               expires September 2006               [Page 15] 
-
-Internet-Draft                                              March 2006         
-
-
-    0                   1                   2                   3 
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |                           AVP Code                            | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |V M r r r r r r|                  AVP Length                   | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |                        Vendor-ID (opt)                        | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |    Data ... 
-   +-+-+-+-+-+-+-+-+ 
-
-   AVP Code 
-
-      The AVP Code is four octets and, combined with the Vendor-ID 
-      field if present, identifies the attribute uniquely. The first 
-      256 AVP numbers represent attributes defined in RADIUS. AVP 
-      numbers 256 and above are defined in Diameter. 
-
-   AVP Flags 
-
-      The AVP Flags field is one octet, and provides the receiver with 
-      information necessary to interpret the AVP.  
-
-      The 'V' (Vendor-Specific) bit indicates whether the optional 
-      Vendor-ID field is present. When set to 1, the Vendor-ID field is 
-      present and the AVP Code is interpreted according to the 
-      namespace defined by the vendor indicated in the Vendor-ID field. 
-
-      The 'M' (Mandatory) bit indicates whether support of the AVP is 
-      required. When set to 0, this indicates that the AVP may be 
-      safely ignored if the receiving party does not understand or 
-      support it. When set to 1, if the receiving party does not 
-      understand or support the AVP it MUST fail the negotiation by 
-      sending an InnerApplicationFailure error alert. 
-
-      The 'r' (reserved) bits are unused and must be set to 0. 
-
-   AVP Length 
-
-      The AVP Length field is three octets, and indicates the length of 
-      this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID 
-      (if present) and Data. 
-
-   Vendor-ID 
-
-      The Vendor-ID field is present if and only if the 'V' bit is set 
-      in the AVP Flags field. It is four octets, and contains the 
-      vendor's IANA-assigned "SMI Network Management Private Enterprise 
-      Codes" [RFC1700] value. Vendors defining their own AVPs must 
-
-
-
-
-Paul Funk               expires September 2006               [Page 16] 
-
-Internet-Draft                                              March 2006         
-
-
-      maintain a consistent namespace for use of those AVPs within 
-      RADIUS, Diameter and TLS/IA. 
-
-      A Vendor-ID value of zero is semantically equivalent to absence 
-      of the Vendor-ID field altogether. 
-
-3.2  AVP Sequences 
-
-   Data encapsulated within the TLS Record Layer must consist entirely 
-   of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet 
-   boundary relative to the first AVP in the sequence. If an AVP is not 
-   a multiple of 4 octets, it must be padded with 0s to the next 4-
-   octet boundary. 
-
-   Note that the AVP Length does not include the padding. 
-
-3.3  Guidelines for Maximum Compatibility with AAA Servers 
-
-   When maximum compatibility with AAA servers is desired, the 
-   following guidelines for AVP usage are suggested: 
-
-   -  Non-vendor-specific AVPs should be selected from the set of 
-      attributes defined for RADIUS; that is, attributes with codes 
-      less than 256. This provides compatibility with both RADIUS and 
-      Diameter. 
-
-   -  Vendor-specific AVPs should be defined in terms of RADIUS. 
-      Vendor-specific RADIUS attributes translate to Diameter 
-      automatically; the reverse is not true. RADIUS vendor-specific 
-      attributes use RADIUS attribute 26 and include vendor ID, vendor-
-      specific attribute code and length; see [RFC2865] for details. 
-
-4  Tunneled Authentication within Application Phases 
-
-   TLS/IA permits user authentication information to be tunneled within 
-   an application phase between client and server, protecting the 
-   authentication information against active and passive attack.  
-
-   Any type of authentication method may be tunneled. Also, multiple 
-   tunneled authentications may be performed. Normally, tunneled 
-   authentication is used when the TLS handshake provides only one-way 
-   authentication of the server to the client; however, in certain 
-   cases it may be desirable to perform certificate authentication of 
-   the client during the initial handshake phase as well as tunneled 
-   user authentication in a subsequent application phase. 
-
-   This section establishes rules for using well known authentication 
-   mechanisms within TLS/IA. Any new authentication mechanism should, 
-   in general, be covered by these rules if it is defined as an EAP 
-   type. Authentication mechanisms whose use within TLS/IA is not 
-   covered within this specification may require separate 
-
-
-
-Paul Funk               expires September 2006               [Page 17] 
-
-Internet-Draft                                              March 2006         
-
-
-   standardization, preferably within the standard that describes the 
-   authentication mechanism in question. 
-
-4.1  Implicit challenge 
-
-   Certain authentication protocols that use a challenge/response 
-   mechanism rely on challenge material that is not generated by the 
-   authentication server, and therefore require special handling. 
-
-   In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the 
-   Network Access Server (NAS) issues a challenge to the client, the 
-   client then hashes the challenge with the password and forwards the 
-   response to the NAS. The NAS then forwards both challenge and 
-   response to a AAA server. But because the AAA server did not itself 
-   generate the challenge, such protocols are susceptible to replay 
-   attack.  
-
-   Since within TLS/IA the client also plays the role of NAS, the 
-   replay problem is exacerbated. If the client were able to create 
-   both challenge and response, anyone able to observe a CHAP or MS-
-   CHAP exchange could pose as that user by replaying that challenge 
-   and response into a TLS/IA conversation.  
-
-   To make these protocols secure in TLS/IA, it is necessary to provide 
-   a mechanism that produces a challenge that the client cannot control 
-   or predict.  
-
-   When a challenge-based authentication mechanism is used, both client 
-   and server use the TLS PRF function to generate as many octets as 
-   are required for the challenge, using the constant string "inner 
-   application challenge", based on the master secret and random values 
-   established during the TLS handshake, as follows. 
-
-      IA_challenge = PRF(SecurityParameters.master_secret, 
-                             "inner application challenge", 
-                             SecurityParameters.server_random + 
-                             SecurityParameters.client_random); 
-
-4.2  Tunneled Authentication Protocols 
-
-   This section describes the rules for tunneling specific 
-   authentication protocols within TLS/IA.  
-
-   For each protocol, the RADIUS RFC that defines the relevant 
-   attribute formats is cited. Note that these attributes are 
-   encapsulated as described in section 3.1; that is, as Diameter 
-   attributes, not as RADIUS attributes. In other words, the AVP Code, 
-   Length, Flags and optional Vendor-ID are formatted as described in 
-   section 3.1, while the Data is formatted as described by the cited 
-   RADIUS RFC. 
-
-
-
-
-Paul Funk               expires September 2006               [Page 18] 
-
-Internet-Draft                                              March 2006         
-
-
-   All tunneled authentication protocols except EAP must be initiated 
-   by the client in the first ApplicationPayload message of an 
-   application phase. EAP may be initiated by the client in the first 
-   ApplicationPayload message of an application phase; it may also be 
-   initiated by the server in any ApplicationPayload message. 
-
-   The authentication protocols described below may be performed 
-   directly by the TLS/IA server or may be forwarded to a backend AAA 
-   server. For authentication protocols that generate session keys, the 
-   backend server must return those session keys to the TLS/IA server 
-   in order to allow the protocol to succeed within TLS/IA. RADIUS or 
-   Diameter servers are suitable backend AAA servers for this purpose. 
-   RADIUS servers typically return session keys in MS-MPPE-Recv-Key and 
-   MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return 
-   session keys in the EAP-Master-Session-Key AVP [AAA-EAP]. 
-
-4.2.1 EAP 
-
-   EAP is described in [RFC3784]; RADIUS attribute formats are 
-   described in [RFC3579]. 
-
-   When EAP is the tunneled authentication protocol, each tunneled EAP 
-   packet between the client and server is encapsulated in an EAP-
-   Message AVP. 
-
-   Either the client or the server may initiate EAP.  
-
-   The client is the first to transmit within any application phase, 
-   and it may include an EAP-Response/Identity AVP in its 
-   ApplicationPayload message to begin an EAP conversation. 
-   Alternatively, if the client does not initiate EAP the server may, 
-   by including an EAP-Request/Identity AVP in its ApplicationPayload 
-   message. 
-
-   The client's EAP-Response/Identity provides the username, which MUST 
-   be a Network Access Identifier (NAI) [RFC2486]; that is, it MUST be 
-   in the following format: 
-
-      username@realm 
-
-   The @realm portion is optional, and is used to allow the server to 
-   forward the EAP message sequence to the appropriate server in the 
-   AAA infrastructure when necessary.  
-
-   The EAP authentication between client and server proceeds normally, 
-   as described in [RFC3784]. However, upon completion the server does 
-   not send an EAP-Success or EAP-Failure AVP. Instead, the server 
-   signals success when it concludes the application phase by issuing a 
-   Finished or PhaseFinished message, or it signals failure by issuing 
-   an InnerApplicationFailure alert. 
-
-
-
-
-Paul Funk               expires September 2006               [Page 19] 
-
-Internet-Draft                                              March 2006         
-
-
-   Note that the client may also issue an InnerApplicationFailure 
-   alert, for example, when authentication of the server fails in a 
-   method providing mutual authentication. 
-
-4.2.2 CHAP 
-
-   The CHAP algorithm is described in [RFC1994]; RADIUS attribute 
-   formats are described in [RFC2865]. 
-
-   Both client and server generate 17 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      CHAP-Challenge    [16 octets] 
-      CHAP Identifier   [1 octet] 
-
-   The client initiates CHAP by including User-Name, CHAP-Challenge and 
-   CHAP-Password AVPs in the first ApplicationPayload message in any 
-   application phase. The CHAP-Challenge value is taken from the 
-   challenge material. The CHAP-Password consists of CHAP Identifier, 
-   taken from the challenge material; and CHAP response, computed 
-   according to the CHAP algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the CHAP-Challenge AVP and the value of the CHAP 
-   Identifier in the CHAP-Password AVP are equal to the values 
-   generated as challenge material. If either item does not match, the 
-   server must reject the client. Otherwise, it validates the CHAP-
-   Challenge to determine the result of the authentication. 
-
-4.2.3 MS-CHAP 
-
-   The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute 
-   formats are described in [RFC2548]. 
-
-   Both client and server generate 9 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      MS-CHAP-Challenge [8 octets] 
-      Ident              [1 octet] 
-
-   The client initiates MS-CHAP by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload 
-   message in any application phase. The MS-CHAP-Challenge value is 
-   taken from the challenge material. The MS-CHAP-Response consists of 
-   Ident, taken from the challenge material; Flags, set according the 
-   client preferences; and LM-Response and NT-Response, computed 
-   according to the MS-CHAP algorithm. 
-
-
-
-
-
-Paul Funk               expires September 2006               [Page 20] 
-
-Internet-Draft                                              March 2006         
-
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP-Response AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the MS-CHAP-Challenge to determine the result of the authentication.  
-
-4.2.4 MS-CHAP-V2 
-
-   The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute 
-   formats are described in [RFC2548]. 
-
-   Both client and server generate 17 octets of challenge material, 
-   using the constant string "inner application challenge" as described 
-   above. These octets are used as follows: 
-
-      MS-CHAP-Challenge [16 octets] 
-      Ident              [1 octet] 
-
-   The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload 
-   message in any application phase. The MS-CHAP-Challenge value is 
-   taken from the challenge material. The MS-CHAP2-Response consists of 
-   Ident, taken from the challenge material; Flags, set to 0; Peer-
-   Challenge, set to a random value; and Response, computed according 
-   to the MS-CHAP-V2 algorithm. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP2-Response AVP are equal to the values 
-   generated as challenge material. If either item does not match 
-   exactly, the server must reject the client. Otherwise, it validates 
-   the MS-CHAP2-Challenge. 
-
-   If the MS-CHAP2-Challenge received from the client is correct, the 
-   server tunnels the MS-CHAP2-Success AVP to the client. 
-
-   Upon receipt of the MS-CHAP2-Success AVP, the client is able to 
-   authenticate the server. In its next InnerApplicationPayload message 
-   to the server, the client does not include any MS-CHAP-V2 AVPs. 
-   (This may result in an empty InnerApplicationPayload if no other 
-   AVPs need to be sent.) 
-
-   If the MS-CHAP2-Challenge received from the client is not correct, 
-   the server tunnels an MS-CHAP2-Error AVP to the client. This AVP 
-   contains a new Ident and a string with additional information such 
-   as error reason and whether a retry is allowed. If the error reason 
-   is an expired password and a retry is allowed, the client may 
-   proceed to change the user's password. If the error reason is not an 
-   expired password or if the client does not wish to change the user's 
-   password, it issues an InnerApplicationFailure alert. 
-
-
-
-Paul Funk               expires September 2006               [Page 21] 
-
-Internet-Draft                                              March 2006         
-
-
-   If the client does wish to change the password, it tunnels MS-CHAP-
-   NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server. 
-   The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge 
-   received in the MS-CHAP2-Error AVP. The MS-CHAP-Challenge AVP simply 
-   echoes the new Challenge. 
-
-   Upon receipt of these AVPs from the client, the server must verify 
-   that the value of the MS-CHAP-Challenge AVP and the value of the 
-   Ident in the client's MS-CHAP2-CPW AVP match the values it sent in 
-   the MS-CHAP2-Error AVP. If either item does not match exactly, the 
-   server must reject the client. Otherwise, it validates the MS-CHAP2-
-   CPW AVP. 
-
-   If the MS-CHAP2-CPW AVP received from the client is correct, and the 
-   server is able to change the user's password, the server tunnels the 
-   MS-CHAP2-Success AVP to the client and the negotiation proceeds as 
-   described above. 
-
-   Note that additional AVPs associated with MS-CHAP-V2 may be sent by 
-   the server; for example, MS-CHAP-Domain. The server must tunnel such 
-   authentication-related AVPs along with the MS-CHAP2-Success. 
-
-4.2.5 PAP 
-
-   PAP RADIUS attribute formats are described in [RFC2865]. 
-
-   The client initiates PAP by including User-Name and User-Password 
-   AVPs in the first ApplicationPayload message in any application 
-   phase. 
-
-   In RADIUS, User-Password is padded with nulls to a multiple of 16 
-   octets, then encrypted using a shared secret and other packet 
-   information.  
-
-   A TLS/IA, however, does not RADIUS-encrypt the password since all 
-   application phase data is already encrypted. The client SHOULD, 
-   however, null-pad the password to a multiple of 16 octets, to 
-   obfuscate its length. 
-
-   Upon receipt of these AVPs from the client, the server may be able 
-   to decide whether to authenticate the client immediately, or it may 
-   need to challenge the client for more information. 
-
-   If the server wishes to issue a challenge to the client, it MUST 
-   tunnel the Reply-Message AVP to the client; this AVP normally 
-   contains a challenge prompt of some kind. It may also tunnel 
-   additional AVPs if necessary, such the Prompt AVP. Upon receipt of 
-   the Reply-Message AVPs, the client tunnels User-Name and User-
-   Password AVPs again, with the User-Password AVP containing new 
-   information in response to the challenge. This process continues 
-
-
-
-
-Paul Funk               expires September 2006               [Page 22] 
-
-Internet-Draft                                              March 2006         
-
-
-   until the server determines the authentication has succeeded or 
-   failed. 
-
-4.3  Performing Multiple Authentications 
-
-   In some cases, it is desirable to perform multiple user 
-   authentications. For example, a server may want first to 
-   authenticate the user by password, then by a hardware token. 
-
-   The server may perform any number of additional user authentications 
-   using EAP, simply by issuing a EAP-Request with a new protocol type 
-   once the previous authentication has completed. 
-
-   For example, a server wishing to perform MD5-Challenge followed by 
-   Generic Token Card would first issue an EAP-Request/MD5-Challenge 
-   AVP and receive a response. If the response is satisfactory, it 
-   would then issue EAP-Request/Generic Token Card AVP and receive a 
-   response. If that response were also satisfactory, it would consider 
-   the user authenticated. 
-
-5  Example Message Sequences 
-
-   This section presents a variety of possible TLS/IA message 
-   sequences. These examples are not meant to exhaustively depict all 
-   possible scenarios.  
-
-   Parentheses indicate optional TLS messages. Brackets indicate 
-   optional message exchanges. An ellipsis (. . .) indicates optional 
-   repetition of preceding messages. 
-
-5.1  Full Initial Handshake with Intermediate and Final Application 
-Phases 
-
-   The diagram below depicts a full initial handshake phase followed by 
-   two application phases. 
-
-   Note that the client concludes the intermediate phase and starts the 
-   final phase in an uninterrupted sequence of three messages: 
-   ChangeCipherSpec and PhaseFinished belong to the intermediate phase, 
-   and ApplicationPayload belongs to the final phase.  
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** TLS Handshake:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                       (Certificate) 
-                                                   ServerKeyExchange 
-                                                (CertificateRequest) 
-                                      <--------      ServerHelloDone 
-
-
-
-Paul Funk               expires September 2006               [Page 23] 
-
-Internet-Draft                                              March 2006         
-
-
-         (Certificate) 
-         ClientKeyExchange 
-         (CertificateVerify) 
-         ChangeCipherSpec 
-         Finished                     --------> 
-                                                    ChangeCipherSpec 
-                                      <--------        Finished 
-    
-   *** Intermediate Phase: 
-         ApplicationPayload           -------->  
-    
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                      <--------        
-   IntermediatePhaseFinished 
-         IntermediatePhaseFinished 
-   *** Final Phase: 
-         ApplicationPayload           -------->  
-                                          
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                      <--------   FinalPhaseFinished 
-    
-         FinalPhaseFinished           --------> 
-    
-5.2  Resumed Session with Single Application Phase 
-
-   The diagram below depicts a resumed session followed by a single 
-   application phase. 
-
-   Note that the client concludes the initial phase and starts the 
-   final phase in an uninterrupted sequence of three messages: 
-   ChangeCipherSpec and PhaseFinished belong to the initial phase, and 
-   ApplicationPayload belongs to the final phase.  
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** TLS Handshake:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-
-
-
-Paul Funk               expires September 2006               [Page 24] 
-
-Internet-Draft                                              March 2006         
-
-
-                                                    ChangeCipherSpec 
-                                      <--------             Finished 
-         ChangeCipherSpec 
-         Finished 
-   *** Final Phase: 
-         ApplicationPayload           -------->  
-                                          
-       [ 
-                                      <--------   ApplicationPayload  
-    
-         ApplicationPayload           -------->  
-    
-                                         ... 
-       ] 
-                                      <--------   FinalPhaseFinished 
-                      
-         FinalPhaseFinished           --------> 
-    
-5.3  Resumed Session with No Application Phase 
-
-   The diagram below depicts a resumed session without any subsequent 
-   application phase. This will occur if the client indicates in its 
-   ClientInnerApplication message that no application phase is required 
-   and the server concurs.  
-
-   Note that this message sequence is identical to that of a standard 
-   TLS resumed session. 
-
-         Client                                               Server 
-         ------                                               ------ 
-    
-   *** TLS Handshake:  
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                    ChangeCipherSpec 
-                                      <--------             Finished 
-         ChangeCipherSpec 
-         Finished                     --------> 
-    
-6  Security Considerations 
-
-   This document introduces a new TLS extension called "Inner 
-   Application". When TLS is used with the Inner Application extension 
-   (TLS/IA), additional messages are exchanged during the TLS 
-   handshake. Hence a number of security issues need to be taken into 
-   consideration. Since the security heavily depends on the information 
-   (called "applications") which are exchanged between the TLS client 
-   and the TLS server as part of the TLS/IA extension we try to 
-   classify them into two categories: The first category considers the 
-   case where the exchange results in the generation of keying 
-   material. This is, for example, the case with certain EAP methods. 
-
-
-
-Paul Funk               expires September 2006               [Page 25] 
-
-Internet-Draft                                              March 2006         
-
-
-   EAP is one of the envisioned main "applications". The second 
-   category focuses on cases where no session key is generated. The 
-   security treatment of the latter category is discouraged since it is 
-   subject to man-in-the-middle attacks if the two sessions cannot be 
-   bound to each other as suggested in [MITM].  
-
-   In the following, we investigate a number of security issues:  
-
-   - Architecture and Trust Model 
-
-     For many of the use cases in this document we assume that three 
-     functional entities participate in the protocol exchange: TLS 
-     client, TLS server and a AAA infrastructure (typically consisting 
-     of a AAA server and possibly a AAA broker). The protocol exchange 
-     described in this document takes place between the TLS client and 
-     the TLS server. The interaction between the AAA client (which 
-     corresponds to the TLS server) and the AAA server is described in 
-     the respective AAA protocol documents and therefore outside the 
-     scope of this document. The trust model behind this architecture 
-     with respect to the authentication, authorization, session key 
-     establishment and key transport within the AAA infrastructure is 
-     discussed in [KEYING].  
-
-   - Authentication 
-
-     This document assumes that the TLS server is authenticated to the 
-     TLS client as part of the authentication procedure of the initial 
-     TLS Handshake. This approach is similar to the one chosen with 
-     the EAP support in IKEv2 (see [IKEv2]). Typically, public key 
-     based server authentication is used for this purpose. More 
-     interesting is the client authentication property whereby 
-     information exchanged as part of the Inner Application is used to 
-     authenticate (or authorize) the client. For example, if EAP is 
-     used as an inner application then EAP methods are used to perform 
-     authentication and key agreement between the EAP peer (most 
-     likely the TLS client) and the EAP server (i.e., AAA server).  
-
-   - Authorization  
-
-     Throughout this document it is assumed that the TLS server can be 
-     authorized by the TLS client as a legitimate server as part of 
-     the authentication procedure of the initial TLS Handshake. The 
-     entity acting as TLS client can be authorized either by the TLS 
-     server or by the AAA server (if the authorization decision is 
-     offloaded). Typically, the authenticated identity is used to 
-     compute the authorization decision but credential-based 
-     authorization mechanisms may be used as well. 
-
-   - Man-in-the-Middle Attack 
-
-
-
-
-
-Paul Funk               expires September 2006               [Page 26] 
-
-Internet-Draft                                              March 2006         
-
-
-     Man-in-the-middle attacks have become a concern with tunneled 
-     authentication protocols because of the discovered 
-     vulnerabilities (see [MITM]) of a missing cryptographic binding 
-     between the independent protocol sessions. This document also 
-     proposes a tunneling protocol, namely individual inner 
-     application sessions are tunneled within a previously executed 
-     session. The first protocol session in this exchange is the 
-     initial TLS Handshake. To avoid man-in-the-middle attacks, 
-     Section 2.2 addresses how to establish such a cryptographic 
-     binding.  
-
-   - User Identity Confidentiality 
-
-     The TLS/IA extension allows splitting the authentication of the 
-     TLS server from the TLS client into two separate sessions. As one 
-     of the advantages, this provides active user identity 
-     confidentiality since the TLS client is able to authenticate the 
-     TLS server and to establish a unilateral authenticated and 
-     confidentiality-protected channel prior to starting the client-
-     side authentication. 
-
-   - Session Key Establishment 
-
-     TLS [RFC2246] defines how session key material produced during 
-     the TLS Handshake is generated with the help of a pseudo-random 
-     function to expand it to keying material of the desired length 
-     for later usage in the TLS Record Layer. Section 2.2 gives some 
-     guidelines with regard to the master key generation. Since the 
-     TLS/IA extension supports multiple exchanges whereby each phase 
-     concludes with a generated keying material. In addition to the 
-     keying material established as part of TLS itself, most inner 
-     applications will produce their keying material. For example, 
-     keying material established as part of an EAP method must be 
-     carried from the AAA server to the AAA client. Details are 
-     subject to the specific AAA protocol (for example, EAP usage in 
-     Diameter [AAA-EAP].  
-
-   - Denial of Service Attacks 
-
-     This document does not modify the initial TLS Handshake and as 
-     such, does not introduce new vulnerabilities with regard to DoS 
-     attacks. Since the TLS/IA extension allows to postpone the 
-     client-side authentication to a later stage in the protocol 
-     phase. As such, it allows malicious TLS clients to initiate a 
-     number of exchanges while remaining anonymous. As a consequence, 
-     state at the server is allocated and computational efforts are 
-     required at the server side. Since the TLS client cannot be 
-     stateless this is not strictly a DoS attack. 
-
-   - Confidentiality Protection and Dictionary Attack Resistance 
-
-
-
-
-Paul Funk               expires September 2006               [Page 27] 
-
-Internet-Draft                                              March 2006         
-
-
-     Similar to the user identity confidentiality property the usage 
-     of the TLS/IA extension allows to establish a unilateral 
-     authenticated tunnel which is confidentiality protected. This 
-     tunnel protects the inner application information elements to be 
-     protected against active adversaries and therefore provides 
-     resistance against dictionary attacks when password-based 
-     authentication protocols are used inside the tunnel. In general, 
-     information exchanged inside the tunnel experiences 
-     confidentiality protection.  
-
-   - Downgrading Attacks 
-
-     This document defines a new extension. The TLS client and the TLS 
-     server indicate the capability to support the TLS/IA extension as 
-     part of the client_hello_extension_list and the 
-     server_hello_extension_list payload. More details can be found in 
-     Section 2.5. To avoid downgrading attacks whereby an adversary 
-     removes a capability from the list is avoided by the usage of the 
-     IntermediatePhaseFinished or FinalPhaseFinished message as 
-     described in Section 2.1. 
-
-7  References 
-
-7.1  Normative References 
-
-   [RFC1700]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 
-               1700, October 1994. 
-
-   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication 
-               Protocol (CHAP)", RFC 1994, August 1996. 
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate 
-               Requirement Levels", RFC 2119, March 1997. 
-
-   [RFC2246]  Dierks, T., and C. Allen, "The TLS Protocol Version 
-               1.0", RFC 2246, November 1998. 
-
-   [RFC2433]  Zorn, G., and S. Cobb, "Microsoft PPP CHAP Extensions", 
-               RFC 2433, October 1998. 
-
-   [RFC2486]  Aboba, B., and M. Beadles, "The Network Access 
-               Identifier", RFC 2486, January 1999. 
-
-   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", 
-               RFC 2548, March 1999. 
-
-   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", 
-               RFC 2759, January 2000. 
-
-
-
-
-
-
-Paul Funk               expires September 2006               [Page 28] 
-
-Internet-Draft                                              March 2006         
-
-
-   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson, 
-               "Remote Authentication Dial In User Service (RADIUS)", 
-               RFC 2865, June 2000. 
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 
-               J., and T. Wright, "Transport Layer Security (TLS) 
-               Extensions", RFC 3546, June 2003. 
-
-   [RFC3579]  Aboba, B., and P.Calhoun, "RADIUS (Remote Authentication 
-               Dial In User Service) Support For Extensible 
-               Authentication Protocol (EAP)", RFC 3579, September 
-               2003. 
-
-   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 
-               Arkko, "Diameter Base Protocol", RFC 3588, July 2003. 
-
-   [RFC3784]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and 
-               H. Levkowetz, "PPP Extensible Authentication Protocol 
-               (EAP)", RFC 3784, June 2004. 
-
- 
-7.2  Informative References 
-
-   [RFC1661]  Simpson, W. (Editor), "The Point-to-Point Protocol 
-               (PPP)", STD 51, RFC 1661, July 1994. 
-
-   [RFC2716]  Aboba, B., and D. Simon, "PPP EAP TLS Authentication 
-               Protocol", RFC 2716, October 1999. 
-
-   [EAP-TTLS] Funk, P., and S. Blake-Wilson, " EAP Tunneled TLS 
-               Authentication Protocol (EAP-TTLS)", draft-ietf-pppext-
-               eap-ttls-05.txt, July 2004. 
-
-   [EAP-PEAP] Palekar, A., Simon, D., Salowey, J., Zhou, H., Zorn, G., 
-               and S. Josefsson, "Protected EAP Protocol (PEAP) Version 
-               2", draft-josefsson-pppext-eap-tls-eap-08.txt, July 
-               2004. 
-
-   [TLS-PSK]  Eronen, P., and H. Tschofenig, "Pre-Shared Key 
-               Ciphersuites for Transport Layer Security (TLS)", draft-
-               ietf-tls-psk-01.txt, August 2004. 
-
-   [802.1X]   IEEE Standards for Local and Metropolitan Area Networks:  
-               Port based Network Access Control, IEEE Std 802.1X-2001, 
-               June 2001. 
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 
-               in Tunneled Authentication", 
-               http://www.saunalahti.fi/~asokan/research/mitm.html, 
-               Nokia Research Center, Finland, October 24 2002. 
-
-
-
-
-Paul Funk               expires September 2006               [Page 29] 
-
-Internet-Draft                                              March 2006         
-
-
-   [KEYING]   Aboba, B., Simon, D., Arkko, J. and H. Levkowetz, "EAP 
-               Key Management Framework", draft-ietf-eap-keying-01.txt 
-               (work in progress), October 2003. 
-
-   [IKEv2]    C.Kaufman, "Internet Key Exchange (IKEv2) Protocol", 
-               draft-ietf-ipsec-ikev2-16.txt (work in progress), 
-               September 2004. 
-
-   [AAA-EAP]  Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 
-               Authentication Protocol (EAP) Application", draft-ietf-
-               aaa-eap-03.txt (work in progress), October 2003. 
-
-8  Authors' Addresses 
-
-   Questions about this memo can be directed to: 
-
-      Paul Funk 
-      Juniper Networks 
-      222 Third Street 
-      Cambridge, MA 02142 
-      USA 
-      Phone: +1 617 497-6339 
-      E-mail: pfunk@juniper.net 
-
-      Simon Blake-Wilson 
-      Basic Commerce & Industries, Inc. 
-      96 Spadina Ave, Unit 606  
-      Toronto, Ontario M5V 2J6 
-      Canada 
-      Phone: +1 416 214-5961 
-      E-mail: sblakewilson@bcisse.com 
-
-      Ned Smith 
-      Intel Corporation 
-      MS: JF1-229 
-      2111 N.E. 25th Ave. 
-      Hillsboro, OR 97124 
-      USA 
-      Phone: +1 503 264-2692  
-      E-mail: ned.smith@intel.com 
-
-      Hannes Tschofenig 
-      Siemens 
-      Otto-Hahn-Ring 6 
-      Munich, Bayern  81739\ 
-      Germany 
-      Phone: +49 89 636 40390 
-      E-mail: Hannes.Tschofenig@siemens.com 
-
-      Thomas Hardjono 
-      VeriSign Inc. 
-
-
-
-Paul Funk               expires September 2006               [Page 30] 
-
-Internet-Draft                                              March 2006         
-
-
-      487 East Middlefield Road 
-      M/S MV6-2-1 
-      Mountain View, CA 94043 
-      USA 
-      Phone: +1 650 426-3204 
-      E-mail: thardjono@verisign.com 
-
-9  Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The Internet Society (2006).  This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-Paul Funk               expires September 2006               [Page 31] 
-
-Internet-Draft                                              March 2006         
-
-
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Paul Funk               expires September 2006               [Page 32] 
-
diff --git a/doc/protocol/draft-funk-tls-inner-application-extension-03.txt b/doc/protocol/draft-funk-tls-inner-application-extension-03.txt
deleted file mode 100644
index cc63d2e753..0000000000
--- a/doc/protocol/draft-funk-tls-inner-application-extension-03.txt
+++ /dev/null
@@ -1,2073 +0,0 @@
-
-
-
-TLS Working Group                                                P. Funk
-Internet-Draft                                       Funk Software, Inc.
-Expires: December 27, 2006                               S. Blake-Wilson
-                                            Basic Commerce & Industries,
-                                                                    Inc.
-                                                                N. Smith
-                                                       Intel Corporation
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                             T. Hardjono
-                                                            Verisign Inc
-                                                           June 25, 2006
-
-
-                TLS Inner Application Extension (TLS/IA)
-           draft-funk-tls-inner-application-extension-03.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 27, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 1]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   This document defines a new TLS extension called "Inner Application".
-   When TLS is used with the Inner Application extension (TLS/IA),
-   additional messages are exchanged after completion of the TLS
-   handshake, in effect providing an extended handshake prior to the
-   start of upper layer data communications.  Each TLS/IA message
-   contains an encrypted sequence of Attribute-Value-Pairs (AVPs) from
-   the RADIUS/Diameter namespace.  Hence, the AVPs defined in RADIUS and
-   Diameter have the same meaning in TLS/AI; that is, each attribute
-   code point refers to the same logical attribute in any of these
-   protocols.  Arbitrary "applications" may be implemented using the AVP
-   exchange.  Possible applications include EAP or other forms of user
-   authentication, client integrity checking, provisioning of additional
-   tunnels, and the like.  Use of the RADIUS/Diameter namespace provides
-   natural compatibility between TLS/IA applications and widely deployed
-   AAA infrastructures.
-
-   It is anticipated that TLS/IA will be used with and without
-   subsequent protected data communication within the tunnel established
-   by the handshake.  For example, TLS/IA may be used to secure an HTTP
-   data connection, allowing more robust password-based user
-   authentication to occur than would otherwise be possible using
-   mechanisms available in HTTP.  TLS/IA may also be used for its
-   handshake portion alone; for example, EAP-TTLSv1 encapsulates a
-   TLS/IA handshake in EAP as a means to mutually authenticate a client
-   and server and establish keys for a separate data connection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 2]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  A bit of History . . . . . . . . . . . . . . . . . . . . .  5
-     1.2.  TLS With or Without Upper Layer Data Communications  . . .  6
-   2.  The Inner Application Extension to TLS . . . . . . . . . . . .  7
-     2.1.  TLS/IA Overview  . . . . . . . . . . . . . . . . . . . . .  8
-     2.2.  Message Exchange . . . . . . . . . . . . . . . . . . . . .  9
-     2.3.  Inner Secret . . . . . . . . . . . . . . . . . . . . . . . 10
-       2.3.1.  Application Session Key Material . . . . . . . . . . . 11
-     2.4.  Session Resumption . . . . . . . . . . . . . . . . . . . . 13
-     2.5.  Error Termination  . . . . . . . . . . . . . . . . . . . . 13
-     2.6.  Negotiating the Inner Application Extension  . . . . . . . 13
-     2.7.  InnerApplication Protocol  . . . . . . . . . . . . . . . . 14
-       2.7.1.  InnerApplicationExtension  . . . . . . . . . . . . . . 14
-       2.7.2.  InnerApplication Message . . . . . . . . . . . . . . . 15
-       2.7.3.  IntermediatePhaseFinished and FinalPhaseFinished
-               Messages . . . . . . . . . . . . . . . . . . . . . . . 15
-       2.7.4.  The ApplicationPayload Message . . . . . . . . . . . . 16
-     2.8.  Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-   3.  Encapsulation of AVPs within ApplicationPayload Messages . . . 18
-     3.1.  AVP Format . . . . . . . . . . . . . . . . . . . . . . . . 18
-     3.2.  AVP Sequences  . . . . . . . . . . . . . . . . . . . . . . 19
-     3.3.  Guidelines for Maximum Compatibility with AAA Servers  . . 20
-   4.  Tunneled Authentication within Application Phases  . . . . . . 21
-     4.1.  Implicit challenge . . . . . . . . . . . . . . . . . . . . 21
-     4.2.  Tunneled Authentication Protocols  . . . . . . . . . . . . 22
-       4.2.1.  EAP  . . . . . . . . . . . . . . . . . . . . . . . . . 22
-       4.2.2.  CHAP . . . . . . . . . . . . . . . . . . . . . . . . . 23
-       4.2.3.  MS-CHAP  . . . . . . . . . . . . . . . . . . . . . . . 23
-       4.2.4.  MS-CHAP-V2 . . . . . . . . . . . . . . . . . . . . . . 24
-       4.2.5.  PAP  . . . . . . . . . . . . . . . . . . . . . . . . . 25
-     4.3.  Performing Multiple Authentications  . . . . . . . . . . . 26
-   5.  Example Message Sequences  . . . . . . . . . . . . . . . . . . 27
-     5.1.  Full Initial Handshake with Intermediate and Final
-           Application Phasess  . . . . . . . . . . . . . . . . . . . 27
-     5.2.  Resumed Session with Single Application Phase  . . . . . . 29
-     5.3.  Resumed Session with No Application Phase  . . . . . . . . 29
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 34
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 35
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
-   Intellectual Property and Copyright Statements . . . . . . . . . . 37
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 3]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-1.  Introduction
-
-   This specification defines the TLS "Inner Application" extension.
-   The term "TLS/IA" refers to the TLS protocol when used with the Inner
-   Application extension.
-
-   In TLS/IA, the setup portion of TLS is extended to allow an arbitrary
-   exchange of information between client and server within a protected
-   tunnel established during the TLS handshake and prior to the start of
-   upper layer TLS data communications.  The TLS handshake itself is
-   unchanged; the subsequent Inner Application exchange is conducted
-   under the confidentiality and integrity protection that is afforded
-   by the TLS handshake.
-
-   The primary motivation for providing this facility is to allow robust
-   user authentication to occur as part of an "extended" handshake, in
-   particular, user authentication that is based on password
-   credentials, which is best conducted under the protection of an
-   encrypted tunnel to preclude dictionary attack by eavesdroppers.  For
-   example, the Extensible Authentication Protocol (EAP) may be used for
-   authentication using any of a wide variety of methods as part of this
-   extended handshake.  The multi-layer approach of TLS/IA, in which a
-   strong authentication, typically based on a server certificate, is
-   used to protected a password-based authentication, distinguishes it
-   from other TLS variants that rely entirely on a pre-shared key or
-   password for security (such as [I-D.ietf-tls-psk]).
-
-   The protected exchange accommodates any type of client-server
-   application, not just authentication, though authentication may often
-   be the prerequisite for other applications to proceed.  For example,
-   TLS/IA may be used to set up HTTP connections, establish IPsec
-   security associations (as an alternative to IKE), obtain credentials
-   for single sign-on, provide client integrity verification, and so on.
-
-   The new messages that are exchanged between client and server are
-   encoded as sequences of Attribute-Value-Pairs (AVPs) from the RADIUS/
-   Diameter namespace.  Use of the RADIUS/Diameter namespace provides
-   natural compatibility between TLS/IA applications and widely deployed
-   AAA infrastructures.  This namespace is extensible, allowing new AVPs
-   and, thus, new applications to be defined as needed, either by
-   standards bodies or by vendors wishing to define proprietary
-   applications.
-
-   The TLS/IA exchange comprises one or more "phases", each of which
-   consists of an arbitrary number of AVP exchanges followed by a
-   confirmation exchange.  Authentications occurring in any phase must
-   be confirmed prior to continuing to the next phase.  This allows
-   applications to implement security dependencies in which particular
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 4]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   assurances are required prior to the exchange of additional
-   information.
-
-1.1.  A bit of History
-
-   The TLS protocol has its roots in the Netscape SSL protocol, which
-   was originally intended to protect HTTP traffic.  It provides either
-   one-way or mutual certificate-based authentication of client and
-   server.  In its most typical use in HTTP, the client authenticates
-   the server based on the server's certificate and establishes a tunnel
-   through which HTTP traffic is passed.
-
-   For the server to authenticate the client within the TLS handshake,
-   the client must have its own certificate.  In cases where the client
-   must be authenticated without a certificate, HTTP, not TLS,
-   mechanisms would have to be employed.  For example, HTTP headers have
-   been defined to perform user authentications.  However, these
-   mechanisms are primitive compared to other mechanisms, most notably
-   EAP, that have been defined for contexts other than HTTP.
-   Furthermore, any mechanisms defined for HTTP cannot be utilized when
-   TLS is used to protect non-HTTP traffic.
-
-   The TLS protocol has also found an important use in authentication
-   for network access, originally within PPP for dial-up access and
-   later for wireless and wired 802.1X access.  Several EAP types have
-   been defined that utilize TLS to perform mutual client-server
-   authentication.  The first to appear, EAP-TLS, uses the TLS handshake
-   to authenticate both client and server based on their certificates.
-
-   Subsequently proposed protocols, such EAP-TTLSv0 and EAP-PEAP,
-   utilize the TLS handshake to allow the client to authenticate the
-   server based on the latter's certificate, and then use the protected
-   channel established by the TLS handshake to perform user
-   authentication, typically based on a password.  Such protocols are
-   called "tunneled" EAP protocols.  The authentication mechanism used
-   inside the tunnel may itself be EAP, and the tunnel may also be used
-   to convey additional information between client and server.
-
-   While tunneled authentication would be useful in other contexts
-   besides EAP, the tunneled protocols mentioned above cannot be
-   employed in a more general use of TLS, since the outermost protocol
-   is EAP, not TLS.  Furthermore, these protocols use the TLS tunnel to
-   carry authentication exchanges, and thus preclude use of the TLS
-   tunnel for other purposes such as carrying HTTP traffic.
-
-   TLS/IA provides a means to perform user authentication and other
-   message exchanges between client and server strictly within TLS.
-   TLS/IA can thus be used both for flexible user authentication within
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 5]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   a TLS session and as a basis for tunneled authentication within EAP.
-
-   The TLS/IA approach is to insert an additional message exchange
-   between the TLS handshake and the subsequent data communications
-   phase.  This message exchange is carried in a new record type, which
-   is distinct from the record type that carries upper layer data.
-   Thus, the data portion of the TLS exchange becomes available for HTTP
-   or another protocol that needs to be secured.
-
-1.2.  TLS With or Without Upper Layer Data Communications
-
-   It is anticipated that TLS/IA will be used with and without
-   subsequent protected data communication within the tunnel established
-   by the handshake.
-
-   For example, TLS/IA may be used to protect an HTTP connection,
-   allowing more robust password-based user authentication to occur
-   within the TLS/IA extended handshake than would otherwise be possible
-   using mechanisms available in HTTP.
-
-   TLS/IA may also be used for its handshake portion alone.  For
-   example, EAP-TTLSv1 encapsulates a TLS/IA extended handshake in EAP
-   as a means to mutually authenticate a client and server and establish
-   keys for a separate data connection; no subsequent TLS data portion
-   is required.  Another example might be the use of TLS/IA directly
-   over TCP in order to provide a user with credentials for single
-   sign-on.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 6]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-2.  The Inner Application Extension to TLS
-
-   The Inner Application extension to TLS follows the guidelines of
-   [RFC3546].
-
-   A new extension type is defined for negotiating use of TLS/IA:
-      The InnerApplicationExtension extension type.  The client proposes
-      use of this extension by including a InnerApplicationExtension
-      message in its ClientHello handshake message, and the server
-      confirms its use by including a InnerApplicationExtension message
-      in its ServerHello handshake message.
-
-
-   A new record type (ContentType) is defined for use in TLS/IA:
-      The InnerApplication record type.  This record type carries all
-      messages that are exchanged after the TLS handshake and prior to
-      exchange of data.
-
-
-   A new message type is defined for use within the InnerApplication
-   record type:
-
-      The InnerApplication message.  This message may encapsulate any of
-      the three following subtypes:
-
-         The ApplicationPayload message.  This message is used to carry
-         AVP (Attribute-Value Pair) sequences within the TLS/IA extended
-         handshake, in support of client-server applications such as
-         authentication.
-
-         The IntermediatePhaseFinished message.  This message confirms
-         session keys established during the current TLS/IA phase, and
-         indicates that at least one additional phase is to follow.
-
-         The FinalPhaseFinished message.  This message confirms session
-         keys established during the current TLS/IA phase, and indicates
-         that no further phases are to follow.
-
-
-   Two new alert codes are defined for use in TLS/IA:
-
-      The InnerApplicationFailure alert.  This error alert allows either
-      party to terminate the TLS/IA extended handshake due to a failure
-      in an application implemented via AVP sequences carried in
-      ApplicationPayload messages.
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 7]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-      The InnerApplicationVerification alert.  This error alert allows
-      either party to terminate the TLS/IA extended handshake due to
-      incorrect verification data in a received
-      IntermediatePhaseFinished or FinalPhaseFinished message.
-
-
-   The following new assigned numbers are used in TLS/IA:
-      "InnerApplicationExtension" extension type: 37703
-      "InnerApplication" record type: 24
-      "InnerApplicationFailure" alert code: 208
-      "InnerApplicationVerification" alert code: 209
-
-   [Editor's note: I have not checked these types yet against types
-   defined in RFCs or drafts.  The TLS RFC specifies that new record
-   types use the next number after ones already defined; hence I used
-   24, though I don't know if that is already taken.]
-
-2.1.  TLS/IA Overview
-
-   In TLS/IA, zero or more "application phases are inserted after the
-   TLS handshake and prior to ordinary data exchange.  The last such
-   application phase is called the "final phase"; any application phases
-   prior to the final phase are called "intermediate phases".
-   Intermediate phases are only necessary if interim confirmation of
-   session keys generated during an application phase is desired.
-
-   Each application phase consists of ApplicationPayload handshake
-   messages exchanged by client and server to implement applications
-   such as authentication, plus concluding messages for cryptographic
-   confirmation.  These messages are encapsulated in records with
-   ContentType of InnerApplication.  All application phases prior to the
-   final phase use IntermediatePhaseFinished rather than
-   FinalPhaseFinished as the concluding message.  The final phase
-   concludes with the FinalPhaseFinished message.
-
-   Application phases may be omitted entirely only when session
-   resumption is used, provided both client and server agree that no
-   application phase is required.  The client indicates in its
-   ClientHello whether it is willing to omit application phases in a
-   resumed session, and the server indicates in its ServerHello whether
-   any application phases are to ensue.
-
-   In each application phase, the client sends the first
-   ApplicationPayload message.  ApplicationPayload messages are then
-   traded one at a time between client and server, until the server
-   concludes the phase by sending, in response to an ApplicationPayload
-   message from the client, an IntermediatePhaseFinished sequence to
-   conclude an intermediate phase, or a FinalPhaseFinished sequence to
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 8]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   conclude the final phase.  The client then responds with its own
-   IntermediatePhaseFinished or FinalPhaseFinished message.
-
-   Note that the server MUST NOT send an IntermediatePhaseFinished or
-   FinalPhaseFinished message immediately after sending an
-   ApplicationPayload message.  It must allow the client to send an
-   ApplicationPayload message prior to concluding the phase.  Thus,
-   within any application phase, there will be one more
-   ApplicationPayload message sent by the client than sent by the
-   server.
-
-   The server determines which type of concluding message is used,
-   either IntermediatePhaseFinished or FinalPhaseFinished, and the
-   client MUST echo the same type of concluding message.  Each
-   IntermediatePhaseFinished or FinalPhaseFinished message provides
-   cryptographic confirmation of any session keys generated during the
-   current and any prior applications phases.
-
-   Each ApplicationPayload message contains opaque data interpreted as
-   an AVP (Attribute-Value Pair) sequence.  Each AVP in the sequence
-   contains a typed data element.  The exchanged AVPs allow client and
-   server to implement "applications" within a secure tunnel.  An
-   application may be any procedure that someone may usefully define.  A
-   typical application might be authentication; for example, the server
-   may authenticate the client based on password credentials using EAP.
-   Other possible applications include distribution of keys, validating
-   client integrity, setting up IPsec parameters, setting up SSL VPNs,
-   and so on.
-
-   An "inner secret" is computed during each application phase that
-   cryptographically combines the TLS master secret with any session
-   keys that have been generated during the current and any previous
-   application phases.  At the conclusion of each application phase, a
-   new inner secret is computed a nd is used to create verification data
-   that is exchanged via the IntermediatePhaseFinished or
-   FinalPhaseFinished messages.  By mixing session keys of inner
-   authentications with the TLS master secret, certain man-in-the-middle
-   attacks are thwarted [MITM].
-
-2.2.  Message Exchange
-
-   Each intermediate application phase consists of ApplicationPayload
-   messages sent alternately by client and server, and a concluding
-   exchange of IntermediatePhaseFinished messages.  The first and last
-   ApplicationPayload message in each intermediate phase is sent by the
-   client; the first IntermediatePhaseFinished message is sent by the
-   server.  Thus the client begins the exchange with an
-   ApplicationPayload message and the server determines when to conclude
-
-
-
-Funk, et al.            Expires December 27, 2006               [Page 9]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   it by sending IntermediatePhaseFinished.  When it receives the
-   server's IntermediatePhaseFinished message, the client sends its own
-   IntermediatePhaseFinished message, followed by an ApplicationPayload
-   message to begin the next handshake phase.
-
-   The final application proceeds in the same manner as the intermediate
-   phase, except that the FinalPhaseFinished message is sent by the
-   server and echoed by the client, and the client does not send an
-   ApplicationPayload message for the next phase because there is no
-   next phase.
-
-   At the start of each application phase, the server MUST wait for the
-   client's opening ApplicationPayload message before it sends its own
-   ApplicationPayload message to the client.  The client MUST NOT
-   initiate conclusion of an application phase by sending the first
-   IntermediatePhaseFinished or FinalPhaseFinished message; it MUST
-   allow the server to initiate the conclusion of the phase.
-
-   Note that it is perfectly acceptable for either client or server to
-   send an ApplicationPayload message containing no AVPs.  The client,
-   for example, may have no AVPs to send in its first or last
-   ApplicationPayload message during an application phase.
-
-2.3.  Inner Secret
-
-   The inner secret is a 48-octet value used to confirm that the
-   endpoints of the TLS handshake are the same entities as the endpoints
-   of the inner authentications that may have been performed during each
-   application phase.
-
-   The inner secret is initialized to the master secret at the
-   conclusion of the TLS handshake.  At the conclusion of each
-   application phase, prior to computing verification data for inclusion
-   in the IntermediatePhaseFinished or FinalPhaseFinished message, each
-   party permutes the inner secret using a PRF that includes session
-   keys produced during the current application phase.  The value that
-   results replaces the current inner secret and is used to compute the
-   verification data.
-
-
-   inner_secret = PRF(inner_secret,
-                      "inner secret permutation",
-                      SecurityParameters.server_random +
-                      SecurityParameters.client_random +
-                                     session_key_material) [0..48];
-
-   session_key_material is the concatenation of session_key vectors,
-   one for each session key generated during the current phase, where:
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 10]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-           opaque session_key<1..2^16-1>;
-
-
-   In other words, each session key is prefixed by a 2-octet length to
-   produce the session_key vector.
-
-   Since multiple session keys may be produced during a single
-   application phase, the following method is used to determine the
-   order of concatenation: Each session key is treated as an unsigned
-   big-endian numeric value, and the set of session keys is ordered from
-   lowest to highest.  The session keys are then converted to
-   session_key vectors and concatenated in the determined order to form
-   session_key_material.
-
-   If no session keys were generated during the current phase,
-   session_key_material will be null.
-
-   Note that session_key_material itself is not a vector and therefore
-   not prefixed with the length of the entire collection of session_key
-   vectors.  Note that, within TLS itself, the inner secret is used for
-   verification only, not for encryption.  However, the inner secret
-   resulting from the final application phase may be exported for use as
-   a key from which additional session keys may be derived for arbitrary
-   purposes, including encryption of data communications separate from
-   TLS.
-
-   An exported inner secret should not be used directly for any
-   cryptographic purpose.  Instead, additional keys should be derived
-   from the inner secret, for example by using a PRF.  This ensures
-   cryptographic separation between use of the inner secret for session
-   key confirmation and additional use of the inner secret outside
-   TLS/IA.
-
-2.3.1.  Application Session Key Material
-
-   Many authentication protocols used today generate session keys that
-   are bound to the authentication.  Such keying material is normally
-   intended for use in a subsequent data connection for encryption and
-   validation.  For example, EAP-TLS, MS-CHAP-V2, and EAP-MS-CHAP-V2
-   generate session keys.
-
-   Any session keys generated during an application phase MUST be used
-   to permute the TLS/IA inner secret between one phase and the next,
-   and MUST NOT be used for any other purpose.
-
-   Each authentication protocol may define how the session key it
-   generates is mapped to an octet sequence of some length for the
-   purpose of TLS/IA mixing.  However, for protocols which do not
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 11]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   specify this (including the multitude of protocols that pre-date
-   TLS/IA) the following rules are defined.  The first rule that applies
-   SHALL be the method for determining the session key.
-
-      If the authentication protocol produces an MSK (as defined in
-      [RFC3784]), the MSK is used as the session key.  Note that an MSK
-      is 64 octets.
-
-
-      If the authentication protocol maps its keying material to the
-      RADIUS attributes MS-MPPE-Recv-Key and MS-MPPE-Send-Key
-      [RFC2548]], then the keying material for those attributes are
-      concatenated, with MS-MPPE-Recv-Key first (Note that this rule
-      applies to MS-CHAP-V2 and EAP-MS-CHAP-V2.)
-
-
-      If the authentication protocol uses a pseudo-random function to
-      generate keying material, that function is used to generate 64
-      octets for use as keying material.
-
-   Providing verification of the binding of session keys to the TLS
-   master secret is necessary to preclude man-in-the-middle attacks
-   against tunneled authentication protocols, as described in [MITM].
-   In such an attack, an unsuspecting client is induced to perform an
-   untunneled authentication with an attacker posing as a server; the
-   attacker then introduces the authentication protocol into a tunneled
-   authentication protocol, fooling an authentic server into believing
-   that the attacker is the authentic user.
-
-   By mixing both the TLS master secret and session keys generated
-   during application phase authentication into the inner secret used
-   for application phase verification, such attacks are thwarted, as it
-   guarantees that the same client acted as the endpoint for both the
-   TLS handshake and the application phase authentication.  Note that
-   the session keys generated during authentication must be
-   cryptographically bound to the authentication and not derivable from
-   data exchanged during authentication in order for the keying material
-   to be useful in thwarting such attacks.
-
-   In addition, the fact that the inner secret cryptographically
-   incorporates session keys from application phase authentications
-   provides additional protection when the inner secret is exported for
-   the purpose of generating additional keys for use outside of the TLS
-   exchange.  If such an exported secret did not include keying material
-   from inner authentications, an eavesdropper who somehow knew the
-   server's private key could, in an RSA-based handshake, determine the
-   exported secret and hence would be able to compute the additional
-   keys that are based on it.  When inner authentication keying
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 12]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   material, unknown to the attacker, is incorporated into the exported
-   secret, such an attack becomes infeasible.
-
-2.4.  Session Resumption
-
-   A TLS/IA initial handshake phase may be resumed using standard
-   mechanisms defined in [RFC2246].  When the TLS session is resumed,
-   client and server may not deem it necessary to exchange AVPs in one
-   or more additional application phases, as the resumption itself may
-   provide the necessary security.
-
-   The client indicates within the InnerApplicationExtension message in
-   ClientHello whether it requires AVP exchange when session resumption
-   occurs.  If it indicates that it does not, then the server may at its
-   option omit application phases and the two parties proceed to upper
-   layer data communications immediately upon completion of the TLS
-   handshake.  The server indicates whether application phases are to
-   follow the TLS handshake in its InnerApplication extension message in
-   ServerHello.
-
-   Note that [RFC3546] specifically states that when session resumption
-   is used, the server MUST ignore any extensions in the ClientHello.
-   However, it is not possible to comply with this requirement for the
-   Inner Application extension, since even in a resumed session it may
-   be necessary to include application phases, and whether they must be
-   included is negotiated in the extension message itself.  Therefore,
-   the [RFC3546] provision is explicitly overridden for the single case
-   of the Inner Application extension, which is considered an exception
-   to this rule.
-
-   A TLS/IA session MAY NOT be resumed if an application phase resulted
-   in failure, even though the TLS handshake itself succeeded.  Both
-   client and server MUST NOT save session state for possible future
-   resumption unless the TLS handshake and all subsequent application
-   phases have been successfully executed.
-
-2.5.  Error Termination
-
-   The TLS/IA handshake may be terminated by either party sending a
-   fatal alert, following standard TLS procedures.
-
-2.6.  Negotiating the Inner Application Extension
-
-   Use of the InnerApplication extension follows [RFC3546].  The client
-   proposes use of this extension by including the
-   InnerApplicationExtension message in the client_hello_extension_list
-   of the extended ClientHello.  If this message is included in the
-   ClientHello, the server MAY accept the proposal by including the
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 13]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   InnerApplicationExtension message in the server_hello_extension_list
-   of the extended ServerHello.  If use of this extension is either not
-   proposed by the client or not confirmed by the server, the
-   InnerApplication record type MUST NOT be used.
-
-2.7.  InnerApplication Protocol
-
-   All specifications of TLS/IA messages follow the usage defined in
-   [RFC2246].
-
-2.7.1.  InnerApplicationExtension
-
-
-     enum {
-           no(0), yes(1), (255)
-     } AppPhaseOnResumption;
-
-     struct {
-           AppPhaseOnResumption app_phase_on_resumption;
-     } InnerApplicationExtension;
-
-   If the client wishes to propose use of the Inner Application
-   extension, it must include the InnerApplicationExtension message in
-   the extension_data vector in the Extension structure in its extended
-   ClientHello message.
-
-   If the server wishes to confirm use of the Inner Application
-   extension that has been proposed by the client, it must include the
-   InnerApplicationExtension message in the extension_data vector in the
-   Extension structure in its extended ServerHello message.  The
-   AppPhaseOnResumption enumeration allow client and server to negotiate
-   an abbreviated, single-phase handshake when session resumption is
-   employed.  If the client sets app_phase_on_resumption to "no", and if
-   the server resumes the previous session, then the server MAY set
-   app_phase_on_resumption to "no" in the InnerApplication message it
-   sends to the client.  If the server sets app_phase_on_resumption to
-   "no", no application phases occur and the TLS connection proceeds to
-   upper layer data exchange immediately upon conclusion of the TLS
-   handshake.
-
-   The server MUST set app_phase_on_resumption to "yes" if the client
-   set app_phase_on_resumption to "yes" or if the server does not resume
-   the session.  The server MAY set app_phase_on_resumption to "yes" for
-   a resumed session even if the client set app_phase_on_resumption to
-   "no", as the server may have reason to proceed with one or more
-   application phases.
-
-   If the server sets app_phase_on_resumption to "yes" for a resumed
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 14]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   session, then the client MUST initiate an application phase at the
-   conclusion of the TLS handshake.
-
-   The value of app_phase_on_resumption applies to the current handshake
-   only; that is, it is possible for app_phase_on_resumption to have
-   different values in two handshakes that are both resumed from the
-   same original TLS session.
-
-2.7.2.  InnerApplication Message
-
-
-         enum {
-            application_payload(0), intermediate_phase_finished(1),
-            final_phase_finished(2), (255)
-         } InnerApplicationType;
-
-         struct {
-            InnerApplicationType msg_type;
-            uint24 length;
-            select (InnerApplicationType) {
-               case application_payload:       ApplicationPayload;
-               case intermediate_phase_finished:
-            IntermediatePhaseFinished;
-               case final_phase_finished:      FinalPhaseFinished;
-               } body;
-            } InnerApplication;
-
-   The InnerApplication message carries any of the message types defined
-   for the InnerApplication protocol.
-
-2.7.3.  IntermediatePhaseFinished and FinalPhaseFinished Messages
-
-
-         struct {
-            opaque verify_data[12];
-         } PhaseFinished;
-
-         PhaseFinished IntermediatePhaseFinished;
-
-         PhaseFinished FinalPhaseFinished;
-
-         verify_data
-            PRF(inner_secret, finished_label) [0..11];
-
-         finished_label
-            when sent by the client, the string "client phase finished"
-            when sent by the server, the string "server phase finished"
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 15]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   The IntermediatePhaseFinished and FinalPhaseFinished messages have
-   the same structure and include verification data based on the current
-   inner secret.  IntermediatePhaseFinished is sent by the server and
-   echoed by the client to conclude an intermediate application phase,
-   and FinalPhaseFinished is used in the same manner to conclude the
-   final application phase.
-
-2.7.4.  The ApplicationPayload Message
-
-   The ApplicationPayload message carries an AVP sequence during an
-   application handshake phase.  It is defined as follows:
-
-         struct {
-            opaque avps[InnerApplication.length];
-         } ApplicationPayload;
-
-         avps
-            The AVP sequence, treated as an opaque sequence of octets.
-
-         InnerApplication.length
-            The length field in the encapsulating InnerApplication
-         message.
-
-   Note that the "avps" element has its length defined in square bracket
-   rather than angle bracket notation, implying a fixed rather than
-   variable length vector.  This avoids having the length of the AVP
-   sequence specified redundantly both in the encapsulating
-   InnerApplication message and as a length prefix in the avps element
-   itself.
-
-2.8.  Alerts
-
-   Two new alert codes are defined for use during an application phase.
-   The AlertLevel for either of these alert codes MUST be set to
-   "fatal".
-
-   InnerApplicationFailure: An InnerApplicationFailure error alert may
-   be sent by either party during an application phase.  This indicates
-   that the sending party considers the negotiation to have failed due
-   to an application carried in the AVP sequences, for example, a failed
-   authentication.
-
-   InnerApplicationVerification: An InnerApplicationVerification error
-   alert is sent by either party during an application phase to indicate
-   that the received IntermediatePhaseFinished or FinalPhaseFinished is
-   invalid.
-
-   Note that other alerts are possible during an application phase; for
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 16]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   example, decrypt_error.  The InnerApplicationFailure alert relates
-   specifically to the failure of an application implemented via AVP
-   sequences; for example, failure of an EAP or other authentication
-   method, or information passed within the AVP sequence that is found
-   unsatisfactory.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 17]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-3.  Encapsulation of AVPs within ApplicationPayload Messages
-
-   During application phases of the TLS handshake, information is
-   exchanged between client and server through the use of attribute-
-   value pairs (AVPs).  This data is encrypted using the current cipher
-   state.
-
-   The AVP format chosen for TLS/IA is compatible with the Diameter AVP
-   format.  This does not in any way represent a requirement that
-   Diameter be supported by any of the devices or servers participating
-   in the TLS/IA conversation, whether directly as client or server or
-   indirectly as a backend authenticator.  Use of this format is merely
-   a convenience.  Diameter is a superset of RADIUS and includes the
-   RADIUS attribute namespace by definition, though it does not limit
-   the size of an AVP as does RADIUS.  RADIUS, in turn, is a widely
-   deployed AAA protocol and attribute definitions exist for the
-   encapsulation of EAP as well as all commonly used non-EAP password
-   authentication protocols.
-
-   Thus, Diameter is not considered normative except as specified in
-   this document.  Specifically, the AVP Codes used in TLS/IA are
-   semantically equivalent to those defined for Diameter, and, by
-   extension, RADIUS.
-
-   Use of the RADIUS/Diameter namespace allows a TLS/IA server to
-   translate between AVPs it uses to communicate with clients and the
-   protocol requirements of AAA servers that are widely deployed.
-   Additionally, it provides a well-understood mechanism to allow
-   vendors to extend that namespace for their particular requirements.
-
-3.1.  AVP Format
-
-   The format of an AVP is shown below.  All items are in network, or
-   big-endian, order; that is, they have most significant octet first.
-
-    0                   1                   2                   3
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                           AVP Code                            |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |V M r r r r r r|                  AVP Length                   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                        Vendor-ID (opt)                        |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |    Data ...
-   +-+-+-+-+-+-+-+-+
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 18]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   AVP Code
-
-      The AVP Code is four octets and, combined with the Vendor-ID field
-      if present, identifies the attribute uniquely.  The first 256 AVP
-      numbers represent attributes defined in RADIUS.  AVP numbers 256
-      and above are defined in Diameter.
-
-   AVP Flags
-
-      The AVP Flags field is one octet, and provides the receiver with
-      information necessary to interpret the AVP.
-
-      The 'V' (Vendor-Specific) bit indicates whether the optional
-      Vendor-ID field is present.  When set to 1, the Vendor-ID field is
-      present and the AVP Code is interpreted according to the namespace
-      defined by the vendor indicated in the Vendor-ID field.
-
-      The 'M' (Mandatory) bit indicates whether support of the AVP is
-      required.  When set to 0, this indicates that the AVP may be
-      safely ignored if the receiving party does not understand or
-      support it.  When set to 1, if the receiving party does not
-      understand or support the AVP it MUST fail the negotiation by
-      sending an InnerApplicationFailure error alert.  The 'r'
-      (reserved) bits are unused and must be set to 0.
-
-   AVP Length
-
-      The AVP Length field is three octets, and indicates the length of
-      this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
-      (if present) and Data.
-
-   Vendor-ID
-
-      The Vendor-ID field is present if and only if the 'V' bit is set
-      in the AVP Flags field.  It is four octets, and contains the
-      vendor's IANA-assigned "SMI Network Management Private Enterprise
-      Codes" [RFC1700] value.  Vendors defining their own AVPs must
-      maintain a consistent namespace for use of those AVPs within
-      RADIUS, Diameter and TLS/IA.  A Vendor-ID value of zero is
-      semantically equivalent to absence of the Vendor-ID field
-      altogether.
-
-
-3.2.  AVP Sequences
-
-   Data encapsulated within the TLS Record Layer must consist entirely
-   of a sequence of zero or more AVPs.  Each AVP must begin on a 4-octet
-   boundary relative to the first AVP in the sequence.  If an AVP is not
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 19]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   a multiple of 4 octets, it must be padded with 0s to the next 4-octet
-   boundary.  Note that the AVP Length does not include the padding.
-
-
-3.3.  Guidelines for Maximum Compatibility with AAA Servers
-
-   When maximum compatibility with AAA servers is desired, the following
-   guidelines for AVP usage are suggested:
-      Non-vendor-specific AVPs should be selected from the set of
-      attributes defined for RADIUS; that is, attributes with codes less
-      than 256.  This provides compatibility with both RADIUS and
-      Diameter.
-      Vendor-specific AVPs should be defined in terms of RADIUS.
-      Vendor-specific RADIUS attributes translate to Diameter
-      automatically; the reverse is not true.  RADIUS vendor-specific
-      attributes use RADIUS attribute 26 and include vendor ID, vendor-
-      specific attribute code and length; see[RFC2865] for details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 20]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-4.  Tunneled Authentication within Application Phases
-
-   TLS/IA permits user authentication information to be tunneled within
-   an application phase between client and server, protecting the
-   authentication information against active and passive attack.
-
-   Any type of authentication method may be tunneled.  Also, multiple
-   tunneled authentications may be performed.  Normally, tunneled
-   authentication is used when the TLS handshake provides only one-way
-   authentication of the server to the client; however, in certain cases
-   it may be desirable to perform certificate authentication of the
-   client during the initial handshake phase as well as tunneled user
-   authentication in a subsequent application phase.
-
-   This section establishes rules for using well known authentication
-   mechanisms within TLS/IA.  Any new authentication mechanism should,
-   in general, be covered by these rules if it is defined as an EAP
-   type.  Authentication mechanisms whose use within TLS/IA is not
-   covered within this specification may require separate
-   standardization, preferably within the standard that describes the
-   authentication mechanism in question.
-
-4.1.  Implicit challenge
-
-   Certain authentication protocols that use a challenge/response
-   mechanism rely on challenge material that is not generated by the
-   authentication server, and therefore require special handling.
-
-   In PPP protocols such CHAP, MS-CHAP and MS-CHAP-V2, for example, the
-   Network Access Server (NAS) issues a challenge to the client, the
-   client then hashes the challenge with the password and forwards the
-   response to the NAS.  The NAS then forwards both challenge and
-   response to a AAA server.  But because the AAA server did not itself
-   generate the challenge, such protocols are susceptible to replay
-   attack.
-
-   Since within TLS/IA the client also plays the role of NAS, the replay
-   problem is exacerbated.  If the client were able to create both
-   challenge and response, anyone able to observe a CHAP or MS-CHAP
-   exchange could pose as that user by replaying that challenge and
-   response into a TLS/IA conversation.
-
-   To make these protocols secure in TLS/IA, it is necessary to provide
-   a mechanism that produces a challenge that the client cannot control
-   or predict.  When a challenge-based authentication mechanism is used,
-   both client and server use the TLS PRF function to generate as many
-   octets as are required for the challenge, using the constant string
-   "inner application challenge", based on the master secret and random
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 21]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   values established during the TLS handshake, as follows.
-
-           IA_challenge = PRF(SecurityParameters.master_secret,
-                             "inner application challenge",
-                             SecurityParameters.server_random +
-                             SecurityParameters.client_random);
-
-4.2.  Tunneled Authentication Protocols
-
-   This section describes the rules for tunneling specific
-   authentication protocols within TLS/IA.  For each protocol, the
-   RADIUS RFC that defines the relevant attribute formats is cited.
-   Note that these attributes are encapsulated as described in section
-   3.1; that is, as Diameter attributes, not as RADIUS attributes.  In
-   other words, the AVP Code, Length, Flags and optional Vendor-ID are
-   formatted as described in section 3.1, while the Data is formatted as
-   described by the cited RADIUS RFC.
-
-   All tunneled authentication protocols except EAP must be initiated by
-   the client in the first ApplicationPayload message of an application
-   phase.  EAP may be initiated by the client in the first
-   ApplicationPayload message of an application phase; it may also be
-   initiated by the server in any ApplicationPayload message.
-
-   The authentication protocols described below may be performed
-   directly by the TLS/IA server or may be forwarded to a backend AAA
-   server.  For authentication protocols that generate session keys, the
-   backend server must return those session keys to the TLS/IA server in
-   order to allow the protocol to succeed within TLS/IA.  RADIUS or
-   Diameter servers are suitable backend AAA servers for this purpose.
-   RADIUS servers typically return session keys in MS-MPPE-Recv-Key and
-   MS-MPPE-Send-Key attributes [RFC2548]; Diameter servers return
-   session keys in the EAP-Master-Session-Key AVP [I-D.ietf-aaa-eap].
-
-4.2.1.  EAP
-
-   EAP is described in [RFC3784]; RADIUS attribute formats are described
-   in [RFC3579].  When EAP is the tunneled authentication protocol, each
-   tunneled EAP packet between the client and server is encapsulated in
-   an EAP-Message AVP.  Either the client or the server may initiate
-   EAP.
-
-   The client is the first to transmit within any application phase, and
-   it may include an EAP-Response/Identity AVP in its ApplicationPayload
-   message to begin an EAP conversation.  Alternatively, if the client
-   does not initiate EAP the server may, by including an EAP-Request/
-   Identity AVP in its ApplicationPayload message.  The client's EAP-
-   Response/Identity provides the username, which MUST be a Network
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 22]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   Access Identifier (NAI) [RFC2486]; that is, it MUST be in the
-   following format: username@realm
-
-   The @realm portion is optional, and is used to allow the server to
-   forward the EAP message sequence to the appropriate server in the AAA
-   infrastructure when necessary.
-
-   The EAP authentication between client and server proceeds normally,
-   as described in [RFC3784].  However, upon completion the server does
-   not send an EAP-Success or EAP-Failure AVP.  Instead, the server
-   signals success when it concludes the application phase by issuing a
-   Finished or PhaseFinished message, or it signals failure by issuing
-   an InnerApplicationFailure alert.
-
-   Note that the client may also issue an InnerApplicationFailure alert,
-   for example, when authentication of the server fails in a method
-   providing mutual authentication.
-
-4.2.2.  CHAP
-
-   The CHAP algorithm is described in [RFC1994]; RADIUS attribute
-   formats are described in [RFC2865].
-
-   Both client and server generate 17 octets of challenge material,
-   using the constant string "inner application challenge" as described
-   above.  These octets are used as follows:
-      CHAP-Challenge [16 octets]
-      CHAP Identifier [1 octet]
-
-   The client initiates CHAP by including User-Name, CHAP-Challenge and
-   CHAP-Password AVPs in the first ApplicationPayload message in any
-   application phase.  The CHAP-Challenge value is taken from the
-   challenge material.  The CHAP-Password consists of CHAP Identifier,
-   taken from the challenge material; and CHAP response, computed
-   according to the CHAP algorithm.
-
-   Upon receipt of these AVPs from the client, the server must verify
-   that the value of the CHAP-Challenge AVP and the value of the CHAP
-   Identifier in the CHAP-Password AVP are equal to the values generated
-   as challenge material.  If either item does not match, the server
-   must reject the client.  Otherwise, it validates the CHAP-Challenge
-   to determine the result of the authentication.
-
-4.2.3.  MS-CHAP
-
-   The MS-CHAP algorithm is described in [RFC2433]; RADIUS attribute
-   formats are described in [RFC2548].
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 23]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   Both client and server generate 9 octets of challenge material, using
-   the constant string "inner application challenge" as described above.
-   These octets are used as follows:
-      MS-CHAP-Challenge [8 octets]
-      Ident [1 octet]
-
-   The client initiates MS-CHAP by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP-Response AVPs in the first ApplicationPayload
-   message in any application phase.  The MS-CHAP-Challenge value is
-   taken from the challenge material.  The MS-CHAP-Response consists of
-   Ident, taken from the challenge material; Flags, set according the
-   client preferences; and LM-Response and NT-Response, computed
-   according to the MS-CHAP algorithm.
-
-   Upon receipt of these AVPs from the client, the server must verify
-   that the value of the MS-CHAP-Challenge AVP and the value of the
-   Ident in the client's MS-CHAP-Response AVP are equal to the values
-   generated as challenge material.  If either item does not match
-   exactly, the server must reject the client.  Otherwise, it validates
-   the MS-CHAP-Challenge to determine the result of the authentication.
-
-4.2.4.  MS-CHAP-V2
-
-   The MS-CHAP-V2 algorithm is described in [RFC2759]; RADIUS attribute
-   formats are described in [RFC2548].
-
-   Both client and server generate 17 octets of challenge material,
-   using the constant string "inner application challenge" as described
-   above.  These octets are used as follows:
-      MS-CHAP-Challenge [16 octets]
-      Ident [1 octet]
-
-   The client initiates MS-CHAP-V2 by including User-Name, MS-CHAP-
-   Challenge and MS-CHAP2-Response AVPs in the first ApplicationPayload
-   message in any application phase.  The MS-CHAP-Challenge value is
-   taken from the challenge material.  The MS-CHAP2-Response consists of
-   Ident, taken from the challenge material; Flags, set to 0; Peer-
-   Challenge, set to a random value; and Response, computed according to
-   the MS-CHAP-V2 algorithm.
-
-   Upon receipt of these AVPs from the client, the server must verify
-   that the value of the MS-CHAP-Challenge AVP and the value of the
-   Ident in the client's MS-CHAP2-Response AVP are equal to the values
-   generated as challenge material.  If either item does not match
-   exactly, the server must reject the client.  Otherwise, it validates
-   the MS-CHAP2-Challenge.
-
-   If the MS-CHAP2-Challenge received from the client is correct, the
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 24]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   server tunnels the MS-CHAP2-Success AVP to the client.
-
-   Upon receipt of the MS-CHAP2-Success AVP, the client is able to
-   authenticate the server.  In its next InnerApplicationPayload message
-   to the server, the client does not include any MS-CHAP-V2 AVPs.
-   (This may result in an empty InnerApplicationPayload if no other AVPs
-   need to be sent.)
-
-   If the MS-CHAP2-Challenge received from the client is not correct,
-   the server tunnels an MS-CHAP2-Error AVP to the client.  This AVP
-   contains a new Ident and a string with additional information such as
-   error reason and whether a retry is allowed.  If the error reason is
-   an expired password and a retry is allowed, the client may proceed to
-   change the user's password.  If the error reason is not an expired
-   password or if the client does not wish to change the user's
-   password, it issues an InnerApplicationFailure alert.
-
-   If the client does wish to change the password, it tunnels MS-CHAP-
-   NT-Enc-PW, MS-CHAP2-CPW, and MS-CHAP-Challenge AVPs to the server.
-   The MS-CHAP2-CPW AVP is derived from the new Ident and Challenge
-   received in the MS-CHAP2-Error AVP.  The MS-CHAP-Challenge AVP simply
-   echoes the new Challenge.
-
-   Upon receipt of these AVPs from the client, the server must verify
-   that the value of the MS-CHAP-Challenge AVP and the value of the
-   Ident in the client's MS-CHAP2-CPW AVP match the values it sent in
-   the MS-CHAP2-Error AVP.  If either item does not match exactly, the
-   server must reject the client.  Otherwise, it validates the MS-CHAP2-
-   CPW AVP.
-
-   If the MS-CHAP2-CPW AVP received from the client is correct, and the
-   server is able to change the user's password, the server tunnels the
-   MS-CHAP2-Success AVP to the client and the negotiation proceeds as
-   described above.
-
-   Note that additional AVPs associated with MS-CHAP-V2 may be sent by
-   the server; for example, MS-CHAP-Domain.  The server must tunnel such
-   authentication-related AVPs along with the MS-CHAP2-Success.
-
-4.2.5.  PAP
-
-   PAP RADIUS attribute formats are described in [RFC2865].
-
-   The client initiates PAP by including User-Name and User-Password
-   AVPs in the first ApplicationPayload message in any application
-   phase.
-
-   In RADIUS, User-Password is padded with nulls to a multiple of 16
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 25]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   octets, then encrypted using a shared secret and other packet
-   information.
-
-   A TLS/IA, however, does not RADIUS-encrypt the password since all
-   application phase data is already encrypted.  The client SHOULD,
-   however, null-pad the password to a multiple of 16 octets, to
-   obfuscate its length.
-
-   Upon receipt of these AVPs from the client, the server may be able to
-   decide whether to authenticate the client immediately, or it may need
-   to challenge the client for more information.
-
-   If the server wishes to issue a challenge to the client, it MUST
-   tunnel the Reply-Message AVP to the client; this AVP normally
-   contains a challenge prompt of some kind.  It may also tunnel
-   additional AVPs if necessary, such the Prompt AVP.  Upon receipt of
-   the Reply-Message AVPs, the client tunnels User-Name and User-
-   Password AVPs again, with the User-Password AVP containing new
-   information in response to the challenge.  This process continues
-   until the server determines the authentication has succeeded or
-   failed.
-
-4.3.  Performing Multiple Authentications
-
-   In some cases, it is desirable to perform multiple user
-   authentications.  For example, a server may want first to
-   authenticate the user by password, then by a hardware token.
-
-   The server may perform any number of additional user authentications
-   using EAP, simply by issuing a EAP-Request with a new protocol type
-   once the previous authentication has completed.
-
-   For example, a server wishing to perform MD5-Challenge followed by
-   Generic Token Card would first issue an EAP-Request/MD5-Challenge AVP
-   and receive a response.  If the response is satisfactory, it would
-   then issue EAP-Request/Generic Token Card AVP and receive a response.
-   If that response were also satisfactory, it would consider the user
-   authenticated.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 26]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-5.  Example Message Sequences
-
-   This section presents a variety of possible TLS/IA message sequences.
-   These examples are not meant to exhaustively depict all possible
-   scenarios.
-
-   Parentheses indicate optional TLS messages.  Brackets indicate
-   optional message exchanges.  An ellipsis (. . .) indicates optional
-   repetition of preceding messages.
-
-5.1.  Full Initial Handshake with Intermediate and Final Application
-      Phasess
-
-   The diagram below depicts a full initial handshake phase followed by
-   two application phases.
-
-   Note that the client concludes the intermediate phase and starts the
-   final phase in an uninterrupted sequence of three messages:
-   ChangeCipherSpec and PhaseFinished belong to the intermediate phase,
-   and ApplicationPayload belongs to the final phase.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 27]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-         Client                                               Server
-         ------                                               ------
-
-   *** TLS Handshake:
-         ClientHello                -------->
-                                                         ServerHello
-                                                       (Certificate)
-                                                   ServerKeyExchange
-                                                (CertificateRequest)
-                                     <--------      ServerHelloDone
-         (Certificate)
-         ClientKeyExchange
-         (CertificateVerify)
-         ChangeCipherSpec
-         Finished                   -------->
-                                                    ChangeCipherSpec
-                                    <--------        Finished
-
-   *** Intermediate Phase:
-         ApplicationPayload         -------->
-
-       [
-                                    <--------  ApplicationPayload
-
-         ApplicationPayload         -------->
-
-                                         ...
-       ]
-                                    <-------- IntermediatePhaseFinished
-         IntermediatePhaseFinished
-   *** Final Phase:
-         ApplicationPayload         -------->
-
-       [
-                                    <--------   ApplicationPayload
-
-         ApplicationPayload         -------->
-
-                                         ...
-       ]
-                                    <--------   FinalPhaseFinished
-
-         FinalPhaseFinished         -------->
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 28]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-5.2.  Resumed Session with Single Application Phase
-
-   The diagram below depicts a resumed session followed by a single
-   application phase.
-
-   Note that the client concludes the initial phase and starts the final
-   phase in an uninterrupted sequence of three messages:
-   ChangeCipherSpec and PhaseFinished belong to the initial phase, and
-   ApplicationPayload belongs to the final phase.
-
-
-         Client                                               Server
-         ------                                               ------
-
-   *** TLS Handshake:
-         ClientHello                  -------->
-                                                         ServerHello
-                                                    ChangeCipherSpec
-                                      <--------             Finished
-         ChangeCipherSpec
-         Finished
-   *** Final Phase:
-         ApplicationPayload           -------->
-
-       [
-                                      <--------   ApplicationPayload
-
-         ApplicationPayload           -------->
-
-                                         ...
-       ]
-                                      <--------   FinalPhaseFinished
-
-         FinalPhaseFinished           -------->
-
-
-
-5.3.  Resumed Session with No Application Phase
-
-   The diagram below depicts a resumed session without any subsequent
-   application phase.  This will occur if the client indicates in its
-   ClientInnerApplication message that no application phase is required
-   and the server concurs.  Note that this message sequence is identical
-   to that of a standard TLS resumed session.
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 29]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-         Client                                               Server
-         ------                                               ------
-
-   *** TLS Handshake:
-         ClientHello                  -------->
-                                                         ServerHello
-                                                    ChangeCipherSpec
-                                      <--------             Finished
-         ChangeCipherSpec
-         Finished                     -------->
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 30]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-6.  Security Considerations
-
-   This document introduces a new TLS extension called "Inner
-   Application".  When TLS is used with the Inner Application extension
-   (TLS/IA), additional messages are exchanged during the TLS handshake.
-   Hence a number of security issues need to be taken into
-   consideration.  Since the security heavily depends on the information
-   (called "applications") which are exchanged between the TLS client
-   and the TLS server as part of the TLS/IA extension we try to classify
-   them into two categories: The first category considers the case where
-   the exchange results in the generation of keying material.  This is,
-   for example, the case with certain EAP methods.  EAP is one of the
-   envisioned main "applications".  The second category focuses on cases
-   where no session key is generated.  The security treatment of the
-   latter category is discouraged since it is subject to man-in-the-
-   middle attacks if the two sessions cannot be bound to each other as
-   suggested in [MITM].
-
-   In the following, we investigate a number of security issues:
-
-   Architecture and Trust Model
-
-      For many of the use cases in this document we assume that three
-      functional entities participate in the protocol exchange: TLS
-      client, TLS server and a AAA infrastructure (typically consisting
-      of a AAA server and possibly a AAA broker).  The protocol exchange
-      described in this document takes place between the TLS client and
-      the TLS server.  The interaction between the AAA client (which
-      corresponds to the TLS server) and the AAA server is described in
-      the respective AAA protocol documents and therefore outside the
-      scope of this document.  The trust model behind this architecture
-      with respect to the authentication, authorization, session key
-      establishment and key transport within the AAA infrastructure is
-      discussed in [I-D.ietf-eap-keying].
-
-   Authentication
-
-      This document assumes that the TLS server is authenticated to the
-      TLS client as part of the authentication procedure of the initial
-      TLS Handshake.  This approach is similar to the one chosen with
-      the EAP support in IKEv2 (see [RFC4306].  Typically, public key
-      based server authentication is used for this purpose.  More
-      interesting is the client authentication property whereby
-      information exchanged as part of the Inner Application is used to
-      authenticate (or authorize) the client.  For example, if EAP is
-      used as an inner application then EAP methods are used to perform
-      authentication and key agreement between the EAP peer (most likely
-      the TLS client) and the EAP server (i.e., AAA server).
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 31]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   Authorization
-
-      Throughout this document it is assumed that the TLS server can be
-      authorized by the TLS client as a legitimate server as part of the
-      authentication procedure of the initial TLS Handshake.  The entity
-      acting as TLS client can be authorized either by the TLS server or
-      by the AAA server (if the authorization decision is offloaded).
-      Typically, the authenticated identity is used to compute the
-      authorization decision but credential-based authorization
-      mechanisms may be used as well.
-
-   Man-in-the-Middle Attack
-
-      Man-in-the-middle attacks have become a concern with tunneled
-      authentication protocols because of the discovered vulnerabilities
-      (see [MITM]) of a missing cryptographic binding between the
-      independent protocol sessions.  This document also proposes a
-      tunneling protocol, namely individual inner application sessions
-      are tunneled within a previously executed session.  The first
-      protocol session in this exchange is the initial TLS Handshake.
-      To avoid man-in-the-middle attacks a number of sections address
-      how to establish such a cryptographic binding (see Section 2.3).
-
-   User Identity Confidentiality
-
-      The TLS/IA extension allows splitting the authentication of the
-      TLS server from the TLS client into two separate sessions.  As one
-      of the advantages, this provides active user identity
-      confidentiality since the TLS client is able to authenticate the
-      TLS server and to establish a unilateral authenticated and
-      confidentiality-protected channel prior to starting the client-
-      side authentication.
-
-   Session Key Establishment
-
-      TLS [RFC2246] defines how session key material produced during the
-      TLS Handshake is generated with the help of a pseudo-random
-      function to expand it to keying material of the desired length for
-      later usage in the TLS Record Layer.  Section 2.3 gives some
-      guidelines with regard to the master key generation.  Since the
-      TLS/IA extension supports multiple exchanges whereby each phase
-      concludes with a generated keying material.  In addition to the
-      keying material established as part of TLS itself, most inner
-      applications will produce their keying material.  For example,
-      keying material established as part of an EAP method must be
-      carried from the AAA server to the AAA client.  Details are
-      subject to the specific AAA protocol (for example, EAP usage in
-      Diameter [I-D.ietf-aaa-eap]).
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 32]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-   Denial of Service Attacks
-
-      This document does not modify the initial TLS Handshake and as
-      such, does not introduce new vulnerabilities with regard to DoS
-      attacks.  Since the TLS/IA extension allows to postpone the
-      client-side authentication to a later stage in the protocol phase.
-      As such, it allows malicious TLS clients to initiate a number of
-      exchanges while remaining anonymous.  As a consequence, state at
-      the server is allocated and computational efforts are required at
-      the server side.  Since the TLS client cannot be stateless this is
-      not strictly a DoS attack.
-
-   Confidentiality Protection and Dictionary Attack Resistance
-
-      Similar to the user identity confidentiality property the usage of
-      the TLS/IA extension allows to establish a unilateral
-      authenticated tunnel which is confidentiality protected.  This
-      tunnel protects the inner application information elements to be
-      protected against active adversaries and therefore provides
-      resistance against dictionary attacks when password-based
-      authentication protocols are used inside the tunnel.  In general,
-      information exchanged inside the tunnel experiences
-      confidentiality protection.
-
-   Downgrading Attacks
-
-      This document defines a new extension.  The TLS client and the TLS
-      server indicate the capability to support the TLS/IA extension as
-      part of the client_hello_extension_list and the
-      server_hello_extension_list payload.  More details can be found in
-      Section 2.6.  To avoid downgrading attacks whereby an adversary
-      removes a capability from the list is avoided by the usage of the
-      Finish or PhaseFinished message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 33]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
-              October 1994.
-
-   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
-              Protocol (CHAP)", RFC 1994, August 1996.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC2433]  Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
-              RFC 2433, October 1998.
-
-   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
-              RFC 2486, January 1999.
-
-   [RFC2548]  Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
-              RFC 2548, March 1999.
-
-   [RFC2759]  Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
-              RFC 2759, January 2000.
-
-   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
-              "Remote Authentication Dial In User Service (RADIUS)",
-              RFC 2865, June 2000.
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 3546, June 2003.
-
-   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
-              Dial In User Service) Support For Extensible
-              Authentication Protocol (EAP)", RFC 3579, September 2003.
-
-   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
-              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
-
-   [RFC3784]  Smit, H. and T. Li, "Intermediate System to Intermediate
-              System (IS-IS) Extensions for Traffic Engineering (TE)",
-              RFC 3784, June 2004.
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 34]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-7.2.  Informative References
-
-   [I-D.ietf-aaa-eap]
-              Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
-              Authentication Protocol (EAP) Application",
-              draft-ietf-aaa-eap-10 (work in progress), November 2004.
-
-   [I-D.ietf-eap-keying]
-              Aboba, B., "Extensible Authentication Protocol (EAP) Key
-              Management Framework", draft-ietf-eap-keying-13 (work in
-              progress), May 2006.
-
-   [I-D.ietf-pppext-eap-ttls]
-              Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
-              Authentication Protocol (EAP-TTLS)",
-              draft-ietf-pppext-eap-ttls-05 (work in progress),
-              July 2004.
-
-   [I-D.ietf-tls-psk]
-              Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
-              (work in progress), June 2005.
-
-   [I-D.josefsson-pppext-eap-tls-eap]
-              Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
-              "Protected EAP Protocol (PEAP) Version 2",
-              draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
-              October 2004.
-
-   [MITM]     Asokan, N., Niemi, V., Nyberg, K., and W. Dixon, "Man-in-
-              the-Middle in Tunneled Authentication", October 2002.
-
-   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
-              RFC 1661, July 1994.
-
-   [RFC2716]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication
-              Protocol", RFC 2716, October 1999.
-
-   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              RFC 4306, December 2005.
-
-   [ieee]     "IEEE Standards for Local and Metropolitan Area Networks:
-              Port based Network Access Control", E Std 802.1X-2001,
-              June 2001.
-
-
-
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 35]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-Authors' Addresses
-
-   Paul Funk
-   Funk Software, Inc.
-   222 Third Street
-   Cambridge, MA  02142
-   USA
-
-   Phone: +1 617 497-6339
-   Email: paul@funk.com
-
-
-   Simon Blake-Wilson
-   Basic Commerce & Industries, Inc.
-   96 Spadina Ave, Unit 606
-   Toronto, Ontario  M5V 2J6
-   Canada
-
-   Phone: +1 416 214-5961
-   Email: sblakewilson@bcisse.com
-
-
-   Ned Smith
-   Intel Corporation.
-   2111 N.E. 25th Ave.
-   Hillsboro, OR  97124
-   USA
-
-   Phone: +1 503 264-2692
-   Email: ned.smith@intel.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bavaria  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-   URI:   http://www.tschofenig.com
-
-
-   Thomas Hardjono
-   Verisign Inc
-
-
-   Email: thomas@signacert.com
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 36]
-
-Internet-Draft            TLS inner Application                June 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Funk, et al.            Expires December 27, 2006              [Page 37]
-
-
diff --git a/doc/protocol/draft-hajjeh-tls-identity-protection-00.txt b/doc/protocol/draft-hajjeh-tls-identity-protection-00.txt
deleted file mode 100644
index a9b65adb2c..0000000000
--- a/doc/protocol/draft-hajjeh-tls-identity-protection-00.txt
+++ /dev/null
@@ -1,505 +0,0 @@
-
- 
-
-Internet Engineering Task Force                               I. Hajjeh 
-                                                              ESRGroups 
-                                                               M. Badra 
-                                                       ISIMA Laboratory 
-    
-Expires: April 2007                                      November, 2006 
-    
-       Identity Protection Ciphersuites for Transport Layer Security 
-                <draft-hajjeh-tls-identity-protection-00.txt> 
-    
-    
-Status of this Memo 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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. 
-    
-   This Internet-Draft will expire on April 2007. 
-    
-   Copyright Notice 
-    
-   Copyright (C) The Internet Society (2006). All Rights Reserved. 
-    
-Abstract 
-    
-   TLS defines several ciphersuites providing authentication, data 
-   protection and session key exchange between two communicating 
-   entities. Some of these ciphersuites are used for completely 
-   anonymous key exchange, in which neither party is authenticated. 
-   However, they are vulnerable to man-in-the-middle attacks and are 
-   therefore deprecated. 
-    
-   This document defines a set of ciphersuites to add client identity 
-   protection to the Transport Layer Security (TLS) protection. 
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 1] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-1. Introduction 
-    
-   TLS is the most deployed security protocol for securing exchanges. 
-   It provides end-to-end secure communications between two entities 
-   with authentication and data protection. 
-    
-   TLS supports three authentication modes: authentication of both 
-   parties, only server-side authentication, and anonymous key 
-   exchange. For each mode, TLS specifies a set of ciphersuites. 
-   However, anonymous ciphersuites are strongly discouraged because 
-   they cannot prevent man-in-the-middle attacks. 
-    
-   Client identity protection may be established by changing the order 
-   of the messages that the client sends after receiving 
-   ServerHelloDone [CORELLA]. This is done by sending the 
-   ChangeCipherSpec message before the Certificate and the 
-   CertificateVerify messages and after the ClientKeyExchange message. 
-   However, it requires a major change to TLS machine state as long as 
-   a new TLS version. 
-    
-   Client identity protection may also be done through a EDH exchange 
-   before establishing an ordinary handshake with identity information 
-   [RESCORLA]. This wouldn't however be secure enough against active 
-   attackers and wouldn't be favorable for some environments (e.g. 
-   mobile), due to the additional cryptographic computations. 
-    
-   Client identity protection may be also possible, assuming that the 
-   client permits renegotiation after the first server authentication. 
-   However, this requires more cryptographic computations and augments 
-   significantly the number of rounds trips. 
-    
-   Finally, client identity protection may be realized by exchanging a 
-   TLS extension that negotiates the symmetric encryption algorithm to 
-   be used for client certificate encrypting/decrypting [EAPTLSIP]. 
-   This solution may suffer from interoperability issues related to TLS 
-   Extensions, TLS 1.0 and TLS 1.1 implementations, as described in 
-   [INTEROP]. 
-    
-   This document defines a set of ciphersuites to add client identity 
-   protection to TLS protocol. Client identity protection is provided 
-   by symmetrically encrypting the client certificate with a key 
-   derived from the SecurityParameters.master_secret, 
-   SecurityParameters.server_random and 
-   SecurityParameters.client_random. The symmetric encryption algorithm 
-   is set to the cipher algorithm of the ServerHello.cipher_suite. 
-    
-1.2. Requirements language 
-    
-   The key words "MUST", "MUST NOT" and "MAY" in this document are to 
-   be interpreted as described in RFC-2119. 
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 2] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-2. TLS Identity Protection overview 
-    
-   This document specifies a set of ciphersuites for TLS. These 
-   ciphersuites reuse existing key exchange algorithms that require 
-   based-certificates authentication, and reuse also existing MAC, 
-   stream and bloc ciphers algorithms from [TLS] and [TLSCTR], 
-   [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "IP" 
-   to refer to the client identity protection. An example is shown 
-   below. 
-    
-   CipherSuite                          Key Exchange  Cipher       Hash 
-    
-   TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5    RSA           RC4 40       MD5 
-   TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA  DHE           AES 128_CBC  SHA 
-    
-   If the client has not a certificate with a type appropriate for one 
-   of the supported cipher key exchange algorithms or if the client 
-   will not be able to send such a certificate, it MUST NOT include any 
-   ciphersuite with client identity protection in the 
-   ClientHello.cipher_suites. 
-    
-   If the server selects a ciphersuite with client identity protection, 
-   the server MUST request a certificate from the client. 
-    
-   If the server selects one of the ciphersuites defined in this 
-   document, the client MUST encrypt its certificate using the 
-   symmetric algorithm selected by the server from the list in 
-   ClientHello.cipher_suites and a key derived from the 
-   SecurityParameters.master_secret (see section 3 for the key 
-   computation). 
-    
-   In the case of DH_DSS and DH_RSA ciphersuites with client 
-   authentication, the ClientKeyExchange message always contains 
-   explicit Diffie-Hellman public value and it is possible to correlate 
-   sessions by the same client. Consequently, DH_DSS and DH_RSA are not 
-   currently omitted from this document. 
-    
-   For EDH, the client MUST explicitly send its EDH public value in the 
-   ClientKeyExchange message. 
-
-
-
-
-
-
-
-
-
-
-
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 3] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-         Client                                        Server 
-    
-         ClientHello          --------> 
-                                                  ServerHello 
-                                                  Certificate 
-                                            ServerKeyExchange* 
-                                           CertificateRequest 
-                              <--------       ServerHelloDone 
-         ClientKeyExchange 
-        {Certificate} 
-         CertificateVerify 
-        [ChangeCipherSpec] 
-         Finished             --------> 
-                                            [ChangeCipherSpec] 
-                              <--------              Finished 
-         Application Data     <------->      Application Data 
-    
-   * Indicates optional or situation-dependent messages that are not 
-   always sent. 
-   {} Indicates messages that are symmetrically encrypted. 
-    
-   The ciphersuites in Section 4 (IP_RSA Key Exchange Algorithm) use 
-   RSA based certificates to mutually authenticate a RSA exchange with 
-   the client identity protection. 
-   The ciphersuites in Section 5 (IP_EDH Key Exchange Algorithm) use 
-   EDH_RSA or EDH_DSS to mutually authenticate a Diffie-Hellman 
-   exchange with the client identity protection. 
-    
-   The ciphersuites in Section 6 (IP_ECC Key Exchange Algorithm) are 
-   TBC. 
-    
-3. Key computation to encrypt/decrypt client's certificate 
-    
-   Before sending its certificate, the client is able to compute the 
-   master secret and then the key_block. Thus, the client and the 
-   server derive from the key_block a key called 
-   identity_protection_key. This key is deployed by the client 
-   (respectively the server) to encrypt (respectively decrypt) the 
-   client's certificate. 
-    
-   The identity_protection_key is set to the low order bits of the 
-   key_block, and its length is set appropriately to 
-   ServerHello.cipher_suite. For example, if the client and the server 
-   have agreed on using a ciphersuite with RC4_128 as symmetric 
-   cryptography, they therefore set their key to the low order 128-bits 
-   of the key_block. 
-    
-   Exportable encryption algorithms (for which CipherSpec.is_exportable 
-   is true) require additional processing as follows to derive their 
-   final identity_protection_key: 
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 4] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-    
-          final_identity_protection_key = 
-          PRF(SecurityParameters.identity_protection_key, 
-                                     "identity_protection_key", 
-                                     SecurityParameters.client_random + 
-                                     SecurityParameters.server_random); 
-    
-4. IP_RSA Key Exchange Algorithm 
-    
-   This section defines additional ciphersuites that use RSA based 
-   certificates to authenticate a RSA exchange. These ciphersuites give 
-   client identity protection. 
-    
-   CipherSuite                      Key Exchange  Cipher           Hash 
-    
-   TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5     RSA      RC4_40            MD5 
-   TLS_IP_RSA_WITH_RC4_128_MD5           RSA      RC4_128           MD5 
-   TLS_IP_RSA_WITH_RC4_128_SHA           RSA      RC4_128           SHA 
-   TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA      RC2_CBC_40        MD5 
-   TLS_IP_RSA_WITH_IDEA_CBC_SHA          RSA      IDEA_CBC          SHA 
-   TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA  RSA      DES40_CBC_        SHA 
-   TLS_IP_RSA_WITH_DES_CBC_SHA           RSA      DES_CBC           SHA 
-   TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA      RSA      3DES_EDE          SHA 
-   TLS_IP_RSA_WITH_AES_128_CBC_SHA       RSA      AES_128_CBC       SHA 
-   TLS_IP_RSA_WITH_AES_256_CBC_SHA       RSA      AES_256_CBC       SHA 
-   TLS_IP_RSA_WITH_AES_128_CTR_SHA       RSA      AES_128_CTR       SHA 
-   TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA  RSA      CAMELLIA_128_CBC  SHA 
-   TLS_IP_RSA_WITH_AES_256_CTR_SHA       RSA      AES_256_CTR       SHA 
-   TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA  RSA      CAMELLIA_256_CBC  SHA 
-    
-5. IP_EDH Key Exchange Algorithm 
-    
-   This section defines additional ciphersuites that use EDH with RSA 
-   or DSS based certificates to authenticate a Diffie-Hellman exchange. 
-   These ciphersuites give client identity protection. 
-    
-   The client MUST explicitly send its EDH public value in the 
-   ClientKeyExchange message. 
-    
-   Note that this document does not specify any CipherSpec that uses DH 
-   RSA or DSS based certificates. 
-    
-   CipherSuite                      Key Exchange  Cipher           Hash 
-    
-   TLS_IP_DHE_DSS_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
-   TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
-   TLS_IP_DHE_RSA_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
-   TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
-   TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 
-   TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 5] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-   TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
-   TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
-   TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
-   TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
-   TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
-   TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
-   TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
-   TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
-   TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
-   TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
-    
-6. IP_ECC Key Exchange Algorithm 
-    
-   TBC. 
- 
-7. Security Considerations 
-    
-   The security considerations described throughout [TLS], [DTLS], 
-   [TLS1.1], [TLSAES] and [TLSAES] apply here as well. 
-    
-8. IANA Considerations 
-    
-   This section provides guidance to the IANA regarding registration of 
-   values related to the identity protection ciphersuites. 
-    
-   CipherSuite TLS_IP_RSA_EXPORT_WITH_RC4_40_MD5       = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_RC4_128_MD5             = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_RC4_128_SHA             = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_EXPORT_WITH_RC2_CBC_40_MD5   = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_IDEA_CBC_SHA            = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_EXPORT_WITH_DES40_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_DES_CBC_SHA             = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_3DES_EDE_CBC_SHA        = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_AES_128_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_AES_256_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_AES_128_CTR_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_CAMELLIA_128_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_AES_256_CTR_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_RSA_WITH_CAMELLIA_256_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_RSA_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 6] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-   CipherSuite TLS_IP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_RSA_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_DSS_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_IP_DHE_RSA_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
-    
-   Note: For implementation and deployment facilities, it is helpful to 
-   reserve a specific registry sub-range (minor, major) for identity 
-   protection ciphersuites. 
-    
-References 
-    
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",  
-              RFC 2246, January 1999. 
-    
-   [TLS1.1]   Dierks, T. and E. Rescorla, "The TLS Protocol Version  
-              1.1", RFC 4346, April 2005. 
-    
-   [DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer  
-              Security", RFC 4347, April 2006. 
-    
-   [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia  
-              Cipher Suites to Transport Layer Security (TLS)",  
-              RFC 4132, July 2005. 
-    
-   [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)  
-              Ciphersuites for Transport Layer Security (TLS)",  
-              RFC 3268, June 2002. 
-    
-   [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,  
-              Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher  
-              Suites for Transport Layer Security (TLS)", RFC 4492, May  
-              2006 
-    
-   [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher  
-              Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work  
-              in progress), June 2006. 
-    
-   [EAPTLSIP] Urien, P. and M. Badra, "Identity Protection within EAP- 
-              TLS",  
-              draft-urien-badra-eap-tls-identity-protection-01.txt  
-              (work in progress), October 2006. 
-    
-   [INTEROP]  Pettersen, Y., "Clientside interoperability  
-              experiences for the SSL and TLS protocols", draft-ietf- 
-              tls-interoperability-00 (work in progress), October 2006. 
-    
-   [CORELLA]  Corella, F., "adding client identity protection to TLS",  
-              message on ietf-tls@lists.certicom.com mailing list,  
-              http://www.imc.org/ietf-tls/mail-archive/msg02004.html,  
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 7] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-              August 2000. 
-    
-   [RESCORLA] Rescorla, E., "SSL and TLS: Designing and Building Secure  
-              Systems", Addison-Wesley, March 2001. 
-    
-Author's Addresses 
-    
-   Ibrahim Hajjeh 
-   ESRGroups, Security WG 
-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
-    
-   Mohamad Badra 
-   LIMOS Laboratory - UMR (6158), CNRS 
-   France                    Email: badra@isima.fr 
-    
-   Intellectual Property Statement 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights. 
-   Information on the IETF's procedures with respect to rights in IETF 
-   Documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Disclaimer of Validity 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-   Copyright Statement 
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 8] 
- 
-Internet-draft  Identity Protection Ciphersuites for TLS  November 2006 
- 
-    
-   Copyright (C) The Internet Society (2006). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   Acknowledgment 
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
-Hajjeh & Badra             Expires April 2007                  [Page 9] 
\ No newline at end of file
diff --git a/doc/protocol/draft-hajjeh-tls-identity-protection-01.txt b/doc/protocol/draft-hajjeh-tls-identity-protection-01.txt
deleted file mode 100644
index b16c81fb9a..0000000000
--- a/doc/protocol/draft-hajjeh-tls-identity-protection-01.txt
+++ /dev/null
@@ -1,506 +0,0 @@
-
- 
-
-Internet Engineering Task Force                               I. Hajjeh 
-                                                              ESRGroups 
-                                                               M. Badra 
-                                                       LIMOS Laboratory 
-    
-Expires: November 2007                                       June, 2007 
-    
-       Credential Protection Ciphersuites for Transport Layer Security 
-                <draft-hajjeh-tls-identity-protection-01.txt> 
-    
-    
-Status of this Memo 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet- 
-   Drafts. 
-    
-   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  
-    
-   This Internet-Draft will expire on November 2007. 
-    
-Copyright Notice 
-    
-  Copyright (C) The IETF Trust (2007).  
-    
-Abstract 
-    
-   TLS defines several ciphersuites providing authentication, data 
-   protection and session key exchange between two communicating 
-   entities. Some of these ciphersuites are used for completely 
-   anonymous key exchange, in which neither party is authenticated. 
-   However, they are vulnerable to man-in-the-middle attacks and are 
-   therefore deprecated. 
-    
-   This document defines a set of ciphersuites to add client credential 
-   protection to the Transport Layer Security (TLS) protocol. 
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 1] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-1. Introduction 
-    
-   TLS is the most deployed security protocol for securing exchanges. 
-   It provides end-to-end secure communications between two entities 
-   with authentication and data protection. 
-    
-   TLS supports three authentication modes: authentication of both 
-   parties, only server-side authentication, and anonymous key 
-   exchange. For each mode, TLS specifies a set of ciphersuites. 
-   However, anonymous ciphersuites are strongly discouraged because 
-   they cannot prevent man-in-the-middle attacks. 
-    
-   Client credential protection may be established by changing the 
-   order of the messages that the client sends after receiving 
-   ServerHelloDone [CORELLA]. This is done by sending the 
-   ChangeCipherSpec message before the Certificate and the 
-   CertificateVerify messages and after the ClientKeyExchange message. 
-   However, it requires a major change to TLS machine state as long as 
-   a new TLS version. 
-    
-   Client credential protection may also be done through a DHE exchange 
-   before establishing an ordinary handshake with identity information 
-   [RESCORLA]. This wouldn't however be secure enough against active 
-   attackers, which will be able to disclose the client's credentials 
-   and wouldn't be favorable for some environments (e.g. mobile), due 
-   to the additional cryptographic computations. 
-    
-   Client credential protection may be also possible, assuming that the 
-   client permits renegotiation after the first server authentication. 
-   However, this requires more cryptographic computations and augments 
-   significantly the number of rounds trips. 
-    
-   Client credential protection may as well be realized by exchanging a 
-   TLS extension that negotiates the symmetric encryption algorithm to 
-   be used for client certificate encrypting/decrypting [EAPTLSIP]. 
-   This solution may suffer from interoperability issues related to TLS 
-   Extensions, TLS 1.0 and TLS 1.1 implementations, as described in 
-   [INTEROP]. 
-    
-   This document defines a set of ciphersuites to add client credential 
-   protection to TLS protocol. Client credential protection is provided 
-   by symmetrically encrypting the client certificate with a key 
-   derived from the SecurityParameters.master_secret, 
-   SecurityParameters.server_random and 
-   SecurityParameters.client_random. The symmetric encryption algorithm 
-   is set to the cipher algorithm of the ServerHello.cipher_suite. 
-    
-1.2. Requirements language 
-    
-
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 2] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-   The key words "MUST", "MUST NOT" and "MAY" in this document are to 
-   be interpreted as described in RFC-2119. 
-    
-2. TLS credential protection overview 
-    
-   This document specifies a set of ciphersuites for TLS. These 
-   ciphersuites reuse existing key exchange algorithms that require 
-   based-certificates authentication, and reuse also existing MAC, 
-   stream and bloc ciphers algorithms from [TLS] and [TLSCTR], 
-   [TLSECC], [TLSAES] and [TLSCAM]. Their names include the text "CP" 
-   to refer to the client credential protection. An example is shown 
-   below. 
-    
-   CipherSuite                          Key Exchange  Cipher       Hash 
-    
-   TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5    RSA           RC4_40       MD5 
-   TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA  DHE           AES_128_CBC  SHA 
-    
-   If the client has not a certificate with a type appropriate for one 
-   of the supported cipher key exchange algorithms or if the client 
-   will not be able to send such a certificate, it MUST NOT include any 
-   ciphersuite with client credential protection in the 
-   ClientHello.cipher_suites. 
-    
-   If the server selects a ciphersuite with client credential 
-   protection, the server MUST request a certificate from the client. 
-    
-   If the server selects one of the ciphersuites defined in this 
-   document, the client MUST encrypt the Certificate and the 
-   CertificateVerify messages using the symmetric algorithm selected by 
-   the server from the list in ClientHello.cipher_suites and a key 
-   derived from the SecurityParameters.master_secret. This key is the 
-   same key used to encrypt data written by the client. 
-    
-   If a stream cipher encryption algorithm has been selected, the 
-   client symmetrically encrypts Certificate and CertificateVerify 
-   messages without any padding byte.  
-    
-   If a block cipher encryption algorithm has been selected, the client 
-   uses an explicit IV and adds padding value to force the length of 
-   the plaintext to be an integral multiple of the block cipher's block 
-   length, as it is described in section 6.2.3.2 of [TLS1.1].  
-    
-   For DHE key exchange algorithm, the client always sends the 
-   ClientKeyExchange message conveying its ephemeral DH public key Yc. 
-    
-   For ECDHE key exchange algorithm, the client always sends the 
-   ClientKeyExchange message conveying its ephemeral ECDH public key 
-   Yc. 
-    
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 3] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-   Current TLS specifications note that if the client certificate 
-   already contains a suitable DH or ECDH public key, then Yc is 
-   implicit and does not need to be sent again and consequently, the 
-   client key exchange message will be sent, but it MUST be empty. 
-   Implementations of this document MUST send ClientKeyExchange message 
-   but always carrying the client Yc, whatever the PublicValueEncoding 
-   is implicit or explicit. Note that it is possible to correlate 
-   sessions by the same client when DH or ECDH are in use. 
-    
-         Client                                        Server 
-    
-         ClientHello          --------> 
-                                                  ServerHello 
-                                                  Certificate 
-                                            ServerKeyExchange* 
-                                           CertificateRequest 
-                              <--------       ServerHelloDone 
-        {Certificate} 
-         ClientKeyExchange 
-        {CertificateVerify} 
-        [ChangeCipherSpec] 
-         Finished             --------> 
-                                            [ChangeCipherSpec] 
-                              <--------              Finished 
-         Application Data     <------->      Application Data 
-    
-   * Indicates optional or situation-dependent messages that are not 
-   always sent. 
-   {} Indicates messages that are symmetrically encrypted. 
-    
-   The ciphersuites in Section 3 (CP_RSA Key Exchange Algorithm) use 
-   RSA based certificates to mutually authenticate a RSA exchange with 
-   the client credential protection. 
-    
-   The ciphersuites in Section 4 (CP_DHE and CP_DH Key Exchange 
-   Algorithm) use DHE_RSA, DH_RSA, DHE_DSS or DH_DSS to mutually 
-   authenticate a (Ephemeral) Diffie-Hellman exchange. 
-    
-   The ciphersuites in Section 5 (CP_ECDH and CP_ECDHE Key Exchange 
-   Algorithms) use ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA or ECDHE_RSA to 
-   mutually authenticate a (Ephemeral) EC Diffie-Hellman exchange. 
-    
-3. CP_RSA Key Exchange Algorithm 
-    
-   This section defines additional ciphersuites that use RSA based 
-   certificates to authenticate a RSA exchange. These ciphersuites give 
-   client credential protection. 
-    
-   CipherSuite                      Key Exchange  Cipher           Hash 
-    
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 4] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-   TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5     RSA      RC4_40            MD5 
-   TLS_CP_RSA_WITH_RC4_128_MD5           RSA      RC4_128           MD5 
-   TLS_CP_RSA_WITH_RC4_128_SHA           RSA      RC4_128           SHA 
-   TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5 RSA      RC2_CBC_40        MD5 
-   TLS_CP_RSA_WITH_IDEA_CBC_SHA          RSA      IDEA_CBC          SHA 
-   TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA  RSA      DES40_CBC_        SHA 
-   TLS_CP_RSA_WITH_DES_CBC_SHA           RSA      DES_CBC           SHA 
-   TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA      RSA      3DES_EDE          SHA 
-   TLS_CP_RSA_WITH_AES_128_CBC_SHA       RSA      AES_128_CBC       SHA 
-   TLS_CP_RSA_WITH_AES_256_CBC_SHA       RSA      AES_256_CBC       SHA 
-   TLS_CP_RSA_WITH_AES_128_CTR_SHA       RSA      AES_128_CTR       SHA 
-   TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA  RSA      CAMELLIA_128_CBC  SHA 
-   TLS_CP_RSA_WITH_AES_256_CTR_SHA       RSA      AES_256_CTR       SHA 
-   TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA  RSA      CAMELLIA_256_CBC  SHA 
-    
-4. CP_DHE and CP_DH Key Exchange Algorithms 
-    
-   This section defines additional ciphersuites that use DH and DHE as 
-   key exchange algorithms, with RSA or DSS based certificates to 
-   authenticate a (Ephemeral) Diffie-Hellman exchange. These 
-   ciphersuites give client credential protection. 
-    
-   CipherSuite                      Key Exchange  Cipher           Hash 
-    
-   TLS_CP_DHE_DSS_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
-   TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
-   TLS_CP_DHE_RSA_WITH_DES_CBC_SHA          DHE   DES_CBC           SHA 
-   TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE   3DES_EDE_CBC      SHA 
-   TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA      DHE   AES_128_CBC       SHA 
-   TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA      DHE   AES_256_CBC       SHA 
-   TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
-   TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA DHE   CAMELLIA_128_CBC  SHA 
-   TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
-   TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA DHE   CAMELLIA_256_CBC  SHA 
-   TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA      DHE   AES_128_CTR       SHA 
-   TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA      DHE   AES_256_CTR       SHA 
-   TLS_CP_DH_DSS_WITH_DES_CBC_SHA           DH    DES_CBC           SHA 
-   TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA      DH    3DES_EDE_CBC      SHA  
-   TLS_CP_DH_RSA_WITH_DES_CBC_SHA           DH    DES_CBC           SHA  
-   TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA      DH    3DES_EDE_CBC      SHA  
-   TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA       DH    AES_128_CBC       SHA 
-   TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA       DH    AES_128_CBC       SHA 
-   TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA       DH    AES_256_CBC       SHA 
-   TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA       DH    AES_256_CBC       SHA 
-    
-
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 5] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-5. CP_ECDH and CP_ECDHE Key Exchange Algorithm 
-    
-   This section defines additional ciphersuites that use ECDH and ECDHE 
-   as key exchange algorithms, with RSA or ECDSA based certificates to 
-   authenticate a (Ephemeral) ECDH exchange. These ciphersuites give 
-   client credential protection. 
-    
-   CipherSuite                          Key Exchange Cipher        Hash 
-    
-   TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA        ECDH    RC4_128_      SHA 
-   TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   ECDH    3DES_EDE_CBC  SHA 
-   TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA    ECDH    AES_128_CBC   SHA 
-   TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA    ECDHE   AES_256_CBC   SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA       ECDHE   RC4_128       SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  ECDHE   3DES_EDE_CBC  SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   ECDHE   AES_128_CBC   SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDHE   AES_256_CBC   SHA 
-   TLS_CP_ECDH_RSA_WITH_RC4_128_SHA          ECDH    RC4_128       SHA 
-   TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     ECDH    3DES_EDE_CBC  SHA 
-   TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA      ECDH    AES_256_CBC   SHA 
-   TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA      ECDH    AES_256_CBC   SHA 
-   TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA         ECDHE   RC4_128       SHA 
-   TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    ECDHE   3DES_EDE_CBC  SHA 
-   TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA     ECDHE   AES_256_CBC   SHA 
-   TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA     ECDHE   AES_256_CBC   SHA 
- 
-6. Security Considerations 
-    
-   The security considerations described throughout [TLS], [DTLS], 
-   [TLS1.1], [TLSAES], [TLSECC] and [TLSAES] apply here as well. 
-    
-7. IANA Considerations 
-    
-   This section provides guidance to the IANA regarding registration of 
-   values related to the credential protection ciphersuites. 
-    
-   CipherSuite TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5       = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5             = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA             = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5   = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_IDEA_CBC_SHA            = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_DES_CBC_SHA             = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA        = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_128_CTR_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_256_CTR_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA    = { 0xXX,0xXX }; 
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 6] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-   CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_DES_CBC_SHA         = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_DES_CBC_SHA          = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_DES_CBC_SHA          = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA      = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA      = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA      = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA      = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA      = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA  = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA  = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA     = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA= { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_RC4_128_SHA        = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA   = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA    = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA       = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA  = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA   = { 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA   = { 0xXX,0xXX }; 
-    
-   Note: For implementation and deployment facilities, it is helpful to 
-   reserve a specific registry sub-range (minor, major) for credential 
-   protection ciphersuites. 
-    
-8. References 
-    
-8.1. Normative References 
-    
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",  
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 7] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-              RFC 2246, January 1999. 
-    
-   [TLS1.1]   Dierks, T. and E. Rescorla, "The TLS Protocol Version  
-              1.1", RFC 4346, April 2005. 
-    
-   [DTLS]     Rescorla, E. and N. Modadugu, "Datagram Transport Layer  
-              Security", RFC 4347, April 2006. 
-    
-   [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia  
-              Cipher Suites to Transport Layer Security (TLS)",  
-              RFC 4132, July 2005. 
-    
-   [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)  
-              Ciphersuites for Transport Layer Security (TLS)",  
-              RFC 3268, June 2002. 
-    
-   [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,  
-              Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher  
-              Suites for Transport Layer Security (TLS)", RFC 4492, May  
-              2006 
-    
-   [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher  
-              Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work  
-    
-8.1. Informative References 
-    
-   [RESCORLA] Rescorla, E., "SSL and TLS: Designing and Building Secure  
-              Systems", Addison-Wesley, March 2001. 
-    
-   [CORELLA]  Corella, F., "adding client identity protection to TLS",  
-              message on ietf-tls@lists.certicom.com mailing list,  
-              http://www.imc.org/ietf-tls/mail-archive/msg02004.html,  
-              August 2000. 
-    
-   [INTEROP]  Pettersen, Y., "Clientside interoperability  
-              experiences for the SSL and TLS protocols", draft-ietf- 
-              tls-interoperability-00 (work in progress), October 2006. 
-              in progress), June 2006. 
-    
-   [EAPTLSIP] Urien, P. and M. Badra, "Identity Protection within EAP- 
-              TLS",  
-              draft-urien-badra-eap-tls-identity-protection-01.txt  
-              (work in progress), October 2006. 
-    
-Author's Addresses 
-    
-   Ibrahim Hajjeh 
-   ESRGroups, Security WG 
-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
-    
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 8] 
- 
-Internet-draft  Credential protection Ciphersuites for TLS    June 2007 
- 
-   Mohamad Badra 
-   LIMOS Laboratory - UMR (6158), CNRS 
-   France                    Email: badra@isima.fr 
-    
-   Full Copyright Statement 
-    
-   Copyright (C) The IETF Trust (2007). 
-    
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-    
-   Intellectual Property 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Acknowledgement 
-    
-   Funding for the RFC Editor function is provided by the IETF 
-   Administrative Support Activity (IASA). 
-
-
-
- 
-Hajjeh & Badra          Expires November 2007                  [Page 9] 
\ No newline at end of file
diff --git a/doc/protocol/draft-hajjeh-tls-identity-protection-02.txt b/doc/protocol/draft-hajjeh-tls-identity-protection-02.txt
deleted file mode 100644
index e9ddc64d65..0000000000
--- a/doc/protocol/draft-hajjeh-tls-identity-protection-02.txt
+++ /dev/null
@@ -1,592 +0,0 @@
-Working Group Name                                          I. Hajjeh 
-Internet Draft                                             INEOVATION 
-                                                             M. Badra 
-                                                     LIMOS Laboratory 
-Intended status: Experimental                       December 13, 2007 
-Expires: June 2008 
-                                   
- 
-                                      
-      Credential Protection Ciphersuites for Transport Layer Security 
-                draft-hajjeh-tls-identity-protection-02.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on June 13, 2007. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2007). 
-
-Abstract 
-
-   TLS defines several ciphersuites providing authentication, data 
-   protection and session key exchange between two communicating 
-   entities. Some of these ciphersuites are used for completely 
-   anonymous key exchange, in which neither party is authenticated. 
- 
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 1] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-   However, they are vulnerable to man-in-the-middle attacks and are 
-   therefore deprecated.  
-
-   This document defines a set of ciphersuites to add client credential 
-   protection to the Transport Layer Security (TLS) protocol.  
-
-Table of Contents 
-
-    
-   1. Introduction................................................2 
-   2. TLS credential protection overview..........................3 
-   3. CP_RSA Key Exchange Algorithm...............................5 
-   4. CP_DHE and CP_DH Key Exchange Algorithms....................6 
-   5. CP_ECDH and CP_ECDHE Key Exchange Algorithm.................6 
-   6. Security Considerations.....................................7 
-   7. IANA Considerations.........................................7 
-   8. References..................................................9 
-      8.1. Normative References...................................9 
-      8.2. Informative References.................................9 
-   Author's Addresses............................................10 
-   Intellectual Property Statement...............................10 
-   Disclaimer of Validity........................................10 
-    
-1. Introduction 
-
-   TLS is the most deployed security protocol for securing exchanges. It 
-   provides end-to-end secure communications between two entities with 
-   authentication and data protection.  
-
-   TLS supports three authentication modes: authentication of both 
-   parties, only server-side authentication, and anonymous key exchange. 
-   For each mode, TLS specifies a set of ciphersuites. However, 
-   anonymous ciphersuites are strongly discouraged because they cannot 
-   prevent man-in-the-middle attacks.  
-
-   Client credential protection may be established by changing the order 
-   of the messages that the client sends after receiving ServerHelloDone 
-   [CORELLA]. This is done by sending the ChangeCipherSpec message 
-   before the Certificate and the CertificateVerify messages and after 
-   the ClientKeyExchange message. However, it requires a major change to 
-   TLS machine state as long as a new TLS version.  
-
-   Client credential protection may also be done through a DHE exchange 
-   before establishing an ordinary handshake with identity information 
-   [SSLTLS]. This wouldn't however be secure enough against active 
-   attackers, which will be able to disclose the client's credentials 
-
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 2] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-   and wouldn't be favorable for some environments (e.g. mobile), due to 
-   the additional cryptographic computations.  
-
-   Client credential protection may also be possible, assuming that the 
-   client permits renegotiation after the first server authentication 
-   [TLS]. However, this requires more cryptographic computations and 
-   augments significantly the number of rounds trips. In fact, 
-   renegotiation refers back to an asymmetric encryption/decryption and 
-   to a full previously certificate chain verified public key, whose 
-   chain was verified properly during the first handshake and stored in 
-   the client session context. In addition, computation overhead 
-   increases due to all second handshake messages encryption/decryption. 
-   Where for round trips, their number increases dramatically when small 
-   data packets are used to convey TLS messages. Furthermore, it is 
-   mandatory for the server to complete a first TLS handshake before it 
-   becomes able to confirm if the client has a certificate or not.  
-
-   Client credential protection may as well be realized by exchanging a 
-   TLS extension that negotiates the symmetric encryption algorithm to 
-   be used for client certificate encrypting/decrypting [EAPIP]. This 
-   solution may suffer from interoperability issues related to TLS 
-   Extensions, TLS 1.0 and TLS 1.1 implementations, as described in 
-   [INTEROP].  
-
-   This document defines a set of ciphersuites to add client credential 
-   protection to TLS protocol. Client credential protection is provided 
-   by symmetrically encrypting the client certificate with a key derived 
-   from the SecurityParameters.master_secret, 
-   SecurityParameters.server_random and 
-   SecurityParameters.client_random. The symmetric encryption algorithm 
-   is set to the cipher algorithm of the ServerHello.cipher_suite. 
-
-1.1. 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 [RFC2119]. 
-
-2. TLS credential protection overview 
-
-   This document specifies a set of ciphersuites for TLS. These 
-   ciphersuites reuse existing key exchange algorithms that require 
-   based-certificates authentication, and reuse also existing MAC, and 
-   bloc ciphers algorithms from [TLS] and [TLSCTR], [TLSECC], [TLSAES] 
-   and [TLSCAM]. Their names include the text "CP" to refer to the 
-   client credential protection. An example is shown below.  
-
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 3] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-   CipherSuite                         Key Exchange   Cipher        Hash 
-   TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5   RSA            RC4_40        MD5 
-   TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA DHE            AES_128_CBC   SHA 
-
-   If the client has not a certificate with a type appropriate for one 
-   of the supported cipher key exchange algorithms or if the client will 
-   not be able to send such a certificate, the client MUST NOT include 
-   any credential protection ciphersuite in the 
-   ClientHello.cipher_suites.  
-
-   If the server selects a ciphersuite with client credential 
-   protection, the server MUST request a certificate from the client. 
-
-   If the server selects one of the ciphersuites defined in this 
-   document, the client MUST encrypt the Certificate and the 
-   CertificateVerify messages using the symmetric algorithm selected by 
-   the server from the list in ClientHello.cipher_suites and a key 
-   derived from the SecurityParameters.master_secret. This key is the 
-   same key used to encrypt data written by the client. 
-
-   If a stream cipher encryption algorithm has been selected, the client 
-   symmetrically encrypts Certificate and CertificateVerify messages 
-   without any padding byte. 
-
-   If a block cipher encryption algorithm has been selected, the client 
-   uses an explicit IV and adds padding value to force the length of the 
-   plaintext to be an integral multiple of the block cipher's block 
-   length, as it is described in section 6.2.3.2 of [TLS]. 
-
-   For DHE key exchange algorithm, the client always sends the 
-   ClientKeyExchange message conveying its ephemeral DH public key Yc. 
-
-   For ECDHE key exchange algorithm, the client always sends the 
-   ClientKeyExchange message conveying its ephemeral ECDH public key Yc.  
-
-   Current TLS specifications note that if the client certificate 
-   already contains a suitable DH or ECDH public key, then Yc is  
-   implicit and does not need to be sent again and consequently, the  
-   client key exchange message will be sent, but it MUST be empty. 
-   Implementations of this document MUST send ClientKeyExchange message 
-   but always carrying the client Yc, whatever the PublicValueEncoding 
-   is implicit or explicit. Note that it is possible to correlate 
-   sessions by the same client when DH or ECDH are in use.  
-
-    
-
-    
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 4] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-         Client                           Server 
-
-         ClientHello       --------> 
-                                          ServerHello 
-                                          Certificate 
-                                          ServerKeyExchange* 
-                           <--------      CertificateRequest 
-         {Certificate} 
-         ClientKeyExchange 
-         {CertificateVerify} 
-         ChangeCipherSpec 
-         Finished          --------> 
-                                          ChangeCipherSpec 
-                           <--------      Finished 
-         Application Data  <------->      Application Data 
-
-   * Indicates optional or situation-dependent messages that are not 
-   always sent. 
-
-   {} Indicates messages that are symmetrically encrypted. 
-
-   The ciphersuites in Section 3 (CP_RSA Key Exchange Algorithm) use RSA 
-   based certificates to mutually authenticate a RSA exchange with the 
-   client credential protection.  
-
-   The ciphersuites in Section 4 (CP_DHE and CP_DH Key Exchange 
-   Algorithm) use DHE_RSA, DH_RSA, DHE_DSS or DH_DSS to mutually 
-   authenticate a (Ephemeral) Diffie-Hellman exchange. 
-
-   The ciphersuites in Section 5 (CP_ECDH and CP_ECDHE Key Exchange 
-   Algorithms) use ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA or ECDHE_RSA to 
-   mutually authenticate a (Ephemeral) EC Diffie-Hellman exchange. 
-
-3. CP_RSA Key Exchange Algorithm 
-
-   This section defines additional ciphersuites that use RSA based 
-   certificates to authenticate a RSA exchange. These ciphersuites give 
-   client credential protection.  
-
-   CipherSuite                       Key Exchange  Cipher           Hash 
-
-   TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5      RSA      RC4_40            MD5 
-   TLS_CP_RSA_WITH_RC4_128_MD5            RSA      RC4_128           MD5 
-   TLS_CP_RSA_WITH_RC4_128_SHA            RSA      RC4_128           SHA 
-   TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5  RSA      RC2_CBC_40        MD5 
-   TLS_CP_RSA_WITH_IDEA_CBC_SHA           RSA      IDEA_CBC          SHA 
-   TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA   RSA      DES40_CBC         SHA 
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 5] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-   TLS_CP_RSA_WITH_DES_CBC_SHA            RSA      DES_CBC           SHA 
-   TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA       RSA      3DES_EDE          SHA 
-   TLS_CP_RSA_WITH_AES_128_CBC_SHA        RSA      AES_128_CBC       SHA 
-   TLS_CP_RSA_WITH_AES_256_CBC_SHA        RSA      AES_256_CBC       SHA 
-   TLS_CP_RSA_WITH_AES_128_CTR_SHA        RSA      AES_128_CTR       SHA 
-   TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA   RSA      CAMELLIA_128_CBC  SHA 
-   TLS_CP_RSA_WITH_AES_256_CTR_SHA        RSA      AES_256_CTR       SHA 
-   TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA   RSA      CAMELLIA_256_CBC  SHA  
-
-4. CP_DHE and CP_DH Key Exchange Algorithms 
-
-   This section defines additional ciphersuites that use DH and DHE as 
-   key exchange algorithms, with RSA or DSS based certificates to 
-   authenticate a (Ephemeral) Diffie-Hellman exchange. These 
-   ciphersuites give client credential protection. 
-
-   CipherSuite                      Key Exchange   Cipher           Hash  
-
-   TLS_CP_DHE_DSS_WITH_DES_CBC_SHA           DHE   DES_CBC           SHA 
-   TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA      DHE   3DES_EDE_CBC      SHA 
-   TLS_CP_DHE_RSA_WITH_DES_CBC_SHA           DHE   DES_CBC           SHA 
-   TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA      DHE   3DES_EDE_CBC      SHA 
-   TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA       DHE   AES_128_CBC       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA       DHE   AES_128_CBC       SHA 
-   TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA       DHE   AES_256_CBC       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA       DHE   AES_256_CBC       SHA 
-   TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA  DHE   CAMELLIA_128_CBC  SHA 
-   TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA  DHE   CAMELLIA_128_CBC  SHA 
-   TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA  DHE   CAMELLIA_256_CBC  SHA 
-   TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA  DHE   CAMELLIA_256_CBC  SHA 
-   TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA       DHE   AES_128_CTR       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA       DHE   AES_128_CTR       SHA 
-   TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA       DHE   AES_256_CTR       SHA 
-   TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA       DHE   AES_256_CTR       SHA 
-   TLS_CP_DH_DSS_WITH_DES_CBC_SHA            DH    DES_CBC           SHA 
-   TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA       DH    3DES_EDE_CBC      SHA 
-   TLS_CP_DH_RSA_WITH_DES_CBC_SHA            DH    DES_CBC           SHA 
-   TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA       DH    3DES_EDE_CBC      SHA 
-   TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA        DH    AES_128_CBC       SHA 
-   TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA        DH    AES_128_CBC       SHA 
-   TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA        DH    AES_256_CBC       SHA 
-   TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA        DH    AES_256_CBC       SHA  
-
-5. CP_ECDH and CP_ECDHE Key Exchange Algorithm 
-
-   This section defines additional ciphersuites that use ECDH and ECDHE 
-   as key exchange algorithms, with RSA or ECDSA based certificates to 
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 6] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-   authenticate a (Ephemeral) ECDH exchange. These ciphersuites give 
-   client credential protection.  
-
-   CipherSuite                         Key Exchange   Cipher        Hash  
-
-   TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA        ECDH     RC4_128        SHA 
-   TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   ECDH     3DES_EDE_CBC   SHA 
-   TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA    ECDH     AES_128_CBC    SHA 
-   TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA    ECDHE    AES_256_CBC    SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA       ECDHE    RC4_128        SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  ECDHE    3DES_EDE_CBC   SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   ECDHE    AES_128_CBC    SHA 
-   TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ECDHE    AES_256_CBC    SHA 
-   TLS_CP_ECDH_RSA_WITH_RC4_128_SHA          ECDH     RC4_128        SHA 
-   TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     ECDH     3DES_EDE_CBC   SHA 
-   TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA      ECDH     AES_256_CBC    SHA 
-   TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA      ECDH     AES_256_CBC    SHA 
-   TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA         ECDHE    RC4_128        SHA 
-   TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    ECDHE    3DES_EDE_CBC   SHA 
-   TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA     ECDHE    AES_256_CBC    SHA 
-   TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA     ECDHE    AES_256_CBC    SHA 
-
-6. Security Considerations 
-
-   The security considerations described throughout [TLS], [DTLS], 
-   [TLSAES], [TLSECC] and [TLSAES] apply here as well. 
-
-7. IANA Considerations 
-
-   This section provides guidance to the IANA regarding registration of 
-   values related to the credential protection ciphersuites.  
-
-   CipherSuite TLS_CP_RSA_EXPORT_WITH_RC4_40_MD5         ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_RC4_128_MD5               ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_RC4_128_SHA               ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_EXPORT_WITH_RC2_CBC_40_MD5     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_IDEA_CBC_SHA              ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_EXPORT_WITH_DES40_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_DES_CBC_SHA               ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_3DES_EDE_CBC_SHA          ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_128_CBC_SHA           ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_256_CBC_SHA           ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_128_CTR_SHA           ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_128_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_AES_256_CTR_SHA           ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_RSA_WITH_CAMELLIA_256_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_DES_CBC_SHA           ={ 0xXX,0xXX }; 
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 7] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-   CipherSuite TLS_CP_DHE_DSS_WITH_3DES_EDE_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_DES_CBC_SHA           ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_3DES_EDE_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CBC_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CBC_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CBC_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CBC_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA  ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA  ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA  ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA  ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_128_CTR_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_128_CTR_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_DSS_WITH_AES_256_CTR_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DHE_RSA_WITH_AES_256_CTR_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_DES_CBC_SHA            ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_3DES_EDE_CBC_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_DES_CBC_SHA            ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_3DES_EDE_CBC_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_AES_128_CBC_SHA        ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_AES_128_CBC_SHA        ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_DSS_WITH_AES_256_CBC_SHA        ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_DH_RSA_WITH_AES_256_CBC_SHA        ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_RC4_128_SHA        ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_128_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_ECDSA_WITH_AES_256_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_RC4_128_SHA       ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_RC4_128_SHA          ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_AES_128_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDH_RSA_WITH_AES_256_CBC_SHA      ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_RC4_128_SHA         ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_128_CBC_SHA     ={ 0xXX,0xXX }; 
-   CipherSuite TLS_CP_ECDHE_RSA_WITH_AES_256_CBC_SHA     ={ 0xXX,0xXX };  
-
-   Note: For implementation and deployment facilities, it is helpful to 
-   reserve a specific registry sub-range (minor, major) for credential 
-   protection ciphersuites. 
-
-
-
-
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 8] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-8. References 
-
-8.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [TLS]    Dierks, T. and E. Rescorla, "The TLS Protocol Version  
-             1.1", RFC 4346, April 2005.  
-
-   [DTLS]   Rescorla, E. and N. Modadugu, "Datagram Transport Layer  
-             Security", RFC 4347, April 2006.  
-
-   [TLSCAM]  Moriai, S., Kato, A., Kanda M., "Addition of Camellia 
-             Cipher Suites to Transport Layer Security (TLS)", RFC 4132, 
-             July 2005.  
-
-   [TLSAES]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 3268, June 2002.  
-
-   [TLSECC]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., 
-             Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher 
-             Suites for Transport Layer Security (TLS)", RFC 4492, May 
-             2006  
-
-   [TLSCTR]  Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher 
-             Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt 
-             (expired), June 2006. 
-
-8.2. Informative References 
-
-   [SSLTLS]  Rescorla, E., "SSL and TLS: Designing and Building Secure 
-             Systems", Addison-Wesley, March 2001.  
-
-   [CORELLA] Corella, F., "adding client identity protection to TLS", 
-             message on ietf-tls@lists.certicom.com mailing list, 
-             http://www.imc.org/ietf-tls/mail-archive/msg02004.html, 
-             August 2000.  
-
-   [INTEROP] Pettersen, Y., "Clientside interoperability experiences for 
-             the SSL and TLS protocols",draft-ietf-tls-interoperability-
-             00 (expired), October 2006.  
-
-   [EAPIP]  Urien, P. and M. Badra, "Identity Protection within EAP-
-             TLS", draft-urien-badra-eap-tls-identity-protection-01.txt 
-             (expired), October 2006. 
-
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 9] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-Author's Addresses 
-
-   Ibrahim Hajjeh 
-   INEOVATION 
-   France 
-      
-   Email: hajjeh@ineovation.com 
-    
-
-   Mohamad Badra  
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-      
-   Email: badra@isima.fr 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
- 
- 
-Hajjeh & Badra            Expires June 2008                  [Page 10] 
-
-Internet-Draft  Credential Protection Ciphersuites for TLS December 2007 
-    
-
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2007). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Hajjeh & Badra            Expires June 2008                  [Page 11] 
-
diff --git a/doc/protocol/draft-hajjeh-tls-sign-00.txt b/doc/protocol/draft-hajjeh-tls-sign-00.txt
deleted file mode 100644
index 6fc44075ad..0000000000
--- a/doc/protocol/draft-hajjeh-tls-sign-00.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-Internet Engineering Task Force                             I. Hajjeh 
-INTERNET DRAFT                                         A. Serhrouchni 
-                                                           ENST Paris 
-                                                        M. Badra, Ed. 
-                                                         O. Cherkaoui 
-                                                      UQAM University 
-Expires: June 2005                                   January 09, 2005 
-  
-                               TLS Sign 
-                    <draft-hajjeh-tls-sign-00.txt> 
-  
-  
-Status 
-    
-   By submitting this Internet-Draft, I certify that any applicable 
-   patent or other IPR claims of which I am aware have been disclosed, 
-   or will be disclosed, and any of which I become aware will be 
-   disclosed, in accordance with RFC 3668. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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 (2004).  All Rights Reserved.  
-    
-Abstract 
-    
-   TLS protocol provides authentication and data protection for 
-   communication between two entities. However, missing from the 
-   protocol is a way to perform non-repudiation service. 
-    
-   This document defines extensions to the TLS protocol to allow it to 
-   perform non-repudiation service. It is based on [TLSSign] and it 
-   provides the client and the server the ability to sign by TLS, 
-   handshake and applications data using certificates such as X.509. 
-    
-    
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 1]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-Table of Contents 
-    
-   Abstract...........................................................1 
-   1 Introduction.....................................................2 
-   1.2 Requirements language..........................................3 
-   2 TLS Sign overview................................................3 
-      2.1 Signed data Record type.....................................5 
-      2.1.1 TLS Sign activate/deactivate..............................5 
-      2.1.1 TLS sign packet format....................................5 
-      2.2 Storing signed data.........................................6 
-   Security Considerations............................................7 
-   References.........................................................7 
-   Author's Addresses.................................................8 
-    
-1 Introduction 
-    
-   Actually, TLS is the most deployed security protocol for securing 
-   exchanges. It provides end-to-end secure communications between two 
-   entities with authentication and data protection. However, what is 
-   missing from the protocol is a way to provide the non-repudiation 
-   service. 
-    
-   This document describes how the non-repudiation service may be 
-   integrated as an optional module in TLS. This is in order to provide 
-   both parties with evidence that the transaction has taken place and 
-   to offer a clear separation with application design and development. 
-   TLS-Sign's design motivations included: 
-    
-   o   TLS is application protocol-independent. Higher-level protocol  
-       can operate on top of the TLS protocol transparently. 
-    
-   o   TLS is a modular nature protocol. Since TLS is developed in four  
-       independent protocols, the approach defined in this document can  
-       be added by extending the TLS protocol and with a total  
-       reuse of pre-existing TLS infrastructures and implementations. 
-    
-   o   Several applications like E-Business require non-repudiation  
-       proof of transactions. It is critical in these applications to  
-       have the non-repudiation service that generates, distributes,  
-       validates and maintains the evidence of an electronic  
-       transaction. Since TLS is widely used to secure these  
-       applications exchanges, the non-repudiation should be offered by  
-       TLS. 
-    
-   o   Generic Non repudiation with TLS. TLS SIGN provides a generic  
-       non-repudiation service that can be easily used with protocols.   
-       TLS SIGN minimizes both design and implementation of the  
-       signature service and that of the designers and implementators  
-       who wish to use this module. 
-    
-    
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 2]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-1.2 Requirements language 
-    
-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
-   are to be interpreted as described in RFC-2119. 
-    
-2 TLS Sign overview 
-    
-   TLS Sign is integrated as a higher-level module of the TLS Record 
-   protocol. It is optionally used if the two entities agree. This is 
-   negotiated by extending Client and Server Hello messages in the same 
-   way defined in [TLSExt]. 
-    
-   In order to allow a TLS client to negotiate the TLS Sign, a new 
-   extension type should be added to the Extended Client and Server 
-   Hellos messages. TLS clients and servers may include an extension of 
-   type 'signature' in the Extended Client and Server Hellos messages. 
-   The 'extension_data' field of this extension contains a 
-   'signature_request' where: 
-    
-     enum { 
-           pkcs7(0), smime(1), xmldsig(2), (255); 
-        } ContentFormat; 
-    
-     struct { 
-             ContentFormat content_format; 
-             SignMethod sign_meth; 
-             Signature_type sign_type<1..2^16-1>; 
-        } signature_request; 
-    
-     enum { 
-         ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255); 
-        } SignMethod; 
-    
-       opaque Signature_type<1..2^16-1>; 
-     
-   The client initiates the TLS Sign module by sending the  
-   ExtendedClientHello including the 'signature' extension. This  
-   extension contains: 
-      
-   - the signature type (e.g., non-repudiation with proof of origin), 
-   - the content format (e.g., PKCS7 [PKCS7], S/MIME [S/MIME], XMLDSIG 
-     [XMLDSIG]), 
-   - the signature method (e.g. X509 authentication certificate).  
-     Actually, this document uses the same certificate used in client  
-     authentication. Any new signature method MAY be added in future  
-     versions (e.g. delegated attributes certificates). 
-    
-   The server MAY reject the connection by sending the error alert 
-   "unsupported_extension" [TLSExt] and closing the connection. 
-    
-    
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 3]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-   If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client does 
-   not include any cipher_suite with signature ability, the server MUST 
-   close the connection by sending a fatal error. 
-    
-   If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client 
-   includes at least a cipher_suite with signature ability, the server 
-   MUST select a cipher_suite with signature ability and MUST provide a 
-   certificate (e.g., RSA) that MAY be used for key exchange. Further, 
-   the server MUST request a certificate from the client with signing 
-   ability in the certificate request message (e.g., an RSA or a DSS 
-   signature-capable certificate). This request however, MUST be 
-   appropriate for the selected cipher suite. 
-    
-   If the server has no interest in getting non-repudiation data from 
-   the client, the server will select a cipher_suite or, if no 
-   acceptable choices are presented, return a handshake failure alert 
-   and close the connection [TLS]." 
-    
-   However, the client MAY demand a non-repudiation data without having 
-   a certificate. In this case, the client MAY reject the connection if 
-   the server is not ready to give it the non-repudiation service. This 
-   may be done using the signature type field of the signature_request 
-   structure. 
-    
-         Client                                               Server 
-         ------                                               ------ 
-    
-         ClientHello                  --------> 
-                                                         ServerHello 
-                                                         Certificate 
-                                                  ServerKeyExchange* 
-                                                  CertificateRequest 
-                                      <--------      ServerHelloDone 
-         Certificate 
-         ClientKeyExchange 
-         CertificateVerify 
-         ChangeCipherSpec 
-         Finished                     --------> 
-                                                    ChangeCipherSpec 
-                                      <--------             Finished 
-         (Signed) Application Data    <------->   (Signed) App. Data 
-    
-    
-    
-    
-    
-    
-    
-
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 4]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-2.1 Signed data Record type 
-    
-   New record type is added in this document: the signed data protocol.  
-   The message consists of a single byte of value 1 or 0.  
-     
-       enum {  
-           change_cipher_spec(20), alert(21), handshake(22),  
-           application_data(23), tls_sign(25), (255)  
-       } ContentType;  
-     
-       struct {  
-           enum { tls_sign_off(0), tls_sign_on(1), (255) } type;  
-       } TLSSignOnOff;             
-  
-2.1.1 TLS Sign activate/deactivate 
-    
-   To manage the generation of evidence, new record protocol is added  
-   by this document, called tls_sign_on_off. This protocol consists of  
-   a single message that is encrypted and compressed under the  
-   established connection state. Thus, no man in the middle can replay  
-   or inject this message. It consists of a Boolean of value 1  
-   (tls_sign_on) or 0 (tls_sign_off).  
-     
-   The tls_sign_on_off message is sent by both the client and server to  
-   notify the receiving party that subsequent records will carry data  
-   under the negotiated parameters and keys.  
-     
-   If the client was not authenticated in his first TLS exchange or  
-   does not support a signature algorithm, the server who receives  
-   tls_sign_on_off message, MAY answer by signed data, ignore it or MAY 
-   invite the client to start a new TLS session sending the 
-   HelloRequest message.  
-     
-   This message can be sent at any point after the TLS session has been  
-   established. 
-    
-2.1.1 TLS sign packet format 
- 
-   This document defines a new packet format that encapsulates signed 
-   data. The packet format is shown below. The fields are transmitted 
-   from left to right. 
-    
-    0                   1                   2                   3       
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
-   | Content-Type  |          Length               |  
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |                Signed Data ... 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
-     
-   Content-Type  
-    
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 5]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-    0 1 2 3 4 5 6 7  
-   +-+-+-+-+-+-+-+-+  
-   |A D R R R R R R|  
-   +-+-+-+-+-+-+-+-+  
-    
-   A = acknowledgement of receipt 
-   D = signed data 
-   R = Reserved 
-    
-   When the whole signed data is delivered to the receiver, the TLS 
-   Sign will check the signature. If the signature is valid and that 
-   the sender requires a proof of receipt, the receiver MUST generate a 
-   message with Type=A (acknowledgement of receipt), and as data-field 
-   the digest of the whole data. The data-field is of course signed by 
-   the receiver before it is sent to the sender. 
-    
-2.2 Storing signed data 
-    
-   The objective of TLS Sign is to provide both parties with evidence 
-   that can be stored and later presented to a third party to resolve 
-   disputes that arise if and when a communication is repudiated by one 
-   of the entities involved. This document provides the two basic types 
-   of non-repudiation service: 
-    
-   o   Non-repudiation with proof of origin: provides the TLS server  
-       with evidence proving that the TLS client has sent it the signed  
-       data at a certain time. 
-    
-   o   Non-repudiation with proof of delivery: provides the TLS client  
-       with evidence that the server has received the client's signed  
-       data at a specific time. 
-    
-   TLS Handshake exchanges the current time and date according to the 
-   entities internal clock. Thus, the time and date can be stored with 
-   the signed data as a proof of communication. For B2C or B2B 
-   transactions, non-repudiation with proof of origin and non-
-   repudiation with proof of receipt are both important. If the TLS 
-   client requests a non-repudiation service with proof of receipt, the 
-   server SHOULD verify and send back to client a signature on the hash 
-   of signed data. 
-    
-   The following figure explains the different events for proving and 
-   storing signed data [RFC2828]. RFC 2828 uses the term "critical 
-   action" to refer to the act of communication between the two 
-   entities. For a complete non-repudiation deployment, 6 phases should 
-   be respected: 
-    
-    
-    
-    
-    
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 6]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-    --------   --------   --------   --------   --------   . -------- 
-    Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6: 
-    Request    Generate   Transfer   Verify     Retain     . Resolve 
-    Service    Evidence   Evidence   Evidence   Evidence   . Dispute 
-    --------   --------   --------   --------   --------   . -------- 
-    Service    Critical   Evidence   Evidence   Archive    . Evidence 
-    Request => Action  => Stored  => Is      => Evidence   . Is 
-    Is Made    Occurs     For Later  Tested     In Case    . Verified 
-               and        Use |          ^      Critical   .     ^ 
-               Evidence       v          |      Action Is  .     | 
-               Is         +-------------------+ Repudiated .     | 
-               Generated  |Verifiable Evidence|------> ... . ----+ 
-                          +-------------------+ 
-    
-   1- Requesting explicit transaction evidence before sending data. 
-   Normally, this action is taken by the SSL/TLS client 
-    
-   2- If the server accepts, the client will generate evidence by 
-   signing data using his X.509 authentication certificate. Server will 
-   go through the same process if the evidence of receipt is requested.  
-    
-   3 - The signed data is then sent by the initiator (client or server) 
-   and stored it locally, or by a third party, for a later use if 
-   needed. 
-    
-   4 - The entity that receive the evidence process to verify the 
-   signed data. 
-    
-   5- The evidence is then stored by the receiver entity for a later 
-   use if needed. 
-    
-   6- In this phase, which occurs only if the critical action is 
-   repudiated, the evidence is retrieved from storage, presented, and 
-   verified to resolve the dispute. 
-    
-   With this method, the stored signed data (or evidence) can be 
-   retrieved by both parties, presented and verified if the critical 
-   action is repudiated. 
-    
-Security Considerations 
-    
-   Security issues are discussed throughout this memo. 
-    
-References 
-    
-   [TLS]    Dierks, T., et. al, "The TLS Protocol Version 1.0", RFC 
-            2246, January 1999. 
-    
-   [TLSExt] Blake-Wilson, S., et. al, "Transport Layer Security (TLS) 
-            Extensions", RFC 3546, June 2003. 
-    
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 7]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message 
-            Syntax Standard," version 1.5, November 1993. 
-    
-   [S/MIME] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 
-            2633, June 1999. 
-    
-   [XMLDSIG]Eastlake, D., et. al, "(Extensible Markup Language) XML 
-            Signature Syntax and Processing", RFC 3275, March 2002. 
-    
-   [TLSSign]Hajjeh, I., Serhrouchni, A., "Integrating a signature  
-            module in SSL/TLS, ICETEÆ2004, ACM/IEEE, First  
-            International Conference on E-Business and 
-            Telecommunication Networks, Portugal, August 2004. 
-    
-   [RFC2828]Shirey, R., "Internet Security Glossary", RFC 2828, May  
-            2000. 
-    
-Author's Addresses 
-    
-   Ibrahim Hajjeh 
-   ENST 
-   46 rue Barrault 
-   75013 Paris               Phone: NA 
-   France                    Email: Ibrahim.Hajjeh@enst.fr 
-    
-   Ahmed serhrouchni 
-   ENST 
-   46 rue Barrault 
-   75013 Paris               Phone: NA 
-   France                    Email: Ahmed.serhrouchni@enst.fr 
-    
-   Mohamad Badra 
-   UQAM University 
-   Montreal (Quebec)         Phone: NA 
-   Canada                    Email: Mohamad.Badra@uqam.ca 
-    
-   Omar Cherkaoui 
-   UQAM University 
-   Montreal (Quebec)         Phone: NA 
-   Canada                    Email: Omar.Cherkaoui@uqam.ca 
-    
-   Acknowledgements 
-    
-   The authors would like to thank Eric Rescorla for discussions and 
-   comments on the design of TLS Sign. 
-    
-   Intellectual Property Statement 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 8]
-INTERNET-DRAFT                   TLS Sign                  January 2005 
- 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights. 
-   Information on the IETF's procedures with respect to rights in IETF 
-   Documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Disclaimer of Validity 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-    
-   Copyright Statement 
-    
-   Copyright (C) The Internet Society (2004). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   Acknowledgment 
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
-Hajjeh, et. al.       Informational - Expires June 2005        [Page 9]
-
diff --git a/doc/protocol/draft-hajjeh-tls-sign-01.txt b/doc/protocol/draft-hajjeh-tls-sign-01.txt
deleted file mode 100644
index 4955fe0693..0000000000
--- a/doc/protocol/draft-hajjeh-tls-sign-01.txt
+++ /dev/null
@@ -1,561 +0,0 @@
-
-
-
-Internet Engineering Task Force                               I. Hajjeh 
-INTERNET DRAFT                                                ESRGroups 
-                                                               M. Badra 
-                                                         A. Serhrouchni 
-                                                             ENST Paris 
-                                                           J. Demerjian 
-                                                            M. Achemlal 
-                                                     France Telecom R&D 
-Expires: April 2006                                    October 20, 2005 
-    
-                                  TLS Sign  
-                       <draft-hajjeh-tls-sign-01.txt> 
-    
-    
-Status 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-     
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet 
-   Drafts. 
-    
-   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   
-     
-   This Internet-Draft will expire on April 20, 2006. 
-    
-Copyright Notice 
-    
-   Copyright (C) The Internet Society (2005). 
-     
-Abstract  
-     
-   TLS protocol provides authentication and data protection for 
-   communication between two entities. However, missing from the 
-   protocol is a way to perform non-repudiation service.  
-     
-   This document defines extensions to the TLS protocol to allow it to 
-   perform non-repudiation service. It is based on [TLSSign] and it 
-
- 
-Hajjeh, et. al.              Expires April 2006                [Page 1] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-   provides the client and the server the ability to sign by TLS, 
-   handshake and applications data using certificates such as X.509. 
-    
-1 Introduction 
-    
-   Actually, TLS is the most deployed security protocol for securing 
-   exchanges. It provides end-to-end secure communications between two 
-   entities with authentication and data protection. However, what is 
-   missing from the protocol is a way to provide the non-repudiation 
-   service. 
-    
-   This document describes how the non-repudiation service may be 
-   integrated as an optional module in TLS. This is in order to provide 
-   both parties with evidence that the transaction has taken place and 
-   to offer a clear separation with application design and development.  
-    
-   TLS-Sign's design motivations included:  
-     
-   o   TLS is application protocol-independent. Higher-level protocol   
-       can operate on top of the TLS protocol transparently.  
-     
-   o   TLS is a modular nature protocol. Since TLS is developed in four  
-       independent protocols, the approach defined in this document can  
-       be added by extending the TLS protocol and with a total 
-       reuse of pre-existing TLS infrastructures and implementations.  
-        
-   o   Several applications like E-Business require non-repudiation   
-       proof of transactions. It is critical in these applications to   
-       have the non-repudiation service that generates, distributes,   
-       validates and maintains the evidence of an electronic   
-       transaction. Since TLS is widely used to secure these   
-       applications exchanges, the non-repudiation should be offered by   
-       TLS.  
-        
-   o   Generic Non repudiation with TLS. TLS SIGN provides a generic   
-       non-repudiation service that can be easily used with protocols.    
-       TLS SIGN minimizes both design and implementation of the   
-       signature service and that of the designers and implementators   
-       who wish to use this module. 
-    
-1.2 Requirements language 
-    
-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
-   are to be interpreted as described in RFC-2119. 
-    
-2 TLS Sign overview  
-     
-   TLS Sign is integrated as a higher-level module of the TLS Record 
-   protocol. It is optionally used if the two entities agree. This is 
-   negotiated by extending Client and Server Hello messages in the same 
-   way defined in [TLSExt]. 
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 2] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-    
-   In order to allow a TLS client to negotiate the TLS Sign, a new 
-   extension type should be added to the Extended Client and Server 
-   Hellos messages. TLS clients and servers MAY include an extension of 
-   type 'signature' in the Extended Client and Server Hellos messages. 
-   The 'extension_data' field of this extension contains a 
-   'signature_request' where:  
-     
-    enum {  
-          pkcs7(0), smime(1), xmldsig(2), (255);  
-       } ContentFormat;  
-    
-    struct {  
-            ContentFormat content_format;  
-            SignMethod sign_meth;  
-            SignType_sign_type;  
-         } signature_request;  
-    
-    enum {  
-          ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);  
-       } SignMethod;  
-     
-    opaque Signature_type<1..2^16-1>;  
-      
-   The client initiates the TLS Sign module by sending the 
-   ExtendedClientHello including the 'signature' extension. This 
-   extension contains:  
- 
-   - the SignType contains the type of the non repudiation proof. It 
-   can have one of these two values: 
-    
-   SignType non_repudiation_with_proof_of_origin      = { 0x00, 0x01 }; 
-   SignType non_repudiation_without_proof_of_origin   = { 0x00, 0x02 }; 
-    
-   - the ContentFormat contains the format of signed data. It can be 
-   PKCS7 [PKCS7], S/MIME [S/MIME] or XMLDSIG [XMLDSIG] 
-    
-             ContentFormat PKCS7   = { 0x00, 0xA1 }; 
-             ContentFormat SMIME   = { 0x00, 0xA2 }; 
-             ContentFormat XMLDSIG = { 0x00, 0xA3 }; 
-    
-         o if the value of the ContentFormat is PKCS7, then the PKCS7  
-           Content_type is of type signed-data. 
-    
-         o if the value of the ContentFormat is S/MIME, then S/MIME  
-           Content_type is of type SignedData 
-    
-         o if the value of the ContentFormat is XMLDSIG, then XMLDSIG  
-           signatureMethod algorithms. 
-    
-
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 3] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-   - the sign_method contains the signature method that is used to sign 
-   the application data (e.g. X509  authentication certificate). 
-    
-               SignMethod X509 = { 0x00, 0xB1 }; 
-    
-   Actually, this document uses the same certificate used in client 
-   authentication. Any new signature method MAY be added in future 
-   versions (e.g. delegated attributes certificates). 
-    
-   The server MAY reject the connection by sending the error alert 
-   "unsupported_extension" [TLSExt] and closing the connection. 
-    
-   If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client does 
-   not include any cipher_suite with signature ability, the server MUST 
-   close the connection by sending a fatal error. 
-    
-   If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client 
-   includes at least a cipher_suite with signature ability, the server 
-   MUST select a cipher_suite with signature ability and MUST provide a 
-   certificate (e.g., RSA) that MAY be used for key exchange. Further, 
-   the server MUST request a certificate from the client using the TLS 
-   certificate request message (e.g., an RSA or a DSS signature-capable 
-   certificate). This request however, MUST be appropriate for the 
-   selected cipher suite. 
-    
-   If the server has no interest in getting non-repudiation data from 
-   the client, it replays with an ordinary TLS ServerHello or return a 
-   handshake failure alert and close the connection [TLS].
-    
-         Client                                               Server  
-         ------                                               ------  
-    
-         ClientHello                  -------->  
-                                                         ServerHello  
-                                                         Certificate  
-                                                  ServerKeyExchange*  
-                                                  CertificateRequest  
-                                      <--------      ServerHelloDone  
-         Certificate  
-         ClientKeyExchange  
-         CertificateVerify  
-         ChangeCipherSpec  
-         Finished                     -------->  
-                                                    ChangeCipherSpec  
-                                      <--------             Finished  
-         (Signed) Application Data    <------->   (Signed) App. Data 
-    
-   However, the client MAY request a non-repudiation data without 
-   having a certificate. In this case, the client MAY reject the 
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 4] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-   connection if the server is not ready to give it the non-repudiation 
-   service. This MAY be done using the signature type field of the 
-   signature_request structure. 
-    
-2.1 Signed data Record type  
-    
-   New record type is added in this document: the signed data protocol. 
-   The message consists of a single byte of value 1 or 0.   
-    
-       enum {   
-             change_cipher_spec(20), alert(21), handshake(22),   
-             application_data(23), tls_sign(25), (255)   
-          } ContentType;   
-      
-       struct {   
-               enum { tls_sign_off(0), tls_sign_on(1), (255) } type;   
-            } TLSSignOnOff;  
-    
- 2.1.1 TLS Sign activate/deactivate  
-    
-   To manage the generation of evidence, new sub-protocol is added by 
-   this document, called tls_sign_on_off. This protocol consists of a 
-   single message that is encrypted and compressed under the 
-   established connection state. Thus, no man in the middle can replay 
-   or inject this message. It consists of a Boolean of value 1 
-   (tls_sign_on) or 0 (tls_sign_off). 
-    
-   The tls_sign_on_off message is sent by both the client and server to 
-   notify the receiving party that subsequent records will carry data 
-   under the negotiated parameters and keys.   
-    
-   If the client was not authenticated in his first TLS exchange or 
-   does not support a signature algorithm, the server who receives 
-   tls_sign_on_off message, MAY answer by signed data, ignore it or MAY 
-   invite the client to start a new TLS session sending the 
-   HelloRequest message.   
-    
-   This message can be sent at any time after the TLS session has been 
-   established.  
-    
- 2.1.2 TLS sign packet format  
-    
-   This document defines a new packet format that encapsulates signed 
-   data. The packet format is shown below. The fields are transmitted 
-   from left to right.  
-    
-    
-    
-    
-    
-    
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 5] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-   0                   1                   2                   3        
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
-   | Content-Type  |          Length               |   
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
-   |                Signed Data ...  
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
-    
-   Content-Type 
-    
-   0 1 2 3 4 5 6 7   
-   +-+-+-+-+-+-+-+-+   
-   |A D R R R R R R|   
-   +-+-+-+-+-+-+-+-+   
-    
-   A = acknowledgement of receipt  
-   D = signed data  
-   R = Reserved  
-    
-   When the whole signed data is delivered to the receiver, the TLS 
-   Sign will check the signature. If the signature is valid and that 
-   the sender requires a proof of receipt, the receiver MUST generate a 
-   message with Type=A (acknowledgement of receipt). The data-field of 
-   that message contains the digest of the whole data. The digest is 
-   signed before sending the result to the other side. 
-    
-2.2 Storing signed data  
-    
-   The objective of TLS Sign is to provide both parties with evidence 
-   that can be stored and later presented to a third party to resolve 
-   disputes that arise if and when a communication is repudiated by one 
-   of the entities involved. This document provides the two basic types 
-   of non-repudiation service:  
-    
-   o   Non-repudiation with proof of origin: provides the TLS server   
-       with evidence proving that the TLS client has sent it the signed   
-       data at a certain time.  
-    
-   o   Non-repudiation with proof of delivery: provides the TLS client   
-       with evidence that the server has received the client's signed   
-       data at a specific time.  
-    
-   TLS Handshake exchanges the current time and date according to the 
-   entities internal clock. Thus, the time and date can be stored with 
-   the signed data as a proof of communication. For B2C or B2B 
-   transactions, non-repudiation with proof of origin and non-
-   repudiation with proof of receipt are both important. If the TLS 
-   client requests a non-repudiation service with proof of receipt, the 
-   server SHOULD verify and send back to client a signature on the hash 
-   of signed data.  
-    
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 6] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-   The following figure explains the different events for proving and 
-   storing signed data [RFC2828]. RFC 2828 uses the term "critical 
-   action" to refer to the act of communication between the two 
-   entities. For a complete non-repudiation deployment, 6 phases should 
-   be respected: 
-    
-   --------   --------   --------   --------   --------   . --------  
-   Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6:  
-   Request    Generate   Transfer   Verify     Retain     . Resolve  
-   Service    Evidence   Evidence   Evidence   Evidence   . Dispute  
-   --------   --------   --------   --------   --------   . --------  
-   Service    Critical   Evidence   Evidence   Archive    . Evidence  
-   Request => Action  => Stored  => Is      => Evidence   . Is  
-   Is Made    Occurs     For Later  Tested     In Case    . Verified  
-              and        Use |          ^      Critical   .     ^  
-              Evidence       v          |      Action Is  .     |  
-              Is         +-------------------+ Repudiated .     |  
-              Generated  |Verifiable Evidence|------> ... . ----+  
-                         +-------------------+  
-    
-   1- Requesting explicit transaction evidence before sending data. 
-   Normally, this action is taken by the SSL/TLS client  
-    
-   2- If the server accepts, the client will generate evidence by 
-   signing data using his X.509 authentication certificate. Server will 
-   go through the same process if the evidence of receipt is requested. 
-    
-   3 - The signed data is then sent by the initiator (client or server) 
-   and stored it locally, or by a third party, for a later use if 
-   needed. 
-    
-   4 - The entity that receive the evidence process to verify the 
-   signed data. 
-    
-   5- The evidence is then stored by the receiver entity for a later 
-   use if needed. 
-    
-   6- In this phase, which occurs only if the critical action is 
-   repudiated, the evidence is retrieved from storage, presented, and 
-   verified to resolve the dispute. 
-    
-   With this method, the stored signed data (or evidence) can be 
-   retrieved by both parties, presented and verified if the critical 
-   action is repudiated. 
-    
-Security Considerations 
-    
-   Security issues are discussed throughout this memo. 
-    
-
-
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 7] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
- 
-References 
-    
-   [TLS]     Dierks, T., et. al., "The TLS Protocol Version 1.0",  
-             RFC 2246, January 1999. 
-    
-   [TLSExt]  Blake-Wilson, S., et. al., "Transport Layer Security TLS)  
-             Extensions", RFC 3546, June 2003. 
-    
-   [PKCS7]   RSA Laboratories, "PKCS #7: RSA Cryptographic Message  
-             Syntax Standard," version 1.5, November 1993.  
-        
-   [S/MIME]  Ramsdell, B., "S/MIME Version 3 Message Specification",  
-             RFC 2633, June 1999.  
-    
-   [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML  
-             Signature Syntax and Processing", RFC 3275, March 2002.  
-    
-   [TLSSign] Hajjeh, I., Serhrouchni, A., "Integrating a signature   
-             module in SSL/TLS, ICETE2004., ACM/IEEE, First   
-             International Conference on E-Business and  
-             Telecommunication Networks, Portugal, August 2004.  
-    
-   [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May   
-             2000. 
-    
-Author's Addresses 
-    
-   Ibrahim Hajjeh  
-   Engineering and Scientific Research Groups (ESRGroups) 
-   17 Passage Barrault  
-   75013 Paris               Phone: NA  
-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
-    
-   Mohamad Badra  
-   ENST 
-   46 rue Barrault  
-   75634 Paris               Phone: NA  
-   France                    Email: Mohamad.Badra@enst.fr 
-    
-   Ahmed serhrouchni  
-   ENST                      Phone: NA  
-   France                    Email: Ahmed.serhrouchni@enst.fr  
-    
-   Jacques Demerjian  
-   France Telecom R&D  
-   42 rue des coutures  
-   14066 Caen Cedex 4        Phone: NA  
-   France                    Email: jacques.demerjian@francetelecom.com 
-    
-   Mohammed Achemlal  
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 8] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-   France Telecom R&D        Phone: NA  
-   France                    Email: Mohammed.Achemlal@francetelecom.com 
-    
-   Acknowledgements  
-    
-   The authors would like to thank Eric Rescorla for discussions and 
-   comments on the design of TLS Sign. 
-    
-Appendix  Changelog 
-    
-   Changes from -00 to -01: 
-    
-   o Clarifications to the format of the signed data in Section 2. 
-    
-   o Small clarifications to TLS SIGN negotiation in Section 2. 
-    
-   o Added Jacques Demerjian and Mohammed Achemlal as 
-     contributors/authors. 
-    
-   Intellectual Property Statement  
-     
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights. 
-   Information on the IETF's procedures with respect to rights in IETF 
-   Documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Disclaimer of Validity 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 9] 
-INTERNET-DRAFT                   TLS Sign                  October 2005 
- 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
-    
-   Copyright Statement 
-     
-   Copyright (C) The Internet Society (2004). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights. 
-    
-   Acknowledgment  
-    
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
-Badra & Hajjeh               Expires April 2006               [Page 10] 
\ No newline at end of file
diff --git a/doc/protocol/draft-hajjeh-tls-sign-02.txt b/doc/protocol/draft-hajjeh-tls-sign-02.txt
deleted file mode 100644
index 49d9397297..0000000000
--- a/doc/protocol/draft-hajjeh-tls-sign-02.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-

-
-
-Internet Engineering Task Force                               I. Hajjeh 

-INTERNET DRAFT                                                ESRGroups 

-                                                          M. Badra, Ed. 

-                                                       LIMOS Laboratory 

- 

-Expires: April 2007                                       November 2006 

-    

-                                  TLS Sign  

-                       <draft-hajjeh-tls-sign-02.txt> 

-    

-    

-Status 

-    

-   By submitting this Internet-Draft, each author represents that any 

-   applicable patent or other IPR claims of which he or she is aware 

-   have been or will be disclosed, and any of which he or she becomes 

-   aware will be disclosed, in accordance with Section 6 of BCP 79. 

-     

-   Internet-Drafts are working documents of the Internet Engineering 

-   Task Force (IETF), its areas, and its working groups. Note that 

-   other groups may also distribute working documents as Internet 

-   Drafts. 

-    

-   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   

-     

-   This Internet-Draft will expire on April 09, 2007. 

-    

-Copyright Notice 

-    

-   Copyright (C) The Internet Society (2006). 

-     

-Abstract  

-     

-   TLS protocol provides authentication and data protection for 

-   communication between two entities. However, missing from the 

-   protocol is a way to perform non-repudiation service.  

-     

-   This document defines extensions to the TLS protocol to allow it to 

-   perform non-repudiation service. It is based on [TLSSign] and it 

-   provides the client and the server the ability to sign by TLS, 

-   handshake and applications data using certificates such as X.509. 

-    

-
- 

-Hajjeh, et. al.              Expires April 2007                [Page 1] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-1 Introduction 

-    

-   Actually, TLS is the most deployed security protocol for securing 

-   exchanges. It provides end-to-end secure communications between two 

-   entities with authentication and data protection. However, what is 

-   missing from the protocol is a way to provide the non-repudiation 

-   service. 

-    

-   This document describes how the non-repudiation service may be 

-   integrated as an optional module in TLS. This is in order to provide 

-   both parties with evidence that the transaction has taken place and 

-   to offer a clear separation with application design and development.  

-    

-   TLS-Sign's design motivations included:  

-     

-   o   TLS is application protocol-independent. Higher-level protocol   

-       can operate on top of the TLS protocol transparently.  

-     

-   o   TLS is a modular nature protocol. Since TLS is developed in four  

-       independent protocols, the approach defined in this document can  

-       be added by extending the TLS protocol and with a total 

-       reuse of pre-existing TLS infrastructures and implementations.  

-        

-   o   Several applications like E-Business require non-repudiation   

-       proof of transactions. It is critical in these applications to   

-       have the non-repudiation service that generates, distributes,   

-       validates and maintains the evidence of an electronic   

-       transaction. Since TLS is widely used to secure these   

-       applications exchanges, the non-repudiation should be offered by   

-       TLS.  

-        

-   o   Generic non-repudiation with TLS. TLS Sign provides a generic   

-       non-repudiation service that can be easily used with protocols.    

-       TLS Sign minimizes both design and implementation of the   

-       signature service and that of the designers and implementators   

-       who wish to use this module. 

-    

-1.2 Requirements language 

-    

-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 

-   are to be interpreted as described in RFC-2119. 

-    

-2 TLS Sign overview  

-     

-   TLS Sign is integrated as a higher-level module of the TLS Record 

-   protocol. It is optionally used if the two entities agree. This is 

-   negotiated by extending Client and Server Hello messages in the same 

-   way defined in [TLSExt]. 

-    

-   In order to allow a TLS client to negotiate the TLS Sign, a new 

-   extension type should be added to the Extended Client and Server 

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 2] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-   Hellos messages. TLS clients and servers MAY include an extension of 

-   type 'signature' in the Extended Client and Server Hellos messages. 

-   The 'extension_data' field of this extension contains a 

-   'signature_request' where:  

-     

-    enum {  

-          pkcs7(0), smime(1), xmldsig(2), (255);  

-       } ContentFormat;  

-    

-    struct {  

-            ContentFormat content_format;  

-            SignMethod sign_meth;  

-            SignType sign_type<2..2^16-1>;  

-         } SignatureRequest;  

-    

-    enum {  

-          ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);  

-       } SignMethod;  

-     

-    uint8 SignType[2]; 

-    

-   The client initiates the TLS Sign module by sending the 

-   ExtendedClientHello including the 'signature' extension. This 

-   extension contains:  

-    

-   - the SignType carrying the type of the non repudiation proof. It 

-   can have one of these two values: 

-    

-   SignType non_repudiation_with_proof_of_origin      = { 0x00, 0x01 }; 

-   SignType non_repudiation_without_proof_of_origin   = { 0x00, 0x02 }; 

-    

-   - the ContentFormat carrying the format of signed data. It can be 

-   PKCS7 [PKCS7], S/MIME [S/MIME] or XMLDSIG [XMLDSIG] 

-    

-             ContentFormat PKCS7   = { 0x00, 0xA1 }; 

-             ContentFormat SMIME   = { 0x00, 0xA2 }; 

-             ContentFormat XMLDSIG = { 0x00, 0xA3 }; 

-    

-         o if the value of the ContentFormat is PKCS7, then the PKCS7  

-           Content_type is of type signed-data. 

-    

-         o if the value of the ContentFormat is S/MIME, then S/MIME  

-           Content_type is of type SignedData 

-    

-         o if the value of the ContentFormat is XMLDSIG, then XMLDSIG  

-           signatureMethod algorithms. 

-    

-   - the SignMethod carrying the signature method that is used to sign 

-   the application data (e.g. X509  authentication certificate). 

-    

-               SignMethod X509 = { 0x00, 0xB1 }; 

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 3] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-    

-   Actually, this document uses the same certificate used in client 

-   authentication. Any new signature method MAY be added in future 

-   versions (e.g. delegated attributes certificates). 

-    

-   The server MAY reject the connection by sending the error alert 

-   "unsupported_extension" [TLSExt] and closing the connection. 

-    

-   The client and the server MAY or MAY NOT use the same certificates 

-   used by the Handshake protocol. Several cases are possible: 

-    

-   - If the server has an interest in getting non-repudiation data from 

-   the client and that the cipher_suites list sent by the client does 

-   not include any cipher_suite with signature ability, the server MUST 

-   (upon reception of tls_sign_on_off protocol message not followed by 

-   a certificate with a type equals to ExtendedServerHello.sign_method) 

-   close the connection by sending a fatal error. 

-    

-   - If the server has an interest in getting non-repudiation data from 

-   the client and that the cipher_suites list sent by the client 

-   includes at least a cipher_suite with signature ability, the server 

-   SHOULD select a cipher_suite with signature ability and MUST provide 

-   a certificate (e.g., RSA) that MAY be used for key exchange. 

-   Further, the server MUST request a certificate from the client using 

-   the TLS certificate request message (e.g., an RSA or a DSS 

-   signature-capable certificate). If the client does not send a 

-   certificate during the TLS Handshake, the server MUST close the TLS 

-   session by sending a fatal error in the case where the client sends 

-   a tls_sign_on_off protocol message not followed by a certificate 

-   with a type equals to ExtendedServerHello.sign_method. 

-    

-   - The client or the server MAY use a certificate different to these 

-   being used by TLS Handshake. This MAY happen when the server agrees 

-   in getting non-repudiation data from the client and that the type of 

-   the client certificate used by TLS Handshake and the type selected 

-   by the server from the list in ExtendedClientHello.sign_method are 

-   different, or when the ExtendedServerHello.cipher_suite does not 

-   require client and/or server certificates. In these cases, the 

-   client or the server sends a new message called certificate_sign, 

-   right after sending the tls_sign_on_off protocol messages. The new 

-   message contains the sender's certificate in which the type is the 

-   same type selected by the server from the list in 

-   ExtendedClientHello.sign_method. The certificate_sign is therefore 

-   used to generate signed data. It is defined as follows: 

-    

-       opaque ASN.1Cert<2^24-1>; 

-    

-       struct { 

-           ASN.1Cert certificate_list<1..2^24-1>; 

-       } CertificateSign; 

-    

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 4] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-   The certificate_list, as defined in [TLS], is a sequence (chain) of 

-   certificates. The sender's certificate MUST come first in the list. 

-    

-   If the server has no interest in getting non-repudiation data from 

-   the client, it replays with an ordinary TLS ServerHello or return a 

-   handshake failure alert and close the connection [TLS]. 

-    

-         Client                                               Server  

-         ------                                               ------  

-    

-         ClientHello             -------->  

-                                                         ServerHello  

-                                                        Certificate* 

-                                                  ServerKeyExchange*  

-                                                 CertificateRequest*  

-                                 <--------           ServerHelloDone  

-         Certificate*  

-         ClientKeyExchange  

-         CertificateVerify* 

-         [ChangeCipherSpec] 

-         Finished                -------->  

-                                                  [ChangeCipherSpec] 

-                                 <--------                  Finished 

-    

-         TLSSignOnOff   <-------------------------->    TLSSignOnOff 

-          

-         CertificateSign* <-----------------------> CertificateSign* 

-     

-         (Signed) Application Data <---->  (Signed) Application Data 

-    

-   * Indicates optional or situation-dependent messages that are not 

-   always sent. 

-    

-2.1 tls sign on off protocol  

-    

-   To manage the generation of evidence, new sub-protocol is added by 

-   this document, called tls_sign_on_off. This protocol consists of a 

-   single message that is encrypted and compressed under the 

-   established connection state. This message can be sent at any time 

-   after the TLS session has been established. Thus, no man in the 

-   middle can replay or inject this message. It consists of a single 

-   byte of value 1 (tls_sign_on) or 0 (tls_sign_off). 

-    

-       enum {   

-             change_cipher_spec(20), alert(21), handshake(22),   

-             application_data(23), tls_sign(TBC), (255)   

-          } ContentType;   

-      

-       struct {   

-               enum { tls_sign_off(0), tls_sign_on(1), (255) } type;   

-            } TLSSignOnOff;  

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 5] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-    

-   The tls_sign_on_off message is sent by the client and/or server to 

-   notify the receiving party that subsequent records will carry data 

-   signed under the negotiated parameters.   

-    

-   Note: TLSSignOnOff is an independent TLS Protocol content type, and 

-   is not actually a TLS handshake message. 

-    

- 2.1.1 TLS sign packet format  

-    

-   This document defines a new packet format that encapsulates signed 

-   data, the TLSSigntext. The packet format is shown below. The fields 

-   are transmitted from left to right.  

-    

-   0                   1                   2                   3        

-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

-   | Content-Type  |     Flag      |     Version                   |   

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

-   |              Length           |  Signed Data ...  

-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

-    

-   Content-Type 

-    

-   Same as TLSPlaintext.type. 

-    

-   Flag 

-    

-   0 1 2 3 4 5 6 7 8  

-   +-+-+-+-+-+-+-+-+   

-   |A R R R R R R R|   

-   +-+-+-+-+-+-+-+-+   

-    

-   A = acknowledgement of receipt 

-   R = Reserved 

-    

-   When the whole signed data is delivered to the receiver, the TLS 

-   Sign will check the signature. If the signature is valid and that 

-   the sender requires a proof of receipt, the receiver MUST generate a 

-   TLSSigntext packet with the bit A set to 1 (acknowledgement of 

-   receipt). This helps the receiver of the acknowledgment of receipt 

-   in storing the data-field for later use (see section 2.2). The data-

-   field of that message contains the digest of the whole data receiver 

-   by the generator of the acknowledgement of receipt. The digest is 

-   signed before sending the result to the other side. 

-    

-    2.1.3 bad_sign alert 

-    

-   This alert is returned if a record is received with an incorrect 

-   signature. This message is always fatal. 

-    

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 6] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-2.2 Storing signed data  

-    

-   The objective of TLS Sign is to provide both parties with evidence 

-   that can be stored and later presented to a third party to resolve 

-   disputes that arise if and when a communication is repudiated by one 

-   of the entities involved. This document provides the two basic types 

-   of non-repudiation service:  

-    

-   o   Non-repudiation with proof of origin: provides the TLS server   

-       with evidence proving that the TLS client has sent it the signed   

-       data at a certain time.  

-    

-   o   Non-repudiation with proof of delivery: provides the TLS client   

-       with evidence that the server has received the client's signed   

-       data at a specific time.  

-    

-   TLS Handshake exchanges the current time and date according to the 

-   entities internal clock. Thus, the time and date can be stored with 

-   the signed data as a proof of communication. For B2C or B2B 

-   transactions, non-repudiation with proof of origin and non-

-   repudiation with proof of receipt are both important. If the TLS 

-   client requests a non-repudiation service with proof of receipt, the 

-   server SHOULD verify and send back to client a signature on the hash 

-   of signed data.  

-    

-   The following figure explains the different events for proving and 

-   storing signed data [RFC2828]. RFC 2828 uses the term "critical 

-   action" to refer to the act of communication between the two 

-   entities. For a complete non-repudiation deployment, 6 phases should 

-   be respected: 

-    

-   --------   --------   --------   --------   --------     --------  

-   Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:     Phase 6:  

-   Request    Generate   Transfer   Verify     Retain       Resolve  

-   Service    Evidence   Evidence   Evidence   Evidence     Dispute  

-   --------   --------   --------   --------   --------     --------  

-   Service    Critical   Evidence   Evidence   Archive      Evidence  

-   Request => Action  => Stored  => Is      => Evidence     Is  

-   Is Made    Occurs     For Later  Tested     In Case      Verified  

-              and        Use |          ^      Critical         ^  

-              Evidence       v          |      Action Is        |  

-              Is         +-------------------+ Repudiated       |  

-              Generated  |Verifiable Evidence|------>       ----+  

-                         +-------------------+  

-    

-   1- Requesting explicit transaction evidence before sending data. 

-   Normally, this action is taken by the SSL/TLS client  

-    

-   2- If the server accepts, the client will generate evidence by 

-   signing data using his X.509 authentication certificate. Server will 

-   go through the same process if the evidence of receipt is requested. 

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 7] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-    

-   3 - The signed data is then sent by the initiator (client or server) 

-   and stored it locally, or by a third party, for a later use if 

-   needed. 

-    

-   4 - The entity that receive the evidence process to verify the 

-   signed data. 

-    

-   5- The evidence is then stored by the receiver entity for a later 

-   use if needed. 

-    

-   6- In this phase, which occurs only if the critical action is 

-   repudiated, the evidence is retrieved from storage, presented, and 

-   verified to resolve the dispute. 

-    

-   With this method, the stored signed data (or evidence) can be 

-   retrieved by both parties, presented and verified if the critical 

-   action is repudiated. 

-    

-Security Considerations 

-    

-   Security issues are discussed throughout this memo. 

-    

-IANA Considerations 

-    

-   This document defines a new TLS extension "signature", assigned the 

-   value TBD from the TLS ExtensionType registry defined in [TLSEXT]. 

-    

-   This document defines one TLS ContentType: tls_sign(TBD). This 

-   ContentType value is assigned from the TLS ContentType registry 

-   defined in [TLS]. 

-    

-   This document defines a new handshake message, certificate_sign, 

-   whose value is to be allocated from the TLS HandshakeType registry 

-   defined in [TLS]. 

-    

-   The bad_sign alert that is defined in this document is assigned to 

-   the TLS Alert registry defined in [TLS]. 

-    

-References 

-    

-   [TLS]     Dierks, T., et. al., "The TLS Protocol Version 1.0",  

-             RFC 2246, January 1999. 

-    

-   [TLSExt]  Blake-Wilson, S., et. al., "Transport Layer Security TLS)  

-             Extensions", RFC 3546, June 2003. 

-    

-   [PKCS7]   RSA Laboratories, "PKCS #7: RSA Cryptographic Message  

-             Syntax Standard," version 1.5, November 1993.  

-        

-   [S/MIME]  Ramsdell, B., "S/MIME Version 3 Message Specification",  

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 8] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-             RFC 2633, June 1999.  

-    

-   [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML  

-             Signature Syntax and Processing", RFC 3275, March 2002.  

-    

-   [TLSSign] Hajjeh, I., Serhrouchni, A., "Integrating a signature   

-             module in SSL/TLS, ICETE2004., ACM/IEEE, First   

-             International Conference on E-Business and  

-             Telecommunication Networks, Portugal, August 2004.  

-    

-   [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May   

-             2000. 

-    

-Author's and Contributors' Addresses 

-    

-   Ibrahim Hajjeh  

-   Engineering and Scientific Research Groups (ESRGroups) 

-   17 Passage Barrault  

-   75013 Paris               Phone: NA  

-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 

-    

-   Mohamad Badra 

-   LIMOS Laboratory - UMR (6158), CNRS 

-   France                    Email: badra@isima.fr 

-    

-   Ahmed serhrouchni  

-   ENST                      Phone: NA  

-   France                    Email: Ahmed.serhrouchni@enst.fr  

-    

-   Jacques Demerjian  

-   France Telecom R&D  

-   42 rue des coutures  

-   14066 Caen Cedex 4        Phone: NA  

-   France                    Email: jacques.demerjian@francetelecom.com 

-    

-   Acknowledgements  

-    

-   The authors would like to thank Eric Rescorla for discussions and 

-   comments on the design of TLS Sign. 

-    

-Appendix  Changelog 

-    

-   Changes from -01 to -02: 

-    

-   o Add an IANA section. 

-    

-   o Small clarifications to section 2.  

-    

-   o Add the bad_sign alert and the certificate_sign message. 

-    

-   Changes from -00 to -01: 

-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 9] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-    

-   o Clarifications to the format of the signed data in Section 2. 

-    

-   o Small clarifications to TLS SIGN negotiation in Section 2. 

-    

-   o Added Jacques Demerjian and Mohammed Achemlal as 

-     contributors/authors. 

-    

-   Intellectual Property Statement  

-     

-   The IETF takes no position regarding the validity or scope of any 

-   Intellectual Property Rights or other rights that might be claimed 

-   to pertain to the implementation or use of the technology described 

-   in this document or the extent to which any license under such 

-   rights might or might not be available; nor does it represent that 

-   it has made any independent effort to identify any such rights. 

-   Information on the IETF's procedures with respect to rights in IETF 

-   Documents can be found in BCP 78 and BCP 79. 

-    

-   Copies of IPR disclosures made to the IETF Secretariat and any 

-   assurances of licenses to be made available, or the result of an 

-   attempt made to obtain a general license or permission for the use 

-   of such proprietary rights by implementers or users of this 

-   specification can be obtained from the IETF on-line IPR repository 

-   at http://www.ietf.org/ipr. 

-    

-   The IETF invites any interested party to bring to its attention any 

-   copyrights, patents or patent applications, or other proprietary 

-   rights that may cover technology that may be required to implement 

-   this standard. Please address the information to the IETF at ietf-

-   ipr@ietf.org. 

-    

-   Disclaimer of Validity 

-    

-   This document and the information contained herein are provided on 

-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 

-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 

-   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 

-   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  

-    

-   Copyright Statement 

-     

-   Copyright (C) The Internet Society (2006). This document is subject 

-   to the rights, licenses and restrictions contained in BCP 78, and 

-   except as set forth therein, the authors retain all their rights. 

-    

-   Acknowledgment  

-    

-
-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 10] 

-INTERNET-DRAFT                   TLS Sign                 November 2006 

-
-   Funding for the RFC Editor function is currently provided by the 

-   Internet Society. 

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 

-Hajjeh, et. al.              Expires April 2007               [Page 11] 
\ No newline at end of file
diff --git a/doc/protocol/draft-hajjeh-tls-sign-03.txt b/doc/protocol/draft-hajjeh-tls-sign-03.txt
deleted file mode 100644
index c0a9b1cb76..0000000000
--- a/doc/protocol/draft-hajjeh-tls-sign-03.txt
+++ /dev/null
@@ -1,561 +0,0 @@
-
-
-
-Internet Engineering Task Force                               I. Hajjeh 
-INTERNET DRAFT                                                ESRGroups 
-                                                               M. Badra 
-                                                       LIMOS Laboratory 
- 
-Expires: November 2007                                        June 2007 
-    
-                                  TLS Sign  
-                       <draft-hajjeh-tls-sign-03.txt> 
-    
-    
-Status 
-    
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-    
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups. Note that 
-   other groups may also distribute working documents as Internet- 
-   Drafts. 
-    
-   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  
-    
-   This Internet-Draft will expire on November 2007. 
-    
-Copyright Notice 
-    
-   Copyright (C) The IETF Trust (2007). 
-    
-Abstract  
-     
-   TLS protocol provides authentication and data protection for 
-   communication between two entities. However, missing from the 
-   protocol is a way to perform non-repudiation service.  
-     
-   This document defines extensions to the TLS protocol to allow it to 
-   perform non-repudiation service. It is based on [TLSSign] and it 
-   provides the client and the server the ability to sign by TLS, 
-   handshake and applications data using certificates such as X.509. 
-    
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 1] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-1 Introduction 
-    
-   Actually, TLS is the most deployed security protocol for securing 
-   exchanges. It provides end-to-end secure communications between two 
-   entities with authentication and data protection. However, what is 
-   missing from the protocol is a way to provide the non-repudiation 
-   service. 
-    
-   This document describes how the non-repudiation service may be 
-   integrated as an optional module in TLS. This is in order to provide 
-   both parties with evidence that the transaction has taken place and 
-   to offer a clear separation with application design and development.  
-    
-   TLS-Sign's design motivations included:  
-     
-   o   TLS is application protocol-independent. Higher-level protocol   
-       can operate on top of the TLS protocol transparently.  
-     
-   o   TLS is a modular nature protocol. Since TLS is developed in four  
-       independent protocols, the approach defined in this document can  
-       be added by extending the TLS protocol and with a total 
-       reuse of pre-existing TLS infrastructures and implementations.  
-        
-   o   Several applications like E-Business require non-repudiation   
-       proof of transactions. It is critical in these applications to   
-       have the non-repudiation service that generates, distributes,   
-       validates and maintains the evidence of an electronic   
-       transaction. Since TLS is widely used to secure these   
-       applications exchanges, the non-repudiation should be offered by   
-       TLS.  
-        
-   o   Generic non-repudiation with TLS. TLS Sign provides a generic   
-       non-repudiation service that can be easily used with protocols.    
-       TLS Sign minimizes both design and implementation of the   
-       signature service and that of the designers and implementators   
-       who wish to use this module. 
-    
-1.2 Requirements language 
-    
-   The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document 
-   are to be interpreted as described in RFC-2119. 
-    
-2 TLS Sign overview  
-     
-   TLS Sign is integrated as a higher-level module of the TLS Record 
-   protocol. It is optionally used if the two entities agree. This is 
-   negotiated by extending Client and Server Hello messages in the same 
-   way defined in [TLSExt]. 
-    
-   In order to allow a TLS client to negotiate the TLS Sign, a new 
-   extension type should be added to the Extended Client and Server 
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 2] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-   Hellos messages. TLS clients and servers MAY include an extension of 
-   type 'signature' in the Extended Client and Server Hellos messages. 
-   The 'extension_data' field of this extension contains a 
-   'signature_request' where:  
-     
-    enum {  
-          pkcs7(0), smime(1), xmldsig(2), (255);  
-       } ContentFormat;  
-    
-    struct {  
-            ContentFormat content_format;  
-            SignMethod sign_meth;  
-            SignType sign_type<2..2^16-1>;  
-         } SignatureRequest;  
-    
-    enum {  
-          ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255);  
-       } SignMethod;  
-     
-    uint8 SignType[2]; 
-    
-   The client initiates the TLS Sign module by sending the 
-   ExtendedClientHello including the 'signature' extension. This 
-   extension contains:  
-    
-   - the SignType carrying the type of the non repudiation proof. It 
-   can have one of these two values: 
-    
-   SignType non_repudiation_with_proof_of_origin      = { 0x00, 0x01 }; 
-   SignType non_repudiation_without_proof_of_origin   = { 0x00, 0x02 }; 
-    
-   - the ContentFormat carrying the format of signed data. It can be 
-   PKCS7 [PKCS7], S/MIME [S/MIME] or XMLDSIG [XMLDSIG] 
-    
-             ContentFormat PKCS7   = { 0x00, 0xA1 }; 
-             ContentFormat SMIME   = { 0x00, 0xA2 }; 
-             ContentFormat XMLDSIG = { 0x00, 0xA3 }; 
-    
-         o if the value of the ContentFormat is PKCS7, then the PKCS7  
-           Content_type is of type signed-data. 
-    
-         o if the value of the ContentFormat is S/MIME, then S/MIME  
-           Content_type is of type SignedData 
-    
-         o if the value of the ContentFormat is XMLDSIG, then XMLDSIG  
-           signatureMethod algorithms. 
-    
-   - the SignMethod carrying the signature method that is used to sign 
-   the application data (e.g. X509  authentication certificate). 
-    
-               SignMethod X509 = { 0x00, 0xB1 }; 
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 3] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-    
-   Actually, this document uses the same certificate used in client 
-   authentication. Any new signature method MAY be added in future 
-   versions (e.g. delegated attributes certificates). 
-    
-   The server MAY reject the connection by sending the error alert 
-   "unsupported_extension" [TLSExt] and closing the connection. 
-    
-   The client and the server MAY or MAY NOT use the same certificates 
-   used by the Handshake protocol. Several cases are possible: 
-    
-   - If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client does 
-   not include any cipher_suite with signature ability, the server MUST 
-   (upon reception of tls_sign_on_off protocol message not followed by 
-   a certificate with a type equals to ExtendedServerHello.sign_method) 
-   close the connection by sending a fatal error. 
-    
-   - If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client 
-   includes at least a cipher_suite with signature ability, the server 
-   SHOULD select a cipher_suite with signature ability and MUST provide 
-   a certificate (e.g., RSA) that MAY be used for key exchange. 
-   Further, the server MUST request a certificate from the client using 
-   the TLS certificate request message (e.g., an RSA or a DSS 
-   signature-capable certificate). If the client does not send a 
-   certificate during the TLS Handshake, the server MUST close the TLS 
-   session by sending a fatal error in the case where the client sends 
-   a tls_sign_on_off protocol message not followed by a certificate 
-   with a type equals to ExtendedServerHello.sign_method. 
-    
-   - The client or the server MAY use a certificate different to these 
-   being used by TLS Handshake. This MAY happen when the server agrees 
-   in getting non-repudiation data from the client and that the type of 
-   the client certificate used by TLS Handshake and the type selected 
-   by the server from the list in ExtendedClientHello.sign_method are 
-   different, or when the ExtendedServerHello.cipher_suite does not 
-   require client and/or server certificates. In these cases, the 
-   client or the server sends a new message called certificate_sign, 
-   right after sending the tls_sign_on_off protocol messages. The new 
-   message contains the sender's certificate in which the type is the 
-   same type selected by the server from the list in 
-   ExtendedClientHello.sign_method. The certificate_sign is therefore 
-   used to generate signed data. It is defined as follows: 
-    
-       opaque ASN.1Cert<2^24-1>; 
-    
-       struct { 
-           ASN.1Cert certificate_list<1..2^24-1>; 
-       } CertificateSign; 
-    
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 4] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-   The certificate_list, as defined in [TLS], is a sequence (chain) of 
-   certificates. The sender's certificate MUST come first in the list. 
-    
-   If the server has no interest in getting non-repudiation data from 
-   the client, it replays with an ordinary TLS ServerHello or return a 
-   handshake failure alert and close the connection [TLS]. 
-    
-         Client                                               Server  
-         ------                                               ------  
-    
-         ClientHello             -------->  
-                                                         ServerHello  
-                                                        Certificate* 
-                                                  ServerKeyExchange*  
-                                                 CertificateRequest*  
-                                 <--------           ServerHelloDone  
-         Certificate*  
-         ClientKeyExchange  
-         CertificateVerify* 
-         [ChangeCipherSpec] 
-         Finished                -------->  
-                                                  [ChangeCipherSpec] 
-                                 <--------                  Finished 
-    
-         TLSSignOnOff   <-------------------------->    TLSSignOnOff 
-          
-         CertificateSign* <-----------------------> CertificateSign* 
-     
-         (Signed) Application Data <---->  (Signed) Application Data 
-    
-   * Indicates optional or situation-dependent messages that are not 
-   always sent. 
-    
-2.1 tls sign on off protocol  
-    
-   To manage the generation of evidence, new sub-protocol is added by 
-   this document, called tls_sign_on_off. This protocol consists of a 
-   single message that is encrypted and compressed under the 
-   established connection state. This message can be sent at any time 
-   after the TLS session has been established. Thus, no man in the 
-   middle can replay or inject this message. It consists of a single 
-   byte of value 1 (tls_sign_on) or 0 (tls_sign_off). 
-    
-       enum {   
-             change_cipher_spec(20), alert(21), handshake(22),   
-             application_data(23), tls_sign(TBC), (255)   
-          } ContentType;   
-      
-       struct {   
-               enum { tls_sign_off(0), tls_sign_on(1), (255) } type;   
-            } TLSSignOnOff;  
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 5] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-    
-   The tls_sign_on_off message is sent by the client and/or server to 
-   notify the receiving party that subsequent records will carry data 
-   signed under the negotiated parameters.   
-    
-   Note: TLSSignOnOff is an independent TLS Protocol content type, and 
-   is not actually a TLS handshake message. 
-    
- 2.1.1 TLS sign packet format  
-    
-   This document defines a new packet format that encapsulates signed 
-   data, the TLSSigntext. The packet format is shown below. The fields 
-   are transmitted from left to right.  
-    
-   0                   1                   2                   3        
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
-   | Content-Type  |     Flag      |     Version                   |   
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
-   |              Length           |  Signed Data ...  
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
-    
-   Content-Type 
-    
-   Same as TLSPlaintext.type. 
-    
-   Flag 
-    
-   0 1 2 3 4 5 6 7 8  
-   +-+-+-+-+-+-+-+-+   
-   |A R R R R R R R|   
-   +-+-+-+-+-+-+-+-+   
-    
-   A = acknowledgement of receipt 
-   R = Reserved 
-    
-   When the whole signed data is delivered to the receiver, the TLS 
-   Sign will check the signature. If the signature is valid and that 
-   the sender requires a proof of receipt, the receiver MUST generate a 
-   TLSSigntext packet with the bit A set to 1 (acknowledgement of 
-   receipt). This helps the receiver of the acknowledgment of receipt 
-   in storing the data-field for later use (see section 2.2). The data-
-   field of that message contains the digest of the whole data receiver 
-   by the generator of the acknowledgement of receipt. The digest is 
-   signed before sending the result to the other side. 
-    
-    2.1.3 bad_sign alert 
-    
-   This alert is returned if a record is received with an incorrect 
-   signature. This message is always fatal. 
-    
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 6] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-2.2 Storing signed data  
-    
-   The objective of TLS Sign is to provide both parties with evidence 
-   that can be stored and later presented to a third party to resolve 
-   disputes that arise if and when a communication is repudiated by one 
-   of the entities involved. This document provides the two basic types 
-   of non-repudiation service:  
-    
-   o   Non-repudiation with proof of origin: provides the TLS server   
-       with evidence proving that the TLS client has sent it the signed   
-       data at a certain time.  
-    
-   o   Non-repudiation with proof of delivery: provides the TLS client   
-       with evidence that the server has received the client's signed   
-       data at a specific time.  
-    
-   TLS Handshake exchanges the current time and date according to the 
-   entities internal clock. Thus, the time and date can be stored with 
-   the signed data as a proof of communication. For B2C or B2B 
-   transactions, non-repudiation with proof of origin and non-
-   repudiation with proof of receipt are both important. If the TLS 
-   client requests a non-repudiation service with proof of receipt, the 
-   server SHOULD verify and send back to client a signature on the hash 
-   of signed data.  
-    
-   The following figure explains the different events for proving and 
-   storing signed data [RFC2828]. RFC 2828 uses the term "critical 
-   action" to refer to the act of communication between the two 
-   entities. For a complete non-repudiation deployment, 6 phases should 
-   be respected: 
-    
-   --------   --------   --------   --------   --------     --------  
-   Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:     Phase 6:  
-   Request    Generate   Transfer   Verify     Retain       Resolve  
-   Service    Evidence   Evidence   Evidence   Evidence     Dispute  
-   --------   --------   --------   --------   --------     --------  
-   Service    Critical   Evidence   Evidence   Archive      Evidence  
-   Request => Action  => Stored  => Is      => Evidence     Is  
-   Is Made    Occurs     For Later  Tested     In Case      Verified  
-              and        Use |          ^      Critical         ^  
-              Evidence       v          |      Action Is        |  
-              Is         +-------------------+ Repudiated       |  
-              Generated  |Verifiable Evidence|------>       ----+  
-                         +-------------------+  
-    
-   1- Requesting explicit transaction evidence before sending data. 
-   Normally, this action is taken by the SSL/TLS client  
-    
-   2- If the server accepts, the client will generate evidence by 
-   signing data using his X.509 authentication certificate. Server will 
-   go through the same process if the evidence of receipt is requested. 
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 7] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-    
-   3 - The signed data is then sent by the initiator (client or server) 
-   and stored it locally, or by a third party, for a later use if 
-   needed. 
-    
-   4 - The entity that receive the evidence process to verify the 
-   signed data. 
-    
-   5- The evidence is then stored by the receiver entity for a later 
-   use if needed. 
-    
-   6- In this phase, which occurs only if the critical action is 
-   repudiated, the evidence is retrieved from storage, presented, and 
-   verified to resolve the dispute. 
-    
-   With this method, the stored signed data (or evidence) can be 
-   retrieved by both parties, presented and verified if the critical 
-   action is repudiated. 
-    
-Security Considerations 
-    
-   Security issues are discussed throughout this memo. 
-    
-IANA Considerations 
-    
-   This document defines a new TLS extension "signature", assigned the 
-   value TBD from the TLS ExtensionType registry defined in [TLSEXT]. 
-    
-   This document defines one TLS ContentType: tls_sign(TBD). This 
-   ContentType value is assigned from the TLS ContentType registry 
-   defined in [TLS]. 
-    
-   This document defines a new handshake message, certificate_sign, 
-   whose value is to be allocated from the TLS HandshakeType registry 
-   defined in [TLS]. 
-    
-   The bad_sign alert that is defined in this document is assigned to 
-   the TLS Alert registry defined in [TLS]. 
-    
-References 
-    
-   [TLS]     Dierks, T., et. al., "The TLS Protocol Version 1.0",  
-             RFC 2246, January 1999. 
-    
-   [TLSExt]  Blake-Wilson, S., et. al., "Transport Layer Security TLS)  
-             Extensions", RFC 3546, June 2003. 
-    
-   [PKCS7]   RSA Laboratories, "PKCS #7: RSA Cryptographic Message  
-             Syntax Standard," version 1.5, November 1993.  
-        
-   [S/MIME]  Ramsdell, B., "S/MIME Version 3 Message Specification",  
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 8] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-             RFC 2633, June 1999.  
-    
-   [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML  
-             Signature Syntax and Processing", RFC 3275, March 2002.  
-    
-   [TLSSign] Hajjeh, I., Serhrouchni, A., "Integrating a signature   
-             module in SSL/TLS, ICETE2004., ACM/IEEE, First   
-             International Conference on E-Business and  
-             Telecommunication Networks, Portugal, August 2004.  
-    
-   [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May   
-             2000. 
-    
-Author's Addresses 
-    
-   Ibrahim Hajjeh 
-   Engineering and Scientific Research Groups (ESRGroups) 
-   82 rue Baudricourt 
-   75013 Paris               Phone: NA  
-   France                    Email: Ibrahim.Hajjeh@esrgroups.org 
-    
-   Mohamad Badra 
-   LIMOS Laboratory - UMR 6158, CNRS 
-   France                    Email: badra@isima.fr 
-    
-   Acknowledgements  
-    
-   The authors would like to thank Eric Rescorla for discussions and 
-   comments on the design of TLS Sign. 
-    
-Appendix  Changelog 
-    
-   Changes from -01 to -02: 
-    
-   o Add an IANA section. 
-    
-   o Small clarifications to section 2.  
-    
-   o Add the bad_sign alert and the certificate_sign message. 
-    
-   Changes from -00 to -01: 
-    
-   o Clarifications to the format of the signed data in Section 2. 
-    
-   o Small clarifications to TLS SIGN negotiation in Section 2. 
-    
-   o Added Jacques Demerjian and Mohammed Achemlal as 
-     contributors/authors. 
-    
-   Full Copyright Statement 
-    
-
- 
-Hajjeh & Badra            Expires November 2007                [Page 9] 
-INTERNET-DRAFT                   TLS Sign                     June 2007 
-
-   Copyright (C) The IETF Trust (2007). 
-    
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-    
-   This document and the information contained herein are provided on 
-   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
-   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
-   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 
-   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
-   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
-   FOR A PARTICULAR PURPOSE. 
-    
-   Intellectual Property 
-    
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed 
-   to pertain to the implementation or use of the technology described 
-   in this document or the extent to which any license under such 
-   rights might or might not be available; nor does it represent that 
-   it has made any independent effort to identify any such rights.  
-   Information on the procedures with respect to rights in RFC 
-   documents can be found in BCP 78 and BCP 79. 
-    
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use 
-   of such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository 
-   at http://www.ietf.org/ipr. 
-    
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org. 
-    
-   Acknowledgement 
-    
-   Funding for the RFC Editor function is provided by the IETF 
-   Administrative Support Activity (IASA). 
-
-
-
-
-
-
-
-
-
- 
-Hajjeh & Badra            Expires November 2007               [Page 10] 
\ No newline at end of file
diff --git a/doc/protocol/draft-hajjeh-tls-sign-04.txt b/doc/protocol/draft-hajjeh-tls-sign-04.txt
deleted file mode 100644
index 3dc77cbcee..0000000000
--- a/doc/protocol/draft-hajjeh-tls-sign-04.txt
+++ /dev/null
@@ -1,647 +0,0 @@
-TLS Working Group                                             I. Hajjeh 
-Internet Draft                                               INEOVATION 
-                                                               M. Badra 
-                                                       LIMOS Laboratory 
-Intended status: Experimental                         December 15, 2007 
-Expires: June 2008 
-                                    
- 
-                                      
-                                 TLS Sign 
-                       draft-hajjeh-tls-sign-04.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on June 15, 2007. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2007). 
-
-Abstract 
-
-   TLS protocol provides authentication and data protection for 
-   communication between two entities. However, missing from the 
-   protocol is a way to perform non-repudiation service.  
-
- 
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 1] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   This document defines extensions to the TLS protocol to allow it to 
-   perform non-repudiation service. It is based on [TLSSIGN] and it 
-   provides the client and the server the ability to sign by TLS, 
-   handshake and applications data using certificates such as X.509. 
-
-Table of Contents 
-
-    
-   1. Introduction...................................................2 
-      1.1. Conventions used in this document.........................3 
-   2. TLS Sign overview..............................................3 
-      2.1. tls sign on off protocol..................................6 
-         2.1.1. bad_sign alert.......................................7 
-      2.2. Storing signed data.......................................7 
-   3. Security Considerations........................................9 
-   4. IANA Considerations............................................9 
-   5. References.....................................................9 
-      5.1. Normative References......................................9 
-      5.2. Informative References...................................10 
-   Author's Addresses...............................................10 
-   Appendix Changelog...............................................10 
-   Intellectual Property Statement..................................11 
-   Disclaimer of Validity...........................................11 
-    
-1. Introduction 
-
-   Actually, TLS is the most deployed security protocol for securing 
-   exchanges. It provides end-to-end secure communications between two 
-   entities with authentication and data protection. However, what is 
-   missing from the protocol is a way to provide the non-repudiation 
-   service.  
-
-   This document describes how the non-repudiation service may be 
-   integrated as an optional module in TLS. This is in order to provide 
-   both parties with evidence that the transaction has taken place and 
-   to offer a clear separation with application design and development. 
-
-   TLS-Sign's design motivations included: 
-
-   O  TLS is application protocol-independent. Higher-level protocol can 
-      operate on top of the TLS protocol transparently. 
-
-   O  TLS is a modular nature protocol. Since TLS is developed in four 
-      independent protocols, the approach defined in this document can 
-      be added by extending the TLS protocol and with a total reuse of 
-      pre-existing TLS infrastructures and implementations. 
-
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 2] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   O  Several applications like E-Business require non-repudiation proof 
-      of transactions. It is critical in these applications to have the 
-      non-repudiation service that generates, distributes, validates and 
-      maintains the evidence of an electronic transaction. Since TLS is 
-      widely used to secure these applications exchanges, the non-
-      repudiation should be offered by TLS. 
-
-   O  Generic non-repudiation with TLS. TLS Sign provides a generic non-
-      repudiation service that can be easily used with protocols. TLS 
-      Sign minimizes both design and implementation of the signature 
-      service and that of the designers and implementators who wish to 
-      use this module. 
-
-1.1. 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 [RFC2119]. 
-
-2. TLS Sign overview 
-
-   TLS Sign is integrated as a higher-level module of the TLS Record 
-   protocol. It is optionally used if the two entities agree. This is 
-   negotiated by extending Client and Server Hello messages in the same 
-   way defined in [TLSEXT]. 
-
-   In order to allow a TLS client to negotiate the TLS Sign, a new 
-   extension type should be added to the Extended Client and Server 
-   Hellos messages. TLS clients and servers MAY include an extension of 
-   type 'signature' in the Extended Client and Server Hellos messages. 
-   The 'extension_data' field of this extension contains a 
-   'signature_request' where: 
-
-      enum { 
-            pkcs7(0), smime(1), xmldsig(2), (255);   
-         } ContentFormat;   
-
-      struct { 
-              ContentFormat content_format; 
-              SignMethod sign_meth; 
-              SignType sign_type<2..2^16-1>; 
-           } SignatureRequest;   
-
-      enum { 
-            ssl_client_auth_cert(0), ssl_client_auth_cert_url(1), (255); 
-         } SignMethod;   
-
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 3] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-      uint8 SignType[2];  
-
-   The client initiates the TLS Sign module by sending the 
-   ExtendedClientHello including the 'signature' extension. This 
-   extension contains: 
-
-   - the SignType carrying the type of the non repudiation proof. It can 
-   have one of these two values:  
-
-   SignType non_repudiation_with_proof_of_origin      = { 0x00, 0x01 }; 
-   SignType non_repudiation_without_proof_of_origin   = { 0x00, 0x02 };  
-
-   - the ContentFormat carrying the format of signed data. It can be 
-   PKCS7 [PKCS7], S/MIME [SMIME] or XMLDSIG [XMLDSIG]  
-
-            ContentFormat PKCS7   = { 0x00, 0xA1 };  
-            ContentFormat SMIME   = { 0x00, 0xA2 };  
-            ContentFormat XMLDSIG = { 0x00, 0xA3 };  
-
-         o if the value of the ContentFormat is PKCS7, then the PKCS7 
-         Content_type is of type signed-data.  
-
-         o if the value of the ContentFormat is S/MIME, then S/MIME 
-         Content_type is of type SignedData  
-
-         o if the value of the ContentFormat is XMLDSIG, then XMLDSIG 
-         signatureMethod algorithms.  
-
-   - the SignMethod carrying the signature method that is used to sign 
-   the application data (e.g. X509  authentication certificate). 
-
-            SignMethod X509 = { 0x00, 0xB1 };  
-
-   Actually, this document uses the same certificate used in client 
-   authentication. Any new signature method MAY be added in future 
-   versions (e.g. delegated attributes certificates).  
-
-   The server MAY reject the connection by sending the error alert 
-   "unsupported_extension" [TLSEXT] and closing the connection. 
-
-   The client and the server MAY use the same certificates used by the 
-   Handshake protocol. Several cases are possible:  
-
-   - If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client does 
-   not include any cipher_suite with signature ability, the server MUST 
-   (upon reception of tls_sign_on_off protocol message not followed by a 
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 4] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   certificate with a type equals to ExtendedServerHello.sign_method) 
-   close the connection by sending a fatal error.  
-
-   - If the server has an interest in getting non-repudiation data from 
-   the client and that the cipher_suites list sent by the client 
-   includes at least a cipher_suite with signature ability, the server 
-   SHOULD select a cipher_suite with signature ability and MUST provide 
-   a certificate (e.g., RSA) that MAY be used for key exchange. Further, 
-   the server MUST request a certificate from the client using the TLS 
-   certificate request message (e.g., an RSA or a DSS signature-capable 
-   certificate). If the client does not send a certificate during the 
-   TLS Handshake, the server MUST close the TLS session by sending a 
-   fatal error in the case where the client sends a tls_sign_on_off 
-   protocol message not followed by a certificate with a type equals to 
-   ExtendedServerHello.sign_method. 
-
-   - The client or the server MAY use a certificate different to these 
-   being used by TLS Handshake. This MAY happen when the server agrees 
-   in getting non-repudiation data from the client and that the type of 
-   the client certificate used by TLS Handshake and the type selected by 
-   the server from the list in ExtendedClientHello.sign_method are 
-   different, or when the ExtendedServerHello.cipher_suite does not 
-   require client and/or server certificates. In these cases, the client 
-   or the server sends a new message called certificate_sign, right 
-   after sending the tls_sign_on_off protocol messages. The new message 
-   contains the sender's certificate in which the type is the same type 
-   selected by the server from the list in 
-   ExtendedClientHello.sign_method. The certificate_sign is therefore 
-   used to generate signed data. It is defined as follows:  
-
-      opaque ASN.1Cert<2^24-1>;  
-
-      struct { 
-              ASN.1Cert certificate_list<1..2^24-1>; 
-           } CertificateSign;  
-
-   The certificate_list, as defined in [TLS], is a sequence (chain) of 
-   certificates. The sender's certificate MUST come first in the list. 
-   If the server has no interest in getting non-repudiation data from 
-   the client, it replays with an ordinary TLS ServerHello or return a 
-   handshake failure alert and close the connection [TLS].  
-
-       Client                                               Server 
-
-       ClientHello             --------> 
-                                                       ServerHello 
-                                                      Certificate* 
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 5] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-                                                ServerKeyExchange* 
-                                               CertificateRequest* 
-                              <--------            ServerHelloDone 
-       Certificate* 
-       ClientKeyExchange 
-       CertificateVerify* 
-       ChangeCipherSpec 
-       Finished                --------> 
-                                                  ChangeCipherSpec 
-                            <--------                     Finished 
-       TLSSignOnOff   <------------------------->     TLSSignOnOff 
-       CertificateSign* <---------------------->  CertificateSign* 
-       (Signed) Application Data <-----> (Signed) Application Data 
-
-   * Indicates optional or situation-dependent messages that are not 
-   always sent. 
-
-2.1. tls sign on off protocol   
-
-   To manage the generation of evidence, new sub-protocol is added by 
-   this document, called tls_sign_on_off. This protocol consists of a 
-   single message that is encrypted and compressed under the established 
-   connection state. This message can be sent at any time after the TLS 
-   session has been established. Thus, no man in the middle can replay 
-   or inject this message. It consists of a single byte of value 1 
-   (tls_sign_on) or 0 (tls_sign_off). 
-
-      enum { 
-            change_cipher_spec(20), alert(21), handshake(22), 
-            application_data(23), tls_sign(TBC), (255)    
-         } ContentType; 
-
-      struct { 
-              enum { tls_sign_off(0), tls_sign_on(1), (255) } type; 
-           } TLSSignOnOff;   
-
-   The tls_sign_on_off message is sent by the client and/or server to 
-   notify the receiving party that subsequent records will carry data 
-   signed under the negotiated parameters. 
-
-   Note: TLSSignOnOff is an independent TLS Protocol content type, and 
-   is not actually a TLS handshake message.  
-
-   2.1.1 TLS sign packet format 
-
-
-
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 6] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   This document defines a new packet format that encapsulates signed 
-   data, the TLSSigntext. The packet format is shown below. The fields 
-   are transmitted from left to right. 
-
-   0                   1                   2                   3 
-   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   | Content-Type  |     Flag      |     Version                   | 
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-   |              Length           |  Signed Data ...   
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
-
-   Content-Type 
-
-      Same as TLSPlaintext.type. 
-
-   Flag 
-
-      0 1 2 3 4 5 6 7 8   
-      +-+-+-+-+-+-+-+-+    
-      |A R R R R R R R|    
-      +-+-+-+-+-+-+-+-+    
-
-   A = acknowledgement of receipt  
-   R = Reserved. 
-
-   When the whole signed data is delivered to the receiver, the TLS Sign 
-   will check the signature. If the signature is valid and that the 
-   sender requires a proof of receipt, the receiver MUST generate a 
-   TLSSigntext packet with the bit A set to 1 (acknowledgement of 
-   receipt). This helps the receiver of the acknowledgment of receipt in 
-   storing the data-field for later use (see section 2.2). The data 
-   field of that message contains the digest of the whole data receiver 
-   by the generator of the acknowledgement of receipt. The digest is 
-   signed before sending the result to the other side.  
-
-2.1.1. bad_sign alert  
-
-   This alert is returned if a record is received with an incorrect 
-   signature. This message is always fatal.  
-
-2.2. Storing signed data 
-
-   The objective of TLS Sign is to provide both parties with evidence 
-   that can be stored and later presented to a third party to resolve 
-   disputes that arise if and when a communication is repudiated by one 
-
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 7] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   of the entities involved. This document provides the two basic types 
-   of non-repudiation service: 
-
-   O  Non-repudiation with proof of origin: provides the TLS server with 
-      evidence proving that the TLS client has sent it the signed data 
-      at a certain time. 
-
-   O  Non-repudiation with proof of delivery: provides the TLS client 
-      with evidence that the server has received the client's signed 
-      data at a specific time. 
-
-   TLS Handshake exchanges the current time and date according to the 
-   entities internal clock. Thus, the time and date can be stored with 
-   the signed data as a proof of communication. For B2C or B2B 
-   transactions, non-repudiation with proof of origin and non-
-   repudiation with proof of receipt are both important. If the TLS 
-   client requests a non-repudiation service with proof of receipt, the 
-   server SHOULD verify and send back to client a signature on the hash 
-   of signed data. 
-
-   The following figure explains the different events for proving and 
-   storing signed data [RFC4949]. RFC 4949 uses the term "critical 
-   action" to refer to the act of communication between the two 
-   entities. For a complete non-repudiation deployment, 6 phases should 
-   be respected: 
-
-   --------   --------   --------   --------   --------   . -------- 
-   Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6: 
-   Request    Generate   Transfer   Verify     Retain     . Resolve 
-   Service    Evidence   Evidence   Evidence   Evidence   . Dispute 
-   --------   --------   --------   --------   --------   . -------- 
-
-   Service    Critical   Evidence   Evidence   Archive    . Evidence 
-   Request => Action  => Stored  => Is      => Evidence   . Is 
-   Is Made    Occurs     For Later  Tested     In Case    . Verified 
-              and        Use |          ^      Critical   .     ^   
-              Evidence       v          |      Action Is  .     |   
-              Is         +-------------------+ Repudiated .     |   
-              Generated  |Verifiable Evidence|------> ... . ----+   
-                         +-------------------+ 
-
-   1- Requesting explicit transaction evidence before sending data. 
-   Normally, this action is taken by the SSL/TLS client  
-
-   2- If the server accepts, the client will generate evidence by 
-   signing data using his X.509 authentication certificate. Server will 
-   go through the same process if the evidence of receipt is requested. 
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 8] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   3 - The signed data is then sent by the initiator (client or server) 
-   and stored it locally, or by a third party, for a later use if 
-   needed. 
-
-   4 - The entity that receive the evidence process to verify the signed 
-   data.  
-
-   5- The evidence is then stored by the receiver entity for a later use 
-   if needed.  
-
-   6- In this phase, which occurs only if the critical action is 
-   repudiated, the evidence is retrieved from storage, presented, and 
-   verified to resolve the dispute. 
-
-   With this method, the stored signed data (or evidence) can be 
-   retrieved by both parties, presented and verified if the critical 
-   action is repudiated. 
-
-3. Security Considerations 
-
-   Security issues are discussed throughout this memo. 
-
-4. IANA Considerations 
-
-   This document defines a new TLS extension "signature", assigned the 
-   value TBD from the TLS ExtensionType registry defined in [TLSEXT]. 
-
-   This document defines one TLS ContentType: tls_sign(TBD). This 
-   ContentType value is assigned from the TLS ContentType registry 
-   defined in [TLS]. 
-
-   This document defines a new handshake message, certificate_sign, 
-   whose value is to be allocated from the TLS HandshakeType registry 
-   defined in [TLS]. 
-
-   The bad_sign alert that is defined in this document is assigned to 
-   the TLS Alert registry defined in [TLS]. 
-
-5. References 
-
-5.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [TLS]     Dierks, T. and E. Rescorla, "The TLS Protocol Version  
-             1.1", RFC 4346, April 2005. 
- 
- 
-Hajjeh & Badra            Expires June 2008                    [Page 9] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   [TLSEXT]  Blake-Wilson, S., et. al., "Transport Layer Security TLS) 
-             Extensions", RFC 4366, April 2006.  
-
-   [PKCS7]   RSA Laboratories, "PKCS #7: RSA Cryptographic Message 
-             Syntax Standard," version 1.5, November 1993.   
-
-   [SMIME]   Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 
-             3851, July 2004.   
-
-   [XMLDSIG] Eastlake, D., et. al, "(Extensible Markup Language) XML 
-             Signature Syntax and Processing", RFC 3275, March 2002. 
-
-5.2. Informative References 
-
-   [RFC4949] Shirey, R., "Internet Security Glossary", RFC 4949, August 
-             2007. 
-
-   [TLSSIGN] Hajjeh, I., Serhrouchni, A., "Integrating a signature 
-             module in SSL/TLS, ICETE2004., ACM/IEEE, First 
-             International Conference on E-Business and 
-             Telecommunication Networks, Portugal, August 2004. 
-
-Author's Addresses 
-
-   Ibrahim Hajjeh 
-   INEOVATION 
-   France 
-       
-   Email: hajjeh@ineovation.com 
-    
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-       
-   Email: badra@isima.fr 
-    
-
-Appendix Changelog  
-
-   Changes from -01 to -02: 
-
-   o Add an IANA section. 
-
-   o Small clarifications to section 2. 
-
-   o Add the bad_sign alert and the certificate_sign message. 
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 10] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   Changes from -00 to -01:  
-
-   o Clarifications to the format of the signed data in Section 2. 
-
-   o Small clarifications to TLS SIGN negotiation in Section 2.  
-
-   o Added Jacques Demerjian and Mohammed Achemlal as 
-   contributors/authors. 
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2007). 
-
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 11] 
-
-Internet-Draft                  TLS Sign                  December 2007 
-    
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Hajjeh & Badra            Expires June 2008                   [Page 12] 
-
diff --git a/doc/protocol/draft-hickman-netscape-ssl-00.txt b/doc/protocol/draft-hickman-netscape-ssl-00.txt
deleted file mode 100644
index 5658bdff89..0000000000
--- a/doc/protocol/draft-hickman-netscape-ssl-00.txt
+++ /dev/null
@@ -1,1510 +0,0 @@
-
-						 Kipp E.B. Hickman
-Internet Draft	   		          Netscape Communications Corp
-					    April 1995 (Expires 10/95)
-
-                           The SSL Protocol
-                    <draft-hickman-netscape-ssl-00.txt>
-
-1. STATUS OF THIS MEMO
-
-This document is an Internet-Draft.Internet-Drafts are working documents 
-of the Internet Engineering Task Force (IETF), its areas, and its working 
-groups. Note that other groups may also distribute working documents as 
-Internet-Drafts.
-
-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."
-
-To learn the current status of any Internet-Draft, please check the "1id-
-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories 
-on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US 
-West Coast), or munnari.oz.au (Pacific Rim).
-2. ABSTRACT
-
-This document specifies the Secure Sockets Layer (SSL) protocol, a 
-security protocol that provides privacy over the Internet. The protocol 
-allows client/server applications to communicate in a way that cannot be 
-eavesdropped. Server's are always authenticated and clients are optionally 
-authenticated.
-
-3. INTRODUCTION
-
-The SSL Protocol is designed to provide privacy between two 
-communicating applications (a client and a server). Second, the protocol is 
-designed to authenticate the server, and optionally the client. SSL requires 
-a reliable transport protocol (e.g. TCP) for data transmission and 
-reception.
-
-The advantage of the SSL Protocol is that it is application protocol 
-independent. A "higher level" application protocol (e.g. HTTP, FTP, 
-TELNET, etc.) can layer on top of the SSL Protocol transparently. The 
-SSL Protocol can negotiate an encryption algorithm and session key as 
-well as authenticate a server before the application protocol transmits or 
-receives its first byte of data. All of the application protocol data is 
-transmitted encrypted, ensuring privacy.
-
-The SSL protocol provides "channel security" which has three basic 
-properties:
-
-  The channel is private. Encryption is used for all messages after a 
-simple handshake is used to define a secret key. Symmetric 
-cryptography is used for data encryption (e.g. DES, RC4, etc.)
-
-  The channel is authenticated. The server endpoint of the conversation 
-is always authenticated, while the client endpoint is optionally 
-authenticated. Asymmetric cryptography is used for authentication 
-
-Hickman							[page  1]
-
-(e.g. Public Key Cryptography).
-
-  The channel is reliable. The message transport includes a message 
-integrity check (using a MAC). Secure hash functions (e.g. MD2, 
-MD5) are used for MAC computations.
-
-The SSL protocol is actually composed of two protocols. At the lowest 
-level, layered on top of some reliable transport protocol, is the "SSL 
-Record Protocol". The SSL Record Protocol is used for encapsulation of 
-all transmitted and received data, including the SSL Handshake Protocol, 
-which is used to establish security parameters.
-4. SSL Record Protocol Specification
-
-4.1 SSL Record Header Format
-
-In SSL, all data sent is encapsulated in a record, an object which is 
-composed of a header and some non-zero amount of data. Each record 
-header contains a two or three byte length code. If the most significant bit 
-is set in the first byte of the record length code then the record has no 
-padding and the total header length will be 2 bytes, otherwise the record 
-has padding and the total header length will be 3 bytes. The record header 
-is transmitted before the data portion of the record.
-
-Note that in the long header case (3 bytes total), the second most 
-significant bit in the first byte has special meaning. When zero, the record 
-being sent is a data record. When one, the record being sent is a security 
-escape (there are currently no examples of security escapes; this is 
-reserved for future versions of the protocol). In either case, the length code 
-describes how much data is in the record.
-
-The record length code does not include the number of bytes consumed by 
-the record header (2 or 3). For the 2 byte header, the record length is 
-computed by (using a "C"-like notation):
-
-RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];
-
-Where byte[0] represents the first byte received and byte[1] the second 
-byte received. When the 3 byte header is used, the record length is 
-computed as follows (using a "C"-like notation):
-
-RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
-IS-ESCAPE = (byte[0] & 0x40) != 0;
-PADDING = byte[2];
-
-The record header defines a value called PADDING. The PADDING 
-value specifies how many bytes of data were appended to the original 
-record by the sender. The padding data is used to make the record length 
-be a multiple of the block ciphers block size when a block cipher is used 
-for encryption.
-
-The sender of a "padded" record appends the padding data to the end of its 
-normal data and then encrypts the total amount (which is now a multiple 
-of the block cipher's block size). The actual value of the padding data is 
-unimportant, but the encrypted form of it must be transmitted for the 
-receiver to properly decrypt the record. Once the total amount being 
-
-Hickman							[page  2]
-
-transmitted is known the header can be properly constructed with the 
-PADDING value set appropriately.
-
-The receiver of a padded record decrypts the entire record data (sans 
-record length and the optional padding) to get the clear data, then subtracts 
-the PADDING value from the RECORD-LENGTH to determine the 
-final RECORD-LENGTH. The clear form of the padding data must be 
-discarded.
-
-4.1.1 SSL Record Data Format
-
-The data portion of an SSL record is composed of three components 
-(transmitted and received in the order shown):
-
-MAC-DATA[MAC-SIZE]
-ACTUAL-DATA[N]
-PADDING-DATA[PADDING]
-
-ACTUAL-DATA is the actual data being transmitted (the message 
-payload). PADDING-DATA is the padding data sent when a block cipher 
-is used and padding is needed. Finally, MAC-DATA is the "Message 
-Authentication Code".
-
-When SSL records are sent in the clear, no cipher is used.Consequently the 
-amount of PADDING-DATA will be zero and the amount of MAC-
-DATA will be zero. When encryption is in effect, the PADDING-DATA 
-will be a function of the cipher block size. The MAC-DATA is a function 
-of the CIPHER-CHOICE (more about that later).
-
-The MAC-DATA is computed as follows:
-
-MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA,
-SEQUENCE-NUMBER ]
-
-Where the SECRET data is fed to the hash function first, followed by the 
-ACTUAL-DATA, which is followed by the PADDING-DATA which is 
-finally followed by the SEQUENCE-NUMBER. The SEQUENCE-
-NUMBER is a 32 bit value which is presented to the hash function as four 
-bytes, with the first byte being the most significant byte of the sequence 
-number, the second byte being the next most significant byte of the 
-sequence number, the third byte being the third most significant byte, and 
-the fourth byte being the least significant byte (that is, in network byte 
-order or "big endian" order).
-
-MAC-SIZE is a function of the digest algorithm being used. For MD2 and 
-MD5 the MAC-SIZE will be 16 bytes (128 bits).
-
-The SECRET value is a function of which party is sending the message. If 
-the client is sending the message then the SECRET is the CLIENT-
-WRITE-KEY (the server will use the SERVER-READ-KEY to verify 
-the MAC). If the client is receiving the message then the SECRET is the 
-CLIENT-READ-KEY (the server will use the SERVER-WRITE-KEY 
-to
-generate the MAC).
-
-Hickman							[page  3]
-
-The SEQUENCE-NUMBER is a counter which is incremented by both 
-the sender and the receiver. For each transmission direction, a pair of 
-counters is kept (one by the sender, one by the receiver). Every time a 
-message is sent by a sender the counter is incremented. Sequence numbers 
-are 32 bit unsigned quantities and must wrap to zero after incrementing 
-past 0xFFFFFFFF.
-
-The receiver of a message uses the expected value of the sequence number 
-as input into the MAC HASH function (the HASH function is chosen from 
-the CIPHER-CHOICE). The computed MAC-DATA must agree bit for 
-bit with the transmitted MAC-DATA. If the comparison is not identity 
-then the record is considered damaged, and it is to be treated as if an "I/O 
-Error" had occurred (i.e. an unrecoverable error is asserted and the 
-connection is closed).
-
-A final consistency check is done when a block cipher is used and the 
-protocol is using encryption. The amount of data present in a record 
-(RECORD-LENGTH))must be a multiple of the cipher's block size. If 
-the received record is not a multiple of the cipher's block size then the 
-record is considered damaged, and it is to be treated as if an "I/O Error" 
-had occurred (i.e. an unrecoverable error is asserted and the connection is 
-closed).
-
-The SSL Record Layer is used for all SSL communications, including 
-handshake messages, security escapes and application data transfers. The 
-SSL Record Layer is used by both the client and the server at all times.
-
-For a two byte header, the maximum record length is 32767 bytes. For the 
-three byte header, the maximum record length is 16383 bytes. The SSL 
-Handshake Protocol messages are constrained to fit in a single SSL Record 
-Protocol record. Application protocol messages are allowed to consume 
-multiple SSL Record Protocol record's.
-
-Before the first record is sent using SSL all sequence numbers are 
-initialized to zero. The transmit sequence number is incremented after 
-every message sent, starting with the CLIENT-HELLO and SERVER-
-HELLO messages.
-
-5. SSL Handshake Protocol Specification
-
-5.1 SSL Handshake Protocol Flow
-
-The SSL Handshake Protocol is used to negotiate security enhancements 
-to data sent using the SSL Record Protocol. The security enhancements 
-consist of authentication, symmetric encryption, and message integrity.
-
-The SSL Handshake Protocol has two major phases. The first phase is 
-used to establish private communications. The second phase is used for 
-client authentication.
-
-5.1.1 Phase 1
-
-The first phase is the initial connection phase where both parties 
-communicate their "hello" messages. The client initiates the conversation 
-by sending the CLIENT-HELLO message. The server receives the 
-
-Hickman							[page  4]
-
-CLIENT-HELLO message and processes it responding with the 
-SERVER-HELLO message.
-
-At this point both the client and server have enough information to know 
-whether or not a new "master key" is needed (The master key is used for 
-production of the symmetric encryption session keys). When a new master 
-key is not needed, both the client and the server proceed immediately to 
-phase 2.
-
-When a new master key is needed, the SERVER-HELLO message will 
-contain enough information for the client to generate it. This includes the 
-server's signed certificate (more about that later), a list of bulk cipher 
-specifications (see below), and a connection-id (a connection-id is a 
-randomly generated value generated by the server that is used by the client 
-and server during a single connection). The client generates the master key 
-and responds with a CLIENT-MASTER-KEY message (or an ERROR 
-message if the server information indicates that the client and server 
-cannot agree on a bulk cipher).
-
-It should be noted here that each SSL endpoint uses a pair of ciphers per 
-connection (for a total of four ciphers). At each endpoint, one cipher is 
-used for outgoing communications, and one is used for incoming 
-communications. When the client or server generate a session key, they 
-actually generate two keys, the SERVER-READ-KEY (also known as the 
-CLIENT-WRITE-KEY) and the SERVER-WRITE-KEY (also known 
-as the CLIENT-READ-KEY). The master key is used by the client and 
-server to generate the various session keys (more about that later).
-
-Finally, the server sends a SERVER-VERIFY message to the client after 
-the master key has been determined. This final step authenticates the 
-server, because only a server which has the appropriate public key can 
-know the master key.
-
-5.1.2 Phase 2
-
-The second phase is the client authentication phase. The server has already 
-been authenticated by the client in the first phase, so this phase is primarily 
-used to authenticate the client. In a typical scenario, the server will require 
-authentication of  the client and send a REQUEST-CERTIFICATE 
-message. The client will answer in the positive if it has the needed 
-information, or send an ERROR message if it does not. This protocol 
-specification does not define the semantics of an ERROR response to a 
-server request (e.g., an implementation can ignore the error, close the 
-connection, etc. and still conform to this specification). In addition, it is 
-permissable for a server to cache client authentication information with the 
-"session-id" cache. The server is not required to re-authenticate the client 
-on every connection.
-
-When a party is done authenticating the other party, it sends its finished 
-message. For the client, the CLIENT-FINISHED message contains the 
-encrypted form of the CONNECTION-ID for the server to verify. If the 
-verification fails, the server sends an ERROR message.
-
-Once a party has sent its finished message it must continue to listen to its 
-peers messages until it too receives a finished message. Once a party has 
-
-Hickman							[page  5]
-
-both sent a finished message and received its peers finished message, the 
-SSL handshake protocol is done. At this point the application protocol 
-begins to operate (Note: the application protocol continues to be layered 
-on the SSL Record Protocol).
-
-5.2 Typical Protocol Message Flow
-
-The following sequences define several typical protocol message flows for 
-the SSL Handshake Protocol. In these examples we have two principals in 
-the conversation: the client and the server. We use a notation commonly 
-found in the literature [10]. When something is enclosed in curly braces 
-"{something}key" then the something has been encrypted using "key".
-
-5.2.1 Assuming no session-identifier
-
-client-hello		C -> S: challenge, cipher_specs
-server-hello		S -> C: connection-id, server_certificate,
-				  cipher_specs
-client-master-key	C -> S: {master_key}server_public_key
-client-finish		C -> S: {connection-id}client_write_key
-server-verify		S -> C: {challenge}server_write_key
-server-finish		S -> C: {new_session_id}server_write_key
-
-5.2.2 Assuming a session-identifier was found by both client & server
-
-client-hello		C -> S: challenge, session_id, cipher_specs
-server-hello		S -> C: connection-id, session_id_hit
-client-finish		C -> S: {connection-id}client_write_key
-server-verify		S -> C: {challenge}server_write_key
-server-finish		S -> C: {session_id}server_write_key
-
-5.2.3 Assuming a session-identifier was used and client authentication 
-is used
-
-client-hello		C -> S: challenge, session_id, cipher_specs
-server-hello		S -> C: connection-id, session_id_hit
-client-finish		C -> S: {connection-id}client_write_key
-server-verify		S -> C: {challenge}server_write_key
-request-certificate	S -> C: {auth_type,challenge'}
-				  server_write_key
-client-certificate	C -> S: {cert_type,client_cert,
-				   response_data}client_write_key
-server-finish		S -> C: {session_id}server_write_key
-
-In this last exchange, the response_data is a function of the auth_type.
-
-5.3 Errors
-
-Error handling in the SSL connection protocol is very simple. When an 
-error is detected, the detecting party sends a message to the other party. 
-Errors that are not recoverable cause the client and server to abort the 
-secure connection. Servers and client are required to "forget" any session-
-identifiers associated with a failing connection.
-
-The SSL Handshake Protocol defines the following errors:
-
-
-Hickman							[page  6]
-
-NO-CIPHER-ERROR
-This error is returned by the client to the server when it cannot find 
-a cipher or key size that it supports that is also supported by the 
-server. This error is not recoverable.
-
-NO-CERTIFICATE-ERROR
-When a REQUEST-CERTIFICATE message is sent, this error may 
-be returned if the client has no certificate to reply with. This error 
-is recoverable (for client authentication only).
-
-BAD-CERTIFICATE-ERROR
-This error is returned when a certificate is deemed bad by the 
-receiving party. Bad means that either the signature of the 
-certificate was bad or that the values in the certificate were 
-inappropriate (e.g. a name in the certificate did not match the 
-expected name). This error is recoverable (for client authentication 
-only).
-
-UNSUPPORTED-CERTIFICATE-TYPE-ERROR
-This error is returned when a client/server receives a certificate 
-type that it can't support. This error is recoverable (for client 
-authentication only).
-
-5.4 SSL Handshake Protocol Messages
-
-The SSL Handshake Protocol messages are encapsulated using the SSL 
-Record Protocol and are composed of two parts: a single byte message 
-type code, and some data. The client and server exchange messages until 
-both ends have sent their "finished" message, indicating that they are 
-satisfied with the SSL Handshake Protocol conversation. While one end 
-may be finished, the other may not, therefore the finished end must 
-continue to receive SSL Handshake Protocol messages until it receives a 
-"finished" message from its peer.
-
-After the pair of session keys has been determined by each party, the 
-message bodies are encrypted. For the client, this happens after it verifies 
-the session-identifier or creates a new master key and has sent it to the 
-server. For the server, this happens after the session-identifier is found to 
-be good, or the server receives the client's master key message.
-
-The following notation is used for SSLHP messages:
-
-char MSG-EXAMPLE
-char FIELD1
-char FIELD2
-char THING-MSB
-char THING-LSB
-char THING-DATA[(MSB<<8)|LSB];
-...
-
-This notation defines the data in the protocol message, including the 
-message type code. The order is presented top to bottom, with the top most 
-element being transmitted first, and the bottom most element transferred 
-last.
-
-
-Hickman							[page  7]
-
-For the "THING-DATA" entry, the MSB and LSB values are actually 
-THING-MSB and THING-LSB (respectively) and define the number of 
-bytes of data actually present in the message. For example, if THING-
-MSB were zero and THING-LSB were 8 then the THING-DATA array 
-would be exactly 8 bytes long. This shorthand is used below.
-
-Length codes are unsigned values, and when the MSB and LSB are 
-combined the result is an unsigned value. Unless otherwise specified 
-lengths values are "length in bytes".
-
-5.5 Client Only Protocol Messages
-
-There are several messages that are only generated by clients. These 
-messages are never generated by correctly functioning servers. A client 
-receiving such a message closes the connection to the server and returns an 
-error status to the application through some unspecified mechanism.
-
-5.5.1 CLIENT-HELLO (Phase 1; Sent in the clear)
-
-char MSG-CLIENT-HELLO
-char CLIENT-VERSION-MSB
-char CLIENT-VERSION-LSB
-char CIPHER-SPECS-LENGTH-MSB
-char CIPHER-SPECS-LENGTH-LSB
-char SESSION-ID-LENGTH-MSB
-char SESSION-ID-LENGTH-LSB
-char CHALLENGE-LENGTH-MSB
-char CHALLENGE-LENGTH-LSB
-char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
-char SESSION-ID-DATA[(MSB<<8)|LSB]
-char CHALLENGE-DATA[(MSB<<8)|LSB]
-
-When a client first connects to a server it is required to send the CLIENT-
-HELLO message. The server is expecting this message from the client as 
-its first message. It is an error for a client to send anything else as its
-first 
-message.
-
-The client sends to the server its SSL version, its cipher specs (see below), 
-some challenge data, and the session-identifier data. The session-identifier 
-data is only sent if the client found a session-identifier in its cache for the 
-server, and the SESSION-ID-LENGTH will be non-zero. When there is 
-no session-identifier for the server SESSION-ID-LENGTH must be zero. 
-The challenge data is used to authenticate the server. After the client and 
-server agree on a pair of session keys, the server returns a SERVER-
-VERIFY message with the encrypted form of the CHALLENGE-DATA.
-
-Also note that the server will not send its SERVER-HELLO message 
-until it has received the CLIENT-HELLO message. This is done so that 
-the server can indicate the status of the client's session-identifier back to 
-the client in the server's first message (i.e. to increase protocol efficiency 
-and reduce the number of round trips required).
-
-The server examines the CLIENT-HELLO message and will verify that it 
-can support the client version and one of the client cipher specs. The 
-server can optionally edit the cipher specs, removing any entries it doesn't 
-
-Hickman							[page  8]
-
-choose to support. The edited version will be returned in the SERVER-
-HELLO message if the session-identifier is not in the server's cache.
-
-The CIPHER-SPECS-LENGTH must be greater than zero and a 
-multiple of 3. The SESSION-ID-LENGTH must either be zero or 16. 
-The CHALLENGE-LENGTH must be greater than or equal to 16 and 
-less than or equal to 32.
-
-This message must be the first message sent by the client to the server. 
-After the message is sent the client waits for a SERVER-HELLO 
-message. Any other message returned by the server (other than ERROR) 
-is disallowed.
-
-5.5.2 CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear)
-
-char MSG-CLIENT-MASTER-KEY
-char CIPHER-KIND[3]
-char CLEAR-KEY-LENGTH-MSB
-char CLEAR-KEY-LENGTH-LSB
-char ENCRYPTED-KEY-LENGTH-MSB
-char ENCRYPTED-KEY-LENGTH-LSB
-char KEY-ARG-LENGTH-MSB
-char KEY-ARG-LENGTH-LSB
-char CLEAR-KEY-DATA[MSB<<8|LSB]
-char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
-char KEY-ARG-DATA[MSB<<8|LSB]
-
-The client sends this message when it has determined a master key for the 
-server to use. Note that when a session-identifier has been agreed upon, 
-this message is not sent.
-
-The CIPHER-KIND field indicates which cipher was chosen from the 
-server's CIPHER-SPECS.
-
-The CLEAR-KEY-DATA contains the clear portion of the MASTER-
-KEY. The CLEAR-KEY-DATA is combined with the SECRET-KEY-
-DATA (described shortly) to form the MASTER-KEY, with the 
-SECRET-KEY-DATA being the least significant bytes of the final 
-MASTER-KEY. The ENCRYPTED-KEY-DATA contains the secret 
-portions of the MASTER-KEY, encrypted using the server's public key. 
-The encryption block is formatted using block type 2 from PKCS#1 [5]. 
-The data portion of the block is formatted as follows:
-
-char SECRET-KEY-DATA[SECRET-LENGTH]
-
-SECRET-LENGTH is the number of bytes of each session key that is 
-being transmitted encrypted. The SECRET-LENGTH plus the CLEAR-
-KEY-LENGTH equals the number of bytes present in the cipher key (as 
-defined by the CIPHER-KIND). It is an error if the SECRET-LENGTH 
-found after decrypting the PKCS#1 formatted encryption block doesn't 
-match the expected value. It is also an error if CLEAR-KEY-LENGTH is 
-non-zero and the CIPHER-KIND is not an export cipher.
-
-If the key algorithm needs an argument (for example, DES-CBC's 
-initialization vector) then the KEY-ARG-LENGTH fields will be non-
-
-Hickman							[page 9]
-
-zero and the KEY-ARG-DATA will contain the relevant data. For the 
-SSL_CK_RC2_128_CBC_WITH_MD5, 
-SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5, 
-SSL_CK_IDEA_128_CBC_WITH_MD5, 
-SSL_CK_DES_64_CBC_WITH_MD5 and 
-SSL_CK_DES_192_EDE3_CBC_WITH_MD5 algorithms the KEY-ARG 
-data must be present and be exactly 8 bytes long.
-
-Client and server session key production is a function of the CIPHER-
-CHOICE:
-
-SSL_CK_RC4_128_WITH_MD5
-SSL_CK_RC4_128_EXPORT40_WITH_MD5
-SSL_CK_RC2_128_CBC_WITH_MD5
-SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
-SSL_CK_IDEA_128_CBC_WITH_MD5
-
-KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, 
-CONNECTION-ID ]
-KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, 
-CONNECTION-ID ]
-
-CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
-CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
-
-Where KEY-MATERIAL-0[0-15] means the first 16 bytes of the KEY-
-MATERIAL-0 data, with KEY-MATERIAL-0[0] becoming the  most 
-significant byte of the CLIENT-READ-KEY.
-
-Data is fed to the MD5 hash function in the order shown, from left to 
-right: first the MASTER-KEY, then the "0" or "1", then the 
-CHALLENGE and then finally the CONNECTION-ID.
-
-Note that the "0" means the ascii zero character (0x30), not a zero value. 
-"1" means the ascii 1 character (0x31). MD5 produces 128 bits of output 
-data which are used directly as the key to the cipher algorithm (The most 
-significant byte of the MD5 output becomes the most significant byte of 
-the key material).
-
-SSL_CK_DES_64_CBC_WITH_MD5
-
- KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, 
-CONNECTION-ID ]
-
- CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
- CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
-
-For DES-CBC, a single 16 bytes of key material are produced using MD5. 
-The first 8 bytes of the MD5 digest are used as the CLIENT-READ-KEY 
-while the remaining 8 bytes are used as the CLIENT-WRITE-KEY. The 
-initialization vector is provided in the KEY-ARG-DATA. Note that the 
-raw key data is not parity adjusted and that this step must be performed 
-before the keys are legitimate DES keys.
-
-SSL_CK_DES_192_EDE3_CBC_WITH_MD5
-
-
-Hickman							[page  10]
-
- KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, 
-CONNECTION-ID ]
- KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, 
-CONNECTION-ID ]
- KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, 
-CONNECTION-ID ]
-
- CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
- CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
- CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
- CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
- CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
- CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
-
-Data is fed to the MD5 hash function in the order shown, from left to 
-right: first the MASTER-KEY, then the "0", "1" or "2", then the 
-CHALLENGE and then finally the CONNECTION-ID. Note that the 
-"0" means the ascii zero character (0x30), not a zero value. "1" means the 
-ascii 1 character (0x31). "2" means the ascii 2 character (0x32).
-
-A total of 6 keys are produced, 3 for the read side DES-EDE3 cipher and 3 
-for the write side DES-EDE3 function. The initialization vector is 
-provided in the KEY-ARG-DATA. The keys that are produced are not 
-parity adjusted. This step must be performed before proper DES keys are 
-usable.
-
-Recall that the MASTER-KEY is given to the server in the CLIENT-
-MASTER-KEY message. The CHALLENGE is given to the server by 
-the client in the CLIENT-HELLO message. The CONNECTION-ID is 
-given to the client by the server in the SERVER-HELLO message. This 
-makes the resulting cipher keys a function of the original session and the 
-current session. Note that the master key is never directly used to encrypt 
-data, and therefore cannot be easily discovered.
-
-The CLIENT-MASTER-KEY message must be sent after the CLIENT-
-HELLO message and before the CLIENT-FINISHED message. The 
-CLIENT-MASTER-KEY message must be sent if the SERVER-
-HELLO message contains a SESSION-ID-HIT value of 0.
-
-5.5.3 CLIENT-CERTIFICATE (Phase 2; Sent encrypted)
-
-char MSG-CLIENT-CERTIFICATE
-char CERTIFICATE-TYPE
-char CERTIFICATE-LENGTH-MSB
-char CERTIFICATE-LENGTH-LSB
-char RESPONSE-LENGTH-MSB
-char RESPONSE-LENGTH-LSB
-char CERTIFICATE-DATA[MSB<<8|LSB]
-char RESPONSE-DATA[MSB<<8|LSB]
-
-This message is sent by one an SSL client in response to a server 
-REQUEST-CERTIFICATE message. The CERTIFICATE-DATA 
-contains data defined by the CERTIFICATE-TYPE value. An ERROR 
-message is sent with error code NO-CERTIFICATE-ERROR when this 
-request cannot be answered properly (e.g. the receiver of the message has 
-
-Hickman							[page 11]
-
-no registered certificate).
-
-CERTIFICATE-TYPE is one of:
-
-SSL_X509_CERTIFICATE
-The CERTIFICATE-DATA contains an X.509 (1988) [3] signed 
-certificate.
-
-The RESPONSE-DATA contains the authentication response data. This 
-data is a function of the AUTHENTICATION-TYPE value sent by the 
-server.
-
-When AUTHENTICATION-TYPE is 
-SSL_AT_MD5_WITH_RSA_ENCRYPTION then the RESPONSE-
-DATA contains a digital signature of the following components (in the 
-order shown):
-
-  the KEY-MATERIAL-0
-  the KEY-MATERIAL-1 (only if defined by the cipher kind)
-  the KEY-MATERIAL-2 (only if defined by the cipher kind)
-  the CERTIFICATE-CHALLENGE-DATA (from the 
-REQUEST-CERTIFICATE message)
-  the server's signed certificate (from the SERVER-HELLO 
-message)
-
-The digital signature is constructed using MD5 and then encrypted using 
-the clients private key, formatted according to PKCS#1's digital signature 
-standard [5]. The server authenticates the client by verifying the digital 
-signature using standard techniques. Note that other digest functions are 
-supported. Either a new AUTHENTICATION-TYPE can be added, or 
-the algorithm-id in the digital signature can be changed.
-
-This message must be sent by the client only in response to a REQUEST-
-CERTIFICATE message.
-
-5.5.4 CLIENT-FINISHED (Phase 2; Sent encrypted)
-
-char MSG-CLIENT-FINISHED
-char CONNECTION-ID[N-1]
-
-The client sends this message when it is satisfied with the server. Note that 
-the client must continue to listen for server messages until it receives a 
-SERVER-FINISHED message. The CONNECTION-ID data is the 
-original connection-identifier the server sent with its SERVER-HELLO 
-message, encrypted using the agreed upon session key.
-
-"N" is the number of bytes in the message that was sent, so "N-1" is the 
-number of bytes in the message without the message header byte.
-
-For version 2 of the protocol, the client must send this message after it has 
-received the SERVER-HELLO message. If the SERVER-HELLO 
-message SESSION-ID-HIT flag is non-zero then the CLIENT-
-FINISHED message is sent immediately, otherwise the CLIENT-
-FINISHED message is sent after the CLIENT-MASTER-KEY message.
-
-
-Hickman							[page 12]
-
-
-
-
-
-
-5.6 Server Only Protocol Messages
-
-There are several messages that are only generated by servers. The 
-messages are never generated by correctly functioning clients.
-
-5.6.1 SERVER-HELLO (Phase 1; Sent in the clear)
-
-char MSG-SERVER-HELLO
-char SESSION-ID-HIT
-char CERTIFICATE-TYPE
-char SERVER-VERSION-MSB
-char SERVER-VERSION-LSB
-char CERTIFICATE-LENGTH-MSB
-char CERTIFICATE-LENGTH-LSB
-char CIPHER-SPECS-LENGTH-MSB
-char CIPHER-SPECS-LENGTH-LSB
-char CONNECTION-ID-LENGTH-MSB
-char CONNECTION-ID-LENGTH-LSB
-char CERTIFICATE-DATA[MSB<<8|LSB]
-char CIPHER-SPECS-DATA[MSB<<8|LSB]
-char CONNECTION-ID-DATA[MSB<<8|LSB]
-
-The server sends this message after receiving the clients CLIENT-
-HELLO message. The server returns the SESSION-ID-HIT flag 
-indicating whether or not the received session-identifier is known by the 
-server (i.e. in the server's session-identifier cache). The SESSION-ID-
-HIT flag will be non-zero if the client sent the server a session-identifier 
-(in the CLIENT-HELLO message with SESSION-ID-LENGTH != 0) 
-and the server found the client's session-identifier in its cache. If the 
-SESSION-ID-HIT flag is non-zero then the CERTIFICATE-TYPE, 
-CERTIFICATE-LENGTH and CIPHER-SPECS-LENGTH fields will 
-be zero.
-
-The CERTIFICATE-TYPE value, when non-zero, has one of the values 
-described above (see the information on the CLIENT-CERTIFICATE 
-message).
-
-When the SESSION-ID-HIT flag is zero, the server packages up its 
-certificate, its cipher specs and a connection-id to send to the client. Using 
-this information the client can generate a session key and return it to the 
-server with the CLIENT-MASTER-KEY message.
-
-When the SESSION-ID-HIT flag is non-zero, both the server and the 
-client compute a new pair of session keys for the current session derived 
-from the MASTER-KEY that was exchanged when the SESSION-ID 
-was created. The SERVER-READ-KEY and SERVER-WRITE-KEY 
-are derived from the original MASTER-KEY keys in the same manner as 
-the CLIENT-READ-KEY and CLIENT-WRITE-KEY:
-
-SERVER-READ-KEY = CLIENT-WRITE-KEY
-SERVER-WRITE-KEY = CLIENT-READ-KEY
-
-Note that when keys are being derived and the SESSION-ID-HIT flag is 
-set and the server discovers the client's session-identifier in the servers 
-cache, then the KEY-ARG-DATA is used from the time when the 
-
-Hickman							[page 13]
-
-SESSION-ID was established. This is because the client does not send 
-new KEY-ARG-DATA (recall that the KEY-ARG-DATA is sent only in 
-the CLIENT-MASTER-KEY message).
-
-The CONNECTION-ID-DATA is a string of randomly generated bytes 
-used by the server and client at various points in the protocol. The 
-CLIENT-FINISHED message contains an encrypted version of the 
-CONNECTION-ID-DATA. The length of the CONNECTION-ID must 
-be between 16 and than 32 bytes, inclusive.
-
-The CIPHER-SPECS-DATA define a cipher type and key length (in bits) 
-that the receiving end supports. Each SESSION-CIPHER-SPEC is 3 
-bytes long and looks like this:
-
-char CIPHER-KIND-0
-char CIPHER-KIND-1
-char CIPHER-KIND-2
-
-Where CIPHER-KIND is one of:
-
-SSL_CK_RC4_128_WITH_MD5
-SSL_CK_RC4_128_EXPORT40_WITH_MD5
-SSL_CK_RC2_128_CBC_WITH_MD5
-SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
-SSL_CK_IDEA_128_CBC_WITH_MD5
-SSL_CK_DES_64_CBC_WITH_MD5
-SSL_CK_DES_192_EDE3_CBC_WITH_MD5
-
-This list is not exhaustive and may be changed in the future.
-
-The SSL_CK_RC4_128_EXPORT40_WITH_MD5 cipher is an RC4 
-cipher where some of the session key is sent in the clear and the rest is sent 
-encrypted (exactly 40 bits of it). MD5 is used as the hash function for 
-production of MAC's and session key's. This cipher type is provided to 
-support "export" versions (i.e. versions of the protocol that can be 
-distributed outside of the United States) of the client or server.
-
-An exportable implementation of the SSL Handshake Protocol will have 
-secret key lengths restricted to 40 bits. For non-export implementations 
-key lengths can be more generous (we recommend at least 128 bits). It is 
-permissible for the client and server to have a non-intersecting set of 
-stream ciphers. This, simply put, means they cannot communicate.
-
-Version 2 of the SSL Handshake Protocol defines the 
-SSL_CK_RC4_128_WITH_MD5 to have a key length of 128 bits. The 
-SSL_CK_RC4_128_EXPORT40_WITH_MD5 also has a key length of 
-128 bits. However, only 40 of the bits are secret (the other 88 bits are sent 
-in the clear by the client to the server).
-
-The SERVER-HELLO message is sent after the server receives the 
-CLIENT-HELLO message, and before the server sends the SERVER-
-VERIFY message.
-5.6.2 SERVER-VERIFY (Phase 1; Sent encrypted)
-
-char MSG-SERVER-VERIFY
-
-Hickman							[page 14]
-
-char CHALLENGE-DATA[N-1]
-
-The server sends this message after a pair of session keys (SERVER-
-READ-KEY and SERVER-WRITE-KEY) have been agreed upon either 
-by a session-identifier or by explicit specification with the CLIENT-
-MASTER-KEY message. The message contains an encrypted copy of the 
-CHALLENGE-DATA sent by the client in the CLIENT-HELLO 
-message.
-
-"N" is the number of bytes in the message that was sent, so "N-1" is the 
-number of bytes in the CHALLENGE-DATA without the message 
-header byte.
-
-This message is used to verify the server as follows. A legitimate server 
-will have the private key that corresponds to the public key contained in 
-the server certificate that was transmitted in the SERVER-HELLO 
-message. Accordingly, the legitimate server will be able to extract and 
-reconstruct the pair of session keys (SERVER-READ-KEY and 
-SERVER-WRITE-KEY). Finally, only a server that has done the 
-extraction and decryption properly can correctly encrypt the 
-CHALLENGE-DATA. This, in essence, "proves" that the server has the 
-private key that goes with the public key in the server's certificate.
-
-The CHALLENGE-DATA must be the exact same length as originally 
-sent by the client in the CLIENT-HELLO message. Its value must match 
-exactly the value sent in the clear by the client in the CLIENT-HELLO 
-message. The client must decrypt this message and compare the value 
-received with the value sent, and only if the values are identical is the 
-server to be "trusted". If the lengths do not match or the value doesn't 
-match then the connection is to be closed by the client.
-
-This message must be sent by the server to the client after either detecting 
-a session-identifier hit (and replying with a SERVER-HELLO message 
-with SESSION-ID-HIT not equal to zero) or when the server receives the 
-CLIENT-MASTER-KEY message. This message must be sent before 
-any Phase 2 messages or a SERVER-FINISHED message.
-
-5.6.3 SERVER-FINISHED (Phase 2; Sent encrypted)
-
-char MSG-SERVER-FINISHED
-char SESSION-ID-DATA[N-1]
-
-The server sends this message when it is satisfied with the clients security 
-handshake and is ready to proceed with transmission/reception of the 
-higher level protocols data. The SESSION-ID-DATA is used by the client 
-and the server at this time to add entries to their respective session-
-identifier caches. The session-identifier caches must contain a copy of the 
-MASTER-KEY sent in the CLIENT-MASTER-KEY message as the 
-master key is used for all subsequent session key generation.
-
-"N" is the number of bytes in the message that was sent, so "N-1" is the 
-number of bytes in the SESSION-ID-DATA without the message header 
-byte.
-
-This message must be sent after the SERVER-VERIFY message.
-
-Hickman							[page 15]
-
-5.6.4 REQUEST-CERTIFICATE (Phase 2; Sent encrypted)
-
-char MSG-REQUEST-CERTIFICATE
-char AUTHENTICATION-TYPE
-char CERTIFICATE-CHALLENGE-DATA[N-2]
-
-A server may issue this request at any time during the second phase of the 
-connection handshake, asking for the client's certificate. The client 
-responds with a CLIENT-CERTIFICATE message immediately if it has 
-one, or an ERROR message (with error code NO-CERTIFICATE-
-ERROR) if it doesn't. The CERTIFICATE-CHALLENGE-DATA is a 
-short byte string (whose length is greater than or equal to 16 bytes and less 
-than or equal to 32 bytes) that the client will use to respond to this 
-message.
-
-The AUTHENTICATION-TYPE value is used to choose a particular 
-means of authenticating the client. The following types are defined:
-
-SSL_AT_MD5_WITH_RSA_ENCRYPTION
-
-The SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that the 
-client construct an MD5 message digest using information as described 
-above in the section on the CLIENT-CERTIFICATE message. Once the 
-digest is created, the client encrypts it using its private key (formatted 
-according to the digital signature standard defined in PKCS#1). The server 
-authenticates the client when it receives the CLIENT-CERTIFICATE 
-message.
-
-This message may be sent after a SERVER-VERIFY message and before 
-a SERVER-FINISHED message.
-
-5.7 Client/Server Protocol Messages
-
-These messages are generated by both the client and the server.
-
-5.7.1 ERROR (Sent clear or encrypted)
-
-char MSG-ERROR
-char ERROR-CODE-MSB
-char ERROR-CODE-LSB
-
-This message is sent when an error is detected. After the message is sent, 
-the sending party shuts the connection down. The receiving party records 
-the error and then shuts its connection down.
-
-This message is sent in the clear if an error occurs during session key 
-negotiation. After a session key has been agreed upon, errors are sent 
-encrypted like all other messages.
-
-Appendix A: ASN.1 Syntax For Certificates
-
-Certificates are used by SSL to authenticate servers and clients. SSL 
-Certificates are based largely on the X.509 [3] certificates. An X.509 
-certificate contains the following information (in ASN.1 [1] notation):
-
-Hickman							[page 16]
-
-X.509-Certificate ::= SEQUENCE {
-  certificateInfo CertificateInfo,
-  signatureAlgorithm AlgorithmIdentifier,
-  signature BIT STRING
-}
-
-CertificateInfo ::= SEQUENCE {
-  version [0] Version DEFAULT v1988,
-  serialNumber CertificateSerialNumber,
-  signature AlgorithmIdentifier,
-  issuer Name,
-  validity Validity,
-  subject Name,
-  subjectPublicKeyInfo SubjectPublicKeyInfo
-}
-
-Version ::= INTEGER { v1988(0) }
-
-CertificateSerialNumber ::= INTEGER
-
-Validity ::= SEQUENCE {
-  notBefore UTCTime,
-  notAfter UTCTime
-}
-
-SubjectPublicKeyInfo ::= SEQUENCE {
-  algorithm AlgorithmIdentifier,
-  subjectPublicKey BIT STRING
-}
-
-AlgorithmIdentifier ::= SEQUENCE {
-  algorithm OBJECT IDENTIFIER,
-  parameters ANY DEFINED BY ALGORITHM OPTIONAL
-}
-
-For SSL's purposes we restrict the values of some of the X.509 fields:
-
-  The X.509-Certificate::signatureAlgorithm and 
-CertificateInfo::signature fields must be identical in value.
-
-  The issuer name must resolve to a name that is deemed acceptable by 
-the application using SSL. How the application using SSL does this is 
-outside the scope of this memo.
-
-Certificates are validated using a few straightforward steps. First, the 
-signature on the certificate is checked and if invalid, the certificate is 
-invalid (either a transmission error or an attempted forgery occurred). 
-Next, the CertificateInfo::issuer field is verified to be an issuer that the 
-application trusts (using an unspecified mechanism). The 
-CertificateInfo::validity field is checked against the current date and 
-verified.
-
-Finally, the CertificateInfo::subject field is checked. This check is 
-optional and depends on the level of trust required by the application using 
-SSL.
-
-Hickman							[page 17]
-
-Appendix B: Attribute Types and Object Identifiers
-
-SSL uses a subset of the X.520 selected attribute types as well as a
-few specific object identifiers. Future revisions of the SSL protocol
-may include support for more attribute types and more object
-identifiers.
-
-B.1 Selected attribute types
-
-commonName { attributeType 3 }
-The common name contained in the distinguished name contained 
-within a certificate issuer or certificate subject.
-
-countryName { attributeType 6 }
-The country name contained in the distinguished name contained 
-within a certificate issuer or certificate subject.
-
-localityName { attributeType 7 }
-The locality name contained in the distinguished name contained 
-within a certificate issuer or certificate subject.
-
-stateOrProvinceName { attributeType 8 }
-The state or province name contained in the distinguished name 
-contained within a certificate issuer or certificate subject.
-
-organizationName { attributeType 10 }
-The organization name contained in the distinguished name contained 
-within a certificate issuer or certificate subject.
-
-organizationalUnitName { attributeType 11 }
-The organizational unit name contained in the distinguished name 
-contained within a certificate issuer or certificate subject.
-
-B.2 Object identifiers
-
-md2withRSAEncryption { ... pkcs(1) 1 2 }
-The object identifier for digital signatures that use both MD2 and RSA 
-encryption. Used by SSL for certificate signature verification.
-
-md5withRSAEncryption { ... pkcs(1) 1 4 }
-The object identifier for digital signatures that use both MD5 and RSA 
-encryption. Used by SSL for certificate signature verification.
-
-rc4 { ... rsadsi(113549) 3 4 }
-The RC4 symmetric stream cipher algorithm used by SSL for bulk 
-encryption.
-
-Appendix C: Protocol Constant Values
-
-This section describes various protocol constants. A special value needs 
-mentioning - the IANA reserved port number for "https" (HTTP using 
-SSL). IANA has reserved port number 443 (decimal) for "https". IANA 
-has also reserved port number 465 for "ssmtp" and port number 563 for 
-"snntp".
-
-Hickman							[page 18]
-
-C.1 Protocol Version Codes
-
-#define SSL_CLIENT_VERSION 0x0002
-#define SSL_SERVER_VERSION 0x0002
-
-C.2 Protocol Message Codes
-
-The following values define the message codes that are used by version
-2 of the SSL Handshake Protocol.
-
-#define SSL_MT_ERROR			0
-#define SSL_MT_CLIENT_HELLO		1
-#define SSL_MT_CLIENT_MASTER_KEY	2
-#define SSL_MT_CLIENT_FINISHED		3
-#define SSL_MT_SERVER_HELLO		4
-#define SSL_MT_SERVER_VERIFY		5
-#define SSL_MT_SERVER_FINISHED		6
-#define SSL_MT_REQUEST_CERTIFICATE	7
-#define SSL_MT_CLIENT_CERTIFICATE	8
-
-C.3 Error Message Codes
-
-The following values define the error codes used by the ERROR message.
-
-#define SSL_PE_NO_CIPHER			0x0001
-#define SSL_PE_NO_CERTIFICATE 			0x0002
-#define SSL_PE_BAD_CERTIFICATE			0x0004
-#define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE	0x0006
-
-C.4 Cipher Kind Values
-
-The following values define the CIPHER-KIND codes used in the 
-CLIENT-HELLO and SERVER-HELLO messages.
-
-#define SSL_CK_RC4_128_WITH_MD5		
-	0x01,0x00,0x80
-#define SSL_CK_RC4_128_EXPORT40_WITH_MD5	
-	0x02,0x00,0x80
-#define SSL_CK_RC2_128_CBC_WITH_MD5		
-	0x03,0x00,0x80
-#define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
-	0x04,0x00,0x80
-#define SSL_CK_IDEA_128_CBC_WITH_MD5	
-	0x05,0x00,0x80
-#define SSL_CK_DES_64_CBC_WITH_MD5		
-	0x06,0x00,0x40
-#define SSL_CK_DES_192_EDE3_CBC_WITH_MD5	
-	0x07,0x00,0xC0
-
-C.5 Certificate Type Codes
-
-The following values define the certificate type codes used in the 
-SERVER-HELLO and CLIENT-CERTIFICATE messages.
-
-#define SSL_CT_X509_CERTIFICATE		0x01
-
-Hickman							[page 19]
-
-C.6 Authentication Type Codes
-
-The following values define the authentication type codes used in the 
-REQUEST-CERTIFICATE message.
-
-#define SSL_AT_MD5_WITH_RSA_ENCRYPTION 0x01
-
-C.7 Upper/Lower Bounds
-
-The following values define upper/lower bounds for various protocol 
-parameters.
-
-#define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS	256
-#define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES	16
-#define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES	64
-#define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER	32767
-#define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER	16383
-
-C.8 Recommendations
-
-Because protocols have to be implemented to be of value, we recommend 
-the following values for various operational parameters. This is only a 
-recommendation, and not a strict requirement for conformance to the 
-protocol.
-
-Session-identifier Cache Timeout
-
-Session-identifiers are kept in SSL clients and SSL servers. Session-
-identifiers should have a lifetime that serves their purpose (namely, 
-reducing the number of expensive public key operations for a single 
-client/server pairing). Consequently, we recommend a maximum session-
-identifier cache timeout value of 100 seconds. Given a server that can 
-perform N private key operations per second, this reduces the server load 
-for a particular client by a factor of 100.
-
-Appendix D: Attacks
-
-In this section we attempt to describe various attacks that might be used 
-against the SSL protocol. This list is not guaranteed to be exhaustive. SSL 
-was defined to thwart these attacks.
-
-D.1 Cracking Ciphers
-
-SSL depends on several cryptographic technologies. RSA Public Key 
-encryption [5] is used for the exchange of the session key and client/server 
-authentication. Various cryptographic algorithms are used for the session 
-cipher. If successful cryptographic attacks are made against these 
-technologies then SSL is no longer secure.
-
-Attacks against a specific communications session can be made by 
-recording the session, and then spending some large number of compute 
-cycles to crack either the session key or the RSA public key until the 
-communication can be seen in the clear. This approach is easier than 
-cracking the cryptographic technologies for all possible messages. Note 
-that SSL tries to make the cost of such of an attack greater than the 
-
-Hickman							[page 20]
-
-benefits gained from a successful attack, thus making it a waste of 
-money/time to perform such an attack.
-
-There have been many books [9] and papers [10] written on cryptography. 
-This document does not attempt to reference them all.
-
-D.2 Clear Text Attack
-
-A clear text attack is done when the attacker has an idea of what kind of 
-message is being sent using encryption. The attacker can generate a data 
-base whose keys are the encrypted value of the known text (or clear text), 
-and whose values are the session cipher key (we call this a "dictionary"). 
-Once this data base is constructed, a simple lookup function identifies the 
-session key that goes with a particular encrypted value. Once the session 
-key is known, the entire message stream can be decrypted. Custom 
-hardware can be used to make this cost effective and very fast.
-
-Because of the very nature of SSL clear text attacks are possible. For 
-example, the most common byte string sent by an HTTP client application 
-to an HTTP server is "GET". SSL attempts to address this attack by using 
-large session cipher keys. First, the client generates a key which is larger 
-than allowed by export, and sends some of it in the clear to the server (this 
-is allowed by United States government export rules). The clear portion of 
-the key concatenated with the secret portion make a key which is very 
-large (for RC4, exactly 128 bits).
-
-The way that this "defeats" a clear text attack is by making the amount of 
-custom hardware needed prohibitively large. Every bit added to the length 
-of the session cipher key increases the dictionary size by a factor of 2. By 
-using a 128 bit session cipher key length the size of the dictionary required 
-is beyond the ability of anyone to fabricate (it would require more atoms to 
-construct than exist in the entire universe). Even if a smaller dictionary is 
-to be used, it must first be generated using the clear key bits. This is a time 
-consumptive process and also eliminates many possible custom hardware 
-architectures (e.g. static prom arrays).
-
-The second way that SSL attacks this problem is by using large key 
-lengths when permissible (e.g. in the non-export version). Large key sizes 
-require larger dictionaries (just one more bit of key size doubles the size of 
-the dictionary). SSL attempts to use keys that are 128 bits in length.
-
-Note that the consequence of the SSL defense is that a brute force attack 
-becomes the cheapest way to attack the key. Brute force attacks have well 
-known space/time tradeoffs and so it becomes possible to define a cost of 
-the attack. For the 128 bit secret key, the known cost is essentially infinite. 
-For the 40 bit secret key, the cost is much smaller, but still outside the 
-range of the "random hacker".
-
-D.3 Replay
-
-The replay attack is simple. A bad-guy records a communication session 
-between a client and server. Later, it reconnects to the server, and plays 
-back the previously recorded client messages.  SSL defeats this attack 
-using a "nonce" (the connection-id) which is "unique" to the connection. In 
-theory the bad-guy cannot predict the nonce in advance as it is based on a 
-
-Hickman							[page 21]
-
-set of random events outside the bad-guys control, and therefore the bad-
-guy cannot respond properly to server requests.
-
-A bad-guy with large resources can record many sessions between a client 
-and a server, and attempt to choose the right session based on the nonce 
-the server sends initially in its SERVER-HELLO message. However, SSL 
-nonces are at least 128 bits long, so a bad-guy would need to record 
-approximately 2^64 nonces to even have a 50% chance of choosing the 
-right session. This number is sufficiently large that one cannot 
-economically construct a device to record 2^64 messages, and therefore 
-the odds are overwhelmingly against the replay attack ever being 
-successful.
-
-D.4 The Man In The Middle
-
-The man in the middle attack works by having three people in a 
-communications session: the client, the server, and the bad guy. The bad 
-guy sits between the client and the server on the network and intercepts 
-traffic that the client sends to the server, and traffic that the server
-sends to 
-the client.
-
-The man in the middle operates by pretending to be the real server to the 
-client. With SSL this attack is impossible because of the usage of server 
-certificates. During the security connection handshake the server is 
-required to provide a certificate that is signed by a certificate authority. 
-Contained in the certificate is the server's public key as well as its name 
-and the name of the certificate issuer. The client verifies the certificate by 
-first checking the signature and then verifying that the name of the issuer 
-is somebody that the client trusts.
-
-In addition, the server must encrypt something with the private key that 
-goes with the public key mentioned in the certificate. This in essence is a 
-single pass "challenge response" mechanism. Only a server that has both 
-the certificate and the private key can respond properly to the challenge.
-
-If the man in the middle provides a phony certificate, then the signature 
-check will fail. If the certificate provided by the bad guy is legitimate, but 
-for the bad guy instead of for the real server, then the signature will pass 
-but the name check will fail (note that the man in the middle cannot forge 
-certificates without discovering a certificate authority's private key).
-
-Finally, if the bad guy provides the real server's certificate then the 
-signature check will pass and the name check will pass. However, because 
-the bad guy does not have the real server's private key, the bad guy cannot 
-properly encode the response to the challenge code, and this check will 
-fail.
-
-In the unlikely case that a bad guy happens to guess the response code to 
-the challenge, the bad guy still cannot decrypt the session key and 
-therefore cannot examine the encrypted data.
-
-
-Hickman							[page 22]
-
-Appendix E: Terms
-
-Application Protocol
-An application protocol is a protocol that normally layers directly on 
-top of TCP/IP. For example: HTTP, TELNET, FTP, and SMTP.
-
-Authentication
-Authentication is the ability of one entity to determine the identity of 
-another entity. Identity is defined by this document to mean the 
-binding between a public key and a name and the implicit ownership 
-of the corresponding private key.
-
-Bulk Cipher
-This term is used to describe a cryptographic technique with certain 
-performance properties. Bulk ciphers are used when large quantities of 
-data are to be encrypted/decrypted in a timely manner. Examples 
-include RC2, RC4, and IDEA.
-
-Client
-In this document client refers to the application entity that is initiates a 
-connection to a server.
-
-CLIENT-READ-KEY
-The session key that the client uses to initialize the client read cipher. 
-This key has the same value as the SERVER-WRITE-KEY.
-
-CLIENT-WRITE-KEY
-The session key that the client uses to initialize the client write cipher. 
-This key has the same value as the SERVER-READ-KEY.
-
-MASTER-KEY
-The master key that the client and server use for all session key 
-generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY, 
-SERVER-READ-KEY and SERVER-WRITE-KEY are generated 
-from the MASTER-KEY.
-
-MD2
-MD2 [8] is a hashing function that converts an arbitrarily long data 
-stream into a digest of fixed size. This function predates MD5 [7] 
-which is viewed as a more robust hash function [9].
-
-MD5
-MD5 [7] is a hashing function that converts an arbitrarily long data 
-stream into a digest of fixed size. The function has certain properties 
-that make it useful for security, the most important of which is it's 
-inability to be reversed.
-
-Nonce
-A randomly generated value used to defeat "playback" attacks. One 
-party randomly generates a nonce and sends it to the other party. The 
-receiver encrypts it using the agreed upon secret key and returns it to 
-the sender. Because the nonce was randomly generated by the sender 
-this defeats playback attacks because the replayer can't know in 
-advance the nonce the sender will generate. The receiver denies 
-connections that do not have the correctly encrypted nonce.
-
-Hickman							[page 23]
-
-Non-repudiable Information Exchange
-When two entities exchange information it is sometimes valuable to 
-have a record of the communication that is non-repudiable. Neither 
-party can then deny that the information exchange occurred. Version 2 
-of the SSL protocol does not support Non-repudiable information 
-exchange.
-
-Public Key Encryption
-Public key encryption is a technique that leverages asymmetric ciphers. 
-A public key system consists of two keys: a public key and a private 
-key. Messages encrypted with the public key can only be decrypted 
-with the associated private key. Conversely, messages encrypted with 
-the private key can only be decrypted with the public key. Public key 
-encryption tends to be extremely compute intensive and so is not 
-suitable as a bulk cipher.
-
-Privacy
-Privacy is the ability of two entities to communicate without fear of 
-eavesdropping. Privacy is often implemented by encrypting the 
-communications stream between the two entities.
-
-RC2, RC4
-Proprietary bulk ciphers invented by RSA (There is no good reference 
-to these as they are unpublished works; however, see [9]). RC2 is 
-block cipher and RC4 is a stream cipher.
-
-Server
-The server is the application entity that responds to requests for 
-connections from clients. The server is passive, waiting for requests 
-from clients.
-
-Session cipher
-A session cipher is a "bulk" cipher that is capable of encrypting or 
-decrypting arbitrarily large amounts of data. Session ciphers are used 
-primarily for performance reasons. The session ciphers used by this 
-protocol are symmetric. Symmetric ciphers have the property of using 
-a single key for encryption and decryption.
-
-Session identifier
-A session identifier is a random value generated by a client that 
-identifies itself to a particular server. The session identifier can be 
-thought of as a handle that both parties use to access a recorded secret 
-key (in our case a session key). If both parties remember the session 
-identifier then the implication is that the secret key is already known 
-and need not be negotiated.
-
-Session key
-The key to the session cipher. In SSL there are four keys that are called 
-session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY, 
-SERVER-READ-KEY, and SERVER-WRITE-KEY.
-
-SERVER-READ-KEY
-The session key that the server uses to initialize the server read cipher. 
-This key has the same value as the CLIENT-WRITE-KEY.
-
-
-Hickman							[page 24]
-
-SERVER-WRITE-KEY
-The session key that the server uses to initialize the server write cipher. 
-This key has the same value as the CLIENT-READ-KEY.
-
-Symmetric Cipher
-A symmetric cipher has the property that the same key can be used for 
-decryption and encryption. An asymmetric cipher does not have this 
-behavior. Some examples of symmetric ciphers: IDEA, RC2, RC4.
-
-
-
-References
-
-[1] CCITT. Recommendation X.208: "Specification of Abstract Syntax 
-Notation One (ASN.1). 1988.
-
-[2] CCITT. Recommendation X.209: "Specification of Basic Encoding 
-Rules for Abstract Syntax Notation One (ASN.1). 1988.
-
-[3] CCITT. Recommendation X.509: "The Directory - Authentication 
-Framework". 1988.
-
-[4] CCITT. Recommendation X.520: "The Directory - Selected Attribute 
-Types". 1988.
-
-[5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, 
-November 1993.
-
-[6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, 
-Version 1.5, November 1993.
-
-[7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 
-1992.
-
-[8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 
-1992.
-
-[9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source 
-Code in C, Published by John Wiley & Sons, Inc. 1994.
-
-[10] M. Abadi and R. Needham. Prudent engineering practice for 
-cryptographic protocols. 1994.
-
-Patent Statement
-
-This version of the SSL protocol relies on the use of patented public key 
-encryption technology for authentication and encryption. The Internet 
-Standards Process as defined in RFC 1310 requires a written statement 
-from the Patent holder that a license will be made available to applicants 
-under reasonable terms and conditions prior to approving a specification as 
-a Proposed, Draft or Internet Standard.
-
-The Massachusetts Institute of Technology and the Board of Trustees of 
-the Leland Stanford Junior University have granted Public Key Partners 
-(PKP) exclusive sub-licensing rights to the following patents issued in the 
-
-Hickman							[page 25]
-
-United States, and all of their corresponding foreign patents:
-
-Cryptographic Apparatus and Method ("Diffie-Hellman")		
-	No. 4,200,770
-
-Public Key Cryptographic Apparatus and Method ("Hellman-Merkle")	
-	No. 4,218,582
-
-Cryptographic Communications System and Method ("RSA")		
-	No. 4,405,829
-
-Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig")	
-	No. 4,424,414
-
-These patents are stated by PKP to cover all known methods of practicing 
-the art of Public Key encryption, including the variations collectively 
-known as ElGamal.
-
-Public Key Partners has provided written assurance to the Internet Society 
-that parties will be able to obtain, under reasonable, nondiscriminatory 
-terms, the right to use the technology covered by these patents. This 
-assurance is documented in RFC 1170 titled "Public Key Standards and 
-Licenses". A copy of the written assurance dated April 20, 1990, may be 
-obtained from the Internet Assigned Number Authority (IANA).
-
-The Internet Society, Internet Architecture Board, Internet Engineering 
-Steering Group and the Corporation for National Research Initiatives take 
-no position on the validity or scope of the patents and patent applications, 
-nor on the appropriateness of the terms of the assurance. The Internet 
-Society and other groups mentioned above have not made any 
-determination as to any other intellectual property rights which may apply 
-to the practice of this standard. Any further consideration of these matters 
-is the user's own responsibility.
-
-Security Considerations
-
-This entire document is about security.
-
-Author's Address
-
-Kipp E.B. Hickman
-Netscape Communications Corp.
-501 East Middlefield Rd.
-Mountain View, CA 94043
-kipp@netscape.com
-
-
-Hickman							[page 26]
-
-
-
-
-
-
-
diff --git a/doc/protocol/draft-housley-evidence-extns-01.txt b/doc/protocol/draft-housley-evidence-extns-01.txt
deleted file mode 100644
index 639dd0b481..0000000000
--- a/doc/protocol/draft-housley-evidence-extns-01.txt
+++ /dev/null
@@ -1,1176 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-November 2006                                          RedPhone Security
-Expires: May 2007                                             R. Housley
-                                                          Vigil Security
-
-
-           Transport Layer Security (TLS) Evidence Extensions
-                 <draft-housley-evidence-extns-01.txt>
-
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies evidence creation extensions to the Transport
-   Layer Security (TLS) Protocol.  Extension types are carried in the
-   client and server hello message extensions to confirm that both
-   parties support the protocol features needed to perform evidence
-   creation.  The syntax and semantics of the evidence creation alerts
-   and messages are described in detail.
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                             November 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned when the original design criteria for
-   TLS were determined.  The extensions specified in this document
-   support evidence creation in environments where the peers in the TLS
-   session cooperate to create persistent evidence of the TLS-protected
-   application data.  Such evidence may be necessary to meet business
-   requirements, including regulatory requirements.  Also, evidence may
-   be used in tandem with authorization information to make high
-   assurance access control and routing decisions in military and
-   government environments.  Evidence created using this extension may
-   also be used to audit various aspects of the TLS handshake, including
-   the cipher suite negotiation and the use of other TLS extensions.  In
-   many cases, the evidence does not need to be validated by third
-   parties; however, in other cases, the evidence might be validated by
-   third parties.  To accommodate all of these situations, the evidence
-   is generated using a digital signature.  Since validation of a
-   digital signature requires only public information, evidence
-   generated with this mechanism is suitable for sharing with third
-   parties.
-
-   When digital certificates are to be employed in evidence creations,
-   the client must obtain the public key certificate (PKC) for the
-   server, and the server must obtain the PKC for the client.  This is
-   most easily accomplished by using the PKCs provided in the Handshake
-   Protocol Certificate messages.  Further, both parties SHOULD have an
-   opportunity to validate the PKC that will be used by the other party
-   before evidence creation.  Again, this is naturally accomplished
-   using the Handshake Protocol, where the TLS session can be rejected
-   if the PKC cannot be validated.
-
-   This document describes evidence creation TLS extensions supporting
-   both TLS 1.0 and TLS 1.1.  These extensions observe the conventions
-   defined for TLS Extensions [TLSEXT].  The extensions are designed to
-   be backwards compatible, meaning that the protocol alerts and
-   messages associated with the evidence creation extensions will be
-   exchanged only if the client indicates support for them in the client
-   hello message and the server indicates support for them in the server
-   hello message.
-
-   Clients typically know the context of the TLS session before it is
-   established.  As a result, the client can request the use of the
-   evidence creation extensions in sessions where they might be needed.
-   Servers accept extended client hello messages, even if the server
-   does not support the all of the listed extensions.  However, the
-   server will not indicate support for any extensions that are not
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                             November 2006
-
-
-   "understood" by the implementation.  At the end of the hello message
-   exchange, the client may reject communications with servers that do
-   not support the evidence creation extensions, or the client may
-   accept the situation and proceed, whichever is appropriate.
-
-1.1. Conventions
-
-   The syntax for the evidence creation messages is defined using the
-   TLS Presentation Language, which is specified in Section 4 of
-   [TLS1.0].
-
-   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 [STDWORDS].
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the evidence creation alerts
-   and messages in the TLS session.  The first pair of evidence creation
-   alerts indicates the beginning of the protected content that will be
-   covered by the evidence.  The first pair of alerts can appear any
-   place after the TLS Handshake Protocol Finished messages, which
-   ensures that they are integrity protected.  The second pair of
-   evidence creation alerts indicates the ending of the protected
-   content that will be covered by the evidence.  Immediately after the
-   reception of the final alert, a pair of Evidence Protocol messages is
-   exchanged to create the persistent evidence.
-
-   Generating evidence is not compatible with Diffie-Hellman Ephemeral
-   (DHE) key exchanges.  DHE does not permit the same keying material to
-   be generated for validation of the evidence after the TLS session is
-   over.  Persistent evidence requires the use of a digital signature so
-   that it can be validated well after the TLS session is over.
-
-   The ClientHello message includes an indication that the evidence
-   creation messages are supported.  The ServerHello message also
-   includes an indication that the evidence creation messages are
-   supported.  Both the client and the server MUST indicate support for
-   the evidence protocol alerts and messages; otherwise they MUST NOT be
-   employed by either the client or the server.
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                             November 2006
-
-
-      Client                                                 Server
-
-      ClientHello               -------->
-                                                        ServerHello
-                                                       Certificate+
-                                                 ServerKeyExchange*
-                                                CertificateRequest+
-                                <--------           ServerHelloDone
-      Certificate+
-      ClientKeyExchange
-      CertificateVerify+
-      ChangeCipherSpec
-      Finished                  -------->
-                                                   ChangeCipherSpec
-                                <--------                  Finished
-      Application Data          <------->          Application Data
-      Alert(evidence_start1)    -------->
-                                                   Application Data
-                                <--------    Alert(evidence_start2)
-
-      Application Data          <------->          Application Data
-      Alert(evidence_end1)      -------->
-                                                   Application Data
-                                <--------      Alert(evidence_end2)
-      EvidenceRequest           -------->
-                                <--------          EvidenceResponse
-      Application Data          <------->          Application Data
-
-       *  Indicates optional or situation-dependent messages that
-          are not always sent.
-       +  Indicates messages optional to the TLS handshake that
-          MUST be sent when using TLS evidence.
-
-
-           Figure 1. Example TLS Session with Evidence Creation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                             November 2006
-
-
-2. Evidence Extension Types
-
-   The general extension mechanisms enable clients and servers to
-   negotiate whether to use specific extensions, and how to use specific
-   extensions.  As specified in [TLSEXT], the extension format used in
-   the extended client hello message and extended server hello message
-   within the TLS Handshake Protocol is:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the preceding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   preceding extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of the evidence_creation extension
-   type.  This specification adds one new type to ExtensionType:
-
-      enum {
-         evidence_creation(TBD), (65535)
-      } ExtensionType;
-
-   The evidence_creation extension is relevant when a session is
-   initiated and also for any subsequent session resumption.  However, a
-   client that requests resumption of a session does not know whether
-   the server has maintained all of the context necessary to accept this
-   request, and therefore the client SHOULD send an extended client
-   hello message that includes the evidence_creation extension type.
-   This indicates that the client requests the server's continued
-   cooperation in creating evidence.  If the server denies the
-   resumption request, then the evidence_creation extension will be
-   negotiated normally using the full Handshake protocol.
-
-   Clients MUST include the evidence_creation extension in the extended
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                             November 2006
-
-
-   client hello message to indicate their desire to send and receive
-   evidence creation alerts and messages.  The extension_data field
-   indicates the evidence creation algorithms that are supported.  The
-   format is indicated with the EvidenceCreateList type:
-
-      uint16 EvidenceCreateSuite[2];
-
-      struct {
-         EvidenceCreateSuite evidence_suites<2..2^16-1>;
-      } EvidenceCreateList;
-
-   The EvidenceCreateList enumerates the evidence creation algorithms
-   that are supported by the client.  The client MUST order the entries
-   from most preferred to least preferred, but all of the entries MUST
-   be acceptable to the client.  Values are defined in Appendix A, and
-   others can be registered in the future.
-
-   Servers that receive an extended client hello message containing the
-   evidence_creation extension MUST respond with the evidence_creation
-   extension in the extended server hello message if the server is
-   willing to send and receive evidence creation alerts and messages.
-   The evidence_creation extension MUST be omitted from the extended
-   server hello message if the server is unwilling to send and receive
-   using one of the evidence creation algorithm suites identified by the
-   client.  The extension_data field indicates the evidence creation
-   algorithm suite that the server selected from the list provided by
-   the client.  The format is indicated with the EvidenceCreateSuite
-   type defined above.
-
-3. Alert Messages
-
-   This document specifies the use of four new alert message
-   descriptions: the evidence_start1, evidence_start2, evidence_end1,
-   and evidence_end2.  These descriptions are specified in Sections 3.1,
-   3.2, 3.3, and 3.4, respectively.  The alert descriptions are
-   presented below in the order they MUST be sent; sending alerts in an
-   unexpected order results in a fatal error.  These descriptions are
-   always used with the warning alert level.  This specification adds
-   four new types to AlertDescription:
-
-      enum {
-         evidence_start1(TBD),
-         evidence_start2(TBD),
-         evidence_end1(TBD),
-         evidence_end2(TBD),
-         evidence_failure(TBD),
-         (255)
-      } AlertDescription;
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                             November 2006
-
-
-3.1. The evidence_start1 Description
-
-   The client and the server need to synchronize evidence creation.
-   Either party may indicate the desire to start creating evidence by
-   sending the evidence_start1 alert.  If the other party is ready to
-   begin creating evidence, then the other party MUST send an
-   evidence_start2 alert in response to the evidence_start1 alert that
-   was sent.  If the other party is unwilling to begin creating
-   evidence, the other party MUST respond with fatal
-   evidence_failure(TBD) alert and terminate the TLS session.
-
-   Evidence may be collected more than once during a TLS session;
-   however, evidence gathering MUST NOT be nested.  That is, a party
-   sending the a second evidence_start1 alert before evidence_end2 alert
-   has occurred and the evidence protocol has completed is a protocol
-   violation.  Reception of an evidence_start1 alert that would result
-   in evidence nesting MUST be responded to with a fatal
-   evidence_failure(TBD) alert and terminating the TLS session.
-
-   Digital signatures are used in evidence creation.  If an
-   evidence_start1 alert is received before the other party has provided
-   a valid PKC, then the evidence_start1 alert recipient MUST terminate
-   the TLS session using a fatal certificate_unknown alert.
-
-3.2. The evidence_start2 Description
-
-   The evidence_start2 alert is sent in response to the evidence_start1
-   alert.  By sending the evidence_start2 alert, the sending party
-   indicates that they are also ready to begin creating evidence.  After
-   this pair of alerts is exchanged, both the client and the server use
-   the hash function indicated in the extended server hello message to
-   start computing the evidence.  Each party computes two independent
-   hash values: one for each octet that is written, and one for each
-   octet that is read.
-
-   Digital signatures are used in evidence creation.  If an
-   evidence_start2 alert is received before the other party has provided
-   a valid PKC, then the evidence_start2 alert recipient MUST terminate
-   the TLS session using a fatal certificate_unknown alert.
-
-3.3. The evidence_end1 Description
-
-   Either party may initiate the closure of an evidence-creating
-   interval and the exchange of evidence messages by sending the
-   evidence_end1 alert.  Upon sending evidence_end1, the sender MUST not
-   send any more application data on this connection until the Evidence
-   Protocol messages are exchanged.
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                             November 2006
-
-
-   The evidence_end1 alert sender MAY initiate the Evidence Protocol as
-   described in Section 4 at any time following this alert.  The
-   evidence_end1 alert sender SHOULD ensure that it has received all
-   pending application data writes from the other party before
-   initiating the Evidence Protocol.  One way to ensure that all of the
-   application data has been received it to wait for the receipt of an
-   evidence_end2 alert.  If the Evidence Protocol begins before all of
-   the application data is available, the result will be a fatal
-   evidence_failure(TBD) alert when signature verification fails.
-
-3.4. The evidence_end2 Description
-
-   The evidence_end2 alert is sent in response to the evidence_end1
-   alert.  The evidence_end1 alert receiver SHOULD complete any pending
-   writes.  The intent is to include any application data that would be
-   sent in response to application data that was received before the
-   evidence_end1 alert as part of evidence creation.  Once the pending
-   writes are complete, the evidence_end1 alert receiver sends the
-   evidence_end2 alert.
-
-   At this point, each party completes the hash value computations.
-
-   The evidence_end2 alert receiver MUST respond by initiating the
-   Evidence Protocol as described in Section 4, if it has not already
-   done so.
-
-3.5. The evidence_failure Description
-
-   The evidence_failure fatal alert is sent to indicate a failure in
-   evidence creation.  During evidence synchronization, this alert
-   indicates that the sending party is unwilling to begin evidence
-   creation.  During the Evidence Protocol, this alert indicates that
-   the evidence provided by the other party is not acceptable or cannot
-   be validated.
-
-4. Evidence Protocol
-
-   This document specifies an additional TLS Protocol: the Evidence
-   Protocol.  It is used to create persistent evidence of the TLS
-   session content.  This specification adds one new Record layer
-   ContentType:
-
-      enum {
-         evidence(TBD),
-         (255)
-      } ContentType;
-
-
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                             November 2006
-
-
-   Persistence evidence of the TLS session content is produced by the
-   TLS Evidence Protocol.  Evidence messages are supplied to the TLS
-   Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-   The Evidence Protocol structure follows:
-
-      enum {
-         request(1), response(2), (255)
-      } EvidenceMsgType;
-
-      struct {
-         EvidenceMsgType evidence_msg_type;
-         uint24 length; /* number of octets in message */
-         select (EvidenceMsgType) {
-            case request:     EvidenceRequest;
-            case response:    EvidenceResponse;
-         } body;
-      } EvidenceProtocol;
-
-   The Evidence Protocol messages are presented below in the order they
-   MUST be sent; sending evidence messages in an unexpected order
-   results in a fatal unexpected_message(10) alert.  The EvidenceRequest
-   message and the EvidenceResponse message are specified in Section 4.2
-   and Section 4.3, respectively.  Section 4.1 describes structures that
-   are used in the EvidenceRequest and EvidenceResponse messages.
-
-4.1. Certificates and Digital Signatures
-
-   The evidence Protocol makes use of the ASN.1Cert definition used
-   elsewhere in TLS.  It is repeated here for convenience.
-
-      opaque ASN.1Cert<1..2^24-1>;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                             November 2006
-
-
-   The EvidenceSignature definition is very similar to the Signature
-   definition used elsewhere in TLS.  The EvidenceSignature definition
-   signs hash[hash_size], but the Signature definition used elsewhere in
-   TLS signs a combination of an md5_hash and a sha_hash.  Also, the
-   EvidenceSignature definition excludes the anonymous case.
-
-      enum { rsa, dsa, ecdsa } EvidenceSignatureAlgorithm;
-
-      select (EvidenceSignatureAlgorithm)
-      {   case rsa:
-              digitally-signed struct {
-                  opaque hash[hash_size];
-              };
-          case dsa:
-              digitally-signed struct {
-                  opaque hash[hash_size];
-              };
-          case ecdsa:
-              digitally-signed struct {
-                  opaque hash[hash_size];
-              };
-      } EvidenceSignature;
-
-   The hash algorithm and the hash_size depend on evidence create
-   algorithm suite selected by the server in the evidence_creation
-   extension.
-
-4.2. EvidenceRequest Message
-
-   The EvidenceRequest message contains the evidence_end1 alert sender's
-   contribution to the persistent evidence.  It employs the evidence
-   create algorithm suite selected by the server in the
-   evidence_creation extension in the extended server hello message.
-
-      struct {
-         Evidence evidence<1..2^16-1>;
-         ASN.1Cert party1_certificate;
-         EvidenceSignature party1_signature;
-      } EvidenceRequest;
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 10]
-
-Internet-Draft                                             November 2006
-
-
-      struct {
-         EvidenceCreateSuite evidence_suite;
-         uint64 gmt_unix_time;
-         uint64 app_data_sent_offset;
-         uint64 app_data_received_offset;
-         opaque handshake_protocol_hash<1..512>;
-         opaque app_data_sent_hash<1..512>;
-         opaque app_data_received_hash<1..512>;
-      } Evidence;
-
-   The elements of the EvidenceRequest structure are described below:
-
-      evidence
-         Contains an evidence create algorithm identifier, a timestamp,
-         and three hash values in the Evidence structure as described
-         below.
-
-      party1_certificate
-         Contains the X.509 certificate of the signer.  While this
-         certificate was probably exchanged and validated in the
-         Handshake Protocol, inclusion here makes it clear which
-         certificate was employed by the signer when the evidence is
-         validated in the future, possibly by a third party.
-
-      party1_signature
-         Contains the digital signature computed by the sender of the
-         evidence_end1 alert using the evidence creation algorithm suite
-         identified in evidence_create_suite.  The hash value is
-         computed as:
-
-            Hash(evidence)
-
-   The elements of the Evidence structure are described below:
-
-      evidence_suite
-         Indicates the evidence creation algorithm suite selected by the
-         server in the evidence_creation extension in the Handshake
-         Protocol.  This value determines the structure of the hash
-         values and digital signatures.
-
-      gmt_unix_time
-         Indicates the current date and time according to the local
-         system clock used by the sender of the evidence_end1 alert.
-         This time value is intended to represent the moment in time
-         that evidence_end1 was sent.  Unlike other places in the TLS
-         protocol, a 64-bit value is used to ensure that time values do
-         not wrap in 2038.
-
-
-
-
-Brown & Housley                                                [Page 11]
-
-Internet-Draft                                             November 2006
-
-
-      app_data_sent_offset
-         Indicates the number of octets that were sent as part of this
-         TLS session before evidence collection began.
-
-      app_data_received_offset
-         Indicates the number of octets that were received as part of
-         this TLS session before evidence collection began.
-
-      handshake_protocol_hash
-         Compute as:
-
-            Hash(handshake_messages),
-
-         where handshake_messages refers to all Handshake Protocol
-         messages sent or received, beginning with the most recent
-         client hello message.  If the double handshake mechanism
-         described in the security considerations of [TLSAUTHZ] is used
-         to encrypt the Handshake Protocol, the plaintext form of these
-         messages is used in calculating this hash value.
-
-         Verification of the handshake_protocol_hash is performed using
-         the plaintext form of the Handshake protocol messages.  For
-         this hash value to be validated at a later time, this
-         information must be saved as part of the overall evidence.  Any
-         attempt to save this data must ensure that it is not
-         inappropriately disclosed by employing suitable physical
-         protection or cryptographic mechanisms that are at least as
-         strong as the selected TLS ciphersuite.  Suitable controls are
-         discussed further in the Security Considerations; see Section
-         6.
-
-         In the case of successful TLS session resumption, the most
-         recent client hello message will contain a valid
-         ClientHello.session_id value as well as extensions, and these
-         extensions may include sensitive data.  The TLS Authorization
-         Extension [AUTHZ] is one example where an extension might
-         contain sensitive information.  Thus, even when session
-         resumption is employed, the content of the Handshake protocol
-         messages ought to be protected.
-
-         TLS users should ensure that the content of the Handshake
-         protocol messages contain sufficient evidence to determine the
-         intent of the signers, where "signers" are defined as the
-         subject identities in the exchanged X.509 certificates.
-         Clients and servers MAY record the protocol messages containing
-         an expression of the intent of the signers using a suitable TLS
-         extension [TLSEXT], such as [TLSAUTHZ].  For example, a client
-         may request access to a resource provided by the server,
-
-
-
-Brown & Housley                                                [Page 12]
-
-Internet-Draft                                             November 2006
-
-
-         provide sufficient authentication and authorization information
-         grounds to convince the server to grant the requested access,
-         and receive an affirmative response from the server.  A record
-         of TLS Handshake protocol messages representing this example
-         may provide a sufficient record of the intent of both the
-         client and the server.
-
-      app_data_sent_hash
-         Compute as:
-
-            Hash(sent_application_data),
-
-         where sent_application_data refers to all of the Application
-         Data messages sent since the most recent evidence_start1 or
-         evidence start2 alert was sent, and ending with the sending of
-         the evidence_end1 alert.  The alerts are not application data,
-         and they are not included in the hash computation.
-
-      app_data_received_hash
-         Compute as:
-
-            Hash(received_application_data),
-
-         where received_application_data refers to all of the
-         Application Data messages received since the most recent
-         evidence_start1 or evidence start2 alert was received, and
-         ending with the receipt of the evidence_end2 alert.  The alerts
-         are not application data, and they are not included in the hash
-         computation.
-
-4.3. EvidenceResponse Message
-
-   The EvidenceResponse message contains the complete persistent
-   evidence.  The value is saved by one or both parties as evidence of
-   the TLS session content identified by the evidence_start1,
-   evidence_start2, evidence_end1, and evidence_end2 alerts.
-
-      struct {
-         Evidence evidence<1..2^16-1>;
-         ASN.1Cert party1_certificate;
-         EvidenceSignature party1_signature;
-         ASN.1Cert party2_certificate;
-         EvidenceSignature party2_signature;
-      } EvidenceResponse;
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 13]
-
-Internet-Draft                                             November 2006
-
-
-   The elements of the EvidenceResponse structure are described below:
-
-      evidence
-         Contains an evidence create algorithm identifier, a timestamp,
-         and three hash values in the Evidence structure as described in
-         section 4.2.  The evidence creation algorithm MUST match the
-         evidence create algorithm suite selected by the server in the
-         evidence_creation extension in the extended server hello
-         message.  The timestamp MUST be acceptable to the
-         EvidenceRequest recipient as the same value is provided in the
-         EvidenceResponse message.  The three hash values received in
-         the EvidenceRequest message MUST match locally computed values
-         over the same data.  Note that the app_data_sent_hash and the
-         app_data_received_hash values represent the session from the
-         perspective of the EvidenceRequest originator, and the values
-         are not swapped to represent the EvidenceRequest recipient
-         perspective.  If any of these conditions is not met, then the
-         EvidenceResponse message MUST NOT be sent, and the TLS session
-         MUST be closed immediately after sending a fatal
-         evidence_failure(TBD) alert.
-
-      party1_certificate
-         Contains the X.509 certificate of the sender of the
-         evidence_end1 alert.  If this certificate cannot be validated,
-         then TLS session must be closed immediately after sending one
-         of the following fatal alerts: bad_certificate(42),
-         unsupported_certificate(43), certificate_revoked(44), or
-         certificate_expired(45).  These alerts are described in Section
-         7.2.2 of [TLS1.1].
-
-      party1_signature
-         Contains the digital signature computed by the sender of the
-         evidence_end1 alert.  If this signature cannot be validated,
-         then TLS session must be closed immediately after sending a
-         fatal evidence_failure(TBD) alert.
-
-      party2_certificate
-         Contains the X.509 certificate of the sender of the
-         evidence_end2 alert.  While this certificate was probably
-         exchanged and validated in the Handshake Protocol, inclusion
-         here make it clear which certificate was employed by the signer
-         when the evidence is validated in the future, possibly by a
-         third party.
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 14]
-
-Internet-Draft                                             November 2006
-
-
-      Party2_signature
-         Contains the digital signature computed by the sender of the
-         evidence_end2 alert using the evidence creation algorithm suite
-         identified in evidence_suite.  The hash value is computed as:
-
-            Hash(evidence)
-
-5. IANA Considerations
-
-   This document defines one TLS extension: evidence_creation(TBD).
-   This extension type value is assigned from the TLS Extension Type
-   registry defined in [TLSEXT].
-
-   This document defines five TLS alert descriptions: the
-   evidence_start1(TBD), evidence_start2(TBD), evidence_end1(TBD),
-   evidence_end2(TBD), and evidence_failure(TBD).  These alert
-   descriptions are assigned from the TLS Alert registry defined in
-   [TLS1.1].
-
-   This document defines one TLS ContentType: evidence(TBD).  This
-   ContentType value is assigned from the TLS ContentType registry
-   defined in [TLS1.1].
-
-   This document establishes a registry for TLS Evidence Protocol
-   EvidenceMsgType.  The first two entries in the registry are
-   request(1) and response(2).  All additional TLS Evidence Protocol
-   EvidenceMsgType values are assigned by Standards Action as described
-   in [IANA].
-
-   This document establishes a registry for Evidence Create Algorithm
-   suite identifiers.   Appendix A lists the initial values for this
-   registry.  Evidence Create Algorithm suite identifier values with the
-   first byte in the range 0-191 (decimal) inclusive are assigned by
-   Standards Action as described in [IANA].  Values with the first byte
-   in the range 192-254 (decimal) are assigned by Specification Required
-   as described in [IANA].  Values with the first byte 255 (decimal) are
-   reserved for Private Use as described in [IANA].
-
-6. Security Considerations
-
-   This document describes an extension to the TLS protocol, and the
-   security considerations in [TLS1.1] and [TLSEXT] apply.
-   Additionally, temporal and storage security considerations are
-   discussed below.
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 15]
-
-Internet-Draft                                             November 2006
-
-
-6.1. Temporal Considerations
-
-   Generating evidence that covers Application Data values that do not
-   explicitly or implicitly indicate the point in time at which the
-   Application Data was transferred over the TLS session might give rise
-   to replay attacks, post-dating, pre-dating, or other temporal
-   disputes.  To avoid these concerns, the evidence includes an
-   indication of the date and time.  The TLS implementation MUST NOT
-   attempt to extract date and time values from the Application Data;
-   doing so is likely to be error prone.  Instead, the date and time
-   SHOULD come from a local clock or a trustworthy time server.  Date
-   and time are provided by one of the parties, and the other party
-   determines that the date and time value is sufficiently accurate.
-
-   When a more highly trusted time source is needed, the Time-Stamp
-   Protocol [TSP] can be used to obtain a time-stamp on the evidence
-   from a trusted third party.
-
-6.2. Storage Considerations
-
-   Parties that choose to preserve a plaintext record of Application
-   Data or Handshake Protocol messages for evidence verification at a
-   later time must ensure must ensure that this data is not
-   inappropriately disclosed by employing suitable physical protection
-   or cryptographic mechanisms that are at least as strong as the
-   selected TLS ciphersuite.
-
-   Suitable physical controls for the protection of Application Data or
-   Handshake Protocol messages containing keying material or sensitive
-   data should use removable storage media in conjunction with durable,
-   locking storage containers.  If the removable media is transferred
-   from one location to another or backup copies are made, secure
-   handling protections ought to be employed, which might include the
-   use of insured or bonded couriers.
-
-   A suitable cryptographic mechanism provides confidentiality
-   protection, since the hash value in the evidence itself provides
-   integrity protection.  One reasonable solution is to encrypt the
-   Handshake Protocol messages and Application Data messages with a
-   fresh symmetric encryption key using the same algorithm that was
-   negotiated for the selected TLS ciphersuite.  The key generation
-   should follow the recommendations in [RANDOM].  Then, the symmetric
-   key is encrypted for storage with the party's RSA public key or long-
-   lived key-encryption key.  The Cryptographic Message Syntax (CMS)
-   [CMS] offers a convenient way to keep all of this information
-   together.
-
-
-
-
-
-Brown & Housley                                                [Page 16]
-
-Internet-Draft                                             November 2006
-
-
-   An alternative cryptographic mechanism is to save the TLS session
-   itself.  The negotiated TLS ciphersuite was already used to protect
-   the Application Data messages, and the Handshake Protocol messages
-   contain the keying material necessary to decrypt them if the party
-   retains the private keys and/or pre-shared secrets.
-
-7. References
-
-7.1. Normative References
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-   [DSS]        Federal Information Processing Standards Publication
-                (FIPS PUB) 186, Digital Signature Standard, 2000.
-
-   [PKCS1]      Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
-                RFC 2313, March 1998.
-
-   [PKIX1]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                Public Key Infrastructure - Certificate and
-                Certificate Revocation List (CRL) Profile", RFC 3280,
-                April 2002.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, April 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 4366, April 2006.
-
-   [SHA]        Federal Information Processing Standards Publication
-                (FIPS PUB) 180-2, Secure Hash Algorithm, 2002.
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [X9.62]      X9.62-1998, "Public Key Cryptography For The Financial
-                Services Industry: The Elliptic Curve Digital
-                Signature Algorithm (ECDSA)", January 7, 1999.
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 17]
-
-Internet-Draft                                             November 2006
-
-
-7.2. Informative References
-
-   [AUTHZ]      Brown, M., and R. Housley, "Transport Layer Security
-                (TLS) Authorization Extensions", work in progress,
-                draft-housley-tls-authz-extns.
-
-   [CMS]        Housley, R., "Cryptographic Message Syntax (CMS)",
-                RFC 3852, July 2004.
-
-   [TSP]        Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
-                "Internet X.509 Public Key Infrastructure: Time-Stamp
-                Protocol (TSP)", RFC 3161,August 2001.
-
-8.  Acknowledgements
-
-   Thanks to C. Robert Beattie, J.D. and Randy V. Sabett, J.D., CISSP
-   for their observations and comparisons between the Uniform Electronic
-   Transactions Act (1999) prepared by the National Conference of
-   Commissioners on Uniform State Laws versus the American Bar
-   Association's Digital Signature Guidelines (1996), their observations
-   regarding the strengths and weaknesses of these two approaches, and
-   their desire to promote trust and reduce potential for litigation in
-   online transactions.  Their pro bono contribution of time and
-   expertise deserves recognition.
-
-   This material is based, in part, upon work supported by the United
-   States Navy Space and Naval Warfare Systems Command under Contract
-   No. N00039-06-C-0097.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 18]
-
-Internet-Draft                                             November 2006
-
-
-Appendix A.  Evidence Create Algorithms
-
-   The following values define the EvidenceCreateSuite identifiers used
-   in the TLS Evidence Extensions.
-
-   An EvidenceCreateSuite defines a cipher specification supported by
-   TLS Evidence Extensions.  A suite identifier names a public key
-   signature algorithm and an associated one-way hash function.  A
-   registration is named as follows:
-
-      <SignatureAlgorithm>_WITH_<HashFunction>
-
-   These components have the following meaning:
-
-      <SignatureAlgorithm>
-         Specifies the digital signature algorithm and key length
-         associated with the algorithm.  It is used to digitally sign
-         the evidence.  The "RSA_1024" value indicates the use of the
-         PKCS#1 v1.5 [PKCS1] digital signature algorithm using a
-         1024-bit public key.  The "DSS_1024" value indicates the use of
-         the DSS digital signature algorithm [DSS] with a 1024-bit
-         public key.  The "ECDSA_P384" value indicates the use of the
-         ECDSA digital signature algorithm [X9.62] using the P-384 named
-         elliptic curve.
-
-      <HashFunction>
-         Specifies the one-way hash function used as part of the digital
-         signature. The "SHA_1", "SHA_224", "SHA_256", "SHA_384", and
-         "SHA_512" values identify members of the Secure Hash Algorithm
-         family of one-way- hash functions [SHA].
-
-   In most cases it will be appropriate to use the same algorithms and
-   certified public keys that were negotiated in the TLS Handshake
-   Protocol.  The following additional steps are required in order to
-   employ the digital signature aspects of a TLS CipherSuite to a valid
-   EvidenceCreateSuite:
-
-      1) CipherSuites that do not include signature-capable certificates
-         cannot be used as EvidenceCreateSuite.
-
-      2) CipherSuites that specify the use of MD5 one-way hash function
-         should not be used as EvidenceCreateSuite.
-
-   Of course, any aspect of a CipherSuite that deals with symmetric
-   ciphers and symmetric cipher key lengths is not relevant to the
-   EvidenceCreateSuite.
-
-
-
-
-
-Brown & Housley                                                [Page 19]
-
-Internet-Draft                                             November 2006
-
-
-   All public key certificate profiles used in TLS are defined by the
-   IETF PKIX working group in [PKIX1].  When a key usage extension is
-   present, then either the digitalSignature bit or the nonRepudiation
-   bit MUST be set for the public key to be eligible for signing
-   evidence.  If both bits are set, then this requirement is satisfied.
-
-   The following EvidenceCreateSuite definitions are made at this time.
-   Section 5 specifies the procedures for registering additional
-   EvidenceCreateSuite definitions.
-
-      EvidenceCreateSuite RSA_1024_WITH_SHA_1       = { 0x00, 0x01 };
-      EvidenceCreateSuite RSA_1024_WITH_SHA_256     = { 0x00, 0x02 };
-      EvidenceCreateSuite RSA_2048_WITH_SHA_256     = { 0x00, 0x03 };
-
-      EvidenceCreateSuite DSS_1024_WITH_SHA_1       = { 0x00, 0x11 };
-      EvidenceCreateSuite DSS_2048_WITH_SHA_256     = { 0x00, 0x12 };
-
-      EvidenceCreateSuite ECDSA_P256_WITH_SHA_256   = { 0x00, 0x21 };
-      EvidenceCreateSuite ECDSA_P384_WITH_SHA_384   = { 0x00, 0x22 };
-      EvidenceCreateSuite ECDSA_P521_WITH_SHA_512   = { 0x00, 0x23 };
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 20]
-
-Internet-Draft                                             November 2006
-
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN  55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 21]
diff --git a/doc/protocol/draft-housley-tls-authz-extns-00.txt b/doc/protocol/draft-housley-tls-authz-extns-00.txt
deleted file mode 100644
index 8d7deb4e77..0000000000
--- a/doc/protocol/draft-housley-tls-authz-extns-00.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-February 2006                                          RedPhone Security
-Expires: August 2006                                          R. Housley
-                                                          Vigil Security
-
-        Transport Layer Security (TLS) Authorization Extensions
-                 <draft-housley-tls-authz-extns-00.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies authorization extensions to the Transport
-   Layer Security (TLS) Handshake Protocol.  Extension types are carried
-   in the client and server hello messages to confirm that both parties
-   support the authorization messages.  The syntax and semantics of the
-   authorization messages are described in detail.
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                             February 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned when the original design criteria for
-   TLS were determined.  The extensions introduced in this document are
-   designed to enable TLS to operate in environments where authorization
-   information needs to be exchanged between the client and the server
-   before any protected data is exchanged.
-
-   This document describes authorization extensions for the TLS
-   Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
-   observe the conventions defined for TLS Extensions [TLSEXT] that make
-   use of the general extension mechanisms for the client hello message
-   and the server hello message.  The extensions described in this
-   document allow TLS clients to provide to the TLS server authorization
-   information, and allow TLS server to provide to the TLS client
-   authorization information about the TLS server.
-
-   The authorization extensions may be used in conjunction with TLS 1.0
-   and TLS 1.1.  The extensions are designed to be backwards compatible,
-   meaning that the Handshake Protocol messages associated with the
-   authorization extensions will only be exchanged if the client
-   indicates support for them in the client hello message and the server
-   indicates support for them in the server hello message.
-
-   Clients typically know the context of the TLS session that is being
-   setup, thus the client can request the use of the authorization
-   extensions when they are needed.  Servers must accept extended client
-   hello messages, even if the server does not "understand" the all of
-   the listed extensions.  However, the server will not indicate support
-   for these "not understood" extensions.  Then, clients may reject
-   communications with servers that do not support the authorization
-   extensions.
-
-1.1. Conventions
-
-   The syntax for the authorization messages is defined using the TLS
-   Presentation Language, which is specified in Section 4 of [TLS1.0].
-
-   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 [STDWORDS].
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                             February 2006
-
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the authorization messages in
-   the full TLS handshake.  In order to avoid unnecessary disclosure of
-   privilege information, the authorization messages appear after the
-   Finished message.  This placement ensures that they are encrypted and
-   integrity protected.
-
-      Client                                                 Server
-
-      ClientHello               -------->
-                                                        ServerHello
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                <--------           ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                  -------->
-      ClientAuthorizationData   -------->
-                                                 [ChangeCipherSpec]
-                                <--------                  Finished
-                                <--------   ServerAuthorizationData
-      Application Data          <------->          Application Data
-
-       *  Indicates optional or situation-dependent messages that
-          are not always sent.
-
-       [] Indicates that ChangeCipherSpec is an independent TLS
-          Protocol content type; it is not actually a TLS
-          handshake message.
-
-        Figure 1. Authorization data exchange in full TLS handshake
-
-   The ClientHello message includes an indication that the
-   ClientAuthorizationData message and ServerAuthorizationData message
-   are supported.  The ServerHello message also includes an indication
-   that the ClientAuthorizationData message and ServerAuthorizationData
-   message are supported.  Both the client and the server MUST indicate
-   support for the authorization messages, otherwise they MUST NOT be
-   included in the handshake.
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                             February 2006
-
-
-2. Authorization Extension Types
-
-   The general extension mechanisms enable clients and servers to
-   negotiate whether to use specific extensions, and how to use specific
-   extensions.  As specified in [TLSEXT], the extension format used in
-   the extended client hello message and extended server hello message
-   is:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the corresponding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   associated extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of two new extension types:
-   client_authz_request and server_authz_request.  These extension types
-   are described in Section 2.1 and Section 2.2, respectively.  This
-   specification adds two new types to ExtensionType:
-
-      enum {
-        client_authz_request(TBD), server_authz_request(TBD),
-        (65535)
-      } ExtensionType;
-
-   The authorization extensions are relevant when a session is initiated
-   and any subsequent session resumption.  However, a client that
-   requests resumption of a session does not know whether the server
-   will have all of the context necessary to accept this request, and
-   therefore the client SHOULD send an extended client hello message
-   that includes the extension types associated with the authorization
-   extensions.  This way, if the resumption request is denied, then the
-   authorization extensions will be negotiated as normal.
-
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                             February 2006
-
-
-2.1. The client_authz_request Extension Type
-
-   Clients MUST include the client_authz_request extension type in the
-   extended client hello message to indicate their desire to send
-   authorization data to the server.  The extension_data field indicates
-   the format of the authorization data that will be sent.  The format
-   is indicated with the AuthzDataFormat type defined in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   client_authz_request extension MUST respond with the same
-   client_authz_request extension in the extended server hello message
-   if the server is willing to receive authorization data in the
-   indicated format.  The client_authz_request extension MUST be omitted
-   from the extended server hello message if the server is not willing
-   to receive authorization data in the indicated format.
-
-2.2. The server_authz_request Extension Type
-
-   Clients MUST include the server_authz_request extension type in the
-   extended client hello message to indicate their desire to receive
-   authorization data from the server.  The extension_data field
-   indicates the format of the authorization data that is desired.  The
-   format is indicated with the AuthzDataFormat type defined in Section
-   2.3.
-
-   Servers that receive an extended client hello message containing the
-   server_authz_request extension MUST respond with the same
-   server_authz_request extension in the extended server hello message
-   if the server is willing to provide authorization data in the
-   requested format.  The server_authz_request extension MUST be omitted
-   from the extended server hello message if the server is not able to
-   provide authorization data in the requested format.
-
-2.3. AuthzDataFormat Type
-
-   The AuthzDataFormat type is used in both the client_authz_request and
-   the server_authz_request extensions.  It indicates the format of the
-   authorization data that will be transferred.  The AuthzDataFormat
-   type definition is:
-
-      enum{
-         x509_attr_cert(0), saml_assertion(1), (255)
-      } AuthzDataFormat;
-
-   When the x509_attr_cert value is present, the authorization data is
-   an X.509 Attribute Certificate that conforms to the profile in RFC
-   3281 [ATTRCERT].
-
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                             February 2006
-
-
-   When the saml_assertion value is present, the authorization data is
-   an assertion composed using the Security Assertion Markup Language
-   (SAML) [SAML].
-
-3. Handshake Messages
-
-   This document specifies the use of two new handshake messages: the
-   ClientAuthorizationData message and ServerAuthorizationData message.
-   These messages are described in Section 3.1 and Section 3.2,
-   respectively.  The updated handshake message structure becomes:
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), certificate_url(21), certificate_status(22),
-          client_authz_data(TBD), server_authz_data(TBD), (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* octets in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case certificate_url:     CertificateURL;
-              case certificate_status:  CertificateStatus;
-              case client_authz_data:   ClientAuthorizationData;
-              case server_authz_data:   ServerAuthorizationData;
-          } body;
-      } Handshake;
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                             February 2006
-
-
-3.1. ClientAuthorizationData Message
-
-   The ClientAuthorizationData message contains authorization data
-   associated with the TLS client.  The format of the authentication
-   data depends on the format negotiated in the client_authz_request
-   hello message extensions.
-
-      struct {
-         client_authz_data AuthorizationData;
-      } ClientAuthorizationData;
-
-   The AuthorizationData structure is described in Section 3.3.
-
-3.2. ServerAuthorizationData Message
-
-   The ServerAuthorizationData message contains authorization data
-   associated with the TLS server.  The format of the authorization data
-   depends on the format negotiated in the server_authz_request hello
-   message extensions.
-
-      struct {
-         server_authz_data AuthorizationData;
-      } ServerAuthorizationData;
-
-   The AuthorizationData structure is described in Section 3.3.
-
-3.3. AuthorizationData Type
-
-   The AuthorizationData structure is defined as follows.  For
-   readability, the definition of AuthzDataFormat is repeated from
-   section 2.3.
-
-   All of the entries in the authz_data_list MUST contain the same
-   authz_format value, and this value MUST match the one advertised by
-   the client in the extended hello message extension.
-
-      struct{
-         AuthorizationDataEntry authz_data_list<1..2^16-1>;
-      } AuthorizationData;
-
-      struct {
-         AuthzDataFormat authz_format;
-         select (authz_format) {
-            case x509_attr_cert: X509AttrCert;
-            case saml_assertion: SAMLAssertion;
-         } authz_data_entry;
-      } AuthorizationDataEntry;
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                             February 2006
-
-
-      enum{
-         x509_attr_cert(0), saml_assertion(1), (255)
-      } AuthzDataFormat;
-
-      opaque X509AttrCert<1..2^16-1>;
-
-      opaque SAMLAssertion<1..2^16-1>;
-
-   When X509AttrCert is used, the field contains an ASN.1 DER-encoded
-   X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
-   [ATTRCERT].  An AC is a structure similar to a public key certificate
-   (PKC); the main difference being that the AC contains no public key.
-   An AC may contain attributes that specify group membership, role,
-   security clearance, or other authorization information associated
-   with the AC holder.
-
-   When SAMLAssertion is used, the field contains XML constructs with a
-   nested structure defined in [SAML].  SAML is an XML-based framework
-   for exchanging security information.  This security information is
-   expressed in the form of assertions about subjects, where a subject
-   is either human or computer with an identity.  In this context, the
-   assertions are most likely to convey authorization decisions about
-   whether subjects are allowed to access certain resources.  Assertions
-   are issued by SAML authorities, namely, authentication authorities,
-   attribute authorities, and policy decision points.
-
-4. IANA Considerations
-
-   IANA needs to assign two TLS Extension Types: client_authz_request,
-   and server_authz_request.
-
-   IANA needs to assign two TLS Handshake Message Types:
-   client_authz_data, and server_authz_data.
-
-   IANA needs to establish a registry for TLS Authorization Data
-   Formats.  The first two entries in the registry are x509_attr_cert(0)
-   and saml_assertion(1).  TLS Authorization Data Format identifiers
-   with values in the inclusive range 0-63 (decimal) are assigned via
-   RFC 2434 [IANA] Standards Action.  Values from the inclusive range
-   64-223 (decimal) are assigned via RFC 2434 Specification Required.
-   Values from the inclusive range 224-255 (decimal) are reserved for
-   RFC 2434 Private Use.
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                             February 2006
-
-
-5. Security Considerations
-
-   A TLS server can support more than one application, and each
-   application may include several features, each of which requires
-   separate authorization checks.  This is the reason that more than one
-   piece of authorization information can be provided.
-
-   A TLS server that requires different authorization information for
-   different applications or different application features may find
-   that a client has provided sufficient authorization information to
-   grant access to a subset of these offerings.  In this situation the
-   TLS Handshake protocol will complete successfully; however, the
-   server must ensure that the client will only be able to use the
-   appropriate applications and application features.  That is, the TLS
-   server must deny access to the applications and application features
-   for which authorization has not been confirmed.
-
-6. Normative References
-
-   [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
-                Certificate Profile for Authorization", RFC 3281,
-                April 2002.
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 3546, June 2003.
-
-   [SAML]       Organization for the Advancement of Structured Information
-                Standards, "Security Assertion Markup Language (SAML),
-                version 1.1", September 2003.  [Version 2.0 is out for
-                public comment; it will replace this reference if approved.]
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                             February 2006
-
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN  55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 10]
diff --git a/doc/protocol/draft-housley-tls-authz-extns-01.txt b/doc/protocol/draft-housley-tls-authz-extns-01.txt
deleted file mode 100644
index 449a44c880..0000000000
--- a/doc/protocol/draft-housley-tls-authz-extns-01.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-March 2006                                             RedPhone Security
-Expires: September 2006                                       R. Housley
-                                                          Vigil Security
-
-        Transport Layer Security (TLS) Authorization Extensions
-                 <draft-housley-tls-authz-extns-01.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies authorization extensions to the Transport
-   Layer Security (TLS) Handshake Protocol.  Authorization information
-   is carried in the client and server hello messages.  The syntax and
-   semantics of the authorization messages are described in detail.
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                                March 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned when the original design criteria for
-   TLS were determined.  The authorization extensions introduced in this
-   document are designed to enable TLS to operate in environments where
-   authorization information needs to be exchanged between the client
-   and the server before any protected data is exchanged.
-
-   This document describes authorization extensions for the TLS
-   Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
-   observe the conventions defined for TLS Extensions [TLSEXT] that make
-   use of the general extension mechanisms for the client hello message
-   and the server hello message.  The extensions described in this
-   document allow TLS clients to provide to the TLS server authorization
-   information, and allow TLS server to provide to the TLS client
-   authorization information about the TLS server.
-
-   The authorization extensions are intended for use with both TLS 1.0
-   and TLS 1.1.  The extensions are designed to be backwards compatible,
-   meaning that the authorization information carried in the client
-   hello message and the server hello message can be ignored by any
-   implementation that does not support the included authorization
-   information format.
-
-   Clients typically know the context of the TLS session that is being
-   setup, thus the client can use of the authorization extensions when
-   needed.  Servers must accept extended client hello messages, even if
-   the server does not "understand" the all of the listed extensions.
-   However, the server will not make use of the authorization
-   information if the authorization extension is not supported or the
-   authorization information is provided in an unsupported format.
-
-1.1. Conventions
-
-   The syntax for the authorization messages is defined using the TLS
-   Presentation Language, which is specified in Section 4 of [TLS1.0].
-
-   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 [STDWORDS].
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                                March 2006
-
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the authorization messages in
-   the full TLS handshake.
-
-      Client                                                 Server
-
-      ClientHello
-      (with AuthorizationData)  -------->
-                                                        ServerHello
-                                           (with AuthorizationData)
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                <--------           ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                  -------->
-                                                 [ChangeCipherSpec]
-                                <--------                  Finished
-      Application Data          <------->          Application Data
-
-       *  Indicates optional or situation-dependent messages that
-          are not always sent.
-
-       [] Indicates that ChangeCipherSpec is an independent TLS
-          Protocol content type; it is not actually a TLS
-          Handshake Protocol message.
-
-    Figure 1. AuthorizationData carried in ClientHello and ServerHello
-
-   The ClientHello message includes the AuthorizationData extension,
-   which contains the authorization data for the client, and then the
-   ServerHello message includes the AuthorizationData extension, which
-   contains the authorization data for the server.  If the server does
-   not support the AuthorizationData extension, or the server does not
-   support the authorization information format used by the client, then
-   the server MUST NOT include the AuthorizationData extension in the
-   ServerHello message.  The Handshake Protocol continues, but without
-   the benefit of authorization information.
-
-2. AuthorizationData Extension
-
-   The general extension mechanisms enable clients and servers to
-   negotiate the use of specific extensions.  As specified in [TLSEXT],
-   the extension format used in the extended client hello message and
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                                March 2006
-
-
-   extended server hello message is:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the corresponding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   associated extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of one new extension type:
-   authz_data.
-
-   This specification adds one new type to ExtensionType:
-
-      enum {
-        authz_data(TBD), (65535)
-      } ExtensionType;
-
-   The authorization extension is relevant when a session is initiated,
-   regardless of the use of a full handshake or use of session
-   resumption.  Clients MUST explicitly present AuthorizationData in
-   every client hello message for which authorization information is
-   desired.  Upon receipt of a client hello message that requests
-   session resumption but which contains no acceptable
-   AuthorizationData, the TLS server MAY resume the session but it MUST
-   NOT grant authorization to the session being resumed based on any
-   prior session authorization.
-
-   These requirements allow a series of resumed sessions to have
-   different authorizations from one another.  More importantly, the
-   authorization information is always provided by the client in case
-   the server no longer honors the session resumption at the requested
-   authorization level.  Repeated inclusion of the authorization
-   information allows the Handshake Protocol to proceed the same way for
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                                March 2006
-
-
-   both resume and session origination.
-
-2.1. The authz_data Extension Type
-
-   Clients MUST include the authz_data extension type in the extended
-   client hello message to send authorization data to the server.  The
-   extension_data field contains the authorization data.  Section 2.2
-   specifies the authorization data formats that are supported.
-
-   Servers that receive an extended client hello message containing the
-   authz_data extension MUST respond with the authz_data extension in
-   the extended server hello message if the server is willing to make
-   use of the received authorization data in the provided format.  If
-   the server has any authorization information to send to the client,
-   then the server MUST include the information in the authz_data
-   extension type in the extended server hello message.
-
-   The AuthorizationData structure is described in Section 2.3.
-
-2.2. AuthzDataFormat Type
-
-   The AuthzDataFormat type is used in the authz_data extension.  It
-   indicates the format of the authorization information that will be
-   transferred.  The AuthzDataFormat type definition is:
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-   When the x509_attr_cert value is present, the authorization data is
-   an X.509 Attribute Certificate (AC) that conforms to the profile in
-   RFC 3281 [ATTRCERT].
-
-   When the saml_assertion value is present, the authorization data is
-   an assertion composed using the Security Assertion Markup Language
-   (SAML) [SAML].
-
-   When the x509_attr_cert_url value is present, the authorization data
-   is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT];
-   however, the AC is fetched with the supplied URL.  A one-way hash
-   value is provided to ensure that the intended AC is obtained.
-
-   When the saml_assertion_url value is present, the authorization data
-   is a SAML Assertion; however, the SAML Assertion is fetched with the
-   supplied URL.  A one-way hash value is provided to ensure that the
-   intended SAML Assertion is obtained.
-
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                                March 2006
-
-
-   Additional formats can be registered in the future using the
-   procedures in section 3.
-
-2.3. AuthorizationData Type
-
-   The AuthorizationData type is carried in the extension_data field for
-   the authz_data extension.  When it appears in the extended client
-   hello message, it carries authorization information for the TLS
-   client.  When it appears in the extended server hello message, it
-   carries authorization information for the TLS server.
-
-      struct {
-         AuthorizationDataEntry authz_data_list<1..2^16-1>;
-      } AuthorizationData;
-
-      struct {
-         AuthzDataFormat authz_format;
-         select (authz_format) {
-            case x509_attr_cert:     X509AttrCert;
-            case saml_assertion:     SAMLAssertion;
-            case x509_attr_cert_url: URLandHash;
-            case saml_assertion_url: URLandHash;
-         } authz_data_entry;
-      } AuthorizationDataEntry;
-
-      opaque X509AttrCert<1..2^16-1>;
-
-      opaque SAMLAssertion<1..2^16-1>;
-
-      struct {
-         opaque url<1..2^16-1>;
-         HashType hash_type;
-         select (hash_type) {
-            case sha1:   SHA1Hash;
-            case sha256: SHA256Hash;
-         } hash;
-      } URLandHash;
-
-      enum {
-         sha1(0), sha256(1), (255)
-      } HashType;
-
-      opaque SHA1Hash[20];
-
-      opaque SHA1Hash[32];
-
-   When X509AttrCert is used, the field contains an ASN.1 DER-encoded
-   X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                                March 2006
-
-
-   [ATTRCERT].  An AC is a structure similar to a public key certificate
-   (PKC); the main difference being that the AC contains no public key.
-   An AC may contain attributes that specify group membership, role,
-   security clearance, or other authorization information associated
-   with the AC holder.
-
-   When SAMLAssertion is used, the field contains XML constructs with a
-   nested structure defined in [SAML].  SAML is an XML-based framework
-   for exchanging security information.  This security information is
-   expressed in the form of assertions about subjects, where a subject
-   is either human or computer with an identity.  In this context, the
-   assertions are most likely to convey authorization decisions about
-   whether subjects are allowed to access certain resources.  Assertions
-   are issued by SAML authorities, namely, authentication authorities,
-   attribute authorities, and policy decision points.
-
-   Since X509AttrCert and SAMLAssertion can lead to a significant
-   increase in the size of the hello messages, alternatives provide a
-   URL to obtain the ASN.1 DER-encoded X.509 AC or SAML Assertion.  To
-   ensure that the intended object is obtained, a one-way hash value of
-   the object is also included.  Integrity of this one-way hash value is
-   provided by the TLS Finished message.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support URLs that employ the http scheme.
-   Other schemes may also be supported; however, to avoid circular
-   dependencies, supported schemes SHOULD NOT themselves make use of
-   TLS, such as the https scheme.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
-   as one-way hash functions.  Other one-way hash functions may also be
-   supported.  Additional one-way hash functions can be registered in
-   the future using the procedures in section 3.
-
-3. IANA Considerations
-
-   IANA has assigned one TLS Extension Types: authz_data(TBD).
-
-   IANA has established a registry for TLS Authorization Data Formats.
-   The first two entries in the registry are x509_attr_cert(0) and
-   saml_assertion(1).  TLS Authorization Data Format identifiers with
-   values in the inclusive range 0-63 (decimal) are assigned via RFC
-   2434 [IANA] Standards Action.  Values from the inclusive range 64-223
-   (decimal) are assigned via RFC 2434 Specification Required.  Values
-   from the inclusive range 224-255 (decimal) are reserved for RFC 2434
-   Private Use.
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                                March 2006
-
-
-   IANA has established a registry for TLS Hash Types.  The first two
-   entries in the registry are sha1(0) and sha256(1).  TLS Hash Type
-   identifiers with values in the inclusive range 0-158 (decimal) are
-   assigned via RFC 2434 [IANA] Standards Action.  Values from the
-   inclusive range 159-223 (decimal) are assigned via RFC 2434
-   Specification Required.  Values from the inclusive range 224-255
-   (decimal) are reserved for RFC 2434 Private Use.
-
-4. Security Considerations
-
-   A TLS server can support more than one application, and each
-   application may include several features, each of which requires
-   separate authorization checks.  This is the reason that more than one
-   piece of authorization information can be provided.
-
-   A TLS server that requires different authorization information for
-   different applications or different application features may find
-   that a client has provided sufficient authorization information to
-   grant access to a subset of these offerings.  In this situation the
-   TLS Handshake Protocol will complete successfully; however, the
-   server must ensure that the client will only be able to use the
-   appropriate applications and application features.  That is, the TLS
-   server must deny access to the applications and application features
-   for which authorization has not been confirmed.
-
-   In many cases, the authorization information is itself sensitive.
-   The double handshake technique can be used to provide protection for
-   the authorization information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   authorization information, but it does result in protected
-   communications.  Then, a second handshake that includes the
-   authorization information is performed using the protected
-   communications.  In Figure 2, the number on the right side indicates
-   the amount of protection for the TLS message on that line.  A zero
-   (0) indicates that there is no communication protection; a one (1)
-   indicates that protection is provided by the first TLS session; and a
-   two (2) indicates that protection is provided by both TLS sessions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                                March 2006
-
-
-      Client                                                 Server
-
-      ClientHello                                                    |0
-      (no AuthorizationData)    -------->                            |0
-                                                        ServerHello  |0
-                                             (no AuthorizationData)  |0
-                                                       Certificate*  |0
-                                                 ServerKeyExchange*  |0
-                                                CertificateRequest*  |0
-                                <--------           ServerHelloDone  |0
-      Certificate*                                                   |0
-      ClientKeyExchange                                              |0
-      CertificateVerify*                                             |0
-      [ChangeCipherSpec]                                             |0
-      Finished                  -------->                            |1
-                                                 [ChangeCipherSpec]  |0
-                                <--------                  Finished  |1
-      ClientHello                                                    |1
-      (with AuthorizationData)  -------->                            |1
-                                                        ServerHello  |1
-                                           (with AuthorizationData)  |1
-                                                       Certificate*  |1
-                                                 ServerKeyExchange*  |1
-                                                CertificateRequest*  |1
-                                <--------           ServerHelloDone  |1
-      Certificate*                                                   |1
-      ClientKeyExchange                                              |1
-      CertificateVerify*                                             |1
-      [ChangeCipherSpec]                                             |1
-      Finished                  -------->                            |2
-                                                 [ChangeCipherSpec]  |1
-                                <--------                  Finished  |2
-      Application Data          <------->          Application Data  |2
-
-     Figure 2. Protection of Authorization Data (Two Full Handshakes)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                                March 2006
-
-
-   Public key operations can be minimized by making the second handshake
-   a resumption.  This is much more efficient in term of computation and
-   message exchanges.  Figure 3 illustrates this more efficient double
-   handshake.
-
-
-      Client                                                 Server
-
-      ClientHello                                                    |0
-      (no AuthorizationData)    -------->                            |0
-                                                        ServerHello  |0
-                                             (no AuthorizationData)  |0
-                                                       Certificate*  |0
-                                                 ServerKeyExchange*  |0
-                                                CertificateRequest*  |0
-                                <--------           ServerHelloDone  |0
-      Certificate*                                                   |0
-      ClientKeyExchange                                              |0
-      CertificateVerify*                                             |0
-      [ChangeCipherSpec]                                             |0
-      Finished                  -------->                            |1
-                                                 [ChangeCipherSpec]  |0
-                                <--------                  Finished  |1
-      ClientHello                                                    |1
-      (with AuthorizationData)  -------->                            |1
-                                                        ServerHello  |1
-                                           (with AuthorizationData)  |1
-                                                 [ChangeCipherSpec]  |1
-                                <--------                  Finished  |2
-      [ChangeCipherSpec]                                             |1
-      Finished                  -------->                            |2
-      Application Data          <------->          Application Data  |2
-
-          Figure 3. Protection of Authorization Data (Resumption)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 10]
-
-Internet-Draft                                                March 2006
-
-
-5. Normative References
-
-   [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
-                Certificate Profile for Authorization", RFC 3281,
-                April 2002.
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 3546, June 2003.
-
-   [SAML]       Organization for the Advancement of Structured Information
-                Standards, "Security Assertion Markup Language (SAML),
-                version 1.1", September 2003.  [Version 2.0 is out for
-                public comment; it will replace this reference if approved.]
-
-   [SHA1]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.
-
-   [SHA2]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 11]
-
-Internet-Draft                                                March 2006
-
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN 55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 12]
diff --git a/doc/protocol/draft-housley-tls-authz-extns-03.txt b/doc/protocol/draft-housley-tls-authz-extns-03.txt
deleted file mode 100644
index b413dfadc1..0000000000
--- a/doc/protocol/draft-housley-tls-authz-extns-03.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-April 2006                                             RedPhone Security
-Expires: October 2006                                         R. Housley
-                                                          Vigil Security
-
-        Transport Layer Security (TLS) Authorization Extensions
-                 <draft-housley-tls-authz-extns-03.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies authorization extensions to the Transport
-   Layer Security (TLS) Handshake Protocol.  Extensions carried in the
-   client and server hello messages to confirm that both parties support
-   the desired authorization data types.  Then, if supported by both the
-   client and the server, authorization information is exchanged in the
-   supplemental data handshake message.
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                                April 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned at the time of the original design for
-   TLS.  The extensions introduced in this document are designed to
-   enable TLS to operate in environments where authorization information
-   needs to be exchanged between the client and the server before any
-   protected data is exchanged.
-
-   This document describes authorization extensions for the TLS
-   Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
-   observe the conventions defined for TLS Extensions [TLSEXT] that make
-   use of the general extension mechanisms for the client hello message
-   and the server hello message.  The extensions described in this
-   document confirm that both the client and the server support the
-   desired authorization data types.  Then, if supported, authorization
-   information is exchanged in the supplemental data handshake message
-   [TLSSUPP].
-
-   The authorization extensions may be used in conjunction with TLS 1.0
-   and TLS 1.1.  The extensions are designed to be backwards compatible,
-   meaning that the Handshake Protocol Supplemental Data messages will
-   only contain authorization information of a particular type if the
-   client indicates support for them in the client hello message and the
-   server indicates support for them in the server hello message.
-
-   Clients typically know the context of the TLS session that is being
-   setup, thus the client can use the authorization extensions when they
-   are needed.  Servers must accept extended client hello messages, even
-   if the server does not "understand" the all of the listed extensions.
-   However, the server will not indicate support for these "not
-   understood" extensions.  Then, clients may reject communications with
-   servers that do not support the authorization extensions.
-
-1.1. Conventions
-
-   The syntax for the authorization messages is defined using the TLS
-   Presentation Language, which is specified in Section 4 of [TLS1.0].
-
-   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 [STDWORDS].
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the authorization extensions
-   and supplemental data messages in the full TLS handshake.
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                                April 2006
-
-
-    Client                                                   Server
-
-    ClientHello (w/ extensions) -------->
-
-                                        ServerHello (w/ extensions)
-                                                  SupplementalData*
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                <--------           ServerHelloDone
-    SupplementalData*
-    Certificate*
-    ClientKeyExchange
-    CertificateVerify*
-    [ChangeCipherSpec]
-    Finished                    -------->
-                                                 [ChangeCipherSpec]
-                                <--------                  Finished
-    Application Data            <------->          Application Data
-
-     *  Indicates optional or situation-dependent messages that
-        are not always sent.
-
-     [] Indicates that ChangeCipherSpec is an independent TLS
-        Protocol content type; it is not actually a TLS
-        handshake message.
-
-        Figure 1. Authorization data exchange in full TLS handshake
-
-
-   The ClientHello message includes an indication of the client
-   authorization data formats that are supported and an indication of
-   the server authorization data formats that are supported.  The
-   ServerHello message contains similar indications, but any
-   authentication data formats that are not supported by the server are
-   not included.  Both the client and the server MUST indicate support
-   for the authorization data types.  If the list of mutually supported
-   authorization data formats is empty, then the ServerHello message
-   MUST NOT carry the affected extension at all.
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                                April 2006
-
-
-2. Authorization Extension Types
-
-   The general extension mechanisms enable clients and servers to
-   negotiate whether to use specific extensions, and how to use specific
-   extensions.  As specified in [TLSEXT], the extension format used in
-   the extended client hello message and extended server hello message
-   is repeated here for convenience:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the corresponding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   associated extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of two new extension types:
-   client_authz and server_authz.  These extension types are described
-   in Section 2.1 and Section 2.2, respectively.  This specification
-   adds two new types to ExtensionType:
-
-      enum {
-        client_authz(TBD), server_authz(TBD), (65535)
-      } ExtensionType;
-
-   The authorization extensions are relevant when a session is initiated
-   and any subsequent session resumption.  However, a client that
-   requests resumption of a session does not know whether the server
-   will have all of the context necessary to accept this request, and
-   therefore the client SHOULD send an extended client hello message
-   that includes the extension types associated with the authorization
-   extensions.  This way, if the resumption request is denied, then the
-   authorization extensions will be negotiated as normal.
-
-
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                                April 2006
-
-
-2.1. The client_authz Extension Type
-
-   Clients MUST include the client_authz extension type in the extended
-   client hello message to indicate their desire to send authorization
-   data to the server.  The extension_data field indicates the format of
-   the authorization data that will be sent in the supplemental data
-   handshake message.  The syntax of the client_authz extension_data
-   field is described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   client_authz extension MUST respond with the same client_authz
-   extension in the extended server hello message if the server is
-   willing to receive authorization data in the indicated format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The client_authz extension MUST be omitted from the extended
-   server hello message if the server is not willing to receive
-   authorization data in any of the indicated formats.
-
-2.2. The server_authz Extension Type
-
-   Clients MUST include the server_authz extension type in the extended
-   client hello message to indicate their desire to receive
-   authorization data from the server.  The extension_data field
-   indicates the format of the authorization data that will be sent in
-   the supplemental data handshake message.  The syntax of the
-   server_authz extension_data field as described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   server_authz extension MUST respond with the same server_authz
-   extension in the extended server hello message if the server is
-   willing to provide authorization data in the requested format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The server_authz extension MUST be omitted from the extended
-   server hello message if the server is not able to provide
-   authorization data in any of the indicated formats.
-
-2.3. AuthzDataFormat Type
-
-   The AuthzDataFormat type is used in both the client_authz and the
-   server_authz extensions.  It indicates the format of the
-   authorization data that will be transferred.  The AuthzDataFormat
-   type definition is:
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                                April 2006
-
-
-   When the x509_attr_cert value is present, the authorization data is
-   an X.509 Attribute Certificate (AC) that conforms to the profile in
-   RFC 3281 [ATTRCERT].
-
-   When the saml_assertion value is present, the authorization data is
-   an assertion composed using the Security Assertion Markup Language
-   (SAML) [SAML1.1][SAML2.0].
-
-   When the x509_attr_cert_url value is present, the authorization data
-   is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT];
-   however, the AC is fetched with the supplied URL.  A one-way hash
-   value is provided to ensure that the intended AC is obtained.
-
-   When the saml_assertion_url value is present, the authorization data
-   is a SAML Assertion; however, the SAML Assertion is fetched with the
-   supplied URL.  A one-way hash value is provided to ensure that the
-   intended SAML Assertion is obtained.
-
-3. Supplemental Data Handshake Message Usage
-
-   As shown in Figure 1, supplemental data can be exchanges in two
-   places in the handshake protocol.  The client_authz extension
-   determines what authorization data formats are acceptable for
-   transfer from the client to the server, and the server_authz
-   extension determines what authorization data formats are acceptable
-   for transfer from the server to the client.  In both cases, the
-   syntax specified in [TLSSUPP] is used along with the authz_data type
-   defined in this document.
-
-      enum {
-         authz_data(TBD), (65535)
-      } SupplementalDataType;
-
-      struct {
-         SupplementalDataType supplemental_data_type;
-         select(SupplementalDataType) {
-            case authz_data:  AuthorizationData;
-         }
-      } SupplementalData;
-
-3.1. Client Authorization Data
-
-   The SupplementalData message sent from the client to the server
-   contains authorization data associated with the TLS client.
-   Following the principle of least privilege, the client ought to send
-   the minimal set of authorization information necessary to accomplish
-   the task at hand.  That is, only those authorizations that are
-   expected to be required by the server in order to gain access to the
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                                April 2006
-
-
-   needed server resources ought to be included.  The format of the
-   authentication data depends on the format negotiated in the
-   client_authz hello message extension.  The AuthorizationData
-   structure is described in Section 3.3.
-
-   In some systems, clients present authorization information to the
-   server, and then the server provides new authorization information.
-   This type of transaction is not supported by SupplementalData
-   messages.  In cases where the client intends to request the TLS
-   server to perform authorization translation or expansion services,
-   such translation services ought to occur within the ApplicationData
-   messages, not within the TLS Handshake protocol.
-
-3.2. Server Authorization Data
-
-   The SupplementalData message sent from the server to the client
-   contains authorization data associated with the TLS server.  This
-   authorization information is expected to include statements about the
-   server's qualifications, reputation, accreditation, and so on.
-   Wherever possible, authorizations that can be misappropriated for
-   fraudulent use ought to be avoided.  The format of the authorization
-   data depends on the format negotiated in the server_authz hello
-   message extensions.  The AuthorizationData structure is described in
-   Section 3.3.
-
-3.3. AuthorizationData Type
-
-   The AuthorizationData structure carried authorization information for
-   either the client or the server.  The AuthzDataFormat specified in
-   Section 2.3 for use in the hello extensions is also used in this
-   structure.
-
-   All of the entries in the authz_data_list MUST employ authorization
-   data formats that were negotiated in the relevant hello message
-   extension.
-
-      struct{
-         AuthorizationDataEntry authz_data_list<1..2^16-1>;
-      } AuthorizationData;
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                                April 2006
-
-
-      struct {
-         AuthzDataFormat authz_format;
-         select (AuthzDataFormat) {
-            case x509_attr_cert:     X509AttrCert;
-            case saml_assertion:     SAMLAssertion;
-            case x509_attr_cert_url: URLandHash;
-            case saml_assertion_url: URLandHash;
-         }
-      } AuthorizationDataEntry;
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-      opaque X509AttrCert<1..2^16-1>;
-
-      opaque SAMLAssertion<1..2^16-1>;
-
-      struct {
-         opaque url<1..2^16-1>;
-         HashType hash_type;
-         select (hash_type) {
-            case sha1:   SHA1Hash;
-            case sha256: SHA256Hash;
-         } hash;
-      } URLandHash;
-
-      enum {
-         sha1(0), sha256(1), (255)
-      } HashType;
-
-      opaque SHA1Hash[20];
-
-      opaque SHA256Hash[32];
-
-3.3.1. X.509 Attribute Certificate
-
-   When X509AttrCert is used, the field contains an ASN.1 DER-encoded
-   X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
-   [ATTRCERT].  An AC is a structure similar to a public key certificate
-   (PKC) [PKIX1]; the main difference being that the AC contains no
-   public key.  An AC may contain attributes that specify group
-   membership, role, security clearance, or other authorization
-   information associated with the AC holder.
-
-   When making an authorization decision based on an AC, proper linkage
-   between the AC holder and the public key certificate that is
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                                April 2006
-
-
-   transferred in the TLS Certificate message is needed.  The AC holder
-   field provides this linkage.  The holder field is a SEQUENCE allowing
-   three different (optional) syntaxes: baseCertificateID, entityName
-   and objectDigestInfo.  In the TLS authorization context, the holder
-   field MUST use the either baseCertificateID or entityName.  In the
-   baseCertificateID case, the baseCertificateID field MUST match the
-   issuer and serialNumber fields in the certificate.  In the entityName
-   case, the entityName MUST be the same as the subject field in the
-   certificate or one of the subjectAltName extension values in the
-   certificate.  Note that [PKIX1] mandates that the subjectAltName
-   extension be present if the subject field contains an empty
-   distinguished name.
-
-3.3.2. SAML Assertion
-
-   When SAMLAssertion is used, the field contains XML constructs with a
-   nested structure defined in [SAML1.1][SAML2.0].  SAML is an XML-based
-   framework for exchanging security information.  This security
-   information is expressed in the form of assertions about subjects,
-   where a subject is either human or computer with an identity.  In
-   this context, the SAML assertions are most likely to convey
-   authentication or attribute statements to be used as input to
-   authorization policy governing whether subjects are allowed to access
-   certain resources.  Assertions are issued by SAML authorities.
-
-   When making an authorization decision based on a SAML assertion,
-   proper linkage between the SAML assertion and the public key
-   certificate that is transferred in the TLS Certificate message may be
-   needed.  A "Holder of Key" subject confirmation method in the SAML
-   assertion can provide this linkage.  In other scenarios, it may be
-   acceptable to use alternate confirmation methods that do not provide
-   a strong binding, such as a bearer mechanism.  SAML assertion
-   recipients MUST decide which subject confirmation methods are
-   acceptable; such decisions MAY be specific to the SAML assertion
-   contents and the TLS session context.
-
-   There is no general requirement that the subject of the SAML
-   assertion correspond directly to the subject of the certificate.
-   They may represent the same or different entities.  When they are
-   different, SAML also provides a mechanism by which the certificate
-   subject can be identified separately from the subject in the SAML
-   assertion subject confirmation method.
-
-   Since the SAML assertion is being provided at a part of the TLS
-   Handshake that is unencrypted, an eavesdropper could replay the same
-   SAML assertion when they establish their own TLS session.  This is
-   especially important when a bearer mechanism is employed, the
-   recipient of the SAML assertion assumes that the sender is an
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                                April 2006
-
-
-   acceptable attesting entity for the SAML assertion.  Some constraints
-   may be included to limit the context where the bearer mechanism will
-   be accepted.  For example, the period of time that the SAML assertion
-   can be short-lived (often minutes), the source address can be
-   constrained, or the destination endpoint can be identified.  Also,
-   bearer assertions are often checked against a cache of SAML assertion
-   unique identifiers that were recently received in order to detect
-   replay.  This is an appropriate countermeasure if the bearer
-   assertion is intended to be used just once.  Section 5 provides a way
-   to protect authorization information when necessary.
-
-3.3.3. URL and Hash
-
-   Since the X.509 AC and SAML assertion can be large, alternatives
-   provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML
-   Assertion.  To ensure that the intended object is obtained, a one-way
-   hash value of the object is also included.  Integrity of this one-way
-   hash value is provided by the TLS Finished message.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support URLs that employ the http scheme.
-   Other schemes may also be supported; however, to avoid circular
-   dependencies, supported schemes SHOULD NOT themselves make use of
-   TLS, such as the https scheme.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
-   as one-way hash functions.  Other one-way hash functions may also be
-   supported.  Additional one-way hash functions can be registered in
-   the future using the procedures in section 3.
-
-4. IANA Considerations
-
-   This document defines a two TLS extensions: client_authz(TBD) and
-   server_authz(TBD).  These extension type values are assigned from the
-   TLS Extension Type registry defined in [TLSEXT].
-
-   This document defines one TLS supplemental data type:
-   authz_data(TBD).  This supplemental data type is assigned from the
-   TLS Supplemental Data Type registry defined in [TLSSUPP].
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Authorization Data Formats.  The first four entries in the
-   registry are x509_attr_cert(0), saml_assertion(1),
-   x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
-   Data Format identifiers with values in the inclusive range 0-63
-   (decimal) are assigned via RFC 2434 [IANA] Standards Action.  Values
-   from the inclusive range 64-223 (decimal) are assigned via RFC 2434
-
-
-
-Brown & Housley                                                [Page 10]
-
-Internet-Draft                                                April 2006
-
-
-   Specification Required.  Values from the inclusive range 224-255
-   (decimal) are reserved for RFC 2434 Private Use.
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Hash Types.  The first two entries in the registry are
-   sha1(0) and sha256(1).  TLS Hash Type identifiers with values in the
-   inclusive range 0-158 (decimal) are assigned via RFC 2434 [IANA]
-   Standards Action.  Values from the inclusive range 159-223 (decimal)
-   are assigned via RFC 2434 Specification Required.  Values from the
-   inclusive range 224-255 (decimal) are reserved for RFC 2434 Private
-   Use.
-
-5. Security Considerations
-
-   A TLS server can support more than one application, and each
-   application may include several features, each of which requires
-   separate authorization checks.  This is the reason that more than one
-   piece of authorization information can be provided.
-
-   A TLS server that requires different authorization information for
-   different applications or different application features may find
-   that a client has provided sufficient authorization information to
-   grant access to a subset of these offerings.  In this situation the
-   TLS Handshake protocol will complete successfully; however, the
-   server must ensure that the client will only be able to use the
-   appropriate applications and application features.  That is, the TLS
-   server must deny access to the applications and application features
-   for which authorization has not been confirmed.
-
-   In many cases, the authorization information is itself sensitive.
-   The double handshake technique can be used to provide protection for
-   the authorization information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   authorization extensions, but it does result in protected
-   communications.  Then, a second handshake that includes the
-   authorization information is performed using the protected
-   communications.  In Figure 2, the number on the right side indicates
-   the amount of protection for the TLS message on that line.  A zero
-   (0) indicates that there is no communication protection; a one (1)
-   indicates that protection is provided by the first TLS session; and a
-   two (2) indicates that protection is provided by both TLS sessions.
-
-   The placement of the SupplementalData message in the TLS Handshake
-   results in the server providing its authorization information before
-   the client is authenticated.  In many situations, servers will not
-   want to provide authorization information until the client is
-   authenticated.  The double handshake illustrated in Figure 2 provides
-   a technique to ensure that the parties are mutually authenticated
-
-
-
-Brown & Housley                                                [Page 11]
-
-Internet-Draft                                                April 2006
-
-
-   before either party provides authorization information.
-
-6. Acknowledgement
-
-   The authors thank Scott Cantor for his assistance with the SAML
-   Assertion portion of the document.
-
-
-
-    Client                                                   Server
-
-    ClientHello (no extensions) -------->                            |0
-                                        ServerHello (no extensions)  |0
-                                                       Certificate*  |0
-                                                 ServerKeyExchange*  |0
-                                                CertificateRequest*  |0
-                                <--------           ServerHelloDone  |0
-    Certificate*                                                     |0
-    ClientKeyExchange                                                |0
-    CertificateVerify*                                               |0
-    [ChangeCipherSpec]                                               |0
-    Finished                    -------->                            |1
-                                                 [ChangeCipherSpec]  |0
-                                <--------                  Finished  |1
-    ClientHello (w/ extensions) -------->                            |1
-                                        ServerHello (w/ extensions)  |1
-                                  SupplementalData (w/ authz data)*  |1
-                                                       Certificate*  |1
-                                                 ServerKeyExchange*  |1
-                                                CertificateRequest*  |1
-                                <--------           ServerHelloDone  |1
-    SupplementalData (w/ authz data)*                                |1
-    Certificate*                                                     |1
-    ClientKeyExchange                                                |1
-    CertificateVerify*                                               |1
-    [ChangeCipherSpec]                                               |1
-    Finished                    -------->                            |2
-                                                 [ChangeCipherSpec]  |1
-                                <--------                  Finished  |2
-    Application Data            <------->          Application Data  |2
-
-         Figure 2. Double Handshake to Protect Authorization Data
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 12]
-
-Internet-Draft                                                April 2006
-
-
-7. Normative References
-
-   [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
-                Certificate Profile for Authorization", RFC 3281,
-                April 2002.
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-   [PKIX1]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                X.509 Public Key Infrastructure Certificate and
-                Certificate Revocation List (CRL) Profile", RFC 3280,
-                April 2002.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 3546, June 2003.
-
-   [TLSSUPP]    Santesson, S., " TLS Handshake Message for Supplemental
-                Data", work in progress: draft-santesson-tls-supp,
-                March 2006.
-
-   [SAML1.1]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 1.1
-                Specification Set", September 2003.
-
-   [SAML2.0]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 2.0
-                Specification Set", March2005.
-
-   [SHA1]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.
-
-   [SHA2]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-Brown & Housley                                                [Page 13]
-
-Internet-Draft                                                April 2006
-
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN  55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-
-
-
-Brown & Housley                                                [Page 14]
-
-Internet-Draft                                                April 2006
-
-
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 15]
diff --git a/doc/protocol/draft-housley-tls-authz-extns-04.txt b/doc/protocol/draft-housley-tls-authz-extns-04.txt
deleted file mode 100644
index d4b4e15d4d..0000000000
--- a/doc/protocol/draft-housley-tls-authz-extns-04.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-April 2006                                             RedPhone Security
-Expires: October 2006                                         R. Housley
-                                                          Vigil Security
-
-        Transport Layer Security (TLS) Authorization Extensions
-                 <draft-housley-tls-authz-extns-04.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies authorization extensions to the Transport
-   Layer Security (TLS) Handshake Protocol.  Extensions carried in the
-   client and server hello messages to confirm that both parties support
-   the desired authorization data types.  Then, if supported by both the
-   client and the server, authorization information is exchanged in the
-   supplemental data handshake message.
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                                April 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned at the time of the original design for
-   TLS.  The extensions introduced in this document are designed to
-   enable TLS to operate in environments where authorization information
-   needs to be exchanged between the client and the server before any
-   protected data is exchanged.
-
-   The use of these TLS authorization extensions is especially
-   attractive when more than one application protocol can make use of
-   the same authorization information.  Straightforward binding of
-   identification, authentication, and authorization information is
-   possible when all of these are handled within TLS.  If each
-   application requires unique authorization information, then it might
-   best be carried within the TLS-protected application protocol.
-   However, care must be taken to ensure appropriate bindings when
-   identification, authentication, and authorization information are
-   handled at different protocol layers.
-
-   This document describes authorization extensions for the TLS
-   Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
-   observe the conventions defined for TLS Extensions [TLSEXT] that make
-   use of the general extension mechanisms for the client hello message
-   and the server hello message.  The extensions described in this
-   document confirm that both the client and the server support the
-   desired authorization data types.  Then, if supported, authorization
-   information is exchanged in the supplemental data handshake message
-   [TLSSUPP].
-
-   The authorization extensions may be used in conjunction with TLS 1.0
-   and TLS 1.1.  The extensions are designed to be backwards compatible,
-   meaning that the Handshake Protocol Supplemental Data messages will
-   only contain authorization information of a particular type if the
-   client indicates support for them in the client hello message and the
-   server indicates support for them in the server hello message.
-
-   Clients typically know the context of the TLS session that is being
-   setup, thus the client can use the authorization extensions when they
-   are needed.  Servers must accept extended client hello messages, even
-   if the server does not "understand" the all of the listed extensions.
-   However, the server will not indicate support for these "not
-   understood" extensions.  Then, clients may reject communications with
-   servers that do not support the authorization extensions.
-
-
-
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                                April 2006
-
-
-1.1. Conventions
-
-   The syntax for the authorization messages is defined using the TLS
-   Presentation Language, which is specified in Section 4 of [TLS1.0].
-
-   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 [STDWORDS].
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the authorization extensions
-   and supplemental data messages in the full TLS handshake.
-
-    Client                                                   Server
-
-    ClientHello (w/ extensions) -------->
-
-                                        ServerHello (w/ extensions)
-                                                  SupplementalData*
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                <--------           ServerHelloDone
-    SupplementalData*
-    Certificate*
-    ClientKeyExchange
-    CertificateVerify*
-    [ChangeCipherSpec]
-    Finished                    -------->
-                                                 [ChangeCipherSpec]
-                                <--------                  Finished
-    Application Data            <------->          Application Data
-
-     *  Indicates optional or situation-dependent messages that
-        are not always sent.
-
-     [] Indicates that ChangeCipherSpec is an independent TLS
-        Protocol content type; it is not actually a TLS
-        handshake message.
-
-        Figure 1. Authorization data exchange in full TLS handshake
-
-
-   The ClientHello message includes an indication of the client
-   authorization data formats that are supported and an indication of
-   the server authorization data formats that are supported.  The
-   ServerHello message contains similar indications, but any
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                                April 2006
-
-
-   authorization data formats that are not supported by the server are
-   not included.  Both the client and the server MUST indicate support
-   for the authorization data types.  If the list of mutually supported
-   authorization data formats is empty, then the ServerHello message
-   MUST NOT carry the affected extension at all.
-
-2. Authorization Extension Types
-
-   The general extension mechanisms enable clients and servers to
-   negotiate whether to use specific extensions, and how to use specific
-   extensions.  As specified in [TLSEXT], the extension format used in
-   the extended client hello message and extended server hello message
-   is repeated here for convenience:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the corresponding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   associated extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of two new extension types:
-   client_authz and server_authz.  These extension types are described
-   in Section 2.1 and Section 2.2, respectively.  This specification
-   adds two new types to ExtensionType:
-
-      enum {
-        client_authz(TBD), server_authz(TBD), (65535)
-      } ExtensionType;
-
-   The authorization extensions are relevant when a session is initiated
-   and any subsequent session resumption.  However, a client that
-   requests resumption of a session does not know whether the server
-   will have all of the context necessary to accept this request, and
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                                April 2006
-
-
-   therefore the client SHOULD send an extended client hello message
-   that includes the extension types associated with the authorization
-   extensions.  This way, if the resumption request is denied, then the
-   authorization extensions will be negotiated as normal.
-
-2.1. The client_authz Extension Type
-
-   Clients MUST include the client_authz extension type in the extended
-   client hello message to indicate their desire to send authorization
-   data to the server.  The extension_data field indicates the format of
-   the authorization data that will be sent in the supplemental data
-   handshake message.  The syntax of the client_authz extension_data
-   field is described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   client_authz extension MUST respond with the same client_authz
-   extension in the extended server hello message if the server is
-   willing to receive authorization data in the indicated format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The client_authz extension MUST be omitted from the extended
-   server hello message if the server is not willing to receive
-   authorization data in any of the indicated formats.
-
-2.2. The server_authz Extension Type
-
-   Clients MUST include the server_authz extension type in the extended
-   client hello message to indicate their desire to receive
-   authorization data from the server.  The extension_data field
-   indicates the format of the authorization data that will be sent in
-   the supplemental data handshake message.  The syntax of the
-   server_authz extension_data field as described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   server_authz extension MUST respond with the same server_authz
-   extension in the extended server hello message if the server is
-   willing to provide authorization data in the requested format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The server_authz extension MUST be omitted from the extended
-   server hello message if the server is not able to provide
-   authorization data in any of the indicated formats.
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                                April 2006
-
-
-2.3. AuthzDataFormat Type
-
-   The AuthzDataFormat type is used in both the client_authz and the
-   server_authz extensions.  It indicates the format of the
-   authorization data that will be transferred.  The
-   AuthorizationDataFormats type definition is:
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-      AuthorizationDataFormats authz_format_list<1..2^8-1>;
-
-   When the x509_attr_cert value is present, the authorization data is
-   an X.509 Attribute Certificate (AC) that conforms to the profile in
-   RFC 3281 [ATTRCERT].
-
-   When the saml_assertion value is present, the authorization data is
-   an assertion composed using the Security Assertion Markup Language
-   (SAML) [SAML1.1][SAML2.0].
-
-   When the x509_attr_cert_url value is present, the authorization data
-   is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT];
-   however, the AC is fetched with the supplied URL.  A one-way hash
-   value is provided to ensure that the intended AC is obtained.
-
-   When the saml_assertion_url value is present, the authorization data
-   is a SAML Assertion; however, the SAML Assertion is fetched with the
-   supplied URL.  A one-way hash value is provided to ensure that the
-   intended SAML Assertion is obtained.
-
-3. Supplemental Data Handshake Message Usage
-
-   As shown in Figure 1, supplemental data can be exchanges in two
-   places in the handshake protocol.  The client_authz extension
-   determines what authorization data formats are acceptable for
-   transfer from the client to the server, and the server_authz
-   extension determines what authorization data formats are acceptable
-   for transfer from the server to the client.  In both cases, the
-   syntax specified in [TLSSUPP] is used along with the authz_data type
-   defined in this document.
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                                April 2006
-
-
-      enum {
-         authz_data(TBD), (65535)
-      } SupplementalDataType;
-
-      struct {
-         SupplementalDataType supplemental_data_type;
-         select(SupplementalDataType) {
-            case authz_data:  AuthorizationData;
-         }
-      } SupplementalData;
-
-3.1. Client Authorization Data
-
-   The SupplementalData message sent from the client to the server
-   contains authorization data associated with the TLS client.
-   Following the principle of least privilege, the client ought to send
-   the minimal set of authorization information necessary to accomplish
-   the task at hand.  That is, only those authorizations that are
-   expected to be required by the server in order to gain access to the
-   needed server resources ought to be included.  The format of the
-   authorization data depends on the format negotiated in the
-   client_authz hello message extension.  The AuthorizationData
-   structure is described in Section 3.3.
-
-   In some systems, clients present authorization information to the
-   server, and then the server provides new authorization information.
-   This type of transaction is not supported by SupplementalData
-   messages.  In cases where the client intends to request the TLS
-   server to perform authorization translation or expansion services,
-   such translation services ought to occur within the ApplicationData
-   messages, not within the TLS Handshake protocol.
-
-3.2. Server Authorization Data
-
-   The SupplementalData message sent from the server to the client
-   contains authorization data associated with the TLS server.  This
-   authorization information is expected to include statements about the
-   server's qualifications, reputation, accreditation, and so on.
-   Wherever possible, authorizations that can be misappropriated for
-   fraudulent use ought to be avoided.  The format of the authorization
-   data depends on the format negotiated in the server_authz hello
-   message extensions.  The AuthorizationData structure is described in
-   Section 3.3.
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                                April 2006
-
-
-3.3. AuthorizationData Type
-
-   The AuthorizationData structure carried authorization information for
-   either the client or the server.  The AuthzDataFormat specified in
-   Section 2.3 for use in the hello extensions is also used in this
-   structure.
-
-   All of the entries in the authz_data_list MUST employ authorization
-   data formats that were negotiated in the relevant hello message
-   extension.
-
-      struct{
-         AuthorizationDataEntry authz_data_list<1..2^16-1>;
-      } AuthorizationData;
-
-      struct {
-         AuthzDataFormat authz_format;
-         select (AuthzDataFormat) {
-            case x509_attr_cert:     X509AttrCert;
-            case saml_assertion:     SAMLAssertion;
-            case x509_attr_cert_url: URLandHash;
-            case saml_assertion_url: URLandHash;
-         }
-      } AuthorizationDataEntry;
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-      opaque X509AttrCert<1..2^16-1>;
-      opaque SAMLAssertion<1..2^16-1>;
-
-      struct {
-         opaque url<1..2^16-1>;
-         HashType hash_type;
-         select (hash_type) {
-            case sha1:   SHA1Hash;
-            case sha256: SHA256Hash;
-         } hash;
-      } URLandHash;
-
-      enum {
-         sha1(0), sha256(1), (255)
-      } HashType;
-
-      opaque SHA1Hash[20];
-      opaque SHA256Hash[32];
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                                April 2006
-
-
-3.3.1. X.509 Attribute Certificate
-
-   When X509AttrCert is used, the field contains an ASN.1 DER-encoded
-   X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
-   [ATTRCERT].  An AC is a structure similar to a public key certificate
-   (PKC) [PKIX1]; the main difference being that the AC contains no
-   public key.  An AC may contain attributes that specify group
-   membership, role, security clearance, or other authorization
-   information associated with the AC holder.
-
-   When making an authorization decision based on an AC, proper linkage
-   between the AC holder and the public key certificate that is
-   transferred in the TLS Certificate message is needed.  The AC holder
-   field provides this linkage.  The holder field is a SEQUENCE allowing
-   three different (optional) syntaxes: baseCertificateID, entityName
-   and objectDigestInfo.  In the TLS authorization context, the holder
-   field MUST use the either baseCertificateID or entityName.  In the
-   baseCertificateID case, the baseCertificateID field MUST match the
-   issuer and serialNumber fields in the certificate.  In the entityName
-   case, the entityName MUST be the same as the subject field in the
-   certificate or one of the subjectAltName extension values in the
-   certificate.  Note that [PKIX1] mandates that the subjectAltName
-   extension be present if the subject field contains an empty
-   distinguished name.
-
-3.3.2. SAML Assertion
-
-   When SAMLAssertion is used, the field contains XML constructs with a
-   nested structure defined in [SAML1.1][SAML2.0].  SAML is an XML-based
-   framework for exchanging security information.  This security
-   information is expressed in the form of assertions about subjects,
-   where a subject is either human or computer with an identity.  In
-   this context, the SAML assertions are most likely to convey
-   authentication or attribute statements to be used as input to
-   authorization policy governing whether subjects are allowed to access
-   certain resources.  Assertions are issued by SAML authorities.
-
-   When making an authorization decision based on a SAML assertion,
-   proper linkage between the SAML assertion and the public key
-   certificate that is transferred in the TLS Certificate message may be
-   needed.  A "Holder of Key" subject confirmation method in the SAML
-   assertion can provide this linkage.  In other scenarios, it may be
-   acceptable to use alternate confirmation methods that do not provide
-   a strong binding, such as a bearer mechanism.  SAML assertion
-   recipients MUST decide which subject confirmation methods are
-   acceptable; such decisions MAY be specific to the SAML assertion
-   contents and the TLS session context.
-
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                                April 2006
-
-
-   There is no general requirement that the subject of the SAML
-   assertion correspond directly to the subject of the certificate.
-   They may represent the same or different entities.  When they are
-   different, SAML also provides a mechanism by which the certificate
-   subject can be identified separately from the subject in the SAML
-   assertion subject confirmation method.
-
-   Since the SAML assertion is being provided at a part of the TLS
-   Handshake that is unencrypted, an eavesdropper could replay the same
-   SAML assertion when they establish their own TLS session.  This is
-   especially important when a bearer mechanism is employed, the
-   recipient of the SAML assertion assumes that the sender is an
-   acceptable attesting entity for the SAML assertion.  Some constraints
-   may be included to limit the context where the bearer mechanism will
-   be accepted.  For example, the period of time that the SAML assertion
-   can be short-lived (often minutes), the source address can be
-   constrained, or the destination endpoint can be identified.  Also,
-   bearer assertions are often checked against a cache of SAML assertion
-   unique identifiers that were recently received in order to detect
-   replay.  This is an appropriate countermeasure if the bearer
-   assertion is intended to be used just once.  Section 5 provides a way
-   to protect authorization information when necessary.
-
-3.3.3. URL and Hash
-
-   Since the X.509 AC and SAML assertion can be large, alternatives
-   provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML
-   Assertion.  To ensure that the intended object is obtained, a one-way
-   hash value of the object is also included.  Integrity of this one-way
-   hash value is provided by the TLS Finished message.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support URLs that employ the http scheme.
-   Other schemes may also be supported; however, to avoid circular
-   dependencies, supported schemes SHOULD NOT themselves make use of
-   TLS, such as the https scheme.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
-   as one-way hash functions.  Other one-way hash functions may also be
-   supported.  Additional one-way hash functions can be registered in
-   the future using the procedures in section 3.
-
-4. IANA Considerations
-
-   This document defines a two TLS extensions: client_authz(TBD) and
-   server_authz(TBD).  These extension type values are assigned from the
-   TLS Extension Type registry defined in [TLSEXT].
-
-
-
-Brown & Housley                                                [Page 10]
-
-Internet-Draft                                                April 2006
-
-
-   This document defines one TLS supplemental data type:
-   authz_data(TBD).  This supplemental data type is assigned from the
-   TLS Supplemental Data Type registry defined in [TLSSUPP].
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Authorization Data Formats.  The first four entries in the
-   registry are x509_attr_cert(0), saml_assertion(1),
-   x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
-   Data Format identifiers with values in the inclusive range 0-63
-   (decimal) are assigned via RFC 2434 [IANA] Standards Action.  Values
-   from the inclusive range 64-223 (decimal) are assigned via RFC 2434
-   Specification Required.  Values from the inclusive range 224-255
-   (decimal) are reserved for RFC 2434 Private Use.
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Hash Types.  The first two entries in the registry are
-   sha1(0) and sha256(1).  TLS Hash Type identifiers with values in the
-   inclusive range 0-158 (decimal) are assigned via RFC 2434 [IANA]
-   Standards Action.  Values from the inclusive range 159-223 (decimal)
-   are assigned via RFC 2434 Specification Required.  Values from the
-   inclusive range 224-255 (decimal) are reserved for RFC 2434 Private
-   Use.
-
-5. Security Considerations
-
-   A TLS server can support more than one application, and each
-   application may include several features, each of which requires
-   separate authorization checks.  This is the reason that more than one
-   piece of authorization information can be provided.
-
-   A TLS server that requires different authorization information for
-   different applications or different application features may find
-   that a client has provided sufficient authorization information to
-   grant access to a subset of these offerings.  In this situation the
-   TLS Handshake protocol will complete successfully; however, the
-   server must ensure that the client will only be able to use the
-   appropriate applications and application features.  That is, the TLS
-   server must deny access to the applications and application features
-   for which authorization has not been confirmed.
-
-   In many cases, the authorization information is itself sensitive.
-   The double handshake technique can be used to provide protection for
-   the authorization information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   authorization extensions, but it does result in protected
-   communications.  Then, a second handshake that includes the
-   authorization information is performed using the protected
-   communications.  In Figure 2, the number on the right side indicates
-
-
-
-Brown & Housley                                                [Page 11]
-
-Internet-Draft                                                April 2006
-
-
-   the amount of protection for the TLS message on that line.  A zero
-   (0) indicates that there is no communication protection; a one (1)
-   indicates that protection is provided by the first TLS session; and a
-   two (2) indicates that protection is provided by both TLS sessions.
-
-   The placement of the SupplementalData message in the TLS Handshake
-   results in the server providing its authorization information before
-   the client is authenticated.  In many situations, servers will not
-   want to provide authorization information until the client is
-   authenticated.  The double handshake illustrated in Figure 2 provides
-   a technique to ensure that the parties are mutually authenticated
-   before either party provides authorization information.
-
-
-    Client                                                   Server
-
-    ClientHello (no extensions) -------->                            |0
-                                        ServerHello (no extensions)  |0
-                                                       Certificate*  |0
-                                                 ServerKeyExchange*  |0
-                                                CertificateRequest*  |0
-                                <--------           ServerHelloDone  |0
-    Certificate*                                                     |0
-    ClientKeyExchange                                                |0
-    CertificateVerify*                                               |0
-    [ChangeCipherSpec]                                               |0
-    Finished                    -------->                            |1
-                                                 [ChangeCipherSpec]  |0
-                                <--------                  Finished  |1
-    ClientHello (w/ extensions) -------->                            |1
-                                        ServerHello (w/ extensions)  |1
-                                  SupplementalData (w/ authz data)*  |1
-                                                       Certificate*  |1
-                                                 ServerKeyExchange*  |1
-                                                CertificateRequest*  |1
-                                <--------           ServerHelloDone  |1
-    SupplementalData (w/ authz data)*                                |1
-    Certificate*                                                     |1
-    ClientKeyExchange                                                |1
-    CertificateVerify*                                               |1
-    [ChangeCipherSpec]                                               |1
-    Finished                    -------->                            |2
-                                                 [ChangeCipherSpec]  |1
-                                <--------                  Finished  |2
-    Application Data            <------->          Application Data  |2
-
-         Figure 2. Double Handshake to Protect Authorization Data
-
-
-
-
-Brown & Housley                                                [Page 12]
-
-Internet-Draft                                                April 2006
-
-
-6. Acknowledgement
-
-   The authors thank Scott Cantor for his assistance with the SAML
-   Assertion portion of the document.
-
-7. Normative References
-
-   [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
-                Certificate Profile for Authorization", RFC 3281,
-                April 2002.
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-   [PKIX1]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                X.509 Public Key Infrastructure Certificate and
-                Certificate Revocation List (CRL) Profile", RFC 3280,
-                April 2002.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 3546, June 2003.
-
-   [TLSSUPP]    Santesson, S., " TLS Handshake Message for Supplemental
-                Data", work in progress: draft-santesson-tls-supp,
-                March 2006.
-
-   [SAML1.1]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 1.1
-                Specification Set", September 2003.
-
-   [SAML2.0]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 2.0
-                Specification Set", March2005.
-
-   [SHA1]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.
-
-   [SHA2]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.
-
-
-
-
-Brown & Housley                                                [Page 13]
-
-Internet-Draft                                                April 2006
-
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN  55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-Brown & Housley                                                [Page 14]
-
-Internet-Draft                                                April 2006
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 15]
diff --git a/doc/protocol/draft-housley-tls-authz-extns-05.txt b/doc/protocol/draft-housley-tls-authz-extns-05.txt
deleted file mode 100644
index 458445261f..0000000000
--- a/doc/protocol/draft-housley-tls-authz-extns-05.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-May 2006                                               RedPhone Security
-Expires: November 2006                                        R. Housley
-                                                          Vigil Security
-
-        Transport Layer Security (TLS) Authorization Extensions
-                 <draft-housley-tls-authz-extns-05.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies authorization extensions to the Transport
-   Layer Security (TLS) Handshake Protocol.  Extensions carried in the
-   client and server hello messages to confirm that both parties support
-   the desired authorization data types.  Then, if supported by both the
-   client and the server, authorization information is exchanged in the
-   supplemental data handshake message.
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                                  May 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned at the time of the original design for
-   TLS.  The extensions introduced in this document are designed to
-   enable TLS to operate in environments where authorization information
-   needs to be exchanged between the client and the server before any
-   protected data is exchanged.
-
-   The use of these TLS authorization extensions is especially
-   attractive when more than one application protocol can make use of
-   the same authorization information.  Straightforward binding of
-   identification, authentication, and authorization information is
-   possible when all of these are handled within TLS.  If each
-   application requires unique authorization information, then it might
-   best be carried within the TLS-protected application protocol.
-   However, care must be taken to ensure appropriate bindings when
-   identification, authentication, and authorization information are
-   handled at different protocol layers.
-
-   This document describes authorization extensions for the TLS
-   Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
-   observe the conventions defined for TLS Extensions [TLSEXT] that make
-   use of the general extension mechanisms for the client hello message
-   and the server hello message.  The extensions described in this
-   document confirm that both the client and the server support the
-   desired authorization data types.  Then, if supported, authorization
-   information is exchanged in the supplemental data handshake message
-   [TLSSUPP].
-
-   The authorization extensions may be used in conjunction with TLS 1.0
-   and TLS 1.1.  The extensions are designed to be backwards compatible,
-   meaning that the Handshake Protocol Supplemental Data messages will
-   only contain authorization information of a particular type if the
-   client indicates support for them in the client hello message and the
-   server indicates support for them in the server hello message.
-
-   Clients typically know the context of the TLS session that is being
-   setup, thus the client can use the authorization extensions when they
-   are needed.  Servers must accept extended client hello messages, even
-   if the server does not "understand" the all of the listed extensions.
-   However, the server will not indicate support for these "not
-   understood" extensions.  Then, clients may reject communications with
-   servers that do not support the authorization extensions.
-
-
-
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                                  May 2006
-
-
-1.1. Conventions
-
-   The syntax for the authorization messages is defined using the TLS
-   Presentation Language, which is specified in Section 4 of [TLS1.0].
-
-   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 [STDWORDS].
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the authorization extensions
-   and supplemental data messages in the full TLS handshake.
-
-    Client                                                   Server
-
-    ClientHello (w/ extensions) -------->
-
-                                        ServerHello (w/ extensions)
-                                                  SupplementalData*
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                <--------           ServerHelloDone
-    SupplementalData*
-    Certificate*
-    ClientKeyExchange
-    CertificateVerify*
-    [ChangeCipherSpec]
-    Finished                    -------->
-                                                 [ChangeCipherSpec]
-                                <--------                  Finished
-    Application Data            <------->          Application Data
-
-     *  Indicates optional or situation-dependent messages that
-        are not always sent.
-
-     [] Indicates that ChangeCipherSpec is an independent TLS
-        Protocol content type; it is not actually a TLS
-        handshake message.
-
-        Figure 1. Authorization data exchange in full TLS handshake
-
-
-   The ClientHello message includes an indication of the client
-   authorization data formats that are supported and an indication of
-   the server authorization data formats that are supported.  The
-   ServerHello message contains similar indications, but any
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                                  May 2006
-
-
-   authorization data formats that are not supported by the server are
-   not included.  Both the client and the server MUST indicate support
-   for the authorization data types.  If the list of mutually supported
-   authorization data formats is empty, then the ServerHello message
-   MUST NOT carry the affected extension at all.
-
-2. Authorization Extension Types
-
-   The general extension mechanisms enable clients and servers to
-   negotiate whether to use specific extensions, and how to use specific
-   extensions.  As specified in [TLSEXT], the extension format used in
-   the extended client hello message and extended server hello message
-   is repeated here for convenience:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the corresponding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   associated extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of two new extension types:
-   client_authz and server_authz.  These extension types are described
-   in Section 2.1 and Section 2.2, respectively.  This specification
-   adds two new types to ExtensionType:
-
-      enum {
-        client_authz(TBD), server_authz(TBD), (65535)
-      } ExtensionType;
-
-   The authorization extensions are relevant when a session is initiated
-   and any subsequent session resumption.  However, a client that
-   requests resumption of a session does not know whether the server
-   will have all of the context necessary to accept this request, and
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                                  May 2006
-
-
-   therefore the client SHOULD send an extended client hello message
-   that includes the extension types associated with the authorization
-   extensions.  This way, if the resumption request is denied, then the
-   authorization extensions will be negotiated as normal.
-
-2.1. The client_authz Extension Type
-
-   Clients MUST include the client_authz extension type in the extended
-   client hello message to indicate their desire to send authorization
-   data to the server.  The extension_data field indicates the format of
-   the authorization data that will be sent in the supplemental data
-   handshake message.  The syntax of the client_authz extension_data
-   field is described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   client_authz extension MUST respond with the same client_authz
-   extension in the extended server hello message if the server is
-   willing to receive authorization data in the indicated format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The client_authz extension MUST be omitted from the extended
-   server hello message if the server is not willing to receive
-   authorization data in any of the indicated formats.
-
-2.2. The server_authz Extension Type
-
-   Clients MUST include the server_authz extension type in the extended
-   client hello message to indicate their desire to receive
-   authorization data from the server.  The extension_data field
-   indicates the format of the authorization data that will be sent in
-   the supplemental data handshake message.  The syntax of the
-   server_authz extension_data field as described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   server_authz extension MUST respond with the same server_authz
-   extension in the extended server hello message if the server is
-   willing to provide authorization data in the requested format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The server_authz extension MUST be omitted from the extended
-   server hello message if the server is not able to provide
-   authorization data in any of the indicated formats.
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                                  May 2006
-
-
-2.3. AuthzDataFormat Type
-
-   The AuthzDataFormat type is used in both the client_authz and the
-   server_authz extensions.  It indicates the format of the
-   authorization data that will be transferred.  The
-   AuthorizationDataFormats type definition is:
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), keynote_assertion_list(4), (255)
-      } AuthzDataFormat;
-
-      AuthorizationDataFormats authz_format_list<1..2^8-1>;
-
-   When the x509_attr_cert value is present, the authorization data is
-   an X.509 Attribute Certificate (AC) that conforms to the profile in
-   RFC 3281 [ATTRCERT].
-
-   When the saml_assertion value is present, the authorization data is
-   an assertion composed using the Security Assertion Markup Language
-   (SAML) [SAML1.1][SAML2.0].
-
-   When the x509_attr_cert_url value is present, the authorization data
-   is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT];
-   however, the AC is fetched with the supplied URL.  A one-way hash
-   value is provided to ensure that the intended AC is obtained.
-
-   When the saml_assertion_url value is present, the authorization data
-   is a SAML Assertion; however, the SAML Assertion is fetched with the
-   supplied URL.  A one-way hash value is provided to ensure that the
-   intended SAML Assertion is obtained.
-
-   When the keynote_assertion_list value is present, the authorization
-   data is a list of KeyNote assertions that conforms to the profile in
-   RFC 2704 [KEYNOTE].
-
-3. Supplemental Data Handshake Message Usage
-
-   As shown in Figure 1, supplemental data can be exchanges in two
-   places in the handshake protocol.  The client_authz extension
-   determines what authorization data formats are acceptable for
-   transfer from the client to the server, and the server_authz
-   extension determines what authorization data formats are acceptable
-   for transfer from the server to the client.  In both cases, the
-   syntax specified in [TLSSUPP] is used along with the authz_data type
-   defined in this document.
-
-
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                                  May 2006
-
-
-      enum {
-         authz_data(TBD), (65535)
-      } SupplementalDataType;
-
-      struct {
-         SupplementalDataType supplemental_data_type;
-         select(SupplementalDataType) {
-            case authz_data:  AuthorizationData;
-         }
-      } SupplementalData;
-
-3.1. Client Authorization Data
-
-   The SupplementalData message sent from the client to the server
-   contains authorization data associated with the TLS client.
-   Following the principle of least privilege, the client ought to send
-   the minimal set of authorization information necessary to accomplish
-   the task at hand.  That is, only those authorizations that are
-   expected to be required by the server in order to gain access to the
-   needed server resources ought to be included.  The format of the
-   authorization data depends on the format negotiated in the
-   client_authz hello message extension.  The AuthorizationData
-   structure is described in Section 3.3.
-
-   In some systems, clients present authorization information to the
-   server, and then the server provides new authorization information.
-   This type of transaction is not supported by SupplementalData
-   messages.  In cases where the client intends to request the TLS
-   server to perform authorization translation or expansion services,
-   such translation services ought to occur within the ApplicationData
-   messages, not within the TLS Handshake protocol.
-
-3.2. Server Authorization Data
-
-   The SupplementalData message sent from the server to the client
-   contains authorization data associated with the TLS server.  This
-   authorization information is expected to include statements about the
-   server's qualifications, reputation, accreditation, and so on.
-   Wherever possible, authorizations that can be misappropriated for
-   fraudulent use ought to be avoided.  The format of the authorization
-   data depends on the format negotiated in the server_authz hello
-   message extensions.  The AuthorizationData structure is described in
-   Section 3.3.
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                                  May 2006
-
-
-3.3. AuthorizationData Type
-
-   The AuthorizationData structure carried authorization information for
-   either the client or the server.  The AuthzDataFormat specified in
-   Section 2.3 for use in the hello extensions is also used in this
-   structure.
-
-   All of the entries in the authz_data_list MUST employ authorization
-   data formats that were negotiated in the relevant hello message
-   extension.
-
-      struct{
-         AuthorizationDataEntry authz_data_list<1..2^16-1>;
-      } AuthorizationData;
-
-      struct {
-         AuthzDataFormat authz_format;
-         select (AuthzDataFormat) {
-            case x509_attr_cert:         X509AttrCert;
-            case saml_assertion:         SAMLAssertion;
-            case x509_attr_cert_url:     URLandHash;
-            case saml_assertion_url:     URLandHash;
-            case keynote_assertion_list: KeyNoteAssertionList;
-         }
-      } AuthorizationDataEntry;
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), keynote_assertion_list(4), (255)
-      } AuthzDataFormat;
-
-      opaque X509AttrCert<1..2^16-1>;
-
-      opaque SAMLAssertion<1..2^16-1>;
-
-      opaque KeyNoteAssertionList<1..2^16-1>;
-
-      struct {
-         opaque url<1..2^16-1>;
-         HashType hash_type;
-         select (hash_type) {
-            case sha1:   SHA1Hash;
-            case sha256: SHA256Hash;
-         } hash;
-      } URLandHash;
-
-
-
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                                  May 2006
-
-
-      enum {
-         sha1(0), sha256(1), (255)
-      } HashType;
-
-      opaque SHA1Hash[20];
-
-      opaque SHA256Hash[32];
-
-3.3.1. X.509 Attribute Certificate
-
-   When X509AttrCert is used, the field contains an ASN.1 DER-encoded
-   X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
-   [ATTRCERT].  An AC is a structure similar to a public key certificate
-   (PKC) [PKIX1]; the main difference being that the AC contains no
-   public key.  An AC may contain attributes that specify group
-   membership, role, security clearance, or other authorization
-   information associated with the AC holder.
-
-   When making an authorization decision based on an AC, proper linkage
-   between the AC holder and the public key certificate that is
-   transferred in the TLS Certificate message is needed.  The AC holder
-   field provides this linkage.  The holder field is a SEQUENCE allowing
-   three different (optional) syntaxes: baseCertificateID, entityName
-   and objectDigestInfo.  In the TLS authorization context, the holder
-   field MUST use the either baseCertificateID or entityName.  In the
-   baseCertificateID case, the baseCertificateID field MUST match the
-   issuer and serialNumber fields in the certificate.  In the entityName
-   case, the entityName MUST be the same as the subject field in the
-   certificate or one of the subjectAltName extension values in the
-   certificate.  Note that [PKIX1] mandates that the subjectAltName
-   extension be present if the subject field contains an empty
-   distinguished name.
-
-3.3.2. SAML Assertion
-
-   When SAMLAssertion is used, the field contains XML constructs with a
-   nested structure defined in [SAML1.1][SAML2.0].  SAML is an XML-based
-   framework for exchanging security information.  This security
-   information is expressed in the form of assertions about subjects,
-   where a subject is either human or computer with an identity.  In
-   this context, the SAML assertions are most likely to convey
-   authentication or attribute statements to be used as input to
-   authorization policy governing whether subjects are allowed to access
-   certain resources.  Assertions are issued by SAML authorities.
-
-   When making an authorization decision based on a SAML assertion,
-   proper linkage between the SAML assertion and the public key
-   certificate that is transferred in the TLS Certificate message may be
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                                  May 2006
-
-
-   needed.  A "Holder of Key" subject confirmation method in the SAML
-   assertion can provide this linkage.  In other scenarios, it may be
-   acceptable to use alternate confirmation methods that do not provide
-   a strong binding, such as a bearer mechanism.  SAML assertion
-   recipients MUST decide which subject confirmation methods are
-   acceptable; such decisions MAY be specific to the SAML assertion
-   contents and the TLS session context.
-
-   There is no general requirement that the subject of the SAML
-   assertion correspond directly to the subject of the certificate.
-   They may represent the same or different entities.  When they are
-   different, SAML also provides a mechanism by which the certificate
-   subject can be identified separately from the subject in the SAML
-   assertion subject confirmation method.
-
-   Since the SAML assertion is being provided at a part of the TLS
-   Handshake that is unencrypted, an eavesdropper could replay the same
-   SAML assertion when they establish their own TLS session.  This is
-   especially important when a bearer mechanism is employed, the
-   recipient of the SAML assertion assumes that the sender is an
-   acceptable attesting entity for the SAML assertion.  Some constraints
-   may be included to limit the context where the bearer mechanism will
-   be accepted.  For example, the period of time that the SAML assertion
-   can be short-lived (often minutes), the source address can be
-   constrained, or the destination endpoint can be identified.  Also,
-   bearer assertions are often checked against a cache of SAML assertion
-   unique identifiers that were recently received in order to detect
-   replay.  This is an appropriate countermeasure if the bearer
-   assertion is intended to be used just once.  Section 5 provides a way
-   to protect authorization information when necessary.
-
-3.3.3. URL and Hash
-
-   Since the X.509 AC and SAML assertion can be large, alternatives
-   provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML
-   Assertion.  To ensure that the intended object is obtained, a one-way
-   hash value of the object is also included.  Integrity of this one-way
-   hash value is provided by the TLS Finished message.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support URLs that employ the http scheme.
-   Other schemes may also be supported; however, to avoid circular
-   dependencies, supported schemes SHOULD NOT themselves make use of
-   TLS, such as the https scheme.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
-   as one-way hash functions.  Other one-way hash functions may also be
-
-
-
-Brown & Housley                                                [Page 10]
-
-Internet-Draft                                                  May 2006
-
-
-   supported.  Additional one-way hash functions can be registered in
-   the future using the procedures in section 3.
-
-3.3.4. KeyNote Assertion List
-
-   When KeyNoteAssertion List is used, the field contains an ASCII-
-   encoded list of signed KeyNote assertions, as described in RFC 2704
-   [KEYNOTE].  The assertions are separated by two '\n' (newline)
-   characters.  A KeyNote assertion is a structure similar to a public
-   key certificate; the main difference is that instead of a binding
-   between a name and a public key, KeyNote assertions bind public keys
-   to authorization rules that are evaluated by the peer when the sender
-   later issues specific requests.
-
-   When making an authorization decision based on a list of KeyNote
-   assertions, proper linkage between the KeyNote assertions and the
-   public key certificate that is transferred in the TLS Certificate
-   message is needed.  Receivers of a KeyNote assertion list should
-   initialize the ACTION_AUTHORIZER variable to be the sender's public
-   key, which was used to authenticate the TLS exchange.
-
-4. IANA Considerations
-
-   This document defines a two TLS extensions: client_authz(TBD) and
-   server_authz(TBD).  These extension type values are assigned from the
-   TLS Extension Type registry defined in [TLSEXT].
-
-   This document defines one TLS supplemental data type:
-   authz_data(TBD).  This supplemental data type is assigned from the
-   TLS Supplemental Data Type registry defined in [TLSSUPP].
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Authorization Data Formats.  The first five entries in the
-   registry are x509_attr_cert(0), saml_assertion(1),
-   x509_attr_cert_url(2), saml_assertion_url(3), and
-   keynote_assertion_list(4).  TLS Authorization Data Format identifiers
-   with values in the inclusive range 0-63 (decimal) are assigned via
-   RFC 2434 [IANA] Standards Action.  Values from the inclusive range
-   64-223 (decimal) are assigned via RFC 2434 Specification Required.
-   Values from the inclusive range 224-255 (decimal) are reserved for
-   RFC 2434 Private Use.
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Hash Types.  The first two entries in the registry are
-   sha1(0) and sha256(1).  TLS Hash Type identifiers with values in the
-   inclusive range 0-158 (decimal) are assigned via RFC 2434 [IANA]
-   Standards Action.  Values from the inclusive range 159-223 (decimal)
-   are assigned via RFC 2434 Specification Required.  Values from the
-
-
-
-Brown & Housley                                                [Page 11]
-
-Internet-Draft                                                  May 2006
-
-
-   inclusive range 224-255 (decimal) are reserved for RFC 2434 Private
-   Use.
-
-5. Security Considerations
-
-   A TLS server can support more than one application, and each
-   application may include several features, each of which requires
-   separate authorization checks.  This is the reason that more than one
-   piece of authorization information can be provided.
-
-   A TLS server that requires different authorization information for
-   different applications or different application features may find
-   that a client has provided sufficient authorization information to
-   grant access to a subset of these offerings.  In this situation the
-   TLS Handshake protocol will complete successfully; however, the
-   server must ensure that the client will only be able to use the
-   appropriate applications and application features.  That is, the TLS
-   server must deny access to the applications and application features
-   for which authorization has not been confirmed.
-
-   In many cases, the authorization information is itself sensitive.
-   The double handshake technique can be used to provide protection for
-   the authorization information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   authorization extensions, but it does result in protected
-   communications.  Then, a second handshake that includes the
-   authorization information is performed using the protected
-   communications.  In Figure 2, the number on the right side indicates
-   the amount of protection for the TLS message on that line.  A zero
-   (0) indicates that there is no communication protection; a one (1)
-   indicates that protection is provided by the first TLS session; and a
-   two (2) indicates that protection is provided by both TLS sessions.
-
-   The placement of the SupplementalData message in the TLS Handshake
-   results in the server providing its authorization information before
-   the client is authenticated.  In many situations, servers will not
-   want to provide authorization information until the client is
-   authenticated.  The double handshake illustrated in Figure 2 provides
-   a technique to ensure that the parties are mutually authenticated
-   before either party provides authorization information.
-
-6. Acknowledgement
-
-   The authors thank Scott Cantor for his assistance with the SAML
-   Assertion portion of the document and Angelos Keromytis for his
-   assistance with the KeyNote portion of the document.
-
-
-
-
-
-Brown & Housley                                                [Page 12]
-
-Internet-Draft                                                  May 2006
-
-
-    Client                                                   Server
-
-    ClientHello (no extensions) -------->                            |0
-                                        ServerHello (no extensions)  |0
-                                                       Certificate*  |0
-                                                 ServerKeyExchange*  |0
-                                                CertificateRequest*  |0
-                                <--------           ServerHelloDone  |0
-    Certificate*                                                     |0
-    ClientKeyExchange                                                |0
-    CertificateVerify*                                               |0
-    [ChangeCipherSpec]                                               |0
-    Finished                    -------->                            |1
-                                                 [ChangeCipherSpec]  |0
-                                <--------                  Finished  |1
-    ClientHello (w/ extensions) -------->                            |1
-                                        ServerHello (w/ extensions)  |1
-                                  SupplementalData (w/ authz data)*  |1
-                                                       Certificate*  |1
-                                                 ServerKeyExchange*  |1
-                                                CertificateRequest*  |1
-                                <--------           ServerHelloDone  |1
-    SupplementalData (w/ authz data)*                                |1
-    Certificate*                                                     |1
-    ClientKeyExchange                                                |1
-    CertificateVerify*                                               |1
-    [ChangeCipherSpec]                                               |1
-    Finished                    -------->                            |2
-                                                 [ChangeCipherSpec]  |1
-                                <--------                  Finished  |2
-    Application Data            <------->          Application Data  |2
-
-         Figure 2. Double Handshake to Protect Authorization Data
-
-
-7. Normative References
-
-   [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
-                Certificate Profile for Authorization", RFC 3281,
-                April 2002.
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-   [KEYNOTE]    Blaze, M., Feigenbaum, J., Ioannidis, J., and
-                A. Keromytis, "The KeyNote Trust-Management System,
-                Version 2", RFC 2704, September 1999.
-
-
-
-Brown & Housley                                                [Page 13]
-
-Internet-Draft                                                  May 2006
-
-
-   [PKIX1]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                X.509 Public Key Infrastructure Certificate and
-                Certificate Revocation List (CRL) Profile", RFC 3280,
-                April 2002.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 3546, June 2003.
-
-   [TLSSUPP]    Santesson, S., " TLS Handshake Message for Supplemental
-                Data", work in progress: draft-santesson-tls-supp,
-                March 2006.
-
-   [SAML1.1]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 1.1
-                Specification Set", September 2003.
-
-   [SAML2.0]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 2.0
-                Specification Set", March2005.
-
-   [SHA1]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.
-
-   [SHA2]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 14]
-
-Internet-Draft                                                  May 2006
-
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN  55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 15]
-
-Internet-Draft                                                  May 2006
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 16]
diff --git a/doc/protocol/draft-housley-tls-authz-extns-06.txt b/doc/protocol/draft-housley-tls-authz-extns-06.txt
deleted file mode 100644
index 6d2e48a93c..0000000000
--- a/doc/protocol/draft-housley-tls-authz-extns-06.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-May 2006                                               RedPhone Security
-Expires: November 2006                                        R. Housley
-                                                          Vigil Security
-
-        Transport Layer Security (TLS) Authorization Extensions
-                 <draft-housley-tls-authz-extns-06.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies authorization extensions to the Transport
-   Layer Security (TLS) Handshake Protocol.  Extensions carried in the
-   client and server hello messages to confirm that both parties support
-   the desired authorization data types.  Then, if supported by both the
-   client and the server, authorization information is exchanged in the
-   supplemental data handshake message.
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                                  May 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned at the time of the original design for
-   TLS.  The extensions introduced in this document are designed to
-   enable TLS to operate in environments where authorization information
-   needs to be exchanged between the client and the server before any
-   protected data is exchanged.
-
-   The use of these TLS authorization extensions is especially
-   attractive when more than one application protocol can make use of
-   the same authorization information.  Straightforward binding of
-   identification, authentication, and authorization information is
-   possible when all of these are handled within TLS.  If each
-   application requires unique authorization information, then it might
-   best be carried within the TLS-protected application protocol.
-   However, care must be taken to ensure appropriate bindings when
-   identification, authentication, and authorization information are
-   handled at different protocol layers.
-
-   This document describes authorization extensions for the TLS
-   Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
-   observe the conventions defined for TLS Extensions [TLSEXT] that make
-   use of the general extension mechanisms for the client hello message
-   and the server hello message.  The extensions described in this
-   document confirm that both the client and the server support the
-   desired authorization data types.  Then, if supported, authorization
-   information is exchanged in the supplemental data handshake message
-   [TLSSUPP].
-
-   The authorization extensions may be used in conjunction with TLS 1.0
-   and TLS 1.1.  The extensions are designed to be backwards compatible,
-   meaning that the Handshake Protocol Supplemental Data messages will
-   only contain authorization information of a particular type if the
-   client indicates support for them in the client hello message and the
-   server indicates support for them in the server hello message.
-
-   Clients typically know the context of the TLS session that is being
-   setup, thus the client can use the authorization extensions when they
-   are needed.  Servers must accept extended client hello messages, even
-   if the server does not "understand" the all of the listed extensions.
-   However, the server will not indicate support for these "not
-   understood" extensions.  Then, clients may reject communications with
-   servers that do not support the authorization extensions.
-
-
-
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                                  May 2006
-
-
-1.1. Conventions
-
-   The syntax for the authorization messages is defined using the TLS
-   Presentation Language, which is specified in Section 4 of [TLS1.0].
-
-   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 [STDWORDS].
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the authorization extensions
-   and supplemental data messages in the full TLS handshake.
-
-
-    Client                                                   Server
-
-    ClientHello (w/ extensions) -------->
-
-                                        ServerHello (w/ extensions)
-                                                  SupplementalData*
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                <--------           ServerHelloDone
-    SupplementalData*
-    Certificate*
-    ClientKeyExchange
-    CertificateVerify*
-    [ChangeCipherSpec]
-    Finished                    -------->
-                                                 [ChangeCipherSpec]
-                                <--------                  Finished
-    Application Data            <------->          Application Data
-
-     *  Indicates optional or situation-dependent messages that
-        are not always sent.
-
-     [] Indicates that ChangeCipherSpec is an independent TLS
-        Protocol content type; it is not actually a TLS
-        handshake message.
-
-        Figure 1. Authorization data exchange in full TLS handshake
-
-
-   The ClientHello message includes an indication of the client
-   authorization data formats that are supported and an indication of
-   the server authorization data formats that are supported.  The
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                                  May 2006
-
-
-   ServerHello message contains similar indications, but any
-   authorization data formats that are not supported by the server are
-   not included.  Both the client and the server MUST indicate support
-   for the authorization data types.  If the list of mutually supported
-   authorization data formats is empty, then the ServerHello message
-   MUST NOT carry the affected extension at all.
-
-2. Authorization Extension Types
-
-   The general extension mechanisms enable clients and servers to
-   negotiate whether to use specific extensions, and how to use specific
-   extensions.  As specified in [TLSEXT], the extension format used in
-   the extended client hello message and extended server hello message
-   is repeated here for convenience:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the corresponding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   associated extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of two new extension types:
-   client_authz and server_authz.  These extension types are described
-   in Section 2.1 and Section 2.2, respectively.  This specification
-   adds two new types to ExtensionType:
-
-      enum {
-        client_authz(TBD), server_authz(TBD), (65535)
-      } ExtensionType;
-
-   The authorization extensions are relevant when a session is initiated
-   and any subsequent session resumption.  However, a client that
-   requests resumption of a session does not know whether the server
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                                  May 2006
-
-
-   will have all of the context necessary to accept this request, and
-   therefore the client SHOULD send an extended client hello message
-   that includes the extension types associated with the authorization
-   extensions.  This way, if the resumption request is denied, then the
-   authorization extensions will be negotiated as normal.
-
-2.1. The client_authz Extension Type
-
-   Clients MUST include the client_authz extension type in the extended
-   client hello message to indicate their desire to send authorization
-   data to the server.  The extension_data field indicates the format of
-   the authorization data that will be sent in the supplemental data
-   handshake message.  The syntax of the client_authz extension_data
-   field is described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   client_authz extension MUST respond with the same client_authz
-   extension in the extended server hello message if the server is
-   willing to receive authorization data in the indicated format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The client_authz extension MUST be omitted from the extended
-   server hello message if the server is not willing to receive
-   authorization data in any of the indicated formats.
-
-2.2. The server_authz Extension Type
-
-   Clients MUST include the server_authz extension type in the extended
-   client hello message to indicate their desire to receive
-   authorization data from the server.  The extension_data field
-   indicates the format of the authorization data that will be sent in
-   the supplemental data handshake message.  The syntax of the
-   server_authz extension_data field as described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   server_authz extension MUST respond with the same server_authz
-   extension in the extended server hello message if the server is
-   willing to provide authorization data in the requested format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The server_authz extension MUST be omitted from the extended
-   server hello message if the server is not able to provide
-   authorization data in any of the indicated formats.
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                                  May 2006
-
-
-2.3. AuthzDataFormat Type
-
-   The AuthzDataFormat type is used in both the client_authz and the
-   server_authz extensions.  It indicates the format of the
-   authorization data that will be transferred.  The AuthzDataFormats
-   type definition is:
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-      AuthzDataFormats authz_format_list<1..2^8-1>;
-
-   When the x509_attr_cert value is present, the authorization data is
-   an X.509 Attribute Certificate (AC) that conforms to the profile in
-   RFC 3281 [ATTRCERT].
-
-   When the saml_assertion value is present, the authorization data is
-   an assertion composed using the Security Assertion Markup Language
-   (SAML) [SAML1.1][SAML2.0].
-
-   When the x509_attr_cert_url value is present, the authorization data
-   is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT];
-   however, the AC is fetched with the supplied URL.  A one-way hash
-   value is provided to ensure that the intended AC is obtained.
-
-   When the saml_assertion_url value is present, the authorization data
-   is a SAML Assertion; however, the SAML Assertion is fetched with the
-   supplied URL.  A one-way hash value is provided to ensure that the
-   intended SAML Assertion is obtained.
-
-3. Supplemental Data Handshake Message Usage
-
-   As shown in Figure 1, supplemental data can be exchanges in two
-   places in the handshake protocol.  The client_authz extension
-   determines what authorization data formats are acceptable for
-   transfer from the client to the server, and the server_authz
-   extension determines what authorization data formats are acceptable
-   for transfer from the server to the client.  In both cases, the
-   syntax specified in [TLSSUPP] is used along with the authz_data type
-   defined in this document.
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                                  May 2006
-
-
-      enum {
-         authz_data(TBD), (65535)
-      } SupplementalDataType;
-
-      struct {
-         SupplementalDataType supplemental_data_type;
-         select(SupplementalDataType) {
-            case authz_data:  AuthorizationData;
-         }
-      } SupplementalData;
-
-3.1. Client Authorization Data
-
-   The SupplementalData message sent from the client to the server
-   contains authorization data associated with the TLS client.
-   Following the principle of least privilege, the client ought to send
-   the minimal set of authorization information necessary to accomplish
-   the task at hand.  That is, only those authorizations that are
-   expected to be required by the server in order to gain access to the
-   needed server resources ought to be included.  The format of the
-   authorization data depends on the format negotiated in the
-   client_authz hello message extension.  The AuthorizationData
-   structure is described in Section 3.3.
-
-   In some systems, clients present authorization information to the
-   server, and then the server provides new authorization information.
-   This type of transaction is not supported by SupplementalData
-   messages.  In cases where the client intends to request the TLS
-   server to perform authorization translation or expansion services,
-   such translation services ought to occur within the ApplicationData
-   messages, not within the TLS Handshake protocol.
-
-3.2. Server Authorization Data
-
-   The SupplementalData message sent from the server to the client
-   contains authorization data associated with the TLS server.  This
-   authorization information is expected to include statements about the
-   server's qualifications, reputation, accreditation, and so on.
-   Wherever possible, authorizations that can be misappropriated for
-   fraudulent use ought to be avoided.  The format of the authorization
-   data depends on the format negotiated in the server_authz hello
-   message extensions.  The AuthorizationData structure is described in
-   Section 3.3.
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                                  May 2006
-
-
-3.3. AuthorizationData Type
-
-   The AuthorizationData structure carried authorization information for
-   either the client or the server.  The AuthzDataFormat specified in
-   Section 2.3 for use in the hello extensions is also used in this
-   structure.
-
-   All of the entries in the authz_data_list MUST employ authorization
-   data formats that were negotiated in the relevant hello message
-   extension.
-
-      struct{
-         AuthorizationDataEntry authz_data_list<1..2^16-1>;
-      } AuthorizationData;
-
-      struct {
-         AuthzDataFormat authz_format;
-         select (AuthzDataFormat) {
-            case x509_attr_cert:         X509AttrCert;
-            case saml_assertion:         SAMLAssertion;
-            case x509_attr_cert_url:     URLandHash;
-            case saml_assertion_url:     URLandHash;
-         }
-      } AuthorizationDataEntry;
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-      opaque X509AttrCert<1..2^16-1>;
-
-      opaque SAMLAssertion<1..2^16-1>;
-
-      struct {
-         opaque url<1..2^16-1>;
-         HashType hash_type;
-         select (hash_type) {
-            case sha1:   SHA1Hash;
-            case sha256: SHA256Hash;
-         } hash;
-      } URLandHash;
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                                  May 2006
-
-
-      enum {
-         sha1(0), sha256(1), (255)
-      } HashType;
-
-      opaque SHA1Hash[20];
-
-      opaque SHA256Hash[32];
-
-3.3.1. X.509 Attribute Certificate
-
-   When X509AttrCert is used, the field contains an ASN.1 DER-encoded
-   X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
-   [ATTRCERT].  An AC is a structure similar to a public key certificate
-   (PKC) [PKIX1]; the main difference being that the AC contains no
-   public key.  An AC may contain attributes that specify group
-   membership, role, security clearance, or other authorization
-   information associated with the AC holder.
-
-   When making an authorization decision based on an AC, proper linkage
-   between the AC holder and the public key certificate that is
-   transferred in the TLS Certificate message is needed.  The AC holder
-   field provides this linkage.  The holder field is a SEQUENCE allowing
-   three different (optional) syntaxes: baseCertificateID, entityName
-   and objectDigestInfo.  In the TLS authorization context, the holder
-   field MUST use the either baseCertificateID or entityName.  In the
-   baseCertificateID case, the baseCertificateID field MUST match the
-   issuer and serialNumber fields in the certificate.  In the entityName
-   case, the entityName MUST be the same as the subject field in the
-   certificate or one of the subjectAltName extension values in the
-   certificate.  Note that [PKIX1] mandates that the subjectAltName
-   extension be present if the subject field contains an empty
-   distinguished name.
-
-3.3.2. SAML Assertion
-
-   When SAMLAssertion is used, the field contains XML constructs with a
-   nested structure defined in [SAML1.1][SAML2.0].  SAML is an XML-based
-   framework for exchanging security information.  This security
-   information is expressed in the form of assertions about subjects,
-   where a subject is either human or computer with an identity.  In
-   this context, the SAML assertions are most likely to convey
-   authentication or attribute statements to be used as input to
-   authorization policy governing whether subjects are allowed to access
-   certain resources.  Assertions are issued by SAML authorities.
-
-   When making an authorization decision based on a SAML assertion,
-   proper linkage between the SAML assertion and the public key
-   certificate that is transferred in the TLS Certificate message may be
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                                  May 2006
-
-
-   needed.  A "Holder of Key" subject confirmation method in the SAML
-   assertion can provide this linkage.  In other scenarios, it may be
-   acceptable to use alternate confirmation methods that do not provide
-   a strong binding, such as a bearer mechanism.  SAML assertion
-   recipients MUST decide which subject confirmation methods are
-   acceptable; such decisions MAY be specific to the SAML assertion
-   contents and the TLS session context.
-
-   There is no general requirement that the subject of the SAML
-   assertion correspond directly to the subject of the certificate.
-   They may represent the same or different entities.  When they are
-   different, SAML also provides a mechanism by which the certificate
-   subject can be identified separately from the subject in the SAML
-   assertion subject confirmation method.
-
-   Since the SAML assertion is being provided at a part of the TLS
-   Handshake that is unencrypted, an eavesdropper could replay the same
-   SAML assertion when they establish their own TLS session.  This is
-   especially important when a bearer mechanism is employed, the
-   recipient of the SAML assertion assumes that the sender is an
-   acceptable attesting entity for the SAML assertion.  Some constraints
-   may be included to limit the context where the bearer mechanism will
-   be accepted.  For example, the period of time that the SAML assertion
-   can be short-lived (often minutes), the source address can be
-   constrained, or the destination endpoint can be identified.  Also,
-   bearer assertions are often checked against a cache of SAML assertion
-   unique identifiers that were recently received in order to detect
-   replay.  This is an appropriate countermeasure if the bearer
-   assertion is intended to be used just once.  Section 5 provides a way
-   to protect authorization information when necessary.
-
-3.3.3. URL and Hash
-
-   Since the X.509 AC and SAML assertion can be large, alternatives
-   provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML
-   Assertion.  To ensure that the intended object is obtained, a one-way
-   hash value of the object is also included.  Integrity of this one-way
-   hash value is provided by the TLS Finished message.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support URLs that employ the http scheme.
-   Other schemes may also be supported; however, to avoid circular
-   dependencies, supported schemes SHOULD NOT themselves make use of
-   TLS, such as the https scheme.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
-   as one-way hash functions.  Other one-way hash functions may also be
-
-
-
-Brown & Housley                                                [Page 10]
-
-Internet-Draft                                                  May 2006
-
-
-   supported.  Additional one-way hash functions can be registered in
-   the future using the procedures in section 3.
-
-4. IANA Considerations
-
-   This document defines a two TLS extensions: client_authz(TBD) and
-   server_authz(TBD).  These extension type values are assigned from the
-   TLS Extension Type registry defined in [TLSEXT].
-
-   This document defines one TLS supplemental data type:
-   authz_data(TBD).  This supplemental data type is assigned from the
-   TLS Supplemental Data Type registry defined in [TLSSUPP].
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Authorization Data Formats.  The first five entries in the
-   registry are x509_attr_cert(0), saml_assertion(1),
-   x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
-   Data Format identifiers with values in the inclusive range 0-63
-   (decimal) are assigned via RFC 2434 [IANA] Standards Action.  Values
-   from the inclusive range 64-223 (decimal) are assigned via RFC 2434
-   Specification Required.  Values from the inclusive range 224-255
-   (decimal) are reserved for RFC 2434 Private Use.
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Hash Types.  The first two entries in the registry are
-   sha1(0) and sha256(1).  TLS Hash Type identifiers with values in the
-   inclusive range 0-158 (decimal) are assigned via RFC 2434 [IANA]
-   Standards Action.  Values from the inclusive range 159-223 (decimal)
-   are assigned via RFC 2434 Specification Required.  Values from the
-   inclusive range 224-255 (decimal) are reserved for RFC 2434 Private
-   Use.
-
-5. Security Considerations
-
-   A TLS server can support more than one application, and each
-   application may include several features, each of which requires
-   separate authorization checks.  This is the reason that more than one
-   piece of authorization information can be provided.
-
-   A TLS server that requires different authorization information for
-   different applications or different application features may find
-   that a client has provided sufficient authorization information to
-   grant access to a subset of these offerings.  In this situation the
-   TLS Handshake protocol will complete successfully; however, the
-   server must ensure that the client will only be able to use the
-   appropriate applications and application features.  That is, the TLS
-   server must deny access to the applications and application features
-   for which authorization has not been confirmed.
-
-
-
-Brown & Housley                                                [Page 11]
-
-Internet-Draft                                                  May 2006
-
-
-   In many cases, the authorization information is itself sensitive.
-   The double handshake technique can be used to provide protection for
-   the authorization information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   authorization extensions, but it does result in protected
-   communications.  Then, a second handshake that includes the
-   authorization information is performed using the protected
-   communications.  In Figure 2, the number on the right side indicates
-   the amount of protection for the TLS message on that line.  A zero
-   (0) indicates that there is no communication protection; a one (1)
-   indicates that protection is provided by the first TLS session; and a
-   two (2) indicates that protection is provided by both TLS sessions.
-
-   The placement of the SupplementalData message in the TLS Handshake
-   results in the server providing its authorization information before
-   the client is authenticated.  In many situations, servers will not
-   want to provide authorization information until the client is
-   authenticated.  The double handshake illustrated in Figure 2 provides
-   a technique to ensure that the parties are mutually authenticated
-   before either party provides authorization information.
-
-6. Acknowledgement
-
-   The authors thank Scott Cantor for his assistance with the SAML
-   Assertion portion of the document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 12]
-
-Internet-Draft                                                  May 2006
-
-
-    Client                                                   Server
-
-    ClientHello (no extensions) -------->                            |0
-                                        ServerHello (no extensions)  |0
-                                                       Certificate*  |0
-                                                 ServerKeyExchange*  |0
-                                                CertificateRequest*  |0
-                                <--------           ServerHelloDone  |0
-    Certificate*                                                     |0
-    ClientKeyExchange                                                |0
-    CertificateVerify*                                               |0
-    [ChangeCipherSpec]                                               |0
-    Finished                    -------->                            |1
-                                                 [ChangeCipherSpec]  |0
-                                <--------                  Finished  |1
-    ClientHello (w/ extensions) -------->                            |1
-                                        ServerHello (w/ extensions)  |1
-                                  SupplementalData (w/ authz data)*  |1
-                                                       Certificate*  |1
-                                                 ServerKeyExchange*  |1
-                                                CertificateRequest*  |1
-                                <--------           ServerHelloDone  |1
-    SupplementalData (w/ authz data)*                                |1
-    Certificate*                                                     |1
-    ClientKeyExchange                                                |1
-    CertificateVerify*                                               |1
-    [ChangeCipherSpec]                                               |1
-    Finished                    -------->                            |2
-                                                 [ChangeCipherSpec]  |1
-                                <--------                  Finished  |2
-    Application Data            <------->          Application Data  |2
-
-         Figure 2. Double Handshake to Protect Authorization Data
-
-
-7. Normative References
-
-   [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
-                Certificate Profile for Authorization", RFC 3281,
-                April 2002.
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 13]
-
-Internet-Draft                                                  May 2006
-
-
-   [PKIX1]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                X.509 Public Key Infrastructure Certificate and
-                Certificate Revocation List (CRL) Profile", RFC 3280,
-                April 2002.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 3546, June 2003.
-
-   [TLSSUPP]    Santesson, S., " TLS Handshake Message for Supplemental
-                Data", work in progress: draft-santesson-tls-supp,
-                March 2006.
-
-   [SAML1.1]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 1.1
-                Specification Set", September 2003.
-
-   [SAML2.0]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 2.0
-                Specification Set", March2005.
-
-   [SHA1]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.
-
-   [SHA2]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 14]
-
-Internet-Draft                                                  May 2006
-
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN  55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 15]
-
-Internet-Draft                                                  May 2006
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 16]
diff --git a/doc/protocol/draft-housley-tls-authz-extns-07.txt b/doc/protocol/draft-housley-tls-authz-extns-07.txt
deleted file mode 100644
index 884906c7a8..0000000000
--- a/doc/protocol/draft-housley-tls-authz-extns-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-
-Internet-Draft                                                  M. Brown
-Updates: 4346 (once approved)                          RedPhone Security
-June 2006                                                     R. Housley
-Expires: December 2006                                    Vigil Security
-
-        Transport Layer Security (TLS) Authorization Extensions
-                 <draft-housley-tls-authz-extns-07.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).  All Rights Reserved.
-
-Abstract
-
-   This document specifies authorization extensions to the Transport
-   Layer Security (TLS) Handshake Protocol.  Extensions carried in the
-   client and server hello messages to confirm that both parties support
-   the desired authorization data types.  Then, if supported by both the
-   client and the server, authorization information is exchanged in the
-   supplemental data handshake message.
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 1]
-
-Internet-Draft                                                 June 2006
-
-
-1. Introduction
-
-   Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
-   used in an increasing variety of operational environments, including
-   ones that were not envisioned at the time of the original design for
-   TLS.  The extensions introduced in this document are designed to
-   enable TLS to operate in environments where authorization information
-   needs to be exchanged between the client and the server before any
-   protected data is exchanged.
-
-   The use of these TLS authorization extensions is especially
-   attractive when more than one application protocol can make use of
-   the same authorization information.  Straightforward binding of
-   identification, authentication, and authorization information is
-   possible when all of these are handled within TLS.  If each
-   application requires unique authorization information, then it might
-   best be carried within the TLS-protected application protocol.
-   However, care must be taken to ensure appropriate bindings when
-   identification, authentication, and authorization information are
-   handled at different protocol layers.
-
-   This document describes authorization extensions for the TLS
-   Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
-   observe the conventions defined for TLS Extensions [TLSEXT] that make
-   use of the general extension mechanisms for the client hello message
-   and the server hello message.  The extensions described in this
-   document confirm that both the client and the server support the
-   desired authorization data types.  Then, if supported, authorization
-   information is exchanged in the supplemental data handshake message
-   [TLSSUPP].
-
-   The authorization extensions may be used in conjunction with TLS 1.0
-   and TLS 1.1.  The extensions are designed to be backwards compatible,
-   meaning that the Handshake Protocol Supplemental Data messages will
-   only contain authorization information of a particular type if the
-   client indicates support for them in the client hello message and the
-   server indicates support for them in the server hello message.
-
-   Clients typically know the context of the TLS session that is being
-   setup, thus the client can use the authorization extensions when they
-   are needed.  Servers must accept extended client hello messages, even
-   if the server does not "understand" the all of the listed extensions.
-   However, the server will not indicate support for these "not
-   understood" extensions.  Then, clients may reject communications with
-   servers that do not support the authorization extensions.
-
-
-
-
-
-
-Brown & Housley                                                 [Page 2]
-
-Internet-Draft                                                 June 2006
-
-
-1.1. Conventions
-
-   The syntax for the authorization messages is defined using the TLS
-   Presentation Language, which is specified in Section 4 of [TLS1.0].
-
-   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 [STDWORDS].
-
-1.2. Overview
-
-   Figure 1 illustrates the placement of the authorization extensions
-   and supplemental data messages in the full TLS handshake.
-
-
-    Client                                                   Server
-
-    ClientHello (w/ extensions) -------->
-
-                                        ServerHello (w/ extensions)
-                                                  SupplementalData*
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                <--------           ServerHelloDone
-    SupplementalData*
-    Certificate*
-    ClientKeyExchange
-    CertificateVerify*
-    [ChangeCipherSpec]
-    Finished                    -------->
-                                                 [ChangeCipherSpec]
-                                <--------                  Finished
-    Application Data            <------->          Application Data
-
-     *  Indicates optional or situation-dependent messages that
-        are not always sent.
-
-     [] Indicates that ChangeCipherSpec is an independent TLS
-        Protocol content type; it is not actually a TLS
-        handshake message.
-
-        Figure 1. Authorization data exchange in full TLS handshake
-
-
-   The ClientHello message includes an indication of the client
-   authorization data formats that are supported and an indication of
-   the server authorization data formats that are supported.  The
-
-
-
-Brown & Housley                                                 [Page 3]
-
-Internet-Draft                                                 June 2006
-
-
-   ServerHello message contains similar indications, but any
-   authorization data formats that are not supported by the server are
-   not included.  Both the client and the server MUST indicate support
-   for the authorization data types.  If the list of mutually supported
-   authorization data formats is empty, then the ServerHello message
-   MUST NOT carry the affected extension at all.
-
-2. Authorization Extension Types
-
-   The general extension mechanisms enable clients and servers to
-   negotiate whether to use specific extensions, and how to use specific
-   extensions.  As specified in [TLSEXT], the extension format used in
-   the extended client hello message and extended server hello message
-   is repeated here for convenience:
-
-      struct {
-         ExtensionType extension_type;
-         opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   The extension_type identifies a particular extension type, and the
-   extension_data contains information specific to the particular
-   extension type.
-
-   As specified in [TLSEXT], for all extension types, the extension type
-   MUST NOT appear in the extended server hello message unless the same
-   extension type appeared in the corresponding client hello message.
-   Clients MUST abort the handshake if they receive an extension type in
-   the extended server hello message that they did not request in the
-   associated extended client hello message.
-
-   When multiple extensions of different types are present in the
-   extended client hello message or the extended server hello message,
-   the extensions can appear in any order, but there MUST NOT be more
-   than one extension of the same type.
-
-   This document specifies the use of two new extension types:
-   client_authz and server_authz.  These extension types are described
-   in Section 2.1 and Section 2.2, respectively.  This specification
-   adds two new types to ExtensionType:
-
-      enum {
-        client_authz(TBD), server_authz(TBD), (65535)
-      } ExtensionType;
-
-   The authorization extensions are relevant when a session is initiated
-   and any subsequent session resumption.  However, a client that
-   requests resumption of a session does not know whether the server
-
-
-
-Brown & Housley                                                 [Page 4]
-
-Internet-Draft                                                 June 2006
-
-
-   will have all of the context necessary to accept this request, and
-   therefore the client SHOULD send an extended client hello message
-   that includes the extension types associated with the authorization
-   extensions.  This way, if the resumption request is denied, then the
-   authorization extensions will be negotiated as normal.
-
-2.1. The client_authz Extension Type
-
-   Clients MUST include the client_authz extension type in the extended
-   client hello message to indicate their desire to send authorization
-   data to the server.  The extension_data field indicates the format of
-   the authorization data that will be sent in the supplemental data
-   handshake message.  The syntax of the client_authz extension_data
-   field is described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   client_authz extension MUST respond with the same client_authz
-   extension in the extended server hello message if the server is
-   willing to receive authorization data in the indicated format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The client_authz extension MUST be omitted from the extended
-   server hello message if the server is not willing to receive
-   authorization data in any of the indicated formats.
-
-2.2. The server_authz Extension Type
-
-   Clients MUST include the server_authz extension type in the extended
-   client hello message to indicate their desire to receive
-   authorization data from the server.  The extension_data field
-   indicates the format of the authorization data that will be sent in
-   the supplemental data handshake message.  The syntax of the
-   server_authz extension_data field as described in Section 2.3.
-
-   Servers that receive an extended client hello message containing the
-   server_authz extension MUST respond with the same server_authz
-   extension in the extended server hello message if the server is
-   willing to provide authorization data in the requested format.  Any
-   unacceptable formats must be removed from the list provided by the
-   client.  The server_authz extension MUST be omitted from the extended
-   server hello message if the server is not able to provide
-   authorization data in any of the indicated formats.
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 5]
-
-Internet-Draft                                                 June 2006
-
-
-2.3. AuthzDataFormat Type
-
-   The AuthzDataFormat type is used in both the client_authz and the
-   server_authz extensions.  It indicates the format of the
-   authorization data that will be transferred.  The AuthzDataFormats
-   type definition is:
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-      AuthzDataFormats authz_format_list<1..2^8-1>;
-
-   When the x509_attr_cert value is present, the authorization data is
-   an X.509 Attribute Certificate (AC) that conforms to the profile in
-   RFC 3281 [ATTRCERT].
-
-   When the saml_assertion value is present, the authorization data is
-   an assertion composed using the Security Assertion Markup Language
-   (SAML) [SAML1.1][SAML2.0].
-
-   When the x509_attr_cert_url value is present, the authorization data
-   is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT];
-   however, the AC is fetched with the supplied URL.  A one-way hash
-   value is provided to ensure that the intended AC is obtained.
-
-   When the saml_assertion_url value is present, the authorization data
-   is a SAML Assertion; however, the SAML Assertion is fetched with the
-   supplied URL.  A one-way hash value is provided to ensure that the
-   intended SAML Assertion is obtained.
-
-3. Supplemental Data Handshake Message Usage
-
-   As shown in Figure 1, supplemental data can be exchanges in two
-   places in the handshake protocol.  The client_authz extension
-   determines what authorization data formats are acceptable for
-   transfer from the client to the server, and the server_authz
-   extension determines what authorization data formats are acceptable
-   for transfer from the server to the client.  In both cases, the
-   syntax specified in [TLSSUPP] is used along with the authz_data type
-   defined in this document.
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 6]
-
-Internet-Draft                                                 June 2006
-
-
-      enum {
-         authz_data(TBD), (65535)
-      } SupplementalDataType;
-
-      struct {
-         SupplementalDataType supplemental_data_type;
-         select(SupplementalDataType) {
-            case authz_data:  AuthorizationData;
-         }
-      } SupplementalData;
-
-3.1. Client Authorization Data
-
-   The SupplementalData message sent from the client to the server
-   contains authorization data associated with the TLS client.
-   Following the principle of least privilege, the client ought to send
-   the minimal set of authorization information necessary to accomplish
-   the task at hand.  That is, only those authorizations that are
-   expected to be required by the server in order to gain access to the
-   needed server resources ought to be included.  The format of the
-   authorization data depends on the format negotiated in the
-   client_authz hello message extension.  The AuthorizationData
-   structure is described in Section 3.3.
-
-   In some systems, clients present authorization information to the
-   server, and then the server provides new authorization information.
-   This type of transaction is not supported by SupplementalData
-   messages.  In cases where the client intends to request the TLS
-   server to perform authorization translation or expansion services,
-   such translation services ought to occur within the ApplicationData
-   messages, not within the TLS Handshake protocol.
-
-3.2. Server Authorization Data
-
-   The SupplementalData message sent from the server to the client
-   contains authorization data associated with the TLS server.  This
-   authorization information is expected to include statements about the
-   server's qualifications, reputation, accreditation, and so on.
-   Wherever possible, authorizations that can be misappropriated for
-   fraudulent use ought to be avoided.  The format of the authorization
-   data depends on the format negotiated in the server_authz hello
-   message extensions.  The AuthorizationData structure is described in
-   Section 3.3.
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 7]
-
-Internet-Draft                                                 June 2006
-
-
-3.3. AuthorizationData Type
-
-   The AuthorizationData structure carried authorization information for
-   either the client or the server.  The AuthzDataFormat specified in
-   Section 2.3 for use in the hello extensions is also used in this
-   structure.
-
-   All of the entries in the authz_data_list MUST employ authorization
-   data formats that were negotiated in the relevant hello message
-   extension.
-
-      struct{
-         AuthorizationDataEntry authz_data_list<1..2^16-1>;
-      } AuthorizationData;
-
-      struct {
-         AuthzDataFormat authz_format;
-         select (AuthzDataFormat) {
-            case x509_attr_cert:         X509AttrCert;
-            case saml_assertion:         SAMLAssertion;
-            case x509_attr_cert_url:     URLandHash;
-            case saml_assertion_url:     URLandHash;
-         }
-      } AuthorizationDataEntry;
-
-      enum {
-         x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
-         saml_assertion_url(3), (255)
-      } AuthzDataFormat;
-
-      opaque X509AttrCert<1..2^16-1>;
-
-      opaque SAMLAssertion<1..2^16-1>;
-
-      struct {
-         opaque url<1..2^16-1>;
-         HashType hash_type;
-         select (hash_type) {
-            case sha1:   SHA1Hash;
-            case sha256: SHA256Hash;
-         } hash;
-      } URLandHash;
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                 [Page 8]
-
-Internet-Draft                                                 June 2006
-
-
-      enum {
-         sha1(0), sha256(1), (255)
-      } HashType;
-
-      opaque SHA1Hash[20];
-
-      opaque SHA256Hash[32];
-
-3.3.1. X.509 Attribute Certificate
-
-   When X509AttrCert is used, the field contains an ASN.1 DER-encoded
-   X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
-   [ATTRCERT].  An AC is a structure similar to a public key certificate
-   (PKC) [PKIX1]; the main difference being that the AC contains no
-   public key.  An AC may contain attributes that specify group
-   membership, role, security clearance, or other authorization
-   information associated with the AC holder.
-
-   When making an authorization decision based on an AC, proper linkage
-   between the AC holder and the public key certificate that is
-   transferred in the TLS Certificate message is needed.  The AC holder
-   field provides this linkage.  The holder field is a SEQUENCE allowing
-   three different (optional) syntaxes: baseCertificateID, entityName
-   and objectDigestInfo.  In the TLS authorization context, the holder
-   field MUST use the either baseCertificateID or entityName.  In the
-   baseCertificateID case, the baseCertificateID field MUST match the
-   issuer and serialNumber fields in the certificate.  In the entityName
-   case, the entityName MUST be the same as the subject field in the
-   certificate or one of the subjectAltName extension values in the
-   certificate.  Note that [PKIX1] mandates that the subjectAltName
-   extension be present if the subject field contains an empty
-   distinguished name.
-
-3.3.2. SAML Assertion
-
-   When SAMLAssertion is used, the field contains an XML-encoded
-   <Assertion> element using the AssertionType complex type as defined
-   in [SAML1.1][SAML2.0].  SAML is an XML-based framework for exchanging
-   security information.  This security information is expressed in the
-   form of assertions about subjects, where a subject is either human or
-   computer with an identity.  In this context, the SAML assertions are
-   most likely to convey authentication or attribute statements to be
-   used as input to authorization policy governing whether subjects are
-   allowed to access certain resources.  Assertions are issued by SAML
-   authorities.
-
-   When making an authorization decision based on a SAML assertion,
-   proper linkage between the SAML assertion and the public key
-
-
-
-Brown & Housley                                                 [Page 9]
-
-Internet-Draft                                                 June 2006
-
-
-   certificate that is transferred in the TLS Certificate message may be
-   needed.  A "Holder of Key" subject confirmation method in the SAML
-   assertion can provide this linkage.  In other scenarios, it may be
-   acceptable to use alternate confirmation methods that do not provide
-   a strong binding, such as a bearer mechanism.  SAML assertion
-   recipients MUST decide which subject confirmation methods are
-   acceptable; such decisions MAY be specific to the SAML assertion
-   contents and the TLS session context.
-
-   There is no general requirement that the subject of the SAML
-   assertion correspond directly to the subject of the certificate.
-   They may represent the same or different entities.  When they are
-   different, SAML also provides a mechanism by which the certificate
-   subject can be identified separately from the subject in the SAML
-   assertion subject confirmation method.
-
-   Since the SAML assertion is being provided at a part of the TLS
-   Handshake that is unencrypted, an eavesdropper could replay the same
-   SAML assertion when they establish their own TLS session.  This is
-   especially important when a bearer mechanism is employed, the
-   recipient of the SAML assertion assumes that the sender is an
-   acceptable attesting entity for the SAML assertion.  Some constraints
-   may be included to limit the context where the bearer mechanism will
-   be accepted.  For example, the period of time that the SAML assertion
-   can be short-lived (often minutes), the source address can be
-   constrained, or the destination endpoint can be identified.  Also,
-   bearer assertions are often checked against a cache of SAML assertion
-   unique identifiers that were recently received in order to detect
-   replay.  This is an appropriate countermeasure if the bearer
-   assertion is intended to be used just once.  Section 5 provides a way
-   to protect authorization information when necessary.
-
-3.3.3. URL and Hash
-
-   Since the X.509 AC and SAML assertion can be large, alternatives
-   provide a URL to obtain the ASN.1 DER-encoded X.509 AC or SAML
-   Assertion.  To ensure that the intended object is obtained, a one-way
-   hash value of the object is also included.  Integrity of this one-way
-   hash value is provided by the TLS Finished message.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support URLs that employ the http scheme.
-   Other schemes may also be supported; however, to avoid circular
-   dependencies, supported schemes SHOULD NOT themselves make use of
-   TLS, such as the https scheme.
-
-   Implementations that support either x509_attr_cert_url or
-   saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
-
-
-
-Brown & Housley                                                [Page 10]
-
-Internet-Draft                                                 June 2006
-
-
-   as one-way hash functions.  Other one-way hash functions may also be
-   supported.  Additional one-way hash functions can be registered in
-   the future using the procedures in section 3.
-
-4. IANA Considerations
-
-   This document defines a two TLS extensions: client_authz(TBD) and
-   server_authz(TBD).  These extension type values are assigned from the
-   TLS Extension Type registry defined in [TLSEXT].
-
-   This document defines one TLS supplemental data type:
-   authz_data(TBD).  This supplemental data type is assigned from the
-   TLS Supplemental Data Type registry defined in [TLSSUPP].
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Authorization Data Formats.  The first four entries in the
-   registry are x509_attr_cert(0), saml_assertion(1),
-   x509_attr_cert_url(2), and saml_assertion_url(3).  TLS Authorization
-   Data Format identifiers with values in the inclusive range 0-63
-   (decimal) are assigned via RFC 2434 [IANA] Standards Action.  Values
-   from the inclusive range 64-223 (decimal) are assigned via RFC 2434
-   Specification Required.  Values from the inclusive range 224-255
-   (decimal) are reserved for RFC 2434 Private Use.
-
-   This document establishes a new registry, to be maintained by IANA,
-   for TLS Hash Types.  The first two entries in the registry are
-   sha1(0) and sha256(1).  TLS Hash Type identifiers with values in the
-   inclusive range 0-158 (decimal) are assigned via RFC 2434 [IANA]
-   Standards Action.  Values from the inclusive range 159-223 (decimal)
-   are assigned via RFC 2434 Specification Required.  Values from the
-   inclusive range 224-255 (decimal) are reserved for RFC 2434 Private
-   Use.
-
-5. Security Considerations
-
-   A TLS server can support more than one application, and each
-   application may include several features, each of which requires
-   separate authorization checks.  This is the reason that more than one
-   piece of authorization information can be provided.
-
-   A TLS server that requires different authorization information for
-   different applications or different application features may find
-   that a client has provided sufficient authorization information to
-   grant access to a subset of these offerings.  In this situation the
-   TLS Handshake protocol will complete successfully; however, the
-   server must ensure that the client will only be able to use the
-   appropriate applications and application features.  That is, the TLS
-   server must deny access to the applications and application features
-
-
-
-Brown & Housley                                                [Page 11]
-
-Internet-Draft                                                 June 2006
-
-
-   for which authorization has not been confirmed.
-
-   In many cases, the authorization information is itself sensitive.
-   The double handshake technique can be used to provide protection for
-   the authorization information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   authorization extensions, but it does result in protected
-   communications.  Then, a second handshake that includes the
-   authorization information is performed using the protected
-   communications.  In Figure 2, the number on the right side indicates
-   the amount of protection for the TLS message on that line.  A zero
-   (0) indicates that there is no communication protection; a one (1)
-   indicates that protection is provided by the first TLS session; and a
-   two (2) indicates that protection is provided by both TLS sessions.
-
-   The placement of the SupplementalData message in the TLS Handshake
-   results in the server providing its authorization information before
-   the client is authenticated.  In many situations, servers will not
-   want to provide authorization information until the client is
-   authenticated.  The double handshake illustrated in Figure 2 provides
-   a technique to ensure that the parties are mutually authenticated
-   before either party provides authorization information.
-
-   The use of bearer SAML assertions allows an eavesdropper or a man-in-
-   the-middle to capture the SAML assertion and try to reuse it in
-   another context.  The constraints discussed in Section 3.3.2 might be
-   effective against an eavesdropper, but they are less likely to be
-   effective against a man-in-the-middle.  Authentication of both
-   parties in the TLS session, which involves the use of client
-   authentication, will prevent an undetected man-in the-middle, and the
-   use of the double handshake illustrated in Figure 2 will prevent the
-   disclosure of the bearer SAML assertion to any party other than the
-   TLS peer.
-
-6. Acknowledgement
-
-   The authors thank Scott Cantor for his assistance with the SAML
-   Assertion portion of the document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 12]
-
-Internet-Draft                                                 June 2006
-
-
-    Client                                                   Server
-
-    ClientHello (no extensions) -------->                            |0
-                                        ServerHello (no extensions)  |0
-                                                       Certificate*  |0
-                                                 ServerKeyExchange*  |0
-                                                CertificateRequest*  |0
-                                <--------           ServerHelloDone  |0
-    Certificate*                                                     |0
-    ClientKeyExchange                                                |0
-    CertificateVerify*                                               |0
-    [ChangeCipherSpec]                                               |0
-    Finished                    -------->                            |1
-                                                 [ChangeCipherSpec]  |0
-                                <--------                  Finished  |1
-    ClientHello (w/ extensions) -------->                            |1
-                                        ServerHello (w/ extensions)  |1
-                                  SupplementalData (w/ authz data)*  |1
-                                                       Certificate*  |1
-                                                 ServerKeyExchange*  |1
-                                                CertificateRequest*  |1
-                                <--------           ServerHelloDone  |1
-    SupplementalData (w/ authz data)*                                |1
-    Certificate*                                                     |1
-    ClientKeyExchange                                                |1
-    CertificateVerify*                                               |1
-    [ChangeCipherSpec]                                               |1
-    Finished                    -------->                            |2
-                                                 [ChangeCipherSpec]  |1
-                                <--------                  Finished  |2
-    Application Data            <------->          Application Data  |2
-
-         Figure 2. Double Handshake to Protect Authorization Data
-
-
-7. Normative References
-
-   [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
-                Certificate Profile for Authorization", RFC 3281,
-                April 2002.
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 13]
-
-Internet-Draft                                                 June 2006
-
-
-   [PKIX1]      Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                X.509 Public Key Infrastructure Certificate and
-                Certificate Revocation List (CRL) Profile", RFC 3280,
-                April 2002.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-                RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
-                (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
-
-   [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-                and T. Wright, "Transport Layer Security (TLS) Extensions",
-                RFC 3546, June 2003.
-
-   [TLSSUPP]    Santesson, S., " TLS Handshake Message for Supplemental
-                Data", work in progress: draft-santesson-tls-supp,
-                March 2006.
-
-   [SAML1.1]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 1.1
-                Specification Set", September 2003.
-
-   [SAML2.0]    OASIS Security Services Technical Committee, "Security
-                Assertion Markup Language (SAML) Version 2.0
-                Specification Set", March2005.
-
-   [SHA1]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.
-
-   [SHA2]       National Institute of Standards and Technology (NIST),
-                FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.
-
-   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 14]
-
-Internet-Draft                                                 June 2006
-
-
-Author's Address
-
-   Mark Brown
-   RedPhone Security
-   2019 Palace Avenue
-   Saint Paul, MN  55105
-   USA
-   mark <at> redphonesecurity <dot> com
-
-   Russell Housley
-   Vigil Security, LLC
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   housley <at> vigilsec <dot> com
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 15]
-
-Internet-Draft                                                 June 2006
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown & Housley                                                [Page 16]
diff --git a/doc/protocol/draft-ietf-netconf-tls-01.txt b/doc/protocol/draft-ietf-netconf-tls-01.txt
deleted file mode 100644
index 70efb526ba..0000000000
--- a/doc/protocol/draft-ietf-netconf-tls-01.txt
+++ /dev/null
@@ -1,485 +0,0 @@
-NETCONF Working Group                                     Mohamad Badra 
-Internet Draft                                         LIMOS Laboratory 
-Intended status: Standards Track                      February 15, 2008 
-Expires: August 2008 
-                                    
- 
-                                      
-                NETCONF over Transport Layer Security (TLS) 
-                       draft-ietf-netconf-tls-01.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on August 15, 2008. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2008). 
-
-Abstract 
-
-   The Network Configuration Protocol (NETCONF) provides mechanisms to 
-   install, manipulate, and delete the configuration of network devices.  
-   This document describes how to use the Transport Layer Protocol (TLS) 
-   to secure NETCONF exchanges. 
-
-
- 
- 
- 
-Badra                  Expires August 15, 2008                 [Page 1] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-Table of Contents 
-
-    
-   1. Introduction...................................................2 
-      1.1. Conventions used in this document.........................2 
-   2. NETCONF over TLS...............................................3 
-      2.1. Connection Initiation.....................................3 
-      2.2. Connection Closure........................................3 
-   3. Endpoint Authentication and Identification.....................4 
-      3.1. Server Identity...........................................4 
-      3.2. Client Identity...........................................5 
-      3.3. Password-Based Authentication.............................5 
-   4. Cipher Suite Requirements......................................7 
-   5. Security Considerations........................................7 
-   6. IANA Considerations............................................7 
-   7. Acknowledgments................................................7 
-   8. References.....................................................7 
-      8.1. Normative References......................................7 
-   Author's Addresses................................................8 
-   Intellectual Property Statement...................................8 
-   Disclaimer of Validity............................................9 
-    
-1. Introduction 
-
-   The NETCONF protocol [RFC4741] defines a simple mechanism through 
-   which a network device can be managed.  NETCONF is connection-
-   oriented, requiring a persistent connection between peers.  This 
-   connection must provide reliable, sequenced data delivery, integrity 
-   and confidentiality and peers authentication.  This document 
-   describes how to use TLS [RFC4346] to secure NETCONF connections. 
-
-   Throughout this document, the terms "client" and "server" are used to 
-   refer to the two ends of the TLS connection.  The client actively 
-   opens the TLS connection, and the server passively listens for the 
-   incoming TLS connection.  The terms "manager" and "agent" are used to 
-   refer to the two ends of the NETCONF protocol session.  The manager 
-   issues NETCONF remote procedure call (RPC) commands, and the agent 
-   replies to those commands.  When NETCONF is run over TLS using the 
-   mapping defined in this document, the client is always the manager, 
-   and the server is always the agent. 
-
-1.1. 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 [RFC2119]. 
-
- 
- 
-Badra                  Expires August 15, 2008                 [Page 2] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-2. NETCONF over TLS 
-
-   Since TLS is application protocol-independent, NETCONF can operate on 
-   top of the TLS protocol transparently.  This document defines how 
-   NETCONF can be used within a Transport Layer Security (TLS) session. 
-
-2.1. Connection Initiation 
-
-   The peer acting as the NETCONF manager MUST also act as the TLS 
-   client.  It MUST connect to the server that passively listens for the 
-   incoming TLS connection on the IANA-to-be-assigned TCP port <TBA>.  
-   It MUST therefore send the TLS ClientHello to begin the TLS 
-   handshake.  Once the TLS handshake has been finished, the client and 
-   the server MAY then send their NETCONF exchanges.  In particular, the 
-   client will send complete XML documents to the server containing 
-   <rpc> elements, and the server will respond with complete XML 
-   documents containing <rpc-reply> elements.  The client MAY indicate 
-   interest in receiving event notifications from a NETCONF server by 
-   creating a subscription to receive event notifications [NETNOT], in 
-   which the NETCONF server replies to indicate whether the subscription 
-   request was successful and, if it was successful, begins sending the 
-   event notifications to the NETCONF client as the events occur within 
-   the system.  All these elements are encapsulated into TLS records of 
-   type "application data".  These records are protected using the TLS 
-   material keys. 
-
-   Current NETCONF messages don't include a message's length.  This 
-   document uses consequently the same delimiter sequence defined in 
-   [RFC4742] and therefore the special character sequence, ]]>]]>, to 
-   delimit XML documents. 
-
-2.2. Connection Closure 
-
-   Either NETCONF peer MAY stop the NETCONF connection at any time and 
-   therefore notify the other NETCONF peer that no more data on this 
-   channel will be sent and that any data received after a closure 
-   request will be ignored.  This MAY happen when no data is received 
-   from a connection for a long time, where the application decides what 
-   "long" means. 
-
-   TLS has the ability for secure connection closure using the Alert 
-   protocol.  When the NETCONF peer processes a closure request of the 
-   NETCONF connection, it MUST send a TLS close_notify alert before 
-   closing the connection.  Any data received after a closure alert is 
-   ignored. 
-
-
- 
- 
-Badra                  Expires August 15, 2008                 [Page 3] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-   Unless some other fatal alert has been transmitted, each party is 
-   required to send a close_notify alert before closing the write side 
-   of the connection.  The other party MUST respond with a close_notify 
-   alert of its own and close down the connection immediately, 
-   discarding any pending writes.  It is not required for the initiator 
-   of the close to wait for the responding close_notify alert before 
-   closing the read side of the connection. 
-
-3. Endpoint Authentication and Identification 
-
-   NETCONF requires that its transport provide mutual authentication of 
-   client and server, so cipher suites that are anonymous or which only 
-   authenticate the server to the client MUST NOT be used with NETCONF.  
-   This document specifies how to use TLS with endpoint authentication 
-   in TLS can be based on either preshared keys [RFC4279] or public key 
-   certificates [RFC4346].  Some cipher suites (e.g. 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both.  Section 3.1 describes 
-   how the client authenticates the server if public key certificates 
-   are provided by the server, section 3.2 describes how the server 
-   authenticates the client if public key certificates are provided by 
-   the client, and section 3.3 describes how the client and server 
-   mutually authenticate one another using a password. 
-
-3.1. Server Identity 
-
-   During the TLS negotiation, the client MUST carefully examine the 
-   certificate presented by the server to determine if it meets their 
-   expectations.  Particularly, the client MUST check its understanding 
-   of the server hostname against the server's identity as presented in 
-   the server Certificate message, in order to prevent man-in-the-middle 
-   attacks. 
-
-   Matching is performed according to these rules [RFC4642]: 
-
-      - The client MUST use the server hostname it used to open the 
-        connection (or the hostname specified in TLS "server_name" 
-        extension [RFC4366]) as the value to compare against the server 
-        name as expressed in the server certificate.  The client MUST 
-        NOT use any form of the server hostname derived from an 
-        insecure remote source (e.g., insecure DNS lookup).  CNAME 
-        canonicalization is not done. 
-
-      - If a subjectAltName extension of type dNSName is present in the 
-        certificate, it MUST be used as the source of the server's 
-        identity. 
-
-      - Matching is case-insensitive. 
- 
- 
-Badra                  Expires August 15, 2008                 [Page 4] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-      - A "*" wildcard character MAY be used as the left-most name 
-        component in the certificate.  For example, *.example.com would 
-        match a.example.com, foo.example.com, etc., but would not match 
-        example.com. 
-
-      - If the certificate contains multiple names (e.g., more than one 
-        dNSName field), then a match with any one of the fields is 
-        considered acceptable. 
-
-   If the match fails, the client MUST either ask for explicit user 
-   confirmation or terminate the connection and indicate the server's 
-   identity is suspect. 
-
-   Additionally, clients MUST verify the binding between the identity of 
-   the servers to which they connect and the public keys presented by 
-   those servers.  Clients SHOULD implement the algorithm in Section 6 
-   of [RFC3280] for general certificate validation, but MAY supplement 
-   that algorithm with other validation methods that achieve equivalent 
-   levels of verification (such as comparing the server certificate 
-   against a local store of already-verified certificates and identity 
-   bindings). 
-
-   If the client has external information as to the expected identity of 
-   the server, the hostname check MAY be omitted. 
-
-3.2. Client Identity 
-
-   Typically, the server has no external knowledge of what the client's 
-   identity ought to be and so checks (other than that the client has a 
-   certificate chain rooted in an appropriate CA) are not possible.  If 
-   a server has such knowledge (typically from some source external to 
-   NETCONF or TLS) it MUST check the identity as described above. 
-
-3.3. Password-Based Authentication 
-
-   [RFC4279] supports authentication based on pre-shared keys (PSKs).  
-   These pre-shared keys are symmetric keys, shared in advance among the 
-   communicating parties. 
-
-   The PSK can be generated in many ways and its length is variable.  
-   Implementation of this document MAY rely on [RFC4279] to enable 
-   password based user authentication.  In this case, the password is 
-   used to generate the PSK.  It is RECOMMENDED that implementations 
-   that allow the administrator to manually configure the password also 
-   provide functionality for generating a new random password, taking 
-   [RFC4086] into account. 
-
- 
- 
-Badra                  Expires August 15, 2008                 [Page 5] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-   This document generates the PSK from the password as follow: 
-
-    PSK = SHA-1(SHA-1(password + psk_identity + "Key Pad for Netconf") +  
-                psk_identity_hint)  
-
-   Where + means concatenation.  
-
-   The label "Key Pad for Netconf" is an ASCII string.  
-
-   The psk_identity_hint is initially defined in section 5.1 of 
-   [RFC4279].  The psk_identity_hint can do double duty and also provide 
-   a form of server authentication in the case where the user has the 
-   same password on a number of NETCONF servers.  If a hint is provided, 
-   the psk_identity_hint is encoded in the same way as in [RFC4279] and 
-   should be a string representation of the name of the server 
-   recognizable to the administrator or his software.  In the case where 
-   the user types a server name to connect to, it should be that string.  
-   If the string the user enters differs from the one returned as 
-   psk_identity_hint, the software could display the server's name and 
-   ask the user to confirm.  For automated scripts, the names could be 
-   expected to match.  It is highly recommended that implementations set 
-   the psk_identity_hint to the DNS name of the NETCONF server (i.e., 
-   the TLS server). 
-
-   It is RECOMMENDED that users choose different passwords for the 
-   different servers they manage. 
-
-      Note 1: The NETCONF over TLS implementation need not store the 
-      password in clear text, but rather can store the value of SHA-
-      1(SHA-1(password + psk_identity + "Key Pad for Netconf") + 
-      psk_identity_hint), which could not be used as a password 
-      equivalent for applications other than NETCONF.  Deriving the PSK 
-      from a password is not secure.  This construction is used because 
-      it is anticipated that people will do it anyway. 
-
-      Note 2: [RFC4279] defines some conformance requirements for the 
-      PSK, for the PSK identity encoding and for the identity hint. The 
-      same requirements apply here as well; in particular on the 
-      password.  Moreover, the management interface by which the 
-      password is provided MUST accept ASCII strings of at least 64 
-      octets and MUST NOT add a null terminator before using them as 
-      shared secrets.  It MUST also accept a HEX encoding of the 
-      password.  The management interface MAY accept other encodings if 
-      the algorithm for translating the encoding to a binary string is 
-      specified. 
-
-
- 
- 
-Badra                  Expires August 15, 2008                 [Page 6] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-4. Cipher Suite Requirements 
-
-   A compliant implementation of the protocol specified in this document 
-   MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and 
-   MAY implement any TLS cipher suite that provides mutual 
-   authentication. 
-
-5. Security Considerations 
-
-   The security considerations described throughout [RFC4346] and 
-   [RFC4279] apply here as well. 
-
-   As with all schemes involving shared keys and passwords, special care 
-   should be taken to protect the shared values and passwords as well as 
-   to limit their exposure over time.  Alternatively, using certificates 
-   would provide better protection. 
-
-6. IANA Considerations 
-
-   IANA is requested to assign a TCP port number that will be the 
-   default port for NETCONF over TLS sessions as defined in this 
-   document. 
-
-   IANA has assigned port <TBA> for this purpose. 
-
-7. Acknowledgments 
-
-   A significant amount of the text in this document was lifted from 
-   [RFC4642]. 
-
-   The author would like to acknowledge David Harrington, Miao Fuyou, 
-   Eric Rescorla, Juergen Schoenwaelder and the NETCONF mailing list 
-   members for their comments on the document.  The author appreciates 
-   also Bert Wijnen and Dan Romascanu for their efforts on issues 
-   resolving discussion, and Charlie Kaufman for the thorough review of 
-   this document and for the helpful comments on the password-based 
-   authentication. 
-
-8. References 
-
-8.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-
-
- 
- 
-Badra                  Expires August 15, 2008                 [Page 7] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-   [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 
-             X.509 Public Key Infrastructure Certificate and Certificate 
-             Revocation List (CRL) Profile", RFC 3280, April 2002. 
-
-   [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 
-             "Randomness Requirements for Security", BCP 106, RFC 4086, 
-             June 2005. 
-
-   [RFC4279] Eronen, P. and H. Tschofenig., "Pre-Shared Key Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005. 
-
-   [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 
-             (TLS) Protocol 1.1", RFC 4346, April 2006. 
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 
-             and T. Wright, "Transport Layer Security (TLS) Extensions", 
-             RFC 4366, April 2006. 
-
-   [RFC4642] Murchison, K., Vinocur, J., Newman, C., "Using Transport 
-             Layer Security (TLS) with Network News Transfer Protocol 
-             (NNTP)", RFC 4642, October 2006 
-
-   [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 
-             December 2006. 
-
-   [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 
-             Configuration Protocol over Secure Shell (SSH)", RFC 4742, 
-             December 2006. 
-
-   [NETNOT]  Chisholm, S. and H. Trevino, "NETCONF Event Notifications", 
-             draft-ietf-netconf-notification-11.txt, (work in progress), 
-             November 2007. 
-
-Author's Addresses 
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-       
-   Email: badra@isima.fr 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
- 
- 
-Badra                  Expires August 15, 2008                 [Page 8] 
-
-Internet-Draft             NETCONF over TLS               February 2008 
-    
-
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2008). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
- 
- 
-Badra                  Expires August 15, 2008                 [Page 9] 
-
diff --git a/doc/protocol/draft-ietf-netconf-tls-02.txt b/doc/protocol/draft-ietf-netconf-tls-02.txt
deleted file mode 100644
index 2c37fa6a81..0000000000
--- a/doc/protocol/draft-ietf-netconf-tls-02.txt
+++ /dev/null
@@ -1,809 +0,0 @@
-NETCONF Working Group                                     Mohamad Badra 
-Internet Draft                                         LIMOS Laboratory 
-Intended status: Standards Track                           May 27, 2008 
-Expires: November 2008 
-                                    
- 
-                                      
-                NETCONF over Transport Layer Security (TLS) 
-                       draft-ietf-netconf-tls-02.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on November 27, 2008. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2008). 
-
-Abstract 
-
-   The Network Configuration Protocol (NETCONF) provides mechanisms to 
-   install, manipulate, and delete the configuration of network devices.  
-   This document describes how to use the Transport Layer Protocol (TLS) 
-   to secure NETCONF exchanges. 
-
-
- 
- 
- 
-Badra                 Expires November 27, 2008                [Page 1] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-Table of Contents 
-
-    
-   1. Introduction...................................................3 
-      1.1. Conventions used in this document.........................3 
-   2. NETCONF over TLS...............................................3 
-      2.1. Connection Initiation.....................................3 
-      2.2. Connection Closure........................................4 
-   3. Endpoint Authentication and Identification.....................4 
-      3.1. Server Identity...........................................5 
-      3.2. Client Identity...........................................6 
-      3.3. Password-Based Authentication.............................6 
-   4. Cipher Suite Requirements......................................7 
-   5. Security Considerations........................................7 
-   6. IANA Considerations............................................7 
-   7. Acknowledgments................................................8 
-   A. Appendix - Test Vectors for the PSK Derivation Function........9 
-   B. Appendix - Enabling Third Party Authentication using Passwords10 
-      B.1. Working Group discussion at the 71st IETF meeting........12 
-   Normative References.............................................13 
-   Authors' Addresses...............................................14 
-   Intellectual Property and Copyright Statements...................14 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                 Expires November 27, 2008                [Page 2] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-1. Introduction 
-   The NETCONF protocol [RFC4741] defines a simple mechanism through 
-   which a network device can be managed.  NETCONF is connection-
-   oriented, requiring a persistent connection between peers.  This 
-   connection must provide reliable, sequenced data delivery, integrity 
-   and confidentiality and peers authentication.  This document 
-   describes how to use TLS [RFC4346] to secure NETCONF connections. 
-
-   Throughout this document, the terms "client" and "server" are used to 
-   refer to the two ends of the TLS connection.  The client actively 
-   opens the TLS connection, and the server passively listens for the 
-   incoming TLS connection.  The terms "manager" and "agent" are used to 
-   refer to the two ends of the NETCONF protocol session.  The manager 
-   issues NETCONF remote procedure call (RPC) commands, and the agent 
-   replies to those commands.  When NETCONF is run over TLS using the 
-   mapping defined in this document, the client is always the manager, 
-   and the server is always the agent. 
-
-1.1. 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 [RFC2119]. 
-
-2. NETCONF over TLS 
-
-   Since TLS is application protocol-independent, NETCONF can operate on 
-   top of the TLS protocol transparently.  This document defines how 
-   NETCONF can be used within a Transport Layer Security (TLS) session. 
-
-2.1. Connection Initiation 
-
-   The peer acting as the NETCONF manager MUST also act as the TLS 
-   client.  It MUST connect to the server that passively listens for the 
-   incoming TLS connection on the IANA-to-be-assigned TCP port <TBA>.  
-   It MUST therefore send the TLS ClientHello to begin the TLS 
-   handshake.  Once the TLS handshake has been finished, the client and 
-   the server MAY then send their NETCONF exchanges.  In particular, the 
-   client will send complete XML documents to the server containing 
-   <rpc> elements, and the server will respond with complete XML 
-   documents containing <rpc-reply> elements.  The client MAY indicate 
-   interest in receiving event notifications from a NETCONF server by 
-   creating a subscription to receive event notifications [I-D.ietf--
-   netconf-notification], in which the NETCONF server replies to 
-   indicate whether the subscription request was successful and, if it 
-   was successful, begins sending the event notifications to the NETCONF 
-   client as the events occur within the system.  All these elements are 
- 
- 
-Badra                 Expires November 27, 2008                [Page 3] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-   encapsulated into TLS records of type "application data".  These 
-   records are protected using the TLS material keys. 
-
-   Current NETCONF messages don't include a message's length.  This 
-   document uses consequently the same delimiter sequence defined in 
-   [RFC4742] and therefore the special character sequence, ]]>]]>, to 
-   delimit XML documents. 
-
-2.2. Connection Closure 
-
-   Either NETCONF peer MAY stop the NETCONF connection at any time and 
-   therefore notify the other NETCONF peer that no more data on this 
-   channel will be sent and that any data received after a closure 
-   request will be ignored.  This MAY happen when no data is received 
-   from a connection for a long time, where the application decides what 
-   "long" means. 
-
-   TLS has the ability for secure connection closure using the Alert 
-   protocol.  When the NETCONF peer closes the NETCONF connection, it 
-   MUST send a TLS close_notify alert before closing the TCP connection.  
-   Any data received after a closure alert is ignored. 
-
-   Unless a fatal error has occurred, each party is required to send a 
-   close_notify alert before closing the write side of the connection 
-   [RFC4346].  The other party MUST respond with a close_notify alert of 
-   its own and close down the connection immediately, discarding any 
-   pending writes.  It is not required for the initiator of the close to 
-   wait for the responding close_notify alert before closing the read 
-   side of the connection. 
-
-3. Endpoint Authentication and Identification 
-
-   NETCONF requires that its transport provide mutual authentication of 
-   client and server, so cipher suites that are anonymous or which only 
-   authenticate the server to the client MUST NOT be used with NETCONF.  
-   This document specifies how to use TLS with endpoint authentication, 
-   which can be based on either preshared keys [RFC4279] or public key 
-   certificates [RFC4346].  Some cipher suites (e.g. 
-   TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both.  Section 3.1 describes 
-   how the client authenticates the server if public key certificates 
-   are provided by the server, section 3.2 describes how the server 
-   authenticates the client if public key certificates are provided by 
-   the client, and section 3.3 describes how the client and server 
-   mutually authenticate one another using a password. 
-
-
-
- 
- 
-Badra                 Expires November 27, 2008                [Page 4] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-3.1. Server Identity 
-
-   During the TLS negotiation, the client MUST carefully examine the 
-   certificate presented by the server to determine if it meets their 
-   expectations.  Particularly, the client MUST check its understanding 
-   of the server hostname against the server's identity as presented in 
-   the server Certificate message, in order to prevent man-in-the-middle 
-   attacks. 
-
-   Matching is performed according to these rules [RFC4642]: 
-
-      - The client MUST use the server hostname it used to open the 
-        connection (or the hostname specified in TLS "server_name" 
-        extension [RFC4366]) as the value to compare against the server 
-        name as expressed in the server certificate.  The client MUST 
-        NOT use any form of the server hostname derived from an 
-        insecure remote source (e.g., insecure DNS lookup).  CNAME 
-        canonicalization is not done. 
-
-      - If a subjectAltName extension of type dNSName is present in the 
-        certificate, it MUST be used as the source of the server's 
-        identity. 
-
-      - Matching is case-insensitive. 
-
-      - A "*" wildcard character MAY be used as the left-most name 
-        component in the certificate.  For example, *.example.com would 
-        match a.example.com, foo.example.com, etc., but would not match 
-        example.com. 
-
-      - If the certificate contains multiple names (e.g., more than one 
-        dNSName field), then a match with any one of the fields is 
-        considered acceptable. 
-
-   If the match fails, the client MUST either ask for explicit user 
-   confirmation or terminate the connection and indicate the server's 
-   identity is suspect. 
-
-   Additionally, clients MUST verify the binding between the identity of 
-   the servers to which they connect and the public keys presented by 
-   those servers.  Clients SHOULD implement the algorithm in Section 6 
-   of [RFC5280] for general certificate validation, but MAY supplement 
-   that algorithm with other validation methods that achieve equivalent 
-   levels of verification (such as comparing the server certificate 
-   against a local store of already-verified certificates and identity 
-   bindings). 
-
- 
- 
-Badra                 Expires November 27, 2008                [Page 5] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-   If the client has external information as to the expected identity of 
-   the server, the hostname check MAY be omitted. 
-
-3.2. Client Identity 
-
-   Typically, the server has no external knowledge of what the client's 
-   identity ought to be and so checks (other than that the client has a 
-   certificate chain rooted in an appropriate CA) are not possible.  If 
-   a server has such knowledge (typically from some source external to 
-   NETCONF or TLS) it MUST check the identity as described above. 
-
-3.3. Password-Based Authentication 
-
-   [RFC4279] supports authentication based on pre-shared keys (PSKs).  
-   These pre-shared keys are symmetric keys, shared in advance among the 
-   communicating parties. 
-
-   The PSK can be generated in many ways and its length is variable.  
-   Implementation of this document MAY rely on [RFC4279] to enable 
-   password based user authentication.  In this case, the password is 
-   used to generate the PSK.  It is RECOMMENDED that implementations 
-   that allow the administrator to manually configure the password also 
-   provide functionality for generating a new random password, taking 
-   [RFC4086] into account. 
-
-   This document generates the PSK from the password as follow: 
-
-    PSK = SHA-1(SHA-1(psk_identity + "Key Pad for Netconf" + password) +  
-                psk_identity_hint)  
-
-   Where + means concatenation.  
-
-   The label "Key Pad for Netconf" is an ASCII string.  
-
-   The psk_identity_hint is initially defined in section 5.1 of 
-   [RFC4279].  The psk_identity_hint can do double duty and also provide 
-   a form of server authentication in the case where the user has the 
-   same password on a number of NETCONF servers.  If a hint is provided, 
-   the psk_identity_hint is encoded in the same way as in [RFC4279] and 
-   should be a string representation of the name of the server 
-   recognizable to the administrator or his software.  In the case where 
-   the user types a server name to connect to, it should be that string.  
-   If the string the user enters differs from the one returned as 
-   psk_identity_hint, the software could display the server's name and 
-   ask the user to confirm.  For automated scripts, the names could be 
-   expected to match.  It is highly recommended that implementations set 
-
- 
- 
-Badra                 Expires November 27, 2008                [Page 6] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-   the psk_identity_hint to the DNS name of the NETCONF server (i.e., 
-   the TLS server). 
-
-   It is RECOMMENDED that users choose different passwords for the 
-   different servers they manage. 
-
-      Note 1: The NETCONF over TLS implementation need not store the 
-      password in clear text, but rather can store the value of the 
-      inner SHA-1 (SHA-1(SHA-1(password + psk_identity + "Key Pad for 
-      Netconf") + psk_identity_hint)), which could not be used as a 
-      password equivalent for applications other than NETCONF.  Deriving 
-      the PSK from a password is not secure.  This construction is used 
-      because it is anticipated that people will do it anyway. 
-
-      Note 2: [RFC4279] defines some conformance requirements for the 
-      PSK, for the PSK identity encoding and for the identity hint. The 
-      same requirements apply here as well; in particular on the 
-      password.  Moreover, the management interface by which the 
-      password is provided MUST accept ASCII strings of at least 64 
-      octets and MUST NOT add a null terminator before using them as 
-      shared secrets.  It MUST also accept a HEX encoding of the 
-      password.  The management interface MAY accept other encodings if 
-      the algorithm for translating the encoding to a binary string is 
-      specified. 
-
-4. Cipher Suite Requirements 
-
-   A compliant implementation of the protocol specified in this document 
-   MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and 
-   MAY implement any TLS cipher suite that provides mutual 
-   authentication.  
-
-5. Security Considerations 
-
-   The security considerations described throughout [RFC4346] and 
-   [RFC4279] apply here as well. 
-
-   As with all schemes involving shared keys and passwords, special care 
-   should be taken to protect the shared values and passwords as well as 
-   to limit their exposure over time.  Alternatively, using certificates 
-   would provide better protection. 
-
-6. IANA Considerations 
-
-   IANA is requested to assign a TCP port number that will be the 
-   default port for NETCONF over TLS sessions as defined in this 
-   document. 
- 
- 
-Badra                 Expires November 27, 2008                [Page 7] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-   IANA has assigned port <TBA> for this purpose. 
-
-7. Acknowledgments 
-
-   A significant amount of the text in Section 3.1 was lifted from 
-   [RFC4642]. 
-
-   The author would like to acknowledge David Harrington, Miao Fuyou, 
-   Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier 
-   Coupelon and the NETCONF mailing list members for their comments on 
-   the document.  The author appreciates also Bert Wijnen, Mehmet Ersue 
-   and Dan Romascanu for their efforts on issues resolving discussion, 
-   and Charlie Kaufman for the thorough review of this document and for 
-   the helpful comments on the password-based authentication. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                 Expires November 27, 2008                [Page 8] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-A. Appendix - Test Vectors for the PSK Derivation Function 
-
-   The test vectors for the PSK derivation function in this document 
-   have been cross-verified by two independent implementations.  An 
-   implementation that concurs with the results provided in this 
-   document should be interoperable with other similar implementations. 
-
-         password = password 
-         psk_identity = psk_identity 
-         psk_identity_hint = psk_identity_hint 
-
-         The inner SHA-1 value (in hex): 
-
-         inner := SHA-1(password + psk_identity + "Key Pad for Netconf") 
-               == SHA-1("psk_identityKey Pad for Netconfpassword") 
-               => 6d6eeb6a b8d0466b 45245d07 47d86726 b41b868c 
-
-         The outer SHA-1 value (in hex): 
-
-         outer := SHA-1(inner + psk_identity_hint) 
-               => 88f3824b 3e5659f5 2d00e959 bacab954 b6540344 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                 Expires November 27, 2008                [Page 9] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-B. Appendix - Enabling Third Party Authentication using Passwords 
-
-   During the 71st IETF meeting, several proposals have been proposed to 
-   enable third party authentication that could be used in combination 
-   with existing user authentication databases such as RADIUS. They are 
-   listed below. More details on those proposals may be found at 
-   https://www3.ietf.org/proceedings/08mar/slides/netconf-1/netconf-
-   1.htm and 
-   http://www.psg.com/lists/netconf/netconf.2008/msg00125.html. 
-
-   We summarize them as following: 
-
-   1. Defining <user-login> RPC: 
-      -------------------------- 
-
-     This option relies on JUNOS mechanism to enable an authentication 
-     function via third parties. It consists of establishing a TLS with 
-     no manager authentication, leaving the <request-login> RPC as the 
-     only valid RPC.  Anything else is an error. 
-
-     Once the TLS session is established, the agent MUST authenticate 
-     the manager by emitting the following <rpc> tag element:  
-
-         <rpc-reply message-id="101" 
-            xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
-              <challenge>Password:</challenge> 
-         </rpc-reply> 
-
-       In which the manager MUST reply with the following: 
-
-         <rpc> 
-            <request-login> 
-               <challenge-response>password</challenge-response> 
-            </request-login> 
-         </rpc> 
-
-     The rules to handle this were pretty simple: 
-
-        - The <request-login> RPC could only be performed if the session 
-          wasn't authenticated. 
-
-        - No other RPCs could be performed if the session wasn't  
-          authenticated. 
-
-        - The transport protocol can authenticate the session  
-          (internally). 
-
- 
- 
-Badra                 Expires November 27, 2008               [Page 10] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-          
-
-     Pros and cons: 
-
-     o   is simple to do. But 
-
-     o   might raise questions from the security ADs; NETCONF assumes  
-         the authentication is part of the transport not NETCONF. 
-
-     o   only works for plaintext passwords (SASL PLAIN). 
-
-   2. Enhancing TLS:  
-      -------------- 
-
-     The second option consists of extending TLS so the manager 
-     authentication becomes part of TLS. This extension, detailed in 
-     http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt, 
-     defines a new extension and a new TLS message to the TLS protocol 
-     to enable TLS client authentication using passwords. The extension 
-     is used to convey the manager login, whereas the new message is 
-     defined and sent by the manager to prove its knowledge of the 
-     password. 
-
-     Steps during the TLS negotiation: 
-
-         - The manager adds such an extension to its TLS ClientHello. 
-
-         - If the agent agrees on using this extension, it will notify  
-           the manager and replies with its certificate and/or its  
-           authenticated public key. 
-
-         - The manager generates a premaster secret and encrypts it  
-           using the agent public key. 
-
-         - The manager then computes the session key using the premaster  
-           secret and encrypts, among others, its password with the  
-           computed key. 
-
-         - The agent decrypts the premaster secret and computes the same  
-           key to decrypt the password. 
-
-         - The agent checks with a database (or AAA infrastructures) to  
-           verify the password and then to authenticate the manager. 
-
-     Pros and cons 
-
-     o   is simple to do. But 
- 
- 
-Badra                 Expires November 27, 2008               [Page 11] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-     o   It is indeed not easy to convince TLS WG to add password  
-         authentication extension to TLS. 
-
-   3. Running BEEP over TLS:  
-      ---------------------- 
-
-     It looks complex for a solution, requires that all implementations 
-     do actually support BEEP. 
-
-   4. Extending NETCONF with a message to start TLS:  
-      ---------------------------------------------- 
-
-     This option consists of extending NETCONF with a new message to 
-     start the TLS negotiation and to perform an authentication 
-     mechanism based on RFC4422 (SASL) or on any similar protocol. 
-
-       Pros and cons 
-
-       o   simple to do. But 
-
-       o   might raise questions from the security ADs; NETCONF assumes  
-           the authentication is part of the transport not NETCONF.  
-           Moreover, it adds complexity related to the use of SASL  
-           PLAIN. 
-
-   5. Enable SSH (RFC4742 and TLS (as defined through this document:  
-      -------------------------------------------------------------- 
-
-     Since SSH already defines a password-based authentication and 
-     because this protocol MUST be implemented as a security protocol 
-     for NETCONF, users can rely on SSH for password authentication, and 
-     on TLS for authentication using PSK or certificates. This means the 
-     agent SHOULD passively listen for the incoming SSH (respectively 
-     TLS) connection on port 830 (respectively port <TBA-by-IANA>). 
-
-       Pros and cons 
-
-       o   simple to do. 
-
-       o   already specified by RFC4742 and by the current document.  
-
-B.1. Working Group discussion at the 71st IETF meeting 
-
-   Some of the options have been found as not practical in the WG 
-   session during 71st meeting. 
-
-   Options #2 and #3 have not been supported in the WG session.  
- 
- 
-Badra                 Expires November 27, 2008               [Page 12] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-   Option #1 and # 4 seems to be against the security design for 
-   NETCONF. Whether #5 or other options can be accepted by the WG 
-   members needs to be discussed on the mailing list. 
-
-Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 
-             Housley, R., and W. Polk, "Internet X.509 Public Key 
-             Infrastructure Certificate and Certificate Revocation List 
-             (CRL) Profile", RFC 5280, May 2008. 
-
-   [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 
-             "Randomness Requirements for Security", BCP 106, RFC 4086, 
-             June 2005. 
-
-   [RFC4279] Eronen, P. and H. Tschofenig., "Pre-Shared Key Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005. 
-
-   [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 
-             (TLS) Protocol 1.1", RFC 4346, April 2006. 
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 
-             and T. Wright, "Transport Layer Security (TLS) Extensions", 
-             RFC 4366, April 2006. 
-
-   [RFC4642] Murchison, K., Vinocur, J., Newman, C., "Using Transport 
-             Layer Security (TLS) with Network News Transfer Protocol 
-             (NNTP)", RFC 4642, October 2006 
-
-   [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 
-             December 2006. 
-
-   [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 
-             Configuration Protocol over Secure Shell (SSH)", RFC 4742, 
-             December 2006. 
-
-   [I-D.ietf-netconf-notification]      
-             Chisholm, S. and H. Trevino, "NETCONF Event Notifications", 
-             draft-ietf-netconf-notification-12.txt, (work in progress), 
-             February 2008. 
-
-
-
- 
- 
-Badra                 Expires November 27, 2008               [Page 13] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-Authors' Addresses 
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-       
-   Email: badra@isima.fr 
-
-Contributors 
-
-   Ibrahim Hajjeh 
-   INEOVATION 
-   France 
-       
-   Email: hajjeh@ineovation.com 
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
- 
- 
-Badra                 Expires November 27, 2008               [Page 14] 
-
-Internet-Draft             NETCONF over TLS                    May 2008 
-    
-
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2008). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
- 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                 Expires November 27, 2008               [Page 15] 
-
diff --git a/doc/protocol/draft-ietf-tls-56-bit-ciphersuites-01.txt b/doc/protocol/draft-ietf-tls-56-bit-ciphersuites-01.txt
deleted file mode 100644
index 7a8dd97dcb..0000000000
--- a/doc/protocol/draft-ietf-tls-56-bit-ciphersuites-01.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Transport Layer Security Working Group                        John Banes
-INTERNET-DRAFT                                     Microsoft Corporation
-Expires January, 2002                                 Richard Harrington
-                                                      Qpass Incorporated
-                                                           July 19, 2001
-
-                   56-bit Export Cipher Suites For TLS
-                draft-ietf-tls-56-bit-ciphersuites-01.txt
-
-1.  Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions 
-   of Section 10 of RFC2026. Internet-Drafts are working documents of 
-   the Internet Engineering Task Force (IETF), its areas, and its 
-   working groups.  Note that other groups may also distribute
-   working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or made obsolete 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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-2.  Introduction
-
-   This document describes several cipher suites to be used with the 
-   Transport Layer Security (TLS) protocol.  Changes in US export
-   regulations in 1999 permitted the export of software programs 
-   using 56-bit data encryption and 1024-bit key exchange.  
-   The cipher suites described in this document were designed to take
-   advantage of this change in the regulations.
-
-3. The CipherSuites
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   The following CipherSuite definitions require that the server
-   provide an RSA certificate that can be used for key exchange. The
-   server may request either an RSA or a DSS signature-capable
-   certificate in the certificate request message.
-
-   CipherSuite TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA     = { 0x00,0x62 };
-   CipherSuite TLS_RSA_EXPORT1024_WITH_RC4_56_SHA      = { 0x00,0x64 };
-
-
-Banes                      Expires January, 2002              [Page 1]
-INTERNET-DRAFT             56-bit Export TLS          January 15, 1999
-
-
-   The following CipherSuite definitions are used for
-   server-authenticated (and optionally client-authenticated)
-   Diffie-Hellman.  DHE denotes ephemeral Diffie-Hellman, where the
-   Diffie-Hellman parameters are signed by a DSS certificate, which
-   has been signed by the CA. 
-
-   CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x63 };
-   CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA  = { 0x00,0x65 };
-   CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA            = { 0x00,0x66 };
-
-
-4. CipherSuite definitions
-
-CipherSuite                        Is         Key            Cipher  Hash
-                               Exportable   Exchange
-
-TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA     * RSA_EXPORT1024     DES_CBC  SHA
-TLS_RSA_EXPORT1024_WITH_RC4_56_SHA      * RSA_EXPORT1024     RC4_56   SHA
-TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA * RSA_EXPORT1024     DES_CBC  SHA
-TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA  * DHE_DSS_EXPORT1024 RC4_56   SHA
-TLS_DHE_DSS_WITH_RC4_128_SHA              DHE_DSS            RC4_128  SHA
-
-* Indicates IsExportable is True
-
-      Key
-      Exchange
-      Algorithm           Description                        Key size limit
-      
-      RSA_EXPORT1024      RSA key exchange                   RSA = 1024 bits
-      DHE_DSS_EXPORT1024  Ephemeral DH with DSS signatures   DH = 1024 bits
-
-   Key size limit
-       The key size limit gives the size of the largest public key that
-       can be legally used for encryption in cipher suites that are
-       exportable.
-
-                         Key      Expanded   Effective   IV    Block
-    Cipher       Type  Material Key Material  Key Bits  Size   Size
-    
-    RC4_56       Stream   7         16          56        0     N/A
-    DES_CBC      Block    8          8          56        8      8
-
-
-5. Implementation Notes
-
-   When an RSA_EXPORT1024 cipher suite is used, and the server's RSA
-   Key is larger than 1024 bits in length, then the server must send
-   a server key exchange message to the client. This message is to
-   contain a temporary RSA key, signed by the server. This temporary
-   RSA key should be the maximum allowable length (i.e., 1024 bits).
-
-
-Banes                      Expires January, 2002              [Page 2]
-INTERNET-DRAFT             56-bit Export TLS          January 15, 1999
-
-
-   Servers with a large RSA key will often maintain two temporary RSA
-   keys: a 512-bit key used to support the RSA_EXPORT cipher suites,
-   and a 1024-bit key used to support the RSA_EXPORT1024 cipher suites.
-
-   When 56-bit DES keys are derived for an export cipher suite, the
-   additional export key derivation step must be performed. That is,
-   the final read and write DES keys (and the IV) are not taken 
-   directly from the key_block.
-
-6. References
-
-   [TLS] T. Dierks, C. Allen, The TLS Protocol, 
-   <draft-ietf-tls-protocol-06.txt>, November 1998.
-
-7. Authors
-
-   John Banes                         Richard Harrington
-   Microsoft Corp.                    Qpass Inc.
-   jbanes@microsoft.com               rharrington@qpass.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Banes                      Expires January, 2002              [Page 3]
diff --git a/doc/protocol/draft-ietf-tls-ctr-01.txt b/doc/protocol/draft-ietf-tls-ctr-01.txt
deleted file mode 100644
index 59752fd3fa..0000000000
--- a/doc/protocol/draft-ietf-tls-ctr-01.txt
+++ /dev/null
@@ -1,561 +0,0 @@
-
-
-
-Network Working Group                                        N. Modadugu
-Internet-Draft                                       Stanford University
-Expires: December 15, 2006                                   E. Rescorla
-                                                       Network Resonance
-                                                           June 13, 2006
-
-
-            AES Counter Mode Cipher Suites for TLS and DTLS
-                       draft-ietf-tls-ctr-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes the use of the Advanced Encryption Standard
-   (AES) Counter Mode for use as a Transport Layer Security (TLS) and
-   Datagram Transport Layer Security (DTLS) confidentiality mechanism.
-
-
-
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 1]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Conventions Used In This Document  . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Encrypting Records with AES Counter Mode . . . . . . . . . . .  4
-     3.1.  TLS  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-       3.1.1.  Encryption . . . . . . . . . . . . . . . . . . . . . .  4
-       3.1.2.  Decryption . . . . . . . . . . . . . . . . . . . . . .  5
-       3.1.3.  Counter Block Construction . . . . . . . . . . . . . .  5
-     3.2.  DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-     3.3.  Padding  . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     3.4.  Session Resumption . . . . . . . . . . . . . . . . . . . .  7
-   4.  Design Rationale . . . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-     5.1.  Maximum Key Lifetime . . . . . . . . . . . . . . . . . . .  8
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
-   Intellectual Property and Copyright Statements . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 2]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-1.  Introduction
-
-   Transport Layer Security [3] provides channel-oriented security for
-   application layer protocols.  In TLS, cryptographic algorithms are
-   specified in "Cipher Suites, which consist of a group of algorithms
-   to be used together."
-
-   Cipher suites supported by TLS are divided into stream and block
-   ciphers.  Counter mode ciphers behave like stream ciphers, but are
-   constructed based on a block cipher primitive (that is, counter mode
-   operation of a block cipher results in a stream cipher.)  This
-   specification is limited to discussion of the operation of AES in
-   counter mode (AES-CTR.)
-
-   Counter mode ciphers (CTR) offer a number of attractive features over
-   other block cipher modes and stream ciphers such as RC4:
-
-   Low Bandwidth: AES-CTR provides a saving of 17-32 bytes per record
-      compared to AES-CBC as used in TLS 1.1 and DTLS. 16 bytes are
-      saved from not having to transmit an explicit IV, and another 1-16
-      bytes are saved from the absence of the padding block.
-
-   Random Access: AES-CTR is capable of random access within the key
-      stream.  For DTLS, this implies that records can be processed out
-      of order without dependency on packet arrival order, and also
-      without keystream buffering.
-
-   Parallelizable: As a consequence of AES-CTR supporting random access
-      within the key stream, making the cipher amenable to parallelizing
-      and pipelining in hardware.
-
-   Multiple mode support: AES-CTR support in TLS/DTLS allows for
-      implementator to support both a stream (CTR) and block (CBC)
-      cipher through the implementation of a single symmetric algorithm.
-
-1.1.  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 [1].
-
-
-2.  Terminology
-
-   This document reuses some terminology introduced in [2] and [3].  The
-   term 'counter block' has the same meaning as used in [2].  However,
-   the term 'IV' in this document, holds the meaning defined in [3].
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 3]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-3.  Encrypting Records with AES Counter Mode
-
-   AES-CTR is functionally equivalent to a stream cipher; it generates a
-   pseudo-random cipher stream that is XORed into the plaintext to form
-   ciphertext.
-
-   The cipher stream is generated by applying the AES encrypt operation
-   on a sequence of 128-bit counter blocks.  Counter blocks, in turn,
-   are generated based on record sequence numbers (in the case of TLS),
-   or a combination of record sequence and epoch numbers (in the case of
-   DTLS.)
-
-   It should be noted that although the client and server use the same
-   sequence number space, they use different write keys and counter
-   blocks.
-
-   There is one important constraint on the use of counter mode ciphers:
-   for a given key, a counter block value MUST never be used more than
-   once.
-
-   This constraint is required because a given key and counter block
-   value completely specify a portion of the cipher stream.  Hence, a
-   particular counter block value when used (with a given key) to
-   generate more than one ciphertext leaks information about the
-   corresponding plaintexts.  For a detailed explanation, see Section 7
-   of [2].
-
-   Given this constraint, the challenge then is in the design of the
-   counter block.  We describe the construction of the counter block in
-   the following sections.
-
-   TLS/DTLS records encrypted with AES-CTR mode use a
-   CipherSpec.cipher_type of GenericStreamCipher (Section 6.2.3 of [3]).
-
-3.1.  TLS
-
-   AES counter mode requires the encryptor and decryptor to share a per-
-   record unique counter block.  As previously stated, a given counter
-   block MUST never be used more than once with the same key.  The
-   following description of AES-CTR mode has been adapted from [2].
-
-3.1.1.  Encryption
-
-   To encrypt a payload with AES-CTR, the encryptor sequentially
-   partitions the plaintext (PT) into 128-bit blocks.  The final PT
-   block MAY be less than 128-bits.  This partitioning is denoted as:
-
-   PT = PT[1] PT[2] ...  PT[n]
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 4]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-   In order to encrypt, each PT block is XORed with a block of the key
-   stream to generate the ciphertext (CT.)  The keystream is generated
-   via the AES encryption of each counter block value, with each
-   encryption operation producing 128-bits of key stream.
-
-   The encryption operation is performed as follows:
-
-
-         FOR i := 1 to n-1 DO
-           CT[i] := PT[i] XOR AES(CtrBlk)
-           CtrBlk := CtrBlk + 1
-         END
-         CT[n] := PT[n] XOR TRUNC(AES(CtrBlk))
-
-   The AES() function performs AES encryption with the fresh key.
-
-   The TRUNC() function truncates the output of the AES encrypt
-   operation to the same length as the final plaintext block, returning
-   the leftmost bits.
-
-3.1.2.  Decryption
-
-   Decryption is similar to encryption.  The decryption of n ciphertext
-   blocks is performed as follows:
-
-
-         FOR i := 1 to n-1 DO
-           PT[i] := CT[i] XOR AES(CtrBlk)
-           CtrBlk := CtrBlk + 1
-         END
-         PT[n] := CT[n] XOR TRUNC(AES(CtrBlk))
-
-   The AES() and TRUNC() operate identically as in the case of
-   encryption.
-
-3.1.3.  Counter Block Construction
-
-   To construct the counter block, the leftmost 48-bits of the counter
-   block are set to the rightmost 48-bits of the client_write_IV (for
-   the half-duplex stream originated by the client) or the rightmost 48-
-   bits of the server_write_IV (for the half-duplex stream originated by
-   the server.)  The following 64-bits of the counter block are set to
-   record sequence number, and the remaining 16-bits function as the
-   block counter.  The block counter is a 16-bit unsigned integer in
-   network byte order (i.e. big-endien).  The block counter is initially
-   set to one, and is incremented by one to generate subsequent counter
-   blocks, each resulting in another 128-bits of key stream.
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 5]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-   The structure of the counter block is depicted below:
-
-          struct {
-             case client:
-                 uint48 client_write_IV;  // low order 48-bits
-             case server:
-                 uint48 server_write_IV;  // low order 48-bits
-             uint64 seq_num;
-             uint16 blk_ctr;
-          } CtrBlk;
-
-   The seq_num and blk_ctr fields of the counter block are initialized
-   for each record processed, while the IV is initialized immediately
-   after a key calculation is made (key calculations are made whenever a
-   TLS/DTLS handshake, either full or abbreviated, is executed.) seq_num
-   is set to the sequence number of the record, and blk_ctr is
-   initialized to 1.
-
-   Note that the block counter does not overflow since the maximum size
-   of input to the record payload protection layer in TLS or DTLS
-   (TLSCompressed.length) is 2^14 + 1024 octets, and 16 bits of blk_ctr
-   allow the generation of 2^20 octets (2^16 AES blocks) of keying
-   material per record.
-
-   Note that for TLS, no part of the counter block need be transmitted,
-   since the client_write_IV and server_write_IV are derived during the
-   key calculation phase, and the record sequence number is implicit.
-
-3.2.  DTLS
-
-   The operation of AES-CTR in DTLS is the same as in TLS, with the only
-   difference being the inclusion of the epoch in the counter block.
-   The counter block is constructed as follows for DTLS:
-
-       struct {
-          case client:
-              uint48 client_write_IV;  // low order 48-bits
-          case server:
-              uint48 server_write_IV;  // low order 48-bits
-          uint16 epoch;
-          uint48 seq_num;
-          uint16 blk_ctr;
-       } CtrBlk;
-
-   For decryption, the epoch and seq_num fields are initialized based on
-   the corresponding values in a received record.
-
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 6]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-3.3.  Padding
-
-   Stream ciphers in TLS and DTLS do not require plaintext padding.
-
-3.4.  Session Resumption
-
-   TLS supports session resumption via caching of session ID's and
-   connection parameters on both client and server.  While resumed
-   sessions use the same master secret that was originally negotiated, a
-   resumed session uses new keys that are derived, in part, using fresh
-   client_random and server_random parameters.  As a result resumed
-   sessions do not use the same encryption keys or IV's as the original
-   session.
-
-
-4.  Design Rationale
-
-   An alternate design for the construction of the counter block would
-   be the use of an explicit 'record tag' (as a substitute for the
-   implicit record sequence number) that could potentially be generated
-   via an LFSR.  Such a design, however, suffers a major drawback when
-   used in the TLS or DTLS protocol, without offering any significant
-   benefit: in both TLS and DTLS inclusion of such a tag would incur a
-   bandwidth cost.
-
-
-5.  Security Considerations
-
-   The security considerations for the use of AES-CTR in TLS/DTLS are
-   specified below.  The below text is based heavily on that for AES-CTR
-   in IPsec [2].
-
-   o  Counter blocks must not be used more than once with a given key.
-      Doing so allows a passive attacker to determine the XOR of the
-      affected plain text blocks.  Extracting two plaintexts from their
-      XOR is a relatively straightforward operation.  Because the
-      counter block is derived from the per-record sequence, this means
-      that sequence numbers MUST never be re-used with different data.
-      Note, however, that retransmitting the same record in DTLS is
-      safe.
-   o  AES-CTR can be used in pre-shared key mode, since session keys and
-      not pre-shared keys are used for ciphering.  Also, since separate
-      read and write keys are generated, counter blocks generated by
-      client and server can safely overlap.
-   o  As with other stream ciphers, data forgery is trivial if no
-      message integrity mechanism is employed.  This threat is of no
-      concern in TLS/DTLS since all ciphersuites that support encryption
-      also employ message integrity.
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 7]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-5.1.  Maximum Key Lifetime
-
-   TLS/DTLS sessions employing AES-CTR MUST be renegotiated before
-   sequence numbers repeat.  In the case of TLS, this implies a maximum
-   of 2^64 records per session, while for DTLS the maximum is 2^48 (with
-   the remaining bits reserved for epoch.)
-
-
-6.  IANA Considerations
-
-   IANA has assigned the following values for AES-CTR mode ciphers:
-
-   CipherSuite TLS_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_anon_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-
-   CipherSuite TLS_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_anon_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-
-7.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Housley, R., "Using Advanced Encryption Standard (AES) Counter
-        Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686,
-        January 2004.
-
-   [3]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
-        Protocol Version 1.1", RFC 4346, April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 8]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-Authors' Addresses
-
-   Nagendra Modadugu
-   Stanford University
-   353 Serra Mall
-   Stanford, CA  94305
-   USA
-
-   Email: nagendra@cs.stanford.edu
-
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore Rd., #212
-   Palo Alto, CA  94303
-   USA
-
-   Email: ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006               [Page 9]
-
-Internet-Draft              TLS/DTLS AES-CTR                   June 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Modadugu & Rescorla     Expires December 15, 2006              [Page 10]
-
-
diff --git a/doc/protocol/draft-ietf-tls-des-idea-00.txt b/doc/protocol/draft-ietf-tls-des-idea-00.txt
deleted file mode 100644
index 6237e698f3..0000000000
--- a/doc/protocol/draft-ietf-tls-des-idea-00.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-

-

-

-TLS Working Group                                         P. Eronen, Ed.

-Internet-Draft                                                     Nokia

-Intended status: Informational                         February 14, 2008

-Expires: August 17, 2008

-

-

-     DES and IDEA Cipher Suites for Transport Layer Security (TLS)

-                     draft-ietf-tls-des-idea-00.txt

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups.  Note that

-   other groups may also distribute working documents as Internet-

-   Drafts.

-

-   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.

-

-   This Internet-Draft will expire on August 17, 2008.

-

-Copyright Notice

-

-   Copyright (C) The IETF Trust (2008).

-

-Abstract

-

-   TLS specification versions 1.0 (RFC 2246) and 1.1 (RFC 4346) included

-   cipher suites based on DES (Data Encryption Standard) and IDEA

-   (International Data Encryption Algorithm) algorithms.  DES (when used

-   in single-DES mode) and IDEA are no longer recommended for general

-   use in TLS, and have been removed from TLS 1.2 main specification

-   (RFC NNNN).  This document specifies these cipher suites for

-   completeness, and discusses reasons why their use is no longer

-   recommended.

-

-

-

-Eronen                   Expires August 17, 2008                [Page 1]

-

-Internet-Draft     DES and IDEA Cipher Suites for TLS      February 2008

-

-

-1.  Introduction

-

-   TLS specification versions 1.0 [TLS10] and 1.1 [TLS11] included

-   cipher suites based on DES (Data Encryption Standard) and IDEA

-   (International Data Encryption Algorithm) algorithms.  DES (when used

-   in single-DES mode) and IDEA are no longer recommended for general

-   use in TLS, and have been removed from TLS 1.2 main specification

-   [TLS12].

-

-   This document specifies these cipher suites for completeness, and

-   discusses reasons why their use is no longer recommended.

-

-   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 [REQ].

-

-

-2.  DES Cipher Suites

-

-   DES (Data Encryption Standard) is a block cipher which was originally

-   approved as US federal standard in 1976, and is specified in [DES].

-

-   For TLS key generation purposes, DES is treated as having a 64-bit

-   key, but it still provides only 56 bits of protection, as 8 of the 64

-   bits are not used by the algorithm.  DES uses a 64-bit block size.

-

-   The following cipher suites have been defined for using DES in CBC

-   mode in TLS:

-

-      CipherSuite TLS_RSA_WITH_DES_CBC_SHA            = { 0x00,0x09 };

-      CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA         = { 0x00,0x0C };

-      CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA         = { 0x00,0x0F };

-      CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA        = { 0x00,0x12 };

-      CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA        = { 0x00,0x15 };

-      CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA        = { 0x00,0x1A };

-

-   The key exchange algorithms (RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA,

-   and DH_anon) and the MAC algorithm (SHA) are defined in the base TLS

-   specification.

-

-

-3.  IDEA Cipher Suites

-

-   IDEA (International Data Encryption Algorithm) is block cipher

-   designed by Xuejia Lai and James Massey [IDEA] [SCH].  IDEA uses a

-   128-bit key and operates on 64-bit blocks.

-

-

-

-

-

-Eronen                   Expires August 17, 2008                [Page 2]

-

-Internet-Draft     DES and IDEA Cipher Suites for TLS      February 2008

-

-

-   The following cipher suite has been defined for using IDEA in CBC

-   mode in TLS:

-

-      CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA           = { 0x00,0x07 };

-

-   The key exchange algorithm (RSA) and the MAC algorithm (SHA) are

-   defined in the base TLS specification.

-

-

-4.  Security Considerations

-

-4.1.  DES Cipher Suites

-

-   DES has an effective key strength of 56 bits, which has been been

-   known to be vulnerable to practical brute force attacks for over 20

-   years [DH].  A relatively recent 2006 paper by Kumar et al.  [COPA]

-   describes a system which performs exhaustive key search in less than

-   nine days on average, and costs less than 10,000 USD to build.

-

-   Given these, the single-DES cipher suites SHOULD NOT be implemented

-   by TLS libraries.  If a TLS library implements these cipher suites,

-   it SHOULD NOT enable them by default.  Experience has also shown that

-   rarely used code is a source of security and interoperability

-   problems, so existing implementations SHOULD consider removing these

-   cipher suites.

-

-4.2.  IDEA Cipher Suites

-

-   IDEA has a 128-bit key, and thus is not vulnerable to exhaustive key

-   search.  However, IDEA cipher suites for TLS have not seen widespread

-   use: most implementations either do not support them, do not enable

-   them by default, or do not negotiate them when other algorithms (such

-   as AES, 3DES, or RC4) are available.

-

-   Experience has shown that rarely used code is a source of security

-   and interoperability problems; given this, the IDEA cipher suites

-   SHOULD NOT be implemented by TLS libraries, and SHOULD be removed

-   from existing implementations.

-

-   Several reasons have been suggested to explain why the IDEA cipher

-   suites have been rarely used.  These include the existence of IPR

-   disclosures (which can be obtained from the IETF on-line IPR

-   repository at http://www.ietf.org/ipr); poor performance in software

-   on common CPU architectures; a 64-bit block size which is considered

-   short by modern standards; the existence of weak keys; lack of

-   government approval in many countries; and the availability of other

-   algorithms which addressed at least some of these reasons.

-

-

-

-

-Eronen                   Expires August 17, 2008                [Page 3]

-

-Internet-Draft     DES and IDEA Cipher Suites for TLS      February 2008

-

-

-5.  IANA Considerations

-

-   IANA has already allocated values for the cipher suites described in

-   this document in the TLS Cipher Suite Registry, defined in [TLS11].

-   IANA is requested to update (has updated) the references of these

-   cipher suites to point to this document:

-

-   Value         Description                             Reference

-   -----------   --------------------------------------  ---------

-   0x00,0x07     TLS_RSA_WITH_IDEA_CBC_SHA               [RFCnnnn]

-   0x00,0x09     TLS_RSA_WITH_DES_CBC_SHA                [RFCnnnn]

-   0x00,0x0C     TLS_DH_DSS_WITH_DES_CBC_SHA             [RFCnnnn]

-   0x00,0x0F     TLS_DH_RSA_WITH_DES_CBC_SHA             [RFCnnnn]

-   0x00,0x12     TLS_DHE_DSS_WITH_DES_CBC_SHA            [RFCnnnn]

-   0x00,0x15     TLS_DHE_RSA_WITH_DES_CBC_SHA            [RFCnnnn]

-   0x00,0x1A     TLS_DH_anon_WITH_DES_CBC_SHA            [RFCnnnn]

-

-   This document does not create any new registries to be maintained by

-   IANA, and does not require any new assignments from existing

-   registries.

-

-

-6.  Acknowledgments

-

-   The editor would like to thank Steven Bellovin, Uri Blumenthal,

-   Michael D'Errico, Paul Hoffman, Simon Josefsson, Bodo Moeller, Martin

-   Rex, and Len Sassaman for their contributions to preparing this

-   document.

-

-

-7.  References

-

-7.1.  Normative References

-

-   [DES]    National Institute of Standards and Technology, "Data

-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.

-

-   [IDEA]   Lai, X., "On the Design and Security of Block Ciphers",

-            ETH Series in Information Processing, v. 1, Konstanz:

-            Hartung-Gorre Verlag, 1992.

-

-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate

-            Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [SCH]    Schneier, B., "Applied Cryptography: Protocols, Algorithms,

-            and Source Code in C", 2nd ed., John Wiley & Sons, Inc.,

-            1996.

-

-

-

-

-Eronen                   Expires August 17, 2008                [Page 4]

-

-Internet-Draft     DES and IDEA Cipher Suites for TLS      February 2008

-

-

-   [TLS10]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",

-            RFC 2246, January 1999.

-

-   [TLS11]  Dierks, T. and E. Rescorla, "The Transport Layer Security

-            (TLS) Protocol Version 1.1", RFC 4346, April 2006.

-

-   [TLS12]  Dierks, T. and E. Rescorla, "The Transport Layer Security

-            (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-09

-            (work in progress), February 2008.

-

-7.2.  Informative References

-

-   [COPA]   Kumar, S., Paar, C., Pelzl, J., Pfeiffer, G., and M.

-            Schimmler, "Breaking Ciphers with COPACOBANA - A Cost-

-            Optimized Parallel Code Breaker", Workshop on Cryptographic

-            Hardware and Embedded Systems (CHES 2006), Yokohama, Japan,

-            October 2006.

-

-   [DH]     Diffie, W. and M. Hellman, "Exhaustive Cryptanalysis of the

-            NBS Data Encryption Standard", IEEE Computer, volume 10,

-            issue 6, June 1977.

-

-

-Author's Address

-

-   Pasi Eronen (editor)

-   Nokia Research Center

-   P.O. Box 407

-   FIN-00045 Nokia Group

-   Finland

-

-   Email: pasi.eronen@nokia.com

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Eronen                   Expires August 17, 2008                [Page 5]

-

-Internet-Draft     DES and IDEA Cipher Suites for TLS      February 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-Acknowledgment

-

-   Funding for the RFC Editor function is provided by the IETF

-   Administrative Support Activity (IASA).

-

-

-

-

-

-Eronen                   Expires August 17, 2008                [Page 6]

-

diff --git a/doc/protocol/draft-ietf-tls-ecc-04.txt b/doc/protocol/draft-ietf-tls-ecc-04.txt
deleted file mode 100644
index 208eb4f439..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-04.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-TLS Working Group                                               V. Gupta
-Internet-Draft                                                  Sun Labs
-Expires: May 1, 2004                                     S. Blake-Wilson
-                                                                     BCI
-                                                              B. Moeller
-                                                                     TBD
-                                                                 C. Hawk
-                                                  Independent Consultant
-                                                              N. Bolyard
-                                                                Netscape
-                                                               Nov. 2003
-
-
-                       ECC Cipher Suites for TLS
-                      <draft-ietf-tls-ecc-04.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on May 1, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document describes new key exchange algorithms based on Elliptic
-   Curve Cryptography (ECC) for the TLS (Transport Layer Security)
-   protocol.  In particular, it specifies the use of Elliptic Curve
-   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 1]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
-   authentication mechanism.
-
-   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 [1].
-
-   Please send comments on this document to the TLS mailing list.
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Key Exchange Algorithms  . . . . . . . . . . . . . . . . . .   5
-   2.1  ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . .   6
-   2.2  ECDHE_ECDSA  . . . . . . . . . . . . . . . . . . . . . . . .   7
-   2.3  ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . .   7
-   2.4  ECDHE_RSA  . . . . . . . . . . . . . . . . . . . . . . . . .   7
-   2.5  ECDH_anon  . . . . . . . . . . . . . . . . . . . . . . . . .   7
-   3.   Client Authentication  . . . . . . . . . . . . . . . . . . .   9
-   3.1  ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . .   9
-   3.2  ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . .  10
-   3.3  RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . .  10
-   4.   TLS Extensions for ECC . . . . . . . . . . . . . . . . . . .  11
-   5.   Data Structures and Computations . . . . . . . . . . . . . .  12
-   5.1  Client Hello Extensions  . . . . . . . . . . . . . . . . . .  12
-   5.2  Server Hello Extensions  . . . . . . . . . . . . . . . . . .  14
-   5.3  Server Certificate . . . . . . . . . . . . . . . . . . . . .  15
-   5.4  Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  16
-   5.5  Certificate Request  . . . . . . . . . . . . . . . . . . . .  20
-   5.6  Client Certificate . . . . . . . . . . . . . . . . . . . . .  21
-   5.7  Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  22
-   5.8  Certificate Verify . . . . . . . . . . . . . . . . . . . . .  24
-   5.9  Elliptic Curve Certificates  . . . . . . . . . . . . . . . .  25
-   5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . .  25
-   6.   Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . .  27
-   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  29
-   8.   Intellectual Property Rights . . . . . . . . . . . . . . . .  30
-   9.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  31
-        Normative References . . . . . . . . . . . . . . . . . . . .  32
-        Informative References . . . . . . . . . . . . . . . . . . .  33
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  33
-        Full Copyright Statement . . . . . . . . . . . . . . . . . .  35
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 2]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-1. Introduction
-
-   Elliptic Curve Cryptography (ECC) is emerging as an attractive
-   public-key cryptosystem for mobile/wireless environments.  Compared
-   to currently prevalent cryptosystems such as RSA, ECC offers
-   equivalent security with smaller key sizes.  This is illustrated in
-   the following table, based on [12], which gives approximate
-   comparable key sizes for symmetric- and asymmetric-key cryptosystems
-   based on the best-known algorithms for attacking them.
-
-                   Symmetric    |  ECC    |  DH/DSA/RSA
-                   -------------+---------+------------
-                      80        |  163    |  1024
-                     112        |  233    |  2048
-                     128        |  283    |  3072
-                     192        |  409    |  7680
-                     256        |  571    |  15360
-
-                  Table 1: Comparable key sizes (in bits)
-
-
-   Smaller key sizes result in power, bandwidth and computational
-   savings that make ECC especially attractive for constrained
-   environments.
-
-   This document describes additions to TLS to support ECC.  In
-   particular, it defines
-
-   o  the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
-      scheme with long-term or ephemeral keys to establish the TLS
-      premaster secret, and
-
-   o  the use of fixed-ECDH certificates and ECDSA for authentication of
-      TLS peers.
-
-   The remainder of this document is organized as follows.  Section 2
-   provides an overview of ECC-based key exchange algorithms for TLS.
-   Section 3 describes the use of ECC certificates for client
-   authentication.  TLS extensions that allow a client to negotiate the
-   use of specific curves and point formats are presented in Section 4.
-   Section 5 specifies various data structures needed for an ECC-based
-   handshake, their encoding in TLS messages and the processing of those
-   messages.  Section 6 defines new ECC-based cipher suites and
-   identifies a small subset of these as recommended for all
-   implementations of this specification.  Section 7, Section 8 and
-   Section 9 mention security considerations, intellectual property
-   rights, and acknowledgments, respectively.  This is followed by a
-   list of references cited in this document and the authors' contact
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 3]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   information.
-
-   Implementation of this specification requires familiarity with TLS
-   [2], TLS extensions [3] and ECC [4][5][6][8] .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 4]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-2. Key Exchange Algorithms
-
-   This document introduces five new ECC-based key exchange algorithms
-   for TLS.  All of them use ECDH to compute the TLS premaster secret
-   and differ only in the lifetime of ECDH keys (long-term or ephemeral)
-   and the mechanism (if any) used to authenticate them.  The derivation
-   of the TLS master secret from the premaster secret and the subsequent
-   generation of bulk encryption/MAC keys and initialization vectors is
-   independent of the key exchange algorithm and not impacted by the
-   introduction of ECC.
-
-    The table below summarizes the new key exchange algorithms which
-   mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]),
-   respectively.
-
-          Key
-          Exchange
-          Algorithm           Description
-          ---------           -----------
-
-          ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
-
-          ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
-
-          ECDH_RSA            Fixed ECDH with RSA-signed certificates.
-
-          ECDHE_RSA           Ephemeral ECDH with RSA signatures.
-
-          ECDH_anon           Anonymous ECDH, no signatures.
-
-
-                     Table 2: ECC key exchange algorithms
-
-
-   Note that the anonymous key exchange algorithm does not provide
-   authentication of the server or the client.  Like other anonymous TLS
-   key exchanges, it is subject to man-in-the-middle attacks.
-   Implementations of this algorithm SHOULD provide authentication by
-   other means.
-
-   Note that there is no structural difference between ECDH and ECDSA
-   keys.  A certificate issuer may use X509.v3 keyUsage and
-   extendedKeyUsage extensions to restrict the use of an ECC public key
-   to certain computations.  This document refers to an ECC key as ECDH-
-   capable if its use in ECDH is permitted.  ECDSA-capable is defined
-   similarly.
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 5]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-              Client                                        Server
-              ------                                        ------
-
-              ClientHello          -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                              CertificateRequest*+
-                                   <--------       ServerHelloDone
-              Certificate*+
-              ClientKeyExchange
-              CertificateVerify*+
-              [ChangeCipherSpec]
-              Finished             -------->
-                                                [ChangeCipherSpec]
-                                   <--------              Finished
-
-              Application Data     <------->      Application Data
-
-                 Figure 1: Message flow in a full TLS handshake
-                   * message is not sent under some conditions
-                   + message is not sent unless the client is
-                     authenticated
-
-
-   Figure 1 shows all messages involved in the TLS key establishment
-   protocol (aka full handshake).  The addition of ECC has direct impact
-   only on the ClientHello, the ServerHello, the server's Certificate
-   message, the ServerKeyExchange, the ClientKeyExchange, the
-   CertificateRequest, the client's Certificate message, and the
-   CertificateVerify.  Next, we describe each ECC key exchange algorithm
-   in greater detail in terms of the content and processing of these
-   messages.  For ease of exposition, we defer discussion of client
-   authentication and associated messages (identified with a + in Figure
-   1) until Section 3 and of the optional ECC-specific extensions (which
-   impact the Hello messages) until Section 4.
-
-2.1 ECDH_ECDSA
-
-   In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
-   public key and be signed with ECDSA.
-
-   A ServerKeyExchange MUST NOT be sent (the server's certificate
-   contains all the necessary keying information required by the client
-   to arrive at the premaster secret).
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's long-term public key and send its public key in the
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 6]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   ClientKeyExchange message (except when using client authentication
-   algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
-   modifications from section Section 3.2 or Section 3.3 apply).
-
-   Both client and server MUST perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-2.2 ECDHE_ECDSA
-
-   In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
-   capable public key and be signed with ECDSA.
-
-   The server MUST send its ephemeral ECDH public key and a
-   specification of the corresponding curve in the ServerKeyExchange
-   message.  These parameters MUST be signed with ECDSA using the
-   private key corresponding to the public key in the server's
-   Certificate.
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server MUST perform an ECDH operation (Section 5.10)
-   and use the resultant shared secret as the premaster secret.
-
-2.3 ECDH_RSA
-
-   This key exchange algorithm is the same as ECDH_ECDSA except the
-   server's certificate MUST be signed with RSA rather than ECDSA.
-
-2.4 ECDHE_RSA
-
-   This key exchange algorithm is the same as ECDHE_ECDSA except the
-   server's certificate MUST contain an RSA public key authorized for
-   signing and the signature in the ServerKeyExchange message MUST be
-   computed with the corresponding RSA private key.  The server
-   certificate MUST be signed with RSA.
-
-2.5 ECDH_anon
-
-   In ECDH_anon, the server's Certificate, the CertificateRequest, the
-   client's Certificate, and the CertificateVerify messages MUST NOT be
-   sent.
-
-   The server MUST send an ephemeral ECDH public key and a specification
-   of the corresponding curve in the ServerKeyExchange message.  These
-   parameters MUST NOT be signed.
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 7]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server MUST perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 8]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-3. Client Authentication
-
-   This document defines three new client authentication mechanisms
-   named after the type of client certificate involved: ECDSA_sign,
-   ECDSA_fixed_ECDH and RSA_fixed_ECDH.  The ECDSA_sign mechanism is
-   usable with any of the non-anonymous ECC key exchange algorithms
-   described in Section 2 as well as other non-anonymous (non-ECC) key
-   exchange algorithms defined in TLS [2].  The ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
-   Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
-   use of a long-term ECDH client key would jeopardize the forward
-   secrecy property of these algorithms.
-
-   The server can request ECC-based client authentication by including
-   one or more of these certificate types in its CertificateRequest
-   message.  The server MUST NOT include any certificate types that are
-   prohibited for the negotiated key exchange algorithm.  The client
-   must check if it possesses a certificate appropriate for any of the
-   methods suggested by the server and is willing to use it for
-   authentication.
-
-   If these conditions are not met, the client should send a client
-   Certificate message containing no certificates.  In this case, the
-   ClientKeyExchange should be sent as described in Section 2 and the
-   CertificateVerify should not be sent.  If the server requires client
-   authentication, it may respond with a fatal handshake failure alert.
-
-   If the client has an appropriate certificate and is willing to use it
-   for authentication, it MUST send that certificate in the client's
-   Certificate message (as per Section 5.6) and prove possession of the
-   private key corresponding to the certified key.  The process of
-   determining an appropriate certificate and proving possession is
-   different for each authentication mechanism and described below.
-
-   NOTE: It is permissible for a server to request (and the client to
-   send) a client certificate of a different type than the server
-   certificate.
-
-3.1 ECDSA_sign
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDSA-capable public key and signed with
-   ECDSA.
-
-   The client MUST prove possession of the private key corresponding to
-   the certified key by including a signature in the CertificateVerify
-   message as described in Section 5.8.
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                  [Page 9]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-3.2 ECDSA_fixed_ECDH
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDH-capable public key and that
-   certificate MUST be signed with ECDSA.  Furthermore, the client's
-   ECDH key MUST be on the same elliptic curve as the server's long-term
-   (certified) ECDH key.
-
-   When using this authentication mechanism, the client MUST send an
-   empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
-   the CertificateVerify message.  The ClientKeyExchange is empty since
-   the client's ECDH public key required by the server to compute the
-   premaster secret is available inside the client's certificate.  The
-   client's ability to arrive at the same premaster secret as the server
-   (demonstrated by a successful exchange of Finished messages) proves
-   possession of the private key corresponding to the certified public
-   key and the CertificateVerify message is unnecessary.
-
-3.3 RSA_fixed_ECDH
-
-   This authentication mechanism is identical to ECDSA_fixed_ECDH except
-   the client's certificate MUST be signed with RSA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 10]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-4. TLS Extensions for ECC
-
-   Two new TLS extensions --- (i) the Supported Elliptic Curves
-   Extension, and (ii) the Supported Point Formats Extension --- allow a
-   client to negotiate the use of specific curves and point formats
-   (e.g.  compressed v/s uncompressed), respectively.  These extensions
-   are especially relevant for constrained clients that may only support
-   a limited number of curves or point formats.   They follow the
-   general approach outlined in [3].  The client enumerates the curves
-   and point formats it supports by including the appropriate extensions
-   in its ClientHello message.  By echoing that extension in its
-   ServerHello, the server agrees to restrict its key selection or
-   encoding to the choices specified by the client.
-
-   A TLS client that proposes ECC cipher suites in its ClientHello
-   message SHOULD include these extensions.  Servers implementing ECC
-   cipher suites MUST support these extensions and negotiate the use of
-   an ECC cipher suite only if they can complete the handshake while
-   limiting themselves to the curves and compression techniques
-   enumerated by the client.  This eliminates the possibility that a
-   negotiated ECC handshake will be subsequently aborted due to a
-   client's inability to deal with the server's EC key.
-
-   These extensions MUST NOT be included if the client does not propose
-   any ECC cipher suites.  A client that proposes ECC cipher suites may
-   choose not to include these extension.  In this case, the server is
-   free to choose any one of the elliptic curves or point formats listed
-   in Section 5.  That section also describes the structure and
-   processing of these extensions in greater detail.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 11]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-5. Data Structures and Computations
-
-   This section specifies the data structures and computations used by
-   ECC-based key mechanisms specified in Section 2, Section 3 and
-   Section 4.  The presentation language used here is the same as that
-   used in TLS [2].  Since this specification extends TLS, these
-   descriptions should be merged with those in the TLS specification and
-   any others that extend TLS.  This means that enum types may not
-   specify all possible values and structures with multiple formats
-   chosen with a select() clause may not indicate all possible cases.
-
-5.1 Client Hello Extensions
-
-   When this message is sent:
-
-   The ECC extensions SHOULD be sent along with any ClientHello message
-   that proposes ECC cipher suites.
-
-   Meaning of this message:
-
-   These extensions allow a constrained client to enumerate the elliptic
-   curves and/or point formats it supports.
-
-   Structure of this message:
-
-   The general structure of TLS extensions is described in [3] and this
-   specification adds two new types to ExtensionType.
-
-
-        enum { ellptic_curves(6), ec_point_formats(7) } ExtensionType;
-
-   elliptic_curves:  Indicates the set of elliptic curves supported by
-      the client.  For this extension, the opaque extension_data field
-      contains EllipticCurveList.
-
-   ec_point_formats:  Indicates the set of point formats supported by
-      the client.  For this extension, the opaque extension_data field
-      contains ECPointFormatList.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 12]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-        enum {
-            sect163k1 (1), sect163r1 (2), sect163r2 (3),
-            sect193r1 (4), sect193r2 (5), sect233k1 (6),
-            sect233r1 (7), sect239k1 (8), sect283k1 (9),
-            sect283r1 (10), sect409k1 (11), sect409r1 (12),
-            sect571k1 (13), sect571r1 (14), secp160k1 (15),
-            secp160r1 (16), secp160r2 (17), secp192k1 (18),
-            secp192r1 (19), secp224k1 (20), secp224r1 (21),
-            secp256k1 (22), secp256r1 (23), secp384r1 (24),
-            secp521r1 (25), reserved (240..247),
-            arbitrary_explicit_prime_curves(253),
-            arbitrary_explicit_char2_curves(254),
-            (255)
-        } NamedCurve;
-
-   sect163k1, etc:  Indicates support of the corresponding named curve
-      specified in SEC 2 [10].  Note that many of these curves are also
-      recommended in ANSI X9.62 [6], and FIPS 186-2 [8].  Values 240
-      through 247 are reserved for private use.  Values 253 and 254
-      indicate that the client supports arbitrary prime and
-      charactersitic two curves, respectively (the curve parameters must
-      be encoded explicitly in ECParameters).
-
-
-        struct {
-            NamedCurve elliptic_curve_list<1..2^16-1>
-        } EllipticCurveList;
-
-
-   As an example, a client that only supports secp192r1 (aka NIST P-192)
-   and secp192r1 (aka NIST P-224) would include an elliptic_curves
-   extension with the following octets:
-
-        00 06 00 02 13 14
-
-    A client that supports arbitrary explicit binary polynomial curves
-   would include an extension with the following octets:
-
-        00 06 00 01 fe
-
-
-        enum { uncompressed (0), ansiX963_compressed (1), ansiX963_hybrid (2) }
-        ECPointFormat;
-
-        struct {
-            ECPointFormat ec_point_format_list<1..2^16-1>
-        } ECPointFormatList;
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 13]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   A client that only supports the uncompressed point format includes an
-   extension with the following octets:
-
-        00 07 00 01 00
-
-   A client that prefers the use of the ansiX963_compressed format over
-   uncompressed may indicate that preference by including an extension
-   with the following octets:
-
-        00 07 00 02 01 00
-
-   Actions of the sender:
-
-   A client that proposes ECC cipher suites in its ClientHello appends
-   these extensions (along with any others) enumerating the curves and
-   point formats it supports.
-
-   Actions of the receiver:
-
-   A server that receives a ClientHello containing one or both of these
-   extensions MUST use the client's enumerated capabilities to guide its
-   selection of an appropriate cipher suite.  One of the proposed ECC
-   cipher suites must be negotiated only if the server can successfully
-   complete the handshake while using the curves and point formats
-   supported by the client.
-
-   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
-   different curves for (i) the ECDSA key in its certificate, and (ii)
-   the ephemeral ECDH key in the ServerKeyExchange message.  The server
-   must consider the "elliptic_curves" extension in selecting both of
-   these curves.
-
-   If a server does not understand the "elliptic_curves" extension or is
-   unable to complete the ECC handshake while restricting itself to the
-   enumerated curves, it MUST NOT negotiate the use of an ECC cipher
-   suite.  Depending on what other cipher suites are proposed by the
-   client and supported by the server, this may result in a fatal
-   handshake failure alert due to the lack of common cipher suites.
-
-5.2 Server Hello Extensions
-
-   When this message is sent:
-
-   The ServerHello ECC extensions are sent in response to a Client Hello
-   message containing ECC extensions when negotiating an ECC cipher
-   suite.
-
-   Meaning of this message:
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 14]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   These extensions indicate the server's agreement to use only the
-   elliptic curves and point formats supported by the client during the
-   ECC-based key exchange.
-
-   Structure of this message:
-
-   The ECC extensions echoed by the server are the same as those in the
-   ClientHello except the "extension_data" field is empty.
-
-   For example, a server indicates its acceptance of the client's
-   elliptic_curves extension by sending an extension with the following
-   octets:
-
-        00 06 00 00
-
-   Actions of the sender:
-
-   A server makes sure that it can complete a proposed ECC key exchange
-   mechanism by restricting itself to the curves/point formats supported
-   by the client before sending these extensions.
-
-   Actions of the receiver:
-
-   A client that receives a ServerHello with ECC extensions proceeds
-   with an ECC key exchange assured that it will be able to handle the
-   server's EC key(s).
-
-5.3 Server Certificate
-
-   When this message is sent:
-
-   This message is sent in all non-anonymous ECC-based key exchange
-   algorithms.
-
-   Meaning of this message:
-
-   This message is used to authentically convey the server's static
-   public key to the client.  The following table shows the server
-   certificate type appropriate for each key exchange algorithm.  ECC
-   public keys must be encoded in certificates as described in Section
-   5.9.
-
-   NOTE: The server's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 3 apply only to
-   the server's certificate (first in the chain).
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 15]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-          Key Exchange Algorithm  Server Certificate Type
-          ----------------------  -----------------------
-
-          ECDH_ECDSA              Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDHE_ECDSA             Certificate must contain an
-                                  ECDSA-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDH_RSA                Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with RSA.
-
-          ECDHE_RSA               Certificate must contain an
-                                  RSA public key authorized for
-                                  use in digital signatures. It
-                                  must be signed with RSA.
-
-                    Table 3: Server certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS Certificate format.
-
-   Actions of the sender:
-
-   The server constructs an appropriate certificate chain and conveys it
-   to the client in the Certificate message.
-
-   Actions of the receiver:
-
-   The client validates the certificate chain, extracts the server's
-   public key, and checks that the key type is appropriate for the
-   negotiated key exchange algorithm.
-
-5.4 Server Key Exchange
-
-   When this message is sent:
-
-   This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
-   ECDH_anon key exchange algorithms.
-
-   Meaning of this message:
-
-   This message is used to convey the server's ephemeral ECDH public key
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 16]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   (and the corresponding elliptic curve domain parameters) to the
-   client.
-
-   Structure of this message:
-
-        enum { explicit_prime (1), explicit_char2 (2),
-               named_curve (3), (255) } ECCurveType;
-
-   explicit_prime:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a prime
-      field.
-
-   explicit_char2:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a
-      characteristic 2 field.
-
-   named_curve:  Indicates that a named curve is used.  This option
-      SHOULD be used when applicable.
-
-
-        struct {
-            opaque a <1..2^8-1>;
-            opaque b <1..2^8-1>;
-            opaque seed <0..2^8-1>;
-        } ECCurve;
-
-   a, b:  These parameters specify the coefficients of the elliptic
-      curve.  Each value contains the byte string representation of a
-      field element following the conversion routine in Section 4.3.3 of
-      ANSI X9.62 [6].
-
-   seed:  This is an optional parameter used to derive the coefficients
-      of a randomly generated elliptic curve.
-
-
-        struct {
-            opaque point <1..2^8-1>;
-        } ECPoint;
-
-   point:  This is the byte string representation of an elliptic curve
-      point following the conversion routine in Section 4.3.6 of ANSI
-      X9.62 [6].  Note that this byte string may represent an elliptic
-      curve point in compressed or uncompressed form.  Implementations
-      of this specification MUST support the uncompressed form and MAY
-      support the compressed form.
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 17]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
-
-   ec_basis_trinomial:  Indicates representation of a characteristic two
-      field using a trinomial basis.
-
-   ec_basis_pentanomial:  Indicates representation of a characteristic
-      two field using a pentanomial basis.
-
-
-        struct {
-            ECCurveType    curve_type;
-            select (curve_type) {
-                case explicit_prime:
-                    opaque      prime_p <1..2^8-1>;
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case explicit_char2:
-                    uint16      m;
-                    ECBasisType basis;
-                    select (basis) {
-                        case ec_trinomial:
-                            opaque  k <1..2^8-1>;
-                        case ec_pentanomial:
-                            opaque  k1 <1..2^8-1>;
-                            opaque  k2 <1..2^8-1>;
-                            opaque  k3 <1..2^8-1>;
-                    };
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case named_curve:
-                    NamedCurve namedcurve;
-            };
-        } ECParameters;
-
-   curve_type:  This identifies the type of the elliptic curve domain
-      parameters.
-
-   prime_p:  This is the odd prime defining the field Fp.
-
-   curve:  Specifies the coefficients a and b (and optional seed) of the
-      elliptic curve E.
-
-   base:  Specifies the base point G on the elliptic curve.
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 18]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   order:  Specifies the order n of the base point.
-
-   cofactor:  Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
-      represents the number of points on the elliptic curve E defined
-      over the field Fq.
-
-   m:  This is the degree of the characteristic-two field F2^m.
-
-   k:  The exponent k for the trinomial basis representation x^m + x^k
-      +1.
-
-   k1, k2, k3:  The exponents for the pentanomial representation x^m +
-      x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
-
-   namedcurve:  Specifies a recommended set of elliptic curve domain
-      parameters.  All enum values of NamedCurve are allowed except for
-      arbitrary_explicit_prime_curves(253) and
-      arbitrary_explicit_char2_curves(254).  These two values are only
-      allowed in the ClientHello extension.
-
-
-        struct {
-            ECParameters    curve_params;
-            ECPoint         public;
-        } ServerECDHParams;
-
-   curve_params:  Specifies the elliptic curve domain parameters
-      associated with the ECDH public key.
-
-   public:  The ephemeral ECDH public key.
-
-   The ServerKeyExchange message is extended as follows.
-
-        enum { ec_diffie_hellman } KeyExchangeAlgorithm;
-
-   ec_diffie_hellman:  Indicates the ServerKeyExchange message contains
-      an ECDH public key.
-
-
-        select (KeyExchangeAlgorithm) {
-            case ec_diffie_hellman:
-                ServerECDHParams    params;
-                Signature           signed_params;
-        } ServerKeyExchange;
-
-   params:  Specifies the ECDH public key and associated domain
-      parameters.
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 19]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   signed_params:  A hash of the params, with the signature appropriate
-      to that hash applied.  The private key corresponding to the
-      certified public key in the server's Certificate message is used
-      for signing.
-
-
-          enum { ecdsa } SignatureAlgorithm;
-
-
-          select (SignatureAlgorithm) {
-              case ecdsa:
-                  digitally-signed struct {
-                      opaque sha_hash[sha_size];
-                  };
-          } Signature;
-
-   NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange
-   algorithm and 'anonymous' for ECDH_anon.  These cases are defined in
-   TLS [2].  SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA.  ECDSA
-   signatures are generated and verified as described in Section 5.10.
-   As per ANSI X9.62, an ECDSA signature consists of a pair of integers
-   r and s.  These integers are both converted into byte strings of the
-   same length as the curve order n using the conversion routine
-   specified in Section 4.3.1 of [6].  The two byte strings are
-   concatenated, and the result is placed in the signature field.
-
-   Actions of the sender:
-
-   The server selects elliptic curve domain parameters and an ephemeral
-   ECDH public key corresponding to these parameters according to the
-   ECKAS-DH1 scheme from IEEE 1363 [5].  It conveys this information to
-   the client in the ServerKeyExchange message using the format defined
-   above.
-
-   Actions of the recipient:
-
-   The client verifies the signature (when present) and retrieves the
-   server's elliptic curve domain parameters and ephemeral ECDH public
-   key from the ServerKeyExchange message.
-
-5.5 Certificate Request
-
-   When this message is sent:
-
-   This message is sent when requesting client authentication.
-
-   Meaning of this message:
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 20]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   The server uses this message to suggest acceptable client
-   authentication methods.
-
-   Structure of this message:
-
-   The TLS CertificateRequest message is extended as follows.
-
-        enum {
-            ecdsa_sign(?), rsa_fixed_ecdh(?),
-            ecdsa_fixed_ecdh(?), (255)
-        } ClientCertificateType;
-
-   ecdsa_sign, etc Indicates that the server would like to use the
-      corresponding client authentication method specified in Section 3.
-
-      EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
-      ecdsa_fixed_ecdh have been left as ?.  These values will be
-      assigned when this draft progresses to RFC.  Earlier versions of
-      this draft used the values 5, 6, and 7 - however these values have
-      been removed since they are used differently by SSL 3.0 [13] and
-      their use by TLS is being deprecated.
-
-   Actions of the sender:
-
-   The server decides which client authentication methods it would like
-   to use, and conveys this information to the client using the format
-   defined above.
-
-   Actions of the receiver:
-
-   The client determines whether it has an appropriate certificate for
-   use with any of the requested methods, and decides whether or not to
-   proceed with client authentication.
-
-5.6 Client Certificate
-
-   When this message is sent:
-
-   This message is sent in response to a CertificateRequest when a
-   client has a suitable certificate.
-
-   Meaning of this message:
-
-   This message is used to authentically convey the client's static
-   public key to the server.  The following table summarizes what client
-   certificate types are appropriate for the ECC-based client
-   authentication mechanisms described in Section 3.  ECC public keys
-   must be encoded in certificates as described in Section 5.9.
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 21]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   NOTE: The client's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 4 apply only to
-   the client's certificate (first in the chain).
-
-
-          Client
-          Authentication Method   Client Certificate Type
-          ---------------------   -----------------------
-
-          ECDSA_sign              Certificate must contain an
-                                  ECDSA-capable public key and
-                                  be signed with ECDSA.
-
-          ECDSA_fixed_ECDH        Certificate must contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  must be signed with ECDSA.
-
-          RSA_fixed_ECDH          Certificate must contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  must be signed with RSA.
-
-                     Table 4: Client certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS client Certificate format.
-
-   Actions of the sender:
-
-   The client constructs an appropriate certificate chain, and conveys
-   it to the server in the Certificate message.
-
-   Actions of the receiver:
-
-   The TLS server validates the certificate chain, extracts the client's
-   public key, and checks that the key type is appropriate for the
-   client authentication method.
-
-5.7 Client Key Exchange
-
-   When this message is sent:
-
-   This message is sent in all key exchange algorithms.  If client
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 22]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
-   message is empty.  Otherwise, it contains the client's ephemeral ECDH
-   public key.
-
-   Meaning of the message:
-
-   This message is used to convey ephemeral data relating to the key
-   exchange belonging to the client (such as its ephemeral ECDH public
-   key).
-
-   Structure of this message:
-
-   The TLS ClientKeyExchange message is extended as follows.
-
-        enum { yes, no } EphemeralPublicKey;
-
-   yes, no:  Indicates whether or not the client is providing an
-      ephemeral ECDH public key.  (In ECC ciphersuites, this is "yes"
-      except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH
-      client authentication mechanism.)
-
-
-        struct {
-            select (EphemeralPublicKey) {
-                case yes: ECPoint  ecdh_Yc;
-                case no:  struct { };
-            } ecdh_public;
-        } ClientECDiffieHellmanPublic;
-
-   ecdh_Yc:  Contains the client's ephemeral ECDH public key.
-
-
-        struct {
-            select (KeyExchangeAlgorithm) {
-                case ec_diffie_hellman: ClientECDiffieHellmanPublic;
-            } exchange_keys;
-        } ClientKeyExchange;
-
-   Actions of the sender:
-
-   The client selects an ephemeral ECDH public key corresponding to the
-   parameters it received from the server according to the ECKAS-DH1
-   scheme from IEEE 1363 [5].  It conveys this information to the client
-   in the ClientKeyExchange message using the format defined above.
-
-   Actions of the recipient:
-
-   The server retrieves the client's ephemeral ECDH public key from the
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 23]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   ClientKeyExchange message and checks that it is on the same elliptic
-   curve as the server's ECDH key.
-
-5.8 Certificate Verify
-
-   When this message is sent:
-
-   This message is sent when the client sends a client certificate
-   containing a public key usable for digital signatures, e.g.  when the
-   client is authenticated using the ECDSA_sign mechanism.
-
-   Meaning of the message:
-
-   This message contains a signature that proves possession of the
-   private key corresponding to the public key in the client's
-   Certificate message.
-
-   Structure of this message:
-
-   The TLS CertificateVerify message is extended as follows.
-
-        enum { ecdsa } SignatureAlgorithm;
-
-        select (SignatureAlgorithm) {
-            case ecdsa:
-                digitally-signed struct {
-                    opaque sha_hash[sha_size];
-                };
-        } Signature;
-
-   For the ecdsa case, the signature field in the CertificateVerify
-   message contains an ECDSA signature computed over handshake messages
-   exchanged so far.  ECDSA signatures are computed as described in
-   Section 5.10.  As per ANSI X9.62, an ECDSA signature consists of a
-   pair of integers r and s.  These integers are both converted into
-   byte strings of the same length as the curve order n using the
-   conversion routine specified in Section 4.3.1 of [6].  The two byte
-   strings are concatenated, and the result is placed in the signature
-   field.
-
-   Actions of the sender:
-
-   The client computes its signature over all handshake messages sent or
-   received starting at client hello up to but not including this
-   message.  It uses the private key corresponding to its certified
-   public key to compute the signature which is conveyed in the format
-   defined above.
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 24]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   Actions of the receiver:
-
-   The server extracts the client's signature from the CertificateVerify
-   message, and verifies the signature using the public key it received
-   in the client's Certificate message.
-
-5.9 Elliptic Curve Certificates
-
-   X509 certificates containing ECC public keys or signed using ECDSA
-   MUST comply with [11].  Clients SHOULD use the elliptic curve domain
-   parameters recommended in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2
-   [10].
-
-5.10 ECDH, ECDSA and RSA Computations
-
-   All ECDH calculations (including parameter and key generation as well
-   as the shared secret calculation) MUST be performed according to [5]
-   using
-
-   o  the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation
-      primitive, the KDF1 key derivation function using SHA-1 [7], and
-      null key derivation parameters "P" for elliptic curve parameters
-      where field elements are represented as octet strings of length 24
-      or less (using the IEEE 1363 FE2OSP); in this case, the premaster
-      secret is the output of the ECKAS-DH1 scheme, i.e.  the 20-byte
-      SHA-1 output from the KDF.
-
-   o  the ECKAS-DH1 scheme with the identity map as key derivation
-      function for elliptic curve parameters where field elements are
-      represented as octet strings of length more than 24; in this case,
-      the premaster secret is the x-coordinate of the ECDH shared secret
-      elliptic curve point, i.e.  the octet string Z in IEEE 1363
-      terminology.
-
-   Note that a new extension may be introduced in the future to allow
-   the use of a different KDF during computation of the premaster
-   secret.  In this event, the new KDF would be used in place of the
-   process detailed above.  This may be desirable, for example, to
-   support compatibility with the planned NIST key agreement standard.
-
-   All ECDSA computations MUST be performed according to ANSI X9.62 [6]
-   or its successors.  Data to be signed/verified is hashed and the
-   result run directly through the ECDSA algorithm with no additional
-   hashing.  The default hash function is SHA-1 [7] and sha_size (see
-   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
-   function, such as one of the new SHA hash functions specified in FIPS
-   180-2 [7], may be used instead if the certificate containing the EC
-   public key explicitly requires use of another hash function.
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 25]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   All RSA signatures must be generated and verified according to PKCS#1
-   [9].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 26]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-6. Cipher Suites
-
-   The table below defines new ECC cipher suites that use the key
-   exchange algorithms specified in Section 2.
-
-   EDITOR: Most of the cipher suites below have been left as ??.  The
-   values 47-4C correspond to cipher suites which are known to have been
-   implemented and are therefore proposed here.  The final determination
-   of cipher suite numbers will occur when this draft progresses to RFC.
-   Implementers using the values 47-4C should therefore be wary that
-   these values may change.
-
-     CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA           = { 0x00, 0x47 }
-     CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA        = { 0x00, 0x48 }
-     CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA        = { 0x00, 0x49 }
-     CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   = { 0x00, 0x4A }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA    = { 0x00, 0x4B }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA    = { 0x00, 0x4C }
-
-     CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA       = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA             = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_anon_NULL_WITH_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-                        Table 5: TLS ECC cipher suites
-
-
-   The key exchange method, cipher, and hash algorithm for each of these
-   cipher suites are easily determined by examining the name.  Ciphers
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 27]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   other than AES ciphers, and hash algorithms are defined in [2].  AES
-   ciphers are defined in [14].
-
-   Server implementations SHOULD support all of the following cipher
-   suites, and client implementations SHOULD support at least one of
-   them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
-   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 28]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-7. Security Considerations
-
-   This document is based on [2], [5], [6] and [14].  The appropriate
-   security considerations of those documents apply.
-
-   For ECDH (Section 5.10), this document specifies two different ways
-   to compute the premaster secret.  The choice of the method is
-   determined by the elliptic curve.  Earlier versions of this
-   specification used the KDF1 key derivation function with SHA-1 in all
-   cases; the current version keeps this key derivation function only
-   for curves where field elements are represented as octet strings of
-   length 24 or less (i.e.  up to 192 bits), but omits it for larger
-   curves.
-
-   Rationale: Using KDF1 with SHA-1 limits the security to at most 160
-   bits, independently of the elliptic curve used for ECDH.  For large
-   curves, this would result in worse security than expected.  Using a
-   specific key derivation function for ECDH is not really necessary as
-   TLS always uses its PRF to derive the master secret from the
-   premaster secret.  For large curves, the current specification
-   handles ECDH like the basic TLS specification [14] handles standard
-   DH.  For smaller curves where the extra KDF1 step does not weaken
-   security, the current specification keeps the KDF1 step to obtain
-   compatibility with existing implementations of earlier versions of
-   this specification.  Note that the threshold for switching between
-   the two ECDH calculation methods is necessarily somewhat arbitrary;
-   192-bit ECC corresponds to approximately 96 bits of security in the
-   light of square root attacks, so the 160 bits provided by SHA-1 are
-   comfortable at this limit.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 29]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-8. Intellectual Property Rights
-
-   The IETF has been notified of intellectual property rights claimed in
-   regard to the specification contained in this document.  For more
-   information, consult the online list of claimed rights (http://
-   www.ietf.org/ipr.html).
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in [15].  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementers or users of this specification can
-   be obtained from the IETF Secretariat.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 30]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-9. Acknowledgments
-
-   The authors wish to thank Bill Anderson and Tim Dierks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 31]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-Normative References
-
-   [1]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-         2246, January 1999.
-
-   [3]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
-         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
-         3546, June 2003.
-
-   [4]   SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://
-         www.secg.org/>.
-
-   [5]   IEEE, "Standard Specifications for Public Key Cryptography",
-         IEEE 1363, 2000.
-
-   [6]   ANSI, "Public Key Cryptography For The Financial Services
-         Industry: The Elliptic Curve Digital Signature Algorithm
-         (ECDSA)", ANSI X9.62, 1998.
-
-   [7]   NIST, "Secure Hash Standard", FIPS 180-2, 2002.
-
-   [8]   NIST, "Digital Signature Standard", FIPS 186-2, 2000.
-
-   [9]   RSA Laboratories, "PKCS#1: RSA Encryption Standard version
-         1.5", PKCS 1, November 1993.
-
-   [10]  SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
-         2000, <http://www.secg.org/>.
-
-   [11]  Polk, T., Housley, R. and L. Bassham, "Algorithms and
-         Identifiers for the Internet X.509 Public Key Infrastructure
-         Certificate and Certificate Revocation List (CRL) Profile", RFC
-         3279, April 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 32]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-Informative References
-
-   [12]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", Journal of Cryptology 14 (2001) 255-293, <http://
-         www.cryptosavvy.com/>.
-
-   [13]  Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
-         Version 3.0", November 1996, <http://wp.netscape.com/eng/ssl3/
-         draft302.txt>.
-
-   [14]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-         Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [15]  Hovey, R. and S. Bradner, "The Organizations Involved in the
-         IETF Standards Process", RFC 2028, BCP 11, October 1996.
-
-
-Authors' Addresses
-
-   Vipul Gupta
-   Sun Microsystems Laboratories
-   2600 Casey Avenue
-   MS UMTV29-235
-   Mountain View, CA  94303
-   USA
-
-   Phone: +1 650 336 1681
-   EMail: vipul.gupta@sun.com
-
-
-   Simon Blake-Wilson
-   Basic Commerce & Industries, Inc.
-   96 Spandia Ave
-   Unit 606
-   Toronto, ON  M6G 2T6
-   Canada
-
-   Phone: +1 416 214 5961
-   EMail: sblakewilson@bcisse.com
-
-
-   Bodo Moeller
-   TBD
-
-   EMail: moeller@cdc.informatik.tu-darmstadt.de
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 33]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-   Chris Hawk
-   Independent Consultant
-
-   EMail: chris@socialeng.com
-
-
-   Nelson Bolyard
-   Netscape
-
-   EMail: misterssl@aol.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 34]
-
-Internet-Draft          ECC Cipher Suites for TLS              Nov. 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.              Expires May 1, 2004                 [Page 35]
-
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-07.txt b/doc/protocol/draft-ietf-tls-ecc-07.txt
deleted file mode 100644
index 48c31d341e..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-07.txt
+++ /dev/null
@@ -1,1849 +0,0 @@
-
-
-TLS Working Group                                               V. Gupta
-Internet-Draft                                                  Sun Labs
-Expires: June 1, 2005                                    S. Blake-Wilson
-                                                                     BCI
-                                                              B. Moeller
-                                      University of California, Berkeley
-                                                                 C. Hawk
-                                                      Corriente Networks
-                                                              N. Bolyard
-                                                               Dec. 2004
-
-
-                       ECC Cipher Suites for TLS
-                      <draft-ietf-tls-ecc-07.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 1, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document describes new key exchange algorithms based on Elliptic
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 1]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   Curve Cryptography (ECC) for the TLS (Transport Layer Security)
-   protocol.  In particular, it specifies the use of Elliptic Curve
-   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
-   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
-   authentication mechanism.
-
-   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 [1].
-
-   Please send comments on this document to the TLS mailing list.
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Key Exchange Algorithms  . . . . . . . . . . . . . . . . . .   5
-     2.1  ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.2  ECDHE_ECDSA  . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.3  ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.4  ECDHE_RSA  . . . . . . . . . . . . . . . . . . . . . . . .   8
-     2.5  ECDH_anon  . . . . . . . . . . . . . . . . . . . . . . . .   8
-   3.   Client Authentication  . . . . . . . . . . . . . . . . . . .   9
-     3.1  ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . .   9
-     3.2  ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . .  10
-     3.3  RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . .  10
-   4.   TLS Extensions for ECC . . . . . . . . . . . . . . . . . . .  11
-   5.   Data Structures and Computations . . . . . . . . . . . . . .  12
-     5.1  Client Hello Extensions  . . . . . . . . . . . . . . . . .  12
-     5.2  Server Hello Extensions  . . . . . . . . . . . . . . . . .  15
-     5.3  Server Certificate . . . . . . . . . . . . . . . . . . . .  16
-     5.4  Server Key Exchange  . . . . . . . . . . . . . . . . . . .  17
-     5.5  Certificate Request  . . . . . . . . . . . . . . . . . . .  20
-     5.6  Client Certificate . . . . . . . . . . . . . . . . . . . .  21
-     5.7  Client Key Exchange  . . . . . . . . . . . . . . . . . . .  22
-     5.8  Certificate Verify . . . . . . . . . . . . . . . . . . . .  23
-     5.9  Elliptic Curve Certificates  . . . . . . . . . . . . . . .  25
-     5.10   ECDH, ECDSA and RSA Computations . . . . . . . . . . . .  25
-   6.   Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . .  26
-   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  28
-   8.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  29
-   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  30
-   9.1  Normative References . . . . . . . . . . . . . . . . . . . .  30
-   9.2  Informative References . . . . . . . . . . . . . . . . . . .  30
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  31
-        Intellectual Property and Copyright Statements . . . . . . .  33
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 2]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-1.  Introduction
-
-   Elliptic Curve Cryptography (ECC) is emerging as an attractive
-   public-key cryptosystem for mobile/wireless environments.  Compared
-   to currently prevalent cryptosystems such as RSA, ECC offers
-   equivalent security with smaller key sizes.  This is illustrated in
-   the following table, based on [12], which gives approximate
-   comparable key sizes for symmetric- and asymmetric-key cryptosystems
-   based on the best-known algorithms for attacking them.
-
-                   Symmetric    |  ECC    |  DH/DSA/RSA
-                   -------------+---------+------------
-                      80        |  163    |  1024
-                     112        |  233    |  2048
-                     128        |  283    |  3072
-                     192        |  409    |  7680
-                     256        |  571    |  15360
-
-                  Table 1: Comparable key sizes (in bits)
-
-
-                                Figure 1
-
-   Smaller key sizes result in power, bandwidth and computational
-   savings that make ECC especially attractive for constrained
-   environments.
-
-   This document describes additions to TLS to support ECC.  In
-   particular, it defines
-   o  the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
-      scheme with long-term or ephemeral keys to establish the TLS
-      premaster secret, and
-   o  the use of fixed-ECDH certificates and ECDSA for authentication of
-      TLS peers.
-
-   The remainder of this document is organized as follows.  Section 2
-   provides an overview of ECC-based key exchange algorithms for TLS.
-   Section 3 describes the use of ECC certificates for client
-   authentication.  TLS extensions that allow a client to negotiate the
-   use of specific curves and point formats are presented in Section 4.
-   Section 5 specifies various data structures needed for an ECC-based
-   handshake, their encoding in TLS messages and the processing of those
-   messages.  Section 6 defines new ECC-based cipher suites and
-   identifies a small subset of these as recommended for all
-   implementations of this specification.  Section 7 and Section 8
-   mention security considerations and acknowledgments, respectively.
-   This is followed by a list of references cited in this document, the
-   authors' contact information, and statements on intellectual property
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 3]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   rights and copyrights.
-
-   Implementation of this specification requires familiarity with TLS
-   [2], TLS extensions [3] and ECC [4][5][6][8] .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 4]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-2.  Key Exchange Algorithms
-
-   This document introduces five new ECC-based key exchange algorithms
-   for TLS.  All of them use ECDH to compute the TLS premaster secret
-   and differ only in the lifetime of ECDH keys (long-term or ephemeral)
-   and the mechanism (if any) used to authenticate them.  The derivation
-   of the TLS master secret from the premaster secret and the subsequent
-   generation of bulk encryption/MAC keys and initialization vectors is
-   independent of the key exchange algorithm and not impacted by the
-   introduction of ECC.
-
-   The table below summarizes the new key exchange algorithms which
-   mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]),
-   respectively.
-
-          Key
-          Exchange
-          Algorithm           Description
-          ---------           -----------
-
-          ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
-
-          ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
-
-          ECDH_RSA            Fixed ECDH with RSA-signed certificates.
-
-          ECDHE_RSA           Ephemeral ECDH with RSA signatures.
-
-          ECDH_anon           Anonymous ECDH, no signatures.
-
-
-                     Table 2: ECC key exchange algorithms
-
-
-                                Figure 2
-
-   The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
-   secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
-   certificate and easily comply with a constrained client's elliptic
-   curve preferences (see Section 4).  However, the computational cost
-   incurred by a server is higher for ECDHE_RSA than for the traditional
-   RSA key exchange which does not provide forward secrecy.
-
-   The ECDH_RSA mechanism requires a server to acquire an ECC
-   certificate but the certificate issuer can still use an existing RSA
-   key for signing.  This eliminates the need to update the trusted key
-   store in TLS clients.  The ECDH_ECDSA mechanism requires ECC keys for
-   the server as well as the certification authority and is best suited
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 5]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   for constrained devices unable to support RSA.
-
-   The anonymous key exchange algorithm does not provide authentication
-   of the server or the client.  Like other anonymous TLS key exchanges,
-   it is subject to man-in-the-middle attacks.  Implementations of this
-   algorithm SHOULD provide authentication by other means.
-
-   Note that there is no structural difference between ECDH and ECDSA
-   keys.  A certificate issuer may use X509.v3 keyUsage and
-   extendedKeyUsage extensions to restrict the use of an ECC public key
-   to certain computations.  This document refers to an ECC key as
-   ECDH-capable if its use in ECDH is permitted.  ECDSA-capable is
-   defined similarly.
-
-
-              Client                                        Server
-              ------                                        ------
-
-              ClientHello          -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                              CertificateRequest*+
-                                   <--------       ServerHelloDone
-              Certificate*+
-              ClientKeyExchange
-              CertificateVerify*+
-              [ChangeCipherSpec]
-              Finished             -------->
-                                                [ChangeCipherSpec]
-                                   <--------              Finished
-
-              Application Data     <------->      Application Data
-
-                 Figure 1: Message flow in a full TLS handshake
-                   * message is not sent under some conditions
-                   + message is not sent unless the client is
-                     authenticated
-
-
-                                Figure 3
-
-   Figure 1 shows all messages involved in the TLS key establishment
-   protocol (aka full handshake).  The addition of ECC has direct impact
-   only on the ClientHello, the ServerHello, the server's Certificate
-   message, the ServerKeyExchange, the ClientKeyExchange, the
-   CertificateRequest, the client's Certificate message, and the
-   CertificateVerify.  Next, we describe each ECC key exchange algorithm
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 6]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   in greater detail in terms of the content and processing of these
-   messages.  For ease of exposition, we defer discussion of client
-   authentication and associated messages (identified with a + in Figure
-   1) until Section 3 and of the optional ECC-specific extensions (which
-   impact the Hello messages) until Section 4.
-
-2.1  ECDH_ECDSA
-
-   In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
-   public key and be signed with ECDSA.
-
-   A ServerKeyExchange MUST NOT be sent (the server's certificate
-   contains all the necessary keying information required by the client
-   to arrive at the premaster secret).
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's long-term public key and send its public key in the
-   ClientKeyExchange message (except when using client authentication
-   algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
-   modifications from section Section 3.2 or Section 3.3 apply).
-
-   Both client and server MUST perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-2.2  ECDHE_ECDSA
-
-   In ECDHE_ECDSA, the server's certificate MUST contain an
-   ECDSA-capable public key and be signed with ECDSA.
-
-   The server MUST send its ephemeral ECDH public key and a
-   specification of the corresponding curve in the ServerKeyExchange
-   message.  These parameters MUST be signed with ECDSA using the
-   private key corresponding to the public key in the server's
-   Certificate.
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server MUST perform an ECDH operation (Section 5.10)
-   and use the resultant shared secret as the premaster secret.
-
-2.3  ECDH_RSA
-
-   This key exchange algorithm is the same as ECDH_ECDSA except the
-   server's certificate MUST be signed with RSA rather than ECDSA.
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 7]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-2.4  ECDHE_RSA
-
-   This key exchange algorithm is the same as ECDHE_ECDSA except the
-   server's certificate MUST contain an RSA public key authorized for
-   signing and the signature in the ServerKeyExchange message MUST be
-   computed with the corresponding RSA private key.  The server
-   certificate MUST be signed with RSA.
-
-2.5  ECDH_anon
-
-   In ECDH_anon, the server's Certificate, the CertificateRequest, the
-   client's Certificate, and the CertificateVerify messages MUST NOT be
-   sent.
-
-   The server MUST send an ephemeral ECDH public key and a specification
-   of the corresponding curve in the ServerKeyExchange message.  These
-   parameters MUST NOT be signed.
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server MUST perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 8]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-3.  Client Authentication
-
-   This document defines three new client authentication mechanisms
-   named after the type of client certificate involved: ECDSA_sign,
-   ECDSA_fixed_ECDH and RSA_fixed_ECDH.  The ECDSA_sign mechanism is
-   usable with any of the non-anonymous ECC key exchange algorithms
-   described in Section 2 as well as other non-anonymous (non-ECC) key
-   exchange algorithms defined in TLS [2].  The ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
-   Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
-   use of a long-term ECDH client key would jeopardize the forward
-   secrecy property of these algorithms.
-
-   The server can request ECC-based client authentication by including
-   one or more of these certificate types in its CertificateRequest
-   message.  The server MUST NOT include any certificate types that are
-   prohibited for the negotiated key exchange algorithm.  The client
-   must check if it possesses a certificate appropriate for any of the
-   methods suggested by the server and is willing to use it for
-   authentication.
-
-   If these conditions are not met, the client should send a client
-   Certificate message containing no certificates.  In this case, the
-   ClientKeyExchange should be sent as described in Section 2 and the
-   CertificateVerify should not be sent.  If the server requires client
-   authentication, it may respond with a fatal handshake failure alert.
-
-   If the client has an appropriate certificate and is willing to use it
-   for authentication, it MUST send that certificate in the client's
-   Certificate message (as per Section 5.6) and prove possession of the
-   private key corresponding to the certified key.  The process of
-   determining an appropriate certificate and proving possession is
-   different for each authentication mechanism and described below.
-
-   NOTE: It is permissible for a server to request (and the client to
-   send) a client certificate of a different type than the server
-   certificate.
-
-3.1  ECDSA_sign
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDSA-capable public key and signed with
-   ECDSA.
-
-   The client MUST prove possession of the private key corresponding to
-   the certified key by including a signature in the CertificateVerify
-   message as described in Section 5.8.
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                  [Page 9]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-3.2  ECDSA_fixed_ECDH
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDH-capable public key and that
-   certificate MUST be signed with ECDSA.  Furthermore, the client's
-   ECDH key MUST be on the same elliptic curve as the server's long-term
-   (certified) ECDH key.  This might limit use of this mechanism to
-   closed environments.  In situations where the client has an ECC key
-   on a different curve, it would have to authenticate either using
-   ECDSA_sign or a non-ECC mechanism (e.g.  RSA).  Using fixed ECDH for
-   both servers and clients is computationally more efficient than
-   mechanisms providing forward secrecy.
-
-   When using this authentication mechanism, the client MUST send an
-   empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
-   the CertificateVerify message.  The ClientKeyExchange is empty since
-   the client's ECDH public key required by the server to compute the
-   premaster secret is available inside the client's certificate.  The
-   client's ability to arrive at the same premaster secret as the server
-   (demonstrated by a successful exchange of Finished messages) proves
-   possession of the private key corresponding to the certified public
-   key and the CertificateVerify message is unnecessary.
-
-3.3  RSA_fixed_ECDH
-
-   This authentication mechanism is identical to ECDSA_fixed_ECDH except
-   the client's certificate MUST be signed with RSA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 10]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-4.  TLS Extensions for ECC
-
-   Two new TLS extensions --- (i) the Supported Elliptic Curves
-   Extension, and (ii) the Supported Point Formats Extension --- allow a
-   client to negotiate the use of specific curves and point formats
-   (e.g.  compressed v/s uncompressed), respectively.  These extensions
-   are especially relevant for constrained clients that may only support
-   a limited number of curves or point formats.  They follow the general
-   approach outlined in [3].  The client enumerates the curves and point
-   formats it supports by including the appropriate extensions in its
-   ClientHello message.  By echoing that extension in its ServerHello,
-   the server agrees to restrict its key selection or encoding to the
-   choices specified by the client.
-
-   A TLS client that proposes ECC cipher suites in its ClientHello
-   message SHOULD include these extensions.  Servers implementing ECC
-   cipher suites MUST support these extensions and negotiate the use of
-   an ECC cipher suite only if they can complete the handshake while
-   limiting themselves to the curves and compression techniques
-   enumerated by the client.  This eliminates the possibility that a
-   negotiated ECC handshake will be subsequently aborted due to a
-   client's inability to deal with the server's EC key.
-
-   These extensions MUST NOT be included if the client does not propose
-   any ECC cipher suites.  A client that proposes ECC cipher suites may
-   choose not to include these extension.  In this case, the server is
-   free to choose any one of the elliptic curves or point formats listed
-   in Section 5.  That section also describes the structure and
-   processing of these extensions in greater detail.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 11]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-5.  Data Structures and Computations
-
-   This section specifies the data structures and computations used by
-   ECC-based key mechanisms specified in Section 2, Section 3 and
-   Section 4.  The presentation language used here is the same as that
-   used in TLS [2].  Since this specification extends TLS, these
-   descriptions should be merged with those in the TLS specification and
-   any others that extend TLS.  This means that enum types may not
-   specify all possible values and structures with multiple formats
-   chosen with a select() clause may not indicate all possible cases.
-
-5.1  Client Hello Extensions
-
-   When this message is sent:
-
-   The ECC extensions SHOULD be sent along with any ClientHello message
-   that proposes ECC cipher suites.
-
-   Meaning of this message:
-
-   These extensions allow a constrained client to enumerate the elliptic
-   curves and/or point formats it supports.
-
-   Structure of this message:
-
-   The general structure of TLS extensions is described in [3] and this
-   specification adds two new types to ExtensionType.
-
-
-        enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
-
-   elliptic_curves:  Indicates the set of elliptic curves supported by
-      the client.  For this extension, the opaque extension_data field
-      contains EllipticCurveList.
-   ec_point_formats:  Indicates the set of point formats supported by
-      the client.  For this extension, the opaque extension_data field
-      contains ECPointFormatList.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 12]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-        enum {
-            sect163k1 (1), sect163r1 (2), sect163r2 (3),
-            sect193r1 (4), sect193r2 (5), sect233k1 (6),
-            sect233r1 (7), sect239k1 (8), sect283k1 (9),
-            sect283r1 (10), sect409k1 (11), sect409r1 (12),
-            sect571k1 (13), sect571r1 (14), secp160k1 (15),
-            secp160r1 (16), secp160r2 (17), secp192k1 (18),
-            secp192r1 (19), secp224k1 (20), secp224r1 (21),
-            secp256k1 (22), secp256r1 (23), secp384r1 (24),
-            secp521r1 (25), reserved (240..247),
-            arbitrary_explicit_prime_curves(253),
-            arbitrary_explicit_char2_curves(254),
-            (255)
-        } NamedCurve;
-
-   sect163k1, etc:  Indicates support of the corresponding named curve
-      specified in SEC 2 [10].  Note that many of these curves are also
-      recommended in ANSI X9.62 [6], and FIPS 186-2 [8].  Values 240
-      through 247 are reserved for private use.  Values 253 and 254
-      indicate that the client supports arbitrary prime and
-      characteristic-2 curves, respectively (the curve parameters must
-      be encoded explicitly in ECParameters).
-
-
-        struct {
-            NamedCurve elliptic_curve_list<1..2^8-1>
-        } EllipticCurveList;
-
-
-   Items in elliptic_curve_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   As an example, a client that only supports secp192r1 (aka NIST P-192)
-   and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would
-   include an elliptic_curves extension with the following octets:
-
-        00 ?? 02 13 15
-
-    A client that supports arbitrary explicit binary polynomial curves
-   would include an extension with the following octets:
-
-        00 ?? 01 fe
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 13]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-        enum { uncompressed (0), ansiX963_compressed (1),
-               ansiX963_hybrid (2), (255)
-        } ECPointFormat;
-
-        struct {
-            ECPointFormat ec_point_format_list<1..2^8-1>
-        } ECPointFormatList;
-
-   Three point formats are included in the defintion of ECPointFormat
-   above.  The uncompressed point format is the default format that
-   implementations of this document MUST support.  The
-   ansix963_compressed format reduces bandwidth by including only the
-   x-coordinate and a single bit of the y-coordinate of the point.  The
-   ansix963_hybrid format includes both the full y-coordinate and the
-   compressed y-coordinate to allow flexibility and improve efficiency
-   in some cases.  Implementations of this document MAY support the
-   ansix963_compressed and ansix963_hybrid point formats.
-
-   Items in ec_point_format_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   A client that only supports the uncompressed point format includes an
-   extension with the following octets:
-
-        00 ?? 01 00
-
-   A client that prefers the use of the ansiX963_compressed format over
-   uncompressed may indicate that preference by including an extension
-   with the following octets:
-
-        00 ?? 02 01 00
-
-   Actions of the sender:
-
-   A client that proposes ECC cipher suites in its ClientHello appends
-   these extensions (along with any others) enumerating the curves and
-   point formats it supports.
-
-   Actions of the receiver:
-
-   A server that receives a ClientHello containing one or both of these
-   extensions MUST use the client's enumerated capabilities to guide its
-   selection of an appropriate cipher suite.  One of the proposed ECC
-   cipher suites must be negotiated only if the server can successfully
-   complete the handshake while using the curves and point formats
-   supported by the client.
-
-   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 14]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   different curves for (i) the ECDSA key in its certificate, and (ii)
-   the ephemeral ECDH key in the ServerKeyExchange message.  The server
-   must consider the "elliptic_curves" extension in selecting both of
-   these curves.
-
-   If a server does not understand the "elliptic_curves" extension or is
-   unable to complete the ECC handshake while restricting itself to the
-   enumerated curves, it MUST NOT negotiate the use of an ECC cipher
-   suite.  Depending on what other cipher suites are proposed by the
-   client and supported by the server, this may result in a fatal
-   handshake failure alert due to the lack of common cipher suites.
-
-5.2  Server Hello Extensions
-
-   When this message is sent:
-
-   The ServerHello ECC extensions are sent in response to a Client Hello
-   message containing ECC extensions when negotiating an ECC cipher
-   suite.
-
-   Meaning of this message:
-
-   These extensions indicate the server's agreement to use only the
-   elliptic curves and point formats supported by the client during the
-   ECC-based key exchange.
-
-   Structure of this message:
-
-   The ECC extensions echoed by the server are the same as those in the
-   ClientHello except the "extension_data" field is empty.
-
-   For example, a server indicates its acceptance of the client's
-   elliptic_curves extension by sending an extension with the following
-   octets:
-
-        00 ?? 00 00
-
-   Actions of the sender:
-
-   A server makes sure that it can complete a proposed ECC key exchange
-   mechanism by restricting itself to the curves/point formats supported
-   by the client before sending these extensions.
-
-   Actions of the receiver:
-
-   A client that receives a ServerHello with ECC extensions proceeds
-   with an ECC key exchange assured that it will be able to handle the
-   server's EC key(s).
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 15]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-5.3  Server Certificate
-
-   When this message is sent:
-
-   This message is sent in all non-anonymous ECC-based key exchange
-   algorithms.
-
-   Meaning of this message:
-
-   This message is used to authentically convey the server's static
-   public key to the client.  The following table shows the server
-   certificate type appropriate for each key exchange algorithm.  ECC
-   public keys must be encoded in certificates as described in Section
-   5.9.
-
-   NOTE: The server's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 3 apply only to
-   the server's certificate (first in the chain).
-
-
-          Key Exchange Algorithm  Server Certificate Type
-          ----------------------  -----------------------
-
-          ECDH_ECDSA              Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDHE_ECDSA             Certificate must contain an
-                                  ECDSA-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDH_RSA                Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with RSA.
-
-          ECDHE_RSA               Certificate must contain an
-                                  RSA public key authorized for
-                                  use in digital signatures. It
-                                  must be signed with RSA.
-
-                    Table 3: Server certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS Certificate format.
-
-   Actions of the sender:
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 16]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   The server constructs an appropriate certificate chain and conveys it
-   to the client in the Certificate message.
-
-   Actions of the receiver:
-
-   The client validates the certificate chain, extracts the server's
-   public key, and checks that the key type is appropriate for the
-   negotiated key exchange algorithm.
-
-5.4  Server Key Exchange
-
-   When this message is sent:
-
-   This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
-   ECDH_anon key exchange algorithms.
-
-   Meaning of this message:
-
-   This message is used to convey the server's ephemeral ECDH public key
-   (and the corresponding elliptic curve domain parameters) to the
-   client.
-
-   Structure of this message:
-
-        enum { explicit_prime (1), explicit_char2 (2),
-               named_curve (3), (255) } ECCurveType;
-
-   explicit_prime:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a prime
-      field.
-   explicit_char2:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a
-      characteristic-2 field.
-   named_curve:  Indicates that a named curve is used.  This option
-      SHOULD be used when applicable.
-
-        struct {
-            opaque a <1..2^8-1>;
-            opaque b <1..2^8-1>;
-        } ECCurve;
-
-   a, b:  These parameters specify the coefficients of the elliptic
-      curve.  Each value contains the byte string representation of a
-      field element following the conversion routine in Section 4.3.3 of
-      ANSI X9.62 [6].
-
-        struct {
-            opaque point <1..2^8-1>;
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 17]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-        } ECPoint;
-
-   point:  This is the byte string representation of an elliptic curve
-      point following the conversion routine in Section 4.3.6 of ANSI
-      X9.62 [6].  Note that this byte string may represent an elliptic
-      curve point in compressed or uncompressed form.
-
-        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
-
-   ec_basis_trinomial:  Indicates representation of a characteristic-2
-      field using a trinomial basis.
-   ec_basis_pentanomial:  Indicates representation of a characteristic-2
-      field using a pentanomial basis.
-
-        struct {
-            ECCurveType    curve_type;
-            select (curve_type) {
-                case explicit_prime:
-                    opaque      prime_p <1..2^8-1>;
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case explicit_char2:
-                    uint16      m;
-                    ECBasisType basis;
-                    select (basis) {
-                        case ec_trinomial:
-                            opaque  k <1..2^8-1>;
-                        case ec_pentanomial:
-                            opaque  k1 <1..2^8-1>;
-                            opaque  k2 <1..2^8-1>;
-                            opaque  k3 <1..2^8-1>;
-                    };
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case named_curve:
-                    NamedCurve namedcurve;
-            };
-        } ECParameters;
-
-   curve_type:  This identifies the type of the elliptic curve domain
-      parameters.
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 18]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   prime_p:  This is the odd prime defining the field Fp.
-   curve:  Specifies the coefficients a and b of the elliptic curve E.
-   base:  Specifies the base point G on the elliptic curve.
-   order:  Specifies the order n of the base point.
-   cofactor:  Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
-      represents the number of points on the elliptic curve E defined
-      over the field Fq.
-   m:  This is the degree of the characteristic-2 field F2^m.
-   k:  The exponent k for the trinomial basis representation x^m + x^k
-      +1.
-   k1, k2, k3:  The exponents for the pentanomial representation x^m +
-      x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
-   namedcurve:  Specifies a recommended set of elliptic curve domain
-      parameters.  All enum values of NamedCurve are allowed except for
-      arbitrary_explicit_prime_curves(253) and
-      arbitrary_explicit_char2_curves(254).  These two values are only
-      allowed in the ClientHello extension.
-
-        struct {
-            ECParameters    curve_params;
-            ECPoint         public;
-        } ServerECDHParams;
-
-   curve_params:  Specifies the elliptic curve domain parameters
-      associated with the ECDH public key.
-   public:  The ephemeral ECDH public key.
-
-   The ServerKeyExchange message is extended as follows.
-
-        enum { ec_diffie_hellman } KeyExchangeAlgorithm;
-
-   ec_diffie_hellman:  Indicates the ServerKeyExchange message contains
-      an ECDH public key.
-
-        select (KeyExchangeAlgorithm) {
-            case ec_diffie_hellman:
-                ServerECDHParams    params;
-                Signature           signed_params;
-        } ServerKeyExchange;
-
-   params:  Specifies the ECDH public key and associated domain
-      parameters.
-   signed_params:  A hash of the params, with the signature appropriate
-      to that hash applied.  The private key corresponding to the
-      certified public key in the server's Certificate message is used
-      for signing.
-
-          enum { ecdsa } SignatureAlgorithm;
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 19]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-          select (SignatureAlgorithm) {
-              case ecdsa:
-                  digitally-signed struct {
-                      opaque sha_hash[sha_size];
-                  };
-          } Signature;
-
-   NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange
-   algorithm and 'anonymous' for ECDH_anon.  These cases are defined in
-   TLS [2].  SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA.  ECDSA
-   signatures are generated and verified as described in Section 5.10.
-   As per ANSI X9.62, an ECDSA signature consists of a pair of integers
-   r and s.  These integers are both converted into byte strings of the
-   same length as the curve order n using the conversion routine
-   specified in Section 4.3.1 of [6].  The two byte strings are
-   concatenated, and the result is placed in the signature field.
-
-   Actions of the sender:
-
-   The server selects elliptic curve domain parameters and an ephemeral
-   ECDH public key corresponding to these parameters according to the
-   ECKAS-DH1 scheme from IEEE 1363 [5].  It conveys this information to
-   the client in the ServerKeyExchange message using the format defined
-   above.
-
-   Actions of the recipient:
-
-   The client verifies the signature (when present) and retrieves the
-   server's elliptic curve domain parameters and ephemeral ECDH public
-   key from the ServerKeyExchange message.
-
-5.5  Certificate Request
-
-   When this message is sent:
-
-   This message is sent when requesting client authentication.
-
-   Meaning of this message:
-
-   The server uses this message to suggest acceptable client
-   authentication methods.
-
-   Structure of this message:
-
-   The TLS CertificateRequest message is extended as follows.
-
-        enum {
-            ecdsa_sign(?), rsa_fixed_ecdh(?),
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 20]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-            ecdsa_fixed_ecdh(?), (255)
-        } ClientCertificateType;
-
-   ecdsa_sign, etc Indicates that the server would like to use the
-      corresponding client authentication method specified in Section 3.
-      EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
-      ecdsa_fixed_ecdh have been left as ?.  These values will be
-      assigned when this draft progresses to RFC.  Earlier versions of
-      this draft used the values 5, 6, and 7 - however these values have
-      been removed since they are used differently by SSL 3.0 [13] and
-      their use by TLS is being deprecated.
-
-   Actions of the sender:
-
-   The server decides which client authentication methods it would like
-   to use, and conveys this information to the client using the format
-   defined above.
-
-   Actions of the receiver:
-
-   The client determines whether it has an appropriate certificate for
-   use with any of the requested methods, and decides whether or not to
-   proceed with client authentication.
-
-5.6  Client Certificate
-
-   When this message is sent:
-
-   This message is sent in response to a CertificateRequest when a
-   client has a suitable certificate.
-
-   Meaning of this message:
-
-   This message is used to authentically convey the client's static
-   public key to the server.  The following table summarizes what client
-   certificate types are appropriate for the ECC-based client
-   authentication mechanisms described in Section 3.  ECC public keys
-   must be encoded in certificates as described in Section 5.9.
-
-   NOTE: The client's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 4 apply only to
-   the client's certificate (first in the chain).
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 21]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-          Client
-          Authentication Method   Client Certificate Type
-          ---------------------   -----------------------
-
-          ECDSA_sign              Certificate must contain an
-                                  ECDSA-capable public key and
-                                  be signed with ECDSA.
-
-          ECDSA_fixed_ECDH        Certificate must contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  must be signed with ECDSA.
-
-          RSA_fixed_ECDH          Certificate must contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  must be signed with RSA.
-
-                     Table 4: Client certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS client Certificate format.
-
-   Actions of the sender:
-
-   The client constructs an appropriate certificate chain, and conveys
-   it to the server in the Certificate message.
-
-   Actions of the receiver:
-
-   The TLS server validates the certificate chain, extracts the client's
-   public key, and checks that the key type is appropriate for the
-   client authentication method.
-
-5.7  Client Key Exchange
-
-   When this message is sent:
-
-   This message is sent in all key exchange algorithms.  If client
-   authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
-   message is empty.  Otherwise, it contains the client's ephemeral ECDH
-   public key.
-
-   Meaning of the message:
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 22]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   This message is used to convey ephemeral data relating to the key
-   exchange belonging to the client (such as its ephemeral ECDH public
-   key).
-
-   Structure of this message:
-
-   The TLS ClientKeyExchange message is extended as follows.
-
-        enum { yes, no } EphemeralPublicKey;
-
-   yes, no:  Indicates whether or not the client is providing an
-      ephemeral ECDH public key.  (In ECC ciphersuites, this is "yes"
-      except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH
-      client authentication mechanism.)
-
-        struct {
-            select (EphemeralPublicKey) {
-                case yes: ECPoint  ecdh_Yc;
-                case no:  struct { };
-            } ecdh_public;
-        } ClientECDiffieHellmanPublic;
-
-   ecdh_Yc:  Contains the client's ephemeral ECDH public key.
-
-        struct {
-            select (KeyExchangeAlgorithm) {
-                case ec_diffie_hellman: ClientECDiffieHellmanPublic;
-            } exchange_keys;
-        } ClientKeyExchange;
-
-   Actions of the sender:
-
-   The client selects an ephemeral ECDH public key corresponding to the
-   parameters it received from the server according to the ECKAS-DH1
-   scheme from IEEE 1363 [5].  It conveys this information to the client
-   in the ClientKeyExchange message using the format defined above.
-
-   Actions of the recipient:
-
-   The server retrieves the client's ephemeral ECDH public key from the
-   ClientKeyExchange message and checks that it is on the same elliptic
-   curve as the server's ECDH key.
-
-5.8  Certificate Verify
-
-   When this message is sent:
-
-   This message is sent when the client sends a client certificate
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 23]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   containing a public key usable for digital signatures, e.g.  when the
-   client is authenticated using the ECDSA_sign mechanism.
-
-   Meaning of the message:
-
-   This message contains a signature that proves possession of the
-   private key corresponding to the public key in the client's
-   Certificate message.
-
-   Structure of this message:
-
-   The TLS CertificateVerify message is extended as follows.
-
-        enum { ecdsa } SignatureAlgorithm;
-
-        select (SignatureAlgorithm) {
-            case ecdsa:
-                digitally-signed struct {
-                    opaque sha_hash[sha_size];
-                };
-        } Signature;
-
-   For the ecdsa case, the signature field in the CertificateVerify
-   message contains an ECDSA signature computed over handshake messages
-   exchanged so far.  ECDSA signatures are computed as described in
-   Section 5.10.  As per ANSI X9.62, an ECDSA signature consists of a
-   pair of integers r and s.  These integers are both converted into
-   byte strings of the same length as the curve order n using the
-   conversion routine specified in Section 4.3.1 of [6].  The two byte
-   strings are concatenated, and the result is placed in the signature
-   field.
-
-   Actions of the sender:
-
-   The client computes its signature over all handshake messages sent or
-   received starting at client hello up to but not including this
-   message.  It uses the private key corresponding to its certified
-   public key to compute the signature which is conveyed in the format
-   defined above.
-
-   Actions of the receiver:
-
-   The server extracts the client's signature from the CertificateVerify
-   message, and verifies the signature using the public key it received
-   in the client's Certificate message.
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 24]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-5.9  Elliptic Curve Certificates
-
-   X509 certificates containing ECC public keys or signed using ECDSA
-   MUST comply with [11] or another RFC that replaces or extends it.
-   Clients SHOULD use the elliptic curve domain parameters recommended
-   in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
-
-5.10  ECDH, ECDSA and RSA Computations
-
-   All ECDH calculations (including parameter and key generation as well
-   as the shared secret calculation) MUST be performed according to [5]
-   using the ECKAS-DH1 scheme with the identity map as key derivation
-   function, so that the premaster secret is the x-coordinate of the
-   ECDH shared secret elliptic curve point, i.e.  the octet string Z in
-   IEEE 1363 terminology.
-
-   Note that a new extension may be introduced in the future to allow
-   the use of a different KDF during computation of the premaster
-   secret.  In this event, the new KDF would be used in place of the
-   process detailed above.  This may be desirable, for example, to
-   support compatibility with the planned NIST key agreement standard.
-
-   All ECDSA computations MUST be performed according to ANSI X9.62 [6]
-   or its successors.  Data to be signed/verified is hashed and the
-   result run directly through the ECDSA algorithm with no additional
-   hashing.  The default hash function is SHA-1 [7] and sha_size (see
-   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
-   function, such as one of the new SHA hash functions specified in FIPS
-   180-2 [7], may be used instead if the certificate containing the EC
-   public key explicitly requires use of another hash function.  (The
-   mechanism for specifying the required hash function has not been
-   standardized but this provision anticipates such standardization and
-   obviates the need to update this document in response.  Future PKIX
-   RFCs may choose, for example, to specify the hash function to be used
-   with a public key in the parameters field of subjectPublicKeyInfo.)
-
-   All RSA signatures must be generated and verified according to PKCS#1
-   [9].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 25]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-6.  Cipher Suites
-
-   The table below defines new ECC cipher suites that use the key
-   exchange algorithms specified in Section 2.
-
-     CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA           = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA    = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA       = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA             = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_anon_NULL_WITH_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-                        Table 5: TLS ECC cipher suites
-
-
-                               Figure 30
-
-   The key exchange method, cipher, and hash algorithm for each of these
-   cipher suites are easily determined by examining the name.  Ciphers
-   other than AES ciphers, and hash algorithms are defined in [2].  AES
-   ciphers are defined in [14].
-
-   Server implementations SHOULD support all of the following cipher
-   suites, and client implementations SHOULD support at least one of
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 26]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
-   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 27]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-7.  Security Considerations
-
-   This document is based on [2], [5], [6] and [14].  The appropriate
-   security considerations of those documents apply.
-
-   One important issue that implementors and users must consider is
-   elliptic curve selection.  Guidance on selecting an appropriate
-   elliptic curve size is given in Figure 1.
-
-   Beyond elliptic curve size, the main issue is elliptic curve
-   structure.  As a general principle, it is more conservative to use
-   elliptic curves with as little algebraic structure as possible - thus
-   random curves are more conservative than special curves such as
-   Koblitz curves, and curves over F_p with p random are more
-   conservative than curves over F_p with p of a special form (and
-   curves over F_p with p random might be considered more conservative
-   than curves over F_2^m as there is no choice between multiple fields
-   of similar size for characteristic 2).  Note, however, that algebraic
-   structure can also lead to implementation efficiencies and
-   implementors and users may, therefore, need to balance conservatism
-   against a need for efficiency.  Concrete attacks are known against
-   only very few special classes of curves, such as supersingular
-   curves, and these classes are excluded from the ECC standards that
-   this document references [5], [6].
-
-   Another issue is the potential for catastrophic failures when a
-   single elliptic curve is widely used.  In this case, an attack on the
-   elliptic curve might result in the compromise of a large number of
-   keys.  Again, this concern may need to be balanced against efficiency
-   and interoperability improvements associated with widely-used curves.
-   Substantial additional information on elliptic curve choice can be
-   found in [4], [5], [6], [8].
-
-   Implementors and users must also consider whether they need forward
-   secrecy.  Forward secrecy refers to the property that session keys
-   are not compromised if the static, certified keys belonging to the
-   server and client are compromised.  The ECDHE_ECDSA and ECDHE_RSA key
-   exchange algorithms provide forward secrecy protection in the event
-   of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
-   Similarly if the client is providing a static, certified key,
-   ECDSA_sign client authentication provides forward secrecy protection
-   in the event of client key compromise, while ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH do not.  Thus to obtain complete forward secrecy
-   protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
-   with ECDSA_sign used for client authentication if necessary.  Here
-   again the security benefits of forward secrecy may need to be
-   balanced against the improved efficiency offered by other options.
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 28]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-8.  Acknowledgments
-
-   The authors wish to thank Bill Anderson and Tim Dierks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 29]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-         2246, January 1999.
-
-   [3]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
-         T. Wright, "Transport Layer Security (TLS) Extensions",
-         draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004.
-
-   [4]   SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
-         <http://www.secg.org/>.
-
-   [5]   IEEE, "Standard Specifications for Public Key Cryptography",
-         IEEE 1363, 2000.
-
-   [6]   ANSI, "Public Key Cryptography For The Financial Services
-         Industry: The Elliptic Curve Digital Signature Algorithm
-         (ECDSA)", ANSI X9.62, 1998.
-
-   [7]   NIST, "Secure Hash Standard", FIPS 180-2, 2002.
-
-   [8]   NIST, "Digital Signature Standard", FIPS 186-2, 2000.
-
-   [9]   RSA Laboratories, "PKCS#1: RSA Encryption Standard version
-         1.5", PKCS 1, November 1993.
-
-   [10]  SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
-         2000, <http://www.secg.org/>.
-
-   [11]  Polk, T., Housley, R. and L. Bassham, "Algorithms and
-         Identifiers for the Internet X.509 Public Key Infrastructure
-         Certificate and Certificate Revocation List (CRL) Profile", RFC
-         3279, April 2002.
-
-9.2  Informative References
-
-   [12]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", Journal of Cryptology 14 (2001) 255-293,
-         <http://www.cryptosavvy.com/>.
-
-   [13]  Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol
-         Version 3.0", November 1996,
-         <http://wp.netscape.com/eng/ssl3/draft302.txt>.
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 30]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   [14]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-         Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [15]  Hovey, R. and S. Bradner, "The Organizations Involved in the
-         IETF Standards Process", RFC 2028, BCP 11, October 1996.
-
-
-Authors' Addresses
-
-   Vipul Gupta
-   Sun Microsystems Laboratories
-   16 Network Circle
-   MS UMPK16-160
-   Menlo Park, CA  94025
-   USA
-
-   Phone: +1 650 786 7551
-   EMail: vipul.gupta@sun.com
-
-
-   Simon Blake-Wilson
-   Basic Commerce & Industries, Inc.
-   96 Spandia Ave
-   Unit 606
-   Toronto, ON  M6G 2T6
-   Canada
-
-   Phone: +1 416 214 5961
-   EMail: sblakewilson@bcisse.com
-
-
-   Bodo Moeller
-   University of California, Berkeley
-   EECS -- Computer Science Division
-   513 Soda Hall
-   Berkeley, CA  94720-1776
-   USA
-
-   EMail: bodo@openssl.org
-
-
-   Chris Hawk
-   Corriente Networks
-
-   EMail: chris@corriente.net
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 31]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-   Nelson Bolyard
-
-   EMail: nelson@bolyard.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 32]
-
-Internet-Draft         ECC Cipher Suites for TLS               Dec. 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Gupta, et al.             Expires June 1, 2005                 [Page 33]
-
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-09.txt b/doc/protocol/draft-ietf-tls-ecc-09.txt
deleted file mode 100644
index 8efbae5f95..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-09.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-TLS Working Group                                               V. Gupta
-Internet-Draft                                                  Sun Labs
-Expires: October 9, 2005                                 S. Blake-Wilson
-                                                                     BCI
-                                                              B. Moeller
-                                                   University of Calgary
-                                                                 C. Hawk
-                                                      Corriente Networks
-                                                              N. Bolyard
-                                                           April 7, 2005
-
-
-                       ECC Cipher Suites for TLS
-                      <draft-ietf-tls-ecc-09.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 9, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 1]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   This document describes new key exchange algorithms based on Elliptic
-   Curve Cryptography (ECC) for the TLS (Transport Layer Security)
-   protocol.  In particular, it specifies the use of Elliptic Curve
-   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
-   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
-   authentication mechanism.
-
-   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 [1].
-
-   Please send comments on this document to the TLS mailing list.
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Key Exchange Algorithms  . . . . . . . . . . . . . . . . . .   5
-     2.1  ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.2  ECDHE_ECDSA  . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.3  ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.4  ECDHE_RSA  . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.5  ECDH_anon  . . . . . . . . . . . . . . . . . . . . . . . .   8
-   3.   Client Authentication  . . . . . . . . . . . . . . . . . . .   9
-     3.1  ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . .   9
-     3.2  ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . .  10
-     3.3  RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . .  10
-   4.   TLS Extensions for ECC . . . . . . . . . . . . . . . . . . .  11
-   5.   Data Structures and Computations . . . . . . . . . . . . . .  12
-     5.1  Client Hello Extensions  . . . . . . . . . . . . . . . . .  12
-     5.2  Server Hello Extension . . . . . . . . . . . . . . . . . .  15
-     5.3  Server Certificate . . . . . . . . . . . . . . . . . . . .  16
-     5.4  Server Key Exchange  . . . . . . . . . . . . . . . . . . .  18
-     5.5  Certificate Request  . . . . . . . . . . . . . . . . . . .  22
-     5.6  Client Certificate . . . . . . . . . . . . . . . . . . . .  23
-     5.7  Client Key Exchange  . . . . . . . . . . . . . . . . . . .  24
-     5.8  Certificate Verify . . . . . . . . . . . . . . . . . . . .  25
-     5.9  Elliptic Curve Certificates  . . . . . . . . . . . . . . .  26
-     5.10   ECDH, ECDSA and RSA Computations . . . . . . . . . . . .  26
-   6.   Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . .  28
-   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  30
-   8.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  31
-   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  32
-     9.1  Normative References . . . . . . . . . . . . . . . . . . .  32
-     9.2  Informative References . . . . . . . . . . . . . . . . . .  32
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  33
-        Intellectual Property and Copyright Statements . . . . . . .  35
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 2]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-1.  Introduction
-
-   Elliptic Curve Cryptography (ECC) is emerging as an attractive
-   public-key cryptosystem for mobile/wireless environments.  Compared
-   to currently prevalent cryptosystems such as RSA, ECC offers
-   equivalent security with smaller key sizes.  This is illustrated in
-   the following table, based on [13], which gives approximate
-   comparable key sizes for symmetric- and asymmetric-key cryptosystems
-   based on the best-known algorithms for attacking them.
-
-                   Symmetric    |  ECC    |  DH/DSA/RSA
-                   -------------+---------+------------
-                      80        |  163    |  1024
-                     112        |  233    |  2048
-                     128        |  283    |  3072
-                     192        |  409    |  7680
-                     256        |  571    |  15360
-
-                  Table 1: Comparable key sizes (in bits)
-
-
-   Smaller key sizes result in power, bandwidth and computational
-   savings that make ECC especially attractive for constrained
-   environments.
-
-   This document describes additions to TLS to support ECC.  In
-   particular, it defines
-
-   o  the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
-      scheme with long-term or ephemeral keys to establish the TLS
-      premaster secret, and
-
-   o  the use of fixed-ECDH certificates and ECDSA for authentication of
-      TLS peers.
-
-   The remainder of this document is organized as follows.  Section 2
-   provides an overview of ECC-based key exchange algorithms for TLS.
-   Section 3 describes the use of ECC certificates for client
-   authentication.  TLS extensions that allow a client to negotiate the
-   use of specific curves and point formats are presented in Section 4.
-   Section 5 specifies various data structures needed for an ECC-based
-   handshake, their encoding in TLS messages and the processing of those
-   messages.  Section 6 defines new ECC-based cipher suites and
-   identifies a small subset of these as recommended for all
-   implementations of this specification.  Section 7 and Section 8
-   mention security considerations and acknowledgments, respectively.
-   This is followed by a list of references cited in this document, the
-   authors' contact information, and statements on intellectual property
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 3]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   rights and copyrights.
-
-   Implementation of this specification requires familiarity with TLS
-   [2], TLS extensions [3] and ECC [4][5][6][8].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 4]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-2.  Key Exchange Algorithms
-
-   This document introduces five new ECC-based key exchange algorithms
-   for TLS.  All of them use ECDH to compute the TLS premaster secret
-   and differ only in the lifetime of ECDH keys (long-term or ephemeral)
-   and the mechanism (if any) used to authenticate them.  The derivation
-   of the TLS master secret from the premaster secret and the subsequent
-   generation of bulk encryption/MAC keys and initialization vectors is
-   independent of the key exchange algorithm and not impacted by the
-   introduction of ECC.
-
-   The table below summarizes the new key exchange algorithms which
-   mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]),
-   respectively.
-
-          Key
-          Exchange
-          Algorithm           Description
-          ---------           -----------
-
-          ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
-
-          ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
-
-          ECDH_RSA            Fixed ECDH with RSA-signed certificates.
-
-          ECDHE_RSA           Ephemeral ECDH with RSA signatures.
-
-          ECDH_anon           Anonymous ECDH, no signatures.
-
-                     Table 2: ECC key exchange algorithms
-
-
-   The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
-   secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
-   certificate and easily comply with a constrained client's elliptic
-   curve preferences (see Section 4).  However, the computational cost
-   incurred by a server is higher for ECDHE_RSA than for the traditional
-   RSA key exchange which does not provide forward secrecy.
-
-   The ECDH_RSA mechanism requires a server to acquire an ECC
-   certificate but the certificate issuer can still use an existing RSA
-   key for signing.  This eliminates the need to update the trusted key
-   store in TLS clients.  The ECDH_ECDSA mechanism requires ECC keys for
-   the server as well as the certification authority and is best suited
-   for constrained devices unable to support RSA.
-
-   The anonymous key exchange algorithm does not provide authentication
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 5]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   of the server or the client.  Like other anonymous TLS key exchanges,
-   it is subject to man-in-the-middle attacks.  Implementations of this
-   algorithm SHOULD provide authentication by other means.
-
-   Note that there is no structural difference between ECDH and ECDSA
-   keys.  A certificate issuer may use X509.v3 keyUsage and
-   extendedKeyUsage extensions to restrict the use of an ECC public key
-   to certain computations.  This document refers to an ECC key as ECDH-
-   capable if its use in ECDH is permitted.  ECDSA-capable is defined
-   similarly.
-
-
-              Client                                        Server
-              ------                                        ------
-
-              ClientHello          -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                              CertificateRequest*+
-                                   <--------       ServerHelloDone
-              Certificate*+
-              ClientKeyExchange
-              CertificateVerify*+
-              [ChangeCipherSpec]
-              Finished             -------->
-                                                [ChangeCipherSpec]
-                                   <--------              Finished
-
-              Application Data     <------->      Application Data
-
-
-                   * message is not sent under some conditions
-                   + message is not sent unless client authentication
-                     is desired
-
-                 Figure 1: Message flow in a full TLS handshake
-
-
-   Figure 1 shows all messages involved in the TLS key establishment
-   protocol (aka full handshake).  The addition of ECC has direct impact
-   only on the ClientHello, the ServerHello, the server's Certificate
-   message, the ServerKeyExchange, the ClientKeyExchange, the
-   CertificateRequest, the client's Certificate message, and the
-   CertificateVerify.  Next, we describe each ECC key exchange algorithm
-   in greater detail in terms of the content and processing of these
-   messages.  For ease of exposition, we defer discussion of client
-   authentication and associated messages (identified with a + in
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 6]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   Figure 1) until Section 3 and of the optional ECC-specific extensions
-   (which impact the Hello messages) until Section 4.
-
-2.1  ECDH_ECDSA
-
-   In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
-   public key and be signed with ECDSA.
-
-   A ServerKeyExchange MUST NOT be sent (the server's certificate
-   contains all the necessary keying information required by the client
-   to arrive at the premaster secret).
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's long-term public key and send its public key in the
-   ClientKeyExchange message (except when using client authentication
-   algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
-   modifications from section Section 3.2 or Section 3.3 apply).
-
-   Both client and server MUST perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-2.2  ECDHE_ECDSA
-
-   In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
-   capable public key and be signed with ECDSA.
-
-   The server MUST send its ephemeral ECDH public key and a
-   specification of the corresponding curve in the ServerKeyExchange
-   message.  These parameters MUST be signed with ECDSA using the
-   private key corresponding to the public key in the server's
-   Certificate.
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server MUST perform an ECDH operation (Section 5.10)
-   and use the resultant shared secret as the premaster secret.
-
-2.3  ECDH_RSA
-
-   This key exchange algorithm is the same as ECDH_ECDSA except the
-   server's certificate MUST be signed with RSA rather than ECDSA.
-
-2.4  ECDHE_RSA
-
-   This key exchange algorithm is the same as ECDHE_ECDSA except the
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 7]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   server's certificate MUST contain an RSA public key authorized for
-   signing and the signature in the ServerKeyExchange message MUST be
-   computed with the corresponding RSA private key.  The server
-   certificate MUST be signed with RSA.
-
-2.5  ECDH_anon
-
-   In ECDH_anon, the server's Certificate, the CertificateRequest, the
-   client's Certificate, and the CertificateVerify messages MUST NOT be
-   sent.
-
-   The server MUST send an ephemeral ECDH public key and a specification
-   of the corresponding curve in the ServerKeyExchange message.  These
-   parameters MUST NOT be signed.
-
-   The client MUST generate an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server MUST perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 8]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-3.  Client Authentication
-
-   This document defines three new client authentication mechanisms
-   named after the type of client certificate involved: ECDSA_sign,
-   ECDSA_fixed_ECDH and RSA_fixed_ECDH.  The ECDSA_sign mechanism is
-   usable with any of the non-anonymous ECC key exchange algorithms
-   described in Section 2 as well as other non-anonymous (non-ECC) key
-   exchange algorithms defined in TLS [2].  The ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
-   Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
-   use of a long-term ECDH client key would jeopardize the forward
-   secrecy property of these algorithms.
-
-   The server can request ECC-based client authentication by including
-   one or more of these certificate types in its CertificateRequest
-   message.  The server MUST NOT include any certificate types that are
-   prohibited for the negotiated key exchange algorithm.  The client
-   must check if it possesses a certificate appropriate for any of the
-   methods suggested by the server and is willing to use it for
-   authentication.
-
-   If these conditions are not met, the client should send a client
-   Certificate message containing no certificates.  In this case, the
-   ClientKeyExchange should be sent as described in Section 2 and the
-   CertificateVerify should not be sent.  If the server requires client
-   authentication, it may respond with a fatal handshake failure alert.
-
-   If the client has an appropriate certificate and is willing to use it
-   for authentication, it MUST send that certificate in the client's
-   Certificate message (as per Section 5.6) and prove possession of the
-   private key corresponding to the certified key.  The process of
-   determining an appropriate certificate and proving possession is
-   different for each authentication mechanism and described below.
-
-   NOTE: It is permissible for a server to request (and the client to
-   send) a client certificate of a different type than the server
-   certificate.
-
-3.1  ECDSA_sign
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDSA-capable public key and signed with
-   ECDSA.
-
-   The client MUST prove possession of the private key corresponding to
-   the certified key by including a signature in the CertificateVerify
-   message as described in Section 5.8.
-
-
-
-
-Gupta, et al.            Expires October 9, 2005                [Page 9]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-3.2  ECDSA_fixed_ECDH
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDH-capable public key and that
-   certificate MUST be signed with ECDSA.  Furthermore, the client's
-   ECDH key MUST be on the same elliptic curve as the server's long-term
-   (certified) ECDH key.  This might limit use of this mechanism to
-   closed environments.  In situations where the client has an ECC key
-   on a different curve, it would have to authenticate either using
-   ECDSA_sign or a non-ECC mechanism (e.g.  RSA).  Using fixed ECDH for
-   both servers and clients is computationally more efficient than
-   mechanisms providing forward secrecy.
-
-   When using this authentication mechanism, the client MUST send an
-   empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
-   the CertificateVerify message.  The ClientKeyExchange is empty since
-   the client's ECDH public key required by the server to compute the
-   premaster secret is available inside the client's certificate.  The
-   client's ability to arrive at the same premaster secret as the server
-   (demonstrated by a successful exchange of Finished messages) proves
-   possession of the private key corresponding to the certified public
-   key and the CertificateVerify message is unnecessary.
-
-3.3  RSA_fixed_ECDH
-
-   This authentication mechanism is identical to ECDSA_fixed_ECDH except
-   the client's certificate MUST be signed with RSA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 10]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-4.  TLS Extensions for ECC
-
-   Two new TLS extensions are defined in this specification: (i) the
-   Supported Elliptic Curves Extension, and (ii) the Supported Point
-   Formats Extension.  These allow negotiating the use of specific
-   curves and point formats (e.g. compressed vs. uncompressed),
-   respectively, during a handshake starting a new session.  These
-   extensions are especially relevant for constrained clients that may
-   only support a limited number of curves or point formats.  They
-   follow the general approach outlined in [3]; message details are
-   specified in Section 5.  The client enumerates the curves it supports
-   and the point formats it can parse by including the appropriate
-   extensions in its ClientHello message.  The server similarly
-   enumerates the point formats it can parse by including an extension
-   in its ServerHello message.
-
-   A TLS client that proposes ECC cipher suites in its ClientHello
-   message SHOULD include these extensions.  Servers implementing ECC
-   cipher suites MUST support these extensions, and when a client uses
-   these extensions, servers MUST NOT negotiate the use of an ECC cipher
-   suite unless they can complete the handshake while respecting the
-   choice of curves and compression techniques specified by the client.
-   This eliminates the possibility that a negotiated ECC handshake will
-   be subsequently aborted due to a client's inability to deal with the
-   server's EC key.
-
-   These extensions MUST NOT be included if the client does not propose
-   any ECC cipher suites.  A client that proposes ECC cipher suites may
-   choose not to include these extension.  In this case, the server is
-   free to choose any one of the elliptic curves or point formats listed
-   in Section 5.  That section also describes the structure and
-   processing of these extensions in greater detail.
-
-   In the case of session resumption, the server simply ignores the
-   Supported Elliptic Curves Extension and the Supported Point Formats
-   Extension as appearing in the current ClientHello message.  These
-   extensions only play a role during handshakes negotiating a new
-   session.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 11]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-5.  Data Structures and Computations
-
-   This section specifies the data structures and computations used by
-   ECC-based key mechanisms specified in Section 2, Section 3 and
-   Section 4.  The presentation language used here is the same as that
-   used in TLS [2].  Since this specification extends TLS, these
-   descriptions should be merged with those in the TLS specification and
-   any others that extend TLS.  This means that enum types may not
-   specify all possible values and structures with multiple formats
-   chosen with a select() clause may not indicate all possible cases.
-
-5.1  Client Hello Extensions
-
-   This section specifies two TLS extensions that can be included with
-   the ClientHello message as described in [3], the Supported Elliptic
-   Curves Extension and the Supported Point Formats Extension.
-
-   When these extensions are sent:
-
-   The extensions SHOULD be sent along with any ClientHello message that
-   proposes ECC cipher suites.
-
-   Meaning of these extensions:
-
-   These extensions allow a client to enumerate the elliptic curves it
-   supports and/or the point formats it can parse.
-
-   Structure of these extensions:
-
-   The general structure of TLS extensions is described in [3] and this
-   specification adds two new types to ExtensionType.
-
-
-       enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
-
-   [[ EDITOR: The values used for elliptic_curves and ec_point_formats
-   have been left as ??.  These values will be assigned when this draft
-   progresses to RFC.  (The examples below will have to be changed
-   accordingly.) ]]
-
-   elliptic_curves (Supported Elliptic Curves Extension):  Indicates the
-      set of elliptic curves supported by the client.  For this
-      extension, the opaque extension_data field contains
-      EllipticCurveList.
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 12]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   ec_point_formats (Supported Point Formats Extension):  Indicates the
-      set of point formats that the client can parse.  For this
-      extension, the opaque extension_data field contains
-      ECPointFormatList.
-
-
-        enum {
-            sect163k1 (1), sect163r1 (2), sect163r2 (3),
-            sect193r1 (4), sect193r2 (5), sect233k1 (6),
-            sect233r1 (7), sect239k1 (8), sect283k1 (9),
-            sect283r1 (10), sect409k1 (11), sect409r1 (12),
-            sect571k1 (13), sect571r1 (14), secp160k1 (15),
-            secp160r1 (16), secp160r2 (17), secp192k1 (18),
-            secp192r1 (19), secp224k1 (20), secp224r1 (21),
-            secp256k1 (22), secp256r1 (23), secp384r1 (24),
-            secp521r1 (25), reserved (240..247),
-            arbitrary_explicit_prime_curves(253),
-            arbitrary_explicit_char2_curves(254),
-            (255)
-        } NamedCurve;
-
-   sect163k1, etc:  Indicates support of the corresponding named curve
-      specified in SEC 2 [10].  Note that many of these curves are also
-      recommended in ANSI X9.62 [6], and FIPS 186-2 [8].  Values 240
-      through 247 are reserved for private use.  Values 253 and 254
-      indicate that the client supports arbitrary prime and
-      characteristic-2 curves, respectively (the curve parameters must
-      be encoded explicitly in ECParameters).
-
-
-        struct {
-            NamedCurve elliptic_curve_list<1..2^8-1>
-        } EllipticCurveList;
-
-
-   Items in elliptic_curve_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   As an example, a client that only supports secp192r1 (aka NIST P-192;
-   value 19 = 0x13) and secp224r1 (aka NIST P-224; value 21 = 0x15) and
-   prefers to use secp192r1 would include a TLS extension consisting of
-   the following octets:
-
-        00 ?? 00 03 02 13 15
-
-   A client that supports arbitrary explicit characteristic-2 curves
-   (value 254 = 0xFE) would include an extension consisting of the
-   following octets:
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 13]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-        00 ?? 00 02 01 FE
-
-
-        enum { uncompressed (0), ansiX962_compressed (1),
-               ansiX962_hybrid (2), reserved (3 .. 255)
-        } ECPointFormat;
-
-        struct {
-            ECPointFormat ec_point_format_list<1..2^8-1>
-        } ECPointFormatList;
-
-   Three point formats are included in the definition of ECPointFormat
-   above.  The uncompressed point format is the default format in that
-   implementations of this document MUST support it.  The
-   ansiX962_compressed format reduces bandwidth by including only the
-   x-coordinate and a single bit of the y-coordinate of the point.  The
-   ansiX962_hybrid format includes both the full y-coordinate and the
-   compressed y-coordinate to allow flexibility and improve efficiency
-   in some cases.  Implementations of this document MAY support the
-   ansiX962_compressed and ansiX962_hybrid point formats.  (These three
-   formats are described in [6].)  Values 248 through 255 are reserved
-   for private use.
-
-   Items in ec_point_format_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   A client that can parse only the uncompressed point format includes
-   an extension consisting of the following octets:
-
-        00 ?? 00 02 01 00
-
-   A client that prefers the use of the ansiX962_compressed format over
-   uncompressed may indicate that preference by including an extension
-   consisting of the following octets:
-
-        00 ?? 00 03 02 01 00
-
-   Actions of the sender:
-
-   A client that proposes ECC cipher suites in its ClientHello message
-   appends these extensions (along with any others), enumerating the
-   curves it supports and the point formats it can parse.  Clients
-   SHOULD send both the Supported Elliptic Curves Extension and the
-   Supported Point Formats Extension.  If the Supported Point Formats
-   Extension is indeed sent, it MUST contain the value 0 (uncompressed)
-   as one of the items in the list of point formats.
-
-   Actions of the receiver:
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 14]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   A server that receives a ClientHello containing one or both of these
-   extensions MUST use the client's enumerated capabilities to guide its
-   selection of an appropriate cipher suite.  One of the proposed ECC
-   cipher suites must be negotiated only if the server can successfully
-   complete the handshake while using the curves and point formats
-   supported by the client (cf. Section 5.3 and Section 5.4).
-
-   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
-   different curves for (i) the ECDSA key in its certificate, and (ii)
-   the ephemeral ECDH key in the ServerKeyExchange message.  The server
-   must consider the "elliptic_curves" extension in selecting both of
-   these curves.
-
-   If a server does not understand the "elliptic_curves" extension or is
-   unable to complete the ECC handshake while restricting itself to the
-   enumerated curves, it MUST NOT negotiate the use of an ECC cipher
-   suite.  Depending on what other cipher suites are proposed by the
-   client and supported by the server, this may result in a fatal
-   handshake failure alert due to the lack of common cipher suites.
-
-5.2  Server Hello Extension
-
-   This section specifies a TLS extension that can be included with the
-   ServerHello message as described in [3], the Supported Point Formats
-   Extension.
-
-   When this extension is sent:
-
-   The Supported Point Formats Extension is included in a ServerHello
-   message in response to a ClientHello message containing the Supported
-   Point Formats Extension when negotiating an ECC cipher suite.
-
-   Meaning of this extensions:
-
-   This extension allows a server to enumerate the point formats it can
-   parse (for the curve that will appear in its ServerKeyExchange
-   message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
-   exchange algorithm, or for the curve that is used in the server's
-   public key that will appear in its Certificate message when using the
-   ECDH_ECDSA or ECDH_RSA key exchange algorithm).
-
-   Structure of this extension:
-
-   The server's Supported Point Formats Extension has the same structure
-   as the client's Supported Point Formats Extension.  Items in
-   elliptic_curve_list here are ordered according to the server's
-   preference (favorite choice first).  Note that the server may include
-   items that were not found in the client's list (e.g., the server may
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 15]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   prefer to receive points in compressed format even when a client
-   cannot parse this format: the same client may nevertheless be capable
-   to output points in compressed format).
-
-   Actions of the sender:
-
-   A server that selects an ECC cipher suite in response to a
-   ClientHello message including a Supported Point Formats Extension
-   appends this extension (along with others) to its ServerHello
-   message, enumerating the point formats it can parse.  The Supported
-   Point Formats Extension, when used, MUST contain the value 0
-   (uncompressed) as one of the items in the list of point formats.
-
-   Actions of the receiver:
-
-   A client that receives a ServerHello message containing a Supported
-   Point Formats Extension MUST respect the server's choice of point
-   formats during the handshake (cf. Section 5.6 and Section 5.7).  If
-   no Supported Point Formats Extension is received with the
-   ServerHello, this is equivalent to an extension allowing only the
-   uncompressed point format.
-
-5.3  Server Certificate
-
-   When this message is sent:
-
-   This message is sent in all non-anonymous ECC-based key exchange
-   algorithms.
-
-   Meaning of this message:
-
-   This message is used to authentically convey the server's static
-   public key to the client.  The following table shows the server
-   certificate type appropriate for each key exchange algorithm.  ECC
-   public keys must be encoded in certificates as described in
-   Section 5.9.
-
-   NOTE: The server's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 3 apply only to
-   the server's certificate (first in the chain).
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 16]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-          Key Exchange Algorithm  Server Certificate Type
-          ----------------------  -----------------------
-
-          ECDH_ECDSA              Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDHE_ECDSA             Certificate must contain an
-                                  ECDSA-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDH_RSA                Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with RSA.
-
-          ECDHE_RSA               Certificate must contain an
-                                  RSA public key authorized for
-                                  use in digital signatures. It
-                                  must be signed with RSA.
-
-                    Table 3: Server certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS Certificate format.
-
-   Actions of the sender:
-
-   The server constructs an appropriate certificate chain and conveys it
-   to the client in the Certificate message.  If the client has used a
-   Supported Elliptic Curves Extension, the public key in the server's
-   certificate MUST respect the client's choice of elliptic curves; in
-   particular, the public key MUST employ a named curve (not the same
-   curve as an explicit curve) unless the client has indicated support
-   for explicit curves of the appropriate type.  If the client has used
-   a Supported Point Formats Extension, both the server's public key
-   point and (in the case of an explicit curve) the curve's base point
-   MUST respect the client's choice of point formats.  (A server that
-   cannot satisfy these requirements must not choose an ECC cipher suite
-   in its ServerHello message.)
-
-   Actions of the receiver:
-
-   The client validates the certificate chain, extracts the server's
-   public key, and checks that the key type is appropriate for the
-   negotiated key exchange algorithm.
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 17]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-5.4  Server Key Exchange
-
-   When this message is sent:
-
-   This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
-   ECDH_anon key exchange algorithms.
-
-   Meaning of this message:
-
-   This message is used to convey the server's ephemeral ECDH public key
-   (and the corresponding elliptic curve domain parameters) to the
-   client.
-
-   Structure of this message:
-
-        enum { explicit_prime (1), explicit_char2 (2),
-               named_curve (3), reserved(4 .. 255) } ECCurveType;
-
-   explicit_prime:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a prime
-      field.
-
-   explicit_char2:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a
-      characteristic-2 field.
-
-   named_curve:  Indicates that a named curve is used.  This option
-      SHOULD be used when applicable.
-
-   Values 248 through 255 are reserved for private use.
-
-        struct {
-            opaque a <1..2^8-1>;
-            opaque b <1..2^8-1>;
-        } ECCurve;
-
-   a, b:  These parameters specify the coefficients of the elliptic
-      curve.  Each value contains the byte string representation of a
-      field element following the conversion routine in Section 4.3.3 of
-      ANSI X9.62 [6].
-
-
-        struct {
-            opaque point <1..2^8-1>;
-        } ECPoint;
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 18]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   point:  This is the byte string representation of an elliptic curve
-      point following the conversion routine in Section 4.3.6 of ANSI
-      X9.62 [6].  This byte string may represent an elliptic curve point
-      in uncompressed, hybrid, or compressed format; it MUST conform to
-      what the client has requested through a Supported Point Formats
-      Extension if this extension was used.
-
-
-        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
-
-   ec_basis_trinomial:  Indicates representation of a characteristic-2
-      field using a trinomial basis.
-
-   ec_basis_pentanomial:  Indicates representation of a characteristic-2
-      field using a pentanomial basis.
-
-
-        struct {
-            ECCurveType    curve_type;
-            select (curve_type) {
-                case explicit_prime:
-                    opaque      prime_p <1..2^8-1>;
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case explicit_char2:
-                    uint16      m;
-                    ECBasisType basis;
-                    select (basis) {
-                        case ec_trinomial:
-                            opaque  k <1..2^8-1>;
-                        case ec_pentanomial:
-                            opaque  k1 <1..2^8-1>;
-                            opaque  k2 <1..2^8-1>;
-                            opaque  k3 <1..2^8-1>;
-                    };
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case named_curve:
-                    NamedCurve namedcurve;
-            };
-        } ECParameters;
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 19]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   curve_type:  This identifies the type of the elliptic curve domain
-      parameters.
-
-   prime_p:  This is the odd prime defining the field Fp.
-
-   curve:  Specifies the coefficients a and b of the elliptic curve E.
-
-   base:  Specifies the base point G on the elliptic curve.
-
-   order:  Specifies the order n of the base point.
-
-   cofactor:  Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
-      represents the number of points on the elliptic curve E defined
-      over the field Fq (either Fp or F2^m).
-
-   m:  This is the degree of the characteristic-2 field F2^m.
-
-   k:  The exponent k for the trinomial basis representation x^m + x^k
-      +1.
-
-   k1, k2, k3:  The exponents for the pentanomial representation x^m +
-      x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
-
-   namedcurve:  Specifies a recommended set of elliptic curve domain
-      parameters.  All enum values of NamedCurve are allowed except for
-      arbitrary_explicit_prime_curves(253) and
-      arbitrary_explicit_char2_curves(254).  These two values are only
-      allowed in the ClientHello extension.
-
-
-        struct {
-            ECParameters    curve_params;
-            ECPoint         public;
-        } ServerECDHParams;
-
-   curve_params:  Specifies the elliptic curve domain parameters
-      associated with the ECDH public key.
-
-   public:  The ephemeral ECDH public key.
-
-   The ServerKeyExchange message is extended as follows.
-
-        enum { ec_diffie_hellman } KeyExchangeAlgorithm;
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 20]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   ec_diffie_hellman:  Indicates the ServerKeyExchange message contains
-      an ECDH public key.
-
-
-        select (KeyExchangeAlgorithm) {
-            case ec_diffie_hellman:
-                ServerECDHParams    params;
-                Signature           signed_params;
-        } ServerKeyExchange;
-
-   params:  Specifies the ECDH public key and associated domain
-      parameters.
-
-   signed_params:  A hash of the params, with the signature appropriate
-      to that hash applied.  The private key corresponding to the
-      certified public key in the server's Certificate message is used
-      for signing.
-
-
-          enum { ecdsa } SignatureAlgorithm;
-
-
-          select (SignatureAlgorithm) {
-              case ecdsa:
-                  digitally-signed struct {
-                      opaque sha_hash[sha_size];
-                  };
-          } Signature;
-
-   NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
-   algorithm and "anonymous" for ECDH_anon.  These cases are defined in
-   TLS [2].  SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA.  ECDSA
-   signatures are generated and verified as described in Section 5.10.
-   As per ANSI X9.62, an ECDSA signature consists of a pair of integers
-   r and s.  These integers are both converted into byte strings of the
-   same length as the curve order n using the conversion routine
-   specified in Section 4.3.1 of [6].  The two byte strings are
-   concatenated, and the result is placed in the signature field.
-
-   Actions of the sender:
-
-   The server selects elliptic curve domain parameters and an ephemeral
-   ECDH public key corresponding to these parameters according to the
-   ECKAS-DH1 scheme from IEEE 1363 [5].  It conveys this information to
-   the client in the ServerKeyExchange message using the format defined
-   above.
-
-   Actions of the recipient:
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 21]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   The client verifies the signature (when present) and retrieves the
-   server's elliptic curve domain parameters and ephemeral ECDH public
-   key from the ServerKeyExchange message.
-
-5.5  Certificate Request
-
-   When this message is sent:
-
-   This message is sent when requesting client authentication.
-
-   Meaning of this message:
-
-   The server uses this message to suggest acceptable client
-   authentication methods.
-
-   Structure of this message:
-
-   The TLS CertificateRequest message is extended as follows.
-
-        enum {
-            ecdsa_sign(??), rsa_fixed_ecdh(??),
-            ecdsa_fixed_ecdh(??), (255)
-        } ClientCertificateType;
-
-   ecdsa_sign, etc Indicates that the server would like to use the
-      corresponding client authentication method specified in Section 3.
-
-      [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
-      ecdsa_fixed_ecdh have been left as ??.  These values will be
-      assigned when this draft progresses to RFC.  Earlier versions of
-      this draft used the values 5, 6, and 7 - however these values have
-      been removed since they are used differently by SSL 3.0 [14] and
-      their use by TLS is being deprecated. ]]
-
-   Actions of the sender:
-
-   The server decides which client authentication methods it would like
-   to use, and conveys this information to the client using the format
-   defined above.
-
-   Actions of the receiver:
-
-   The client determines whether it has a suitable certificate for use
-   with any of the requested methods, and decides whether or not to
-   proceed with client authentication.
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 22]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-5.6  Client Certificate
-
-   When this message is sent:
-
-   This message is sent in response to a CertificateRequest when a
-   client has a suitable certificate and has decided to proceed with
-   client authentication.  (Note that if the server has used a Supported
-   Point Formats Extension, a certificate can only be considered
-   suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and
-   ECDSA_fixed_ECDH authentication methods if the public key point
-   specified in it respects the server's choice of point formats.  If no
-   Supported Point Formats Extension has been used, a certificate can
-   only be considered suitable for use with these authentication methods
-   if the point is represented in uncompressed point format.)
-
-   Meaning of this message:
-
-   This message is used to authentically convey the client's static
-   public key to the server.  The following table summarizes what client
-   certificate types are appropriate for the ECC-based client
-   authentication mechanisms described in Section 3.  ECC public keys
-   must be encoded in certificates as described in Section 5.9.
-
-   NOTE: The client's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 4 apply only to
-   the client's certificate (first in the chain).
-
-
-          Client
-          Authentication Method   Client Certificate Type
-          ---------------------   -----------------------
-
-          ECDSA_sign              Certificate must contain an
-                                  ECDSA-capable public key and
-                                  be signed with ECDSA.
-
-          ECDSA_fixed_ECDH        Certificate must contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  must be signed with ECDSA.
-
-          RSA_fixed_ECDH          Certificate must contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  must be signed with RSA.
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 23]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-                     Table 4: Client certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS client Certificate format.
-
-   Actions of the sender:
-
-   The client constructs an appropriate certificate chain, and conveys
-   it to the server in the Certificate message.
-
-   Actions of the receiver:
-
-   The TLS server validates the certificate chain, extracts the client's
-   public key, and checks that the key type is appropriate for the
-   client authentication method.
-
-5.7  Client Key Exchange
-
-   When this message is sent:
-
-   This message is sent in all key exchange algorithms.  If client
-   authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
-   message is empty.  Otherwise, it contains the client's ephemeral ECDH
-   public key.
-
-   Meaning of the message:
-
-   This message is used to convey ephemeral data relating to the key
-   exchange belonging to the client (such as its ephemeral ECDH public
-   key).
-
-   Structure of this message:
-
-   The TLS ClientKeyExchange message is extended as follows.
-
-        enum { implicit, explicit } PublicValueEncoding;
-
-   implicit, explicit:  For ECC cipher suites, this indicates whether
-      the client's ECDH public key is in the client's certificate
-      ("implicit") or is provided, as an ephemeral ECDH public key, in
-      the ClientKeyExchange message ("explicit").  (This is "explicit"
-      in ECC cipher suites except when the client uses the
-      ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
-      mechanism.)
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 24]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-        struct {
-            select (PublicValueEncoding) {
-                case implicit: struct { };
-                case explicit: ECPoint ecdh_Yc;
-            } ecdh_public;
-        } ClientECDiffieHellmanPublic;
-
-   ecdh_Yc:  Contains the client's ephemeral ECDH public key as a byte
-      string ECPoint.point, which may represent an elliptic curve point
-      in uncompressed, hybrid, or compressed format.  Here the format
-      MUST conform to what the server has requested through a Supported
-      Point Formats Extension if this extension was used, and MUST be
-      uncompressed if this extension was not used.
-
-
-        struct {
-            select (KeyExchangeAlgorithm) {
-                case ec_diffie_hellman: ClientECDiffieHellmanPublic;
-            } exchange_keys;
-        } ClientKeyExchange;
-
-   Actions of the sender:
-
-   The client selects an ephemeral ECDH public key corresponding to the
-   parameters it received from the server according to the ECKAS-DH1
-   scheme from IEEE 1363 [5].  It conveys this information to the client
-   in the ClientKeyExchange message using the format defined above.
-
-   Actions of the recipient:
-
-   The server retrieves the client's ephemeral ECDH public key from the
-   ClientKeyExchange message and checks that it is on the same elliptic
-   curve as the server's ECDH key.
-
-5.8  Certificate Verify
-
-   When this message is sent:
-
-   This message is sent when the client sends a client certificate
-   containing a public key usable for digital signatures, e.g. when the
-   client is authenticated using the ECDSA_sign mechanism.
-
-   Meaning of the message:
-
-   This message contains a signature that proves possession of the
-   private key corresponding to the public key in the client's
-   Certificate message.
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 25]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   Structure of this message:
-
-   The TLS CertificateVerify message is extended as follows.
-
-        enum { ecdsa } SignatureAlgorithm;
-
-        select (SignatureAlgorithm) {
-            case ecdsa:
-                digitally-signed struct {
-                    opaque sha_hash[sha_size];
-                };
-        } Signature;
-
-   For the ecdsa case, the signature field in the CertificateVerify
-   message contains an ECDSA signature computed over handshake messages
-   exchanged so far.  ECDSA signatures are computed as described in
-   Section 5.10.  As per ANSI X9.62, an ECDSA signature consists of a
-   pair of integers r and s.  These integers are both converted into
-   byte strings of the same length as the curve order n using the
-   conversion routine specified in Section 4.3.1 of [6].  The two byte
-   strings are concatenated, and the result is placed in the signature
-   field.
-
-   Actions of the sender:
-
-   The client computes its signature over all handshake messages sent or
-   received starting at client hello up to but not including this
-   message.  It uses the private key corresponding to its certified
-   public key to compute the signature which is conveyed in the format
-   defined above.
-
-   Actions of the receiver:
-
-   The server extracts the client's signature from the CertificateVerify
-   message, and verifies the signature using the public key it received
-   in the client's Certificate message.
-
-5.9  Elliptic Curve Certificates
-
-   X509 certificates containing ECC public keys or signed using ECDSA
-   MUST comply with [11] or another RFC that replaces or extends it.
-   Clients SHOULD use the elliptic curve domain parameters recommended
-   in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
-
-5.10  ECDH, ECDSA and RSA Computations
-
-   All ECDH calculations (including parameter and key generation as well
-   as the shared secret calculation) MUST be performed according to [5]
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 26]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   using the ECKAS-DH1 scheme with the identity map as key derivation
-   function, so that the premaster secret is the x-coordinate of the
-   ECDH shared secret elliptic curve point, i.e. the octet string Z in
-   IEEE 1363 terminology.
-
-   Note that a new extension may be introduced in the future to allow
-   the use of a different KDF during computation of the premaster
-   secret.  In this event, the new KDF would be used in place of the
-   process detailed above.  This may be desirable, for example, to
-   support compatibility with the planned NIST key agreement standard.
-
-   All ECDSA computations MUST be performed according to ANSI X9.62 [6]
-   or its successors.  Data to be signed/verified is hashed and the
-   result run directly through the ECDSA algorithm with no additional
-   hashing.  The default hash function is SHA-1 [7] and sha_size (see
-   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
-   function, such as one of the new SHA hash functions specified in FIPS
-   180-2 [7], may be used instead if the certificate containing the EC
-   public key explicitly requires use of another hash function.  (The
-   mechanism for specifying the required hash function has not been
-   standardized but this provision anticipates such standardization and
-   obviates the need to update this document in response.  Future PKIX
-   RFCs may choose, for example, to specify the hash function to be used
-   with a public key in the parameters field of subjectPublicKeyInfo.)
-
-   All RSA signatures must be generated and verified according to PKCS#1
-   [9] block type 1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 27]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-6.  Cipher Suites
-
-   The table below defines new ECC cipher suites that use the key
-   exchange algorithms specified in Section 2.
-
-     CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA           = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA    = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA       = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA             = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_anon_NULL_WITH_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-                        Table 5: TLS ECC cipher suites
-
-
-   [[ EDITOR: The actual cipher suite numbers will be assigned when this
-   draft progresses to RFC. ]]
-
-   The key exchange method, cipher, and hash algorithm for each of these
-   cipher suites are easily determined by examining the name.  Ciphers
-   other than AES ciphers, and hash algorithms are defined in [2].  AES
-   ciphers are defined in [15].
-
-   Server implementations SHOULD support all of the following cipher
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 28]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   suites, and client implementations SHOULD support at least one of
-   them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
-   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 29]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-7.  Security Considerations
-
-   This document is based on [2], [5], [6] and [15].  The appropriate
-   security considerations of those documents apply.
-
-   One important issue that implementors and users must consider is
-   elliptic curve selection.  Guidance on selecting an appropriate
-   elliptic curve size is given in Table 1.
-
-   Beyond elliptic curve size, the main issue is elliptic curve
-   structure.  As a general principle, it is more conservative to use
-   elliptic curves with as little algebraic structure as possible - thus
-   random curves are more conservative than special curves such as
-   Koblitz curves, and curves over F_p with p random are more
-   conservative than curves over F_p with p of a special form (and
-   curves over F_p with p random might be considered more conservative
-   than curves over F_2^m as there is no choice between multiple fields
-   of similar size for characteristic 2).  Note, however, that algebraic
-   structure can also lead to implementation efficiencies and
-   implementors and users may, therefore, need to balance conservatism
-   against a need for efficiency.  Concrete attacks are known against
-   only very few special classes of curves, such as supersingular
-   curves, and these classes are excluded from the ECC standards that
-   this document references [5], [6].
-
-   Another issue is the potential for catastrophic failures when a
-   single elliptic curve is widely used.  In this case, an attack on the
-   elliptic curve might result in the compromise of a large number of
-   keys.  Again, this concern may need to be balanced against efficiency
-   and interoperability improvements associated with widely-used curves.
-   Substantial additional information on elliptic curve choice can be
-   found in [4], [5], [6], [8].
-
-   Implementors and users must also consider whether they need forward
-   secrecy.  Forward secrecy refers to the property that session keys
-   are not compromised if the static, certified keys belonging to the
-   server and client are compromised.  The ECDHE_ECDSA and ECDHE_RSA key
-   exchange algorithms provide forward secrecy protection in the event
-   of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
-   Similarly if the client is providing a static, certified key,
-   ECDSA_sign client authentication provides forward secrecy protection
-   in the event of client key compromise, while ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH do not.  Thus to obtain complete forward secrecy
-   protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
-   with ECDSA_sign used for client authentication if necessary.  Here
-   again the security benefits of forward secrecy may need to be
-   balanced against the improved efficiency offered by other options.
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 30]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-8.  Acknowledgments
-
-   The authors wish to thank Bill Anderson and Tim Dierks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 31]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [3]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-         T. Wright, "Transport Layer Security (TLS) Extensions",
-         draft-ietf-tls-rfc3546bis-00.txt (work in progress), Nov. 2004.
-
-   [4]   SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
-         <http://www.secg.org/>.
-
-   [5]   IEEE, "Standard Specifications for Public Key Cryptography",
-         IEEE 1363, 2000.
-
-   [6]   ANSI, "Public Key Cryptography For The Financial Services
-         Industry: The Elliptic Curve Digital Signature Algorithm
-         (ECDSA)", ANSI X9.62, 1998.
-
-   [7]   NIST, "Secure Hash Standard", FIPS 180-2, 2002.
-
-   [8]   NIST, "Digital Signature Standard", FIPS 186-2, 2000.
-
-   [9]   RSA Laboratories, "PKCS#1: RSA Encryption Standard version
-         1.5", PKCS 1, November 1993.
-
-   [10]  SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
-         2000, <http://www.secg.org/>.
-
-   [11]  Polk, T., Housley, R., and L. Bassham, "Algorithms and
-         Identifiers for the Internet X.509 Public Key Infrastructure
-         Certificate and Certificate Revocation List (CRL) Profile",
-         RFC 3279, April 2002.
-
-9.2  Informative References
-
-   [12]  Harper, G., Menezes, A., and S. Vanstone, "Public-Key
-         Cryptosystems with Very Small Key Lengths", Advances in
-         Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
-
-   [13]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", Journal of Cryptology 14 (2001) 255-293,
-         <http://www.cryptosavvy.com/>.
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 32]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   [14]  Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
-         Version 3.0", November 1996,
-         <http://wp.netscape.com/eng/ssl3/draft302.txt>.
-
-   [15]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-         Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-
-Authors' Addresses
-
-   Vipul Gupta
-   Sun Microsystems Laboratories
-   16 Network Circle
-   MS UMPK16-160
-   Menlo Park, CA  94025
-   US
-
-   Phone: +1 650 786 7551
-   Email: vipul.gupta@sun.com
-
-
-   Simon Blake-Wilson
-   Basic Commerce & Industries, Inc.
-   96 Spandia Ave
-   Unit 606
-   Toronto, ON  M6G 2T6
-   CA
-
-   Phone: +1 416 214 5961
-   Email: sblakewilson@bcisse.com
-
-
-   Bodo Moeller
-   University of Calgary
-   Dept of Math & Stats
-   2500 University Dr NW
-   Calgary, AB  T2N 1N4
-   CA
-
-   Phone: +1 403 220 5735
-   Email: bodo@openssl.org
-
-
-   Chris Hawk
-   Corriente Networks
-
-   Email: chris@corriente.net
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 33]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-   Nelson Bolyard
-
-   Email: nelson@bolyard.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 34]
-
-Internet-Draft          ECC Cipher Suites for TLS             April 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Gupta, et al.            Expires October 9, 2005               [Page 35]
-
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-10.txt b/doc/protocol/draft-ietf-tls-ecc-10.txt
deleted file mode 100644
index 7b191b3098..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-10.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-
-TLS Working Group                                               V. Gupta
-Internet-Draft                                                  Sun Labs
-Expires: December 2, 2005                                S. Blake-Wilson
-                                                                     BCI
-                                                              B. Moeller
-                                                   University of Calgary
-                                                                 C. Hawk
-                                                      Corriente Networks
-                                                              N. Bolyard
-                                                            May 31, 2005
-
-
-                       ECC Cipher Suites for TLS
-                      <draft-ietf-tls-ecc-10.txt>
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 2, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes new key exchange algorithms based on Elliptic
-   Curve Cryptography (ECC) for the TLS (Transport Layer Security)
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 1]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   protocol.  In particular, it specifies the use of Elliptic Curve
-   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
-   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
-   authentication mechanism.
-
-   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 [1].
-
-   Please send comments on this document to the TLS mailing list.
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Key Exchange Algorithms  . . . . . . . . . . . . . . . . . .   5
-     2.1  ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.2  ECDHE_ECDSA  . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.3  ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.4  ECDHE_RSA  . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.5  ECDH_anon  . . . . . . . . . . . . . . . . . . . . . . . .   8
-   3.   Client Authentication  . . . . . . . . . . . . . . . . . . .   9
-     3.1  ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . .   9
-     3.2  ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . .  10
-     3.3  RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . .  10
-   4.   TLS Extensions for ECC . . . . . . . . . . . . . . . . . . .  11
-   5.   Data Structures and Computations . . . . . . . . . . . . . .  12
-     5.1  Client Hello Extensions  . . . . . . . . . . . . . . . . .  12
-     5.2  Server Hello Extension . . . . . . . . . . . . . . . . . .  15
-     5.3  Server Certificate . . . . . . . . . . . . . . . . . . . .  16
-     5.4  Server Key Exchange  . . . . . . . . . . . . . . . . . . .  18
-     5.5  Certificate Request  . . . . . . . . . . . . . . . . . . .  22
-     5.6  Client Certificate . . . . . . . . . . . . . . . . . . . .  23
-     5.7  Client Key Exchange  . . . . . . . . . . . . . . . . . . .  24
-     5.8  Certificate Verify . . . . . . . . . . . . . . . . . . . .  25
-     5.9  Elliptic Curve Certificates  . . . . . . . . . . . . . . .  26
-     5.10   ECDH, ECDSA and RSA Computations . . . . . . . . . . . .  26
-   6.   Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . .  28
-   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  30
-   8.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  31
-   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  32
-     9.1  Normative References . . . . . . . . . . . . . . . . . . .  32
-     9.2  Informative References . . . . . . . . . . . . . . . . . .  32
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  33
-        Intellectual Property and Copyright Statements . . . . . . .  35
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 2]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-1.  Introduction
-
-   Elliptic Curve Cryptography (ECC) is emerging as an attractive
-   public-key cryptosystem for mobile/wireless environments.  Compared
-   to currently prevalent cryptosystems such as RSA, ECC offers
-   equivalent security with smaller key sizes.  This is illustrated in
-   the following table, based on [13], which gives approximate
-   comparable key sizes for symmetric- and asymmetric-key cryptosystems
-   based on the best-known algorithms for attacking them.
-
-                   Symmetric    |  ECC    |  DH/DSA/RSA
-                   -------------+---------+------------
-                      80        |  163    |  1024
-                     112        |  233    |  2048
-                     128        |  283    |  3072
-                     192        |  409    |  7680
-                     256        |  571    |  15360
-
-                  Table 1: Comparable key sizes (in bits)
-
-
-   Smaller key sizes result in power, bandwidth and computational
-   savings that make ECC especially attractive for constrained
-   environments.
-
-   This document describes additions to TLS to support ECC.  In
-   particular, it defines
-
-   o  the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
-      scheme with long-term or ephemeral keys to establish the TLS
-      premaster secret, and
-
-   o  the use of fixed-ECDH certificates and ECDSA for authentication of
-      TLS peers.
-
-   The remainder of this document is organized as follows.  Section 2
-   provides an overview of ECC-based key exchange algorithms for TLS.
-   Section 3 describes the use of ECC certificates for client
-   authentication.  TLS extensions that allow a client to negotiate the
-   use of specific curves and point formats are presented in Section 4.
-   Section 5 specifies various data structures needed for an ECC-based
-   handshake, their encoding in TLS messages and the processing of those
-   messages.  Section 6 defines new ECC-based cipher suites and
-   identifies a small subset of these as recommended for all
-   implementations of this specification.  Section 7 and Section 8
-   mention security considerations and acknowledgments, respectively.
-   This is followed by a list of references cited in this document, the
-   authors' contact information, and statements on intellectual property
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 3]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   rights and copyrights.
-
-   Implementation of this specification requires familiarity with TLS
-   [2], TLS extensions [3] and ECC [4][5][6][8].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 4]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-2.  Key Exchange Algorithms
-
-   This document introduces five new ECC-based key exchange algorithms
-   for TLS.  All of them use ECDH to compute the TLS premaster secret
-   and differ only in the lifetime of ECDH keys (long-term or ephemeral)
-   and the mechanism (if any) used to authenticate them.  The derivation
-   of the TLS master secret from the premaster secret and the subsequent
-   generation of bulk encryption/MAC keys and initialization vectors is
-   independent of the key exchange algorithm and not impacted by the
-   introduction of ECC.
-
-   The table below summarizes the new key exchange algorithms which
-   mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]),
-   respectively.
-
-          Key
-          Exchange
-          Algorithm           Description
-          ---------           -----------
-
-          ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
-
-          ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
-
-          ECDH_RSA            Fixed ECDH with RSA-signed certificates.
-
-          ECDHE_RSA           Ephemeral ECDH with RSA signatures.
-
-          ECDH_anon           Anonymous ECDH, no signatures.
-
-                     Table 2: ECC key exchange algorithms
-
-
-   The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
-   secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
-   certificate and easily comply with a constrained client's elliptic
-   curve preferences (see Section 4).  However, the computational cost
-   incurred by a server is higher for ECDHE_RSA than for the traditional
-   RSA key exchange which does not provide forward secrecy.
-
-   The ECDH_RSA mechanism requires a server to acquire an ECC
-   certificate but the certificate issuer can still use an existing RSA
-   key for signing.  This eliminates the need to update the trusted key
-   store in TLS clients.  The ECDH_ECDSA mechanism requires ECC keys for
-   the server as well as the certification authority and is best suited
-   for constrained devices unable to support RSA.
-
-   The anonymous key exchange algorithm does not provide authentication
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 5]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   of the server or the client.  Like other anonymous TLS key exchanges,
-   it is subject to man-in-the-middle attacks.  Implementations of this
-   algorithm SHOULD provide authentication by other means.
-
-   Note that there is no structural difference between ECDH and ECDSA
-   keys.  A certificate issuer may use X509.v3 keyUsage and
-   extendedKeyUsage extensions to restrict the use of an ECC public key
-   to certain computations.  This document refers to an ECC key as ECDH-
-   capable if its use in ECDH is permitted.  ECDSA-capable is defined
-   similarly.
-
-
-              Client                                        Server
-              ------                                        ------
-
-              ClientHello          -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                              CertificateRequest*+
-                                   <--------       ServerHelloDone
-              Certificate*+
-              ClientKeyExchange
-              CertificateVerify*+
-              [ChangeCipherSpec]
-              Finished             -------->
-                                                [ChangeCipherSpec]
-                                   <--------              Finished
-
-              Application Data     <------->      Application Data
-
-
-                   * message is not sent under some conditions
-                   + message is not sent unless client authentication
-                     is desired
-
-                 Figure 1: Message flow in a full TLS handshake
-
-
-   Figure 1 shows all messages involved in the TLS key establishment
-   protocol (aka full handshake).  The addition of ECC has direct impact
-   only on the ClientHello, the ServerHello, the server's Certificate
-   message, the ServerKeyExchange, the ClientKeyExchange, the
-   CertificateRequest, the client's Certificate message, and the
-   CertificateVerify.  Next, we describe each ECC key exchange algorithm
-   in greater detail in terms of the content and processing of these
-   messages.  For ease of exposition, we defer discussion of client
-   authentication and associated messages (identified with a + in
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 6]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   Figure 1) until Section 3 and of the optional ECC-specific extensions
-   (which impact the Hello messages) until Section 4.
-
-2.1  ECDH_ECDSA
-
-   In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
-   public key and be signed with ECDSA.
-
-   A ServerKeyExchange MUST NOT be sent (the server's certificate
-   contains all the necessary keying information required by the client
-   to arrive at the premaster secret).
-
-   The client generates an ECDH key pair on the same curve as the
-   server's long-term public key and send its public key in the
-   ClientKeyExchange message (except when using client authentication
-   algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
-   modifications from section Section 3.2 or Section 3.3 apply).
-
-   Both client and server perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-2.2  ECDHE_ECDSA
-
-   In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
-   capable public key and be signed with ECDSA.
-
-   The server sends its ephemeral ECDH public key and a specification of
-   the corresponding curve in the ServerKeyExchange message.  These
-   parameters MUST be signed with ECDSA using the private key
-   corresponding to the public key in the server's Certificate.
-
-   The client generates an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server perform an ECDH operation (Section 5.10) and
-   use the resultant shared secret as the premaster secret.
-
-2.3  ECDH_RSA
-
-   This key exchange algorithm is the same as ECDH_ECDSA except the
-   server's certificate MUST be signed with RSA rather than ECDSA.
-
-2.4  ECDHE_RSA
-
-   This key exchange algorithm is the same as ECDHE_ECDSA except the
-   server's certificate MUST contain an RSA public key authorized for
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 7]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   signing and the signature in the ServerKeyExchange message must be
-   computed with the corresponding RSA private key.  The server
-   certificate MUST be signed with RSA.
-
-2.5  ECDH_anon
-
-   In ECDH_anon, the server's Certificate, the CertificateRequest, the
-   client's Certificate, and the CertificateVerify messages MUST NOT be
-   sent.
-
-   The server MUST send an ephemeral ECDH public key and a specification
-   of the corresponding curve in the ServerKeyExchange message.  These
-   parameters MUST NOT be signed.
-
-   The client generates an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10.
-
-   Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
-   key exchange algorithms require the server's certificate to be signed
-   with a particular signature scheme, this specification (following the
-   similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not
-   impose restrictions on signature schemes used elsewhere in the
-   certificate chain.  (Often such restrictions will be useful, and it
-   is expected that this will be taken into account in certification
-   authorities' signing practices.  However, such restrictions are not
-   strictly required in general: Even if it is beyond the capabilities
-   of a client to completely validate a given chain, the client may be
-   able to validate the server's certificate by relying on a trust
-   anchor that appears as one of the intermediate certificates in the
-   chain.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 8]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-3.  Client Authentication
-
-   This document defines three new client authentication mechanisms
-   named after the type of client certificate involved: ECDSA_sign,
-   ECDSA_fixed_ECDH and RSA_fixed_ECDH.  The ECDSA_sign mechanism is
-   usable with any of the non-anonymous ECC key exchange algorithms
-   described in Section 2 as well as other non-anonymous (non-ECC) key
-   exchange algorithms defined in TLS [2].  The ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
-   Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
-   use of a long-term ECDH client key would jeopardize the forward
-   secrecy property of these algorithms.
-
-   The server can request ECC-based client authentication by including
-   one or more of these certificate types in its CertificateRequest
-   message.  The server must not include any certificate types that are
-   prohibited for the negotiated key exchange algorithm.  The client
-   must check if it possesses a certificate appropriate for any of the
-   methods suggested by the server and is willing to use it for
-   authentication.
-
-   If these conditions are not met, the client should send a client
-   Certificate message containing no certificates.  In this case, the
-   ClientKeyExchange should be sent as described in Section 2 and the
-   CertificateVerify should not be sent.  If the server requires client
-   authentication, it may respond with a fatal handshake failure alert.
-
-   If the client has an appropriate certificate and is willing to use it
-   for authentication, it must send that certificate in the client's
-   Certificate message (as per Section 5.6) and prove possession of the
-   private key corresponding to the certified key.  The process of
-   determining an appropriate certificate and proving possession is
-   different for each authentication mechanism and described below.
-
-   NOTE: It is permissible for a server to request (and the client to
-   send) a client certificate of a different type than the server
-   certificate.
-
-3.1  ECDSA_sign
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDSA-capable public key and signed with
-   ECDSA.
-
-   The client proves possession of the private key corresponding to the
-   certified key by including a signature in the CertificateVerify
-   message as described in Section 5.8.
-
-
-
-
-Gupta, et al.           Expires December 2, 2005                [Page 9]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-3.2  ECDSA_fixed_ECDH
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDH-capable public key and that
-   certificate MUST be signed with ECDSA.  Furthermore, the client's
-   ECDH key MUST be on the same elliptic curve as the server's long-term
-   (certified) ECDH key.  This might limit use of this mechanism to
-   closed environments.  In situations where the client has an ECC key
-   on a different curve, it would have to authenticate either using
-   ECDSA_sign or a non-ECC mechanism (e.g.  RSA).  Using fixed ECDH for
-   both servers and clients is computationally more efficient than
-   mechanisms providing forward secrecy.
-
-   When using this authentication mechanism, the client MUST send an
-   empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
-   the CertificateVerify message.  The ClientKeyExchange is empty since
-   the client's ECDH public key required by the server to compute the
-   premaster secret is available inside the client's certificate.  The
-   client's ability to arrive at the same premaster secret as the server
-   (demonstrated by a successful exchange of Finished messages) proves
-   possession of the private key corresponding to the certified public
-   key and the CertificateVerify message is unnecessary.
-
-3.3  RSA_fixed_ECDH
-
-   This authentication mechanism is identical to ECDSA_fixed_ECDH except
-   the client's certificate MUST be signed with RSA.
-
-   Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH
-   client authentication mechanisms require the clients's certificate to
-   be signed with a particular signature scheme, this specification does
-   not impose restrictions on signature schemes used elsewhere in the
-   certificate chain.  (Often such restrictions will be useful, and it
-   is expected that this will be taken into account in certification
-   authorities' signing practices.  However, such restrictions are not
-   strictly required in general: Even if it is beyond the capabilities
-   of a server to completely validate a given chain, the server may be
-   able to validate the clients certificate by relying on a trust anchor
-   that appears as one of the intermediate certificates in the chain.)
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 10]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-4.  TLS Extensions for ECC
-
-   Two new TLS extensions are defined in this specification: (i) the
-   Supported Elliptic Curves Extension, and (ii) the Supported Point
-   Formats Extension.  These allow negotiating the use of specific
-   curves and point formats (e.g. compressed vs. uncompressed),
-   respectively, during a handshake starting a new session.  These
-   extensions are especially relevant for constrained clients that may
-   only support a limited number of curves or point formats.  They
-   follow the general approach outlined in [3]; message details are
-   specified in Section 5.  The client enumerates the curves it supports
-   and the point formats it can parse by including the appropriate
-   extensions in its ClientHello message.  The server similarly
-   enumerates the point formats it can parse by including an extension
-   in its ServerHello message.
-
-   A TLS client that proposes ECC cipher suites in its ClientHello
-   message SHOULD include these extensions.  Servers implementing ECC
-   cipher suites MUST support these extensions, and when a client uses
-   these extensions, servers MUST NOT negotiate the use of an ECC cipher
-   suite unless they can complete the handshake while respecting the
-   choice of curves and compression techniques specified by the client.
-   This eliminates the possibility that a negotiated ECC handshake will
-   be subsequently aborted due to a client's inability to deal with the
-   server's EC key.
-
-   These extensions MUST NOT be included if the client does not propose
-   any ECC cipher suites.  A client that proposes ECC cipher suites may
-   choose not to include these extension.  In this case, the server is
-   free to choose any one of the elliptic curves or point formats listed
-   in Section 5.  That section also describes the structure and
-   processing of these extensions in greater detail.
-
-   In the case of session resumption, the server simply ignores the
-   Supported Elliptic Curves Extension and the Supported Point Formats
-   Extension as appearing in the current ClientHello message.  These
-   extensions only play a role during handshakes negotiating a new
-   session.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 11]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-5.  Data Structures and Computations
-
-   This section specifies the data structures and computations used by
-   ECC-based key mechanisms specified in Section 2, Section 3 and
-   Section 4.  The presentation language used here is the same as that
-   used in TLS [2].  Since this specification extends TLS, these
-   descriptions should be merged with those in the TLS specification and
-   any others that extend TLS.  This means that enum types may not
-   specify all possible values and structures with multiple formats
-   chosen with a select() clause may not indicate all possible cases.
-
-5.1  Client Hello Extensions
-
-   This section specifies two TLS extensions that can be included with
-   the ClientHello message as described in [3], the Supported Elliptic
-   Curves Extension and the Supported Point Formats Extension.
-
-   When these extensions are sent:
-
-   The extensions SHOULD be sent along with any ClientHello message that
-   proposes ECC cipher suites.
-
-   Meaning of these extensions:
-
-   These extensions allow a client to enumerate the elliptic curves it
-   supports and/or the point formats it can parse.
-
-   Structure of these extensions:
-
-   The general structure of TLS extensions is described in [3] and this
-   specification adds two new types to ExtensionType.
-
-
-       enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
-
-   [[ EDITOR: The values used for elliptic_curves and ec_point_formats
-   have been left as ??.  These values will be assigned when this draft
-   progresses to RFC.  (The examples below will have to be changed
-   accordingly.) ]]
-
-   elliptic_curves (Supported Elliptic Curves Extension):  Indicates the
-      set of elliptic curves supported by the client.  For this
-      extension, the opaque extension_data field contains
-      EllipticCurveList.
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 12]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   ec_point_formats (Supported Point Formats Extension):  Indicates the
-      set of point formats that the client can parse.  For this
-      extension, the opaque extension_data field contains
-      ECPointFormatList.
-
-
-        enum {
-            sect163k1 (1), sect163r1 (2), sect163r2 (3),
-            sect193r1 (4), sect193r2 (5), sect233k1 (6),
-            sect233r1 (7), sect239k1 (8), sect283k1 (9),
-            sect283r1 (10), sect409k1 (11), sect409r1 (12),
-            sect571k1 (13), sect571r1 (14), secp160k1 (15),
-            secp160r1 (16), secp160r2 (17), secp192k1 (18),
-            secp192r1 (19), secp224k1 (20), secp224r1 (21),
-            secp256k1 (22), secp256r1 (23), secp384r1 (24),
-            secp521r1 (25), reserved (240..247),
-            arbitrary_explicit_prime_curves(253),
-            arbitrary_explicit_char2_curves(254),
-            (255)
-        } NamedCurve;
-
-   sect163k1, etc:  Indicates support of the corresponding named curve
-      specified in SEC 2 [10].  Note that many of these curves are also
-      recommended in ANSI X9.62 [6], and FIPS 186-2 [8].  Values 240
-      through 247 are reserved for private use.  Values 253 and 254
-      indicate that the client supports arbitrary prime and
-      characteristic-2 curves, respectively (the curve parameters must
-      be encoded explicitly in ECParameters).
-
-
-        struct {
-            NamedCurve elliptic_curve_list<1..2^8-1>
-        } EllipticCurveList;
-
-
-   Items in elliptic_curve_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   As an example, a client that only supports secp192r1 (aka NIST P-192;
-   value 19 = 0x13) and secp224r1 (aka NIST P-224; value 21 = 0x15) and
-   prefers to use secp192r1 would include a TLS extension consisting of
-   the following octets:
-
-        00 ?? 00 03 02 13 15
-
-   A client that supports arbitrary explicit characteristic-2 curves
-   (value 254 = 0xFE) would include an extension consisting of the
-   following octets:
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 13]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-        00 ?? 00 02 01 FE
-
-
-        enum { uncompressed (0), ansiX962_compressed_prime (1),
-               ansiX962_compressed_char2 (2), reserved (3 .. 255)
-        } ECPointFormat;
-
-        struct {
-            ECPointFormat ec_point_format_list<1..2^8-1>
-        } ECPointFormatList;
-
-   Three point formats are included in the definition of ECPointFormat
-   above.  The uncompressed point format is the default format in that
-   implementations of this document MUST support it for all of their
-   supported curves.  Compressed point formats reduce bandwidth by
-   including only the x-coordinate and a single bit of the y-coordinate
-   of the point.  Implementations of this document MAY support the
-   ansiX962_compressed_prime and ansiX962_compressed_char2 formats,
-   where the former applies only to prime curves and the latter applies
-   only to characteristic-2 curves.  (All formats are described in [6].)
-   Values 248 through 255 are reserved for private use.
-
-   Items in ec_point_format_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   A client that can parse only the uncompressed point format (value 0)
-   includes an extension consisting of the following octets:
-
-        00 ?? 00 02 01 00
-
-   A client that in the case of prime fields prefers the compressed
-   format (ansiX962_compressed_prime, value 1) over the uncompressed
-   format (value 0), but in the case of characteristic-2 fields prefers
-   the uncompressed format (value 0) over the compressed format
-   (ansiX962_compressed_char2, value 2), may indicate these preferences
-   by including an extension consisting of the following octets:
-
-        00 ?? 00 04 03 01 00 02
-
-   Actions of the sender:
-
-   A client that proposes ECC cipher suites in its ClientHello message
-   appends these extensions (along with any others), enumerating the
-   curves it supports and the point formats it can parse.  Clients
-   SHOULD send both the Supported Elliptic Curves Extension and the
-   Supported Point Formats Extension.  If the Supported Point Formats
-   Extension is indeed sent, it MUST contain the value 0 (uncompressed)
-   as one of the items in the list of point formats.
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 14]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   Actions of the receiver:
-
-   A server that receives a ClientHello containing one or both of these
-   extensions MUST use the client's enumerated capabilities to guide its
-   selection of an appropriate cipher suite.  One of the proposed ECC
-   cipher suites must be negotiated only if the server can successfully
-   complete the handshake while using the curves and point formats
-   supported by the client (cf. Section 5.3 and Section 5.4).
-
-   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
-   different curves for (i) the ECDSA key in its certificate, and (ii)
-   the ephemeral ECDH key in the ServerKeyExchange message.  The server
-   must consider the "elliptic_curves" extension in selecting both of
-   these curves.
-
-   If a server does not understand the "elliptic_curves" extension or is
-   unable to complete the ECC handshake while restricting itself to the
-   enumerated curves, it MUST NOT negotiate the use of an ECC cipher
-   suite.  Depending on what other cipher suites are proposed by the
-   client and supported by the server, this may result in a fatal
-   handshake failure alert due to the lack of common cipher suites.
-
-5.2  Server Hello Extension
-
-   This section specifies a TLS extension that can be included with the
-   ServerHello message as described in [3], the Supported Point Formats
-   Extension.
-
-   When this extension is sent:
-
-   The Supported Point Formats Extension is included in a ServerHello
-   message in response to a ClientHello message containing the Supported
-   Point Formats Extension when negotiating an ECC cipher suite.
-
-   Meaning of this extensions:
-
-   This extension allows a server to enumerate the point formats it can
-   parse (for the curve that will appear in its ServerKeyExchange
-   message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
-   exchange algorithm, or for the curve that is used in the server's
-   public key that will appear in its Certificate message when using the
-   ECDH_ECDSA or ECDH_RSA key exchange algorithm).
-
-   Structure of this extension:
-
-   The server's Supported Point Formats Extension has the same structure
-   as the client's Supported Point Formats Extension.  Items in
-   elliptic_curve_list here are ordered according to the server's
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 15]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   preference (favorite choice first).  Note that the server may include
-   items that were not found in the client's list (e.g., the server may
-   prefer to receive points in compressed format even when a client
-   cannot parse this format: the same client may nevertheless be capable
-   to output points in compressed format).
-
-   Actions of the sender:
-
-   A server that selects an ECC cipher suite in response to a
-   ClientHello message including a Supported Point Formats Extension
-   appends this extension (along with others) to its ServerHello
-   message, enumerating the point formats it can parse.  The Supported
-   Point Formats Extension, when used, MUST contain the value 0
-   (uncompressed) as one of the items in the list of point formats.
-
-   Actions of the receiver:
-
-   A client that receives a ServerHello message containing a Supported
-   Point Formats Extension MUST respect the server's choice of point
-   formats during the handshake (cf. Section 5.6 and Section 5.7).  If
-   no Supported Point Formats Extension is received with the
-   ServerHello, this is equivalent to an extension allowing only the
-   uncompressed point format.
-
-5.3  Server Certificate
-
-   When this message is sent:
-
-   This message is sent in all non-anonymous ECC-based key exchange
-   algorithms.
-
-   Meaning of this message:
-
-   This message is used to authentically convey the server's static
-   public key to the client.  The following table shows the server
-   certificate type appropriate for each key exchange algorithm.  ECC
-   public keys must be encoded in certificates as described in
-   Section 5.9.
-
-   NOTE: The server's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 3 apply only to
-   the server's certificate (first in the chain).
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 16]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-          Key Exchange Algorithm  Server Certificate Type
-          ----------------------  -----------------------
-
-          ECDH_ECDSA              Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDHE_ECDSA             Certificate must contain an
-                                  ECDSA-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDH_RSA                Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with RSA.
-
-          ECDHE_RSA               Certificate must contain an
-                                  RSA public key authorized for
-                                  use in digital signatures. It
-                                  must be signed with RSA.
-
-                    Table 3: Server certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS Certificate format.
-
-   Actions of the sender:
-
-   The server constructs an appropriate certificate chain and conveys it
-   to the client in the Certificate message.  If the client has used a
-   Supported Elliptic Curves Extension, the public key in the server's
-   certificate MUST respect the client's choice of elliptic curves; in
-   particular, the public key MUST employ a named curve (not the same
-   curve as an explicit curve) unless the client has indicated support
-   for explicit curves of the appropriate type.  If the client has used
-   a Supported Point Formats Extension, both the server's public key
-   point and (in the case of an explicit curve) the curve's base point
-   MUST respect the client's choice of point formats.  (A server that
-   cannot satisfy these requirements must not choose an ECC cipher suite
-   in its ServerHello message.)
-
-   Actions of the receiver:
-
-   The client validates the certificate chain, extracts the server's
-   public key, and checks that the key type is appropriate for the
-   negotiated key exchange algorithm.
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 17]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-5.4  Server Key Exchange
-
-   When this message is sent:
-
-   This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
-   ECDH_anon key exchange algorithms.
-
-   Meaning of this message:
-
-   This message is used to convey the server's ephemeral ECDH public key
-   (and the corresponding elliptic curve domain parameters) to the
-   client.
-
-   Structure of this message:
-
-        enum { explicit_prime (1), explicit_char2 (2),
-               named_curve (3), reserved(4 .. 255) } ECCurveType;
-
-   explicit_prime:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a prime
-      field.
-
-   explicit_char2:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a
-      characteristic-2 field.
-
-   named_curve:  Indicates that a named curve is used.  This option
-      SHOULD be used when applicable.
-
-   Values 248 through 255 are reserved for private use.
-
-        struct {
-            opaque a <1..2^8-1>;
-            opaque b <1..2^8-1>;
-        } ECCurve;
-
-   a, b:  These parameters specify the coefficients of the elliptic
-      curve.  Each value contains the byte string representation of a
-      field element following the conversion routine in Section 4.3.3 of
-      ANSI X9.62 [6].
-
-
-        struct {
-            opaque point <1..2^8-1>;
-        } ECPoint;
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 18]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   point:  This is the byte string representation of an elliptic curve
-      point following the conversion routine in Section 4.3.6 of ANSI
-      X9.62 [6].  This byte string may represent an elliptic curve point
-      in uncompressed, or compressed format; it MUST conform to what the
-      client has requested through a Supported Point Formats Extension
-      if this extension was used.
-
-
-        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
-
-   ec_basis_trinomial:  Indicates representation of a characteristic-2
-      field using a trinomial basis.
-
-   ec_basis_pentanomial:  Indicates representation of a characteristic-2
-      field using a pentanomial basis.
-
-
-        struct {
-            ECCurveType    curve_type;
-            select (curve_type) {
-                case explicit_prime:
-                    opaque      prime_p <1..2^8-1>;
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case explicit_char2:
-                    uint16      m;
-                    ECBasisType basis;
-                    select (basis) {
-                        case ec_trinomial:
-                            opaque  k <1..2^8-1>;
-                        case ec_pentanomial:
-                            opaque  k1 <1..2^8-1>;
-                            opaque  k2 <1..2^8-1>;
-                            opaque  k3 <1..2^8-1>;
-                    };
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case named_curve:
-                    NamedCurve namedcurve;
-            };
-        } ECParameters;
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 19]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   curve_type:  This identifies the type of the elliptic curve domain
-      parameters.
-
-   prime_p:  This is the odd prime defining the field Fp.
-
-   curve:  Specifies the coefficients a and b of the elliptic curve E.
-
-   base:  Specifies the base point G on the elliptic curve.
-
-   order:  Specifies the order n of the base point.
-
-   cofactor:  Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
-      represents the number of points on the elliptic curve E defined
-      over the field Fq (either Fp or F2^m).
-
-   m:  This is the degree of the characteristic-2 field F2^m.
-
-   k:  The exponent k for the trinomial basis representation x^m + x^k
-      +1.
-
-   k1, k2, k3:  The exponents for the pentanomial representation x^m +
-      x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
-
-   namedcurve:  Specifies a recommended set of elliptic curve domain
-      parameters.  All enum values of NamedCurve are allowed except for
-      arbitrary_explicit_prime_curves(253) and
-      arbitrary_explicit_char2_curves(254).  These two values are only
-      allowed in the ClientHello extension.
-
-
-        struct {
-            ECParameters    curve_params;
-            ECPoint         public;
-        } ServerECDHParams;
-
-   curve_params:  Specifies the elliptic curve domain parameters
-      associated with the ECDH public key.
-
-   public:  The ephemeral ECDH public key.
-
-   The ServerKeyExchange message is extended as follows.
-
-        enum { ec_diffie_hellman } KeyExchangeAlgorithm;
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 20]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   ec_diffie_hellman:  Indicates the ServerKeyExchange message contains
-      an ECDH public key.
-
-
-        select (KeyExchangeAlgorithm) {
-            case ec_diffie_hellman:
-                ServerECDHParams    params;
-                Signature           signed_params;
-        } ServerKeyExchange;
-
-   params:  Specifies the ECDH public key and associated domain
-      parameters.
-
-   signed_params:  A hash of the params, with the signature appropriate
-      to that hash applied.  The private key corresponding to the
-      certified public key in the server's Certificate message is used
-      for signing.
-
-
-          enum { ecdsa } SignatureAlgorithm;
-
-
-          select (SignatureAlgorithm) {
-              case ecdsa:
-                  digitally-signed struct {
-                      opaque sha_hash[sha_size];
-                  };
-          } Signature;
-
-   NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
-   algorithm and "anonymous" for ECDH_anon.  These cases are defined in
-   TLS [2].  SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA.  ECDSA
-   signatures are generated and verified as described in Section 5.10.
-   As per ANSI X9.62, an ECDSA signature consists of a pair of integers
-   r and s.  These integers are both converted into byte strings of the
-   same length as the curve order n using the conversion routine
-   specified in Section 4.3.1 of [6].  The two byte strings are
-   concatenated, and the result is placed in the signature field.
-
-   Actions of the sender:
-
-   The server selects elliptic curve domain parameters and an ephemeral
-   ECDH public key corresponding to these parameters according to the
-   ECKAS-DH1 scheme from IEEE 1363 [5].  It conveys this information to
-   the client in the ServerKeyExchange message using the format defined
-   above.
-
-   Actions of the recipient:
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 21]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   The client verifies the signature (when present) and retrieves the
-   server's elliptic curve domain parameters and ephemeral ECDH public
-   key from the ServerKeyExchange message.
-
-5.5  Certificate Request
-
-   When this message is sent:
-
-   This message is sent when requesting client authentication.
-
-   Meaning of this message:
-
-   The server uses this message to suggest acceptable client
-   authentication methods.
-
-   Structure of this message:
-
-   The TLS CertificateRequest message is extended as follows.
-
-        enum {
-            ecdsa_sign(??), rsa_fixed_ecdh(??),
-            ecdsa_fixed_ecdh(??), (255)
-        } ClientCertificateType;
-
-   ecdsa_sign, etc Indicates that the server would like to use the
-      corresponding client authentication method specified in Section 3.
-
-      [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
-      ecdsa_fixed_ecdh have been left as ??.  These values will be
-      assigned when this draft progresses to RFC.  Earlier versions of
-      this draft used the values 5, 6, and 7 - however these values have
-      been removed since they are used differently by SSL 3.0 [14] and
-      their use by TLS is being deprecated. ]]
-
-   Actions of the sender:
-
-   The server decides which client authentication methods it would like
-   to use, and conveys this information to the client using the format
-   defined above.
-
-   Actions of the receiver:
-
-   The client determines whether it has a suitable certificate for use
-   with any of the requested methods, and decides whether or not to
-   proceed with client authentication.
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 22]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-5.6  Client Certificate
-
-   When this message is sent:
-
-   This message is sent in response to a CertificateRequest when a
-   client has a suitable certificate and has decided to proceed with
-   client authentication.  (Note that if the server has used a Supported
-   Point Formats Extension, a certificate can only be considered
-   suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and
-   ECDSA_fixed_ECDH authentication methods if the public key point
-   specified in it respects the server's choice of point formats.  If no
-   Supported Point Formats Extension has been used, a certificate can
-   only be considered suitable for use with these authentication methods
-   if the point is represented in uncompressed point format.)
-
-   Meaning of this message:
-
-   This message is used to authentically convey the client's static
-   public key to the server.  The following table summarizes what client
-   certificate types are appropriate for the ECC-based client
-   authentication mechanisms described in Section 3.  ECC public keys
-   must be encoded in certificates as described in Section 5.9.
-
-   NOTE: The client's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 4 apply only to
-   the client's certificate (first in the chain).
-
-
-          Client
-          Authentication Method   Client Certificate Type
-          ---------------------   -----------------------
-
-          ECDSA_sign              Certificate MUST contain an
-                                  ECDSA-capable public key and
-                                  be signed with ECDSA.
-
-          ECDSA_fixed_ECDH        Certificate MUST contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  MUST be signed with ECDSA.
-
-          RSA_fixed_ECDH          Certificate MUST contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  MUST be signed with RSA.
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 23]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-                     Table 4: Client certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS client Certificate format.
-
-   Actions of the sender:
-
-   The client constructs an appropriate certificate chain, and conveys
-   it to the server in the Certificate message.
-
-   Actions of the receiver:
-
-   The TLS server validates the certificate chain, extracts the client's
-   public key, and checks that the key type is appropriate for the
-   client authentication method.
-
-5.7  Client Key Exchange
-
-   When this message is sent:
-
-   This message is sent in all key exchange algorithms.  If client
-   authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
-   message is empty.  Otherwise, it contains the client's ephemeral ECDH
-   public key.
-
-   Meaning of the message:
-
-   This message is used to convey ephemeral data relating to the key
-   exchange belonging to the client (such as its ephemeral ECDH public
-   key).
-
-   Structure of this message:
-
-   The TLS ClientKeyExchange message is extended as follows.
-
-        enum { implicit, explicit } PublicValueEncoding;
-
-   implicit, explicit:  For ECC cipher suites, this indicates whether
-      the client's ECDH public key is in the client's certificate
-      ("implicit") or is provided, as an ephemeral ECDH public key, in
-      the ClientKeyExchange message ("explicit").  (This is "explicit"
-      in ECC cipher suites except when the client uses the
-      ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
-      mechanism.)
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 24]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-        struct {
-            select (PublicValueEncoding) {
-                case implicit: struct { };
-                case explicit: ECPoint ecdh_Yc;
-            } ecdh_public;
-        } ClientECDiffieHellmanPublic;
-
-   ecdh_Yc:  Contains the client's ephemeral ECDH public key as a byte
-      string ECPoint.point, which may represent an elliptic curve point
-      in uncompressed or compressed format.  Here the format MUST
-      conform to what the server has requested through a Supported Point
-      Formats Extension if this extension was used, and MUST be
-      uncompressed if this extension was not used.
-
-
-        struct {
-            select (KeyExchangeAlgorithm) {
-                case ec_diffie_hellman: ClientECDiffieHellmanPublic;
-            } exchange_keys;
-        } ClientKeyExchange;
-
-   Actions of the sender:
-
-   The client selects an ephemeral ECDH public key corresponding to the
-   parameters it received from the server according to the ECKAS-DH1
-   scheme from IEEE 1363 [5].  It conveys this information to the client
-   in the ClientKeyExchange message using the format defined above.
-
-   Actions of the recipient:
-
-   The server retrieves the client's ephemeral ECDH public key from the
-   ClientKeyExchange message and checks that it is on the same elliptic
-   curve as the server's ECDH key.
-
-5.8  Certificate Verify
-
-   When this message is sent:
-
-   This message is sent when the client sends a client certificate
-   containing a public key usable for digital signatures, e.g. when the
-   client is authenticated using the ECDSA_sign mechanism.
-
-   Meaning of the message:
-
-   This message contains a signature that proves possession of the
-   private key corresponding to the public key in the client's
-   Certificate message.
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 25]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   Structure of this message:
-
-   The TLS CertificateVerify message is extended as follows.
-
-        enum { ecdsa } SignatureAlgorithm;
-
-        select (SignatureAlgorithm) {
-            case ecdsa:
-                digitally-signed struct {
-                    opaque sha_hash[sha_size];
-                };
-        } Signature;
-
-   For the ecdsa case, the signature field in the CertificateVerify
-   message contains an ECDSA signature computed over handshake messages
-   exchanged so far.  ECDSA signatures are computed as described in
-   Section 5.10.  As per ANSI X9.62, an ECDSA signature consists of a
-   pair of integers r and s.  These integers are both converted into
-   byte strings of the same length as the curve order n using the
-   conversion routine specified in Section 4.3.1 of [6].  The two byte
-   strings are concatenated, and the result is placed in the signature
-   field.
-
-   Actions of the sender:
-
-   The client computes its signature over all handshake messages sent or
-   received starting at client hello up to but not including this
-   message.  It uses the private key corresponding to its certified
-   public key to compute the signature which is conveyed in the format
-   defined above.
-
-   Actions of the receiver:
-
-   The server extracts the client's signature from the CertificateVerify
-   message, and verifies the signature using the public key it received
-   in the client's Certificate message.
-
-5.9  Elliptic Curve Certificates
-
-   X509 certificates containing ECC public keys or signed using ECDSA
-   MUST comply with [11] or another RFC that replaces or extends it.
-   Clients SHOULD use the elliptic curve domain parameters recommended
-   in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
-
-5.10  ECDH, ECDSA and RSA Computations
-
-   All ECDH calculations (including parameter and key generation as well
-   as the shared secret calculation) are performed according to [5]
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 26]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   using the ECKAS-DH1 scheme with the identity map as key derivation
-   function, so that the premaster secret is the x-coordinate of the
-   ECDH shared secret elliptic curve point represented as an octet
-   string.  Note that this octet string (Z in IEEE 1363 terminology) as
-   output by FE2OSP, the Field Element to Octet String Conversion
-   Primitive, has constant length for any given field; leading zeros
-   found in this octet string MUST NOT be truncated.
-
-   Note that a new extension may be introduced in the future to allow
-   the use of a different KDF during computation of the premaster
-   secret.  In this event, the new KDF would be used in place of the
-   process detailed above.  This may be desirable, for example, to
-   support compatibility with the planned NIST key agreement standard.
-
-   All ECDSA computations MUST be performed according to ANSI X9.62 [6]
-   or its successors.  Data to be signed/verified is hashed and the
-   result run directly through the ECDSA algorithm with no additional
-   hashing.  The default hash function is SHA-1 [7] and sha_size (see
-   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
-   function, such as one of the new SHA hash functions specified in FIPS
-   180-2 [7], may be used instead if the certificate containing the EC
-   public key explicitly requires use of another hash function.  (The
-   mechanism for specifying the required hash function has not been
-   standardized but this provision anticipates such standardization and
-   obviates the need to update this document in response.  Future PKIX
-   RFCs may choose, for example, to specify the hash function to be used
-   with a public key in the parameters field of subjectPublicKeyInfo.)
-
-   All RSA signatures must be generated and verified according to PKCS#1
-   [9] block type 1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 27]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-6.  Cipher Suites
-
-   The table below defines new ECC cipher suites that use the key
-   exchange algorithms specified in Section 2.
-
-     CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA           = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA    = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA       = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA             = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_anon_NULL_WITH_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-                        Table 5: TLS ECC cipher suites
-
-
-   [[ EDITOR: The actual cipher suite numbers will be assigned when this
-   draft progresses to RFC. ]]
-
-   The key exchange method, cipher, and hash algorithm for each of these
-   cipher suites are easily determined by examining the name.  Ciphers
-   other than AES ciphers, and hash algorithms are defined in [2].  AES
-   ciphers are defined in [15].
-
-   Server implementations SHOULD support all of the following cipher
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 28]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   suites, and client implementations SHOULD support at least one of
-   them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
-   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 29]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-7.  Security Considerations
-
-   This document is based on [2], [5], [6] and [15].  The appropriate
-   security considerations of those documents apply.
-
-   One important issue that implementors and users must consider is
-   elliptic curve selection.  Guidance on selecting an appropriate
-   elliptic curve size is given in Table 1.
-
-   Beyond elliptic curve size, the main issue is elliptic curve
-   structure.  As a general principle, it is more conservative to use
-   elliptic curves with as little algebraic structure as possible - thus
-   random curves are more conservative than special curves such as
-   Koblitz curves, and curves over F_p with p random are more
-   conservative than curves over F_p with p of a special form (and
-   curves over F_p with p random might be considered more conservative
-   than curves over F_2^m as there is no choice between multiple fields
-   of similar size for characteristic 2).  Note, however, that algebraic
-   structure can also lead to implementation efficiencies and
-   implementors and users may, therefore, need to balance conservatism
-   against a need for efficiency.  Concrete attacks are known against
-   only very few special classes of curves, such as supersingular
-   curves, and these classes are excluded from the ECC standards that
-   this document references [5], [6].
-
-   Another issue is the potential for catastrophic failures when a
-   single elliptic curve is widely used.  In this case, an attack on the
-   elliptic curve might result in the compromise of a large number of
-   keys.  Again, this concern may need to be balanced against efficiency
-   and interoperability improvements associated with widely-used curves.
-   Substantial additional information on elliptic curve choice can be
-   found in [4], [5], [6], [8].
-
-   Implementors and users must also consider whether they need forward
-   secrecy.  Forward secrecy refers to the property that session keys
-   are not compromised if the static, certified keys belonging to the
-   server and client are compromised.  The ECDHE_ECDSA and ECDHE_RSA key
-   exchange algorithms provide forward secrecy protection in the event
-   of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
-   Similarly if the client is providing a static, certified key,
-   ECDSA_sign client authentication provides forward secrecy protection
-   in the event of client key compromise, while ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH do not.  Thus to obtain complete forward secrecy
-   protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
-   with ECDSA_sign used for client authentication if necessary.  Here
-   again the security benefits of forward secrecy may need to be
-   balanced against the improved efficiency offered by other options.
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 30]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-8.  Acknowledgments
-
-   The authors wish to thank Bill Anderson and Tim Dierks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 31]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [3]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-         T. Wright, "Transport Layer Security (TLS) Extensions",
-         draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005.
-
-   [4]   SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
-         <http://www.secg.org/>.
-
-   [5]   IEEE, "Standard Specifications for Public Key Cryptography",
-         IEEE 1363, 2000.
-
-   [6]   ANSI, "Public Key Cryptography For The Financial Services
-         Industry: The Elliptic Curve Digital Signature Algorithm
-         (ECDSA)", ANSI X9.62, 1998.
-
-   [7]   NIST, "Secure Hash Standard", FIPS 180-2, 2002.
-
-   [8]   NIST, "Digital Signature Standard", FIPS 186-2, 2000.
-
-   [9]   RSA Laboratories, "PKCS#1: RSA Encryption Standard version
-         1.5", PKCS 1, November 1993.
-
-   [10]  SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
-         2000, <http://www.secg.org/>.
-
-   [11]  Polk, T., Housley, R., and L. Bassham, "Algorithms and
-         Identifiers for the Internet X.509 Public Key Infrastructure
-         Certificate and Certificate Revocation List (CRL) Profile",
-         RFC 3279, April 2002.
-
-9.2  Informative References
-
-   [12]  Harper, G., Menezes, A., and S. Vanstone, "Public-Key
-         Cryptosystems with Very Small Key Lengths", Advances in
-         Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
-
-   [13]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", Journal of Cryptology 14 (2001) 255-293,
-         <http://www.cryptosavvy.com/>.
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 32]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   [14]  Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
-         Version 3.0", November 1996,
-         <http://wp.netscape.com/eng/ssl3/draft302.txt>.
-
-   [15]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-         Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-
-Authors' Addresses
-
-   Vipul Gupta
-   Sun Microsystems Laboratories
-   16 Network Circle
-   MS UMPK16-160
-   Menlo Park, CA  94025
-   US
-
-   Phone: +1 650 786 7551
-   Email: vipul.gupta@sun.com
-
-
-   Simon Blake-Wilson
-   Basic Commerce & Industries, Inc.
-   96 Spandia Ave
-   Unit 606
-   Toronto, ON  M6G 2T6
-   CA
-
-   Phone: +1 416 214 5961
-   Email: sblakewilson@bcisse.com
-
-
-   Bodo Moeller
-   University of Calgary
-   Dept of Math & Stats
-   2500 University Dr NW
-   Calgary, AB  T2N 1N4
-   CA
-
-   Phone: +1 403 220 5735
-   Email: bodo@openssl.org
-
-
-   Chris Hawk
-   Corriente Networks
-
-   Email: chris@corriente.net
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 33]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-   Nelson Bolyard
-
-   Email: nelson@bolyard.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 34]
-
-Internet-Draft          ECC Cipher Suites for TLS               May 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Gupta, et al.           Expires December 2, 2005               [Page 35]
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-11.txt b/doc/protocol/draft-ietf-tls-ecc-11.txt
deleted file mode 100644
index b1ef49bd98..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-11.txt
+++ /dev/null
@@ -1,2016 +0,0 @@
-
-
-
-TLS Working Group                                               V. Gupta
-Internet-Draft                                                  Sun Labs
-Expires: March 20, 2006                                  S. Blake-Wilson
-                                                                     BCI
-                                                              B. Moeller
-                                                   University of Calgary
-                                                                 C. Hawk
-                                                      Corriente Networks
-                                                              N. Bolyard
-                                                      September 16, 2005
-
-
-                       ECC Cipher Suites for TLS
-                      <draft-ietf-tls-ecc-11.txt>
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on March 20, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes new key exchange algorithms based on Elliptic
-   Curve Cryptography (ECC) for the TLS (Transport Layer Security)
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 1]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   protocol.  In particular, it specifies the use of Elliptic Curve
-   Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
-   Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
-   authentication mechanism.
-
-   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 [1].
-
-   Please send comments on this document to the TLS mailing list.
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Key Exchange Algorithms  . . . . . . . . . . . . . . . . . .   5
-     2.1  ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.2  ECDHE_ECDSA  . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.3  ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.4  ECDHE_RSA  . . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.5  ECDH_anon  . . . . . . . . . . . . . . . . . . . . . . . .   8
-   3.   Client Authentication  . . . . . . . . . . . . . . . . . . .   9
-     3.1  ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . .   9
-     3.2  ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . .  10
-     3.3  RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . .  10
-   4.   TLS Extensions for ECC . . . . . . . . . . . . . . . . . . .  11
-   5.   Data Structures and Computations . . . . . . . . . . . . . .  12
-     5.1  Client Hello Extensions  . . . . . . . . . . . . . . . . .  12
-     5.2  Server Hello Extension . . . . . . . . . . . . . . . . . .  15
-     5.3  Server Certificate . . . . . . . . . . . . . . . . . . . .  16
-     5.4  Server Key Exchange  . . . . . . . . . . . . . . . . . . .  18
-     5.5  Certificate Request  . . . . . . . . . . . . . . . . . . .  22
-     5.6  Client Certificate . . . . . . . . . . . . . . . . . . . .  23
-     5.7  Client Key Exchange  . . . . . . . . . . . . . . . . . . .  24
-     5.8  Certificate Verify . . . . . . . . . . . . . . . . . . . .  25
-     5.9  Elliptic Curve Certificates  . . . . . . . . . . . . . . .  26
-     5.10   ECDH, ECDSA and RSA Computations . . . . . . . . . . . .  26
-   6.   Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . .  28
-   7.   Security Considerations  . . . . . . . . . . . . . . . . . .  30
-   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  31
-   9.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  32
-   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  33
-     10.1   Normative References . . . . . . . . . . . . . . . . . .  33
-     10.2   Informative References . . . . . . . . . . . . . . . . .  33
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  34
-        Intellectual Property and Copyright Statements . . . . . . .  36
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 2]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-1.  Introduction
-
-   Elliptic Curve Cryptography (ECC) is emerging as an attractive
-   public-key cryptosystem for mobile/wireless environments.  Compared
-   to currently prevalent cryptosystems such as RSA, ECC offers
-   equivalent security with smaller key sizes.  This is illustrated in
-   the following table, based on [14], which gives approximate
-   comparable key sizes for symmetric- and asymmetric-key cryptosystems
-   based on the best-known algorithms for attacking them.
-
-                   Symmetric    |  ECC    |  DH/DSA/RSA
-                   -------------+---------+------------
-                      80        |  163    |  1024
-                     112        |  233    |  2048
-                     128        |  283    |  3072
-                     192        |  409    |  7680
-                     256        |  571    |  15360
-
-                  Table 1: Comparable key sizes (in bits)
-
-
-   Smaller key sizes result in power, bandwidth and computational
-   savings that make ECC especially attractive for constrained
-   environments.
-
-   This document describes additions to TLS to support ECC.  In
-   particular, it defines
-
-   o  the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
-      scheme with long-term or ephemeral keys to establish the TLS
-      premaster secret, and
-
-   o  the use of fixed-ECDH certificates and ECDSA for authentication of
-      TLS peers.
-
-   The remainder of this document is organized as follows.  Section 2
-   provides an overview of ECC-based key exchange algorithms for TLS.
-   Section 3 describes the use of ECC certificates for client
-   authentication.  TLS extensions that allow a client to negotiate the
-   use of specific curves and point formats are presented in Section 4.
-   Section 5 specifies various data structures needed for an ECC-based
-   handshake, their encoding in TLS messages and the processing of those
-   messages.  Section 6 defines new ECC-based cipher suites and
-   identifies a small subset of these as recommended for all
-   implementations of this specification.  Section 7 discusses security
-   considerations.  Section 8 describes IANA considerations for the name
-   spaces created by this document.  Section 9 gives acknowledgments.
-   This is followed by the lists of normative and informative references
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 3]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   cited in this document, the authors' contact information, and
-   statements on intellectual property rights and copyrights.
-
-   Implementation of this specification requires familiarity with TLS
-   [2], TLS extensions [3] and ECC [4][5][6][8].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 4]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-2.  Key Exchange Algorithms
-
-   This document introduces five new ECC-based key exchange algorithms
-   for TLS.  All of them use ECDH to compute the TLS premaster secret
-   and differ only in the lifetime of ECDH keys (long-term or ephemeral)
-   and the mechanism (if any) used to authenticate them.  The derivation
-   of the TLS master secret from the premaster secret and the subsequent
-   generation of bulk encryption/MAC keys and initialization vectors is
-   independent of the key exchange algorithm and not impacted by the
-   introduction of ECC.
-
-   The table below summarizes the new key exchange algorithms which
-   mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]),
-   respectively.
-
-          Key
-          Exchange
-          Algorithm           Description
-          ---------           -----------
-
-          ECDH_ECDSA          Fixed ECDH with ECDSA-signed certificates.
-
-          ECDHE_ECDSA         Ephemeral ECDH with ECDSA signatures.
-
-          ECDH_RSA            Fixed ECDH with RSA-signed certificates.
-
-          ECDHE_RSA           Ephemeral ECDH with RSA signatures.
-
-          ECDH_anon           Anonymous ECDH, no signatures.
-
-                     Table 2: ECC key exchange algorithms
-
-
-   The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
-   secrecy.  With ECDHE_RSA, a server can reuse its existing RSA
-   certificate and easily comply with a constrained client's elliptic
-   curve preferences (see Section 4).  However, the computational cost
-   incurred by a server is higher for ECDHE_RSA than for the traditional
-   RSA key exchange which does not provide forward secrecy.
-
-   The ECDH_RSA mechanism requires a server to acquire an ECC
-   certificate but the certificate issuer can still use an existing RSA
-   key for signing.  This eliminates the need to update the trusted key
-   store in TLS clients.  The ECDH_ECDSA mechanism requires ECC keys for
-   the server as well as the certification authority and is best suited
-   for constrained devices unable to support RSA.
-
-   The anonymous key exchange algorithm does not provide authentication
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 5]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   of the server or the client.  Like other anonymous TLS key exchanges,
-   it is subject to man-in-the-middle attacks.  Implementations of this
-   algorithm SHOULD provide authentication by other means.
-
-   Note that there is no structural difference between ECDH and ECDSA
-   keys.  A certificate issuer may use X509.v3 keyUsage and
-   extendedKeyUsage extensions to restrict the use of an ECC public key
-   to certain computations.  This document refers to an ECC key as ECDH-
-   capable if its use in ECDH is permitted.  ECDSA-capable is defined
-   similarly.
-
-
-              Client                                        Server
-              ------                                        ------
-
-              ClientHello          -------->
-                                                       ServerHello
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                              CertificateRequest*+
-                                   <--------       ServerHelloDone
-              Certificate*+
-              ClientKeyExchange
-              CertificateVerify*+
-              [ChangeCipherSpec]
-              Finished             -------->
-                                                [ChangeCipherSpec]
-                                   <--------              Finished
-
-              Application Data     <------->      Application Data
-
-
-                   * message is not sent under some conditions
-                   + message is not sent unless client authentication
-                     is desired
-
-                 Figure 1: Message flow in a full TLS handshake
-
-
-   Figure 1 shows all messages involved in the TLS key establishment
-   protocol (aka full handshake).  The addition of ECC has direct impact
-   only on the ClientHello, the ServerHello, the server's Certificate
-   message, the ServerKeyExchange, the ClientKeyExchange, the
-   CertificateRequest, the client's Certificate message, and the
-   CertificateVerify.  Next, we describe each ECC key exchange algorithm
-   in greater detail in terms of the content and processing of these
-   messages.  For ease of exposition, we defer discussion of client
-   authentication and associated messages (identified with a + in
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 6]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   Figure 1) until Section 3 and of the optional ECC-specific extensions
-   (which impact the Hello messages) until Section 4.
-
-2.1  ECDH_ECDSA
-
-   In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
-   public key and be signed with ECDSA.
-
-   A ServerKeyExchange MUST NOT be sent (the server's certificate
-   contains all the necessary keying information required by the client
-   to arrive at the premaster secret).
-
-   The client generates an ECDH key pair on the same curve as the
-   server's long-term public key and send its public key in the
-   ClientKeyExchange message (except when using client authentication
-   algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
-   modifications from Section 3.2 or Section 3.3 apply).
-
-   Both client and server perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10
-
-2.2  ECDHE_ECDSA
-
-   In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
-   capable public key and be signed with ECDSA.
-
-   The server sends its ephemeral ECDH public key and a specification of
-   the corresponding curve in the ServerKeyExchange message.  These
-   parameters MUST be signed with ECDSA using the private key
-   corresponding to the public key in the server's Certificate.
-
-   The client generates an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server perform an ECDH operation (Section 5.10) and
-   use the resultant shared secret as the premaster secret.
-
-2.3  ECDH_RSA
-
-   This key exchange algorithm is the same as ECDH_ECDSA except the
-   server's certificate MUST be signed with RSA rather than ECDSA.
-
-2.4  ECDHE_RSA
-
-   This key exchange algorithm is the same as ECDHE_ECDSA except the
-   server's certificate MUST contain an RSA public key authorized for
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 7]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   signing and the signature in the ServerKeyExchange message must be
-   computed with the corresponding RSA private key.  The server
-   certificate MUST be signed with RSA.
-
-2.5  ECDH_anon
-
-   In ECDH_anon, the server's Certificate, the CertificateRequest, the
-   client's Certificate, and the CertificateVerify messages MUST NOT be
-   sent.
-
-   The server MUST send an ephemeral ECDH public key and a specification
-   of the corresponding curve in the ServerKeyExchange message.  These
-   parameters MUST NOT be signed.
-
-   The client generates an ECDH key pair on the same curve as the
-   server's ephemeral ECDH key and send its public key in the
-   ClientKeyExchange message.
-
-   Both client and server perform an ECDH operation and use the
-   resultant shared secret as the premaster secret.  All ECDH
-   calculations are performed as specified in Section 5.10.
-
-   Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
-   key exchange algorithms require the server's certificate to be signed
-   with a particular signature scheme, this specification (following the
-   similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not
-   impose restrictions on signature schemes used elsewhere in the
-   certificate chain.  (Often such restrictions will be useful, and it
-   is expected that this will be taken into account in certification
-   authorities' signing practices.  However, such restrictions are not
-   strictly required in general: Even if it is beyond the capabilities
-   of a client to completely validate a given chain, the client may be
-   able to validate the server's certificate by relying on a trust
-   anchor that appears as one of the intermediate certificates in the
-   chain.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 8]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-3.  Client Authentication
-
-   This document defines three new client authentication mechanisms
-   named after the type of client certificate involved: ECDSA_sign,
-   ECDSA_fixed_ECDH and RSA_fixed_ECDH.  The ECDSA_sign mechanism is
-   usable with any of the non-anonymous ECC key exchange algorithms
-   described in Section 2 as well as other non-anonymous (non-ECC) key
-   exchange algorithms defined in TLS [2].  The ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
-   Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
-   use of a long-term ECDH client key would jeopardize the forward
-   secrecy property of these algorithms.
-
-   The server can request ECC-based client authentication by including
-   one or more of these certificate types in its CertificateRequest
-   message.  The server must not include any certificate types that are
-   prohibited for the negotiated key exchange algorithm.  The client
-   must check if it possesses a certificate appropriate for any of the
-   methods suggested by the server and is willing to use it for
-   authentication.
-
-   If these conditions are not met, the client should send a client
-   Certificate message containing no certificates.  In this case, the
-   ClientKeyExchange should be sent as described in Section 2 and the
-   CertificateVerify should not be sent.  If the server requires client
-   authentication, it may respond with a fatal handshake failure alert.
-
-   If the client has an appropriate certificate and is willing to use it
-   for authentication, it must send that certificate in the client's
-   Certificate message (as per Section 5.6) and prove possession of the
-   private key corresponding to the certified key.  The process of
-   determining an appropriate certificate and proving possession is
-   different for each authentication mechanism and described below.
-
-   NOTE: It is permissible for a server to request (and the client to
-   send) a client certificate of a different type than the server
-   certificate.
-
-3.1  ECDSA_sign
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDSA-capable public key and signed with
-   ECDSA.
-
-   The client proves possession of the private key corresponding to the
-   certified key by including a signature in the CertificateVerify
-   message as described in Section 5.8.
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                 [Page 9]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-3.2  ECDSA_fixed_ECDH
-
-   To use this authentication mechanism, the client MUST possess a
-   certificate containing an ECDH-capable public key and that
-   certificate MUST be signed with ECDSA.  Furthermore, the client's
-   ECDH key MUST be on the same elliptic curve as the server's long-term
-   (certified) ECDH key.  This might limit use of this mechanism to
-   closed environments.  In situations where the client has an ECC key
-   on a different curve, it would have to authenticate either using
-   ECDSA_sign or a non-ECC mechanism (e.g.  RSA).  Using fixed ECDH for
-   both servers and clients is computationally more efficient than
-   mechanisms providing forward secrecy.
-
-   When using this authentication mechanism, the client MUST send an
-   empty ClientKeyExchange as described in Section 5.7 and MUST NOT send
-   the CertificateVerify message.  The ClientKeyExchange is empty since
-   the client's ECDH public key required by the server to compute the
-   premaster secret is available inside the client's certificate.  The
-   client's ability to arrive at the same premaster secret as the server
-   (demonstrated by a successful exchange of Finished messages) proves
-   possession of the private key corresponding to the certified public
-   key and the CertificateVerify message is unnecessary.
-
-3.3  RSA_fixed_ECDH
-
-   This authentication mechanism is identical to ECDSA_fixed_ECDH except
-   the client's certificate MUST be signed with RSA.
-
-   Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH
-   client authentication mechanisms require the clients's certificate to
-   be signed with a particular signature scheme, this specification does
-   not impose restrictions on signature schemes used elsewhere in the
-   certificate chain.  (Often such restrictions will be useful, and it
-   is expected that this will be taken into account in certification
-   authorities' signing practices.  However, such restrictions are not
-   strictly required in general: Even if it is beyond the capabilities
-   of a server to completely validate a given chain, the server may be
-   able to validate the clients certificate by relying on a trust anchor
-   that appears as one of the intermediate certificates in the chain.)
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 10]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-4.  TLS Extensions for ECC
-
-   Two new TLS extensions are defined in this specification: (i) the
-   Supported Elliptic Curves Extension, and (ii) the Supported Point
-   Formats Extension.  These allow negotiating the use of specific
-   curves and point formats (e.g. compressed vs. uncompressed),
-   respectively, during a handshake starting a new session.  These
-   extensions are especially relevant for constrained clients that may
-   only support a limited number of curves or point formats.  They
-   follow the general approach outlined in [3]; message details are
-   specified in Section 5.  The client enumerates the curves it supports
-   and the point formats it can parse by including the appropriate
-   extensions in its ClientHello message.  The server similarly
-   enumerates the point formats it can parse by including an extension
-   in its ServerHello message.
-
-   A TLS client that proposes ECC cipher suites in its ClientHello
-   message SHOULD include these extensions.  Servers implementing ECC
-   cipher suites MUST support these extensions, and when a client uses
-   these extensions, servers MUST NOT negotiate the use of an ECC cipher
-   suite unless they can complete the handshake while respecting the
-   choice of curves and compression techniques specified by the client.
-   This eliminates the possibility that a negotiated ECC handshake will
-   be subsequently aborted due to a client's inability to deal with the
-   server's EC key.
-
-   These extensions MUST NOT be included if the client does not propose
-   any ECC cipher suites.  A client that proposes ECC cipher suites may
-   choose not to include these extension.  In this case, the server is
-   free to choose any one of the elliptic curves or point formats listed
-   in Section 5.  That section also describes the structure and
-   processing of these extensions in greater detail.
-
-   In the case of session resumption, the server simply ignores the
-   Supported Elliptic Curves Extension and the Supported Point Formats
-   Extension as appearing in the current ClientHello message.  These
-   extensions only play a role during handshakes negotiating a new
-   session.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 11]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-5.  Data Structures and Computations
-
-   This section specifies the data structures and computations used by
-   ECC-based key mechanisms specified in Section 2, Section 3 and
-   Section 4.  The presentation language used here is the same as that
-   used in TLS [2].  Since this specification extends TLS, these
-   descriptions should be merged with those in the TLS specification and
-   any others that extend TLS.  This means that enum types may not
-   specify all possible values and structures with multiple formats
-   chosen with a select() clause may not indicate all possible cases.
-
-5.1  Client Hello Extensions
-
-   This section specifies two TLS extensions that can be included with
-   the ClientHello message as described in [3], the Supported Elliptic
-   Curves Extension and the Supported Point Formats Extension.
-
-   When these extensions are sent:
-
-   The extensions SHOULD be sent along with any ClientHello message that
-   proposes ECC cipher suites.
-
-   Meaning of these extensions:
-
-   These extensions allow a client to enumerate the elliptic curves it
-   supports and/or the point formats it can parse.
-
-   Structure of these extensions:
-
-   The general structure of TLS extensions is described in [3] and this
-   specification adds two new types to ExtensionType.
-
-
-       enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType;
-
-   [[ EDITOR: The values used for elliptic_curves and ec_point_formats
-   have been left as ??.  These values will be assigned when this draft
-   progresses to RFC.  (The examples below will have to be changed
-   accordingly.) ]]
-
-   elliptic_curves (Supported Elliptic Curves Extension):  Indicates the
-      set of elliptic curves supported by the client.  For this
-      extension, the opaque extension_data field contains
-      EllipticCurveList.
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 12]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   ec_point_formats (Supported Point Formats Extension):  Indicates the
-      set of point formats that the client can parse.  For this
-      extension, the opaque extension_data field contains
-      ECPointFormatList.
-
-
-        enum {
-            sect163k1 (1), sect163r1 (2), sect163r2 (3),
-            sect193r1 (4), sect193r2 (5), sect233k1 (6),
-            sect233r1 (7), sect239k1 (8), sect283k1 (9),
-            sect283r1 (10), sect409k1 (11), sect409r1 (12),
-            sect571k1 (13), sect571r1 (14), secp160k1 (15),
-            secp160r1 (16), secp160r2 (17), secp192k1 (18),
-            secp192r1 (19), secp224k1 (20), secp224r1 (21),
-            secp256k1 (22), secp256r1 (23), secp384r1 (24),
-            secp521r1 (25),
-            reserved (0xFE00..0xFEFF),
-            arbitrary_explicit_prime_curves(0xFF01),
-            arbitrary_explicit_char2_curves(0xFF02),
-            (0xFFFF)
-        } NamedCurve;
-
-   sect163k1, etc:  Indicates support of the corresponding named curve
-      or class of explicitly defined curves.  The named curves defined
-      here are those specified in SEC 2 [10].  Note that many of these
-      curves are also recommended in ANSI X9.62 [6] and FIPS 186-2 [8].
-      Values 0xFE00 through 0xFEFF are reserved for private use.  Values
-      0xFF01 and 0xFF02 indicate that the client supports arbitrary
-      prime and characteristic-2 curves, respectively (the curve
-      parameters must be encoded explicitly in ECParameters).
-
-   The NamedCurve name space is maintained by IANA.  See Section 8 for
-   information on how new value assignments are added.
-
-
-        struct {
-            NamedCurve elliptic_curve_list<1..2^8-1>
-        } EllipticCurveList;
-
-
-   Items in elliptic_curve_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   As an example, a client that only supports secp192r1 (aka NIST P-192;
-   value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015)
-   and prefers to use secp192r1 would include a TLS extension consisting
-   of the following octets:
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 13]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-        00 ?? 00 06 00 04 00 13 00 15
-
-   A client that supports arbitrary explicit characteristic-2 curves
-   (value 0xFF02) would include an extension consisting of the following
-   octets:
-
-        00 ?? 00 04 00 02 FF 02
-
-
-        enum { uncompressed (0), ansiX962_compressed_prime (1),
-               ansiX962_compressed_char2 (2), reserved (248..255)
-        } ECPointFormat;
-
-        struct {
-            ECPointFormat ec_point_format_list<1..2^8-1>
-        } ECPointFormatList;
-
-   Three point formats are included in the definition of ECPointFormat
-   above.  The uncompressed point format is the default format in that
-   implementations of this document MUST support it for all of their
-   supported curves.  Compressed point formats reduce bandwidth by
-   including only the x-coordinate and a single bit of the y-coordinate
-   of the point.  Implementations of this document MAY support the
-   ansiX962_compressed_prime and ansiX962_compressed_char2 formats,
-   where the former applies only to prime curves and the latter applies
-   only to characteristic-2 curves.  (These formats are specified in
-   [6].)  Values 248 through 255 are reserved for private use.
-
-   The ECPointFormat name space is maintained by IANA.  See Section 8
-   for information on how new value assignments are added.
-
-   Items in ec_point_format_list are ordered according to the client's
-   preferences (favorite choice first).
-
-   A client that can parse only the uncompressed point format (value 0)
-   includes an extension consisting of the following octets:
-
-        00 ?? 00 02 01 00
-
-   A client that in the case of prime fields prefers the compressed
-   format (ansiX962_compressed_prime, value 1) over the uncompressed
-   format (value 0), but in the case of characteristic-2 fields prefers
-   the uncompressed format (value 0) over the compressed format
-   (ansiX962_compressed_char2, value 2), may indicate these preferences
-   by including an extension consisting of the following octets:
-
-        00 ?? 00 04 03 01 00 02
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 14]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   Actions of the sender:
-
-   A client that proposes ECC cipher suites in its ClientHello message
-   appends these extensions (along with any others), enumerating the
-   curves it supports and the point formats it can parse.  Clients
-   SHOULD send both the Supported Elliptic Curves Extension and the
-   Supported Point Formats Extension.  If the Supported Point Formats
-   Extension is indeed sent, it MUST contain the value 0 (uncompressed)
-   as one of the items in the list of point formats.
-
-   Actions of the receiver:
-
-   A server that receives a ClientHello containing one or both of these
-   extensions MUST use the client's enumerated capabilities to guide its
-   selection of an appropriate cipher suite.  One of the proposed ECC
-   cipher suites must be negotiated only if the server can successfully
-   complete the handshake while using the curves and point formats
-   supported by the client (cf. Section 5.3 and Section 5.4).
-
-   NOTE: A server participating in an ECDHE-ECDSA key exchange may use
-   different curves for (i) the ECDSA key in its certificate, and (ii)
-   the ephemeral ECDH key in the ServerKeyExchange message.  The server
-   must consider the "elliptic_curves" extension in selecting both of
-   these curves.
-
-   If a server does not understand the "elliptic_curves" extension or is
-   unable to complete the ECC handshake while restricting itself to the
-   enumerated curves, it MUST NOT negotiate the use of an ECC cipher
-   suite.  Depending on what other cipher suites are proposed by the
-   client and supported by the server, this may result in a fatal
-   handshake failure alert due to the lack of common cipher suites.
-
-5.2  Server Hello Extension
-
-   This section specifies a TLS extension that can be included with the
-   ServerHello message as described in [3], the Supported Point Formats
-   Extension.
-
-   When this extension is sent:
-
-   The Supported Point Formats Extension is included in a ServerHello
-   message in response to a ClientHello message containing the Supported
-   Point Formats Extension when negotiating an ECC cipher suite.
-
-   Meaning of this extensions:
-
-   This extension allows a server to enumerate the point formats it can
-   parse (for the curve that will appear in its ServerKeyExchange
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 15]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
-   exchange algorithm, or for the curve that is used in the server's
-   public key that will appear in its Certificate message when using the
-   ECDH_ECDSA or ECDH_RSA key exchange algorithm).
-
-   Structure of this extension:
-
-   The server's Supported Point Formats Extension has the same structure
-   as the client's Supported Point Formats Extension.  Items in
-   elliptic_curve_list here are ordered according to the server's
-   preference (favorite choice first).  Note that the server may include
-   items that were not found in the client's list (e.g., the server may
-   prefer to receive points in compressed format even when a client
-   cannot parse this format: the same client may nevertheless be capable
-   to output points in compressed format).
-
-   Actions of the sender:
-
-   A server that selects an ECC cipher suite in response to a
-   ClientHello message including a Supported Point Formats Extension
-   appends this extension (along with others) to its ServerHello
-   message, enumerating the point formats it can parse.  The Supported
-   Point Formats Extension, when used, MUST contain the value 0
-   (uncompressed) as one of the items in the list of point formats.
-
-   Actions of the receiver:
-
-   A client that receives a ServerHello message containing a Supported
-   Point Formats Extension MUST respect the server's choice of point
-   formats during the handshake (cf. Section 5.6 and Section 5.7).  If
-   no Supported Point Formats Extension is received with the
-   ServerHello, this is equivalent to an extension allowing only the
-   uncompressed point format.
-
-5.3  Server Certificate
-
-   When this message is sent:
-
-   This message is sent in all non-anonymous ECC-based key exchange
-   algorithms.
-
-   Meaning of this message:
-
-   This message is used to authentically convey the server's static
-   public key to the client.  The following table shows the server
-   certificate type appropriate for each key exchange algorithm.  ECC
-   public keys must be encoded in certificates as described in
-   Section 5.9.
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 16]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   NOTE: The server's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 3 apply only to
-   the server's certificate (first in the chain).
-
-
-          Key Exchange Algorithm  Server Certificate Type
-          ----------------------  -----------------------
-
-          ECDH_ECDSA              Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDHE_ECDSA             Certificate must contain an
-                                  ECDSA-capable public key. It
-                                  must be signed with ECDSA.
-
-          ECDH_RSA                Certificate must contain an
-                                  ECDH-capable public key. It
-                                  must be signed with RSA.
-
-          ECDHE_RSA               Certificate must contain an
-                                  RSA public key authorized for
-                                  use in digital signatures. It
-                                  must be signed with RSA.
-
-                    Table 3: Server certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS Certificate format.
-
-   Actions of the sender:
-
-   The server constructs an appropriate certificate chain and conveys it
-   to the client in the Certificate message.  If the client has used a
-   Supported Elliptic Curves Extension, the public key in the server's
-   certificate MUST respect the client's choice of elliptic curves; in
-   particular, the public key MUST employ a named curve (not the same
-   curve as an explicit curve) unless the client has indicated support
-   for explicit curves of the appropriate type.  If the client has used
-   a Supported Point Formats Extension, both the server's public key
-   point and (in the case of an explicit curve) the curve's base point
-   MUST respect the client's choice of point formats.  (A server that
-   cannot satisfy these requirements must not choose an ECC cipher suite
-   in its ServerHello message.)
-
-   Actions of the receiver:
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 17]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   The client validates the certificate chain, extracts the server's
-   public key, and checks that the key type is appropriate for the
-   negotiated key exchange algorithm.
-
-5.4  Server Key Exchange
-
-   When this message is sent:
-
-   This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
-   ECDH_anon key exchange algorithms.
-
-   Meaning of this message:
-
-   This message is used to convey the server's ephemeral ECDH public key
-   (and the corresponding elliptic curve domain parameters) to the
-   client.
-
-   Structure of this message:
-
-        enum { explicit_prime (1), explicit_char2 (2),
-               named_curve (3), reserved(248..255) } ECCurveType;
-
-   explicit_prime:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a prime
-      field.
-
-   explicit_char2:  Indicates the elliptic curve domain parameters are
-      conveyed verbosely, and the underlying finite field is a
-      characteristic-2 field.
-
-   named_curve:  Indicates that a named curve is used.  This option
-      SHOULD be used when applicable.
-
-   Values 248 through 255 are reserved for private use.
-
-   The ECCurveType name space is maintained by IANA.  See Section 8 for
-   information on how new value assignments are added.
-
-        struct {
-            opaque a <1..2^8-1>;
-            opaque b <1..2^8-1>;
-        } ECCurve;
-
-   a, b:  These parameters specify the coefficients of the elliptic
-      curve.  Each value contains the byte string representation of a
-      field element following the conversion routine in Section 4.3.3 of
-      ANSI X9.62 [6].
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 18]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-        struct {
-            opaque point <1..2^8-1>;
-        } ECPoint;
-
-   point:  This is the byte string representation of an elliptic curve
-      point following the conversion routine in Section 4.3.6 of ANSI
-      X9.62 [6].  This byte string may represent an elliptic curve point
-      in uncompressed, or compressed format; it MUST conform to what the
-      client has requested through a Supported Point Formats Extension
-      if this extension was used.
-
-
-        enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
-
-   ec_basis_trinomial:  Indicates representation of a characteristic-2
-      field using a trinomial basis.
-
-   ec_basis_pentanomial:  Indicates representation of a characteristic-2
-      field using a pentanomial basis.
-
-
-        struct {
-            ECCurveType    curve_type;
-            select (curve_type) {
-                case explicit_prime:
-                    opaque      prime_p <1..2^8-1>;
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case explicit_char2:
-                    uint16      m;
-                    ECBasisType basis;
-                    select (basis) {
-                        case ec_trinomial:
-                            opaque  k <1..2^8-1>;
-                        case ec_pentanomial:
-                            opaque  k1 <1..2^8-1>;
-                            opaque  k2 <1..2^8-1>;
-                            opaque  k3 <1..2^8-1>;
-                    };
-                    ECCurve     curve;
-                    ECPoint     base;
-                    opaque      order <1..2^8-1>;
-                    opaque      cofactor <1..2^8-1>;
-                case named_curve:
-                    NamedCurve namedcurve;
-            };
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 19]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-        } ECParameters;
-
-   curve_type:  This identifies the type of the elliptic curve domain
-      parameters.
-
-   prime_p:  This is the odd prime defining the field Fp.
-
-   curve:  Specifies the coefficients a and b of the elliptic curve E.
-
-   base:  Specifies the base point G on the elliptic curve.
-
-   order:  Specifies the order n of the base point.
-
-   cofactor:  Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
-      represents the number of points on the elliptic curve E defined
-      over the field Fq (either Fp or F2^m).
-
-   m:  This is the degree of the characteristic-2 field F2^m.
-
-   k:  The exponent k for the trinomial basis representation x^m + x^k
-      +1.
-
-   k1, k2, k3:  The exponents for the pentanomial representation x^m +
-      x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
-
-   namedcurve:  Specifies a recommended set of elliptic curve domain
-      parameters.  All those values of NamedCurve are allowed that refer
-      to a specific curve.  Values of NamedCurve that indicate support
-      for a class of explicitly defined curves are not allowed here
-      (they are only permissible in the ClientHello extension); this
-      applies to arbitrary_explicit_prime_curves(0xFF01) and
-      arbitrary_explicit_char2_curves(0xFF02).
-
-
-        struct {
-            ECParameters    curve_params;
-            ECPoint         public;
-        } ServerECDHParams;
-
-   curve_params:  Specifies the elliptic curve domain parameters
-      associated with the ECDH public key.
-
-   public:  The ephemeral ECDH public key.
-
-   The ServerKeyExchange message is extended as follows.
-
-        enum { ec_diffie_hellman } KeyExchangeAlgorithm;
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 20]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   ec_diffie_hellman:  Indicates the ServerKeyExchange message contains
-      an ECDH public key.
-
-
-        select (KeyExchangeAlgorithm) {
-            case ec_diffie_hellman:
-                ServerECDHParams    params;
-                Signature           signed_params;
-        } ServerKeyExchange;
-
-   params:  Specifies the ECDH public key and associated domain
-      parameters.
-
-   signed_params:  A hash of the params, with the signature appropriate
-      to that hash applied.  The private key corresponding to the
-      certified public key in the server's Certificate message is used
-      for signing.
-
-
-          enum { ecdsa } SignatureAlgorithm;
-
-
-          select (SignatureAlgorithm) {
-              case ecdsa:
-                  digitally-signed struct {
-                      opaque sha_hash[sha_size];
-                  };
-          } Signature;
-
-   NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
-   algorithm and "anonymous" for ECDH_anon.  These cases are defined in
-   TLS [2].  SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA.  ECDSA
-   signatures are generated and verified as described in Section 5.10.
-   As per ANSI X9.62, an ECDSA signature consists of a pair of integers
-   r and s.  These integers are both converted into byte strings of the
-   same length as the curve order n using the conversion routine
-   specified in Section 4.3.1 of [6].  The two byte strings are
-   concatenated, and the result is placed in the signature field.
-
-   Actions of the sender:
-
-   The server selects elliptic curve domain parameters and an ephemeral
-   ECDH public key corresponding to these parameters according to the
-   ECKAS-DH1 scheme from IEEE 1363 [5].  It conveys this information to
-   the client in the ServerKeyExchange message using the format defined
-   above.
-
-   Actions of the recipient:
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 21]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   The client verifies the signature (when present) and retrieves the
-   server's elliptic curve domain parameters and ephemeral ECDH public
-   key from the ServerKeyExchange message.
-
-5.5  Certificate Request
-
-   When this message is sent:
-
-   This message is sent when requesting client authentication.
-
-   Meaning of this message:
-
-   The server uses this message to suggest acceptable client
-   authentication methods.
-
-   Structure of this message:
-
-   The TLS CertificateRequest message is extended as follows.
-
-        enum {
-            ecdsa_sign(??), rsa_fixed_ecdh(??),
-            ecdsa_fixed_ecdh(??), (255)
-        } ClientCertificateType;
-
-   ecdsa_sign, etc Indicates that the server would like to use the
-      corresponding client authentication method specified in Section 3.
-
-      [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
-      ecdsa_fixed_ecdh have been left as ??.  These values will be
-      assigned when this draft progresses to RFC.  Earlier versions of
-      this draft used the values 5, 6, and 7 - however these values have
-      been removed since they are used differently by SSL 3.0 [15] and
-      their use by TLS is being deprecated. ]]
-
-   Actions of the sender:
-
-   The server decides which client authentication methods it would like
-   to use, and conveys this information to the client using the format
-   defined above.
-
-   Actions of the receiver:
-
-   The client determines whether it has a suitable certificate for use
-   with any of the requested methods, and decides whether or not to
-   proceed with client authentication.
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 22]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-5.6  Client Certificate
-
-   When this message is sent:
-
-   This message is sent in response to a CertificateRequest when a
-   client has a suitable certificate and has decided to proceed with
-   client authentication.  (Note that if the server has used a Supported
-   Point Formats Extension, a certificate can only be considered
-   suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and
-   ECDSA_fixed_ECDH authentication methods if the public key point
-   specified in it respects the server's choice of point formats.  If no
-   Supported Point Formats Extension has been used, a certificate can
-   only be considered suitable for use with these authentication methods
-   if the point is represented in uncompressed point format.)
-
-   Meaning of this message:
-
-   This message is used to authentically convey the client's static
-   public key to the server.  The following table summarizes what client
-   certificate types are appropriate for the ECC-based client
-   authentication mechanisms described in Section 3.  ECC public keys
-   must be encoded in certificates as described in Section 5.9.
-
-   NOTE: The client's Certificate message is capable of carrying a chain
-   of certificates.  The restrictions mentioned in Table 4 apply only to
-   the client's certificate (first in the chain).
-
-
-          Client
-          Authentication Method   Client Certificate Type
-          ---------------------   -----------------------
-
-          ECDSA_sign              Certificate MUST contain an
-                                  ECDSA-capable public key and
-                                  be signed with ECDSA.
-
-          ECDSA_fixed_ECDH        Certificate MUST contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  MUST be signed with ECDSA.
-
-          RSA_fixed_ECDH          Certificate MUST contain an
-                                  ECDH-capable public key on the
-                                  same elliptic curve as the server's
-                                  long-term ECDH key. This certificate
-                                  MUST be signed with RSA.
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 23]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-                     Table 4: Client certificate types
-
-
-   Structure of this message:
-
-   Identical to the TLS client Certificate format.
-
-   Actions of the sender:
-
-   The client constructs an appropriate certificate chain, and conveys
-   it to the server in the Certificate message.
-
-   Actions of the receiver:
-
-   The TLS server validates the certificate chain, extracts the client's
-   public key, and checks that the key type is appropriate for the
-   client authentication method.
-
-5.7  Client Key Exchange
-
-   When this message is sent:
-
-   This message is sent in all key exchange algorithms.  If client
-   authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this
-   message is empty.  Otherwise, it contains the client's ephemeral ECDH
-   public key.
-
-   Meaning of the message:
-
-   This message is used to convey ephemeral data relating to the key
-   exchange belonging to the client (such as its ephemeral ECDH public
-   key).
-
-   Structure of this message:
-
-   The TLS ClientKeyExchange message is extended as follows.
-
-        enum { implicit, explicit } PublicValueEncoding;
-
-   implicit, explicit:  For ECC cipher suites, this indicates whether
-      the client's ECDH public key is in the client's certificate
-      ("implicit") or is provided, as an ephemeral ECDH public key, in
-      the ClientKeyExchange message ("explicit").  (This is "explicit"
-      in ECC cipher suites except when the client uses the
-      ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication
-      mechanism.)
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 24]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-        struct {
-            select (PublicValueEncoding) {
-                case implicit: struct { };
-                case explicit: ECPoint ecdh_Yc;
-            } ecdh_public;
-        } ClientECDiffieHellmanPublic;
-
-   ecdh_Yc:  Contains the client's ephemeral ECDH public key as a byte
-      string ECPoint.point, which may represent an elliptic curve point
-      in uncompressed or compressed format.  Here the format MUST
-      conform to what the server has requested through a Supported Point
-      Formats Extension if this extension was used, and MUST be
-      uncompressed if this extension was not used.
-
-
-        struct {
-            select (KeyExchangeAlgorithm) {
-                case ec_diffie_hellman: ClientECDiffieHellmanPublic;
-            } exchange_keys;
-        } ClientKeyExchange;
-
-   Actions of the sender:
-
-   The client selects an ephemeral ECDH public key corresponding to the
-   parameters it received from the server according to the ECKAS-DH1
-   scheme from IEEE 1363 [5].  It conveys this information to the client
-   in the ClientKeyExchange message using the format defined above.
-
-   Actions of the recipient:
-
-   The server retrieves the client's ephemeral ECDH public key from the
-   ClientKeyExchange message and checks that it is on the same elliptic
-   curve as the server's ECDH key.
-
-5.8  Certificate Verify
-
-   When this message is sent:
-
-   This message is sent when the client sends a client certificate
-   containing a public key usable for digital signatures, e.g. when the
-   client is authenticated using the ECDSA_sign mechanism.
-
-   Meaning of the message:
-
-   This message contains a signature that proves possession of the
-   private key corresponding to the public key in the client's
-   Certificate message.
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 25]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   Structure of this message:
-
-   The TLS CertificateVerify message is extended as follows.
-
-        enum { ecdsa } SignatureAlgorithm;
-
-        select (SignatureAlgorithm) {
-            case ecdsa:
-                digitally-signed struct {
-                    opaque sha_hash[sha_size];
-                };
-        } Signature;
-
-   For the ecdsa case, the signature field in the CertificateVerify
-   message contains an ECDSA signature computed over handshake messages
-   exchanged so far.  ECDSA signatures are computed as described in
-   Section 5.10.  As per ANSI X9.62, an ECDSA signature consists of a
-   pair of integers r and s.  These integers are both converted into
-   byte strings of the same length as the curve order n using the
-   conversion routine specified in Section 4.3.1 of [6].  The two byte
-   strings are concatenated, and the result is placed in the signature
-   field.
-
-   Actions of the sender:
-
-   The client computes its signature over all handshake messages sent or
-   received starting at client hello up to but not including this
-   message.  It uses the private key corresponding to its certified
-   public key to compute the signature which is conveyed in the format
-   defined above.
-
-   Actions of the receiver:
-
-   The server extracts the client's signature from the CertificateVerify
-   message, and verifies the signature using the public key it received
-   in the client's Certificate message.
-
-5.9  Elliptic Curve Certificates
-
-   X509 certificates containing ECC public keys or signed using ECDSA
-   MUST comply with [11] or another RFC that replaces or extends it.
-   Clients SHOULD use the elliptic curve domain parameters recommended
-   in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10].
-
-5.10  ECDH, ECDSA and RSA Computations
-
-   All ECDH calculations (including parameter and key generation as well
-   as the shared secret calculation) are performed according to [5]
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 26]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   using the ECKAS-DH1 scheme with the identity map as key derivation
-   function, so that the premaster secret is the x-coordinate of the
-   ECDH shared secret elliptic curve point represented as an octet
-   string.  Note that this octet string (Z in IEEE 1363 terminology) as
-   output by FE2OSP, the Field Element to Octet String Conversion
-   Primitive, has constant length for any given field; leading zeros
-   found in this octet string MUST NOT be truncated.
-
-   Note that a new extension may be introduced in the future to allow
-   the use of a different KDF during computation of the premaster
-   secret.  In this event, the new KDF would be used in place of the
-   process detailed above.  This may be desirable, for example, to
-   support compatibility with the planned NIST key agreement standard.
-
-   All ECDSA computations MUST be performed according to ANSI X9.62 [6]
-   or its successors.  Data to be signed/verified is hashed and the
-   result run directly through the ECDSA algorithm with no additional
-   hashing.  The default hash function is SHA-1 [7] and sha_size (see
-   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
-   function, such as one of the new SHA hash functions specified in FIPS
-   180-2 [7], may be used instead if the certificate containing the EC
-   public key explicitly requires use of another hash function.  (The
-   mechanism for specifying the required hash function has not been
-   standardized but this provision anticipates such standardization and
-   obviates the need to update this document in response.  Future PKIX
-   RFCs may choose, for example, to specify the hash function to be used
-   with a public key in the parameters field of subjectPublicKeyInfo.)
-
-   All RSA signatures must be generated and verified according to PKCS#1
-   [9] block type 1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 27]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-6.  Cipher Suites
-
-   The table below defines new ECC cipher suites that use the key
-   exchange algorithms specified in Section 2.
-
-     CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA           = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA        = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA    = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA       = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA  = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA             = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA          = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-     CipherSuite TLS_ECDH_anon_NULL_WITH_SHA            = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA         = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA    = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA     = { 0x00, 0x?? }
-     CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA     = { 0x00, 0x?? }
-
-                        Table 5: TLS ECC cipher suites
-
-
-   [[ EDITOR: The actual cipher suite numbers will be assigned when this
-   draft progresses to RFC. ]]
-
-   The key exchange method, cipher, and hash algorithm for each of these
-   cipher suites are easily determined by examining the name.  Ciphers
-   other than AES ciphers, and hash algorithms are defined in [2].  AES
-   ciphers are defined in [16].
-
-   Server implementations SHOULD support all of the following cipher
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 28]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   suites, and client implementations SHOULD support at least one of
-   them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
-   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 29]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-7.  Security Considerations
-
-   This document is based on [2], [5], [6] and [16].  The appropriate
-   security considerations of those documents apply.
-
-   One important issue that implementors and users must consider is
-   elliptic curve selection.  Guidance on selecting an appropriate
-   elliptic curve size is given in Table 1.
-
-   Beyond elliptic curve size, the main issue is elliptic curve
-   structure.  As a general principle, it is more conservative to use
-   elliptic curves with as little algebraic structure as possible - thus
-   random curves are more conservative than special curves such as
-   Koblitz curves, and curves over F_p with p random are more
-   conservative than curves over F_p with p of a special form (and
-   curves over F_p with p random might be considered more conservative
-   than curves over F_2^m as there is no choice between multiple fields
-   of similar size for characteristic 2).  Note, however, that algebraic
-   structure can also lead to implementation efficiencies and
-   implementors and users may, therefore, need to balance conservatism
-   against a need for efficiency.  Concrete attacks are known against
-   only very few special classes of curves, such as supersingular
-   curves, and these classes are excluded from the ECC standards that
-   this document references [5], [6].
-
-   Another issue is the potential for catastrophic failures when a
-   single elliptic curve is widely used.  In this case, an attack on the
-   elliptic curve might result in the compromise of a large number of
-   keys.  Again, this concern may need to be balanced against efficiency
-   and interoperability improvements associated with widely-used curves.
-   Substantial additional information on elliptic curve choice can be
-   found in [4], [5], [6], [8].
-
-   Implementors and users must also consider whether they need forward
-   secrecy.  Forward secrecy refers to the property that session keys
-   are not compromised if the static, certified keys belonging to the
-   server and client are compromised.  The ECDHE_ECDSA and ECDHE_RSA key
-   exchange algorithms provide forward secrecy protection in the event
-   of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
-   Similarly if the client is providing a static, certified key,
-   ECDSA_sign client authentication provides forward secrecy protection
-   in the event of client key compromise, while ECDSA_fixed_ECDH and
-   RSA_fixed_ECDH do not.  Thus to obtain complete forward secrecy
-   protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
-   with ECDSA_sign used for client authentication if necessary.  Here
-   again the security benefits of forward secrecy may need to be
-   balanced against the improved efficiency offered by other options.
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 30]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-8.  IANA Considerations
-
-   This document describes three new name spaces for use with the TLS
-   protocol:
-
-   o  NamedCurve (Section 5.1)
-
-   o  ECPointFormat (Section 5.1)
-
-   o  ECCurveType (Section 5.4)
-
-   For each name space, this document defines the initial value
-   assignments and defines a range of 256 values (NamedCurve) or eight
-   values (ECPointFormat and ECCurveType) reserved for Private Use. Any
-   additional assignments require IETF Consensus action [12].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 31]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-9.  Acknowledgments
-
-   The authors wish to thank Bill Anderson and Tim Dierks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 32]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-10.  References
-
-10.1  Normative References
-
-   [1]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [3]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-         T. Wright, "Transport Layer Security (TLS) Extensions",
-         draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005.
-
-   [4]   SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
-         <http://www.secg.org/>.
-
-   [5]   IEEE, "Standard Specifications for Public Key Cryptography",
-         IEEE 1363, 2000.
-
-   [6]   ANSI, "Public Key Cryptography For The Financial Services
-         Industry: The Elliptic Curve Digital Signature Algorithm
-         (ECDSA)", ANSI X9.62, 1998.
-
-   [7]   NIST, "Secure Hash Standard", FIPS 180-2, 2002.
-
-   [8]   NIST, "Digital Signature Standard", FIPS 186-2, 2000.
-
-   [9]   RSA Laboratories, "PKCS#1: RSA Encryption Standard version
-         1.5", PKCS 1, November 1993.
-
-   [10]  SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
-         2000, <http://www.secg.org/>.
-
-   [11]  Polk, T., Housley, R., and L. Bassham, "Algorithms and
-         Identifiers for the Internet X.509 Public Key Infrastructure
-         Certificate and Certificate Revocation List (CRL) Profile",
-         RFC 3279, April 2002.
-
-   [12]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", RFC 2434, October 1998.
-
-10.2  Informative References
-
-   [13]  Harper, G., Menezes, A., and S. Vanstone, "Public-Key
-         Cryptosystems with Very Small Key Lengths", Advances in
-         Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 33]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   [14]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", Journal of Cryptology 14 (2001) 255-293,
-         <http://www.cryptosavvy.com/>.
-
-   [15]  Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
-         Version 3.0", November 1996,
-         <http://wp.netscape.com/eng/ssl3/draft302.txt>.
-
-   [16]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-         Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-
-Authors' Addresses
-
-   Vipul Gupta
-   Sun Microsystems Laboratories
-   16 Network Circle
-   MS UMPK16-160
-   Menlo Park, CA  94025
-   US
-
-   Phone: +1 650 786 7551
-   Email: vipul.gupta@sun.com
-
-
-   Simon Blake-Wilson
-   Basic Commerce & Industries, Inc.
-   96 Spandia Ave
-   Unit 606
-   Toronto, ON  M6G 2T6
-   CA
-
-   Phone: +1 416 214 5961
-   Email: sblakewilson@bcisse.com
-
-
-   Bodo Moeller
-   University of Calgary
-   Dept of Math & Stats
-   2500 University Dr NW
-   Calgary, AB  T2N 1N4
-   CA
-
-   Phone: +1 403 220 5735
-   Email: bodo@openssl.org
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 34]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-   Chris Hawk
-   Corriente Networks
-
-   Email: chris@corriente.net
-
-
-   Nelson Bolyard
-
-   Email: nelson@bolyard.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 35]
-
-Internet-Draft          ECC Cipher Suites for TLS         September 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Gupta, et al.            Expires March 20, 2006                [Page 36]
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-00.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-00.txt
deleted file mode 100644
index c9d534177a..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-00.txt
+++ /dev/null
@@ -1,449 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Intended status:  Informational                           April 23, 2007
-Expires:  October 25, 2007
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 25, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes eight new CipherSuites for
-   TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
-   with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
-   (GCM).
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 1]
-
-Internet-Draft               TLS ECC New MAC                  April 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-     2.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 4
-     2.4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . 5
-     2.5.  Security Considerations . . . . . . . . . . . . . . . . . . 5
-       2.5.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . 5
-       2.5.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . 5
-       2.5.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . 5
-     2.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 5
-   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     3.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     3.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 2]
-
-Internet-Draft               TLS ECC New MAC                  April 2007
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
-   rather than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes
-   [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
-   cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
-   Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
-   GCM with other key establishment methods.
-
-1.1.  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 [RFC2119].
-
-
-2.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-2.1.  HMAC-based Cipher Suites
-
-   The first four cipher suites use AES [AES] in CBC mode with an HMAC-
-   based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-
-   These four cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
-   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
-
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 3]
-
-Internet-Draft               TLS ECC New MAC                  April 2007
-
-
-      Cipher Suite                                MAC          PRF
-      ------------                                ---          ---
-      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
-      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
-      TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
-      TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
-
-2.2.  Galois Counter Mode-based Cipher Suites
-
-   The second four cipher suites use the new authenticated encryption
-   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-
-   These cipher suites use the authenticated encryption with additional
-   data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
-   be 12 bytes long, and constructed as follows:
-
-             struct {
-                opaque salt[4];
-                uint64 seq_num;
-             } GCMNonce.
-
-   The salt value is either the client_write_IV if the client is sending
-   or the server_write_IV if the server is sending.  These IVs SHALL be
-   4 bytes long.
-
-   In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
-   48-bit seq_num.
-
-   The PRF algorithms SHALL be as follows:
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-384.
-
-2.3.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 4]
-
-Internet-Draft               TLS ECC New MAC                  April 2007
-
-
-2.4.  TLS Versions
-
-   Because these cipher suites depend on features available only in TLS
-   1.2 (PRF flexibility and combined authenticated encryption cipher
-   modes), they MUST NOT be negotiated in older versions of TLS.
-   Clients MUST NOT offer these cipher suites if they do not offer TLS
-   1.2 or later.  Servers which select an earlier version of TLS MUST
-   NOT select one of these cipher suites.  Because TLS has no way for
-   the client to indicate that it supports TLS 1.2 but not earlier, a
-   non-compliant server might potentially negotiate TLS 1.1 or earlier
-   and select one of the cipher suites in this document.  Clients MUST
-   check the TLS version and generate a fatal "illegal_parameter" alert
-   if they detect an incorrect version.
-
-2.5.  Security Considerations
-
-   The security considerations in RFC 4346 and RFC 4492 apply to this
-   document as well.  The remainder of this section describes security
-   considerations specific to the cipher suites described in this
-   document.
-
-2.5.1.  Downgrade Attack
-
-   TLS negotiation is only as secure as the weakest cipher suite that is
-   supported.  For instance, an implementation which supports both 160-
-   bit and 256-bit elliptic curves can be subject to an active downgrade
-   attack to the 160-bit security level.  An attacker who can attack
-   that can then forge the Finished handshake check and successfully
-   mount a man-in-the-middle attack.
-
-2.5.2.  Perfect Forward Secrecy
-
-   The static ECDH cipher suites specified in this document do not
-   provide perfect forward secrecy (PFS).  Thus, compromise of a single
-   static key leads to potential decryption of all traffic protected
-   using that key.  Implementors of this specification SHOULD provide at
-   least one ECDHE mode of operation.
-
-2.5.3.  Counter Reuse with GCM
-
-   AES-GCM is only secure if the counter is never reused.  The IV
-   construction algorithm above is designed to ensure that that cannot
-   happen.
-
-2.6.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 5]
-
-Internet-Draft               TLS ECC New MAC                  April 2007
-
-
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-
-
-3.  References
-
-3.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-02 (work in progress),
-              March 2007.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
-              March 2007.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D (DRAFT), April 2006.
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 6]
-
-Internet-Draft               TLS ECC New MAC                  April 2007
-
-
-3.2.  Informative References
-
-   [I-D.salowey-tls-rsa-aes-gcm]
-              Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
-              draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
-              February 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 7]
-
-Internet-Draft               TLS ECC New MAC                  April 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                Expires October 25, 2007                [Page 8]
-
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-01.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-01.txt
deleted file mode 100644
index 4f5c96e18e..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-01.txt
+++ /dev/null
@@ -1,449 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Intended status:  Informational                             June 2, 2007
-Expires:  December 4, 2007
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 4, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes eight new CipherSuites for
-   TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
-   with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
-   (GCM).
-
-
-
-
-Rescorla                Expires December 4, 2007                [Page 1]
-
-Internet-Draft               TLS ECC New MAC                   June 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-     2.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 5
-     2.4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . 5
-     2.5.  Security Considerations . . . . . . . . . . . . . . . . . . 5
-       2.5.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . 5
-       2.5.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . 6
-       2.5.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . 6
-     2.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
-   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     3.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     3.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires December 4, 2007                [Page 2]
-
-Internet-Draft               TLS ECC New MAC                   June 2007
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
-   rather than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes
-   [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
-   cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
-   Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
-   GCM with other key establishment methods.
-
-1.1.  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 [RFC2119].
-
-
-2.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-2.1.  HMAC-based Cipher Suites
-
-   The first four cipher suites use AES [AES] in CBC [CBC] mode with an
-   HMAC-based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-
-   These four cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
-   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
-
-
-
-
-
-Rescorla                Expires December 4, 2007                [Page 3]
-
-Internet-Draft               TLS ECC New MAC                   June 2007
-
-
-      Cipher Suite                                MAC          PRF
-      ------------                                ---          ---
-      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
-      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
-      TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
-      TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
-
-2.2.  Galois Counter Mode-based Cipher Suites
-
-   The second four cipher suites use the new authenticated encryption
-   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-
-   These cipher suites use authenticated encryption with additional data
-   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
-   be 12 bytes long, and is "partially implicit" (see Section 3.2.1 of
-   [I-D.mcgrew-auth-enc]) part of the nonce is generated as part of the
-   handshake process and is static for the entire session and part is
-   carried in each packet.
-
-             struct {
-                opaque salt[4];
-                opaque explicit_nonce_part[8];
-             } GCMNonce.
-
-   The salt value is either the client_write_IV if the client is sending
-   or the server_write_IV if the server is sending.  These IVs SHALL be
-   4 bytes long.
-
-   The explicit_nonce_part is chosen by the sender and included in the
-   packet.  Each value of the explicit_nonce_part MUST be distinct from
-   all other values, for any fixed key.  Failure to meet this uniqueness
-   requirement can significantly degrade security.  The
-   explicit_nonce_part is carried in the IV field of the
-   GenericAEADCipher structure.  Therefore, for all the algorithms
-   defined in this section, SecurityParameters.iv_length=8.
-
-   In the case of TLS the counter MAY be the 64-bit sequence number.  In
-   the case of Datagram TLS [RFC4347] [NOTE:  there needs to be a new
-   DTLS draft for AEAD, this is a placeholder] the counter MAY be formed
-   from the concatenation of the 16-bit epoch with the 48-bit sequence
-   number.
-
-
-
-
-Rescorla                Expires December 4, 2007                [Page 4]
-
-Internet-Draft               TLS ECC New MAC                   June 2007
-
-
-   The PRF algorithms SHALL be as follows:
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-384.
-
-2.3.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-   David McGrew contributed substantual sections of the GCM nonce text
-   as well as providing a review of this document.
-
-2.4.  TLS Versions
-
-   Because these cipher suites depend on features available only in TLS
-   1.2 (PRF flexibility and combined authenticated encryption cipher
-   modes), they MUST NOT be negotiated by older versions of TLS.
-   Clients MUST NOT offer these cipher suites if they do not offer TLS
-   1.2 or later.  Servers which select an earlier version of TLS MUST
-   NOT select one of these cipher suites.  Because TLS has no way for
-   the client to indicate that it supports TLS 1.2 but not earlier, a
-   non-compliant server might potentially negotiate TLS 1.1 or earlier
-   and select one of the cipher suites in this document.  Clients MUST
-   check the TLS version and generate a fatal "illegal_parameter" alert
-   if they detect an incorrect version.
-
-2.5.  Security Considerations
-
-   The security considerations in RFC 4346 and RFC 4492 apply to this
-   document as well.  The remainder of this section describes security
-   considerations specific to the cipher suites described in this
-   document.
-
-2.5.1.  Downgrade Attack
-
-   TLS negotiation is only as secure as the weakest cipher suite that is
-   supported.  For instance, an implementation which supports both 160-
-   bit and 256-bit elliptic curves can be subject to an active downgrade
-   attack to the 160-bit security level.  An attacker who can attack
-   that can then forge the Finished handshake check and successfully
-   mount a man-in-the-middle attack.
-
-
-
-
-
-
-
-Rescorla                Expires December 4, 2007                [Page 5]
-
-Internet-Draft               TLS ECC New MAC                   June 2007
-
-
-2.5.2.  Perfect Forward Secrecy
-
-   The static ECDH cipher suites specified in this document do not
-   provide perfect forward secrecy (PFS).  Thus, compromise of a single
-   static key leads to potential decryption of all traffic protected
-   using that key.  Implementors of this specification SHOULD provide at
-   least one ECDHE mode of operation.
-
-2.5.3.  Counter Reuse with GCM
-
-   AES-GCM is only secure if the counter is never reused.  The IV
-   construction algorithm above is designed to ensure that this cannot
-   happen.
-
-2.6.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-
-
-3.  References
-
-3.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-02 (work in progress),
-              March 2007.
-
-   [I-D.ietf-tls-rfc4346-bis]
-
-
-
-Rescorla                Expires December 4, 2007                [Page 6]
-
-Internet-Draft               TLS ECC New MAC                   June 2007
-
-
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
-              March 2007.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", SP 800-38A, December 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D (DRAFT), April 2006.
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-3.2.  Informative References
-
-   [I-D.salowey-tls-rsa-aes-gcm]
-              Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
-              draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
-              February 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires December 4, 2007                [Page 7]
-
-Internet-Draft               TLS ECC New MAC                   June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                Expires December 4, 2007                [Page 8]
-
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-02.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-02.txt
deleted file mode 100644
index b6c9433712..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-02.txt
+++ /dev/null
@@ -1,449 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Intended status:  Informational                        December 19, 2007
-Expires:  June 21, 2008
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 21, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes eight new CipherSuites for
-   TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
-   with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
-   (GCM).
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 1]
-
-Internet-Draft               TLS ECC New MAC               December 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-     2.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 5
-     2.4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . 5
-     2.5.  Security Considerations . . . . . . . . . . . . . . . . . . 5
-       2.5.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . 5
-       2.5.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . 6
-       2.5.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . 6
-     2.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
-   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     3.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     3.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 2]
-
-Internet-Draft               TLS ECC New MAC               December 2007
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
-   rather than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes
-   [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
-   cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
-   Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
-   GCM with other key establishment methods.
-
-1.1.  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 [RFC2119].
-
-
-2.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-2.1.  HMAC-based Cipher Suites
-
-   The first four cipher suites use AES [AES] in CBC [CBC] mode with an
-   HMAC-based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-
-   These four cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
-   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 3]
-
-Internet-Draft               TLS ECC New MAC               December 2007
-
-
-      Cipher Suite                                MAC          PRF
-      ------------                                ---          ---
-      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
-      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
-      TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
-      TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
-
-2.2.  Galois Counter Mode-based Cipher Suites
-
-   The second four cipher suites use the new authenticated encryption
-   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-
-   These cipher suites use authenticated encryption with additional data
-   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
-   be 12 bytes long, and is "partially implicit" (see Section 3.2.1 of
-   [I-D.mcgrew-auth-enc]).  Part of the nonce is generated as part of
-   the handshake process and is static for the entire session and part
-   is carried in each packet.
-
-             struct {
-                opaque salt[4];
-                opaque explicit_nonce_part[8];
-             } GCMNonce.
-
-   The salt value is either the client_write_IV if the client is sending
-   or the server_write_IV if the server is sending.  These IVs SHALL be
-   4 bytes long.
-
-   The explicit_nonce_part is chosen by the sender and included in the
-   packet.  Each value of the explicit_nonce_part MUST be distinct from
-   all other values, for any fixed key.  Failure to meet this uniqueness
-   requirement can significantly degrade security.  The
-   explicit_nonce_part is carried in the IV field of the
-   GenericAEADCipher structure.  Therefore, for all the algorithms
-   defined in this section, SecurityParameters.iv_length=8.
-
-   In the case of TLS the counter MAY be the 64-bit sequence number.  In
-   the case of Datagram TLS [RFC4347] [NOTE:  there needs to be a new
-   DTLS draft for AEAD, this is a placeholder] the counter MAY be formed
-   from the concatenation of the 16-bit epoch with the 48-bit sequence
-   number.
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 4]
-
-Internet-Draft               TLS ECC New MAC               December 2007
-
-
-   The PRF algorithms SHALL be as follows:
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-384.
-
-2.3.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-   David McGrew contributed substantual sections of the GCM nonce text
-   as well as providing a review of this document.
-
-2.4.  TLS Versions
-
-   Because these cipher suites depend on features available only in TLS
-   1.2 (PRF flexibility and combined authenticated encryption cipher
-   modes), they MUST NOT be negotiated by older versions of TLS.
-   Clients MUST NOT offer these cipher suites if they do not offer TLS
-   1.2 or later.  Servers which select an earlier version of TLS MUST
-   NOT select one of these cipher suites.  Because TLS has no way for
-   the client to indicate that it supports TLS 1.2 but not earlier, a
-   non-compliant server might potentially negotiate TLS 1.1 or earlier
-   and select one of the cipher suites in this document.  Clients MUST
-   check the TLS version and generate a fatal "illegal_parameter" alert
-   if they detect an incorrect version.
-
-2.5.  Security Considerations
-
-   The security considerations in RFC 4346 and RFC 4492 apply to this
-   document as well.  The remainder of this section describes security
-   considerations specific to the cipher suites described in this
-   document.
-
-2.5.1.  Downgrade Attack
-
-   TLS negotiation is only as secure as the weakest cipher suite that is
-   supported.  For instance, an implementation which supports both 160-
-   bit and 256-bit elliptic curves can be subject to an active downgrade
-   attack to the 160-bit security level.  An attacker who can attack
-   that can then forge the Finished handshake check and successfully
-   mount a man-in-the-middle attack.
-
-
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 5]
-
-Internet-Draft               TLS ECC New MAC               December 2007
-
-
-2.5.2.  Perfect Forward Secrecy
-
-   The static ECDH cipher suites specified in this document do not
-   provide perfect forward secrecy (PFS).  Thus, compromise of a single
-   static key leads to potential decryption of all traffic protected
-   using that key.  Implementors of this specification SHOULD provide at
-   least one ECDHE mode of operation.
-
-2.5.3.  Counter Reuse with GCM
-
-   AES-GCM is only secure if the counter is never reused.  The IV
-   construction algorithm above is designed to ensure that this cannot
-   happen.
-
-2.6.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-
-
-3.  References
-
-3.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-05 (work in progress),
-              November 2007.
-
-   [I-D.ietf-tls-rfc4346-bis]
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 6]
-
-Internet-Draft               TLS ECC New MAC               December 2007
-
-
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07
-              (work in progress), November 2007.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", SP 800-38A, December 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D (DRAFT), April 2006.
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-3.2.  Informative References
-
-   [I-D.salowey-tls-rsa-aes-gcm]
-              Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
-              draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
-              February 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 7]
-
-Internet-Draft               TLS ECC New MAC               December 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 8]
-
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-03.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-03.txt
deleted file mode 100644
index a19243fd1a..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-03.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                                RTFM, Inc.
-Intended status:  Informational                         February 9, 2008
-Expires:  August 12, 2008
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-03.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 12, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes eight new CipherSuites for
-   TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
-   with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
-   (GCM).
-
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 1]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-     2.3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 5
-     2.4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . 5
-     2.5.  Security Considerations . . . . . . . . . . . . . . . . . . 5
-       2.5.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . 5
-       2.5.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . 6
-       2.5.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . 6
-     2.6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
-   3.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     3.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     3.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 2]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
-   rather than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes
-   [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
-   cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
-   Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
-   GCM with other key establishment methods.
-
-1.1.  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 [RFC2119].
-
-
-2.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-2.1.  HMAC-based Cipher Suites
-
-   The first four cipher suites use AES [AES] in CBC [CBC] mode with an
-   HMAC-based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-
-   These four cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
-   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
-
-
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 3]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-      Cipher Suite                                MAC          PRF
-      ------------                                ---          ---
-      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
-      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
-      TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
-      TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
-
-2.2.  Galois Counter Mode-based Cipher Suites
-
-   The second four cipher suites use the new authenticated encryption
-   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-
-   These cipher suites use authenticated encryption with additional data
-   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
-   be 12 bytes long, and is "partially implicit" (see Section 3.2.1 of
-   [I-D.mcgrew-auth-enc]).  Part of the nonce is generated as part of
-   the handshake process and is static for the entire session and part
-   is carried in each packet.
-
-             struct {
-                opaque salt[4];
-                opaque explicit_nonce_part[8];
-             } GCMNonce.
-
-   The salt value is either the client_write_IV if the client is sending
-   or the server_write_IV if the server is sending.  These IVs SHALL be
-   4 bytes long.  Therefore, for all the algorithms defined in this
-   section, SecurityParameters.fixed_iv_length=4.
-
-   The explicit_nonce_part is chosen by the sender and included in the
-   packet.  Each value of the explicit_nonce_part MUST be distinct from
-   all other values, for any fixed key.  Failure to meet this uniqueness
-   requirement can significantly degrade security.  The
-   explicit_nonce_part is carried in the IV field of the
-   GenericAEADCipher structure.  Therefore, for all the algorithms
-   defined in this section, SecurityParameters.record_iv_length=8.
-
-   In the case of TLS the counter MAY be the 64-bit sequence number.  In
-   the case of Datagram TLS [RFC4347] [NOTE:  there needs to be a new
-   DTLS draft for AEAD, this is a placeholder] the counter MAY be formed
-   from the concatenation of the 16-bit epoch with the 48-bit sequence
-   number.
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 4]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-   The PRF algorithms SHALL be as follows:
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA384 it SHALL be P_SHA-384.
-
-2.3.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-   David McGrew contributed substantual sections of the GCM nonce text
-   as well as providing a review of this document.
-
-2.4.  TLS Versions
-
-   Because these cipher suites depend on features available only in TLS
-   1.2 (PRF flexibility and combined authenticated encryption cipher
-   modes), they MUST NOT be negotiated by older versions of TLS.
-   Clients MUST NOT offer these cipher suites if they do not offer TLS
-   1.2 or later.  Servers which select an earlier version of TLS MUST
-   NOT select one of these cipher suites.  Because TLS has no way for
-   the client to indicate that it supports TLS 1.2 but not earlier, a
-   non-compliant server might potentially negotiate TLS 1.1 or earlier
-   and select one of the cipher suites in this document.  Clients MUST
-   check the TLS version and generate a fatal "illegal_parameter" alert
-   if they detect an incorrect version.
-
-2.5.  Security Considerations
-
-   The security considerations in RFC 4346 and RFC 4492 apply to this
-   document as well.  The remainder of this section describes security
-   considerations specific to the cipher suites described in this
-   document.
-
-2.5.1.  Downgrade Attack
-
-   TLS negotiation is only as secure as the weakest cipher suite that is
-   supported.  For instance, an implementation which supports both 160-
-   bit and 256-bit elliptic curves can be subject to an active downgrade
-   attack to the 160-bit security level.  An attacker who can attack
-   that can then forge the Finished handshake check and successfully
-   mount a man-in-the-middle attack.
-
-
-
-
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 5]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-2.5.2.  Perfect Forward Secrecy
-
-   The static ECDH cipher suites specified in this document do not
-   provide perfect forward secrecy (PFS).  Thus, compromise of a single
-   static key leads to potential decryption of all traffic protected
-   using that key.  Implementors of this specification SHOULD provide at
-   least one ECDHE mode of operation.
-
-2.5.3.  Counter Reuse with GCM
-
-   AES-GCM is only secure if the counter is never reused.  The IV
-   construction algorithm above is designed to ensure that this cannot
-   happen.
-
-2.6.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-
-
-3.  References
-
-3.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-05 (work in progress),
-              November 2007.
-
-   [I-D.ietf-tls-rfc4346-bis]
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 6]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-09
-              (work in progress), February 2008.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", SP 800-38A, December 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, November 2007.
-
-3.2.  Informative References
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-   [I-D.salowey-tls-rsa-aes-gcm]
-              Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
-              draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
-              February 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 7]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                 Expires August 12, 2008                [Page 8]
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-04.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-04.txt
deleted file mode 100644
index ebcf7fc3e6..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-04.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                                RTFM, Inc.
-Intended status:  Informational                        February 12, 2008
-Expires:  August 15, 2008
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-04.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 15, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes eight new CipherSuites for
-   TLS/DTLS which specify stronger digest algorithms.  Four use HMAC
-   with SHA-256 or SHA-384 and four use AES in Galois Counter Mode
-   (GCM).
-
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 1]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-   3.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 5
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-     4.1.  Downgrade Attack  . . . . . . . . . . . . . . . . . . . . . 5
-     4.2.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5
-     4.3.  Counter Reuse with GCM  . . . . . . . . . . . . . . . . . . 6
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 2]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which replace SHA-256 and SHA-384
-   rather than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes
-   [I-D.mcgrew-auth-enc].  This document also specifies a set of ECC
-   cipher suites using one such mode, Galois Counter Mode (GCM) [GCM].
-   Another document [I-D.salowey-tls-rsa-aes-gcm], provides support for
-   GCM with other key establishment methods.
-
-1.1.  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 [RFC2119].
-
-
-2.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-2.1.  HMAC-based Cipher Suites
-
-   The first four cipher suites use AES [AES] in CBC [CBC] mode with an
-   HMAC-based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-
-   These four cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
-   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
-
-
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 3]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-      Cipher Suite                                MAC          PRF
-      ------------                                ---          ---
-      TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA-256
-      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA-384
-      TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA-256
-      TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA-384
-
-2.2.  Galois Counter Mode-based Cipher Suites
-
-   The second four cipher suites use the new authenticated encryption
-   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-
-   These cipher suites use authenticated encryption with additional data
-   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
-   be 12 bytes long, and is "partially implicit" (see Section 3.2.1 of
-   [I-D.mcgrew-auth-enc]).  Part of the nonce is generated as part of
-   the handshake process and is static for the entire session and part
-   is carried in each packet.
-
-             struct {
-                opaque salt[4];
-                opaque explicit_nonce_part[8];
-             } GCMNonce.
-
-   The salt value is either the client_write_IV if the client is sending
-   or the server_write_IV if the server is sending.  These IVs SHALL be
-   4 bytes long.  Therefore, for all the algorithms defined in this
-   section, SecurityParameters.fixed_iv_length=4.
-
-   The explicit_nonce_part is chosen by the sender and included in the
-   packet.  Each value of the explicit_nonce_part MUST be distinct from
-   all other values, for any fixed key.  Failure to meet this uniqueness
-   requirement can significantly degrade security.  The
-   explicit_nonce_part is carried in the IV field of the
-   GenericAEADCipher structure.  Therefore, for all the algorithms
-   defined in this section, SecurityParameters.record_iv_length=8.
-
-   In the case of TLS the counter MAY be the 64-bit sequence number.  In
-   the case of Datagram TLS [RFC4347] the counter MAY be formed from the
-   concatenation of the 16-bit epoch with the 48-bit sequence number.
-
-   The PRF algorithms SHALL be as follows:
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 4]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be P_SHA-256.
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA384 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA384 it SHALL be P_SHA-384.
-
-
-3.  TLS Versions
-
-   Because these cipher suites depend on features available only in TLS
-   1.2 (PRF flexibility and combined authenticated encryption cipher
-   modes), they MUST NOT be negotiated by older versions of TLS.
-   Clients MUST NOT offer these cipher suites if they do not offer TLS
-   1.2 or later.  Servers which select an earlier version of TLS MUST
-   NOT select one of these cipher suites.  Because TLS has no way for
-   the client to indicate that it supports TLS 1.2 but not earlier, a
-   non-compliant server might potentially negotiate TLS 1.1 or earlier
-   and select one of the cipher suites in this document.  Clients MUST
-   check the TLS version and generate a fatal "illegal_parameter" alert
-   if they detect an incorrect version.
-
-
-4.  Security Considerations
-
-   The security considerations in RFC 4346 and RFC 4492 apply to this
-   document as well.  The remainder of this section describes security
-   considerations specific to the cipher suites described in this
-   document.
-
-4.1.  Downgrade Attack
-
-   TLS negotiation is only as secure as the weakest cipher suite that is
-   supported.  For instance, an implementation which supports both 160-
-   bit and 256-bit elliptic curves can be subject to an active downgrade
-   attack to the 160-bit security level.  An attacker who can attack
-   that can then forge the Finished handshake check and successfully
-   mount a man-in-the-middle attack.
-
-4.2.  Perfect Forward Secrecy
-
-   The static ECDH cipher suites specified in this document do not
-   provide perfect forward secrecy (PFS).  Thus, compromise of a single
-   static key leads to potential decryption of all traffic protected
-   using that key.  Implementors of this specification SHOULD provide at
-   least one ECDHE mode of operation.
-
-
-
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 5]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-4.3.  Counter Reuse with GCM
-
-   AES-GCM is only secure if the counter is never reused.  The IV
-   construction algorithm above is designed to ensure that this cannot
-   happen.
-
-
-5.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-
-
-6.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-   David McGrew contributed substantual sections of the GCM nonce text
-   as well as providing a review of this document.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-05 (work in progress),
-              November 2007.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-09
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 6]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-              (work in progress), February 2008.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", SP 800-38A, December 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, November 2007.
-
-7.2.  Informative References
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-   [I-D.salowey-tls-rsa-aes-gcm]
-              Salowey, J., "RSA based AES-GCM Cipher Suites for TLS",
-              draft-salowey-tls-rsa-aes-gcm-00 (work in progress),
-              February 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 7]
-
-Internet-Draft               TLS ECC New MAC               February 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                 Expires August 15, 2008                [Page 8]
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-05.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-05.txt
deleted file mode 100644
index ec549cf758..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-05.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                                RTFM, Inc.
-Intended status:  Informational                           April 14, 2008
-Expires:  October 16, 2008
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-05.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 16, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes sixteen new CipherSuites for
-   TLS/DTLS which specify stronger digest algorithms.  Eight use HMAC
-   with SHA-256 or SHA-384 and eight use AES in Galois Counter Mode
-   (GCM).
-
-
-
-
-Rescorla                Expires October 16, 2008                [Page 1]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires October 16, 2008                [Page 2]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which use SHA-256 and SHA-384 rather
-   than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes [RFC5116].  This
-   document also specifies a set of ECC cipher suites using one such
-   mode, Galois Counter Mode (GCM) [GCM].  Another document
-   [I-D.ietf-tls-rsa-aes-gcm], provides support for GCM with other key
-   establishment methods.
-
-1.1.  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 [RFC2119].
-
-
-2.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-2.1.  HMAC-based Cipher Suites
-
-   The first eight cipher suites use AES [AES] in CBC [CBC] mode with an
-   HMAC-based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
-
-   These eight cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
-
-
-
-Rescorla                Expires October 16, 2008                [Page 3]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, and
-   TLS_ECDH_RSA_WITH_AES_256_CBC_SHA) except for the hash and PRF
-   algorithms, which are SHA-256 and SHA-384 [SHS] as follows.
-
-       Cipher Suite                                MAC          PRF
-       ------------                                ---          ---
-       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA256
-       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA384
-       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA256
-       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA384
-       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256       HMAC-SHA-256 P_SHA256
-       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384       HMAC-SHA-384 P_SHA384
-       TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256        HMAC-SHA-256 P_SHA256
-       TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384        HMAC-SHA-384 P_SHA384
-
-2.2.  Galois Counter Mode-based Cipher Suites
-
-   The second eight cipher suites use the same asymmetric algorithms as
-   those in the previous section but use the new authenticated
-   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode
-   (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
-
-   These cipher suites use authenticated encryption with additional data
-   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [RFC5116].  GCM is used as described in [I-D.ietf-tls-rsa-aes-gcm].
-
-
-        Cipher Suite                                PRF
-        ------------                                ---
-        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256     P_SHA256
-        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384     P_SHA384
-        TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256      P_SHA256
-        TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384      P_SHA384
-        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256       P_SHA256
-        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384       P_SHA384
-        TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256        P_SHA256
-
-
-
-Rescorla                Expires October 16, 2008                [Page 4]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-        TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384        P_SHA384
-
-
-3.  Security Considerations
-
-   The security considerations in RFC 4346, RFC 4492, and
-   [I-D.ietf-tls-rsa-aes-gcm] apply to this document as well.  In
-   addition, as described in [I-D.ietf-tls-rsa-aes-gcm], these cipher
-   suites may only be used with TLS 1.2 or greater.
-
-
-4.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
-
-
-5.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-   David McGrew contributed substantual sections of the GCM nonce text
-   as well as providing a review of this document.
-
-
-6.  References
-
-6.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-Rescorla                Expires October 16, 2008                [Page 5]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", RFC 5116, January 2008.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
-              (work in progress), March 2008.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", SP 800-38A, December 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, November 2007.
-
-6.2.  Informative References
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-   [I-D.ietf-tls-rsa-aes-gcm]
-              Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
-              Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02 (work in
-              progress), February 2008.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires October 16, 2008                [Page 6]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-Author's Address
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires October 16, 2008                [Page 7]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                Expires October 16, 2008                [Page 8]
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-06.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-06.txt
deleted file mode 100644
index 2ac8fcaee7..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-06.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                                RTFM, Inc.
-Intended status:  Informational                           April 29, 2008
-Expires:  October 31, 2008
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-06.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 31, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes sixteen new CipherSuites for
-   TLS/DTLS which specify stronger digest algorithms.  Eight use HMAC
-   with SHA-256 or SHA-384 and eight use AES in Galois Counter Mode
-   (GCM).
-
-
-
-
-Rescorla                Expires October 31, 2008                [Page 1]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     2.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     2.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires October 31, 2008                [Page 2]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which use SHA-256 and SHA-384 rather
-   than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes [RFC5116].  This
-   document also specifies a set of ECC cipher suites using one such
-   mode, Galois Counter Mode (GCM) [GCM].  Another document
-   [I-D.ietf-tls-rsa-aes-gcm], provides support for GCM with other key
-   establishment methods.
-
-1.1.  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 [RFC2119].
-
-
-2.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-2.1.  HMAC-based Cipher Suites
-
-   The first eight cipher suites use AES [AES] in CBC [CBC] mode with an
-   HMAC-based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
-
-   These eight cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (with names ending in "_SHA" in place of "_SHA256"
-   or "_SHA384"), except for the hash and PRF algorithms, which use SHA-
-   256 and SHA-384 [SHS] as follows.
-
-
-
-Rescorla                Expires October 31, 2008                [Page 3]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-       Cipher Suite                                MAC          PRF
-       ------------                                ---          ---
-       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256     HMAC-SHA-256 P_SHA256
-       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384     HMAC-SHA-384 P_SHA384
-       TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256      HMAC-SHA-256 P_SHA256
-       TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384      HMAC-SHA-384 P_SHA384
-       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256       HMAC-SHA-256 P_SHA256
-       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384       HMAC-SHA-384 P_SHA384
-       TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256        HMAC-SHA-256 P_SHA256
-       TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384        HMAC-SHA-384 P_SHA384
-
-2.2.  Galois Counter Mode-based Cipher Suites
-
-   The second eight cipher suites use the same asymmetric algorithms as
-   those in the previous section but use the new authenticated
-   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode
-   (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
-
-   These cipher suites use authenticated encryption with additional data
-   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [RFC5116].  GCM is used as described in [I-D.ietf-tls-rsa-aes-gcm].
-
-
-        Cipher Suite                                PRF
-        ------------                                ---
-        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256     P_SHA256
-        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384     P_SHA384
-        TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256      P_SHA256
-        TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384      P_SHA384
-        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256       P_SHA256
-        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384       P_SHA384
-        TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256        P_SHA256
-        TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384        P_SHA384
-
-
-3.  Security Considerations
-
-   The security considerations in RFC 4346, RFC 4492, and
-   [I-D.ietf-tls-rsa-aes-gcm] apply to this document as well.  In
-
-
-
-Rescorla                Expires October 31, 2008                [Page 4]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-   addition, as described in [I-D.ietf-tls-rsa-aes-gcm], these cipher
-   suites may only be used with TLS 1.2 or greater.
-
-
-4.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
-
-
-5.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-   David McGrew contributed substantual sections of the GCM nonce text
-   as well as providing a review of this document.
-
-
-6.  References
-
-6.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", RFC 5116, January 2008.
-
-
-
-
-Rescorla                Expires October 31, 2008                [Page 5]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
-              (work in progress), March 2008.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", SP 800-38A, December 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, November 2007.
-
-6.2.  Informative References
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-   [I-D.ietf-tls-rsa-aes-gcm]
-              Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
-              Suites for TLS", draft-ietf-tls-rsa-aes-gcm-03 (work in
-              progress), April 2008.
-
-
-Author's Address
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires October 31, 2008                [Page 6]
-
-Internet-Draft               TLS ECC New MAC                  April 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                Expires October 31, 2008                [Page 7]
-
diff --git a/doc/protocol/draft-ietf-tls-ecc-new-mac-07.txt b/doc/protocol/draft-ietf-tls-ecc-new-mac-07.txt
deleted file mode 100644
index 774b8737f8..0000000000
--- a/doc/protocol/draft-ietf-tls-ecc-new-mac-07.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                                RTFM, Inc.
-Intended status:  Informational                              May 9, 2008
-Expires:  November 10, 2008
-
-
-TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
-                                  Mode
-                   draft-ietf-tls-ecc-new-mac-07.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on November 10, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm.  This document describes sixteen new cipher suites for
-   TLS which specify stronger digest algorithms.  Eight use HMAC with
-   SHA-256 or SHA-384 and eight use AES in Galois Counter Mode (GCM).
-
-
-
-
-
-Rescorla                Expires November 10, 2008               [Page 1]
-
-Internet-Draft               TLS ECC New MAC                    May 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     3.1.  HMAC-based Cipher Suites  . . . . . . . . . . . . . . . . . 3
-     3.2.  Galois Counter Mode-based Cipher Suites . . . . . . . . . . 4
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires November 10, 2008               [Page 2]
-
-Internet-Draft               TLS ECC New MAC                    May 2008
-
-
-1.  Introduction
-
-   RFC 4492 [RFC4492] describes Elliptic Curve Cryptography (ECC) cipher
-   suites for Transport Layer Security (TLS).  However, all of the RFC
-   4492 suites use HMAC-SHA1 as their MAC algorithm.  Due to recent
-   analytic work on SHA-1 [Wang05], the IETF is gradually moving away
-   from SHA-1 and towards stronger hash algorithms.  This document
-   specifies TLS ECC cipher suites which use SHA-256 and SHA-384 [SHS]
-   rather than SHA-1.
-
-   TLS 1.2 [I-D.ietf-tls-rfc4346-bis], adds support for authenticated
-   encryption with additional data (AEAD) cipher modes [RFC5116].  This
-   document also specifies a set of ECC cipher suites using one such
-   mode, Galois Counter Mode (GCM) [GCM].  Another document
-   [I-D.ietf-tls-rsa-aes-gcm], provides support for GCM with other key
-   establishment methods.
-
-
-2.  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 [RFC2119].
-
-
-3.  Cipher Suites
-
-   This document defines 16 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-3.1.  HMAC-based Cipher Suites
-
-   The first eight cipher suites use AES [AES] in CBC [CBC] mode with an
-   HMAC-based MAC:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
-
-   These eight cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (with names ending in "_SHA" in place of "_SHA256"
-   or "_SHA384"), except for the hash and PRF algorithms.
-
-
-
-Rescorla                Expires November 10, 2008               [Page 3]
-
-Internet-Draft               TLS ECC New MAC                    May 2008
-
-
-   These SHALL be as follows:
-
-   o  For cipher suites ending with _SHA256, the PRF is the TLS PRF
-      [I-D.ietf-tls-rfc4346-bis] with SHA-256 as the hash function.  The
-      MAC is HMAC [RFC2104] with SHA-256 as the hash function.
-   o  For cipher suites ending with _SHA384, the PRF is the TLS PRF
-      [I-D.ietf-tls-rfc4346-bis] with SHA-384 as the hash function.  The
-      MAC is HMAC [RFC2104] with SHA-384 as the hash function.
-
-3.2.  Galois Counter Mode-based Cipher Suites
-
-   The second eight cipher suites use the same asymmetric algorithms as
-   those in the previous section but use the new authenticated
-   encryption modes defined in TLS 1.2 with AES in Galois Counter Mode
-   (GCM) [GCM]:
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
-
-   These cipher suites use authenticated encryption with additional data
-   algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [RFC5116].  GCM is used as described in [I-D.ietf-tls-rsa-aes-gcm].
-
-   The PRFs SHALL be as follows:
-
-   o  For cipher suites ending with _SHA256, the PRF is the TLS PRF
-      [I-D.ietf-tls-rfc4346-bis] with SHA-256 as the hash function.
-   o  For cipher suites ending with _SHA384, the PRF is the TLS PRF
-      [I-D.ietf-tls-rfc4346-bis] with SHA-384 as the hash function.
-
-
-4.  Security Considerations
-
-   The security considerations in RFC 4346, RFC 4492, and
-   [I-D.ietf-tls-rsa-aes-gcm] apply to this document as well.  In
-   addition, as described in [I-D.ietf-tls-rsa-aes-gcm], these cipher
-   suites may only be used with TLS 1.2 or greater.
-
-
-5.  IANA Considerations
-
-   IANA has assigned the following values for these cipher suites:
-
-
-
-Rescorla                Expires November 10, 2008               [Page 4]
-
-Internet-Draft               TLS ECC New MAC                    May 2008
-
-
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384     = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX};
-       CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX};
-       CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX};
-       CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256     = {0xXX,XX};
-       CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384     = {0xXX,XX};
-
-
-6.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-   David McGrew, Pasi Eronen, and Alfred Hoenes provided reviews of this
-   document.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", RFC 5116, January 2008.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
-              (work in progress), March 2008.
-
-
-
-Rescorla                Expires November 10, 2008               [Page 5]
-
-Internet-Draft               TLS ECC New MAC                    May 2008
-
-
-   [I-D.ietf-tls-rsa-aes-gcm]
-              Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
-              Suites for TLS", draft-ietf-tls-rsa-aes-gcm-03 (work in
-              progress), April 2008.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", SP 800-38A, December 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, November 2007.
-
-7.2.  Informative References
-
-   [Wang05]   Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
-              Full SHA-1", CRYPTO 2005, August 2005.
-
-
-Author's Address
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                Expires November 10, 2008               [Page 6]
-
-Internet-Draft               TLS ECC New MAC                    May 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                Expires November 10, 2008               [Page 7]
-
diff --git a/doc/protocol/draft-ietf-tls-ecdhe-psk-01.txt b/doc/protocol/draft-ietf-tls-ecdhe-psk-01.txt
deleted file mode 100644
index 7ce0223fc9..0000000000
--- a/doc/protocol/draft-ietf-tls-ecdhe-psk-01.txt
+++ /dev/null
@@ -1,377 +0,0 @@
-TLS Working Group                                         Mohamad Badra 
-Internet Draft                                         LIMOS Laboratory 
-Intended status: Informational                            April 2, 2008 
-Expires: October 2008 
-                                    
- 
-                                      
-         ECDHE_PSK Ciphersuites for Transport Layer Security (TLS)  
-                      draft-ietf-tls-ecdhe-psk-01.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware 
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on October 2, 2008. 
-
-Copyright Notice 
-
-   Copyright (C) The IETF Trust (2008). 
-
-Abstract 
-
-   This document extends RFC 4279, RFC 4492 and RFC 4785, and specifies 
-   a set of ciphersuites that use a pre-shared key (PSK) to authenticate 
-   an Elliptic Curve Diffie-Hellman exchange (ECDH).  These ciphersuites 
-   provide Perfect Forward Secrecy (PFS). 
-
-
- 
- 
- 
-Badra                  Expires October 2, 2008                 [Page 1] 
-
-Internet-Draft      ECDHE_PSK Ciphersuites for TLS           April 2008 
-    
-
-Table of Contents 
-
-   1. Introduction...................................................3 
-      1.1. Conventions used in this document.........................3 
-   2. ECDHE_PSK Key Exchange Algorithm...............................3 
-   3. ECDHE_PSK Key Exchange Algorithm with NULL Encryption..........5 
-   4. Security Considerations........................................5 
-   5. IANA Considerations............................................5 
-   6. Acknowledgments................................................5 
-   7. References.....................................................5 
-      7.1. Normative References......................................5 
-   Author's Addresses................................................6 
-   Intellectual Property Statement...................................6 
-   Disclaimer of Validity............................................6 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                   Expires August 2, 2008                 [Page 2] 
-
-Internet-Draft      ECDHE_PSK Ciphersuites for TLS           April 2008 
-    
-
-1. Introduction 
-
-   RFC 4279 specifies ciphersuites for supporting TLS using pre-shared 
-   symmetric keys and they (a) use only symmetric key operations for 
-   authentication, (b) use a Diffie-Hellman exchange authenticated with 
-   a pre-shared key, or (c) combines public key authentication of the 
-   server with pre-shared key authentication of the client.  
-
-   RFC 4785 specifies authentication-only ciphersuites (with no 
-   encryption).  These ciphersuites are useful when authentication and 
-   integrity protection is desired, but confidentiality is not needed or 
-   not permitted. 
-
-   RFC 4492 defines a set of ECC-based ciphersuites for TLS and 
-   describes the use of ECC certificates for client authentication.  In 
-   particular, it specifies the use of Elliptic Curve Diffie-Hellman 
-   (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve 
-   Digital Signature Algorithm (ECDSA) as a new authentication 
-   mechanism. 
-
-   This document specifies a set of ciphersuites that use a PSK to 
-   authenticate an ECDH exchange.  These ciphersuites provide Perfect 
-   Forward Secrecy.  One of these ciphersuite provides authentication-
-   only. 
-
-   The reader is expected to become familiar with RFC 4279, RFC 4492, 
-   and RFC 4785 prior to studying this document. 
-
-1.1. 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 [RFC2119]. 
-
-2. ECDHE_PSK Key Exchange Algorithm 
-
-   The ciphersuites in this section match the ciphersuites defined in 
-   [RFC4279], except that they use an Elliptic Curve Diffie-Hellman 
-   exchange [RFC4492] authenticated with a PSK.  They are defined as 
-   follow:  
-
-     CipherSuite                          Key Exchange  Cipher      Hash 
-
-     TLS_ECDHE_PSK_WITH_RC4_128_SHA       ECDHE_PSK     RC4_128      SHA 
-     TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA  ECDHE_PSK     3DES_EDE_CBC SHA 
-     TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA   ECDHE_PSK     AES_128_CBC  SHA 
-     TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA   ECDHE_PSK     AES_256_CBC  SHA 
- 
- 
-Badra                   Expires August 2, 2008                 [Page 3] 
-
-Internet-Draft      ECDHE_PSK Ciphersuites for TLS           April 2008 
-    
-
-   These ciphersuites make use of the EC parameter negotiation mechanism 
-   defined in RFC 4492.  When the ciphersuites defined in this document 
-   are used, the 'ec_diffie_hellman_psk' case inside the 
-   ServerKeyExchange and ClientKeyExchange structure MUST be used 
-   instead of the 'psk' case defined in [RFC4279] (i.e., the 
-   ServerKeyExchange and ClientKeyExchange messages include the Diffie-
-   Hellman parameters).  The PSK identity and identity hint fields have 
-   the same meaning and encoding specified in [RFC4279] (note that the 
-   ServerKeyExchange message is always sent, even if no PSK identity 
-   hint is provided). 
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is 
-   shown below. 
-
-         struct {  
-             select (KeyExchangeAlgorithm) {  
-                 /* other cases for rsa, diffie_hellman, etc. */  
-                 case ec_diffie_hellman_psk:  /* NEW */  
-                     opaque psk_identity_hint<0..2^16-1>;  
-                     ServerECDHParams params;  
-             };  
-         } ServerKeyExchange;  
-
-         struct {  
-             select (KeyExchangeAlgorithm) {  
-                 /* other cases for rsa, diffie_hellman, etc. */  
-                 case ec_diffie_hellman_psk:   /* NEW */  
-                     opaque psk_identity<0..2^16-1>;  
-                     ClientECDiffieHellmanPublic public;  
-             } exchange_keys;  
-         } ClientKeyExchange; 
-
-   The premaster secret is formed as follows.  First, perform an ECDH 
-   operation (See section 5.10 of [RFC4492]) to compute the shared 
-   secret.  Next, concatenate a uint16 containing the length of the 
-   shared secret (in octets), the shared secret itself, a uint16 
-   containing the length of the PSK (in octets), and the PSK itself. 
-
-   This corresponds to the general structure for the premaster secrets 
-   (see Note 1 in Section 2 of [RFC4279]), with "other_secret" 
-   containing the shared secret: 
-
-         struct { 
-              opaque other_secret<0..2^16-1>;  
-              opaque psk<0..2^16-1>;  
-         }; 
-
- 
- 
-Badra                   Expires August 2, 2008                 [Page 4] 
-
-Internet-Draft      ECDHE_PSK Ciphersuites for TLS           April 2008 
-    
-
-3. ECDHE_PSK Key Exchange Algorithm with NULL Encryption 
-
-   The ciphersuite in this section matches the ciphersuites defined in 
-   section 2, except that we define a suite with null encryption. 
-
-     CipherSuite                     Key Exchange   Cipher      Hash  
-
-     TLS_ECDHE_PSK_WITH_NULL_SHA     ECDHE_PSK      NULL        SHA  
-
-4. Security Considerations 
-
-   The security considerations described throughout [RFC4279], 
-   [RFC4346], [RFC4492], and [RFC4785] apply here as well. 
-
-5. IANA Considerations 
-
-   This document defines the following new ciphersuites, whose values 
-   are to be assigned from the TLS Cipher Suite registry defined in 
-   [RFC4346]. 
-
-     CipherSuite TLS_ECDHE_PSK_WITH_RC4_128_SHA        = { 0xXX, 0xXX }; 
-     CipherSuite TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA   = { 0xXX, 0xXX }; 
-     CipherSuite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA    = { 0xXX, 0xXX }; 
-     CipherSuite TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA    = { 0xXX, 0xXX }; 
-     CipherSuite TLS_ECDHE_PSK_WITH_NULL_SHA           = { 0xXX, 0xXX }; 
-
-6. Acknowledgments 
-
-   The author would like to thank Bodo Moeller, Simon Josefsson, Uri 
-   Blumenthal, Pasi Eronen, Alfred Hoenes, Paul Hoffman, Joseph Salowey, 
-   and the TLS mailing list members for their comments on the document. 
-
-7. References 
-
-7.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005.  
-
-   [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", 
-             RFC 4346, April 2006. 
-
-
- 
- 
-Badra                   Expires August 2, 2008                 [Page 5] 
-
-Internet-Draft      ECDHE_PSK Ciphersuites for TLS           April 2008 
-    
-
-   [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 
-             Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 
-             for Transport Layer Security (TLS)", RFC 4492, May 2006. 
-
-   [RFC4785] Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK) 
-             Ciphersuites with NULL Encryption for Transport Layer 
-             Security (TLS)", RFC 4785, January 2007. 
-
-Author's Addresses 
-
-   Mohamad Badra 
-   LIMOS Laboratory - UMR6158, CNRS 
-   France 
-    
-   Email: badra@isima.fr 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
- 
- 
-Badra                   Expires August 2, 2008                 [Page 6] 
-
-Internet-Draft      ECDHE_PSK Ciphersuites for TLS           April 2008 
-    
-
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The IETF Trust (2008). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- 
- 
-Badra                   Expires August 2, 2008                 [Page 7] 
-
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] 
-
diff --git a/doc/protocol/draft-ietf-tls-extractor-00.txt b/doc/protocol/draft-ietf-tls-extractor-00.txt
deleted file mode 100644
index 9c7dd50261..0000000000
--- a/doc/protocol/draft-ietf-tls-extractor-00.txt
+++ /dev/null
@@ -1,337 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Intended status:  Standards Track                      December 19, 2007
-Expires:  June 21, 2008
-
-
-     Keying Material Extractors for Transport Layer Security (TLS)
-                    draft-ietf-tls-extractor-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 21, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   to perform key establishment but then use some of the keying material
-   for their own purposes.  This document describes a general mechanism
-   for allowing that.
-
-
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 1]
-
-Internet-Draft               TLS Extractors                December 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Signalling Extractors . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 3
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     8.2.  Informational References  . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 2]
-
-Internet-Draft               TLS Extractors                December 2007
-
-
-1.  Introduction
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   [4] or Datagram TLS (DTLS) [5] to perform key establishment but then
-   use some of the keying material for their own purposes.  A typical
-   example is DTLS-SRTP [6], which uses DTLS to perform a key exchange
-   and negotiate the SRTP [3] protection suite and then uses the DTLS
-   master_secret to generate the SRTP keys.
-
-   These applications imply a need to be able to extract Exported Keying
-   Material (EKM) from TLS/DTLS.  This mechanism has the following
-   requirements:
-
-   o  Both client and server need to be able to extract the same EKM
-      value.
-   o  EKM values should be indistinguishable from random by attackers
-      who don't know the master_secret.
-   o  It should be possible to extract multiple EKM values from the same
-      TLS/DTLS association.
-   o  Knowing one EKM value should not reveal any information about the
-      master_secret or about other EKM values.
-
-   The mechanism described in this document is intended to fill these
-   requirements.
-
-
-2.  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 [1].
-
-
-3.  Signalling Extractors
-
-   Other protocols which wish to use extractors SHOULD have some way for
-   the peers to signal that an extractor will be used.  An example is a
-   TLS extension, as used in DTLS-SRTP.
-
-
-4.  Extractor Definition
-
-   An extractor takes as input two values:
-
-   o  A disambiguating label string
-   o  A length value
-
-   It then computes:
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 3]
-
-Internet-Draft               TLS Extractors                December 2007
-
-
-          PRF(master_secret, label,
-              SecurityParameters.client_random +
-              SecurityParameters.server_random)[length]
-
-   The output is a pseudorandom bit string of length bytes generated
-   from the master_secret.
-
-   Label values MUST be registered via Specification Required as
-   described by RFC 2434 [2].  Note that extractor labels have the
-   potential to collide with existing PRF labels.  In order to prevent
-   this, labels SHOULD begin with "EXTRACTOR".  This is not a MUST
-   because there are existing uses which have labels which do not begin
-   with this prefix.
-
-
-5.  Security Considerations
-
-   Because an extractor produces the same value if applied twice with
-   the same label to the same master_secret, it is critical that two EKM
-   values generated with the same label be used for two different
-   purposes--hence the requirement for IANA registration.  However,
-   because extractors depend on the TLS PRF, it is not a threat to the
-   use of an EKM value generated from one label to reveal an EKM value
-   generated from another label.
-
-
-6.  IANA Considerations
-
-   IANA is requested to create (has created) a TLS Extractor Label
-   registry for this purpose.  The initial contents of the registry are
-   given below:
-
-      Value                          Reference
-      -----                          ------------
-      client finished                [RFC4346]
-      server finished                [RFC4346]
-      master secret                  [RFC4346]
-      key expansion                  [RFC4346]
-      client EAP encryption          [RFC2716]
-      ttls keying material           [draft-funk-eap-ttls-v0-01]
-
-   Future values are allocated via RFC2434 Specification Required
-   policy.  The label is a string consisting of printable ASCII
-   characters.  IANA MUST also verify that one label is not a prefix of
-   any other label.  For example, labels "key" or "master secretary" are
-   forbidden.
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 4]
-
-Internet-Draft               TLS Extractors                December 2007
-
-
-7.  Acknowledgments
-
-   Thanks to Pasi Eronen for valuable comments and the contents of the
-   IANA section.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [3]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
-        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
-        RFC 3711, March 2004.
-
-   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
-        Protocol Version 1.1", RFC 4346, April 2006.
-
-   [5]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-        Security", RFC 4347, April 2006.
-
-8.2.  Informational References
-
-   [6]  McGrew, D. and E. Rescorla, "Datagram Transport Layer Security
-        (DTLS) Extension to Establish Keys for  Secure Real-time
-        Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01 (work in
-        progress), November 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   Network Resonance
-   2064 Edgewood Drive
-   Palo Alto, CA  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 5]
-
-Internet-Draft               TLS Extractors                December 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                  Expires June 21, 2008                 [Page 6]
-
-
diff --git a/doc/protocol/draft-ietf-tls-extractor-01.txt b/doc/protocol/draft-ietf-tls-extractor-01.txt
deleted file mode 100644
index a992f2b24f..0000000000
--- a/doc/protocol/draft-ietf-tls-extractor-01.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Intended status:  Standards Track                      February 20, 2008
-Expires:  August 23, 2008
-
-
-     Keying Material Extractors for Transport Layer Security (TLS)
-                    draft-ietf-tls-extractor-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 23, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   to perform key establishment but then use some of the keying material
-   for their own purposes.  This document describes a general mechanism
-   for allowing that.
-
-
-
-
-
-
-
-Rescorla                 Expires August 23, 2008                [Page 1]
-
-Internet-Draft               TLS Extractors                February 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Binding to Application Contexts . . . . . . . . . . . . . . . . 3
-   4.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 4
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     8.2.  Informational References  . . . . . . . . . . . . . . . . . 6
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                 Expires August 23, 2008                [Page 2]
-
-Internet-Draft               TLS Extractors                February 2008
-
-
-1.  Introduction
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   [RFC4346] or Datagram TLS (DTLS) [RFC4347] to perform key
-   establishment but then use some of the keying material for their own
-   purposes.  A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp],
-   which uses DTLS to perform a key exchange and negotiate the SRTP
-   [RFC3711] protection suite and then uses the DTLS master_secret to
-   generate the SRTP keys.
-
-   These applications imply a need to be able to extract keying material
-   (later called Exported Keying Material or EKM) from TLS/DTLS, and
-   securely agree on the upper-layer context where the keying material
-   will be used.  The mechanism for extracting the keying material has
-   the following requirements:
-
-   o  Both client and server need to be able to extract the same EKM
-      value.
-   o  EKM values should be indistinguishable from random by attackers
-      who don't know the master_secret.
-   o  It should be possible to extract multiple EKM values from the same
-      TLS/DTLS association.
-   o  Knowing one EKM value should not reveal any information about the
-      master_secret or about other EKM values.
-
-   The mechanism described in this document is intended to fill these
-   requirements.
-
-
-2.  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 [RFC2119].
-
-
-3.  Binding to Application Contexts
-
-   In addition to extracting keying material, an application using the
-   keying material has to securely establish the upper-layer layer
-   context where the keying material will be used.  The details of this
-   context depend on the application, but it could include things such
-   as algorithms and parameters that will be used with the keys,
-   identifier(s) for the endpoint(s) who will use the keys,
-   identifier(s) for the session(s) where the keys will be used, and the
-   lifetime(s) for the context and/or keys.  At minimum, there should be
-   some mechanism for signalling that an extractor will be used.
-
-
-
-
-Rescorla                 Expires August 23, 2008                [Page 3]
-
-Internet-Draft               TLS Extractors                February 2008
-
-
-   This specification does not mandate a single mechanism for agreeing
-   on such context; instead, there are several possibilities that can be
-   used (and can complement each other).  For example:
-
-   o  One important part of the context -- which application will use
-      the extracted keys -- is given by the disambiguating label string
-      (see Section 4).
-   o  Information about the upper-layer context can be included in the
-      optional data after the extractor label (see Section 4).
-   o  Information about the upper-layer context can be exchanged in TLS
-      extensions included in the ClientHello and ServerHello messages.
-      This approach is used in [DTLS-SRTP].  The handshake messages are
-      protected by the Finished messages, so once the handshake
-      completes, the peers will have the same view of the information.
-      Extensions also allow a limited form of negotiation:  for example,
-      the TLS client could propose several alternatives for some context
-      parameters, and TLS server could select one of them.
-   o  The upper-layer protocol can include its own handshake which can
-      be protected using the keys extracted from TLS.
-
-   It is important to note that just embedding TLS messages in the
-   upper-layer protocol may not automatically secure all the important
-   context information, since the upper-layer messages are not covered
-   by TLS Finished messages.
-
-
-4.  Extractor Definition
-
-   An extractor takes as input three values:
-
-   o  A disambiguating label string
-   o  A per-association context value provided by the extractor using
-      application
-   o  A length value
-
-   It then computes:
-
-
-          PRF(master_secret, label,
-              SecurityParameters.client_random +
-              SecurityParameters.server_random +
-              context_value_length + context_value
-              )[length]
-
-   The output is a pseudorandom bit string of length bytes generated
-   from the master_secret.
-
-   Label values beginning with "EXPERIMENTAL" MAY be used for private
-
-
-
-Rescorla                 Expires August 23, 2008                [Page 4]
-
-Internet-Draft               TLS Extractors                February 2008
-
-
-   use without registration.  All other label values MUST be registered
-   via Specification Required as described by RFC 2434 [RFC2434].  Note
-   that extractor labels have the potential to collide with existing PRF
-   labels.  In order to prevent this, labels SHOULD begin with
-   "EXTRACTOR".  This is not a MUST because there are existing uses
-   which have labels which do not begin with this prefix.
-
-   The context value allows the application using the extractor to mix
-   its own data with the TLS PRF for the extractor output.  The context
-   value length is encoded as an unsigned 16-bit quantity (uint16)
-   representing the length of the context value.
-
-
-5.  Security Considerations
-
-   Because an extractor produces the same value if applied twice with
-   the same label to the same master_secret, it is critical that two EKM
-   values generated with the same label be used for two different
-   purposes--hence the requirement for IANA registration.  However,
-   because extractors depend on the TLS PRF, it is not a threat to the
-   use of an EKM value generated from one label to reveal an EKM value
-   generated from another label.
-
-
-6.  IANA Considerations
-
-   IANA is requested to create (has created) a TLS Extractor Label
-   registry for this purpose.  The initial contents of the registry are
-   given below:
-
-      Value                          Reference
-      -----                          ------------
-      client finished                [RFC4346]
-      server finished                [RFC4346]
-      master secret                  [RFC4346]
-      key expansion                  [RFC4346]
-      client EAP encryption          [RFC2716]
-      ttls keying material           [draft-funk-eap-ttls-v0-01]
-
-   Future values are allocated via RFC2434 Specification Required
-   policy.  The label is a string consisting of printable ASCII
-   characters.  IANA MUST also verify that one label is not a prefix of
-   any other label.  For example, labels "key" or "master secretary" are
-   forbidden.
-
-
-
-
-
-
-
-Rescorla                 Expires August 23, 2008                [Page 5]
-
-Internet-Draft               TLS Extractors                February 2008
-
-
-7.  Acknowledgments
-
-   Thanks to Pasi Eronen for valuable comments and the contents of the
-   IANA section and Section 3.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-8.2.  Informational References
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
-              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
-              RFC 3711, March 2004.
-
-   [I-D.ietf-avt-dtls-srtp]
-              McGrew, D. and E. Rescorla, "Datagram Transport Layer
-              Security (DTLS) Extension to Establish Keys for  Secure
-              Real-time Transport Protocol (SRTP)",
-              draft-ietf-avt-dtls-srtp-01 (work in progress),
-              November 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   Network Resonance
-   2064 Edgewood Drive
-   Palo Alto, CA  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-Rescorla                 Expires August 23, 2008                [Page 6]
-
-Internet-Draft               TLS Extractors                February 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                 Expires August 23, 2008                [Page 7]
-
diff --git a/doc/protocol/draft-ietf-tls-kerb-01.txt b/doc/protocol/draft-ietf-tls-kerb-01.txt
deleted file mode 100644
index 35cc348b8b..0000000000
--- a/doc/protocol/draft-ietf-tls-kerb-01.txt
+++ /dev/null
@@ -1,537 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                    Matthew Hur
-Transport Layer Security Working Group            Joseph Salowey
-draft-ietf-tls-kerb-01.txt                        Cisco Systems
-Obsoletes: RFC 2712                               Ari Medvinsky
-November 8, 2001 (Expires May 8, 2001)            Liberate
-
-
-
-
-        Kerberos Cipher Suites in Transport Layer Security (TLS)
-
-
-
-
-0. Status Of this Memo
-
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC 2026.  Internet-Drafts are 
-   working documents of the Internet Engineering Task Force (IETF), its 
-   areas, and its working groups.  Note that other groups may also 
-   distribute working documents as Internet-Drafts.
-
-   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/1id-abstracts.html
-
-     The list of Internet-Draft Shadow Directories can be accessed at
-     http://www.ietf.org/shadow.html
-
-
-
-1. Abstract
-
-   RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos 
-   [KERB] authentication within the TLS protocol [TLS].  This document 
-   extends RFC 2712 to support delegation of Kerberos credentials.  In 
-   this way, a TLS server may obtain a Kerberos service ticket on behalf 
-   of the TLS client.  Thus, a single client identity may be used for 
-   authentication within a multi-tier architecture.  This draft also 
-   proposes a mechanism for a TLS server to indicate Kerberos-specific 
-   information to the client within the certificate request message in 
-   the initial exchange.
-
-
-2. Introduction
-
-   Flexibility is one of the main strengths of the TLS protocol. Clients 
-   and servers can negotiate cipher suites to meet specific security and 
-   administrative policies.  RFC 2712 specified how TLS could be 
-   extended to support organizations with heterogeneous security 
-   deployments that include authentication systems based on symmetric 
-   cryptography.  Kerberos, originally developed at MIT, is based on an 
-   open standard and is the most widely deployed symmetric key 
-   authentication system.  Just as other documents specify hybrid 
-   asymmetric/symmetric key protocols [PKINIT] [PKCROSS] [PKTAPP], this 
-   document specifies how TLS may incorporate both symmetric and 
-   asymmetric key crypto systems.
-
-   This document describes the use of Kerberos authentication within 
-   the TLS framework.  This achieves mutual authentication and the 
-   establishment of a master secret using Kerberos credentials.  
-   Additionally, this document specifies support for delegation of 
-   Kerberos credentials, which enables end to end authentication within 
-   an n-tier architecture.  The proposed changes are minimal and, in 
-   fact, no different from adding a new public key algorithm to the TLS 
-   framework.
-
-
-3. Kerberos Authentication Option In TLS
-
-   This section describes the addition of the Kerberos authentication
-   option to the TLS protocol.  Throughout this document, we refer to
-   the basic SSL handshake shown in Figure 1.  For a review of the TLS
-   handshake see [TLS].
-   
-   +-------------------------------------------------------------------+
-   | CLIENT                                        SERVER              |
-   | ------                                        ------              |
-   | ClientHello                                                       |
-   |                  --------------------------->                     |
-   |                                               ServerHello         |
-   |                                               Certificate *       |
-   |                                               ServerKeyExchange*  |
-   |                                               CertificateRequest* |
-   |                                               ServerHelloDone     |
-   |                  <---------------------------                     |
-   | Certificate*                                                      |
-   | ClientKeyExchange                                                 |
-   | CertificateVerify*                                                |
-   | change cipher spec                                                |
-   | Finished                                                          |
-   |     |            --------------------------->                     |
-   |     |                                          change cipher spec |
-   |     |                                          Finished           |
-   |     |                                              |              |
-   |     |                                              |              |
-   | Application Data <-------------------------->  Application Data   |
-   +-------------------------------------------------------------------+
-   FIGURE 1: The TLS protocol.  All messages followed by a star are
-             optional.  Note: This figure was taken from RFC 2246.
-
-   The TLS security context is negotiated in the client and server hello
-   messages.  For example: TLS_RSA_WITH_RC4_128_MD5 means the initial
-   authentication will be done using the RSA public key algorithm, RC4
-   will be used with a 128 bit session key, and MACs will be based on 
-   the MD5 algorithm.  Thus, to facilitate the Kerberos authentication 
-   option, we must start by defining Kerberos cipher suites including 
-   (but not limited to):
-
-   CipherSuite     TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x70 };
-   CipherSuite     TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x71 };
-   CipherSuite     TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x72 };
-   CipherSuite     TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x73 };
-   CipherSuite     TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x74 };
-   CipherSuite     TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x75 };
-   CipherSuite     TLS_KRB5_WITH_AES_128_CBC_SHA        = { 0x00,0x76 };
-   CipherSuite     TLS_KRB5_WITH_AES_256_CBC_SHA        = { 0x00,0x77 };
-   CipherSuite     TLS_KRB5_WITH_NULL_SHA               = { 0x00,0x78 };
-   CipherSuite     TLS_KRB5_WITH_NULL_MD5               = { 0x00,0x79 };
-
-   To establish a Kerberos-based security context, one or more of the 
-   above cipher suites must be specified in the client hello message. If 
-   the TLS server supports the Kerberos authentication option, the 
-   server hello message, sent to the client, will confirm the Kerberos 
-   cipher suite selected by the server.  The server's certificate and 
-   the ServerKeyExchange shown in Figure 1 will be omitted since 
-   authentication and the establishment of a master secret will be done 
-   using the client's Kerberos credentials for the TLS server.  Note 
-   that these messages are specified as optional in the TLS protocol; 
-   therefore, omitting them is permissible.
-
-   The Kerberos option affects three of the TLS messages: the 
-   CertificateRequest, the client Certificate, and the 
-   ClientKeyExchange.  However, only the client Certificate and the 
-   ClientKeyExchange are required.
-
-
-3.1. Usage of the CertificateRequest Message
-
-   If the server accepts a Kerberos-based ciphersuite, then it MUST send 
-   the CertificateRequest message to the client.  This message conveys 
-   Kerberos-specific characteristics such as realm name or attributes 
-   such as forwarded ticket.
-
-   RFC 2246 defines the CertificateRequest message as follows:
-   +-------------------------------------------------------------------+
-   |                                                                   |
-   |   enum {                                                          |
-   |       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), |
-   |       (255)                                                       |
-   |   } ClientCertificateType;                                        |
-   |                                                                   |
-   |   opaque DistinguishedName<1..2^16-1>;                            |
-   |                                                                   |
-   |   struct { ClientCertificateType certificate_types<1..2^8-1>;     |
-   |            DistinguishedName certificate_authorities<3..2^16-1>;  |
-   |   } CertificateRequest;                                           |
-   |                                                                   |
-   +-------------------------------------------------------------------+
-   FIGURE 2: CertificateRequest message from RFC 2246
-
-   This specification defines a new ClientCertificateType for a Kerberos 
-   certificate.  This enables a client to respond to the 
-   CertificateRequest message when using Kerberos ciphersuites.  The 
-   Kerberos ClientCertificateType MUST NOT be included in 
-   certificate_types for non-Kerberos ciphersuites. Thus the following 
-   change for ClientCertificateType is required (Figure 3).
-
-   +-------------------------------------------------------------------+    
-   |                                                                   | 
-   |   enum {                                                          | 
-   |       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | 
-   |       kerberos(5), (255)                                          | 
-   |   } ClientCertificateType;                                        | 
-   |                                                                   | 
-   +-------------------------------------------------------------------+ 
-   FIGURE 3: New Kerberos ClientCertificateType
-
-   In the case of a public key based authentication algorithm, the 
-   opaque DistinguishedName field is derived from [X509], and it 
-   contains the name of an acceptable certification authority (This is 
-   as specified in [TLS]).  In the case of a Kerberos 
-   ClientCertificateType, the DistinguishedName field is defined to 
-   represent Kerberos information (KerbInfo) as shown in Figure 4.  The 
-   srv_tgt attribute type is used by the server to send a TGT that the 
-   client presents to the KDC in the case of user-to-user 
-   authentication.  The KDC uses the session key from this ticket to 
-   encrypt a service ticket for the server.  In this case the attr_data
-   must be of non-zero length and contain the server's TGT.
-
-   +-------------------------------------------------------------------+    
-   |                                                                   | 
-   |   enum                                                            | 
-   |   {                                                               | 
-   |      srv_tkt(1), fwd_tgt(2), (255)                                | 
-   |   } KerbInfoType;                                                 | 
-   |                                                                   | 
-   |   enum                                                            | 
-   |   {                                                               | 
-   |      initial_tkt_required(1), srv_tgt(2), (255)                   | 
-   |   } AttrType; /* This may be extended to include attributes    */ | 
-   |               /*  such as forwardable or renewable for example */ | 
-   |                                                                   | 
-   |   struct                                                          | 
-   |   {                                                               | 
-   |      AttrType       attr_type;                                    | 
-   |      opaque         attr_data <0..2^16-1>;                        | 
-   |   } AttrInfoType                                                  | 
-   |                                                                   | 
-   |   struct                                                          | 
-   |   {                                                               | 
-   |      uint32         length; /* length of this struct */           | 
-   |      KerbInfoType   type;                                         | 
-   |      opaque         sname <0..2^16-1>;                            | 
-   |      opaque         srealm <0..2^16-1>;                           | 
-   |      opaque         cname <0..2^16-1>;                            | 
-   |      opaque         crealm <0..2^16-1>;                           | 
-   |      AttrInfoType   attr_info <0..2^16-1>; /* sequence of      */ | 
-   |                                            /* attributes       */ | 
-   |      uint32         etypes <0..2^16-1>; /* list of supported   */ | 
-   |                                         /* Kerberos etypes     */ |
-   |                                         /* for authentication  */ |
-   |   } TktInfo;                                                      | 
-   |                                                                   | 
-   |   struct                                                          | 
-   |   {                                                               | 
-   |      TktInfo       tkt_info <1..2^20-1>; /* MUST have at least */ | 
-   |                                          /* 1 TktInfo structs */  | 
-   |   } KerbInfo                                                      | 
-   |                                                                   | 
-   +-------------------------------------------------------------------+ 
-   FIGURE 4: Kerberos Information for CertificateRequest Message
-
-
-3.2. Usage of the Client Certificate Message
-
-   As specified by [TLS], when the client receives the 
-   CertificateRequest message, it MUST respond with the client 
-   Certificate message.  As stated above, this specification defines a 
-   Kerberos certificate type.  The format for the Kerberos certificate 
-   is specified in figure 5 below.  This structure consists of a 
-   Kerberos AP-REQ message that is used for authenticating the client to 
-   he server.  It optionally contains a series of Kerberos KRB-CRED 
-   messages to convey delegated credentials.
-
-   Note that the client may determine the type of credentials to send to 
-   the server, based on local policy.  Part of the input to a client's 
-   decision may come from the Kerberos KDC.  For example, The client may 
-   convey a delegated ticket based on the ok-as-delegate ticket flag set 
-   in the service ticket.  Also, the session key used to protect a 
-   forwarded credential, MUST be of equal or greater strength than the 
-   key used to protect the ticket when originally sent to the client 
-   (typically, this key is the client principal key, shared with the 
-   Kerberos KDC).
-
-   +-------------------------------------------------------------------+
-   |                                                                   |
-   |  opaque KrbCred <1..2^16-1>; /* Kerberos-defined KRB-CRED */      |
-   |                                                                   |
-   |  struct                                                           |
-   |  {                                                                |
-   |      opaque    ap_req <1..2^16-1>;                                |
-   |      KrbCred   krb_cred <0..2^20-1>;                              |
-   |  } KerberosCert;                                                  |
-   |                                                                   |
-   +-------------------------------------------------------------------+
-   FIGURE 5: Kerberos Certificate Type
-
-
-3.3. Usage of the ClientKeyExchange Message
-
-
-   The Kerberos option must be added to the ClientKeyExchange message as    
-   shown in Figure 6.
-
-   +-------------------------------------------------------------------+
-   |                                                                   |
-   |  struct                                                           |
-   |  {                                                                |
-   |      select (KeyExchangeAlgorithm)                                |
-   |      {                                                            |
-   |          case krb:             KerbEncryptedPreMasterSecret;      |
-   |          case rsa:             EncryptedPreMasterSecret;          |
-   |          case diffie_hellman:  ClientDiffieHellmanPublic;         |
-   |      } Exchange_keys;                                             |
-   |  } ClientKeyExchange;                                             |
-   |                                                                   |
-   | KerbEncryptedPreMasterSecret contains the PreMasterSecret         |
-   | encrypted within a Kerberos-defined EncryptedData structure.      |
-   | The encryption key is sealed in the ticket sent in the Client     |
-   | Certificate message.                                              |
-   |                                                                   |
-   +-------------------------------------------------------------------+
-   FIGURE 6: The Kerberos option in the ClientKeyExchange.
-
-   To use the Kerberos authentication option, the TLS client must obtain
-   a service ticket for the TLS server.  In TLS, the ClientKeyExchange
-   message is used to pass a random 48-byte pre-master secret to the
-   server.
-
-   The client and server then use the pre-master secret to independently
-   derive the master secret, which in turn is used for generating
-   session keys and for MAC computations.  Thus, if the Kerberos option
-   is selected, the pre-master secret structure is the same as that used
-   in the RSA case; it is encrypted under the Kerberos session key and
-   sent to the TLS server along with the Kerberos credentials (see
-   Figure 2).  The ticket and authenticator are encoded per RFC 1510
-   (ASN.1 encoding).  Once the ClientKeyExchange message is received,
-   the server's secret key is used to unwrap the credentials and extract
-   the pre-master secret.
-
-   Lastly, the client and server exchange the finished messages to
-   complete the handshake.  At this point we have achieved the
-   following:
-
-   1) A master secret, used to protect all subsequent communication, is
-      securely established.
-
-   2) Mutual client-server authentication is achieved, since the TLS
-      server proves knowledge of the master secret in the finished
-      message.
-
-   Kerberos fits seamlessly into TLS, without adding any new messages.
-
-
-4. Naming Conventions:
-
-   To obtain an appropriate service ticket, the TLS client must
-   determine the principal name of the TLS server.  The Kerberos service
-   naming convention is as follows:
-
-     host/MachineName@Realm
-      where:
-        - The literal, "host", follows the Kerberos convention when not
-          concerned about the protection domain on a particular machine.
-        - "MachineName" is the particular instance of the service.
-        - The Kerberos "Realm" is the domain name of the machine.
-
-   As specified above, in the CertificateRequest message, the server may 
-   indicate the appropriate principal name and realm.
-
-
-5. Summary
-
-   The proposed Kerberos authentication option is added in exactly the
-   same manner as a new public key algorithm would be added to TLS.
-   Furthermore, it establishes the master secret in exactly the same
-   manner.
-
-
-6. Security Considerations
-
-   Kerberos ciphersuites are subject to the same security considerations 
-   as the TLS protocol.  In addition, just as a public key implementation 
-   must take care to protect the private key (for example the PIN for a 
-   smartcard), a Kerberos implementation must take care to protect the 
-   long lived secret that is shared between the principal and the KDC.  
-   In particular, a weak password may be subject to a dictionary attack.  
-   In order to strengthen the initial authentication to a KDC, an 
-   implementor may choose to utilize secondary authentication via a token 
-   card, or one may utilize initial authentication to the KDC based on 
-   public key cryptography (commonly known as PKINIT - a product of the 
-   Kerberos working group of the IETF).
-
-   The unauthenticated CertificateRequest message, specified above, 
-   enables the server to request a particular client principal name as 
-   well as a particular service principal name.  In the event that a 
-   service principal name is specified, there is a risk that the client 
-   may be tricked into requesting a ticket for a rogue server.  
-   Furthermore, if delegation is requested, the client may be tricked 
-   into forwarding its TGT to a rogue server.  In order to assure that a 
-   service ticket is obtained for the correct server, the client should 
-   rely on a combination of its own local policy, local configuration 
-   information, and information supplied by the KDC.  The client may 
-   choose to use only the naming convention specified in section 4.  The 
-   client may rely on the KDC performing name cannonicalization (this is 
-   a matter that is adressed in revisions to RFC 1510).
-
-   The client must apply its local policy to determine whether or not to 
-   forward its credentials.  As previously stated, the client should 
-   incorporate information from the KDC, in particular the ok-as- 
-   delegate ticket flag, in making such a policy decision.
-
-   The forwarded credential MUST be protected in a key that is at least 
-   the same strength as the principal key that originally protected the 
-   TGT.
-
-   A forwarded TGT presents more vulnerabilities in the event of a rogue 
-   server or the compromise of the session key.  An attacker would be 
-   able to impersonate the client to obtain new service tickets.  Such 
-   an attack may be mitigated by the use of restrictions, such as those 
-   described in [Neuman].
-
-   It has been shown that 56-bit DES keys are relatively easy to 
-   compromise [DESCRACK]; therefore, use of 56-bit DES is discouraged.
-
-
-7. Acknowledgements
-
-   We would like to thank the following people for their input for this 
-   document:
-    Clifford Neuma - ISI
-    John Brezak and David Mowers - Microsoft
-    
-
-
-8. References
-
-   [KERBTLS]  A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [KERB]     J. Kohl and C. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510, September 1993.
-
-   [TLS]      T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
-              RFC 2246, January 1999.
-
-   [PKINIT]   B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,
-              J. Wray, J. Trostle.  Public Key Cryptography for Initial
-              Authentication in Kerberos.
-              draft-ietf-cat-kerberos-pk-init-14.txt
-
-   [PKTAPP]   A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
-              Public Key Utilizing Tickets for Application
-              Servers (PKTAPP).  draft-ietf-cat-kerberos-pk-tapp-03.txt
-    
-   [PKCROSS]  M. Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik,
-              A. Medvinsky, B. Sommerfeld.  Public Key Cryptography for
-              Cross-Realm Authentication in Kerberos.
-              draft-ietf-cat-kerberos-pk-cross-07.txt
-
-   [X509]     ITU-T (formerly CCITT) Information technology - Open
-              Systems Interconnection - The Directory: Authentication
-              Framework Recommendation X.509 ISO/IEC 9594-8
-
-   [NEUMAN]   B.C. Neuman, "Proxy-Based Authorization and Accounting for
-              Distributed Systems".  Proceedings of the 13th
-              International Conference on Distributed Computing Systems,
-              May 1993
-
-   [DESCRACK] Electronic Frontier Foundation, "Cracking DES: Secrets of
-              Encryption Research, Wiretap Politics, and Chip Design".
-              May 1998, Electronic Frontier Foundation.
-
-
-9. Authors' Addresses
-
-   Matthew Hur
-   Cisco Systems
-   2901 Third Avenue
-   Seattle, WA 98121
-   Phone: +1 206 256 3197
-   EMail: mhur@cisco.com
-   http://www.cisco.com
-
-   Joseph Salowey
-   Cisco Systems
-   2901 Third Avenue
-   Seattle, WA 98121
-   Phone: +1 206 256 3380
-   EMail: jsalowey@cisco.com
-   http://www.cisco.com
-
-   Ari Medvinsky
-   Liberate
-   2 Circle Star Way
-   San Carlos, CA 94070-6200
-   Phone: +1 650 701 4000
-   EMail: ari@liberate.com
-   http://www.liberate.com
-
-
-10. Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-11. Appendix
-
-Changes from RFC 2712
-
-   Added new cipher suites with NULL confidentiality:
-    	TLS_KRB5_WITH_NULL_SHA
-    	TLS_KRB5_WITH_NULL_MD5
-
-   Added new cipher suites to support AES:
-	TLS_KRB5_WITH_AES_128_CBC_SHA 
-        TLS_KRB5_WITH_AES_256_CBC_SHA 
-
-   40 bit ciphers have been removed, and AES ciphers have been added.
-   
-   All of the ciphersuites have been renumbered to avoid conflicts with
-   exisiting implementations of RFC 2712.	
-
-   RFC 2712 utilized only the ClientKeyExchange message for conveying 
-   the Kerberos credentials and encrypted premaster-secret.  This 
-   specification moves the Kerberos credentials to the client 
-   certificate message, and it allows the client to pass delegated 
-   credentials as well.  Additionally, this specification allows the 
-   server to specify Kerberos-specific information (realm, delegation 
-   required, etc.) in the  CertificateRequest message.
-
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-06.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-06.txt
deleted file mode 100644
index 0120363acc..0000000000
--- a/doc/protocol/draft-ietf-tls-openpgp-keys-06.txt
+++ /dev/null
@@ -1,582 +0,0 @@
-
-TLS Working Group                                     N. Mavroyanopoulos
-Internet-Draft                                          January 25, 2005
-Expires: July 26, 2005
-
-               Using OpenPGP keys for TLS authentication
-                     draft-ietf-tls-openpgp-keys-06
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 26, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This memo proposes extensions to the TLS protocol to support the
-   OpenPGP trust model and keys.  The extensions discussed here include
-   a certificate type negotiation mechanism, and the required
-   modifications to the TLS Handshake Protocol.
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 1]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Extension Type . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Changes to the Handshake Message Contents  . . . . . . . . . .  5
-     3.1   Client Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.2   Server Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.3   Server Certificate . . . . . . . . . . . . . . . . . . . .  6
-     3.4   Certificate request  . . . . . . . . . . . . . . . . . . .  7
-     3.5   Client certificate . . . . . . . . . . . . . . . . . . . .  7
-     3.6   Server key exchange  . . . . . . . . . . . . . . . . . . .  8
-     3.7   Certificate verify . . . . . . . . . . . . . . . . . . . .  8
-     3.8   Finished . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   4.  Cipher suites  . . . . . . . . . . . . . . . . . . . . . . . .  9
-   5.  Internationalization Considerations  . . . . . . . . . . . . . 10
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.1   Normative References . . . . . . . . . . . . . . . . . . . . 12
-   7.2   Informative References . . . . . . . . . . . . . . . . . . . 12
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
-   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
-       Intellectual Property and Copyright Statements . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 2]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-1.  Introduction
-
-   At the time of writing, TLS [1] uses the PKIX [6] infrastructure, to
-   provide certificate services.  Currently the PKIX protocols are
-   limited to a hierarchical key management and as a result,
-   applications which follow different - non hierarchical - trust
-   models, like the "web of trust" model, could not be benefited by TLS.
-
-   OpenPGP keys (sometimes called OpenPGP certificates), provide
-   security services for electronic communications.  They are widely
-   deployed, especially in electronic mail applications, provide public
-   key authentication services, and allow distributed key management.
-
-   This document will extend the TLS protocol to support OpenPGP keys
-   and trust model using the existing TLS cipher suites.  In brief this
-   would be achieved by adding a negotiation of the certificate type in
-   addition to the normal handshake negotiations.  Then the required
-   modifications to the handshake messages, in order to hold OpenPGP
-   keys as well, will be described.  The the normal handshake procedure
-   with X.509 certificates will not be altered, to preserve
-   compatibility with existing TLS servers and clients.
-
-   This document uses the same notation used in the TLS Protocol
-   specification.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 3]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-2.  Extension Type
-
-   A new value, "cert_type(7)", is added to the enumerated
-   ExtensionType, defined in TLSEXT [3].  This value is used as the
-   extension number for the extensions in both the client hello message
-   and the server hello message.  This new extension type will be used
-   for certificate type negotiation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 4]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-3.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP keys are to be used for authentication.
-
-3.1  Client Hello
-
-   In order to indicate the support of multiple certificate types
-   clients will include an extension of type "cert_type" to the extended
-   client hello message.  The hello extension mechanism is described in
-   TLSEXT [3].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension MAY be
-   omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension will contain a
-   CertificateTypeExtension structure.
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-3.2  Server Hello
-
-   Servers that receive an extended client hello containing the
-   "cert_type" extension, and have chosen a cipher suite that supports
-   certificates, then they MUST select a certificate type from the
-   certificate_types field in the extended client hello, or terminate
-   the connection with a fatal alert of type "unsupported_certificate".
-
-   The certificate type selected by the server, is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message, using an extension of type "cert_type".
-   Servers that only support X.509 certificates MAY omit including the
-   "cert_type" extension in the extended server hello.
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 5]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-3.3  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated then it is required to
-   present an OpenPGP key in the Certificate message.  The OpenPGP key
-   must contain a public key that matches the selected key exchange
-   algorithm, as shown below.
-
-      Key Exchange Algorithm  OpenPGP Key Type
-
-      RSA                     RSA public key which can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key.
-
-      DHE_RSA                 RSA public key which can be used for
-                              signing.
-
-   An OpenPGP public key appearing in the Certificate message will be
-   sent using the binary OpenPGP format.  The term public key is used to
-   describe a composition of OpenPGP packets to form a block of data
-   which contains all information needed by the peer.  This includes
-   public key packets, user ID packets and all the fields described in
-   "Transferable Public Keys" section in OpenPGP [2].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire key.  The process of fingerprint generation is
-   described in OpenPGP [2].  The peer shall respond with a
-   "certificate_unobtainable" fatal alert if the key with the given key
-   fingerprint cannot be found.  The "certificate_unobtainable" fatal
-   alert is defined in section 4 of TLSEXT [3].
-
-   If the key is not valid, expired, revoked, corrupt, the appropriate
-   fatal alert message is sent from section A.3 of the TLS
-   specification.  If a key is valid and neither expired nor revoked, it
-   is accepted by the protocol.  The key validation procedure is a local
-   matter outside the scope of this document.
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 6]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-      enum {
-           key_fingerprint (0), key (1), (255)
-      } PGPKeyDescriptorType;
-
-      opaque PGPKeyFingerprint<16..20>;
-
-      opaque PGPKey<0..2^24-1>;
-
-      struct {
-           PGPKeyDescriptorType descriptorType;
-           select (descriptorType) {
-                case key_fingerprint: PGPKeyFingerprint;
-                case key: PGPKey;
-           }
-      } Certificate;
-
-3.4  Certificate request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However the structure of this message has been
-   modified for OpenPGP keys.  The PGPCertificateRequest structure will
-   only be used if the negotiated certificate type is OpenPGP.
-
-      enum {
-          rsa_sign(1), dss_sign(2), (255)
-      } ClientCertificateParamsType;
-
-      struct {
-          ClientCertificateParamsType certificate_params_types<1..2^8-1>;
-      } PGPCertificateRequest;
-
-   The certificate_params_types is a list of accepted client certificate
-   parameter types, sorted in order of the server's preference.
-
-3.5  Client certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP keys have been selected, and no key is available
-   from the client, then a Certificate that contains an empty PGPKey
-   should be sent.  The server may respond with a "handshake_failure"
-   fatal alert if client authentication is required.  This transaction
-   follows the TLS specification.
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 7]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-3.6  Server key exchange
-
-   The server key exchange message for OpenPGP keys is identical to the
-   TLS specification.
-
-3.7  Certificate verify
-
-   The certificate verify message for OpenPGP keys is identical to the
-   TLS specification.
-
-3.8  Finished
-
-   The finished message for OpenPGP keys is identical to the description
-   in the specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 8]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-4.  Cipher suites
-
-   No new cipher suites are required to use OpenPGP keys.  OpenPGP keys
-   can be combined with existing cipher suites defined in TLS [1],
-   except the ones marked as "Exportable".  Exportable cipher suites
-   SHOULD NOT be used with OpenPGP keys.
-
-   Some additional cipher suites are defined here in order to support
-   algorithms which are defined in OpenPGP [2], and are always available
-   in OpenPGP implementations but are not present in TLS [1].
-
-      CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD160 = { 0x00, 0x72 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD160  = { 0x00, 0x73 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD160  = { 0x00, 0x74 };
-      CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD160 = { 0x00, 0x77 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD160  = { 0x00, 0x78 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD160  = { 0x00, 0x79 };
-      CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD160     = { 0x00, 0x7C };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD160      = { 0x00, 0x7D };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD160      = { 0x00, 0x7E };
-
-   All of the above cipher suites use either the AES [5] and 3DES block
-   ciphers in CBC mode.  The choice of hash is the RIPEMD-160 [4]
-   algorithm.  Implementations are not required to support the above
-   cipher suites.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                  [Page 9]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-5.  Internationalization Considerations
-
-   All the methods defined in this document are represented as machine
-   readable structures.  As such issues of human internationalization
-   and localization are not introduced.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                 [Page 10]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-6.  Security Considerations
-
-   As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
-   parsers.  Care must be taken to make those parsers safe against
-   maliciously modified keys, that may crash or modify the application's
-   memory.
-
-   Security considerations about the use of the web of trust or the
-   verification procedure are outside the scope of this document, since
-   they are considered a local policy matter.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                 [Page 11]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-7.  References
-
-7.1  Normative References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-        1999.
-
-   [2]  Callas, J., Donnerhacke, L., Finey, H. and R. Thayer, "OpenPGP
-        Message Format", RFC 2440, November 1998.
-
-   [3]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
-        Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [4]  Dobbertin, H., Bosselaers, A. and B. Preneel, "RIPEMD-160: A
-        Strengthened Version of RIPEMD", April 1996.
-
-   [5]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-        Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-7.2  Informative References
-
-   [6]  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", RFC 3280, April 2002.
-
-   [7]  "Recommendation X.509: The Directory - Authentication
-        Framework", 1988.
-
-Author's Address
-
-   Nikos Mavroyanopoulos
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                 [Page 12]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-Appendix A.  Acknowledgements
-
-   The author wishes to thank Werner Koch, David Taylor and Timo Schulz
-   for their suggestions on improving this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavroyanopoulos          Expires July 26, 2005                 [Page 13]
-Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-Mavroyanopoulos          Expires July 26, 2005                 [Page 14]
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-07.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-07.txt
deleted file mode 100644
index 39ea78b921..0000000000
--- a/doc/protocol/draft-ietf-tls-openpgp-keys-07.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-TLS Working Group                                   N. Mavrogiannopoulos
-Internet-Draft                                    Independent Consultant
-Expires: July 1, 2006                                  December 28, 2005
-
-
-               Using OpenPGP keys for TLS authentication
-                     draft-ietf-tls-openpgp-keys-07
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 1, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This memo proposes extensions to the TLS protocol to support the
-   OpenPGP trust model and keys.  The extensions discussed here include
-   a certificate type negotiation mechanism, and the required
-   modifications to the TLS Handshake Protocol.
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 1]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Extension Type . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Changes to the Handshake Message Contents  . . . . . . . . . .  5
-     3.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.2.  Server Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.3.  Server Certificate . . . . . . . . . . . . . . . . . . . .  6
-     3.4.  Certificate request  . . . . . . . . . . . . . . . . . . .  7
-     3.5.  Client certificate . . . . . . . . . . . . . . . . . . . .  7
-     3.6.  Server key exchange  . . . . . . . . . . . . . . . . . . .  8
-     3.7.  Certificate verify . . . . . . . . . . . . . . . . . . . .  8
-     3.8.  Finished . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   4.  Cipher suites  . . . . . . . . . . . . . . . . . . . . . . . .  9
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
-     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 12
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   Intellectual Property and Copyright Statements . . . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 2]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-1.  Introduction
-
-   At the time of writing, TLS [1] uses the PKIX [4] infrastructure, to
-   provide certificate services.  Currently the PKIX protocols are
-   limited to a hierarchical key management and as a result,
-   applications which follow different - non hierarchical - trust
-   models, like the "web of trust" model, could not be benefited by TLS.
-
-   OpenPGP keys (sometimes called OpenPGP certificates), provide
-   security services for electronic communications.  They are widely
-   deployed, especially in electronic mail applications, provide public
-   key authentication services, and allow distributed key management.
-
-   This document will extend the TLS protocol to support OpenPGP keys
-   and trust model using the existing TLS cipher suites.  In brief this
-   would be achieved by adding a negotiation of the certificate type in
-   addition to the normal handshake negotiations.  Then the required
-   modifications to the handshake messages, in order to hold OpenPGP
-   keys as well, will be described.  The the normal handshake procedure
-   with X.509 certificates will not be altered, to preserve
-   compatibility with existing TLS servers and clients.
-
-   This document uses the same notation used in the TLS Protocol
-   specification.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 3]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-2.  Extension Type
-
-   A new value, "cert_type(7)", is added to the enumerated
-   ExtensionType, defined in TLSEXT [3].  This value is used as the
-   extension number for the extensions in both the client hello message
-   and the server hello message.  This new extension type will be used
-   for certificate type negotiation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 4]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-3.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP keys are to be used for authentication.
-
-3.1.  Client Hello
-
-   In order to indicate the support of multiple certificate types
-   clients will include an extension of type "cert_type" to the extended
-   client hello message.  The hello extension mechanism is described in
-   TLSEXT [3].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension MAY be
-   omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension will contain a
-   CertificateTypeExtension structure.
-
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-3.2.  Server Hello
-
-   Servers that receive an extended client hello containing the
-   "cert_type" extension, and have chosen a cipher suite that supports
-   certificates, then they MUST select a certificate type from the
-   certificate_types field in the extended client hello, or terminate
-   the connection with a fatal alert of type "unsupported_certificate".
-
-   The certificate type selected by the server, is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message, using an extension of type "cert_type".
-   Servers that only support X.509 certificates MAY omit including the
-   "cert_type" extension in the extended server hello.
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 5]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-3.3.  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated then it is required to
-   present an OpenPGP key in the Certificate message.  The OpenPGP key
-   must contain a public key that matches the selected key exchange
-   algorithm, as shown below.
-
-
-      Key Exchange Algorithm  OpenPGP Key Type
-
-      RSA                     RSA public key which can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key.
-
-      DHE_RSA                 RSA public key which can be used for
-                              signing.
-
-   An OpenPGP public key appearing in the Certificate message will be
-   sent using the binary OpenPGP format.  The term public key is used to
-   describe a composition of OpenPGP packets to form a block of data
-   which contains all information needed by the peer.  This includes
-   public key packets, user ID packets and all the fields described in
-   "Transferable Public Keys" section in OpenPGP [2].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire key.  The process of fingerprint generation is
-   described in OpenPGP [2].  The peer shall respond with a
-   "certificate_unobtainable" fatal alert if the key with the given key
-   fingerprint cannot be found.  The "certificate_unobtainable" fatal
-   alert is defined in section 4 of TLSEXT [3].
-
-   If the key is not valid, expired, revoked, corrupt, the appropriate
-   fatal alert message is sent from section A.3 of the TLS
-   specification.  If a key is valid and neither expired nor revoked, it
-   is accepted by the protocol.  The key validation procedure is a local
-   matter outside the scope of this document.
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 6]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-      enum {
-           key_fingerprint (0), key (1), (255)
-      } PGPKeyDescriptorType;
-
-      opaque PGPKeyFingerprint<16..20>;
-
-      opaque PGPKey<0..2^24-1>;
-
-      struct {
-           PGPKeyDescriptorType descriptorType;
-           select (descriptorType) {
-                case key_fingerprint: PGPKeyFingerprint;
-                case key: PGPKey;
-           }
-      } Certificate;
-
-3.4.  Certificate request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However the structure of this message has been
-   modified for OpenPGP keys.  The PGPCertificateRequest structure will
-   only be used if the negotiated certificate type is OpenPGP.
-
-
-      enum {
-          rsa_sign(1), dss_sign(2), (255)
-      } ClientCertificateParamsType;
-
-      struct {
-          ClientCertificateParamsType certificate_params_types<1..2^8-1>;
-      } PGPCertificateRequest;
-
-   The certificate_params_types is a list of accepted client certificate
-   parameter types, sorted in order of the server's preference.
-
-3.5.  Client certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP keys have been selected, and no key is available
-   from the client, then a Certificate that contains an empty PGPKey
-   should be sent.  The server may respond with a "handshake_failure"
-   fatal alert if client authentication is required.  This transaction
-   follows the TLS specification.
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 7]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-3.6.  Server key exchange
-
-   The server key exchange message for OpenPGP keys is identical to the
-   TLS specification.
-
-3.7.  Certificate verify
-
-   The certificate verify message for OpenPGP keys is identical to the
-   TLS specification.
-
-3.8.  Finished
-
-   The finished message for OpenPGP keys is identical to the description
-   in the specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 8]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-4.  Cipher suites
-
-   No new cipher suites are required to use OpenPGP keys.  OpenPGP keys
-   can be combined with existing cipher suites defined in TLS [1],
-   except the ones marked as "Exportable".  Exportable cipher suites
-   SHOULD NOT be used with OpenPGP keys.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                  [Page 9]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-5.  Security Considerations
-
-   As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
-   parsers.  Care must be taken to make those parsers safe against
-   maliciously modified keys, that could cause arbitrary code execution.
-
-   Security considerations about the use of the web of trust or the
-   verification procedure are outside the scope of this document and
-   they are considered an issue to be handled by local policy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                 [Page 10]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-6.  References
-
-6.1.  Normative References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-        January 1999.
-
-   [2]  Callas, J., Donnerhacke, L., Finey, H., and R. Thayer, "OpenPGP
-        Message Format", RFC 2440, November 1998.
-
-   [3]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-        T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-6.2.  Informative References
-
-   [4]  Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", RFC 3280, April 2002.
-
-   [5]  "Recommendation X.509: The Directory - Authentication
-        Framework", 1988.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                 [Page 11]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-Appendix A.  Acknowledgements
-
-   The author wishes to thank Werner Koch, David Taylor and Timo Schulz
-   for their suggestions on improving this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                 [Page 12]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-Author's Address
-
-   Nikos Mavrogiannopoulos
-   Independent Consultant
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                 [Page 13]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication  December 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Mavrogiannopoulos         Expires July 1, 2006                 [Page 14]
-
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-08.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-08.txt
deleted file mode 100644
index 9e52fd2189..0000000000
--- a/doc/protocol/draft-ietf-tls-openpgp-keys-08.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-TLS Working Group                                   N. Mavrogiannopoulos
-Internet-Draft                                    Independent Consultant
-Expires: July 19, 2006                                  January 15, 2006
-
-
-               Using OpenPGP keys for TLS authentication
-                     draft-ietf-tls-openpgp-keys-08
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo proposes extensions to the TLS protocol to support the
-   OpenPGP trust model and keys.  The extensions discussed here include
-   a certificate type negotiation mechanism, and the required
-   modifications to the TLS Handshake Protocol.
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 1]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Extension Type . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Certificate Type . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Changes to the Handshake Message Contents  . . . . . . . . . .  5
-     3.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.2.  Server Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.3.  Server Certificate . . . . . . . . . . . . . . . . . . . .  6
-     3.4.  Certificate request  . . . . . . . . . . . . . . . . . . .  7
-     3.5.  Client certificate . . . . . . . . . . . . . . . . . . . .  7
-     3.6.  Server key exchange  . . . . . . . . . . . . . . . . . . .  8
-     3.7.  Certificate verify . . . . . . . . . . . . . . . . . . . .  8
-     3.8.  Finished . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   4.  Cipher suites  . . . . . . . . . . . . . . . . . . . . . . . .  9
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
-     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 12
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   Intellectual Property and Copyright Statements . . . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 2]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-1.  Introduction
-
-   At the time of writing, TLS [1] uses the PKIX [4] infrastructure, to
-   provide certificate services.  Currently the PKIX protocols are
-   limited to a hierarchical key management and as a result,
-   applications which follow different - non hierarchical - trust
-   models, like the "web of trust" model, could not be benefited by TLS.
-
-   OpenPGP keys (sometimes called OpenPGP certificates), provide
-   security services for electronic communications.  They are widely
-   deployed, especially in electronic mail applications, provide public
-   key authentication services, and allow distributed key management.
-
-   This document will extend the TLS protocol to support OpenPGP keys
-   and trust model using the existing TLS cipher suites.  In brief this
-   would be achieved by adding a negotiation of the certificate type in
-   addition to the normal handshake negotiations.  Then the required
-   modifications to the handshake messages, in order to hold OpenPGP
-   keys as well, will be described.  The normal handshake procedure with
-   X.509 certificates will not be altered, to preserve compatibility
-   with existing TLS servers and clients.
-
-   This document uses the same notation used in the TLS [1] Protocol
-   specification.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 3]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-2.  Extension Type
-
-   A new value, "cert_type(7)", is added to the enumerated
-   ExtensionType, defined in TLSEXT [3].  This value is used as the
-   extension number for the extensions in both the client hello message
-   and the server hello message.
-
-   The new extension type will be used for certificate type negotiation
-   and contains an indicator of the type of the certificate to be used.
-
-2.1.  Certificate Type
-
-   As it can be seen from the CertificateType type at Section 3.1 below,
-   the allowed certificate types are up to 256.  These are segmented in
-   the following way:
-
-   1.  Values 0 (zero) and 1 are defined in this document.
-
-   2.  Values from 2 through 223 decimal (0xDF) inclusive are reserved
-       to be defined by other documents or a future version of this
-       document.
-
-   3.  Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-       inclusive are reserved for private use.  Interoperability with
-       these certificate types is a local matter.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 4]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-3.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP keys are to be used for authentication.
-
-3.1.  Client Hello
-
-   In order to indicate the support of multiple certificate types
-   clients will include an extension of type "cert_type" to the extended
-   client hello message.  The hello extension mechanism is described in
-   TLSEXT [3].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension SHOULD
-   be omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension will contain a
-   CertificateTypeExtension structure.
-
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-3.2.  Server Hello
-
-   Servers that receive an extended client hello containing the
-   "cert_type" extension, and have chosen a cipher suite that supports
-   certificates, then they MUST select a certificate type from the
-   certificate_types field in the extended client hello, or terminate
-   the connection with a fatal alert of type "unsupported_certificate".
-
-   The certificate type selected by the server, is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message, using an extension of type "cert_type".
-   Servers that only support X.509 certificates MAY omit including the
-   "cert_type" extension in the extended server hello.
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 5]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-3.3.  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated then it is required to
-   present an OpenPGP key in the Certificate message.  The OpenPGP key
-   must contain a public key that matches the selected key exchange
-   algorithm, as shown below.
-
-
-      Key Exchange Algorithm  OpenPGP Key Type
-
-      RSA                     RSA public key which can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key.
-
-      DHE_RSA                 RSA public key which can be used for
-                              signing.
-
-   An OpenPGP public key appearing in the Certificate message will be
-   sent using the binary OpenPGP format.  The term public key is used to
-   describe a composition of OpenPGP packets to form a block of data
-   which contains all information needed by the peer.  This includes
-   public key packets, user ID packets and all the fields described in
-   "Transferable Public Keys" section in OpenPGP [2].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire key.  The process of fingerprint generation is
-   described in OpenPGP [2].  The peer shall respond with a
-   "certificate_unobtainable" fatal alert if the key with the given key
-   fingerprint cannot be found.  The "certificate_unobtainable" fatal
-   alert is defined in section 4 of TLSEXT [3].
-
-   If the key is not valid, expired, revoked, corrupt, the appropriate
-   fatal alert message is sent from section A.3 of the TLS
-   specification.  If a key is valid and neither expired nor revoked, it
-   is accepted by the protocol.  The key validation procedure is a local
-   matter outside the scope of this document.
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 6]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-      enum {
-           key_fingerprint (0), key (1), (255)
-      } PGPKeyDescriptorType;
-
-      opaque PGPKeyFingerprint<16..20>;
-
-      opaque PGPKey<0..2^24-1>;
-
-      struct {
-           PGPKeyDescriptorType descriptorType;
-           select (descriptorType) {
-                case key_fingerprint: PGPKeyFingerprint;
-                case key: PGPKey;
-           }
-      } Certificate;
-
-3.4.  Certificate request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However the structure of this message has been
-   modified for OpenPGP keys.  The PGPCertificateRequest structure will
-   only be used if the negotiated certificate type is OpenPGP.
-
-
-     enum {
-         rsa_sign(1), dss_sign(2), (255)
-     } ClientCertificateParamsType;
-
-      struct {
-         ClientCertificateParamsType certificate_params_types<1..2^8-1>;
-     } PGPCertificateRequest;
-
-   The certificate_params_types is a list of accepted client certificate
-   parameter types, sorted in order of the server's preference.
-
-3.5.  Client certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP keys have been selected, and no key is available
-   from the client, then a Certificate that contains an empty PGPKey
-   should be sent.  The server may respond with a "handshake_failure"
-   fatal alert if client authentication is required.  This transaction
-   follows the TLS specification.
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 7]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-3.6.  Server key exchange
-
-   The server key exchange message for OpenPGP keys is identical to the
-   TLS specification.
-
-3.7.  Certificate verify
-
-   The certificate verify message for OpenPGP keys is identical to the
-   TLS specification.
-
-3.8.  Finished
-
-   The finished message for OpenPGP keys is identical to the description
-   in the specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 8]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-4.  Cipher suites
-
-   No new cipher suites are required to use OpenPGP keys.  OpenPGP keys
-   can be combined with existing cipher suites defined in TLS [1],
-   except the ones marked as "Exportable".  Exportable cipher suites
-   SHOULD NOT be used with OpenPGP keys.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                 [Page 9]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-5.  Security Considerations
-
-   As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
-   parsers.  Care must be taken to make those parsers safe against
-   maliciously modified keys, that could cause arbitrary code execution.
-
-   Security considerations about the use of the web of trust or the
-   verification procedure are outside the scope of this document and
-   they are considered an issue to be handled by local policy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                [Page 10]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-6.  References
-
-6.1.  Normative References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-        January 1999.
-
-   [2]  Callas, J., Donnerhacke, L., Finey, H., and R. Thayer, "OpenPGP
-        Message Format", RFC 2440, November 1998.
-
-   [3]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-        T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-6.2.  Informative References
-
-   [4]  Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and Certificate Revocation
-        List (CRL) Profile", RFC 3280, April 2002.
-
-   [5]  "Recommendation X.509: The Directory - Authentication
-        Framework", 1988.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                [Page 11]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-Appendix A.  Acknowledgements
-
-   This document was based on earlier work made by Will Price and
-   Michael Elkins.
-
-   The author wishes to thank Werner Koch, David Taylor and Timo Schulz
-   for their suggestions on improving this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                [Page 12]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-Author's Address
-
-   Nikos Mavrogiannopoulos
-   Independent Consultant
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                [Page 13]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication   January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Mavrogiannopoulos         Expires July 19, 2006                [Page 14]
-
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-09.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-09.txt
deleted file mode 100644
index 84d6393f6a..0000000000
--- a/doc/protocol/draft-ietf-tls-openpgp-keys-09.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-TLS Working Group                                   N. Mavrogiannopoulos
-Internet-Draft                                               Independent
-Expires: November 16, 2006                                  May 15, 2006
-
-
-               Using OpenPGP keys for TLS authentication
-                     draft-ietf-tls-openpgp-keys-09
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on November 16, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo proposes extensions to the TLS protocol to support the
-   OpenPGP trust model and keys.  The extensions discussed here include
-   a certificate type negotiation mechanism, and the required
-   modifications to the TLS Handshake Protocol.
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 1]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-1.  Introduction
-
-   At the time of writing, TLS [TLS] uses the PKIX [PKIX]
-   infrastructure, to provide certificate services.  Currently the PKIX
-   protocols are limited to a hierarchical key management and as a
-   result, applications which follow different - non hierarchical -
-   trust models, could not be benefited by TLS.
-
-   OpenPGP keys (sometimes called OpenPGP certificates), provide
-   security services for electronic communications.  They are widely
-   deployed, especially in electronic mail applications, provide public
-   key authentication services, allow distributed key management and can
-   be used with a non hierarchical trust model called the "web of trust"
-   [WOT].
-
-   This document will extend the TLS protocol to support OpenPGP keys
-   using the existing TLS cipher suites.  In brief this would be
-   achieved by adding a negotiation of the certificate type in addition
-   to the normal handshake negotiations.  Then the required
-   modifications to the handshake messages, in order to hold OpenPGP
-   keys as well, will be described.  The normal handshake procedure with
-   X.509 certificates is not altered, to preserve compatibility with
-   existing TLS servers and clients.
-
-   This document uses the same notation used in the TLS Protocol
-   specification [TLS].
-
-   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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 2]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-2.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP keys are to be used for authentication.
-
-2.1.  Client Hello
-
-   In order to indicate the support of multiple certificate types
-   clients will include an extension of type "cert_type" (see Section 4)
-   to the extended client hello message.  The hello extension mechanism
-   is described in [TLSEXT].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension MUST be
-   omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension will contain a
-   CertificateTypeExtension structure.
-
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-   No new cipher suites are required to use OpenPGP keys.  All existing
-   cipher suites defined in [TLS] that support a compatible, with the
-   key, key exchange method can be used in combination with OpenPGP
-   keys.
-
-2.2.  Server Hello
-
-   Servers that receive an extended client hello containing the
-   "cert_type" extension, and have chosen a cipher suite that supports
-   certificates, they MUST select a certificate type from the
-   certificate_types field in the extended client hello, or terminate
-   the connection with a fatal alert of type "unsupported_certificate".
-
-   The certificate type selected by the server, is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message, using an extension of type "cert_type".
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 3]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-   Servers that only support X.509 certificates MAY omit including the
-   "cert_type" extension in the extended server hello.
-
-2.3.  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated then it is required to
-   present an OpenPGP key in the Certificate message.  The OpenPGP key
-   must contain a public key that matches the selected key exchange
-   algorithm, as shown below.
-
-
-      Key Exchange Algorithm  OpenPGP Key Type
-
-      RSA                     RSA public key which can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key.
-
-      DHE_RSA                 RSA public key which can be used for
-                              signing.
-
-   An OpenPGP public key appearing in the Certificate message will be
-   sent using the binary OpenPGP format.  The term public key is used to
-   describe a composition of OpenPGP packets to form a block of data
-   which contains all information needed by the peer.  This includes
-   public key packets, user ID packets and all the fields described in
-   section 10.1 of [OpenPGP].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire key.  The process of fingerprint generation is
-   described in section 11.2 of [OpenPGP].  The peer shall respond with
-   a "certificate_unobtainable" fatal alert if the key with the given
-   key fingerprint cannot be found.  The "certificate_unobtainable"
-   fatal alert is defined in section 4 of [TLSEXT].
-
-   If the key is not valid, expired, revoked, corrupt, the appropriate
-   fatal alert message is sent from section A.3 of the TLS
-   specification.  If a key is valid and neither expired nor revoked, it
-   is accepted by the protocol.  The key validation procedure is a local
-   matter outside the scope of this document.
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 4]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-      enum {
-           key_fingerprint (0), key (1), (255)
-      } PGPKeyDescriptorType;
-
-      opaque PGPKeyFingerprint<16..20>;
-
-      opaque PGPKey<0..2^24-1>;
-
-      struct {
-           PGPKeyDescriptorType descriptorType;
-           select (descriptorType) {
-                case key_fingerprint: PGPKeyFingerprint;
-                case key: PGPKey;
-           }
-      } Certificate;
-
-2.4.  Certificate request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However if this message is sent, and the negotiated
-   certificate type is OpenPGP, the "certificate_authorities" list MUST
-   be empty.
-
-2.5.  Client certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP keys have been selected, and no key is available
-   from the client, then a Certificate that contains an empty PGPKey
-   should be sent.  The server may respond with a "handshake_failure"
-   fatal alert if client authentication is required.
-
-2.6.  Other Handshake messages
-
-   The rest of the handshake messages such as the server key exchange,
-   the certificate verify and the finished messages are identical to the
-   TLS specification.
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 5]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-3.  Security Considerations
-
-   As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
-   parsers.  Care must be taken to make those parsers safe against
-   maliciously modified keys, that could cause arbitrary code execution.
-
-   Security considerations about the use of the web of trust or the
-   verification procedure are outside the scope of this document and
-   they are considered an issue to be handled by local policy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 6]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-4.  IANA Considerations
-
-   This document defines a new TLS extension, "cert_type", assigned a
-   value of TBD-BY-IANA (the value 7 is suggested) from the TLS
-   ExtensionType registry defined in [TLSEXT].  This value is used as
-   the extension number for the extensions in both the client hello
-   message and the server hello message.  The new extension type will be
-   used for certificate type negotiation.
-
-   To accommodate for future additions to the TLS certificate types a
-   new registry is established in this document, to be maintained by
-   IANA.  The registry is segmented in the following way:
-
-   1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
-
-   2.  Values from 2 through 223 decimal inclusive are assigned via IETF
-       Consensus [RFC2434].
-
-   3.  Values from 224 decimal through 255 decimal inclusive are
-       reserved for private use [RFC2434].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 7]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-5.  References
-
-5.1.  Normative References
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", RFC 4346, April 2006.
-
-   [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., and R. Thayer,
-              "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", RFC 2434,
-              October 1998.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-5.2.  Informative References
-
-   [PKIX]  Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509
-           Public Key Infrastructure Certificate and Certificate
-           Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [WOT]   Abdul-Rahman, A., "The PGP Trust Model", EDI Forum: The
-           Journal of Electronic Commerce, April 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 8]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-Appendix A.  Acknowledgements
-
-   This document was based on earlier work made by Will Price and
-   Michael Elkins.
-
-   The author wishes to thank Werner Koch, David Taylor, Timo Schulz and
-   Pasi Eronen for their suggestions on improving this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006               [Page 9]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-Author's Address
-
-   Nikos Mavrogiannopoulos
-   Independent
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006              [Page 10]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication       May 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Mavrogiannopoulos       Expires November 16, 2006              [Page 11]
-
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-10.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-10.txt
deleted file mode 100644
index a382b26f98..0000000000
--- a/doc/protocol/draft-ietf-tls-openpgp-keys-10.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-TLS Working Group                                   N. Mavrogiannopoulos
-Internet-Draft                                               Independent
-Expires: December 7, 2006                                   June 5, 2006
-
-
-               Using OpenPGP keys for TLS authentication
-                     draft-ietf-tls-openpgp-keys-10
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 7, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo proposes extensions to the TLS protocol to support the
-   OpenPGP trust model and keys.  The extensions discussed here include
-   a certificate type negotiation mechanism, and the required
-   modifications to the TLS Handshake Protocol.
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 1]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-1.  Introduction
-
-   At the time of writing, TLS [TLS] uses the PKIX [PKIX]
-   infrastructure, to provide certificate services.  Currently the PKIX
-   protocols are limited to a hierarchical key management and as a
-   result, applications which follow different - non hierarchical -
-   trust models, could not be benefited by TLS.
-
-   OpenPGP keys (sometimes called OpenPGP certificates), provide
-   security services for electronic communications.  They are widely
-   deployed, especially in electronic mail applications, provide public
-   key authentication services, allow distributed key management and can
-   be used with a non hierarchical trust model called the "web of trust"
-   [WOT].
-
-   This document will extend the TLS protocol to support OpenPGP keys
-   using the existing TLS cipher suites.  In brief this would be
-   achieved by adding a negotiation of the certificate type in addition
-   to the normal handshake negotiations.  Then the required
-   modifications to the handshake messages, in order to hold OpenPGP
-   keys as well, will be described.  The normal handshake procedure with
-   X.509 certificates is not altered, to preserve compatibility with
-   existing TLS servers and clients.
-
-   This document uses the same notation used in the TLS Protocol
-   specification [TLS].
-
-   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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 2]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-2.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP keys are to be used for authentication.
-
-2.1.  Client Hello
-
-   In order to indicate the support of multiple certificate types
-   clients will include an extension of type "cert_type" (see Section 4)
-   to the extended client hello message.  The hello extension mechanism
-   is described in [TLSEXT].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension MUST be
-   omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension will contain a
-   CertificateTypeExtension structure.
-
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-   No new cipher suites are required to use OpenPGP keys.  All existing
-   cipher suites that support a compatible with the key, key exchange
-   method can be used in combination with OpenPGP keys.
-
-2.2.  Server Hello
-
-   Servers that receive an extended client hello containing the
-   "cert_type" extension, and have chosen a cipher suite that supports
-   certificates, they MUST select a certificate type from the
-   certificate_types field in the extended client hello, or terminate
-   the connection with a fatal alert of type "unsupported_certificate".
-
-   The certificate type selected by the server, is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message, using an extension of type "cert_type".
-   Servers that only support X.509 certificates MAY omit including the
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 3]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-   "cert_type" extension in the extended server hello.
-
-2.3.  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated then it is required to
-   present an OpenPGP key in the Certificate message.  The OpenPGP key
-   must contain a public key that matches the selected key exchange
-   algorithm, as shown below.
-
-
-      Key Exchange Algorithm  OpenPGP Key Type
-
-      RSA                     RSA public key which can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key.
-
-      DHE_RSA                 RSA public key which can be used for
-                              signing.
-
-   An OpenPGP public key appearing in the Certificate message will be
-   sent using the binary OpenPGP format.  The term public key is used to
-   describe a composition of OpenPGP packets to form a block of data
-   which contains all information needed by the peer.  This includes
-   public key packets, user ID packets and all the fields described in
-   section 10.1 of [OpenPGP].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire key.  The process of fingerprint generation is
-   described in section 11.2 of [OpenPGP].  The peer shall respond with
-   a "certificate_unobtainable" fatal alert if the key with the given
-   key fingerprint cannot be found.  The "certificate_unobtainable"
-   fatal alert is defined in section 4 of [TLSEXT].
-
-   If the key is not valid, expired, revoked, corrupt, the appropriate
-   fatal alert message is sent from section A.3 of the TLS
-   specification.  If a key is valid and neither expired nor revoked, it
-   is accepted by the protocol.  The key validation procedure is a local
-   matter outside the scope of this document.
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 4]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-      enum {
-           key_fingerprint (0), key (1), (255)
-      } PGPKeyDescriptorType;
-
-      opaque PGPKeyFingerprint<16..20>;
-
-      opaque PGPKey<0..2^24-1>;
-
-      struct {
-           PGPKeyDescriptorType descriptorType;
-           select (descriptorType) {
-                case key_fingerprint: PGPKeyFingerprint;
-                case key: PGPKey;
-           }
-      } Certificate;
-
-2.4.  Certificate request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However if this message is sent, and the negotiated
-   certificate type is OpenPGP, the "certificate_authorities" list MUST
-   be empty.
-
-2.5.  Client certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP keys have been selected, and no key is available
-   from the client, then a Certificate that contains an empty PGPKey
-   should be sent.  The server may respond with a "handshake_failure"
-   fatal alert if client authentication is required.
-
-2.6.  Other Handshake messages
-
-   The rest of the handshake messages such as the server key exchange,
-   the certificate verify and the finished messages are identical to the
-   TLS specification.
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 5]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-3.  Security Considerations
-
-   As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
-   parsers.  Care must be taken to make those parsers safe against
-   maliciously modified keys, that could cause arbitrary code execution.
-
-   Security considerations about the use of the web of trust or the
-   verification procedure are outside the scope of this document and
-   they are considered an issue to be handled by local policy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 6]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-4.  IANA Considerations
-
-   This document defines a new TLS extension, "cert_type", assigned a
-   value of TBD-BY-IANA (the value 7 is suggested) from the TLS
-   ExtensionType registry defined in [TLSEXT].  This value is used as
-   the extension number for the extensions in both the client hello
-   message and the server hello message.  The new extension type will be
-   used for certificate type negotiation.
-
-   The "cert_type" extension contains an 8-bit CertificateType field,
-   for which a new registry, named "TLS Certificate Types", is
-   established in this document, to be maintained by IANA.  The registry
-   is segmented in the following way:
-
-   1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
-
-   2.  Values from 2 through 223 decimal inclusive are assigned via IETF
-       Consensus [RFC2434].
-
-   3.  Values from 224 decimal through 255 decimal inclusive are
-       reserved for Private Use [RFC2434].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 7]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-5.  References
-
-5.1.  Normative References
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", RFC 4346, April 2006.
-
-   [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., and R. Thayer,
-              "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", RFC 2434,
-              October 1998.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-5.2.  Informative References
-
-   [PKIX]  Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509
-           Public Key Infrastructure Certificate and Certificate
-           Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [WOT]   Abdul-Rahman, A., "The PGP Trust Model", EDI Forum: The
-           Journal of Electronic Commerce, April 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 8]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-Appendix A.  Acknowledgements
-
-   This document was based on earlier work made by Will Price and
-   Michael Elkins.
-
-   The author wishes to thank Werner Koch, David Taylor, Timo Schulz and
-   Pasi Eronen for their suggestions on improving this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006                [Page 9]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-Author's Address
-
-   Nikos Mavrogiannopoulos
-   Independent
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006               [Page 10]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      June 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Mavrogiannopoulos       Expires December 7, 2006               [Page 11]
-
diff --git a/doc/protocol/draft-ietf-tls-openpgp-keys-11.txt b/doc/protocol/draft-ietf-tls-openpgp-keys-11.txt
deleted file mode 100644
index 084e00c4b5..0000000000
--- a/doc/protocol/draft-ietf-tls-openpgp-keys-11.txt
+++ /dev/null
@@ -1,729 +0,0 @@
-
-
-
-TLS Working Group                                   N. Mavrogiannopoulos
-Internet-Draft                                               Independent
-Expires: February 1, 2007                                  July 31, 2006
-
-
-               Using OpenPGP keys for TLS authentication
-                     draft-ietf-tls-openpgp-keys-11
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on February 1, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo proposes extensions to the TLS protocol to support the
-   OpenPGP key format.  The extensions discussed here include a
-   certificate type negotiation mechanism, and the required
-   modifications to the TLS Handshake Protocol.
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 1]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.  Changes to the Handshake Message Contents  . . . . . . . . . .  5
-     3.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.2.  Server Hello . . . . . . . . . . . . . . . . . . . . . . .  5
-     3.3.  Server Certificate . . . . . . . . . . . . . . . . . . . .  6
-     3.4.  Certificate request  . . . . . . . . . . . . . . . . . . .  7
-     3.5.  Client certificate . . . . . . . . . . . . . . . . . . . .  7
-     3.6.  Other Handshake messages . . . . . . . . . . . . . . . . .  7
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
-     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 2]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-1.  Introduction
-
-   The IETF has two sets of standards for public key certificates, one
-   set for use of X.509 certificates [PKIX] and one for OpenPGP
-   certificates [OpenPGP].  At the time of writing, the TLS [TLS]
-   standards are defined to use only X.509 certificates.  This document
-   specifies a way to negotiate use of OpenPGP certificates for a TLS
-   session, and specifies how to transport OpenPGP certificates via TLS.
-   The proposed extensions are backward compatible with the current TLS
-   specification, so that existing client and server implementations
-   that make use of X.509 certificates are not affected.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 3]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-2.  Terminology
-
-   The term ``OpenPGP key'' is used in this document as in the OpenPGP
-   specification [OpenPGP].  We use the term ``OpenPGP certificate'' to
-   refer to OpenPGP keys that are enabled for authentication.
-
-   This document uses the same notation and terminology used in the TLS
-   Protocol specification [TLS].
-
-   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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 4]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-3.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP certificates are to be used for authentication.
-
-3.1.  Client Hello
-
-   In order to indicate the support of multiple certificate types
-   clients MUST include an extension of type "cert_type" (see Section 5)
-   to the extended client hello message.  The hello extension mechanism
-   is described in [TLSEXT].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension MUST be
-   omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension contains a
-   CertificateTypeExtension structure.
-
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-   No new cipher suites are required to use OpenPGP certificates.  All
-   existing cipher suites that support a compatible, with the key, key
-   exchange method can be used in combination with OpenPGP certificates.
-
-3.2.  Server Hello
-
-   If the server receives a client hello that contains the "cert_type"
-   extension and chooses a cipher suite that requires a certificate,
-   then two outcomes are possible.  The server MUST either select a
-   certificate type from the certificate_types field in the extended
-   client hello or terminate the connection with a fatal alert of type
-   "unsupported_certificate".
-
-   The certificate type selected by the server is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message using an extension of type "cert_type".  Servers
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 5]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-   that only support X.509 certificates MAY omit including the
-   "cert_type" extension in the extended server hello.
-
-3.3.  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated then it is required to
-   present an OpenPGP certificate in the Certificate message.  The
-   certificate must contain a public key that matches the selected key
-   exchange algorithm, as shown below.
-
-
-      Key Exchange Algorithm  OpenPGP Certificate Type
-
-      RSA                     RSA public key which can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key which can be used for
-                              authentication.
-
-      DHE_RSA                 RSA public key which can be used for
-                              authentication.
-
-   An OpenPGP certificate appearing in the Certificate message is sent
-   using the binary OpenPGP format.  The certificate MUST contain all
-   the elements required by Section 10.1 of [OpenPGP].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire certificate.  The process of fingerprint
-   generation is described in section 11.2 of [OpenPGP].  The peer shall
-   respond with a "certificate_unobtainable" fatal alert if the
-   certificate with the given fingerprint cannot be found.  The
-   "certificate_unobtainable" fatal alert is defined in section 4 of
-   [TLSEXT].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 6]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-      enum {
-           cert_fingerprint (0), cert (1), (255)
-      } OpenPGPCertDescriptorType;
-
-      opaque OpenPGPCertFingerprint<16..20>;
-
-      opaque OpenPGPCert<0..2^24-1>;
-
-      struct {
-           OpenPGPCertDescriptorType descriptorType;
-           select (descriptorType) {
-                case cert_fingerprint: OpenPGPCertFingerprint;
-                case cert: OpenPGPCert;
-           }
-      } Certificate;
-
-3.4.  Certificate request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However if this message is sent, and the negotiated
-   certificate type is OpenPGP, the "certificate_authorities" list MUST
-   be empty.
-
-3.5.  Client certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP certificates have been selected and no certificate
-   is available from the client, then a Certificate structure that
-   contains an empty OpenPGPCert vector MUST be sent.  The server SHOULD
-   respond with a "handshake_failure" fatal alert if client
-   authentication is required.
-
-3.6.  Other Handshake messages
-
-   All the other handshake messages are identical to the TLS
-   specification.
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 7]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-4.  Security Considerations
-
-   All security considerations discussed in [TLS], [TLSEXT] as well as
-   [OpenPGP] apply to this document.  Considerations about the use of
-   the web of trust or identity and certificate verification procedure
-   are outside the scope of this document.  These are considered issues
-   to be handled by the application layer protocols.
-
-   The protocol for certificate type negotiation is identical in
-   operation to ciphersuite negotiation of the [TLS] specification with
-   the addition of default values when the extension is omitted.  Since
-   those omissions have a unique meaning and the same protection is
-   applied to the values as with ciphersuites, it is believed that the
-   security properties of this negotiation are the same as with
-   ciphersuite negotiation.
-
-   When using OpenPGP fingerprints instead of the full certificates, the
-   discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs"
-   applies, especially when external servers are used to retrieve keys.
-   However a major difference is that while the "client_certificate_url"
-   extension allows to identify certificates without including the
-   certificate hashes, this is not possible in the protocol proposed
-   here.  In this protocol the certificates, when not sent, are always
-   identified by their fingerprint, which serves as a cryptographic hash
-   of the certificate (see Section 11.2 of [OpenPGP]).
-
-   The information that is available to participating parties and
-   eavesdroppers (when confidentiality is not available through a
-   previous handshake) is the number and the types of certificates they
-   hold, plus the contents of certificates.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 8]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-5.  IANA Considerations
-
-   This document defines a new TLS extension, "cert_type", assigned a
-   value of TBD-BY-IANA (the value 7 is suggested) from the TLS
-   ExtensionType registry defined in [TLSEXT].  This value is used as
-   the extension number for the extensions in both the client hello
-   message and the server hello message.  The new extension type is used
-   for certificate type negotiation.
-
-   The "cert_type" extension contains an 8-bit CertificateType field,
-   for which a new registry, named "TLS Certificate Types", is
-   established in this document, to be maintained by IANA.  The registry
-   is segmented in the following way:
-
-   1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
-
-   2.  Values from 2 through 223 decimal inclusive are assigned via IETF
-       Consensus [RFC2434].
-
-   3.  Values from 224 decimal through 255 decimal inclusive are
-       reserved for Private Use [RFC2434].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007                [Page 9]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-6.  References
-
-6.1.  Normative References
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", RFC 4346, April 2006.
-
-   [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R.
-              Thayer, "OpenPGP Message Format",
-              draft-ietf-openpgp-rfc2440bis-18 (work in progress),
-              May 2006.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", RFC 2434,
-              October 1998.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-6.2.  Informative References
-
-   [PKIX]  Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509
-           Public Key Infrastructure Certificate and Certificate
-           Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007               [Page 10]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-Appendix A.  Acknowledgements
-
-   This document was based on earlier work made by Will Price and
-   Michael Elkins.
-
-   The author wishes to thank Werner Koch, David Taylor, Timo Schulz,
-   Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks and Hilarie
-   Orman for their suggestions on improving this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007               [Page 11]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-Author's Address
-
-   Nikos Mavrogiannopoulos
-   Independent
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007               [Page 12]
-
-Internet-Draft  Using OpenPGP keys for TLS authentication      July 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Mavrogiannopoulos       Expires February 1, 2007               [Page 13]
-
-
diff --git a/doc/protocol/draft-ietf-tls-psk-01.txt b/doc/protocol/draft-ietf-tls-psk-01.txt
deleted file mode 100644
index b0ed189b4f..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-01.txt
+++ /dev/null
@@ -1,728 +0,0 @@
-
-TLS Working Group                                              P. Eronen
-Internet-Draft                                                     Nokia
-Expires: February 16, 2005                                 H. Tschofenig
-                                                                 Siemens
-                                                         August 18, 2004
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-                       draft-ietf-tls-psk-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   and any of which I become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on February 16, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document specifies three sets of new ciphersuites for the
-   Transport Layer Security (TLS) protocol to support authentication
-   based on pre-shared keys.  These pre-shared keys are symmetric keys,
-   shared in advance among the communicating parties.  The first set of
-   ciphersuites uses only symmetric key operations for authentication.
-   The second set uses a Diffie-Hellman exchange authenticated with a
-   pre-shared key; and the third set combines public key authentication
-   of the server with pre-shared key authentication of the client.
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 1]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-1.  Introduction
-
-   Usually TLS uses public key certificates [3] or Kerberos [11] for
-   authentication.  This document describes how to use symmetric keys
-   (later called pre-shared keys or PSKs), shared in advance among the
-   communicating parties, to establish a TLS connection.
-
-   There are basically two reasons why one might want to do this:
-
-   o  First, TLS may be used in performance-constrained environments
-      where the CPU power needed for public key operations is not
-      available.
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view.  For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-   This document specifies three sets of new ciphersuites for TLS.
-   These ciphersuites use new key exchange algorithms, and re-use
-   existing cipher and MAC algorithms from [3] and [2].  A summary of
-   these ciphersuites is shown below.
-
-      CipherSuite                        Key Exchange  Cipher       Hash
-
-      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
-      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
-      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
-      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
-      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
-      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
-      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
-      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
-      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
-      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
-      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
-      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
-
-   The first set of ciphersuites (with PSK key exchange algorithm),
-   defined in Section 2 use only symmetric key algorithms, and are thus
-   especially suitable for performance-constrained environments.
-
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-   ciphersuites give some additional protection against dictionary
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 2]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-   attacks, and also provide Perfect Forward Secrecy (PFS).
-
-   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
-   defined in Section 4, combine public key based authentication of the
-   server (using RSA and certificates) with mutual authentication using
-   a PSK.
-
-1.1  Applicability statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid PKIs, another possibility worth
-   considering is to use self-signed certificates with public key
-   fingerprints.  Instead of manually configuring a shared secret in,
-   for instance, some configuration file, a fingerprint (hash) of the
-   other party's public key (or certificate) could be placed there
-   instead.
-
-   It is also possible to use the SRP (Secure Remote Password)
-   ciphersuites for shared secret authentication [13].  SRP was designed
-   to be used with passwords, and incorporates protection against
-   dictionary attacks.  However, it is computationally more expensive
-   than the PSK ciphersuites in Section 2.
-
-1.2  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 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 3]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-2.  PSK key exchange algorithm
-
-   This section defines the PSK key exchange algorithm and associated
-   ciphersuites.  These ciphersuites use only symmetric key algorithms.
-
-   It is assumed that the reader is familiar with ordinary TLS
-   handshake, shown below.  The elements in parenthesis are not included
-   when PSK key exchange algorithm is used.
-
-      Client                                               Server
-      ------                                               ------
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                                ServerKeyExchange
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK ciphersuites in the
-   ClientHello message.  If the TLS server also wants to use pre-shared
-   keys, it selects one of the PSK ciphersuites, places the selected
-   ciphersuite in the ServerHello message, and includes an appropriate
-   ServerKeyExchange message (see below).  The Certificate and
-   CertificateRequest payloads are omitted from the response.
-
-   Both clients and servers may have pre-shared keys with several
-   different parties.  The client indicates which key to use by
-   including a "PSK identity" in the ClientKeyExchange message (note
-   that unlike in [6], the session_id field in ClientHello message keeps
-   its usual meaning).  To help the client in selecting which identity
-   to use, the server can provide a "PSK identity hint" in the
-   ServerKeyExchange message (note that if no hint is provided, a
-   ServerKeyExchange message is still sent).
-
-   This document does not specify the format of the PSK identity or PSK
-   identity hint; neither is specified how exactly the client uses the
-   hint (if it uses it at all).  The parties have to agree on the
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 4]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-   identities when the shared secret is configured (however, see Section
-   6 for related security considerations).  In situations where the
-   identity is entered by a person, it is RECOMMENDED that the input is
-   processed using an appropriate stringprep [9] profile and encoded in
-   octets using UTF-8 encoding [14].  One possible stringprep profile is
-   described in [8].
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows: If the PSK is N octets
-   long, concatenate N zero octets and the PSK.
-
-      Note: This effectively means that only the HMAC-SHA1 part of the
-      TLS PRF is used, and the HMAC-MD5 part is not used.  See [7] for a
-      more detailed rationale.
-
-   The TLS handshake is authenticated using the Finished messages as
-   usual.
-
-   If the server does not recognize the PSK identity, it MAY respond
-   with an "unknown_psk_identity" alert message.  Alternatively, if the
-   server wishes to hide the fact that the PSK identity was not known,
-   it MAY continue the protocol as if the PSK identity existed but the
-   key was incorrect: that is, respond with a "decrypt_error" alert.
-
-3.  DHE_PSK key exchange algorithm
-
-   This section defines additional ciphersuites that use a PSK to
-   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
-   additional protection against dictionary attacks, and also provide
-   Perfect Forward Secrecy (PFS).  See Section 6 for discussion of
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 5]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-   related security considerations.
-
-   When these ciphersuites are used, the ServerKeyExchange and
-   ClientKeyExchange also include the Diffie-Hellman parameters.  The
-   PSK identity and identity hint fields have the same meaning as in the
-   previous section.
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-                  ServerDHParams params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  ClientDiffieHellmanPublic public;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows: concatenate the value
-   produced by the Diffie-Hellman exchange (with leading zero bytes
-   stripped as in other Diffie-Hellman based ciphersuites) and the PSK,
-   in this order.
-
-4.  RSA_PSK key exchange algorithm
-
-   The ciphersuites in this section use RSA and certificates to
-   authenticate the server, in addition to using a PSK.
-
-   As in normal RSA ciphersuites, the server must send a Certificate
-   message.  The format of the ServerKeyExchange and ClientKeyExchange
-   messages is shown below.
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 6]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  EncryptedPreMasterSecret;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows: concatenate the 48-byte
-   value generated by the client (and sent to the server in
-   ClientKeyExchange message) and the PSK, in this order.
-
-5.  IANA considerations
-
-   (This depends on whether this document is published before or after
-   TLS 1.1.)
-
-   (If after 1.1) This document does not create any new namespaces to be
-   maintained by IANA, but it requires new values in the ciphersuite
-   namespace defined in TLS 1.1 specification.
-
-   (If before 1.1) There are no IANA actions associated with this
-   document.  For easier reference in the future, the ciphersuite
-   numbers defined in this document are summarized below.
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0xTBD };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0xTBD };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0xTBD };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0xTBD };
-      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0xTBD };
-      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD };
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0xTBD };
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0xTBD };
-      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0xTBD };
-      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0xTBD };
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0xTBD };
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0xTBD };
-
-   This document also defines a new TLS alert message,
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 7]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-   unknown_psk_identity(TBD).  Since IANA does not maintain a registry
-   of TLS alert messages, no IANA action is needed for this.
-
-6.  Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-6.1  Perfect forward secrecy (PFS)
-
-   The PSK and RSA_PSK ciphersuites defined in this document do not
-   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
-   key (in PSK ciphersuites), or both the shared secret key and the RSA
-   private key (in RSA_PSK ciphersuites), is somehow compromised, an
-   attacker can decrypt old conversations.
-
-   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
-   DH private key is generated for each handshake.
-
-6.2  Brute-force and dictionary attacks
-
-   Use of a fixed shared secret of limited entropy (such as a password)
-   may allow an attacker to perform a brute-force or dictionary attack
-   to recover the secret.  This may be either an off-line attack
-   (against a captured TLS handshake messages), or an on-line attack
-   where the attacker attempts to connect to the server and tries
-   different keys.
-
-   For the PSK ciphersuites, an attacker can get the information
-   required for an off-line attack by eavesdropping a TLS handshake, or
-   by getting a valid client to attempt connection with the attacker (by
-   tricking the client to connect to wrong address, or intercepting a
-   connection attempt to the correct address, for instance).
-
-   For the DHE_PSK ciphersuites, an attacker can obtain the information
-   by getting a valid client to attempt connection with the attacker.
-   Passive eavesdropping alone is not sufficient.
-
-   For the RSA_PSK ciphersuites, only the server (authenticated using
-   RSA and certificates) can obtain sufficient information for an
-   off-line attack.
-
-   It is RECOMMENDED that implementations that allow the administrator
-   to manually configure the PSK also provide a functionality for
-   generating a new random PSK, taking [4] into account.
-
-
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 8]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-6.3  Identity privacy
-
-   The PSK identity is sent in cleartext.  While using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties.  Even
-   when the identity does not reveal any information itself, reusing the
-   same identity over time may eventually allow an attacker to perform
-   traffic analysis to identify the parties.  It should be noted that
-   this is no worse than client certificates, since they are also sent
-   in cleartext.
-
-6.4  Implementation notes
-
-   The implementation notes in [10] about correct implementation and use
-   of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
-   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
-   well.
-
-7.  Acknowledgments
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [6] and [2].
-   Valuable feedback was also provided by Philip Ginzboorg, Peter
-   Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, and Mika
-   Tervonen.
-
-   When the first version of this draft was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [12].  However, this draft is not intended for web password
-   authentication, but rather for other uses of TLS.
-
-   The DHE_PSK and RSA_PSK ciphersuites borrow heavily from [5].
-
-8.  Open issues
-
-   o  Identity privacy could be provided (in DHE_PSK/RSA_PSK versions)
-      by encrypting the psk_identity payload with keys derived from the
-      DH value/RSA-encrypted random (but not PSK).  But perhaps this
-      would be an unnecessary complication.
-
-   o  The way the PSK is combined with DH value (and is then used to
-      calculate the Finished message) is not exactly the traditional
-      way.  It should be OK with TLS-PRF, though.
-
-
-
-
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005                [Page 9]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", RFC 2119, March 1997.
-
-   [2]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites  for
-        Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [3]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-        2246, January 1999.
-
-   [4]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-        Recommendations for Security", RFC 1750, December 1994.
-
-9.2  Informative References
-
-   [5]   Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
-         "Pre-Shared-Key key Exchange methods for TLS",
-         draft-badra-tls-key-exchange-00 (work in progress), August
-         2004.
-
-   [6]   Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-         draft-ietf-tls-sharedkeys-02 (expired), October 2003.
-
-   [7]   Krawczyk, H., "Re: TLS shared keys PRF",  message on
-         ietf-tls@lists.certicom.com mailing list 2004-01-13,
-         http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-   [8]   Zeilenga, K., "SASLprep: Stringprep profile for user names and
-         passwords", draft-ietf-sasl-saslprep-10 (work in progress),
-         July 2004.
-
-   [9]   Hoffman, P. and M. Blanchet, "Preparation of Internationalized
-         Strings ("stringprep")", RFC 3454, December 2002.
-
-   [10]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
-         draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004.
-
-   [11]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
-         to Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-   [12]  Simon, D., "Addition of Shared Key Authentication to Transport
-         Layer Security (TLS)",  draft-ietf-tls-passauth-00 (expired),
-         November 1996.
-
-   [13]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005               [Page 10]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-         SRP for TLS Authentication", draft-ietf-tls-srp-07 (work in
-         progress), June 2004.
-
-   [14]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-         3629, November 2003.
-
-
-Authors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   EMail: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   EMail: Hannes.Tschofenig@siemens.com
-
-Appendix A.  Changelog
-
-   (This section should be removed by the RFC Editor before
-   publication.)
-
-   Changes from draft-ietf-tls-psk-00 to -01:
-
-   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
-      other text accordingly
-
-   o  Removed SHA-1 hash from PSK key exchange premaster secret
-      construction (since premaster secret doesn't need to be 48 bytes).
-
-   o  Added unknown_psk_identity alert message.
-
-   o  Updated IANA considerations section.
-
-   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
-
-   o  Updated dictionary attack considerations based on comments from
-      David Jablon.
-
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005               [Page 11]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-   o  Added a recommendation about using UTF-8 in the identity field.
-
-   o  Removed Appendix A comparing this document with
-      draft-ietf-tls-sharedkeys-02.
-
-   o  Removed IPR comment about SPR.
-
-   o  Minor editorial changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005               [Page 12]
-
-Internet-Draft          PSK Ciphersuites for TLS             August 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Eronen & Tschofenig    Expires February 16, 2005               [Page 13]
-
-
diff --git a/doc/protocol/draft-ietf-tls-psk-03.txt b/doc/protocol/draft-ietf-tls-psk-03.txt
deleted file mode 100644
index 03683e63a5..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-03.txt
+++ /dev/null
@@ -1,1047 +0,0 @@
-TLS Working Group                                         P. Eronen, Ed.
-Internet-Draft                                                     Nokia
-Expires: May 17, 2005                                 H. Tschofenig, Ed.
-                                                                 Siemens
-                                                       November 16, 2004
-
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-                       draft-ietf-tls-psk-03.txt
-
-
-Status of this Memo
-
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-
-   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.
-
-
-   This Internet-Draft will expire on May 17, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
-   This document specifies three sets of new ciphersuites for the
-   Transport Layer Security (TLS) protocol to support authentication
-   based on pre-shared keys.  These pre-shared keys are symmetric keys,
-   shared in advance among the communicating parties.  The first set of
-   ciphersuites uses only symmetric key operations for authentication.
-   The second set uses a Diffie-Hellman exchange authenticated with a
-   pre-shared key; and the third set combines public key authentication
-   of the server with pre-shared key authentication of the client.
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 1]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-1.  Introduction
-
-
-   Usually TLS uses public key certificates [3] or Kerberos [12] for
-   authentication.  This document describes how to use symmetric keys
-   (later called pre-shared keys or PSKs), shared in advance among the
-   communicating parties, to establish a TLS connection.
-
-
-   There are basically two reasons why one might want to do this:
-
-
-   o  First, TLS may be used in performance-constrained environments
-      where the CPU power needed for public key operations is not
-      available.
-
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view.  For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-
-   This document specifies three sets of new ciphersuites for TLS.
-   These ciphersuites use new key exchange algorithms, and re-use
-   existing cipher and MAC algorithms from [3] and [2].  A summary of
-   these ciphersuites is shown below.
-
-
-      CipherSuite                        Key Exchange  Cipher       Hash
-
-
-      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
-      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
-      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
-      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
-      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
-      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
-      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
-      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
-      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
-      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
-      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
-      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
-
-
-   The first set of ciphersuites (with PSK key exchange algorithm),
-   defined in Section 2 use only symmetric key algorithms, and are thus
-   especially suitable for performance-constrained environments.
-
-
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-   ciphersuites protect against dictionary attacks by passive
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 2]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-   eavesdroppers (but not active attackers), and also provide Perfect
-   Forward Secrecy (PFS).
-
-
-   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
-   defined in Section 4, combine public key based authentication of the
-   server (using RSA and certificates) with mutual authentication using
-   a PSK.
-
-
-1.1  Applicability statement
-
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-
-   If the main goal is to avoid PKIs, another possibility worth
-   considering is to use self-signed certificates with public key
-   fingerprints.  Instead of manually configuring a shared secret in,
-   for instance, some configuration file, a fingerprint (hash) of the
-   other party's public key (or certificate) could be placed there
-   instead.
-
-
-   It is also possible to use the SRP (Secure Remote Password)
-   ciphersuites for shared secret authentication [14].  SRP was designed
-   to be used with passwords, and incorporates protection against
-   dictionary attacks.  However, it is computationally more expensive
-   than the PSK ciphersuites in Section 2.
-
-
-1.2  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 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 3]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-2.  PSK key exchange algorithm
-
-
-   This section defines the PSK key exchange algorithm and associated
-   ciphersuites.  These ciphersuites use only symmetric key algorithms.
-
-
-   It is assumed that the reader is familiar with ordinary TLS
-   handshake, shown below.  The elements in parenthesis are not included
-   when PSK key exchange algorithm is used.
-
-
-      Client                                               Server
-      ------                                               ------
-
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                                ServerKeyExchange
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK ciphersuites in the
-   ClientHello message.  If the TLS server also wants to use pre-shared
-   keys, it selects one of the PSK ciphersuites, places the selected
-   ciphersuite in the ServerHello message, and includes an appropriate
-   ServerKeyExchange message (see below).  The Certificate and
-   CertificateRequest payloads are omitted from the response.
-
-
-   Both clients and servers may have pre-shared keys with several
-   different parties.  The client indicates which key to use by
-   including a "PSK identity" in the ClientKeyExchange message (note
-   that unlike in [7], the session_id field in ClientHello message keeps
-   its usual meaning).  To help the client in selecting which identity
-   to use, the server can provide a "PSK identity hint" in the
-   ServerKeyExchange message (note that if no hint is provided, a
-   ServerKeyExchange message is still sent).
-
-
-   It is expected that different types of identities are useful for
-   different applications running over TLS.  This document does not
-   therefore mandate the use of any particular type of identity (such as
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 4]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-   IPv4 address or FQDN) or identity hint; neither is specified how
-   exactly the client uses the hint (if it uses it at all).
-
-
-   To increase the chances for successful interoperation between
-   applications that do agree on what type of identity is used, the
-   identity MUST be first converted to a character string, and then
-   encoded to octets using UTF-8 [5].  For instance,
-
-
-   o  IPv4 addresses are sent as dotted-decimal strings (e.g.,
-      "192.0.1.2"), not as 32-bit integers in network byte order.
-
-
-   o  Domain names are sent in their usual text form (e.g.,
-      "www.example.com" or "embedded\.dot.example.net"), not in DNS
-      protocol wire format.
-
-
-   o  X.500 Distinguished Names are sent in their string representation
-      [9], not as BER-encoded ASN.1.
-
-
-   In situations where the identity is entered by a person, processing
-   the character string with an appropriate stringprep [10] profile is
-   RECOMMENDED.
-
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 5]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-   The premaster secret is formed as follows: if the PSK is N octets
-   long, concatenate an uint16 with the value N, N zero octets, a second
-   uint16 with the value N, and the PSK itself.
-
-
-      Note 1: All the ciphersuites in this document share the same
-      general structure for the premaster secret, namely
-
-
-         struct {
-             opaque other_secret<0..2^16-1>;
-             opaque psk<0..2^16-1>;
-         };
-
-
-      Here "other_secret" is either zeroes (plain PSK case), or comes
-      from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
-      respectively).  See Sections 3 and 4 for a more detailed
-      description.
-
-
-      Note 2: Using zeroes for "other_secret" effectively means that
-      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
-      is used when constructing the master secret.  See [8] for a more
-      detailed rationale.
-
-
-   The TLS handshake is authenticated using the Finished messages as
-   usual.
-
-
-   If the server does not recognize the PSK identity, it MAY respond
-   with an "unknown_psk_identity" alert message.  Alternatively, if the
-   server wishes to hide the fact that the PSK identity was not known,
-   it MAY continue the protocol as if the PSK identity existed but the
-   key was incorrect: that is, respond with a "decrypt_error" alert.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 6]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-3.  DHE_PSK key exchange algorithm
-
-
-   This section defines additional ciphersuites that use a PSK to
-   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
-   additional protection against dictionary attacks, and also provide
-   Perfect Forward Secrecy (PFS).  See Section 6 for discussion of
-   related security considerations.
-
-
-   When these ciphersuites are used, the ServerKeyExchange and
-   ClientKeyExchange also include the Diffie-Hellman parameters.  The
-   PSK identity and identity hint fields have the same meaning as in the
-   previous section.
-
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-                  ServerDHParams params;
-          };
-      } ServerKeyExchange;
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  ClientDiffieHellmanPublic public;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-
-   The premaster secret is formed as follows.  Let Z be the value
-   produced by the Diffie-Hellman exchange (with leading zero bytes
-   stripped as in other Diffie-Hellman based ciphersuites).  Concatenate
-   an uint16 containing the length of Z (in octets), Z itself, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 7]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-4.  RSA_PSK key exchange algorithm
-
-
-   The ciphersuites in this section use RSA and certificates to
-   authenticate the server, in addition to using a PSK.
-
-
-   As in normal RSA ciphersuites, the server must send a Certificate
-   message.  The format of the ServerKeyExchange and ClientKeyExchange
-   messages is shown below.
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  EncryptedPreMasterSecret;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-
-   The EncryptedPreMasterSecret field sent from the client to the server
-   contains a 2-byte version number and a 46-byte random value,
-   encrypted using the server's RSA public key as described in Section
-   7.4.7.1 of [3].  The actual premaster secret is formed by both
-   parties as follows: concatenate an uint16 with the value 48, the
-   2-byte version number and the 46-byte random value, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-
-
-   Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
-   themselves specify what the certificates contain (in addition to the
-   RSA public key), or how the certificates are to be validated.  In
-   particular, it is possible to use the RSA_PSK ciphersuites with
-   unvalidated self-signed certificates to provide somewhat similar
-   protection against dictionary attacks as the DHE_PSK ciphersuites
-   defined in Section 3.
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 8]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-5.  IANA considerations
-
-
-   IANA does not currently have a registry for TLS-related numbers, so
-   there are no IANA actions associated with this document.
-
-
-   For easier reference in the future, the ciphersuite numbers defined
-   in this document are summarized below.
-
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x8B };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0x8C };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0x8D };
-      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
-      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x91 };
-      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0x92 };
-      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };
-
-
-   This document also defines a new TLS alert message,
-   unknown_psk_identity(115).
-
-
-6.  Security Considerations
-
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-
-6.1  Perfect forward secrecy (PFS)
-
-
-   The PSK and RSA_PSK ciphersuites defined in this document do not
-   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
-   key (in PSK ciphersuites), or both the shared secret key and the RSA
-   private key (in RSA_PSK ciphersuites), is somehow compromised, an
-   attacker can decrypt old conversations.
-
-
-   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
-   DH private key is generated for each handshake.
-
-
-6.2  Brute-force and dictionary attacks
-
-
-   Use of a fixed shared secret of limited entropy (for example, a PSK
-   that is relatively short, or was chosen by a human and thus may
-   contain less entropy than its length would imply) may allow an
-   attacker to perform a brute-force or dictionary attack to recover the
-   secret.  This may be either an off-line attack (against a captured
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                  [Page 9]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-   TLS handshake messages), or an on-line attack where the attacker
-   attempts to connect to the server and tries different keys.
-
-
-   For the PSK ciphersuites, an attacker can get the information
-   required for an off-line attack by eavesdropping a TLS handshake, or
-   by getting a valid client to attempt connection with the attacker (by
-   tricking the client to connect to wrong address, or intercepting a
-   connection attempt to the correct address, for instance).
-
-
-   For the DHE_PSK ciphersuites, an attacker can obtain the information
-   by getting a valid client to attempt connection with the attacker.
-   Passive eavesdropping alone is not sufficient.
-
-
-   For the RSA_PSK ciphersuites, only the server (authenticated using
-   RSA and certificates) can obtain sufficient information for an
-   off-line attack.
-
-
-   It is RECOMMENDED that implementations that allow the administrator
-   to manually configure the PSK also provide a functionality for
-   generating a new random PSK, taking [4] into account.
-
-
-6.3  Identity privacy
-
-
-   The PSK identity is sent in cleartext.  While using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties.  Even
-   when the identity does not reveal any information itself, reusing the
-   same identity over time may eventually allow an attacker to perform
-   traffic analysis to identify the parties.  It should be noted that
-   this is no worse than client certificates, since they are also sent
-   in cleartext.
-
-
-6.4  Implementation notes
-
-
-   The implementation notes in [11] about correct implementation and use
-   of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
-   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
-   well.
-
-
-7.  Acknowledgments
-
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [7] and [2].
-   The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
-   [6].
-
-
-   Valuable feedback was also provided by Philip Ginzboorg, Peter
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                 [Page 10]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-   Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric
-   Rescorla, and Mika Tervonen.
-
-
-   When the first version of this draft was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [13].  However, this draft is not intended for web password
-   authentication, but rather for other uses of TLS.
-
-
-8.  References
-
-
-8.1  Normative References
-
-
-   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-
-   [2]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-         for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-
-   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-         2246, January 1999.
-
-
-   [4]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-         Recommendations for Security", RFC 1750, December 1994.
-
-
-   [5]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-         3629, November 2003.
-
-
-8.2  Informative References
-
-
-   [6]   Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
-         "Pre-Shared-Key key Exchange methods for TLS",
-         draft-badra-tls-key-exchange-00 (work in progress), August
-         2004.
-
-
-   [7]   Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-         draft-ietf-tls-sharedkeys-02 (expired), October 2003.
-
-
-   [8]   Krawczyk, H., "Re: TLS shared keys PRF",  message on
-         ietf-tls@lists.certicom.com mailing list 2004-01-13,
-         http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-
-   [9]   Zeilenga, K., "LDAP: String Representation of Distinguished
-         Names", draft-ietf-ldapbis-dn-15 (work in progress), October
-         2004.
-
-
-   [10]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
-         Strings ("stringprep")", RFC 3454, December 2002.
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                 [Page 11]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-   [11]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
-         draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004.
-
-
-   [12]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
-         to Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-
-   [13]  Simon, D., "Addition of Shared Key Authentication to Transport
-         Layer Security (TLS)",  draft-ietf-tls-passauth-00 (expired),
-         November 1996.
-
-
-   [14]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
-         SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
-         progress), August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                 [Page 12]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-Authors' and Contributors' Addresses
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-   Email: pasi.eronen@nokia.com
-
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-   Mohamad Badra
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Mohamad.Badra@enst.fr
-
-
-
-   Omar Cherkaoui
-   UQAM University
-   Montreal (Quebec)
-   Canada
-   Email: cherkaoui.omar@uqam.ca
-
-
-
-   Ibrahim Hajjeh
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ibrahim.Hajjeh@enst.fr
-
-
-
-   Ahmed Serhrouchni
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ahmed.Serhrouchni@enst.fr
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                 [Page 13]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-Appendix A.  Changelog
-
-
-   (This section should be removed by the RFC Editor before
-   publication.)
-
-
-   Changes from -02 to -03:
-
-
-   o  Aligned the way the premaster secret is derived.
-
-
-   o  Specified that identities must be sent as human-readable UTF-8
-      strings, not in binary formats.  Changed reference to RFC 3629
-      from informative to normative.
-
-
-   o  Selected ciphersuite and alert numbers, and updated IANA
-      considerations section to match this.
-
-
-   o  Reworded some text about dictionary attacks in Section 6.2.
-
-
-   Changes from -01 to -02:
-
-
-   o  Clarified text about DHE_PSK ciphersuites in Section 1.
-
-
-   o  Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
-
-
-   o  Added note about certificate validation and self-signed
-      certificates in Section 4.
-
-
-   o  Added Mohamad Badra et al. as contributors.
-
-
-   Changes from draft-ietf-tls-psk-00 to -01:
-
-
-   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
-      other text accordingly
-
-
-   o  Removed SHA-1 hash from PSK key exchange premaster secret
-      construction (since premaster secret doesn't need to be 48 bytes).
-
-
-   o  Added unknown_psk_identity alert message.
-
-
-   o  Updated IANA considerations section.
-
-
-   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
-
-
-   o  Updated dictionary attack considerations based on comments from
-      David Jablon.
-
-
-   o  Added a recommendation about using UTF-8 in the identity field.
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                 [Page 14]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-   o  Removed Appendix A comparing this document with
-      draft-ietf-tls-sharedkeys-02.
-
-
-   o  Removed IPR comment about SPR.
-
-
-   o  Minor editorial changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                 [Page 15]
-Internet-Draft          PSK Ciphersuites for TLS       November 16, 2004
-
-
-
-Intellectual Property Statement
-
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Disclaimer of Validity
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Copyright Statement
-
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-
-Acknowledgment
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Eronen & Tschofenig       Expires May 17, 2005                 [Page 16] 
\ No newline at end of file
diff --git a/doc/protocol/draft-ietf-tls-psk-04.txt b/doc/protocol/draft-ietf-tls-psk-04.txt
deleted file mode 100644
index 4191663bc8..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-04.txt
+++ /dev/null
@@ -1,897 +0,0 @@
-TLS Working Group                                         P. Eronen, Ed.
-Internet-Draft                                                     Nokia
-Expires: May 25, 2005                                 H. Tschofenig, Ed.
-                                                                 Siemens
-                                                       November 24, 2004
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-                       draft-ietf-tls-psk-04.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on May 25, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specifies three sets of new ciphersuites for the
-   Transport Layer Security (TLS) protocol to support authentication
-   based on pre-shared keys.  These pre-shared keys are symmetric keys,
-   shared in advance among the communicating parties.  The first set of
-   ciphersuites uses only symmetric key operations for authentication.
-   The second set uses a Diffie-Hellman exchange authenticated with a
-   pre-shared key; and the third set combines public key authentication
-   of the server with pre-shared key authentication of the client.
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 1]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-1.  Introduction
-
-   Usually TLS uses public key certificates [3] or Kerberos [12] for
-   authentication.  This document describes how to use symmetric keys
-   (later called pre-shared keys or PSKs), shared in advance among the
-   communicating parties, to establish a TLS connection.
-
-   There are basically two reasons why one might want to do this:
-
-   o  First, TLS may be used in performance-constrained environments
-      where the CPU power needed for public key operations is not
-      available.
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view.  For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-   This document specifies three sets of new ciphersuites for TLS.
-   These ciphersuites use new key exchange algorithms, and re-use
-   existing cipher and MAC algorithms from [3] and [2].  A summary of
-   these ciphersuites is shown below.
-
-      CipherSuite                        Key Exchange  Cipher       Hash
-
-      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
-      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
-      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
-      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
-      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
-      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
-      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
-      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
-      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
-      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
-      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
-      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
-
-   The first set of ciphersuites (with PSK key exchange algorithm),
-   defined in Section 2 use only symmetric key algorithms, and are thus
-   especially suitable for performance-constrained environments.
-
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-   ciphersuites protect against dictionary attacks by passive
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 2]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   eavesdroppers (but not active attackers), and also provide Perfect
-   Forward Secrecy (PFS).
-
-   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
-   defined in Section 4, combine public key based authentication of the
-   server (using RSA and certificates) with mutual authentication using
-   a PSK.
-
-1.1  Applicability statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid PKIs, another possibility worth
-   considering is to use self-signed certificates with public key
-   fingerprints.  Instead of manually configuring a shared secret in,
-   for instance, some configuration file, a fingerprint (hash) of the
-   other party's public key (or certificate) could be placed there
-   instead.
-
-   It is also possible to use the SRP (Secure Remote Password)
-   ciphersuites for shared secret authentication [14].  SRP was designed
-   to be used with passwords, and incorporates protection against
-   dictionary attacks.  However, it is computationally more expensive
-   than the PSK ciphersuites in Section 2.
-
-1.2  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 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 3]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-2.  PSK key exchange algorithm
-
-   This section defines the PSK key exchange algorithm and associated
-   ciphersuites.  These ciphersuites use only symmetric key algorithms.
-
-   It is assumed that the reader is familiar with ordinary TLS
-   handshake, shown below.  The elements in parenthesis are not included
-   when PSK key exchange algorithm is used.
-
-      Client                                               Server
-      ------                                               ------
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                                ServerKeyExchange
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK ciphersuites in the
-   ClientHello message.  If the TLS server also wants to use pre-shared
-   keys, it selects one of the PSK ciphersuites, places the selected
-   ciphersuite in the ServerHello message, and includes an appropriate
-   ServerKeyExchange message (see below).  The Certificate and
-   CertificateRequest payloads are omitted from the response.
-
-   Both clients and servers may have pre-shared keys with several
-   different parties.  The client indicates which key to use by
-   including a "PSK identity" in the ClientKeyExchange message (note
-   that unlike in [7], the session_id field in ClientHello message keeps
-   its usual meaning).  To help the client in selecting which identity
-   to use, the server can provide a "PSK identity hint" in the
-   ServerKeyExchange message (note that if no hint is provided, a
-   ServerKeyExchange message is still sent).
-
-   It is expected that different types of identities are useful for
-   different applications running over TLS.  This document does not
-   therefore mandate the use of any particular type of identity (such as
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 4]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   IPv4 address or FQDN) or identity hint; neither is specified how
-   exactly the client uses the hint (if it uses it at all).
-
-   To increase the chances for successful interoperation between
-   applications that do agree on what type of identity is used, the
-   identity MUST be first converted to a character string, and then
-   encoded to octets using UTF-8 [5].  For instance,
-
-   o  IPv4 addresses are sent as dotted-decimal strings (e.g.,
-      "192.0.1.2"), not as 32-bit integers in network byte order.
-
-   o  Domain names are sent in their usual text form (e.g.,
-      "www.example.com" or "embedded\.dot.example.net"), not in DNS
-      protocol wire format.
-
-   o  X.500 Distinguished Names are sent in their string representation
-      [9], not as BER-encoded ASN.1.
-
-   In situations where the identity is entered by a person, processing
-   the character string with an appropriate stringprep [10] profile is
-   RECOMMENDED.
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 5]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   The premaster secret is formed as follows: if the PSK is N octets
-   long, concatenate an uint16 with the value N, N zero octets, a second
-   uint16 with the value N, and the PSK itself.
-
-      Note 1: All the ciphersuites in this document share the same
-      general structure for the premaster secret, namely
-
-         struct {
-             opaque other_secret<0..2^16-1>;
-             opaque psk<0..2^16-1>;
-         };
-
-      Here "other_secret" is either zeroes (plain PSK case), or comes
-      from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
-      respectively).  See Sections 3 and 4 for a more detailed
-      description.
-
-      Note 2: Using zeroes for "other_secret" effectively means that
-      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
-      is used when constructing the master secret.  See [8] for a more
-      detailed rationale.
-
-   The TLS handshake is authenticated using the Finished messages as
-   usual.
-
-   If the server does not recognize the PSK identity, it MAY respond
-   with an "unknown_psk_identity" alert message.  Alternatively, if the
-   server wishes to hide the fact that the PSK identity was not known,
-   it MAY continue the protocol as if the PSK identity existed but the
-   key was incorrect: that is, respond with a "decrypt_error" alert.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 6]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-3.  DHE_PSK key exchange algorithm
-
-   This section defines additional ciphersuites that use a PSK to
-   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
-   additional protection against dictionary attacks, and also provide
-   Perfect Forward Secrecy (PFS).  See Section 6 for discussion of
-   related security considerations.
-
-   When these ciphersuites are used, the ServerKeyExchange and
-   ClientKeyExchange also include the Diffie-Hellman parameters.  The
-   PSK identity and identity hint fields have the same meaning as in the
-   previous section.
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-                  ServerDHParams params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  ClientDiffieHellmanPublic public;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows.  Let Z be the value
-   produced by the Diffie-Hellman exchange (with leading zero bytes
-   stripped as in other Diffie-Hellman based ciphersuites).  Concatenate
-   an uint16 containing the length of Z (in octets), Z itself, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing Z.
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 7]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-4.  RSA_PSK key exchange algorithm
-
-   The ciphersuites in this section use RSA and certificates to
-   authenticate the server, in addition to using a PSK.
-
-   As in normal RSA ciphersuites, the server must send a Certificate
-   message.  The format of the ServerKeyExchange and ClientKeyExchange
-   messages is shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  EncryptedPreMasterSecret;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The EncryptedPreMasterSecret field sent from the client to the server
-   contains a 2-byte version number and a 46-byte random value,
-   encrypted using the server's RSA public key as described in Section
-   7.4.7.1 of [3].  The actual premaster secret is formed by both
-   parties as follows: concatenate an uint16 with the value 48, the
-   2-byte version number and the 46-byte random value, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing both the 2-byte version number and the 46-byte random
-   value.
-
-   Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
-   themselves specify what the certificates contain (in addition to the
-   RSA public key), or how the certificates are to be validated.  In
-   particular, it is possible to use the RSA_PSK ciphersuites with
-   unvalidated self-signed certificates to provide somewhat similar
-   protection against dictionary attacks as the DHE_PSK ciphersuites
-   defined in Section 3.
-
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 8]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-5.  IANA considerations
-
-   IANA does not currently have a registry for TLS-related numbers, so
-   there are no IANA actions associated with this document.
-
-   For easier reference in the future, the ciphersuite numbers defined
-   in this document are summarized below.
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x8B };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0x8C };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0x8D };
-      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
-      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x91 };
-      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0x92 };
-      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };
-
-   This document also defines a new TLS alert message,
-   unknown_psk_identity(115).
-
-6.  Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-6.1  Perfect forward secrecy (PFS)
-
-   The PSK and RSA_PSK ciphersuites defined in this document do not
-   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
-   key (in PSK ciphersuites), or both the shared secret key and the RSA
-   private key (in RSA_PSK ciphersuites), is somehow compromised, an
-   attacker can decrypt old conversations.
-
-   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
-   DH private key is generated for each handshake.
-
-6.2  Brute-force and dictionary attacks
-
-   Use of a fixed shared secret of limited entropy (for example, a PSK
-   that is relatively short, or was chosen by a human and thus may
-   contain less entropy than its length would imply) may allow an
-   attacker to perform a brute-force or dictionary attack to recover the
-   secret.  This may be either an off-line attack (against a captured
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                  [Page 9]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   TLS handshake messages), or an on-line attack where the attacker
-   attempts to connect to the server and tries different keys.
-
-   For the PSK ciphersuites, an attacker can get the information
-   required for an off-line attack by eavesdropping a TLS handshake, or
-   by getting a valid client to attempt connection with the attacker (by
-   tricking the client to connect to wrong address, or intercepting a
-   connection attempt to the correct address, for instance).
-
-   For the DHE_PSK ciphersuites, an attacker can obtain the information
-   by getting a valid client to attempt connection with the attacker.
-   Passive eavesdropping alone is not sufficient.
-
-   For the RSA_PSK ciphersuites, only the server (authenticated using
-   RSA and certificates) can obtain sufficient information for an
-   off-line attack.
-
-   It is RECOMMENDED that implementations that allow the administrator
-   to manually configure the PSK also provide a functionality for
-   generating a new random PSK, taking [4] into account.
-
-6.3  Identity privacy
-
-   The PSK identity is sent in cleartext.  While using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties.  Even
-   when the identity does not reveal any information itself, reusing the
-   same identity over time may eventually allow an attacker to perform
-   traffic analysis to identify the parties.  It should be noted that
-   this is no worse than client certificates, since they are also sent
-   in cleartext.
-
-6.4  Implementation notes
-
-   The implementation notes in [11] about correct implementation and use
-   of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
-   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
-   well.
-
-7.  Acknowledgments
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [7] and [2].
-   The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
-   [6].
-
-   Valuable feedback was also provided by Philip Ginzboorg, Peter
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                 [Page 10]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric
-   Rescorla, and Mika Tervonen.
-
-   When the first version of this draft was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [13].  However, this draft is not intended for web password
-   authentication, but rather for other uses of TLS.
-
-8.  References
-
-8.1  Normative References
-
-   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-         for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-         2246, January 1999.
-
-   [4]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-         Recommendations for Security", RFC 1750, December 1994.
-
-   [5]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-         3629, November 2003.
-
-8.2  Informative References
-
-   [6]   Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
-         "Pre-Shared-Key key Exchange methods for TLS",
-         draft-badra-tls-key-exchange-00 (work in progress), August
-         2004.
-
-   [7]   Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-         draft-ietf-tls-sharedkeys-02 (expired), October 2003.
-
-   [8]   Krawczyk, H., "Re: TLS shared keys PRF",  message on
-         ietf-tls@lists.certicom.com mailing list 2004-01-13,
-         http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-   [9]   Zeilenga, K., "LDAP: String Representation of Distinguished
-         Names", draft-ietf-ldapbis-dn-15 (work in progress), October
-         2004.
-
-   [10]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
-         Strings ("stringprep")", RFC 3454, December 2002.
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                 [Page 11]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   [11]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
-         draft-ietf-tls-rfc2246-bis-08 (work in progress), August 2004.
-
-   [12]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
-         to Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-   [13]  Simon, D., "Addition of Shared Key Authentication to Transport
-         Layer Security (TLS)",  draft-ietf-tls-passauth-00 (expired),
-         November 1996.
-
-   [14]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
-         SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
-         progress), August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                 [Page 12]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-Authors' and Contributors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-   Email: Hannes.Tschofenig@siemens.com
-
-
-   Mohamad Badra
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Mohamad.Badra@enst.fr
-
-
-   Omar Cherkaoui
-   UQAM University
-   Montreal (Quebec)
-   Canada
-   Email: cherkaoui.omar@uqam.ca
-
-
-   Ibrahim Hajjeh
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ibrahim.Hajjeh@enst.fr
-
-
-   Ahmed Serhrouchni
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ahmed.Serhrouchni@enst.fr
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                 [Page 13]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-Appendix A.  Changelog
-
-   (This section should be removed by the RFC Editor before
-   publication.)
-
-   Changes from -03 to -04:
-
-   o  Added a note about premaster secret "general structure" in
-      Sections 3 and 4.
-
-   o  Something in the I-D submission procedure had removed all
-         circumflexes from -03 version, turning e.g. "2^16" (two-to-
-         the sixteenth power) to "216" (two hundred and sixteen).
-         Let's try again.
-
-   Changes from -02 to -03:
-
-   o  Aligned the way the premaster secret is derived.
-
-   o  Specified that identities must be sent as human-readable UTF-8
-      strings, not in binary formats.  Changed reference to RFC 3629
-      from informative to normative.
-
-   o  Selected ciphersuite and alert numbers, and updated IANA
-      considerations section to match this.
-
-   o  Reworded some text about dictionary attacks in Section 6.2.
-
-   Changes from -01 to -02:
-
-   o  Clarified text about DHE_PSK ciphersuites in Section 1.
-
-   o  Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
-
-   o  Added note about certificate validation and self-signed
-      certificates in Section 4.
-
-   o  Added Mohamad Badra et al. as contributors.
-
-   Changes from draft-ietf-tls-psk-00 to -01:
-
-   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
-      other text accordingly
-
-   o  Removed SHA-1 hash from PSK key exchange premaster secret
-      construction (since premaster secret doesn't need to be 48 bytes).
-
-   o  Added unknown_psk_identity alert message.
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                 [Page 14]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   o  Updated IANA considerations section.
-
-   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
-
-   o  Updated dictionary attack considerations based on comments from
-      David Jablon.
-
-   o  Added a recommendation about using UTF-8 in the identity field.
-
-   o  Removed Appendix A comparing this document with
-      draft-ietf-tls-sharedkeys-02.
-
-   o  Removed IPR comment about SPR.
-
-   o  Minor editorial changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                 [Page 15]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Eronen & Tschofenig       Expires May 25, 2005                 [Page 16]
-
diff --git a/doc/protocol/draft-ietf-tls-psk-05.txt b/doc/protocol/draft-ietf-tls-psk-05.txt
deleted file mode 100644
index a9e5403564..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-05.txt
+++ /dev/null
@@ -1,900 +0,0 @@
-
-
-TLS Working Group                                         P. Eronen, Ed.
-Internet-Draft                                                     Nokia
-Expires: June 17, 2005                                H. Tschofenig, Ed.
-                                                                 Siemens
-                                                       December 17, 2004
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-                       draft-ietf-tls-psk-05.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 17, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specifies three sets of new ciphersuites for the
-   Transport Layer Security (TLS) protocol to support authentication
-   based on pre-shared keys.  These pre-shared keys are symmetric keys,
-   shared in advance among the communicating parties.  The first set of
-   ciphersuites uses only symmetric key operations for authentication.
-   The second set uses a Diffie-Hellman exchange authenticated with a
-   pre-shared key; and the third set combines public key authentication
-   of the server with pre-shared key authentication of the client.
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 1]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-1.  Introduction
-
-   Usually TLS uses public key certificates [3] or Kerberos [12] for
-   authentication.  This document describes how to use symmetric keys
-   (later called pre-shared keys or PSKs), shared in advance among the
-   communicating parties, to establish a TLS connection.
-
-   There are basically two reasons why one might want to do this:
-
-   o  First, TLS may be used in performance-constrained environments
-      where the CPU power needed for public key operations is not
-      available.
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view.  For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-   This document specifies three sets of new ciphersuites for TLS.
-   These ciphersuites use new key exchange algorithms, and re-use
-   existing cipher and MAC algorithms from [3] and [2].  A summary of
-   these ciphersuites is shown below.
-
-      CipherSuite                        Key Exchange  Cipher       Hash
-
-      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
-      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
-      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
-      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
-      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
-      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
-      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
-      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
-      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
-      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
-      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
-      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
-
-   The first set of ciphersuites (with PSK key exchange algorithm),
-   defined in Section 2 use only symmetric key algorithms, and are thus
-   especially suitable for performance-constrained environments.
-
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-   ciphersuites protect against dictionary attacks by passive
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 2]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   eavesdroppers (but not active attackers), and also provide Perfect
-   Forward Secrecy (PFS).
-
-   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
-   defined in Section 4, combine public key based authentication of the
-   server (using RSA and certificates) with mutual authentication using
-   a PSK.
-
-1.1  Applicability statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid PKIs, another possibility worth
-   considering is to use self-signed certificates with public key
-   fingerprints.  Instead of manually configuring a shared secret in,
-   for instance, some configuration file, a fingerprint (hash) of the
-   other party's public key (or certificate) could be placed there
-   instead.
-
-   It is also possible to use the SRP (Secure Remote Password)
-   ciphersuites for shared secret authentication [14].  SRP was designed
-   to be used with passwords, and incorporates protection against
-   dictionary attacks.  However, it is computationally more expensive
-   than the PSK ciphersuites in Section 2.
-
-1.2  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 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 3]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-2.  PSK key exchange algorithm
-
-   This section defines the PSK key exchange algorithm and associated
-   ciphersuites.  These ciphersuites use only symmetric key algorithms.
-
-   It is assumed that the reader is familiar with ordinary TLS
-   handshake, shown below.  The elements in parenthesis are not included
-   when PSK key exchange algorithm is used, and "*" indicates a
-   situation-dependent message that is not always sent.
-
-      Client                                               Server
-      ------                                               ------
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                               ServerKeyExchange*
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK ciphersuites in the
-   ClientHello message.  If the TLS server also wants to use pre-shared
-   keys, it selects one of the PSK ciphersuites, places the selected
-   ciphersuite in the ServerHello message, and includes an appropriate
-   ServerKeyExchange message (see below).  The Certificate and
-   CertificateRequest payloads are omitted from the response.
-
-   Both clients and servers may have pre-shared keys with several
-   different parties.  The client indicates which key to use by
-   including a "PSK identity" in the ClientKeyExchange message (note
-   that unlike in [7], the session_id field in ClientHello message keeps
-   its usual meaning).  To help the client in selecting which identity
-   to use, the server can provide a "PSK identity hint" in the
-   ServerKeyExchange message.  If no hint is provided, the
-   ServerKeyExchange message is omitted.
-
-   It is expected that different types of identities are useful for
-   different applications running over TLS.  This document does not
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 4]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   therefore mandate the use of any particular type of identity (such as
-   IPv4 address or FQDN) or identity hint; neither is specified how
-   exactly the client uses the hint (if it uses it at all).
-
-   To increase the chances for successful interoperation between
-   applications that do agree on what type of identity is used, the
-   identity MUST be first converted to a character string, and then
-   encoded to octets using UTF-8 [5].  For instance,
-
-   o  IPv4 addresses are sent as dotted-decimal strings (e.g.,
-      "192.0.1.2"), not as 32-bit integers in network byte order.
-
-   o  Domain names are sent in their usual text form (e.g.,
-      "www.example.com" or "embedded\.dot.example.net"), not in DNS
-      protocol wire format.
-
-   o  X.500 Distinguished Names are sent in their string representation
-      [9], not as BER-encoded ASN.1.
-
-   In situations where the identity is entered by a person, processing
-   the character string with an appropriate stringprep [10] profile is
-   RECOMMENDED.
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 5]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   The premaster secret is formed as follows: if the PSK is N octets
-   long, concatenate an uint16 with the value N, N zero octets, a second
-   uint16 with the value N, and the PSK itself.
-
-      Note 1: All the ciphersuites in this document share the same
-      general structure for the premaster secret, namely
-
-         struct {
-             opaque other_secret<0..2^16-1>;
-             opaque psk<0..2^16-1>;
-         };
-
-      Here "other_secret" is either zeroes (plain PSK case), or comes
-      from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
-      respectively).  See Sections 3 and 4 for a more detailed
-      description.
-
-      Note 2: Using zeroes for "other_secret" effectively means that
-      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
-      is used when constructing the master secret.  See [8] for a more
-      detailed rationale.
-
-   The TLS handshake is authenticated using the Finished messages as
-   usual.
-
-   If the server does not recognize the PSK identity, it MAY respond
-   with an "unknown_psk_identity" alert message.  Alternatively, if the
-   server wishes to hide the fact that the PSK identity was not known,
-   it MAY continue the protocol as if the PSK identity existed but the
-   key was incorrect: that is, respond with a "decrypt_error" alert.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 6]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-3.  DHE_PSK key exchange algorithm
-
-   This section defines additional ciphersuites that use a PSK to
-   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
-   additional protection against dictionary attacks, and also provide
-   Perfect Forward Secrecy (PFS).  See Section 6 for discussion of
-   related security considerations.
-
-   When these ciphersuites are used, the ServerKeyExchange and
-   ClientKeyExchange messages also include the Diffie-Hellman
-   parameters.  The PSK identity and identity hint fields have the same
-   meaning as in the previous section (note that the ServerKeyExchange
-   message is always sent even if no PSK identity hint is provided).
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-                  ServerDHParams params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  ClientDiffieHellmanPublic public;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows.  Let Z be the value
-   produced by the Diffie-Hellman exchange (with leading zero bytes
-   stripped as in other Diffie-Hellman based ciphersuites).  Concatenate
-   an uint16 containing the length of Z (in octets), Z itself, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing Z.
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 7]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-4.  RSA_PSK key exchange algorithm
-
-   The ciphersuites in this section use RSA and certificates to
-   authenticate the server, in addition to using a PSK.
-
-   As in normal RSA ciphersuites, the server must send a Certificate
-   message.  The format of the ServerKeyExchange and ClientKeyExchange
-   messages is shown below.  If no PSK identity hint is provided, the
-   ServerKeyExchange message is omitted.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  EncryptedPreMasterSecret;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The EncryptedPreMasterSecret field sent from the client to the server
-   contains a 2-byte version number and a 46-byte random value,
-   encrypted using the server's RSA public key as described in Section
-   7.4.7.1 of [3].  The actual premaster secret is formed by both
-   parties as follows: concatenate an uint16 with the value 48, the
-   2-byte version number and the 46-byte random value, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing both the 2-byte version number and the 46-byte random
-   value.
-
-   Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
-   themselves specify what the certificates contain (in addition to the
-   RSA public key), or how the certificates are to be validated.  In
-   particular, it is possible to use the RSA_PSK ciphersuites with
-   unvalidated self-signed certificates to provide somewhat similar
-   protection against dictionary attacks as the DHE_PSK ciphersuites
-   defined in Section 3.
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 8]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-5.  IANA considerations
-
-   IANA does not currently have a registry for TLS-related numbers, so
-   there are no IANA actions associated with this document.
-
-   For easier reference in the future, the ciphersuite numbers defined
-   in this document are summarized below.
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x8B };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0x8C };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0x8D };
-      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
-      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x91 };
-      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0x92 };
-      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };
-
-   This document also defines a new TLS alert message,
-   unknown_psk_identity(115).
-
-6.  Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-6.1  Perfect forward secrecy (PFS)
-
-   The PSK and RSA_PSK ciphersuites defined in this document do not
-   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
-   key (in PSK ciphersuites), or both the shared secret key and the RSA
-   private key (in RSA_PSK ciphersuites), is somehow compromised, an
-   attacker can decrypt old conversations.
-
-   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
-   DH private key is generated for each handshake.
-
-6.2  Brute-force and dictionary attacks
-
-   Use of a fixed shared secret of limited entropy (for example, a PSK
-   that is relatively short, or was chosen by a human and thus may
-   contain less entropy than its length would imply) may allow an
-   attacker to perform a brute-force or dictionary attack to recover the
-   secret.  This may be either an off-line attack (against a captured
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                 [Page 9]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   TLS handshake messages), or an on-line attack where the attacker
-   attempts to connect to the server and tries different keys.
-
-   For the PSK ciphersuites, an attacker can get the information
-   required for an off-line attack by eavesdropping a TLS handshake, or
-   by getting a valid client to attempt connection with the attacker (by
-   tricking the client to connect to wrong address, or intercepting a
-   connection attempt to the correct address, for instance).
-
-   For the DHE_PSK ciphersuites, an attacker can obtain the information
-   by getting a valid client to attempt connection with the attacker.
-   Passive eavesdropping alone is not sufficient.
-
-   For the RSA_PSK ciphersuites, only the server (authenticated using
-   RSA and certificates) can obtain sufficient information for an
-   off-line attack.
-
-   It is RECOMMENDED that implementations that allow the administrator
-   to manually configure the PSK also provide a functionality for
-   generating a new random PSK, taking [4] into account.
-
-6.3  Identity privacy
-
-   The PSK identity is sent in cleartext.  While using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties.  Even
-   when the identity does not reveal any information itself, reusing the
-   same identity over time may eventually allow an attacker to perform
-   traffic analysis to identify the parties.  It should be noted that
-   this is no worse than client certificates, since they are also sent
-   in cleartext.
-
-6.4  Implementation notes
-
-   The implementation notes in [11] about correct implementation and use
-   of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
-   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
-   well.
-
-7.  Acknowledgments
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [7] and [2].
-   The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
-   [6].
-
-   Valuable feedback was also provided by Philip Ginzboorg, Peter
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                [Page 10]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   Gutmann, David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric
-   Rescorla, and Mika Tervonen.
-
-   When the first version of this draft was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [13].  However, this draft is not intended for web password
-   authentication, but rather for other uses of TLS.
-
-8.  References
-
-8.1  Normative References
-
-   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-         for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-         2246, January 1999.
-
-   [4]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-         Recommendations for Security", RFC 1750, December 1994.
-
-   [5]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-         3629, November 2003.
-
-8.2  Informative References
-
-   [6]   Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
-         "Pre-Shared-Key key Exchange methods for TLS",
-         draft-badra-tls-key-exchange-00 (work in progress), August
-         2004.
-
-   [7]   Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-         draft-ietf-tls-sharedkeys-02 (expired), October 2003.
-
-   [8]   Krawczyk, H., "Re: TLS shared keys PRF",  message on
-         ietf-tls@lists.certicom.com mailing list 2004-01-13,
-         http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-   [9]   Zeilenga, K., "LDAP: String Representation of Distinguished
-         Names", draft-ietf-ldapbis-dn-15 (work in progress), October
-         2004.
-
-   [10]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
-         Strings ("stringprep")", RFC 3454, December 2002.
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                [Page 11]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   [11]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
-         draft-ietf-tls-rfc2246-bis-09 (work in progress), December
-         2004.
-
-   [12]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
-         to Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-   [13]  Simon, D., "Addition of Shared Key Authentication to Transport
-         Layer Security (TLS)",  draft-ietf-tls-passauth-00 (expired),
-         November 1996.
-
-   [14]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
-         SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
-         progress), August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                [Page 12]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-Authors' and Contributors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-   Email: Hannes.Tschofenig@siemens.com
-
-
-   Mohamad Badra
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Mohamad.Badra@enst.fr
-
-
-   Omar Cherkaoui
-   UQAM University
-   Montreal (Quebec)
-   Canada
-   Email: cherkaoui.omar@uqam.ca
-
-
-   Ibrahim Hajjeh
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ibrahim.Hajjeh@enst.fr
-
-
-   Ahmed Serhrouchni
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ahmed.Serhrouchni@enst.fr
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                [Page 13]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-Appendix A.  Changelog
-
-   (This section should be removed by the RFC Editor before
-   publication.)
-
-   Changes from -04 to -05:
-
-   o  Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
-      identity hint is provided.
-
-   Changes from -03 to -04:
-
-   o  Added a note about premaster secret "general structure" in
-      Sections 3 and 4.
-
-   o  Something in the I-D submission procedure had removed all
-         circumflexes from -03 version, turning e.g. "2^16" (two-to-
-         the sixteenth power) to "216" (two hundred and sixteen).
-         Let's try again.
-
-   Changes from -02 to -03:
-
-   o  Aligned the way the premaster secret is derived.
-
-   o  Specified that identities must be sent as human-readable UTF-8
-      strings, not in binary formats.  Changed reference to RFC 3629
-      from informative to normative.
-
-   o  Selected ciphersuite and alert numbers, and updated IANA
-      considerations section to match this.
-
-   o  Reworded some text about dictionary attacks in Section 6.2.
-
-   Changes from -01 to -02:
-
-   o  Clarified text about DHE_PSK ciphersuites in Section 1.
-
-   o  Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
-
-   o  Added note about certificate validation and self-signed
-      certificates in Section 4.
-
-   o  Added Mohamad Badra et al. as contributors.
-
-   Changes from draft-ietf-tls-psk-00 to -01:
-
-   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
-      other text accordingly
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                [Page 14]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-   o  Removed SHA-1 hash from PSK key exchange premaster secret
-      construction (since premaster secret doesn't need to be 48 bytes).
-
-   o  Added unknown_psk_identity alert message.
-
-   o  Updated IANA considerations section.
-
-   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
-
-   o  Updated dictionary attack considerations based on comments from
-      David Jablon.
-
-   o  Added a recommendation about using UTF-8 in the identity field.
-
-   o  Removed Appendix A comparing this document with
-      draft-ietf-tls-sharedkeys-02.
-
-   o  Removed IPR comment about SPR.
-
-   o  Minor editorial changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                [Page 15]
-
-Internet-Draft          PSK Ciphersuites for TLS       November 24, 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Eronen & Tschofenig       Expires June 17, 2005                [Page 16]
-
-
diff --git a/doc/protocol/draft-ietf-tls-psk-06.txt b/doc/protocol/draft-ietf-tls-psk-06.txt
deleted file mode 100644
index 3d6630ec7b..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-06.txt
+++ /dev/null
@@ -1,956 +0,0 @@
-
-
-TLS Working Group                                         P. Eronen, Ed.
-Internet-Draft                                                     Nokia
-Expires: August 22, 2005                              H. Tschofenig, Ed.
-                                                                 Siemens
-                                                       February 21, 2005
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-                       draft-ietf-tls-psk-06.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 17, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document specifies three sets of new ciphersuites for the
-   Transport Layer Security (TLS) protocol to support authentication
-   based on pre-shared keys.  These pre-shared keys are symmetric keys,
-   shared in advance among the communicating parties.  The first set of
-   ciphersuites uses only symmetric key operations for authentication.
-   The second set uses a Diffie-Hellman exchange authenticated with a
-   pre-shared key; and the third set combines public key authentication
-   of the server with pre-shared key authentication of the client.
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 1]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-1.  Introduction
-
-   Usually TLS uses public key certificates [3] or Kerberos [12] for
-   authentication.  This document describes how to use symmetric keys
-   (later called pre-shared keys or PSKs), shared in advance among the
-   communicating parties, to establish a TLS connection.
-
-   There are basically two reasons why one might want to do this:
-
-   o  First, TLS may be used in performance-constrained environments
-      where the CPU power needed for public key operations is not
-      available.
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view.  For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-   This document specifies three sets of new ciphersuites for TLS.
-   These ciphersuites use new key exchange algorithms, and re-use
-   existing cipher and MAC algorithms from [3] and [2].  A summary of
-   these ciphersuites is shown below.
-
-      CipherSuite                        Key Exchange  Cipher       Hash
-
-      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
-      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
-      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
-      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
-      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
-      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
-      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
-      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
-      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
-      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
-      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
-      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
-
-   The first set of ciphersuites (with PSK key exchange algorithm),
-   defined in Section 2 use only symmetric key algorithms, and are thus
-   especially suitable for performance-constrained environments.
-
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-   ciphersuites protect against dictionary attacks by passive
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 2]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-   eavesdroppers (but not active attackers), and also provide Perfect
-   Forward Secrecy (PFS).
-
-   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
-   defined in Section 4, combine public key based authentication of the
-   server (using RSA and certificates) with mutual authentication using
-   a PSK.
-
-1.1  Applicability statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid PKIs, another possibility worth
-   considering is to use self-signed certificates with public key
-   fingerprints.  Instead of manually configuring a shared secret in,
-   for instance, some configuration file, a fingerprint (hash) of the
-   other party's public key (or certificate) could be placed there
-   instead.
-
-   It is also possible to use the SRP (Secure Remote Password)
-   ciphersuites for shared secret authentication [14].  SRP was designed
-   to be used with passwords, and incorporates protection against
-   dictionary attacks.  However, it is computationally more expensive
-   than the PSK ciphersuites in Section 2.
-
-1.2  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 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 3]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-2.  PSK key exchange algorithm
-
-   This section defines the PSK key exchange algorithm and associated
-   ciphersuites.  These ciphersuites use only symmetric key algorithms.
-
-   It is assumed that the reader is familiar with ordinary TLS
-   handshake, shown below.  The elements in parenthesis are not included
-   when PSK key exchange algorithm is used, and "*" indicates a
-   situation-dependent message that is not always sent.
-
-      Client                                               Server
-      ------                                               ------
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                               ServerKeyExchange*
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK ciphersuites in the
-   ClientHello message.  If the TLS server also wants to use pre-shared
-   keys, it selects one of the PSK ciphersuites, places the selected
-   ciphersuite in the ServerHello message, and includes an appropriate
-   ServerKeyExchange message (see below).  The Certificate and
-   CertificateRequest payloads are omitted from the response.
-
-   Both clients and servers may have pre-shared keys with several
-   different parties.  The client indicates which key to use by
-   including a "PSK identity" in the ClientKeyExchange message (note
-   that unlike in [7], the session_id field in ClientHello message keeps
-   its usual meaning).  To help the client in selecting which identity
-   to use, the server can provide a "PSK identity hint" in the
-   ServerKeyExchange message.  If no hint is provided, the
-   ServerKeyExchange message is omitted.  See Section 5 for more
-   detailed description of these fields.
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 4]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows: if the PSK is N octets
-   long, concatenate an uint16 with the value N, N zero octets, a second
-   uint16 with the value N, and the PSK itself.
-
-      Note 1: All the ciphersuites in this document share the same
-      general structure for the premaster secret, namely
-
-         struct {
-             opaque other_secret<0..2^16-1>;
-             opaque psk<0..2^16-1>;
-         };
-
-      Here "other_secret" is either zeroes (plain PSK case), or comes
-      from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
-      respectively).  See Sections 3 and 4 for a more detailed
-      description.
-
-      Note 2: Using zeroes for "other_secret" effectively means that
-      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
-      is used when constructing the master secret.  See [8] for a more
-      detailed rationale.
-
-   The TLS handshake is authenticated using the Finished messages as
-   usual.
-
-   If the server does not recognize the PSK identity, it MAY respond
-   with an "unknown_psk_identity" alert message.  Alternatively, if the
-   server wishes to hide the fact that the PSK identity was not known,
-   it MAY continue the protocol as if the PSK identity existed but the
-   key was incorrect: that is, respond with a "decrypt_error" alert.
-
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 5]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-3.  DHE_PSK key exchange algorithm
-
-   This section defines additional ciphersuites that use a PSK to
-   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
-   additional protection against dictionary attacks, and also provide
-   Perfect Forward Secrecy (PFS).  See Section 7 for discussion of
-   related security considerations.
-
-   When these ciphersuites are used, the ServerKeyExchange and
-   ClientKeyExchange messages also include the Diffie-Hellman
-   parameters.  The PSK identity and identity hint fields have the same
-   meaning as in the previous section (note that the ServerKeyExchange
-   message is always sent even if no PSK identity hint is provided).
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-                  ServerDHParams params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  ClientDiffieHellmanPublic public;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows.  First, perform the
-   Diffie-Hellman computation in the same way as for other
-   Diffie-Hellman based ciphersuites in [3].  Let Z be the value
-   produced by this computation (with leading zero bytes stripped as in
-   other Diffie-Hellman based ciphersuites).  Concatenate an uint16
-   containing the length of Z (in octets), Z itself, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing Z.
-
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 6]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-4.  RSA_PSK key exchange algorithm
-
-   The ciphersuites in this section use RSA and certificates to
-   authenticate the server, in addition to using a PSK.
-
-   As in normal RSA ciphersuites, the server must send a Certificate
-   message.  The format of the ServerKeyExchange and ClientKeyExchange
-   messages is shown below.  If no PSK identity hint is provided, the
-   ServerKeyExchange message is omitted.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  EncryptedPreMasterSecret;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The EncryptedPreMasterSecret field sent from the client to the server
-   contains a 2-byte version number and a 46-byte random value,
-   encrypted using the server's RSA public key as described in Section
-   7.4.7.1 of [3].  The actual premaster secret is formed by both
-   parties as follows: concatenate an uint16 with the value 48, the
-   2-byte version number and the 46-byte random value, an uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-   (The premaster secret is thus 52 octets longer than the PSK.)
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing both the 2-byte version number and the 46-byte random
-   value.
-
-   Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
-   themselves specify what the certificates contain (in addition to the
-   RSA public key), or how the certificates are to be validated.  In
-   particular, it is possible to use the RSA_PSK ciphersuites with
-   unvalidated self-signed certificates to provide somewhat similar
-   protection against dictionary attacks as the DHE_PSK ciphersuites
-   defined in Section 3.
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 7]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-5.  Conformance requirements
-
-   It is expected that different types of identities are useful for
-   different applications running over TLS.  This document does not
-   therefore mandate the use of any particular type of identity (such as
-   IPv4 address or FQDN).
-
-   However, the TLS client and server clearly have to agree on the
-   identities and keys to be used.  To improve interoperability, this
-   document places requirements on how the identity is encoded on the
-   wire, and what kinds of identities and keys implementations have to
-   support.
-
-   The requirements for implementations are divided to two categories,
-   requirements for TLS implementations and management interfaces.  In
-   this context, "TLS implementation" refers to a TLS library or module
-   that is intended to be used for several different purposes, while
-   "management interface" would typically be implemented by a particular
-   application that uses TLS.
-
-5.1  PSK identity encoding
-
-   The PSK identity MUST be first converted to a character string, and
-   then encoded to octets using UTF-8 [5].  For instance,
-
-   o  IPv4 addresses are sent as dotted-decimal strings (e.g.,
-      "192.0.1.2"), not as 32-bit integers in network byte order.
-
-   o  Domain names are sent in their usual text form (e.g.,
-      "www.example.com" or "embedded.dot.example.net"), not in DNS
-      protocol wire format.
-
-   o  X.500 Distinguished Names are sent in their string representation
-      [9], not as BER-encoded ASN.1.
-
-   This encoding is clearly not optimal for many types of identities.
-   It was chosen to avoid identity type specific parsing and encoding
-   code in implementations where the identity is configured by a person
-   using some kind of management interface.  Requiring such identity
-   type specific code would also increase the chances for
-   interoperability problems resulting from different implementations
-   supporting different identity types.
-
-5.2  Identity hint
-
-   In the absence of an application profile specification specifying
-   otherwise, servers SHOULD NOT provide an identity hint and clients
-   MUST ignore the identity hint field.  Applications that do use this
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 8]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-   field MUST specify its contents, how the value is chosen by the TLS
-   server, and what the TLS client is expected to do with the value.
-
-5.3  Requirements for TLS implementations
-
-   TLS implementations supporting these ciphersuites MUST support
-   arbitrary PSK identities up to 128 octets in length, and arbitrary
-   PSKs up to 64 octets in length.  Supporting longer identities and
-   keys is RECOMMENDED.
-
-5.4  Requirements for management interfaces
-
-   In the absence of an application profile specification specifying
-   otherwise, a management interface for entering the PSK and/or PSK
-   identity MUST support entering PSK identities consisting of up to 128
-   printable ASCII characters, and MUST support entering PSKs up to 64
-   octets in length as ASCII strings and in hexadecimal encoding.
-
-   Supporting as wide character repertoire and as long identities and
-   keys as feasible is RECOMMENDED, as is processing the character
-   string with an appropriate stringprep [10] profile.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005                [Page 9]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-6.  IANA considerations
-
-   IANA does not currently have a registry for TLS-related numbers, so
-   there are no IANA actions associated with this document.
-
-   For easier reference in the future, the ciphersuite numbers defined
-   in this document are summarized below.
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x8B };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0x8C };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0x8D };
-      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
-      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x91 };
-      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0x92 };
-      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };
-
-   This document also defines a new TLS alert message,
-   unknown_psk_identity(115).
-
-7.  Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-7.1  Perfect forward secrecy (PFS)
-
-   The PSK and RSA_PSK ciphersuites defined in this document do not
-   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
-   key (in PSK ciphersuites), or both the shared secret key and the RSA
-   private key (in RSA_PSK ciphersuites), is somehow compromised, an
-   attacker can decrypt old conversations.
-
-   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
-   DH private key is generated for each handshake.
-
-7.2  Brute-force and dictionary attacks
-
-   Use of a fixed shared secret of limited entropy (for example, a PSK
-   that is relatively short, or was chosen by a human and thus may
-   contain less entropy than its length would imply) may allow an
-   attacker to perform a brute-force or dictionary attack to recover the
-   secret.  This may be either an off-line attack (against a captured
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 10]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-   TLS handshake messages), or an on-line attack where the attacker
-   attempts to connect to the server and tries different keys.
-
-   For the PSK ciphersuites, an attacker can get the information
-   required for an off-line attack by eavesdropping a TLS handshake, or
-   by getting a valid client to attempt connection with the attacker (by
-   tricking the client to connect to wrong address, or intercepting a
-   connection attempt to the correct address, for instance).
-
-   For the DHE_PSK ciphersuites, an attacker can obtain the information
-   by getting a valid client to attempt connection with the attacker.
-   Passive eavesdropping alone is not sufficient.
-
-   For the RSA_PSK ciphersuites, only the server (authenticated using
-   RSA and certificates) can obtain sufficient information for an
-   off-line attack.
-
-   It is RECOMMENDED that implementations that allow the administrator
-   to manually configure the PSK also provide a functionality for
-   generating a new random PSK, taking [4] into account.
-
-7.3  Identity privacy
-
-   The PSK identity is sent in cleartext.  While using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties.  Even
-   when the identity does not reveal any information itself, reusing the
-   same identity over time may eventually allow an attacker to perform
-   traffic analysis to identify the parties.  It should be noted that
-   this is no worse than client certificates, since they are also sent
-   in cleartext.
-
-7.4  Implementation notes
-
-   The implementation notes in [11] about correct implementation and use
-   of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
-   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
-   well.
-
-8.  Acknowledgments
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [7] and [2].
-   The DHE_PSK and RSA_PSK ciphersuites are based on earlier work in
-   [6].
-
-   Valuable feedback was also provided by Bernard Aboba, Philip
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 11]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-   Ginzboorg, Peter Gutmann, Russ Housley, David Jablon, Nikos
-   Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and Mika Tervonen.
-
-   When the first version of this draft was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [13].  However, this draft is not intended for web password
-   authentication, but rather for other uses of TLS.
-
-9.  References
-
-9.1  Normative References
-
-   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", RFC 2119, March 1997.
-
-   [2]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-         for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [3]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-         2246, January 1999.
-
-   [4]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-         Recommendations for Security", RFC 1750, December 1994.
-
-   [5]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-         3629, November 2003.
-
-9.2  Informative References
-
-   [6]   Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
-         "Pre-Shared-Key key Exchange methods for TLS",
-         draft-badra-tls-key-exchange-00 (work in progress), August
-         2004.
-
-   [7]   Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-         draft-ietf-tls-sharedkeys-02 (expired), October 2003.
-
-   [8]   Krawczyk, H., "Re: TLS shared keys PRF",  message on
-         ietf-tls@lists.certicom.com mailing list 2004-01-13,
-         http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-   [9]   Zeilenga, K., "LDAP: String Representation of Distinguished
-         Names", draft-ietf-ldapbis-dn-15 (work in progress), October
-         2004.
-
-   [10]  Hoffman, P. and M. Blanchet, "Preparation of Internationalized
-         Strings ("stringprep")", RFC 3454, December 2002.
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 12]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-   [11]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
-         draft-ietf-tls-rfc2246-bis-09 (work in progress), December
-         2004.
-
-   [12]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites
-         to Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-   [13]  Simon, D., "Addition of Shared Key Authentication to Transport
-         Layer Security (TLS)",  draft-ietf-tls-passauth-00 (expired),
-         November 1996.
-
-   [14]  Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin, "Using
-         SRP for TLS Authentication", draft-ietf-tls-srp-08 (work in
-         progress), August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 13]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-Authors' and Contributors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-   Email: Hannes.Tschofenig@siemens.com
-
-
-   Mohamad Badra
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Mohamad.Badra@enst.fr
-
-
-   Omar Cherkaoui
-   UQAM University
-   Montreal (Quebec)
-   Canada
-   Email: cherkaoui.omar@uqam.ca
-
-
-   Ibrahim Hajjeh
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ibrahim.Hajjeh@enst.fr
-
-
-   Ahmed Serhrouchni
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ahmed.Serhrouchni@enst.fr
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 14]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-Appendix A.  Changelog
-
-   (This section should be removed by the RFC Editor before
-   publication.)
-
-   Changes from -05 to -06:
-
-   o  Small clarifications to how the premaster secret is formed.
-
-   o  Added a section about conformance requirements, and moved existing
-      text about identity formats there.
-
-   Changes from -04 to -05:
-
-   o  Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
-      identity hint is provided.
-
-   Changes from -03 to -04:
-
-   o  Added a note about premaster secret "general structure" in
-      Sections 3 and 4.
-
-   o  Something in the I-D submission procedure had removed all
-         circumflexes from -03 version, turning e.g. "2^16" (two-to-
-         the sixteenth power) to "216" (two hundred and sixteen).
-         Let's try again.
-
-   Changes from -02 to -03:
-
-   o  Aligned the way the premaster secret is derived.
-
-   o  Specified that identities must be sent as human-readable UTF-8
-      strings, not in binary formats.  Changed reference to RFC 3629
-      from informative to normative.
-
-   o  Selected ciphersuite and alert numbers, and updated IANA
-      considerations section to match this.
-
-   o  Reworded some text about dictionary attacks in Section 6.2.
-
-   Changes from -01 to -02:
-
-   o  Clarified text about DHE_PSK ciphersuites in Section 1.
-
-   o  Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
-
-   o  Added note about certificate validation and self-signed
-      certificates in Section 4.
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 15]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-   o  Added Mohamad Badra et al. as contributors.
-
-   Changes from draft-ietf-tls-psk-00 to -01:
-
-   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
-      other text accordingly
-
-   o  Removed SHA-1 hash from PSK key exchange premaster secret
-      construction (since premaster secret doesn't need to be 48 bytes).
-
-   o  Added unknown_psk_identity alert message.
-
-   o  Updated IANA considerations section.
-
-   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
-
-   o  Updated dictionary attack considerations based on comments from
-      David Jablon.
-
-   o  Added a recommendation about using UTF-8 in the identity field.
-
-   o  Removed Appendix A comparing this document with
-      draft-ietf-tls-sharedkeys-02.
-
-   o  Removed IPR comment about SPR.
-
-   o  Minor editorial changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 16]
-
-Internet-Draft          PSK Ciphersuites for TLS       February 21, 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Eronen & Tschofenig      Expires August 22, 2005               [Page 17]
-
-
diff --git a/doc/protocol/draft-ietf-tls-psk-09.txt b/doc/protocol/draft-ietf-tls-psk-09.txt
deleted file mode 100644
index f606c2d968..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-09.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-TLS Working Group                                         P. Eronen, Ed.
-Internet-Draft                                                     Nokia
-Expires: December 20, 2005                            H. Tschofenig, Ed.
-                                                                 Siemens
-                                                           June 21, 2005
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-                       draft-ietf-tls-psk-09.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 20, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document specifies three sets of new ciphersuites for the
-   Transport Layer Security (TLS) protocol to support authentication
-   based on pre-shared keys.  These pre-shared keys are symmetric keys,
-   shared in advance among the communicating parties.  The first set of
-   ciphersuites uses only symmetric key operations for authentication.
-   The second set uses a Diffie-Hellman exchange authenticated with a
-   pre-shared key; and the third set combines public key authentication
-   of the server with pre-shared key authentication of the client.
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 1]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1  Applicability statement . . . . . . . . . . . . . . . . .  4
-       1.2  Conventions used in this document . . . . . . . . . . . .  4
-   2.  PSK key exchange algorithm . . . . . . . . . . . . . . . . . .  5
-   3.  DHE_PSK key exchange algorithm . . . . . . . . . . . . . . . .  7
-   4.  RSA_PSK key exchange algorithm . . . . . . . . . . . . . . . .  8
-   5.  Conformance requirements . . . . . . . . . . . . . . . . . . .  9
-       5.1  PSK identity encoding . . . . . . . . . . . . . . . . . .  9
-       5.2  Identity hint . . . . . . . . . . . . . . . . . . . . . . 10
-       5.3  Requirements for TLS implementations  . . . . . . . . . . 10
-       5.4  Requirements for management interfaces  . . . . . . . . . 10
-   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 11
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-       7.1  Perfect forward secrecy (PFS) . . . . . . . . . . . . . . 11
-       7.2  Brute-force and dictionary attacks  . . . . . . . . . . . 11
-       7.3  Identity privacy  . . . . . . . . . . . . . . . . . . . . 12
-       7.4  Implementation notes  . . . . . . . . . . . . . . . . . . 12
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-       9.1  Normative References  . . . . . . . . . . . . . . . . . . 13
-       9.2  Informative References  . . . . . . . . . . . . . . . . . 13
-   Authors' and Contributors' Addresses . . . . . . . . . . . . . . . 15
-   Appendix A.  Changelog . . . . . . . . . . . . . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 2]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-1.  Introduction
-
-   Usually TLS uses public key certificates [TLS] or Kerberos [KERB] for
-   authentication.  This document describes how to use symmetric keys
-   (later called pre-shared keys or PSKs), shared in advance among the
-   communicating parties, to establish a TLS connection.
-
-   There are basically two reasons why one might want to do this:
-
-   o  First, using pre-shared keys can, depending on the ciphersuite,
-      avoid the need for public key operations.  This is useful if TLS
-      is used in performance-constrained environments with limited CPU
-      power.
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view.  For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-   This document specifies three sets of new ciphersuites for TLS.
-   These ciphersuites use new key exchange algorithms, and re-use
-   existing cipher and MAC algorithms from [TLS] and [AES].  A summary
-   of these ciphersuites is shown below.
-
-      CipherSuite                        Key Exchange  Cipher       Hash
-
-      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
-      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
-      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
-      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
-      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
-      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
-      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
-      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
-      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
-      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
-      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
-      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
-
-   The first set of ciphersuites (with PSK key exchange algorithm),
-   defined in Section 2 use only symmetric key algorithms, and are thus
-   especially suitable for performance-constrained environments.
-
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 3]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-   ciphersuites protect against dictionary attacks by passive
-   eavesdroppers (but not active attackers), and also provide Perfect
-   Forward Secrecy (PFS).
-
-   The third set of ciphersuites (with RSA_PSK key exchange algorithm),
-   defined in Section 4, combine public key based authentication of the
-   server (using RSA and certificates) with mutual authentication using
-   a PSK.
-
-1.1  Applicability statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid PKIs, another possibility worth
-   considering is to use self-signed certificates with public key
-   fingerprints.  Instead of manually configuring a shared secret in,
-   for instance, some configuration file, a fingerprint (hash) of the
-   other party's public key (or certificate) could be placed there
-   instead.
-
-   It is also possible to use the SRP (Secure Remote Password)
-   ciphersuites for shared secret authentication [SRP].  SRP was
-   designed to be used with passwords, and incorporates protection
-   against dictionary attacks.  However, it is computationally more
-   expensive than the PSK ciphersuites in Section 2.
-
-1.2  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 [KEYWORDS].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 4]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-2.  PSK key exchange algorithm
-
-   This section defines the PSK key exchange algorithm and associated
-   ciphersuites.  These ciphersuites use only symmetric key algorithms.
-
-   It is assumed that the reader is familiar with ordinary TLS
-   handshake, shown below.  The elements in parenthesis are not included
-   when PSK key exchange algorithm is used, and "*" indicates a
-   situation-dependent message that is not always sent.
-
-      Client                                               Server
-      ------                                               ------
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                               ServerKeyExchange*
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK ciphersuites in the
-   ClientHello message.  If the TLS server also wants to use pre-shared
-   keys, it selects one of the PSK ciphersuites, places the selected
-   ciphersuite in the ServerHello message, and includes an appropriate
-   ServerKeyExchange message (see below).  The Certificate and
-   CertificateRequest payloads are omitted from the response.
-
-   Both clients and servers may have pre-shared keys with several
-   different parties.  The client indicates which key to use by
-   including a "PSK identity" in the ClientKeyExchange message (note
-   that unlike in [SHAREDKEYS], the session_id field in ClientHello
-   message keeps its usual meaning).  To help the client in selecting
-   which identity to use, the server can provide a "PSK identity hint"
-   in the ServerKeyExchange message.  If no hint is provided, the
-   ServerKeyExchange message is omitted.  See Section 5 for more
-   detailed description of these fields.
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 5]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows: if the PSK is N octets
-   long, concatenate a uint16 with the value N, N zero octets, a second
-   uint16 with the value N, and the PSK itself.
-
-      Note 1: All the ciphersuites in this document share the same
-      general structure for the premaster secret, namely
-
-         struct {
-             opaque other_secret<0..2^16-1>;
-             opaque psk<0..2^16-1>;
-         };
-
-      Here "other_secret" is either zeroes (plain PSK case), or comes
-      from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
-      respectively).  See Sections 3 and 4 for a more detailed
-      description.
-
-      Note 2: Using zeroes for "other_secret" effectively means that
-      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
-      is used when constructing the master secret.  This was considered
-      more elegant from an analytical viewpoint than, for instance,
-      using the same key for both the HMAC-MD5 and HMAC-SHA1 parts.  See
-      [KRAWCZYK] for a more detailed rationale.
-
-   The TLS handshake is authenticated using the Finished messages as
-   usual.
-
-   If the server does not recognize the PSK identity, it MAY respond
-   with an "unknown_psk_identity" alert message.  Alternatively, if the
-   server wishes to hide the fact that the PSK identity was not known,
-   it MAY continue the protocol as if the PSK identity existed but the
-   key was incorrect: that is, respond with a "decrypt_error" alert.
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 6]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-3.  DHE_PSK key exchange algorithm
-
-   This section defines additional ciphersuites that use a PSK to
-   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
-   additional protection against dictionary attacks, and also provide
-   Perfect Forward Secrecy (PFS).  See Section 7 for discussion of
-   related security considerations.
-
-   When these ciphersuites are used, the ServerKeyExchange and
-   ClientKeyExchange messages also include the Diffie-Hellman
-   parameters.  The PSK identity and identity hint fields have the same
-   meaning as in the previous section (note that the ServerKeyExchange
-   message is always sent even if no PSK identity hint is provided).
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-                  ServerDHParams params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  ClientDiffieHellmanPublic public;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows.  First, perform the
-   Diffie-Hellman computation in the same way as for other
-   Diffie-Hellman based ciphersuites in [TLS].  Let Z be the value
-   produced by this computation (with leading zero bytes stripped as in
-   other Diffie-Hellman based ciphersuites).  Concatenate a uint16
-   containing the length of Z (in octets), Z itself, a uint16 containing
-   the length of the PSK (in octets), and the PSK itself.
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing Z.
-
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 7]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-4.  RSA_PSK key exchange algorithm
-
-   The ciphersuites in this section use RSA and certificates to
-   authenticate the server, in addition to using a PSK.
-
-   As in normal RSA ciphersuites, the server must send a Certificate
-   message.  The format of the ServerKeyExchange and ClientKeyExchange
-   messages is shown below.  If no PSK identity hint is provided, the
-   ServerKeyExchange message is omitted.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  EncryptedPreMasterSecret;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The EncryptedPreMasterSecret field sent from the client to the server
-   contains a 2-byte version number and a 46-byte random value,
-   encrypted using the server's RSA public key as described in Section
-   7.4.7.1 of [TLS].  The actual premaster secret is formed by both
-   parties as follows: concatenate a uint16 with the value 48, the
-   2-byte version number and the 46-byte random value, a uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-   (The premaster secret is thus 52 octets longer than the PSK.)
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing both the 2-byte version number and the 46-byte random
-   value.
-
-   Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
-   themselves specify what the certificates contain (in addition to the
-   RSA public key), or how the certificates are to be validated.  In
-   particular, it is possible to use the RSA_PSK ciphersuites with
-   unvalidated self-signed certificates to provide somewhat similar
-   protection against dictionary attacks as the DHE_PSK ciphersuites
-   defined in Section 3.
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 8]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-5.  Conformance requirements
-
-   It is expected that different types of identities are useful for
-   different applications running over TLS.  This document does not
-   therefore mandate the use of any particular type of identity (such as
-   IPv4 address or FQDN).
-
-   However, the TLS client and server clearly have to agree on the
-   identities and keys to be used.  To improve interoperability, this
-   document places requirements on how the identity is encoded in the
-   protocol, and what kinds of identities and keys implementations have
-   to support.
-
-   The requirements for implementations are divided to two categories,
-   requirements for TLS implementations and management interfaces.  In
-   this context, "TLS implementation" refers to a TLS library or module
-   that is intended to be used for several different purposes, while
-   "management interface" would typically be implemented by a particular
-   application that uses TLS.
-
-   This document does not specify how the server stores the keys and
-   identities, or how exactly it finds the key corresponding to the
-   identity it receives.  For instance, if the identity is a domain
-   name, it might be appropriate to do a case-insensitive lookup.  It is
-   RECOMMENDED that before looking up the key, the server processes the
-   PSK identity with a stringprep profile [STRINGPREP] appropriate for
-   the identity in question (such as Nameprep [NAMEPREP] for components
-   of domain names or SASLprep for usernames [SASLPREP]).
-
-5.1  PSK identity encoding
-
-   The PSK identity MUST be first converted to a character string, and
-   then encoded to octets using UTF-8 [UTF8].  For instance,
-
-   o  IPv4 addresses are sent as dotted-decimal strings (e.g.,
-      "192.0.2.1"), not as 32-bit integers in network byte order.
-
-   o  Domain names are sent in their usual text form (e.g.,
-      "www.example.com" or "embedded.dot.example.net"), not in DNS
-      protocol format.
-
-   o  X.500 Distinguished Names are sent in their string representation
-      [LDAPDN], not as BER-encoded ASN.1.
-
-   This encoding is clearly not optimal for many types of identities.
-   It was chosen to avoid identity type specific parsing and encoding
-   code in implementations where the identity is configured by a person
-   using some kind of management interface.  Requiring such identity
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005               [Page 9]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-   type specific code would also increase the chances for
-   interoperability problems resulting from different implementations
-   supporting different identity types.
-
-5.2  Identity hint
-
-   In the absence of an application profile specification specifying
-   otherwise, servers SHOULD NOT provide an identity hint and clients
-   MUST ignore the identity hint field.  Applications that do use this
-   field MUST specify its contents, how the value is chosen by the TLS
-   server, and what the TLS client is expected to do with the value.
-
-5.3  Requirements for TLS implementations
-
-   TLS implementations supporting these ciphersuites MUST support
-   arbitrary PSK identities up to 128 octets in length, and arbitrary
-   PSKs up to 64 octets in length.  Supporting longer identities and
-   keys is RECOMMENDED.
-
-5.4  Requirements for management interfaces
-
-   In the absence of an application profile specification specifying
-   otherwise, a management interface for entering the PSK and/or PSK
-   identity MUST support the following:
-
-   o  Entering PSK identities consisting of up to 128 printable Unicode
-      characters.  Supporting as wide character repertoire and as long
-      identities as feasible is RECOMMENDED.
-
-   o  Entering PSKs up to 64 octets in length as ASCII strings and in
-      hexadecimal encoding.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 10]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-6.  IANA considerations
-
-   IANA does not currently have a registry for TLS ciphersuite or alert
-   numbers, so there are no IANA actions associated with this document.
-
-   For easier reference in the future, the ciphersuite numbers defined
-   in this document are summarized below.
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x8B };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0x8C };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0x8D };
-      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
-      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x91 };
-      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0x92 };
-      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };
-
-   This document also defines a new TLS alert message,
-   unknown_psk_identity(115).
-
-7.  Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-7.1  Perfect forward secrecy (PFS)
-
-   The PSK and RSA_PSK ciphersuites defined in this document do not
-   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
-   key (in PSK ciphersuites), or both the shared secret key and the RSA
-   private key (in RSA_PSK ciphersuites), is somehow compromised, an
-   attacker can decrypt old conversations.
-
-   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
-   DH private key is generated for each handshake.
-
-7.2  Brute-force and dictionary attacks
-
-   Use of a fixed shared secret of limited entropy (for example, a PSK
-   that is relatively short, or was chosen by a human and thus may
-   contain less entropy than its length would imply) may allow an
-   attacker to perform a brute-force or dictionary attack to recover the
-   secret.  This may be either an off-line attack (against a captured
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 11]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-   TLS handshake messages), or an on-line attack where the attacker
-   attempts to connect to the server and tries different keys.
-
-   For the PSK ciphersuites, an attacker can get the information
-   required for an off-line attack by eavesdropping a TLS handshake, or
-   by getting a valid client to attempt connection with the attacker (by
-   tricking the client to connect to wrong address, or intercepting a
-   connection attempt to the correct address, for instance).
-
-   For the DHE_PSK ciphersuites, an attacker can obtain the information
-   by getting a valid client to attempt connection with the attacker.
-   Passive eavesdropping alone is not sufficient.
-
-   For the RSA_PSK ciphersuites, only the server (authenticated using
-   RSA and certificates) can obtain sufficient information for an
-   off-line attack.
-
-   It is RECOMMENDED that implementations that allow the administrator
-   to manually configure the PSK also provide a functionality for
-   generating a new random PSK, taking [RANDOMNESS] into account.
-
-7.3  Identity privacy
-
-   The PSK identity is sent in cleartext.  While using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties.  Even
-   when the identity does not reveal any information itself, reusing the
-   same identity over time may eventually allow an attacker to perform
-   traffic analysis to identify the parties.  It should be noted that
-   this is no worse than client certificates, since they are also sent
-   in cleartext.
-
-7.4  Implementation notes
-
-   The implementation notes in [TLS11] about correct implementation and
-   use of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
-   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
-   well.
-
-8.  Acknowledgments
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [SHAREDKEYS] and
-   [AES].  The DHE_PSK and RSA_PSK ciphersuites are based on earlier
-   work in [KEYEX].
-
-   Valuable feedback was also provided by Bernard Aboba, Lakshminath
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 12]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-   Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley,
-   David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and
-   Mika Tervonen.
-
-   When the first version of this draft was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [PASSAUTH].  However, this draft is not intended for web password
-   authentication, but rather for other uses of TLS.
-
-9.  References
-
-9.1  Normative References
-
-   [AES]      Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-   [RANDOMNESS]
-              Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-              "Randomness Requirements for Security", BCP 106, RFC 4086,
-              June 2005.
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", RFC 3629, November 2003.
-
-9.2  Informative References
-
-   [KERB]     Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [KEYEX]    Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
-              "Pre-Shared-Key key Exchange methods for TLS",
-              draft-badra-tls-key-exchange-00 (expired), August 2004.
-
-   [KRAWCZYK] Krawczyk, H., "Re: TLS shared keys PRF",  message on
-              ietf-tls@lists.certicom.com mailing list 2004-01-13,
-              http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-   [LDAPDN]   Zeilenga, K., "LDAP: String Representation of
-              Distinguished Names", draft-ietf-ldapbis-dn-16 (work in
-              progress), February 2005.
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 13]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-   [NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-              Profile for Internationalized Domain Names (IDN)", RFC
-              3491, March 2003.
-
-   [PASSAUTH] Simon, D., "Addition of Shared Key Authentication to
-              Transport Layer Security (TLS)",
-              draft-ietf-tls-passauth-00 (expired), November 1996.
-
-   [SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
-              and Passwords", RFC 4013, February 2005.
-
-   [SHAREDKEYS]
-              Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-              draft-ietf-tls-sharedkeys-02 (expired), October 2003.
-
-   [SRP]      Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,
-              "Using SRP for TLS Authentication", draft-ietf-tls-srp-09
-              (work in progress), March 2005.
-
-   [STRINGPREP]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [TLS11]    Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", draft-ietf-tls-rfc2246-bis-12 (work in progress),
-              June 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 14]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-Authors' and Contributors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-   Email: Hannes.Tschofenig@siemens.com
-
-
-   Mohamad Badra
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Mohamad.Badra@enst.fr
-
-
-   Omar Cherkaoui
-   UQAM University
-   Montreal (Quebec)
-   Canada
-   Email: cherkaoui.omar@uqam.ca
-
-
-   Ibrahim Hajjeh
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ibrahim.Hajjeh@enst.fr
-
-
-   Ahmed Serhrouchni
-   ENST Telecom
-   46 rue Barrault
-   75634 Paris
-   France
-   Email: Ahmed.Serhrouchni@enst.fr
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 15]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-Appendix A.  Changelog
-
-   (This section should be removed by the RFC Editor before
-   publication.)
-
-   Changes from -08 to -09:
-
-   o  Clarified internationalization of PSK identities in Section 5.
-
-   o  Corrected the example IP address in Section 5.1.
-
-   o  Small clarification to IANA considerations on Section 6.
-
-   o  Editorial: changed numeric references to symbolic ones, updated
-      references to latest versions.
-
-   Changes from -07 to -08:
-
-   o  Added table of contents and updated I-D boilerplate.
-
-   o  Small clarification to motivation in Section 1.
-
-   o  Small clarification to note 2 in Section 2.
-
-   o  Corrected all instances of "an uint16" to "a uint16".
-
-   o  Updated references to latest versions.
-
-   Changes from -06 to -07:
-
-   o  Small clarifications to management interface requirements.
-
-   Changes from -05 to -06:
-
-   o  Small clarifications to how the premaster secret is formed.
-
-   o  Added a section about conformance requirements, and moved existing
-      text about identity formats there.
-
-   Changes from -04 to -05:
-
-   o  Omit ServerKeyExchange message (in PSK/RSA_PSK versions) if no
-      identity hint is provided.
-
-   Changes from -03 to -04:
-
-   o  Added a note about premaster secret "general structure" in
-      Sections 3 and 4.
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 16]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-   o  Something in the I-D submission procedure had removed all
-      circumflexes from -03 version, turning e.g. "2^16" (two-to- the
-      sixteenth power) to "216" (two hundred and sixteen).  Let's try
-      again.
-
-   Changes from -02 to -03:
-
-   o  Aligned the way the premaster secret is derived.
-
-   o  Specified that identities must be sent as human-readable UTF-8
-      strings, not in binary formats.  Changed reference to RFC 3629
-      from informative to normative.
-
-   o  Selected ciphersuite and alert numbers, and updated IANA
-      considerations section to match this.
-
-   o  Reworded some text about dictionary attacks in Section 6.2.
-
-   Changes from -01 to -02:
-
-   o  Clarified text about DHE_PSK ciphersuites in Section 1.
-
-   o  Clarified explanation of HMAC-SHA1/MD5 use of PRF in Section 2.
-
-   o  Added note about certificate validation and self-signed
-      certificates in Section 4.
-
-   o  Added Mohamad Badra et al. as contributors.
-
-   Changes from draft-ietf-tls-psk-00 to -01:
-
-   o  Added DHE_PSK and RSA_PSK key exchange algorithms, and updated
-      other text accordingly
-
-   o  Removed SHA-1 hash from PSK key exchange premaster secret
-      construction (since premaster secret doesn't need to be 48 bytes).
-
-   o  Added unknown_psk_identity alert message.
-
-   o  Updated IANA considerations section.
-
-   Changes from draft-eronen-tls-psk-00 to draft-ietf-tls-psk-00:
-
-   o  Updated dictionary attack considerations based on comments from
-      David Jablon.
-
-   o  Added a recommendation about using UTF-8 in the identity field.
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 17]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-   o  Removed Appendix A comparing this document with
-      draft-ietf-tls-sharedkeys-02.
-
-   o  Removed IPR comment about SPR.
-
-   o  Minor editorial changes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 18]
-
-Internet-Draft          PSK Ciphersuites for TLS           June 21, 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Eronen & Tschofenig     Expires December 20, 2005              [Page 19]
-
diff --git a/doc/protocol/draft-ietf-tls-psk-null-01.txt b/doc/protocol/draft-ietf-tls-psk-null-01.txt
deleted file mode 100644
index 0ebc99b9f1..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-null-01.txt
+++ /dev/null
@@ -1,261 +0,0 @@
-TLS Working Group                                         U. Blumenthal 
-Internet Draft                                                  P. Goel 
-Expires: March 2007                                   Intel Corporation 
-                                                     September 27, 2006 
-                                    
- 
-                                      
-          Pre-Shared Key Cipher Suites with NULL Encryption for 
-                      Transport Layer Security (TLS) 
-
-
-                      draft-ietf-tls-psk-null-01.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that       
-   any applicable patent or other IPR claims of which he or she is       
-   aware have been or will be disclosed, and any of which he or she       
-   becomes aware will be disclosed, in accordance with Section 6 of       
-   BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on January 27, 2007. 
-
-Abstract 
-
-   This document specifies authentication-only cipher suites for the 
-   Pre-Shared Key based Transport Layer Security (TLS) protocol to 
-   support null encryption. These cipher suites are useful for countries 
-   and places with cryptography-related restrictions.  
-
-
- 
- 
- 
-Blumenthal & Goel       Expires March 27, 2007                 [Page 1] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    September 
-2006 
-    
-
-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 [RFC2119]. 
-
-Table of Contents 
-
-    
-   1. Introduction...................................................2 
-   2. Cipher Usage...................................................2 
-   3. Security Considerations........................................3 
-   4. IANA Considerations............................................3 
-   5. Acknowledgments................................................3 
-   6. References.....................................................4 
-      6.1. Normative References......................................4 
-   Author's Addresses................................................4 
-   Intellectual Property Statement...................................4 
-   Disclaimer of Validity............................................5 
-   Copyright Statement...............................................5 
-   Acknowledgment....................................................5 
-    
-1. Introduction 
-
-   The RFC for Pre-Shared Key based TLS [TLS-PSK] specifies cipher 
-   suites for supporting TLS using pre-shared symmetric keys. However 
-   all the cipher suites defined in [TLS-PSK] require encryption. There 
-   is a need for cipher suites that support no encryption. This is 
-   required for implementations to meet import restrictions in some 
-   countries. Even though no encryption is used, these cipher suites 
-   support authentication of the client and server to each other, and 
-   message integrity. This document augments [TLS-PSK] by adding three 
-   more cipher suites (PSK, DHE, RSA) with authentication and integrity 
-   only - no encryption. 
-
-    
-
-2. Cipher Usage 
-
-   The new cipher suites proposed here is very similar to cipher suites 
-   defined in [TLS-PSK], except that they define null encryption. 
-
-   The cipher suites defined here use the following options for key 
-   exchange and hash part of the protocol: 
-
- 
- 
-Blumenthal & Goel       Expires March 27, 2007                 [Page 2] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    September 
-2006 
-    
-
-    
-
-   CipherSuite                     Key Exchange   Cipher      Hash 
-
-   TLS_PSK_WITH_NULL_SHA           PSK            NULL        SHA 
-   TLS_DHE_PSK_WITH_NULL_SHA       DHE_PSK        NULL        SHA 
-   TLS_RSA_PSK_WITH_NULL_SHA       RSA_PSK        NULL        SHA 
-    
-   For the meaning of the terms PSK please refer to section 1 in [TLS-
-   PSK]. For the meaning of the terms DHE and RSA please refer to 
-   section 7.4.2 in [TLS]. 
-
-3. Security Considerations 
-
-   As with all schemes involving shared keys, special care should be 
-   taken to protect the shared values and to limit their exposure over 
-   time. As this document augments [TLS-PSK], everything stated in its 
-   Security Consideration section applies here. In addition, as cipher 
-   suites defined here do not support confidentiality - care should be 
-   taken not to send confidential information (such as passwords) over 
-   TLS-PSK connection with no encryption. 
-
-4. IANA Considerations 
-
-   This document defines three new cipher suites, whose values are to be 
-   assigned from the TLS Cipher Suite registry defined in [TLS]. 
-
-   CipherSuite   TLS_PSK_WITH_NULL_SHA      = { 0x00, 0xTBD1 }; 
-   CipherSuite   TLS_DHE_PSK_WITH_NULL_SHA  = { 0x00, 0xTBD2 }; 
-   CipherSuite   TLS_RSA_PSK_WITH_NULL_SHA  = { 0x00, 0xTBD3 }; 
-    
-5. Acknowledgments 
-
-   The cipher suites defined in this document are an augmentation to and 
-   based on [TLS-PSK]. 
-
-
-
-
-
-
- 
- 
-Blumenthal & Goel       Expires March 27, 2007                 [Page 3] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    September 
-2006 
-    
-
-6. References 
-
-6.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [TLS]     Dierks, T. and Rescorla, E., "The TLS Protocol Version 
-             1.1", RFC 4346, April 2006. 
-
-   [TLS-PSK] Eronen, P., Tschofenig, H., "Pre-Shared Key CipherSuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005. 
-
-    
-
-Author's Addresses 
-
-   Uri Blumenthal 
-   Intel Corporation 
-   1515 State Route 10,  
-   PY2-1 10-4 
-   Parsippany, NJ 07054 
-   USA 
-       
-   Email: Uri.Blumenthal@intel.com 
-    
-
-   Purushottam Goel 
-   Intel Corporation 
-   2111 N.E. 25 Ave. 
-   JF3-414 
-   Hillsboro, OR 97124 
-   USA 
-       
-   Email: Purushottam.Goel@intel.com 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
- 
- 
-Blumenthal & Goel       Expires March 27, 2007                 [Page 4] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    September 
-2006 
-    
-
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The Internet Society (2006). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
- 
- 
-Blumenthal & Goel       Expires March 27, 2007                 [Page 5] 
-
diff --git a/doc/protocol/draft-ietf-tls-psk-null-02.txt b/doc/protocol/draft-ietf-tls-psk-null-02.txt
deleted file mode 100644
index 24fe032af5..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-null-02.txt
+++ /dev/null
@@ -1,261 +0,0 @@
-TLS Working Group                                         U. Blumenthal 
-Internet Draft                                                  P. Goel 
-Expires: April 2007                                   Intel Corporation 
-                                                        October 3, 2006 
-                                    
- 
-                                      
-          Pre-Shared Key Cipher Suites with NULL Encryption for 
-                      Transport Layer Security (TLS) 
-
-
-                      draft-ietf-tls-psk-null-02.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that       
-   any applicable patent or other IPR claims of which he or she is       
-   aware have been or will be disclosed, and any of which he or she       
-   becomes aware will be disclosed, in accordance with Section 6 of       
-   BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on April 3, 2007. 
-
-Abstract 
-
-   This document specifies authentication-only cipher suites for the 
-   Pre-Shared Key based Transport Layer Security (TLS) protocol to 
-   support null encryption. These cipher suites are useful for countries 
-   and places with cryptography-related restrictions.  
-
-
- 
- 
- 
-Blumenthal & Goel       Expires April 3, 2007                  [Page 1] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-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 [RFC2119]. 
-
-Table of Contents 
-
-    
-   1. Introduction...................................................2 
-   2. Cipher Usage...................................................2 
-   3. Security Considerations........................................3 
-   4. IANA Considerations............................................3 
-   5. Acknowledgments................................................3 
-   6. References.....................................................4 
-      6.1. Normative References......................................4 
-   Author's Addresses................................................4 
-   Intellectual Property Statement...................................4 
-   Disclaimer of Validity............................................5 
-   Copyright Statement...............................................5 
-   Acknowledgment....................................................5 
-    
-1. Introduction 
-
-   The RFC for Pre-Shared Key based TLS [TLS-PSK] specifies cipher 
-   suites for supporting TLS using pre-shared symmetric keys. However 
-   all the cipher suites defined in [TLS-PSK] require encryption. There 
-   is a need for cipher suites that support no encryption. This is 
-   required for implementations to meet import restrictions in some 
-   countries. Even though no encryption is used, these cipher suites 
-   support authentication of the client and server to each other, and 
-   message integrity. This document augments [TLS-PSK] by adding three 
-   more cipher suites (PSK, DHE_PSK, RSA_PSK) with authentication and 
-   integrity only - no encryption. 
-
-    
-
-2. Cipher Usage 
-
-   The new cipher suites proposed here is very similar to cipher suites 
-   defined in [TLS-PSK], except that they define null encryption. 
-
-   The cipher suites defined here use the following options for key 
-   exchange and hash part of the protocol: 
-
- 
- 
-Blumenthal & Goel       Expires April 3, 2007                  [Page 2] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-    
-
-   CipherSuite                     Key Exchange   Cipher      Hash 
-
-   TLS_PSK_WITH_NULL_SHA           PSK            NULL        SHA 
-   TLS_DHE_PSK_WITH_NULL_SHA       DHE_PSK        NULL        SHA 
-   TLS_RSA_PSK_WITH_NULL_SHA       RSA_PSK        NULL        SHA 
-    
-   For the meaning of the terms PSK please refer to section 1 in [TLS-
-   PSK]. For the meaning of the terms DHE and RSA please refer to 
-   section 7.4.2 in [TLS]. 
-
-3. Security Considerations 
-
-   As with all schemes involving shared keys, special care should be 
-   taken to protect the shared values and to limit their exposure over 
-   time. As this document augments [TLS-PSK], everything stated in its 
-   Security Consideration section applies here. In addition, as cipher 
-   suites defined here do not support confidentiality - care should be 
-   taken not to send sensitive information (such as passwords) over 
-   connection protected with one of the cipher suites defined in this 
-   document. 
-
-4. IANA Considerations 
-
-   This document defines three new cipher suites, whose values are to be 
-   assigned from the TLS Cipher Suite registry defined in [TLS]. 
-
-   CipherSuite   TLS_PSK_WITH_NULL_SHA      = { 0x00, 0xTBD1 }; 
-   CipherSuite   TLS_DHE_PSK_WITH_NULL_SHA  = { 0x00, 0xTBD2 }; 
-   CipherSuite   TLS_RSA_PSK_WITH_NULL_SHA  = { 0x00, 0xTBD3 }; 
-    
-5. Acknowledgments 
-
-   The cipher suites defined in this document are an augmentation to and 
-   based on [TLS-PSK]. 
-
-
-
-
-
- 
- 
-Blumenthal & Goel       Expires April 3, 2007                  [Page 3] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-6. References 
-
-6.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [TLS]     Dierks, T. and Rescorla, E., "The TLS Protocol Version 
-             1.1", RFC 4346, April 2006. 
-
-   [TLS-PSK] Eronen, P., Tschofenig, H., "Pre-Shared Key CipherSuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005. 
-
-    
-
-Author's Addresses 
-
-   Uri Blumenthal 
-   Intel Corporation 
-   1515 State Route 10,  
-   PY2-1 10-4 
-   Parsippany, NJ 07054 
-   USA 
-       
-   Email: Uri.Blumenthal@intel.com 
-    
-
-   Purushottam Goel 
-   Intel Corporation 
-   2111 N.E. 25 Ave. 
-   JF3-414 
-   Hillsboro, OR 97124 
-   USA 
-       
-   Email: Purushottam.Goel@intel.com 
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
- 
- 
-Blumenthal & Goel       Expires April 3, 2007                  [Page 4] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The Internet Society (2006). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
-
-
-
-
-
- 
- 
-Blumenthal & Goel       Expires April 3, 2007                  [Page 5] 
-
diff --git a/doc/protocol/draft-ietf-tls-psk-null-03.txt b/doc/protocol/draft-ietf-tls-psk-null-03.txt
deleted file mode 100644
index 20ac868f74..0000000000
--- a/doc/protocol/draft-ietf-tls-psk-null-03.txt
+++ /dev/null
@@ -1,261 +0,0 @@
-TLS Working Group                                         U. Blumenthal 
-Internet Draft                                                  P. Goel 
-Expires: April 2007                                   Intel Corporation 
-                                                       October 20, 2006 
-                                    
- 
-                                      
-          Pre-Shared Key Cipher Suites with NULL Encryption for 
-                      Transport Layer Security (TLS) 
-
-
-                      draft-ietf-tls-psk-null-03.txt 
-
-
-Status of this Memo 
-
-   By submitting this Internet-Draft, each author represents that       
-   any applicable patent or other IPR claims of which he or she is       
-   aware have been or will be disclosed, and any of which he or she       
-   becomes aware will be disclosed, in accordance with Section 6 of       
-   BCP 79. 
-
-   Internet-Drafts are working documents of the Internet Engineering 
-   Task Force (IETF), its areas, and its working groups.  Note that 
-   other groups may also distribute working documents as Internet-
-   Drafts. 
-
-   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 
-
-   This Internet-Draft will expire on April 20, 2007. 
-
-Abstract 
-
-   This document specifies authentication-only cipher suites (with no 
-   encryption) for the Pre-Shared Key based Transport Layer Security 
-   (TLS) protocol. These cipher suites are useful when authentication 
-   and integrity protection is desired, but confidentiality is not 
-   needed or not permitted. 
-
- 
- 
- 
-Blumenthal & Goel       Expires April 20, 2007                 [Page 1] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-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 [RFC2119]. 
-
-Table of Contents 
-
-    
-   1. Introduction...................................................2 
-   2. Cipher Usage...................................................2 
-   3. Security Considerations........................................3 
-   4. IANA Considerations............................................3 
-   5. Acknowledgments................................................3 
-   6. References.....................................................4 
-      6.1. Normative References......................................4 
-   Author's Addresses................................................4 
-   Intellectual Property Statement...................................5 
-   Disclaimer of Validity............................................5 
-   Copyright Statement...............................................5 
-   Acknowledgment....................................................4 
-    
-1. Introduction 
-
-   The RFC for Pre-Shared Key based TLS [TLS-PSK] specifies cipher 
-   suites for supporting TLS using pre-shared symmetric keys. However 
-   all the cipher suites defined in [TLS-PSK] require encryption. 
-   However there are cases when only authentication and integrity 
-   protection is required, and confidentiality is not needed. There are 
-   also cases when confidentiality is not permitted -  e.g. for 
-   implementations that must meet import restrictions in some countries. 
-   Even though no encryption is used, these cipher suites support 
-   authentication of the client and server to each other, and message 
-   integrity. This document augments [TLS-PSK] by adding three more 
-   cipher suites (PSK, DHE_PSK, RSA_PSK) with authentication and 
-   integrity only - no encryption. The reader is expected to become 
-   familiar with [TLS-PSK] standard prior to studying this document. 
-
-    
-
-2. Cipher Usage 
-
-   The three new cipher suites proposed here match the three cipher 
-   suites defined in [TLS-PSK], except that we define suites with null 
-   encryption. 
- 
- 
-Blumenthal & Goel       Expires April 20, 2007                 [Page 2] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-   The cipher suites defined here use the following options for key 
-   exchange and hash part of the protocol: 
-
-    
-
-   CipherSuite                     Key Exchange   Cipher      Hash 
-
-   TLS_PSK_WITH_NULL_SHA           PSK            NULL        SHA 
-   TLS_DHE_PSK_WITH_NULL_SHA       DHE_PSK        NULL        SHA 
-   TLS_RSA_PSK_WITH_NULL_SHA       RSA_PSK        NULL        SHA 
-    
-   For the meaning of the terms PSK please refer to section 1 in [TLS-
-   PSK]. For the meaning of the terms DHE, RSA and SHA please refer to 
-   sections A.5 and Appendix B in [TLS].  
-
-3. Security Considerations 
-
-   As with all schemes involving shared keys, special care should be 
-   taken to protect the shared values and to limit their exposure over 
-   time. As this document augments [TLS-PSK], everything stated in its 
-   Security Consideration section applies here. In addition, as cipher 
-   suites defined here do not support confidentiality - care should be 
-   taken not to send sensitive information (such as passwords) over 
-   connection protected with one of the cipher suites defined in this 
-   document. 
-
-4. IANA Considerations 
-
-   This document defines three new cipher suites, whose values are to be 
-   assigned from the TLS Cipher Suite registry defined in [TLS]. 
-
-   CipherSuite   TLS_PSK_WITH_NULL_SHA      = { 0x00, 0xTBD1 }; 
-   CipherSuite   TLS_DHE_PSK_WITH_NULL_SHA  = { 0x00, 0xTBD2 }; 
-   CipherSuite   TLS_RSA_PSK_WITH_NULL_SHA  = { 0x00, 0xTBD3 }; 
-    
-5. Acknowledgments 
-
-   The cipher suites defined in this document are an augmentation to and 
-   based on [TLS-PSK]. 
-
-
- 
- 
-Blumenthal & Goel       Expires April 20, 2007                 [Page 3] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-6. References 
-
-6.1. Normative References 
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
-             Requirement Levels", BCP 14, RFC 2119, March 1997. 
-
-   [TLS]     Dierks, T. and Rescorla, E., "The TLS Protocol Version 
-             1.1", RFC 4346, April 2006. 
-
-   [TLS-PSK] Eronen, P., Tschofenig, H., "Pre-Shared Key CipherSuites 
-             for Transport Layer Security (TLS)", RFC 4279, December 
-             2005. 
-
-    
-
-Author's Addresses 
-
-   Uri Blumenthal 
-   Intel Corporation 
-   1515 State Route 10,  
-   PY2-1 10-4 
-   Parsippany, NJ 07054 
-   USA 
-       
-   Email: Uri.Blumenthal@intel.com 
-    
-
-   Purushottam Goel 
-   Intel Corporation 
-   2111 N.E. 25 Ave. 
-   JF3-414 
-   Hillsboro, OR 97124 
-   USA 
-       
-   Email: Purushottam.Goel@intel.com 
- 
-
- 
-
-Acknowledgment 
-
-   Funding for the RFC Editor function is currently provided by the 
-   Internet Society. 
-
- 
- 
-Blumenthal & Goel       Expires April 20, 2007                 [Page 4] 
-
-Internet-Draft   PSK NULL-encryption Cipher Suites for TLS    October 
-2006 
-    
-
-    
-
-Intellectual Property Statement 
-
-   The IETF takes no position regarding the validity or scope of any 
-   Intellectual Property Rights or other rights that might be claimed to 
-   pertain to the implementation or use of the technology described in 
-   this document or the extent to which any license under such rights 
-   might or might not be available; nor does it represent that it has 
-   made any independent effort to identify any such rights.  Information 
-   on the procedures with respect to rights in RFC documents can be 
-   found in BCP 78 and BCP 79. 
-
-   Copies of IPR disclosures made to the IETF Secretariat and any 
-   assurances of licenses to be made available, or the result of an 
-   attempt made to obtain a general license or permission for the use of 
-   such proprietary rights by implementers or users of this 
-   specification can be obtained from the IETF on-line IPR repository at 
-   http://www.ietf.org/ipr. 
-
-   The IETF invites any interested party to bring to its attention any 
-   copyrights, patents or patent applications, or other proprietary 
-   rights that may cover technology that may be required to implement 
-   this standard.  Please address the information to the IETF at 
-   ietf-ipr@ietf.org. 
-
-Disclaimer of Validity 
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
-
-Copyright Statement 
-
-   Copyright (C) The Internet Society (2006). 
-
-   This document is subject to the rights, licenses and restrictions 
-   contained in BCP 78, and except as set forth therein, the authors 
-   retain all their rights. 
-
-  
- 
- 
-Blumenthal & Goel       Expires April 20, 2007                 [Page 5] 
-
diff --git a/doc/protocol/draft-ietf-tls-rfc2246-bis-06.txt b/doc/protocol/draft-ietf-tls-rfc2246-bis-06.txt
deleted file mode 100644
index 5c59051b6a..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc2246-bis-06.txt
+++ /dev/null
@@ -1,5756 +0,0 @@
-

-

-                                                              Tim Dierks |

-                                                                  Google |

-                                                           Eric Rescorla |

-INTERNET-DRAFT                                                RTFM, Inc. |

-<draft-ietf-tls-rfc2246-bis-06.txt>  March 2004 (Expires September 2004) |

-

-

-                            The TLS Protocol

-                              Version 1.1                                |

-

-

-Status of this Memo

-

-

-   This document is an Internet-Draft and is in full conformance with    |

-   all provisions of Section 10 of RFC2026.  Internet-Drafts are working |

-   documents of the Internet Engineering Task Force (IETF), its areas,   |

-   and its working groups.  Note that other groups may also distribute   |

-   working documents as Internet-Drafts.                                 |

-

-

-   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."            |

-

-

-   To learn the current status of any Internet-Draft, please check the   |

-   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow   |

-   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),         |

-   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or         |

-   ftp.isi.edu (US West Coast).

-Copyright Notice

-

-

-   Copyright (C) The Internet Society (1999-2004).  All Rights Reserved. |

-

-

-Abstract

-

-

-   This document specifies Version 1.1 of the Transport Layer Security   |

-   (TLS) protocol. The TLS protocol provides communications security

-   over the Internet. The protocol allows client/server applications to

-   communicate in a way that is designed to prevent eavesdropping,

-   tampering, or message forgery.

-

-

-Table of Contents

-

-

-   1.       Introduction                                              3

-   2.       Goals                                                     4

-   3.       Goals of this document                                    5

-   4.       Presentation language                                     5

-   4.1.     Basic block size                                          6

-   4.2.     Miscellaneous                                             6

-   4.3.     Vectors                                                   6

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 1] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   4.4.     Numbers                                                   7

-   4.5.     Enumerateds                                               7

-   4.6.     Constructed types                                         8

-   4.6.1.   Variants                                                  9

-   4.7.     Cryptographic attributes                                 10

-   4.8.     Constants                                                11

-   5.       HMAC and the pseudorandom function                       11

-   6.       The TLS Record Protocol                                  13

-   6.1.     Connection states                                        14

-   6.2.     Record layer                                             16

-   6.2.1.   Fragmentation                                            16

-   6.2.2.   Record compression and decompression                     17

-   6.2.3.   Record payload protection                                18

-   6.2.3.1. Null or standard stream cipher                           19

-   6.2.3.2. CBC block cipher                                         19

-   6.3.     Key calculation                                          21

-   6.3.1.   Export key generation example                            22

-   7.       The TLS Handshake Protocol                               23

-   7.1.     Change cipher spec protocol                              24

-   7.2.     Alert protocol                                           24

-   7.2.1.   Closure alerts                                           25

-   7.2.2.   Error alerts                                             26

-   7.3.     Handshake Protocol overview                              29

-   7.4.     Handshake protocol                                       32

-   7.4.1.   Hello messages                                           33

-   7.4.1.1. Hello request                                            33

-   7.4.1.2. Client hello                                             34

-   7.4.1.3. Server hello                                             36

-   7.4.2.   Server certificate                                       37

-   7.4.3.   Server key exchange message                              39

-   7.4.4.   Certificate request                                      41

-   7.4.5.   Server hello done                                        42

-   7.4.6.   Client certificate                                       43

-   7.4.7.   Client key exchange message                              43

-   7.4.7.1. RSA encrypted premaster secret message                   44

-   7.4.7.2. Client Diffie-Hellman public value                       45

-   7.4.8.   Certificate verify                                       45

-   7.4.9.   Finished                                                 46

-   8.       Cryptographic computations                               47

-   8.1.     Computing the master secret                              47

-   8.1.1.   RSA                                                      48

-   8.1.2.   Diffie-Hellman                                           48

-   9.       Mandatory Cipher Suites                                  48

-   10.      Application data protocol                                48

-   A.       Protocol constant values                                 49

-   A.1.     Record layer                                             49

-   A.2.     Change cipher specs message                              50

-   A.3.     Alert messages                                           50

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 2] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   A.4.     Handshake protocol                                       51

-   A.4.1.   Hello messages                                           51

-   A.4.2.   Server authentication and key exchange messages          52

-   A.4.3.   Client authentication and key exchange messages          53

-   A.4.4.   Handshake finalization message                           54

-   A.5.     The CipherSuite                                          54

-   A.6.     The Security Parameters                                  56

-   B.       Glossary                                                 57

-   C.       CipherSuite definitions                                  61

-   D.       Implementation Notes                                     64

-   D.1.     Temporary RSA keys                                       64

-   D.2.     Random Number Generation and Seeding                     64

-   D.3.     Certificates and authentication                          65

-   D.4.     CipherSuites                                             65

-   E.       Backward Compatibility With SSL                          66

-   E.1.     Version 2 client hello                                   67

-   E.2.     Avoiding man-in-the-middle version rollback              68

-   F.       Security analysis                                        69

-   F.1.     Handshake protocol                                       69

-   F.1.1.   Authentication and key exchange                          69

-   F.1.1.1. Anonymous key exchange                                   69

-   F.1.1.2. RSA key exchange and authentication                      70

-   F.1.1.3. Diffie-Hellman key exchange with authentication          71

-   F.1.2.   Version rollback attacks                                 71

-   F.1.3.   Detecting attacks against the handshake protocol         72

-   F.1.4.   Resuming sessions                                        72

-   F.1.5.   MD5 and SHA                                              72

-   F.2.     Protecting application data                              72

-   F.3.     Final notes                                              73

-   G.       Patent Statement                                         74

-            Security Considerations                                  75

-            References                                               75

-            Credits                                                  77

-            Comments                                                 78

-            Full Copyright Statement                   80

-

-

-Change history                                                           |

-

-

-   Note: Change bars in this draft are from RFC 2246, not draft-00       |

-

-

-   26-Jun-03 ekr@rtfm.com                                                |

-    * Incorporated Last Call comments from Franke Marcus, Jack Lloyd,    |

-    Brad Wetmore, and others.                                            |

-

-

-   22-Apr-03 ekr@rtfm.com                                                |

-    * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks           |

-    * cleaned up IV text a bit.                                          |

-    * Added discussion of Denial of Service attacks.                     |

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 3] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-                                                                         |

-   11-Feb-02 ekr@rtfm.com                                                |

-    * Clarified the behavior of empty certificate lists [Nelson Bolyard] |

-    * Added text explaining the security implications of authenticate    |

-      then encrypt.                                                      |

-    * Cleaned up the explicit IV text.                                   |

-    * Added some more acknowledgement names                              |

-

-

-   02-Nov-02 ekr@rtfm.com                                                |

-    * Changed this to be TLS 1.1.                                        |

-    * Added fixes for the Rogaway and Vaudenay CBC attacks               |

-    * Separated references into normative and informative                |

-

-

-   01-Mar-02 ekr@rtfm.com                                                |

-    * Tightened up the language in F.1.1.2 [Peter Watkins]               |

-    * Fixed smart quotes [Bodo Moeller]                                  |

-    * Changed handling of padding errors to prevent CBC-based attack     |

-      [Bodo Moeller]                                                     |

-    * Fixed certificate_list spec in the appendix [Aman Sawrup]          |

-    * Fixed a bug in the V2 definitions [Aman Sawrup]                    |

-    * Fixed S 7.2.1 to point out that you don't need a close notify      |

-      if you just sent some other fatal alert [Andreas Sterbenz]         |

-    * Marked alert 41 reserved [Andreas Sterbenz]                        |

-    * Changed S 7.4.2 to point out that 512-bit keys cannot be used for  |

-      signing [Andreas Sterbenz]                                         |

-    * Added reserved client key types from SSLv3 [Andreas Sterbenz]      |

-    * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz]      |

-    * Removed RSA patent statement [Andreas Sterbenz]                    |

-    * Removed references to BSAFE and RSAREF [Andreas Sterbenz]          |

-

-

-   14-Feb-02 ekr@rtfm.com                                                |

-    * Re-converted to I-D from RFC                                       |

-    * Made RSA/3DES the mandatory cipher suite.                          |

-    * Added discussion of the EncryptedPMS encoding and PMS version number|

-      issues to 7.4.7.1                                                  |

-    * Removed the requirement in 7.4.1.3 that the Server random must be  |

-      different from the Client random, since these are randomly generated|

-      and we don't expect servers to reject Server random values which   |

-      coincidentally are the same as the Client random.                  |

-    * Replaced may/should/must with MAY/SHOULD/MUST where appropriate.   |

-      In many cases, shoulds became MUSTs, where I believed that was the |

-      actual sense of the text. Added an RFC 2119 bulletin.              |

-   * Clarified the meaning of "empty certificate" message. [Peter Gutmann]|

-   * Redid the CertificateRequest grammar to allow no distinguished names.|

-     [Peter Gutmann]                                                     |

-   * Removed the reference to requiring the master secret to generate    |

-     the CertificateVerify in F.1.1 [Bodo Moeller]                       |

-   * Deprecated EXPORT40.                                                |

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 4] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   * Fixed a bunch of errors in the SSLv2 backward compatible client hello.|

-

-

-1. Introduction

-

-

-   The primary goal of the TLS Protocol is to provide privacy and data

-   integrity between two communicating applications. The protocol is

-   composed of two layers: the TLS Record Protocol and the TLS Handshake

-   Protocol. At the lowest level, layered on top of some reliable

-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The

-   TLS Record Protocol provides connection security that has two basic

-   properties:

-

-

-     - - The connection is private. Symmetric cryptography is used for

-       data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for

-       this symmetric encryption are generated uniquely for each

-       connection and are based on a secret negotiated by another

-       protocol (such as the TLS Handshake Protocol). The Record

-       Protocol can also be used without encryption.

-

-

-     - - The connection is reliable. Message transport includes a

-       message integrity check using a keyed MAC. Secure hash functions

-       (e.g., SHA, MD5, etc.) are used for MAC computations. The Record

-       Protocol can operate without a MAC, but is generally only used in

-       this mode while another protocol is using the Record Protocol as

-       a transport for negotiating security parameters.

-

-

-   The TLS Record Protocol is used for encapsulation of various higher

-   level protocols. One such encapsulated protocol, the TLS Handshake

-   Protocol, allows the server and client to authenticate each other and

-   to negotiate an encryption algorithm and cryptographic keys before

-   the application protocol transmits or receives its first byte of

-   data. The TLS Handshake Protocol provides connection security that

-   has three basic properties:

-

-

-     - - The peer's identity can be authenticated using asymmetric, or

-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This

-       authentication can be made optional, but is generally required

-       for at least one of the peers.

-

-

-     - - The negotiation of a shared secret is secure: the negotiated    |

-       secret is unavailable to eavesdroppers, and for any authenticated

-       connection the secret cannot be obtained, even by an attacker who

-       can place himself in the middle of the connection.

-

-

-     - - The negotiation is reliable: no attacker can modify the

-       negotiation communication without being detected by the parties

-       to the communication.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 5] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   One advantage of TLS is that it is application protocol independent.

-   Higher level protocols can layer on top of the TLS Protocol

-   transparently. The TLS standard, however, does not specify how

-   protocols add security with TLS; the decisions on how to initiate TLS

-   handshaking and how to interpret the authentication certificates

-   exchanged are left up to the judgment of the designers and

-   implementors of protocols which run on top of TLS.

-

-

-1.1 Requirements Terminology                                             |

-

-

-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and   |

-   "MAY" that appear in this document are to be interpreted as described |

-   in RFC 2119 [REQ].                                                    |

-

-

-2. Goals

-

-

-   The goals of TLS Protocol, in order of their priority, are:

-

-

-    1. Cryptographic security: TLS should be used to establish a secure

-       connection between two parties.

-

-

-    2. Interoperability: Independent programmers should be able to

-       develop applications utilizing TLS that will then be able to

-       successfully exchange cryptographic parameters without knowledge

-       of one another's code.

-

-

-    3. Extensibility: TLS seeks to provide a framework into which new

-       public key and bulk encryption methods can be incorporated as

-       necessary. This will also accomplish two sub-goals: to prevent

-       the need to create a new protocol (and risking the introduction

-       of possible new weaknesses) and to avoid the need to implement an

-       entire new security library.

-

-

-    4. Relative efficiency: Cryptographic operations tend to be highly

-       CPU intensive, particularly public key operations. For this

-       reason, the TLS protocol has incorporated an optional session

-       caching scheme to reduce the number of connections that need to

-       be established from scratch. Additionally, care has been taken to

-       reduce network activity.

-

-

-3. Goals of this document

-

-

-   This document and the TLS protocol itself are based on the SSL 3.0

-   Protocol Specification as published by Netscape. The differences

-   between this protocol and SSL 3.0 are not dramatic, but they are

-   significant enough that TLS 1.0 and SSL 3.0 do not interoperate

-   (although TLS 1.0 does incorporate a mechanism by which a TLS

-   implementation can back down to SSL 3.0). This document is intended

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 6] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   primarily for readers who will be implementing the protocol and those

-   doing cryptographic analysis of it. The specification has been

-   written with this in mind, and it is intended to reflect the needs of

-   those two groups. For that reason, many of the algorithm-dependent

-   data structures and rules are included in the body of the text (as

-   opposed to in an appendix), providing easier access to them.

-

-

-   This document is not intended to supply any details of service

-   definition nor interface definition, although it does cover select

-   areas of policy as they are required for the maintenance of solid

-   security.

-

-

-4. Presentation language

-

-

-   This document deals with the formatting of data in an external

-   representation. The following very basic and somewhat casually

-   defined presentation syntax will be used. The syntax draws from

-   several sources in its structure. Although it resembles the

-   programming language "C" in its syntax and XDR [XDR] in both its

-   syntax and intent, it would be risky to draw too many parallels. The

-   purpose of this presentation language is to document TLS only, not to

-   have general application beyond that particular goal.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 7] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-4.1. Basic block size

-

-

-   The representation of all data items is explicitly specified. The

-   basic data block size is one byte (i.e. 8 bits). Multiple byte data

-   items are concatenations of bytes, from left to right, from top to

-   bottom. From the bytestream a multi-byte item (a numeric in the

-   example) is formed (using C notation) by:

-

-

-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |

-               ... | byte[n-1];

-

-

-   This byte ordering for multi-byte values is the commonplace network

-   byte order or big endian format.

-

-

-4.2. Miscellaneous

-

-

-   Comments begin with "/*" and end with "*/".

-

-

-   Optional components are denoted by enclosing them in "[[ ]]" double

-   brackets.

-

-

-   Single byte entities containing uninterpreted data are of type

-   opaque.

-

-

-4.3. Vectors

-

-

-   A vector (single dimensioned array) is a stream of homogeneous data

-   elements. The size of the vector may be specified at documentation

-   time or left unspecified until runtime. In either case the length

-   declares the number of bytes, not the number of elements, in the

-   vector. The syntax for specifying a new type T' that is a fixed

-   length vector of type T is

-

-

-       T T'[n];

-

-

-   Here T' occupies n bytes in the data stream, where n is a multiple of

-   the size of T. The length of the vector is not included in the

-   encoded stream.

-

-

-   In the following example, Datum is defined to be three consecutive

-   bytes that the protocol does not interpret, while Data is three

-   consecutive Datum, consuming a total of nine bytes.

-

-

-       opaque Datum[3];      /* three uninterpreted bytes */

-       Datum Data[9];        /* 3 consecutive 3 byte vectors */

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 8] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Variable length vectors are defined by specifying a subrange of legal

-   lengths, inclusively, using the notation <floor..ceiling>.  When

-   encoded, the actual length precedes the vector's contents in the byte

-   stream. The length will be in the form of a number consuming as many

-   bytes as required to hold the vector's specified maximum (ceiling)

-   length. A variable length vector with an actual length field of zero

-   is referred to as an empty vector.

-

-

-       T T'<floor..ceiling>;

-

-

-   In the following example, mandatory is a vector that must contain

-   between 300 and 400 bytes of type opaque. It can never be empty. The

-   actual length field consumes two bytes, a uint16, sufficient to

-   represent the value 400 (see Section 4.4). On the other hand, longer

-   can represent up to 800 bytes of data, or 400 uint16 elements, and it

-   may be empty. Its encoding will include a two byte actual length

-   field prepended to the vector. The length of an encoded vector must

-   be an even multiple of the length of a single element (for example, a

-   17 byte vector of uint16 would be illegal).

-

-

-       opaque mandatory<300..400>;

-             /* length field is 2 bytes, cannot be empty */

-       uint16 longer<0..800>;

-             /* zero to 400 16-bit unsigned integers */

-

-

-4.4. Numbers

-

-

-   The basic numeric data type is an unsigned byte (uint8). All larger

-   numeric data types are formed from fixed length series of bytes

-   concatenated as described in Section 4.1 and are also unsigned. The

-   following numeric types are predefined.

-

-

-       uint8 uint16[2];

-       uint8 uint24[3];

-       uint8 uint32[4];

-       uint8 uint64[8];

-

-

-   All values, here and elsewhere in the specification, are stored in

-   "network" or "big-endian" order; the uint32 represented by the hex

-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.

-

-

-4.5. Enumerateds

-

-

-   An additional sparse data type is available called enum. A field of

-   type enum can only assume the values declared in the definition.

-   Each definition is a different type. Only enumerateds of the same

-   type may be assigned or compared. Every element of an enumerated must

-

-

-

-

-

-Dierks & Rescorla            Standards Track                     [Page 9] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   be assigned a value, as demonstrated in the following example.  Since

-   the elements of the enumerated are not ordered, they can be assigned

-   any unique value, in any order.

-

-

-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

-

-

-   Enumerateds occupy as much space in the byte stream as would its

-   maximal defined ordinal value. The following definition would cause

-   one byte to be used to carry fields of type Color.

-

-

-       enum { red(3), blue(5), white(7) } Color;

-

-

-   One may optionally specify a value without its associated tag to

-   force the width definition without defining a superfluous element.

-   In the following example, Taste will consume two bytes in the data

-   stream but can only assume the values 1, 2 or 4.

-

-

-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

-

-

-   The names of the elements of an enumeration are scoped within the

-   defined type. In the first example, a fully qualified reference to

-   the second element of the enumeration would be Color.blue. Such

-   qualification is not required if the target of the assignment is well

-   specified.

-

-

-       Color color = Color.blue;     /* overspecified, legal */

-       Color color = blue;           /* correct, type implicit */

-

-

-   For enumerateds that are never converted to external representation,

-   the numerical information may be omitted.

-

-

-       enum { low, medium, high } Amount;

-

-

-4.6. Constructed types

-

-

-   Structure types may be constructed from primitive types for

-   convenience. Each specification declares a new, unique type. The

-   syntax for definition is much like that of C.

-

-

-       struct {

-         T1 f1;

-         T2 f2;

-         ...

-         Tn fn;

-       } [[T]];

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 10] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   The fields within a structure may be qualified using the type's name

-   using a syntax much like that available for enumerateds. For example,

-   T.f2 refers to the second field of the previous declaration.

-   Structure definitions may be embedded.

-

-

-4.6.1. Variants

-

-

-   Defined structures may have variants based on some knowledge that is

-   available within the environment. The selector must be an enumerated

-   type that defines the possible variants the structure defines. There

-   must be a case arm for every element of the enumeration declared in

-   the select. The body of the variant structure may be given a label

-   for reference. The mechanism by which the variant is selected at

-   runtime is not prescribed by the presentation language.

-

-

-       struct {

-           T1 f1;

-           T2 f2;

-           ....

-           Tn fn;

-           select (E) {

-               case e1: Te1;

-               case e2: Te2;

-               ....

-               case en: Ten;

-           } [[fv]];

-       } [[Tv]];

-

-

-   For example:

-

-

-       enum { apple, orange } VariantTag;

-       struct {

-           uint16 number;

-           opaque string<0..10>; /* variable length */

-       } V1;

-       struct {

-           uint32 number;

-           opaque string[10];    /* fixed length */

-       } V2;

-       struct {

-           select (VariantTag) { /* value of selector is implicit */

-               case apple: V1;   /* VariantBody, tag = apple */

-               case orange: V2;  /* VariantBody, tag = orange */

-           } variant_body;       /* optional label on variant */

-       } VariantRecord;

-

-

-   Variant structures may be qualified (narrowed) by specifying a value

-   for the selector prior to the type. For example, a

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 11] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       orange VariantRecord

-

-

-   is a narrowed type of a VariantRecord containing a variant_body of

-   type V2.

-

-

-4.7. Cryptographic attributes

-

-

-   The four cryptographic operations digital signing, stream cipher

-   encryption, block cipher encryption, and public key encryption are

-   designated digitally-signed, stream-ciphered, block-ciphered, and

-   public-key-encrypted, respectively. A field's cryptographic

-   processing is specified by prepending an appropriate key word

-   designation before the field's type specification. Cryptographic keys

-   are implied by the current session state (see Section 6.1).

-

-

-   In digital signing, one-way hash functions are used as input for a

-   signing algorithm. A digitally-signed element is encoded as an opaque

-   vector <0..2^16-1>, where the length is specified by the signing

-   algorithm and key.

-

-

-   In RSA signing, a 36-byte structure of two hashes (one SHA and one

-   MD5) is signed (encrypted with the private key). It is encoded with

-   PKCS #1 block type 0 or type 1 as described in [PKCS1].

-

-

-   In DSS, the 20 bytes of the SHA hash are run directly through the

-   Digital Signing Algorithm with no additional hashing. This produces

-   two values, r and s. The DSS signature is an opaque vector, as above,

-   the contents of which are the DER encoding of:

-

-

-       Dss-Sig-Value  ::=  SEQUENCE  {

-            r       INTEGER,

-            s       INTEGER

-       }

-

-

-   In stream cipher encryption, the plaintext is exclusive-ORed with an

-   identical amount of output generated from a cryptographically-secure

-   keyed pseudorandom number generator.

-

-

-   In block cipher encryption, every block of plaintext encrypts to a

-   block of ciphertext. All block cipher encryption is done in CBC

-   (Cipher Block Chaining) mode, and all items which are block-ciphered

-   will be an exact multiple of the cipher block length.

-

-

-   In public key encryption, a public key algorithm is used to encrypt

-   data in such a way that it can be decrypted only with the matching

-   private key. A public-key-encrypted element is encoded as an opaque

-   vector <0..2^16-1>, where the length is specified by the signing

-   algorithm and key.

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 12] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   An RSA encrypted value is encoded with PKCS #1 block type 2 as

-   described in [PKCS1].

-

-

-   In the following example:

-

-

-       stream-ciphered struct {

-           uint8 field1;

-           uint8 field2;

-           digitally-signed opaque hash[20];

-       } UserType;

-

-

-   The contents of hash are used as input for the signing algorithm,

-   then the entire structure is encrypted with a stream cipher. The

-   length of this structure, in bytes would be equal to 2 bytes for

-   field1 and field2, plus two bytes for the length of the signature,

-   plus the length of the output of the signing algorithm. This is known

-   due to the fact that the algorithm and key used for the signing are

-   known prior to encoding or decoding this structure.

-

-

-4.8. Constants

-

-

-   Typed constants can be defined for purposes of specification by

-   declaring a symbol of the desired type and assigning values to it.

-   Under-specified types (opaque, variable length vectors, and

-   structures that contain opaque) cannot be assigned values. No fields

-   of a multi-element structure or vector may be elided.

-

-

-   For example,

-

-

-       struct {

-           uint8 f1;

-           uint8 f2;

-       } Example1;

-

-

-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */

-

-

-5. HMAC and the pseudorandom function

-

-

-   A number of operations in the TLS record and handshake layer required

-   a keyed MAC; this is a secure digest of some data protected by a

-   secret. Forging the MAC is infeasible without knowledge of the MAC

-   secret. The construction we use for this operation is known as HMAC,

-   described in [HMAC].

-

-

-   HMAC can be used with a variety of different hash algorithms. TLS

-   uses it in the handshake with two different algorithms: MD5 and

-   SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 13] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   data). Additional hash algorithms can be defined by cipher suites and

-   used to protect record data, but MD5 and SHA-1 are hard coded into

-   the description of the handshaking for this version of the protocol.

-

-

-   In addition, a construction is required to do expansion of secrets

-   into blocks of data for the purposes of key generation or validation.

-   This pseudo-random function (PRF) takes as input a secret, a seed,

-   and an identifying label and produces an output of arbitrary length.

-

-

-   In order to make the PRF as secure as possible, it uses two hash

-   algorithms in a way which should guarantee its security if either

-   algorithm remains secure.

-

-

-   First, we define a data expansion function, P_hash(secret, data)

-   which uses a single hash function to expand a secret and seed into an

-   arbitrary quantity of output:

-

-

-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +

-                              HMAC_hash(secret, A(2) + seed) +

-                              HMAC_hash(secret, A(3) + seed) + ...

-

-

-   Where + indicates concatenation.

-

-

-   A() is defined as:

-       A(0) = seed

-       A(i) = HMAC_hash(secret, A(i-1))

-

-

-   P_hash can be iterated as many times as is necessary to produce the

-   required quantity of data. For example, if P_SHA-1 was being used to

-   create 64 bytes of data, it would have to be iterated 4 times

-   (through A(4)), creating 80 bytes of output data; the last 16 bytes

-   of the final iteration would then be discarded, leaving 64 bytes of

-   output data.

-

-

-   TLS's PRF is created by splitting the secret into two halves and

-   using one half to generate data with P_MD5 and the other half to

-   generate data with P_SHA-1, then exclusive-or'ing the outputs of

-   these two expansion functions together.

-

-

-   S1 and S2 are the two halves of the secret and each is the same

-   length. S1 is taken from the first half of the secret, S2 from the

-   second half. Their length is created by rounding up the length of the

-   overall secret divided by two; thus, if the original secret is an odd

-   number of bytes long, the last byte of S1 will be the same as the

-   first byte of S2.

-

-

-       L_S = length in bytes of secret;

-       L_S1 = L_S2 = ceil(L_S / 2);

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 14] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   The secret is partitioned into two halves (with the possibility of

-   one shared byte) as described above, S1 taking the first L_S1 bytes

-   and S2 the last L_S2 bytes.

-

-

-   The PRF is then defined as the result of mixing the two pseudorandom

-   streams by exclusive-or'ing them together.

-

-

-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR

-                                  P_SHA-1(S2, label + seed);

-

-

-   The label is an ASCII string. It should be included in the exact form

-   it is given without a length byte or trailing null character.  For

-   example, the label "slithy toves" would be processed by hashing the

-   following bytes:

-

-

-       73 6C 69 74 68 79 20 74 6F 76 65 73

-

-

-   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20

-   byte outputs, the boundaries of their internal iterations will not be

-   aligned; to generate a 80 byte output will involve P_MD5 being

-   iterated through A(5), while P_SHA-1 will only iterate through A(4).

-

-

-6. The TLS Record Protocol

-

-

-   The TLS Record Protocol is a layered protocol. At each layer,

-   messages may include fields for length, description, and content.

-   The Record Protocol takes messages to be transmitted, fragments the

-   data into manageable blocks, optionally compresses the data, applies

-   a MAC, encrypts, and transmits the result. Received data is

-   decrypted, verified, decompressed, and reassembled, then delivered to

-   higher level clients.

-

-

-   Four record protocol clients are described in this document: the

-   handshake protocol, the alert protocol, the change cipher spec

-   protocol, and the application data protocol. In order to allow

-   extension of the TLS protocol, additional record types can be         |

-   supported by the record protocol. Any new record types SHOULD

-   allocate type values immediately beyond the ContentType values for

-   the four record types described here (see Appendix A.2). If a TLS

-   implementation receives a record type it does not understand, it      |

-   SHOULD just ignore it. Any protocol designed for use over TLS MUST be

-   carefully designed to deal with all possible attacks against it.

-   Note that because the type and length of a record are not protected   |

-   by encryption, care SHOULD be taken to minimize the value of traffic

-   analysis of these values.

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 15] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-6.1. Connection states

-

-

-   A TLS connection state is the operating environment of the TLS Record

-   Protocol. It specifies a compression algorithm, encryption algorithm,

-   and MAC algorithm. In addition, the parameters for these algorithms

-   are known: the MAC secret and the bulk encryption keys for the        |

-   connection in both the read and the write directions. Logically,

-   there are always four connection states outstanding: the current read

-   and write states, and the pending read and write states. All records

-   are processed under the current read and write states. The security

-   parameters for the pending states can be set by the TLS Handshake

-   Protocol, and the Handshake Protocol can selectively make either of

-   the pending states current, in which case the appropriate current

-   state is disposed of and replaced with the pending state; the pending

-   state is then reinitialized to an empty state. It is illegal to make

-   a state which has not been initialized with security parameters a

-   current state. The initial current state always specifies that no

-   encryption, compression, or MAC will be used.

-

-

-   The security parameters for a TLS Connection read and write state are

-   set by providing the following values:

-

-

-   connection end

-       Whether this entity is considered the "client" or the "server" in

-       this connection.

-

-

-   bulk encryption algorithm

-       An algorithm to be used for bulk encryption. This specification

-       includes the key size of this algorithm, how much of that key is

-       secret, whether it is a block or stream cipher, the block size of

-       the cipher (if appropriate), and whether it is considered an

-       "export" cipher.

-

-

-   MAC algorithm

-       An algorithm to be used for message authentication. This

-       specification includes the size of the hash which is returned by

-       the MAC algorithm.

-

-

-   compression algorithm

-       An algorithm to be used for data compression. This specification

-       must include all information the algorithm requires to do

-       compression.

-

-

-   master secret

-       A 48 byte secret shared between the two peers in the connection.

-

-

-   client random

-       A 32 byte value provided by the client.

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 16] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   server random

-       A 32 byte value provided by the server.

-

-

-   These parameters are defined in the presentation language as:

-

-

-       enum { server, client } ConnectionEnd;

-

-

-       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;

-

-

-       enum { stream, block } CipherType;

-

-

-       enum { true, false } IsExportable;

-

-

-       enum { null, md5, sha } MACAlgorithm;

-

-

-       enum { null(0), (255) } CompressionMethod;

-

-

-       /* The algorithms specified in CompressionMethod,

-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */

-

-

-       struct {

-           ConnectionEnd          entity;

-           BulkCipherAlgorithm    bulk_cipher_algorithm;

-           CipherType             cipher_type;

-           uint8                  key_size;

-           uint8                  key_material_length;

-           IsExportable           is_exportable;

-           MACAlgorithm           mac_algorithm;

-           uint8                  hash_size;

-           CompressionMethod      compression_algorithm;

-           opaque                 master_secret[48];

-           opaque                 client_random[32];

-           opaque                 server_random[32];

-       } SecurityParameters;

-

-

-   The record layer will use the security parameters to generate the     |

-   following four items:

-

-

-       client write MAC secret

-       server write MAC secret

-       client write key

-       server write key

-

-

-   The client write parameters are used by the server when receiving and

-   processing records and vice-versa. The algorithm used for generating

-   these items from the security parameters is described in section 6.3.

-

-

-   Once the security parameters have been set and the keys have been

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 17] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   generated, the connection states can be instantiated by making them   |

-   the current states. These current states MUST be updated for each

-   record processed. Each connection state includes the following

-   elements:

-

-

-   compression state

-       The current state of the compression algorithm.

-

-

-   cipher state

-       The current state of the encryption algorithm. This will consist  |

-       of the scheduled key for that connection. For stream ciphers,     |

-       this will also contain whatever the necessary state information   |

-       is to allow the stream to continue to encrypt or decrypt data.

-

-

-   MAC secret

-       The MAC secret for this connection as generated above.

-

-

-   sequence number

-       Each connection state contains a sequence number, which is

-       maintained separately for read and write states. The sequence     |

-       number MUST be set to zero whenever a connection state is made

-       the active state. Sequence numbers are of type uint64 and may not |

-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS             |

-       implementation would need to wrap a sequence number it must       |

-       renegotiate instead. A sequence number is incremented after each

-       record: specifically, the first record which is transmitted under |

-       a particular connection state MUST use sequence number 0.

-

-

-6.2. Record layer

-

-

-   The TLS Record Layer receives uninterpreted data from higher layers

-   in non-empty blocks of arbitrary size.

-

-

-6.2.1. Fragmentation

-

-

-   The record layer fragments information blocks into TLSPlaintext

-   records carrying data in chunks of 2^14 bytes or less. Client message

-   boundaries are not preserved in the record layer (i.e., multiple      |

-   client messages of the same ContentType MAY be coalesced into a       |

-   single TLSPlaintext record, or a single message MAY be fragmented     |

-   across several records).                                              |

-

-

-

-       struct {

-           uint8 major, minor;

-       } ProtocolVersion;

-

-

-       enum {

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 18] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-           change_cipher_spec(20), alert(21), handshake(22),

-           application_data(23), (255)

-       } ContentType;

-

-

-       struct {

-           ContentType type;

-           ProtocolVersion version;

-           uint16 length;

-           opaque fragment[TLSPlaintext.length];

-       } TLSPlaintext;

-

-

-   type

-       The higher level protocol used to process the enclosed fragment.

-

-

-   version

-       The version of the protocol being employed. This document         |

-       describes TLS Version 1.1, which uses the version { 3, 2 }. The   |

-       version value 3.2 is historical: TLS version 1.1 is a minor       |

-       modification to the TLS 1.0 protocol, which was itself a minor    |

-       modification to the SSL 3.0 protocol, which bears the version

-       value 3.0. (See Appendix A.1).

-

-

-   length

-       The length (in bytes) of the following TLSPlaintext.fragment.

-       The length should not exceed 2^14.

-

-

-   fragment

-       The application data. This data is transparent and treated as an

-       independent block to be dealt with by the higher level protocol

-       specified by the type field.

-

-

- Note: Data of different TLS Record layer content types MAY be           |

-       interleaved. Application data is generally of lower precedence    |

-       for transmission than other content types and therefore handshake |

-       records may be held if application data is pending.  However,     |

-       records MUST be delivered to the network in the same order as     |

-       they are protected by the record layer.                           |

-

-

-6.2.2. Record compression and decompression

-

-

-   All records are compressed using the compression algorithm defined in

-   the current session state. There is always an active compression

-   algorithm; however, initially it is defined as

-   CompressionMethod.null. The compression algorithm translates a

-   TLSPlaintext structure into a TLSCompressed structure. Compression

-   functions are initialized with default state information whenever a

-   connection state is made active.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 19] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Compression must be lossless and may not increase the content length

-   by more than 1024 bytes. If the decompression function encounters a

-   TLSCompressed.fragment that would decompress to a length in excess of

-   2^14 bytes, it should report a fatal decompression failure error.

-

-

-       struct {

-           ContentType type;       /* same as TLSPlaintext.type */

-           ProtocolVersion version;/* same as TLSPlaintext.version */

-           uint16 length;

-           opaque fragment[TLSCompressed.length];

-       } TLSCompressed;

-

-

-   length

-       The length (in bytes) of the following TLSCompressed.fragment.

-       The length should not exceed 2^14 + 1024.

-

-

-   fragment

-       The compressed form of TLSPlaintext.fragment.

-

-

- Note: A CompressionMethod.null operation is an identity operation; no

-       fields are altered.

-

-

-   Implementation note:

-       Decompression functions are responsible for ensuring that

-       messages cannot cause internal buffer overflows.

-

-

-6.2.3. Record payload protection

-

-

-   The encryption and MAC functions translate a TLSCompressed structure

-   into a TLSCiphertext. The decryption functions reverse the process.

-   The MAC of the record also includes a sequence number so that

-   missing, extra or repeated messages are detectable.

-

-

-       struct {

-           ContentType type;

-           ProtocolVersion version;

-           uint16 length;

-           select (CipherSpec.cipher_type) {

-               case stream: GenericStreamCipher;

-               case block: GenericBlockCipher;

-           } fragment;

-       } TLSCiphertext;

-

-

-   type

-       The type field is identical to TLSCompressed.type.

-

-

-   version

-       The version field is identical to TLSCompressed.version.

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 20] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   length

-       The length (in bytes) of the following TLSCiphertext.fragment.

-       The length may not exceed 2^14 + 2048.

-

-

-   fragment                                                              |

-       The encrypted form of TLSCompressed.fragment, with the MAC.

-

-

-6.2.3.1. Null or standard stream cipher

-

-

-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix

-   A.6) convert TLSCompressed.fragment structures to and from stream

-   TLSCiphertext.fragment structures.

-

-

-       stream-ciphered struct {

-           opaque content[TLSCompressed.length];

-           opaque MAC[CipherSpec.hash_size];

-       } GenericStreamCipher;

-

-

-   The MAC is generated as:

-

-

-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +

-                     TLSCompressed.version + TLSCompressed.length +

-                     TLSCompressed.fragment));

-

-

-   where "+" denotes concatenation.

-

-

-   seq_num

-       The sequence number for this record.

-

-

-   hash

-       The hashing algorithm specified by

-       SecurityParameters.mac_algorithm.

-

-

-   Note that the MAC is computed before encryption. The stream cipher

-   encrypts the entire block, including the MAC. For stream ciphers that

-   do not use a synchronization vector (such as RC4), the stream cipher

-   state from the end of one record is simply used on the subsequent

-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption

-   consists of the identity operation (i.e., the data is not encrypted

-   and the MAC size is zero implying that no MAC is used).

-   TLSCiphertext.length is TLSCompressed.length plus

-   CipherSpec.hash_size.

-

-

-6.2.3.2. CBC block cipher

-

-

-   For block ciphers (such as RC2 or DES), the encryption and MAC

-   functions convert TLSCompressed.fragment structures to and from block

-   TLSCiphertext.fragment structures.

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 21] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       block-ciphered struct {

-           opaque IV[CipherSpec.block_length];                           |

-           opaque content[TLSCompressed.length];

-           opaque MAC[CipherSpec.hash_size];

-           uint8 padding[GenericBlockCipher.padding_length];

-           uint8 padding_length;

-       } GenericBlockCipher;

-

-

-   The MAC is generated as described in Section 6.2.3.1.

-

-

-   IV                                                                    |

-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit |

-       IV in order to prevent the attacks described by [CBCATT].         |

-       We recommend the following equivalently strong procedures.        |

-       For clarity we use the following notation.                        |

-

-

-       IV -- the transmitted value of the IV field in the                |

-           GenericBlockCipher structure.                                 |

-       CBC residue -- the last ciphertext block of the previous record   |

-       mask -- the actual value which the cipher XORs with the           |

-           plaintext prior to encryption of the first cipher block       |

-           of the record.                                                |

-

-

-       In prior versions of TLS, there was no IV field and the CBC residue|

-       and mask were one and the same.                                   |

-

-

-

-       (1) Generate a cryptographically strong random string R of        |

-           length CipherSpec.block_length. Place R                       |

-           in the IV field. Set the mask to R. Thus, the first           |

-           cipher block will be encrypted as E(R XOR Data).              |

-

-

-       (2) Generate a cryptographically strong random number R of        |

-           length CipherSpec.block_length and prepend it to the plaintext|

-           prior to encryption. In                                       |

-           this case either:                                             |

-

-

-           (a)   The cipher may use a fixed mask such as zero.           |

-           (b) The CBC residue from the previous record may be used      |

-               as the mask. This preserves maximum code compatibility    |

-            with TLS 1.0 and SSL 3. It also has the advantage that       |

-            it does not require the ability to quickly reset the IV,     |

-            which is known to be a   problem on some systems.            |

-

-

-            In either case, the data (R || data) is fed into the         |

-            encryption process. The first cipher block (containing       |

-            E(mask XOR R) is placed in the IV field. The first           |

-            block of content contains E(IV XOR data)                     |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 22] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       The following alternative procedure MAY be used: However, it has  |

-       not been demonstrated to be equivalently cryptographically strong |

-       to the above procedures. The sender prepends a fixed block F to   |

-       the plaintext (or alternatively a block generated with a weak     |

-       PRNG). He then encrypts as in (2) above, using the CBC residue    |

-       from the previous block as the mask for the prepended block. Note |

-       that in this case the mask for the first record transmitted by    |

-       the application (the Finished) MUST be generated using a          |

-       cryptographically strong PRNG.                                    |

-

-

-       The decryption operation for all three alternatives is the same.  |

-       The receiver decrypts the entire GenericBlockCipher structure and |

-       then discards the first cipher block, corresponding to the IV     |

-       component.                                                        |

-

-

-   padding

-       Padding that is added to force the length of the plaintext to be

-       an integral multiple of the block cipher's block length. The      |

-       padding MAY be any length up to 255 bytes long, as long as it

-       results in the TLSCiphertext.length being an integral multiple of

-       the block length. Lengths longer than necessary might be

-       desirable to frustrate attacks on a protocol based on analysis of

-       the lengths of exchanged messages. Each uint8 in the padding data |

-       vector MUST be filled with the padding length value. The receiver |

-       MUST check this padding and SHOULD use the bad_record_mac alert   |

-       to indicate padding errors.

-

-

-   padding_length

-       The padding length MUST be such that the total size of the        |

-       GenericBlockCipher structure is a multiple of the cipher's block

-       length. Legal values range from zero to 255, inclusive. This

-       length specifies the length of the padding field exclusive of the

-       padding_length field itself.

-

-

-   The encrypted data length (TLSCiphertext.length) is one more than the

-   sum of TLSCompressed.length, CipherSpec.hash_size, and

-   padding_length.

-

-

- Example: If the block length is 8 bytes, the content length

-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20   |

-          bytes, the length before padding is 82 bytes (this does not    |

-          include the IV, which may or may not be encrypted, as          |

-          discussed above). Thus, the padding length modulo 8 must be

-          equal to 6 in order to make the total length an even multiple

-          of 8 bytes (the block length). The padding length can be 6,

-          14, 22, and so on, through 254. If the padding length were the

-          minimum necessary, 6, the padding would be 6 bytes, each

-          containing the value 6.  Thus, the last 8 octets of the

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 23] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-          GenericBlockCipher before block encryption would be xx 06 06

-          06 06 06 06 06, where xx is the last octet of the MAC.

-

-

- Note: With block ciphers in CBC mode (Cipher Block Chaining),           |

-       it is critical that the entire plaintext of the record be known   |

-       before any ciphertext is transmitted. Otherwise it is possible    |

-       for the attacker to mount the attack described in [CBCATT].       |

-

-

- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a       |

-       timing attack on CBC padding based on the time required to        |

-       compute the MAC. In order to defend against this attack,          |

-       implementations MUST ensure that record processing time is        |

-       essentially the same whether or not the padding is correct.  In   |

-       general, the best way to to do this is to compute the MAC even if |

-       the padding is incorrect, and only then reject the packet. For    |

-       instance, if the pad appears to be incorrect the implementation   |

-       might assume a zero-length pad and then compute the MAC. This     |

-       leaves a small timing channel, since MAC performance depends to   |

-       some extent on the size of the data fragment, but it is not       |

-       believed to be large enough to be exploitable due to the large    |

-       block size of existing MACs and the small size of the timing      |

-       signal.

-

-

-6.3. Key calculation

-

-

-   The Record Protocol requires an algorithm to generate keys, and MAC   |

-   secrets from the security parameters provided by the handshake

-   protocol.

-

-

-   The master secret is hashed into a sequence of secure bytes, which    |

-   are assigned to the MAC secrets and keys required by the current

-   connection state (see Appendix A.6). CipherSpecs require a client

-   write MAC secret, a server write MAC secret, a client write key, and  |

-   a server write key, which are generated from the master secret in     |

-   that order. Unused values are empty.

-

-

-   When generating keys and MAC secrets, the master secret is used as an

-   entropy source, and the random values provide unencrypted salt        |

-   material for exportable ciphers.

-

-

-   To generate the key material, compute

-

-

-       key_block = PRF(SecurityParameters.master_secret,

-                          "key expansion",

-                          SecurityParameters.server_random +

-                          SecurityParameters.client_random);

-

-

-   until enough output has been generated. Then the key_block is

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 24] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   partitioned as follows:

-

-

-       client_write_MAC_secret[SecurityParameters.hash_size]

-       server_write_MAC_secret[SecurityParameters.hash_size]

-       client_write_key[SecurityParameters.key_material_length]

-       server_write_key[SecurityParameters.key_material_length]

-

-

-

-   Implementation note:

-       The cipher spec which is defined in this document which requires

-       the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte    |

-       keys, 2 x 20 byte MAC secrets, for a total 88 bytes of key        |

-       material.

-

-

-   Exportable encryption algorithms (for which CipherSpec.is_exportable

-   is true) require additional processing as follows to derive their

-   final write keys:

-

-

-       final_client_write_key =

-       PRF(SecurityParameters.client_write_key,

-                                  "client write key",

-                                  SecurityParameters.client_random +

-                                  SecurityParameters.server_random);

-       final_server_write_key =

-       PRF(SecurityParameters.server_write_key,

-                                  "server write key",

-                                  SecurityParameters.client_random +

-                                  SecurityParameters.server_random);

-

-

-6.3.1. Export key generation example

-

-

-   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for

-   each of the two encryption keys and 16 bytes for each of the MAC

-   keys, for a total of 42 bytes of key material. The PRF output is

-   stored in the key_block. The key_block is partitioned, and the write

-   keys are salted because this is an exportable encryption algorithm.

-

-

-       key_block               = PRF(master_secret,

-                                     "key expansion",

-                                     server_random +

-                                     client_random)[0..41]

-       client_write_MAC_secret = key_block[0..15]

-       server_write_MAC_secret = key_block[16..31]

-       client_write_key        = key_block[32..36]

-       server_write_key        = key_block[37..41]

-       final_client_write_key  = PRF(client_write_key,

-                                     "client write key",

-                                     client_random +

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 25] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-                                     server_random)[0..15]

-       final_server_write_key  = PRF(server_write_key,

-                                     "server write key",

-                                     client_random +

-                                     server_random)[0..15]

-

-

-

-7. The TLS Handshake Protocol

-

-

-   The TLS Handshake Protocol consists of a suite of three sub-protocols

-   which are used to allow peers to agree upon security parameters for

-   the record layer, authenticate themselves, instantiate negotiated

-   security parameters, and report error conditions to each other.

-

-

-   The Handshake Protocol is responsible for negotiating a session,

-   which consists of the following items:

-

-

-   session identifier

-       An arbitrary byte sequence chosen by the server to identify an

-       active or resumable session state.

-

-

-   peer certificate

-       X509v3 [X509] certificate of the peer. This element of the state

-       may be null.

-

-

-   compression method

-       The algorithm used to compress data prior to encryption.

-

-

-   cipher spec

-       Specifies the bulk data encryption algorithm (such as null, DES,

-       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines

-       cryptographic attributes such as the hash_size. (See Appendix A.6

-       for formal definition)

-

-

-   master secret

-       48-byte secret shared between the client and server.

-

-

-   is resumable

-       A flag indicating whether the session can be used to initiate new

-       connections.

-

-

-   These items are then used to create security parameters for use by

-   the Record Layer when protecting application data. Many connections

-   can be instantiated using the same session through the resumption

-   feature of the TLS Handshake Protocol.

-

-

-7.1. Change cipher spec protocol

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 26] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   The change cipher spec protocol exists to signal transitions in

-   ciphering strategies. The protocol consists of a single message,

-   which is encrypted and compressed under the current (not the pending)

-   connection state. The message consists of a single byte of value 1.

-

-

-       struct {

-           enum { change_cipher_spec(1), (255) } type;

-       } ChangeCipherSpec;

-

-

-   The change cipher spec message is sent by both the client and server

-   to notify the receiving party that subsequent records will be

-   protected under the newly negotiated CipherSpec and keys. Reception

-   of this message causes the receiver to instruct the Record Layer to

-   immediately copy the read pending state into the read current state.  |

-   Immediately after sending this message, the sender MUST instruct the

-   record layer to make the write pending state the write active state.

-   (See section 6.1.) The change cipher spec message is sent during the

-   handshake after the security parameters have been agreed upon, but

-   before the verifying finished message is sent (see section 7.4.9).

-

-

-7.2. Alert protocol

-

-

-   One of the content types supported by the TLS Record layer is the

-   alert type. Alert messages convey the severity of the message and a

-   description of the alert. Alert messages with a level of fatal result

-   in the immediate termination of the connection. In this case, other

-   connections corresponding to the session may continue, but the        |

-   session identifier MUST be invalidated, preventing the failed session

-   from being used to establish new connections. Like other messages,

-   alert messages are encrypted and compressed, as specified by the

-   current connection state.

-

-

-       enum { warning(1), fatal(2), (255) } AlertLevel;

-

-

-       enum {

-           close_notify(0),

-           unexpected_message(10),

-           bad_record_mac(20),

-           decryption_failed(21),

-           record_overflow(22),

-           decompression_failure(30),

-           handshake_failure(40),

-           no_certificate_RESERVED (41),                                 |

-           bad_certificate(42),

-           unsupported_certificate(43),

-           certificate_revoked(44),

-           certificate_expired(45),

-           certificate_unknown(46),

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 27] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-           illegal_parameter(47),

-           unknown_ca(48),

-           access_denied(49),

-           decode_error(50),

-           decrypt_error(51),

-           export_restriction(60),

-           protocol_version(70),

-           insufficient_security(71),

-           internal_error(80),

-           user_canceled(90),

-           no_renegotiation(100),

-           (255)

-       } AlertDescription;

-

-

-       struct {

-           AlertLevel level;

-           AlertDescription description;

-       } Alert;

-

-

-7.2.1. Closure alerts

-

-

-   The client and the server must share knowledge that the connection is

-   ending in order to avoid a truncation attack. Either party may

-   initiate the exchange of closing messages.

-

-

-   close_notify

-       This message notifies the recipient that the sender will not send |

-       any more messages on this connection. The session MUST not be     |

-       resumed if any connection is terminated without proper

-       close_notify messages with level equal to warning.

-

-

-   Either party may initiate a close by sending a close_notify alert.

-   Any data received after a closure alert is ignored.

-

-

-   Unless some other fatal alert has been transmitted, each party is     |

-   required to send a close_notify alert before closing the write side   |

-   of the connection. The other party MUST respond with a close_notify   |

-   alert of its own and close down the connection immediately,

-   discarding any pending writes. It is not required for the initiator

-   of the close to wait for the responding close_notify alert before

-   closing the read side of the connection.

-

-

-   If the application protocol using TLS provides that any data may be

-   carried over the underlying transport after the TLS connection is

-   closed, the TLS implementation must receive the responding

-   close_notify alert before indicating to the application layer that

-   the TLS connection has ended. If the application protocol will not

-   transfer any additional data, but will only close the underlying      |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 28] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   transport connection, then the implementation MAY choose to close the

-   transport without waiting for the responding close_notify. No part of

-   this standard should be taken to dictate the manner in which a usage

-   profile for TLS manages its data transport, including when

-   connections are opened or closed.

-

-

-   NB: It is assumed that closing a connection reliably delivers

-       pending data before destroying the transport.

-

-

-7.2.2. Error alerts

-

-

-   Error handling in the TLS Handshake protocol is very simple. When an

-   error is detected, the detecting party sends a message to the other

-   party. Upon transmission or receipt of an fatal alert message, both   |

-   parties immediately close the connection. Servers and clients MUST    |

-   forget any session-identifiers, keys, and secrets associated with a

-   failed connection. The following error alerts are defined:

-

-

-   unexpected_message

-       An inappropriate message was received. This alert is always fatal

-       and should never be observed in communication between proper

-       implementations.

-

-

-   bad_record_mac

-       This alert is returned if a record is received with an incorrect  |

-       MAC. This alert also SHOULD be returned if a TLSCiphertext        |

-       decrypted in an invalid way: either it wasn't an even multiple of |

-       the block length, or its padding values, when checked, weren't    |

-       correct. This message is always fatal.

-

-

-   decryption_failed

-       This alert MAY be returned if a TLSCiphertext decrypted in an     |

-       invalid way: either it wasn't an even multiple of the block       |

-       length, or its padding values, when checked, weren't correct.     |

-       This message is always fatal.                                     |

-

-

-       NB: Differentiating between bad_record_mac and decryption_failed  |

-       alerts may permit certain attacks against CBC mode as used in TLS |

-       [CBCATT]. It is preferable to uniformly use the bad_record_mac    |

-       alert to hide the specific type of the error.                     |

-

-

-

-   record_overflow

-       A TLSCiphertext record was received which had a length more than

-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record

-       with more than 2^14+1024 bytes. This message is always fatal.

-

-

-   decompression_failure

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 29] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       The decompression function received improper input (e.g. data

-       that would expand to excessive length). This message is always

-       fatal.

-

-

-   handshake_failure

-       Reception of a handshake_failure alert message indicates that the

-       sender was unable to negotiate an acceptable set of security

-       parameters given the options available. This is a fatal error.

-

-

-   no_certificate_RESERVED                                               |

-       This alert was used in SSLv3 but not in TLS. It should not be     |

-       sent by compliant implementations.                                |

-

-

-   bad_certificate

-       A certificate was corrupt, contained signatures that did not

-       verify correctly, etc.

-

-

-   unsupported_certificate

-       A certificate was of an unsupported type.

-

-

-   certificate_revoked

-       A certificate was revoked by its signer.

-

-

-   certificate_expired

-       A certificate has expired or is not currently valid.

-

-

-   certificate_unknown

-       Some other (unspecified) issue arose in processing the

-       certificate, rendering it unacceptable.

-

-

-   illegal_parameter

-       A field in the handshake was out of range or inconsistent with

-       other fields. This is always fatal.

-

-

-   unknown_ca

-       A valid certificate chain or partial chain was received, but the

-       certificate was not accepted because the CA certificate could not |

-       be located or couldn't be matched with a known, trusted CA.  This

-       message is always fatal.

-

-

-   access_denied

-       A valid certificate was received, but when access control was

-       applied, the sender decided not to proceed with negotiation.

-       This message is always fatal.

-

-

-   decode_error

-       A message could not be decoded because some field was out of the

-       specified range or the length of the message was incorrect. This

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 30] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       message is always fatal.

-

-

-   decrypt_error

-       A handshake cryptographic operation failed, including being

-       unable to correctly verify a signature, decrypt a key exchange,

-       or validate a finished message.

-

-

-   export_restriction

-       A negotiation not in compliance with export restrictions was

-       detected; for example, attempting to transfer a 1024 bit

-       ephemeral RSA key for the RSA_EXPORT handshake method. This

-       message is always fatal.

-

-

-   protocol_version

-       The protocol version the client has attempted to negotiate is

-       recognized, but not supported. (For example, old protocol

-       versions might be avoided for security reasons). This message is

-       always fatal.

-

-

-   insufficient_security

-       Returned instead of handshake_failure when a negotiation has

-       failed specifically because the server requires ciphers more

-       secure than those supported by the client. This message is always

-       fatal.

-

-

-   internal_error

-       An internal error unrelated to the peer or the correctness of the

-       protocol makes it impossible to continue (such as a memory

-       allocation failure). This message is always fatal.

-

-

-   user_canceled

-       This handshake is being canceled for some reason unrelated to a

-       protocol failure. If the user cancels an operation after the

-       handshake is complete, just closing the connection by sending a

-       close_notify is more appropriate. This alert should be followed

-       by a close_notify. This message is generally a warning.

-

-

-   no_renegotiation

-       Sent by the client in response to a hello request or by the

-       server in response to a client hello after initial handshaking.

-       Either of these would normally lead to renegotiation; when that

-       is not appropriate, the recipient should respond with this alert;

-       at that point, the original requester can decide whether to

-       proceed with the connection. One case where this would be

-       appropriate would be where a server has spawned a process to

-       satisfy a request; the process might receive security parameters

-       (key length, authentication, etc.) at startup and it might be

-       difficult to communicate changes to these parameters after that

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 31] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       point. This message is always a warning.

-

-

-   For all errors where an alert level is not explicitly specified, the  |

-   sending party MAY determine at its discretion whether this is a fatal

-   error or not; if an alert with a level of warning is received, the

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 32] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   receiving party MAY decide at its discretion whether to treat this as |

-   a fatal error or not. However, all messages which are transmitted     |

-   with a level of fatal MUST be treated as fatal messages.

-

-

-7.3. Handshake Protocol overview

-

-

-   The cryptographic parameters of the session state are produced by the

-   TLS Handshake Protocol, which operates on top of the TLS Record

-   Layer. When a TLS client and server first start communicating, they

-   agree on a protocol version, select cryptographic algorithms,

-   optionally authenticate each other, and use public-key encryption

-   techniques to generate shared secrets.

-

-

-   The TLS Handshake Protocol involves the following steps:

-

-

-     - - Exchange hello messages to agree on algorithms, exchange random

-       values, and check for session resumption.

-

-

-     - - Exchange the necessary cryptographic parameters to allow the

-       client and server to agree on a premaster secret.

-

-

-     - - Exchange certificates and cryptographic information to allow

-       the client and server to authenticate themselves.

-

-

-     - - Generate a master secret from the premaster secret and

-       exchanged random values.

-

-

-     - - Provide security parameters to the record layer.

-

-

-     - - Allow the client and server to verify that their peer has

-       calculated the same security parameters and that the handshake

-       occurred without tampering by an attacker.

-

-

-   Note that higher layers should not be overly reliant on TLS always

-   negotiating the strongest possible connection between two peers:

-   there are a number of ways a man in the middle attacker can attempt

-   to make two entities drop down to the least secure method they

-   support. The protocol has been designed to minimize this risk, but

-   there are still attacks available: for example, an attacker could

-   block access to the port a secure service runs on, or attempt to get

-   the peers to negotiate an unauthenticated connection. The fundamental

-   rule is that higher levels must be cognizant of what their security

-   requirements are and never transmit information over a channel less

-   secure than what they require. The TLS protocol is secure, in that

-   any cipher suite offers its promised level of security: if you

-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose

-   certificate you have verified, you can expect to be that secure.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 33] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   However, you SHOULD never send data over a link encrypted with 40 bit |

-   security unless you feel that data is worth no more than the effort

-   required to break that encryption.

-

-

-   These goals are achieved by the handshake protocol, which can be

-   summarized as follows: The client sends a client hello message to

-   which the server must respond with a server hello message, or else a

-   fatal error will occur and the connection will fail. The client hello

-   and server hello are used to establish security enhancement

-   capabilities between client and server. The client hello and server

-   hello establish the following attributes: Protocol Version, Session

-   ID, Cipher Suite, and Compression Method. Additionally, two random

-   values are generated and exchanged: ClientHello.random and

-   ServerHello.random.

-

-

-   The actual key exchange uses up to four messages: the server

-   certificate, the server key exchange, the client certificate, and the

-   client key exchange. New key exchange methods can be created by

-   specifying a format for these messages and defining the use of the

-   messages to allow the client and server to agree upon a shared        |

-   secret. This secret MUST be quite long; currently defined key

-   exchange methods exchange secrets which range from 48 to 128 bytes in

-   length.

-

-

-   Following the hello messages, the server will send its certificate,

-   if it is to be authenticated. Additionally, a server key exchange

-   message may be sent, if it is required (e.g. if their server has no

-   certificate, or if its certificate is for signing only). If the

-   server is authenticated, it may request a certificate from the

-   client, if that is appropriate to the cipher suite selected. Now the

-   server will send the server hello done message, indicating that the

-   hello-message phase of the handshake is complete. The server will

-   then wait for a client response. If the server has sent a certificate

-   request message, the client must send the certificate message. The

-   client key exchange message is now sent, and the content of that

-   message will depend on the public key algorithm selected between the

-   client hello and the server hello. If the client has sent a

-   certificate with signing ability, a digitally-signed certificate

-   verify message is sent to explicitly verify the certificate.

-

-

-   At this point, a change cipher spec message is sent by the client,

-   and the client copies the pending Cipher Spec into the current Cipher

-   Spec. The client then immediately sends the finished message under

-   the new algorithms, keys, and secrets. In response, the server will

-   send its own change cipher spec message, transfer the pending to the

-   current Cipher Spec, and send its finished message under the new

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 34] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Cipher Spec. At this point, the handshake is complete and the client

-   and server may begin to exchange application layer data. (See flow

-   chart below.)

-

-

-      Client                                               Server

-

-

-      ClientHello                  -------->

-                                                      ServerHello

-                                                     Certificate*

-                                               ServerKeyExchange*

-                                              CertificateRequest*

-                                   <--------      ServerHelloDone

-      Certificate*

-      ClientKeyExchange

-      CertificateVerify*

-      [ChangeCipherSpec]

-      Finished                     -------->

-                                               [ChangeCipherSpec]

-                                   <--------             Finished

-      Application Data             <------->     Application Data

-

-

-             Fig. 1 - Message flow for a full handshake

-

-

-   * Indicates optional or situation-dependent messages that are not

-   always sent.

-

-

-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an

-       independent TLS Protocol content type, and is not actually a TLS

-       handshake message.

-

-

-   When the client and server decide to resume a previous session or

-   duplicate an existing session (instead of negotiating new security

-   parameters) the message flow is as follows:

-

-

-   The client sends a ClientHello using the Session ID of the session to

-   be resumed. The server then checks its session cache for a match.  If

-   a match is found, and the server is willing to re-establish the

-   connection under the specified session state, it will send a

-   ServerHello with the same Session ID value. At this point, both       |

-   client and server MUST send change cipher spec messages and proceed

-   directly to finished messages. Once the re-establishment is complete, |

-   the client and server MAY begin to exchange application layer data.

-   (See flow chart below.) If a Session ID match is not found, the

-   server generates a new session ID and the TLS client and server

-   perform a full handshake.

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 35] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-      Client                                                Server

-

-

-      ClientHello                   -------->

-                                                       ServerHello

-                                                [ChangeCipherSpec]

-                                    <--------             Finished

-      [ChangeCipherSpec]

-      Finished                      -------->

-      Application Data              <------->     Application Data

-

-

-          Fig. 2 - Message flow for an abbreviated handshake

-

-

-   The contents and significance of each message will be presented in

-   detail in the following sections.

-

-

-7.4. Handshake protocol

-

-

-   The TLS Handshake Protocol is one of the defined higher level clients

-   of the TLS Record Protocol. This protocol is used to negotiate the

-   secure attributes of a session. Handshake messages are supplied to

-   the TLS Record Layer, where they are encapsulated within one or more

-   TLSPlaintext structures, which are processed and transmitted as

-   specified by the current active session state.

-

-

-       enum {

-           hello_request(0), client_hello(1), server_hello(2),

-           certificate(11), server_key_exchange (12),

-           certificate_request(13), server_hello_done(14),

-           certificate_verify(15), client_key_exchange(16),

-           finished(20), (255)

-       } HandshakeType;

-

-

-       struct {

-           HandshakeType msg_type;    /* handshake type */

-           uint24 length;             /* bytes in message */

-           select (HandshakeType) {

-               case hello_request:       HelloRequest;

-               case client_hello:        ClientHello;

-               case server_hello:        ServerHello;

-               case certificate:         Certificate;

-               case server_key_exchange: ServerKeyExchange;

-               case certificate_request: CertificateRequest;

-               case server_hello_done:   ServerHelloDone;

-               case certificate_verify:  CertificateVerify;

-               case client_key_exchange: ClientKeyExchange;

-               case finished:            Finished;

-           } body;

-       } Handshake;

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 36] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   The handshake protocol messages are presented below in the order they |

-   MUST be sent; sending handshake messages in an unexpected order

-   results in a fatal error. Unneeded handshake messages can be omitted,

-   however. Note one exception to the ordering: the Certificate message

-   is used twice in the handshake (from server to client, then from

-   client to server), but described only in its first position. The one

-   message which is not bound by these ordering rules is the Hello       |

-   Request message, which can be sent at any time, but which should be

-   ignored by the client if it arrives in the middle of a handshake.

-

-

-7.4.1. Hello messages

-

-

-   The hello phase messages are used to exchange security enhancement

-   capabilities between the client and server. When a new session

-   begins, the Record Layer's connection state encryption, hash, and

-   compression algorithms are initialized to null. The current

-   connection state is used for renegotiation messages.

-

-

-7.4.1.1. Hello request

-

-

-   When this message will be sent:

-       The hello request message MAY be sent by the server at any time.  |

-

-

-   Meaning of this message:

-       Hello request is a simple notification that the client should

-       begin the negotiation process anew by sending a client hello

-       message when convenient. This message will be ignored by the

-       client if the client is currently negotiating a session. This

-       message may be ignored by the client if it does not wish to

-       renegotiate a session, or the client may, if it wishes, respond

-       with a no_renegotiation alert. Since handshake messages are

-       intended to have transmission precedence over application data,

-       it is expected that the negotiation will begin before no more

-       than a few records are received from the client. If the server

-       sends a hello request but does not receive a client hello in

-       response, it may close the connection with a fatal alert.

-

-

-   After sending a hello request, servers SHOULD not repeat the request  |

-   until the subsequent handshake negotiation is complete.

-

-

-   Structure of this message:

-       struct { } HelloRequest;

-

-

- Note: This message MUST NOT be included in the message hashes which are |

-       maintained throughout the handshake and used in the finished

-       messages and the certificate verify message.

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 37] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-7.4.1.2. Client hello

-

-

-   When this message will be sent:

-       When a client first connects to a server it is required to send

-       the client hello as its first message. The client can also send a

-       client hello in response to a hello request or on its own

-       initiative in order to renegotiate the security parameters in an

-       existing connection.

-

-

-       Structure of this message:

-           The client hello message includes a random structure, which is

-           used later in the protocol.

-

-

-           struct {

-              uint32 gmt_unix_time;

-              opaque random_bytes[28];

-           } Random;

-

-

-       gmt_unix_time

-       The current time and date in standard UNIX 32-bit format (seconds

-       since the midnight starting Jan 1, 1970, GMT) according to the

-       sender's internal clock. Clocks are not required to be set

-       correctly by the basic TLS Protocol; higher level or application

-       protocols may define additional requirements.

-

-

-   random_bytes

-       28 bytes generated by a secure random number generator.

-

-

-   The client hello message includes a variable length session           |

-   identifier. If not empty, the value identifies a session between the

-   same client and server whose security parameters the client wishes to |

-   reuse. The session identifier MAY be from an earlier connection, this

-   connection, or another currently active connection. The second option

-   is useful if the client only wishes to update the random structures

-   and derived values of a connection, while the third option makes it

-   possible to establish several independent secure connections without

-   repeating the full handshake protocol. These independent connections

-   may occur sequentially or simultaneously; a SessionID becomes valid

-   when the handshake negotiating it completes with the exchange of

-   Finished messages and persists until removed due to aging or because

-   a fatal error was encountered on a connection associated with the

-   session. The actual contents of the SessionID are defined by the

-   server.

-

-

-       opaque SessionID<0..32>;

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 38] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Warning:

-       Because the SessionID is transmitted without encryption or        |

-       immediate MAC protection, servers MUST not place confidential

-       information in session identifiers or let the contents of fake

-       session identifiers cause any breach of security. (Note that the

-       content of the handshake as a whole, including the SessionID, is

-       protected by the Finished messages exchanged at the end of the

-       handshake.)

-

-

-   The CipherSuite list, passed from the client to the server in the     |

-   client hello message, contains the combinations of cryptographic

-   algorithms supported by the client in order of the client's

-   preference (favorite choice first). Each CipherSuite defines a key

-   exchange algorithm, a bulk encryption algorithm (including secret key

-   length) and a MAC algorithm. The server will select a cipher suite

-   or, if no acceptable choices are presented, return a handshake

-   failure alert and close the connection.

-

-

-       uint8 CipherSuite[2];    /* Cryptographic suite selector */

-

-

-   The client hello includes a list of compression algorithms supported

-   by the client, ordered according to the client's preference.

-

-

-       enum { null(0), (255) } CompressionMethod;

-

-

-       struct {

-           ProtocolVersion client_version;

-           Random random;

-           SessionID session_id;

-           CipherSuite cipher_suites<2..2^16-1>;

-           CompressionMethod compression_methods<1..2^8-1>;

-       } ClientHello;

-

-

-   client_version

-       The version of the TLS protocol by which the client wishes to     |

-       communicate during this session. This SHOULD be the latest

-       (highest valued) version supported by the client. For this        |

-       version of the specification, the version will be 3.2 (See

-       Appendix E for details about backward compatibility).

-

-

-   random

-       A client-generated random structure.

-

-

-   session_id

-       The ID of a session the client wishes to use for this connection.

-       This field should be empty if no session_id is available or the

-       client wishes to generate new security parameters.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 39] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   cipher_suites

-       This is a list of the cryptographic options supported by the

-       client, with the client's first preference first. If the

-       session_id field is not empty (implying a session resumption      |

-       request) this vector MUST include at least the cipher_suite from

-       that session. Values are defined in Appendix A.5.

-

-

-   compression_methods

-       This is a list of the compression methods supported by the

-       client, sorted by client preference. If the session_id field is

-       not empty (implying a session resumption request) it must include

-       the compression_method from that session. This vector must

-       contain, and all implementations must support,

-       CompressionMethod.null. Thus, a client and server will always be

-       able to agree on a compression method.

-

-

-   After sending the client hello message, the client waits for a server

-   hello message. Any other handshake message returned by the server

-   except for a hello request is treated as a fatal error.

-

-

-   Forward compatibility note:

-       In the interests of forward compatibility, it is permitted for a

-       client hello message to include extra data after the compression  |

-       methods. This data MUST be included in the handshake hashes, but

-       must otherwise be ignored. This is the only handshake message for

-       which this is legal; for all other messages, the amount of data   |

-       in the message MUST match the description of the message

-       precisely.

-

-

-Note: For the intended use of trailing data in the ClientHello, see RFC  |

-       3546 [TLSEXT].                                                    |

-

-

-7.4.1.3. Server hello

-

-

-   When this message will be sent:

-       The server will send this message in response to a client hello

-       message when it was able to find an acceptable set of algorithms.

-       If it cannot find such a match, it will respond with a handshake

-       failure alert.

-

-

-   Structure of this message:

-       struct {

-           ProtocolVersion server_version;

-           Random random;

-           SessionID session_id;

-           CipherSuite cipher_suite;

-           CompressionMethod compression_method;

-       } ServerHello;

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 40] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   server_version

-       This field will contain the lower of that suggested by the client

-       in the client hello and the highest supported by the server. For

-       this version of the specification, the version is 3.2 (See        |

-       Appendix E for details about backward compatibility).

-

-

-   random

-       This structure is generated by the server and MUST be             |

-       independently generated from the ClientHello.random.

-

-

-   session_id

-       This is the identity of the session corresponding to this

-       connection. If the ClientHello.session_id was non-empty, the

-       server will look in its session cache for a match. If a match is

-       found and the server is willing to establish the new connection

-       using the specified session state, the server will respond with

-       the same value as was supplied by the client. This indicates a

-       resumed session and dictates that the parties must proceed

-       directly to the finished messages. Otherwise this field will

-       contain a different value identifying the new session. The server

-       may return an empty session_id to indicate that the session will

-       not be cached and therefore cannot be resumed. If a session is

-       resumed, it must be resumed using the same cipher suite it was

-       originally negotiated with.

-

-

-   cipher_suite

-       The single cipher suite selected by the server from the list in

-       ClientHello.cipher_suites. For resumed sessions this field is the

-       value from the state of the session being resumed.

-

-

-   compression_method                                                    |

-       The single compression algorithm selected by the server from the

-       list in ClientHello.compression_methods. For resumed sessions

-       this field is the value from the resumed session state.

-

-

-7.4.2. Server certificate

-

-

-   When this message will be sent:

-       The server MUST send a certificate whenever the agreed-upon key   |

-       exchange method is not an anonymous one. This message will always

-       immediately follow the server hello message.

-

-

-   Meaning of this message:

-       The certificate type MUST be appropriate for the selected cipher  |

-       suite's key exchange algorithm, and is generally an X.509v3       |

-       certificate. It MUST contain a key which matches the key exchange

-       method, as follows. Unless otherwise specified, the signing

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 41] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       algorithm for the certificate MUST be the same as the algorithm   |

-       for the certificate key. Unless otherwise specified, the public   |

-       key MAY be of any length.

-

-

-       Key Exchange Algorithm  Certificate Key Type

-

-

-       RSA                     RSA public key; the certificate MUST      |

-                               allow the key to be used for encryption.

-

-

-       RSA_EXPORT              RSA public key of length greater than

-                               512 bits which can be used for signing,

-                               or a key of 512 bits or shorter which

-                               can be used for encryption.               |

-

-

-       DHE_DSS                 DSS public key.

-

-

-       DHE_DSS_EXPORT          DSS public key.

-

-

-       DHE_RSA                 RSA public key which can be used for

-                               signing.

-

-

-       DHE_RSA_EXPORT          RSA public key which can be used for

-                               signing.

-

-

-       DH_DSS                  Diffie-Hellman key. The algorithm used

-                               to sign the certificate MUST be DSS.      |

-

-

-       DH_RSA                  Diffie-Hellman key. The algorithm used

-                               to sign the certificate MUST be RSA.      |

-

-

-   All certificate profiles, key and cryptographic formats are defined

-   by the IETF PKIX working group [PKIX]. When a key usage extension is  |

-   present, the digitalSignature bit MUST be set for the key to be

-   eligible for signing, as described above, and the keyEncipherment bit |

-   MUST be present to allow encryption, as described above. The

-   keyAgreement bit must be set on Diffie-Hellman certificates.

-

-

-   As CipherSuites which specify new key exchange methods are specified

-   for the TLS Protocol, they will imply certificate format and the

-   required encoded keying information.

-

-

-   Structure of this message:

-       opaque ASN.1Cert<1..2^24-1>;

-

-

-       struct {

-           ASN.1Cert certificate_list<0..2^24-1>;

-       } Certificate;

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 42] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   certificate_list

-       This is a sequence (chain) of X.509v3 certificates. The sender's

-       certificate must come first in the list. Each following

-       certificate must directly certify the one preceding it. Because

-       certificate validation requires that root keys be distributed

-       independently, the self-signed certificate which specifies the

-       root certificate authority may optionally be omitted from the

-       chain, under the assumption that the remote end must already

-       possess it in order to validate it in any case.

-

-

-   The same message type and structure will be used for the client's     |

-   response to a certificate request message. Note that a client MAY

-   send no certificates if it does not have an appropriate certificate

-   to send in response to the server's authentication request.

-

-

- Note: PKCS #7 [PKCS7] is not used as the format for the certificate

-       vector because PKCS #6 [PKCS6] extended certificates are not

-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making

-       the task of parsing the list more difficult.

-

-

-7.4.3. Server key exchange message

-

-

-   When this message will be sent:

-       This message will be sent immediately after the server

-       certificate message (or the server hello message, if this is an

-       anonymous negotiation).

-

-

-       The server key exchange message is sent by the server only when

-       the server certificate message (if sent) does not contain enough

-       data to allow the client to exchange a premaster secret. This is

-       true for the following key exchange methods:

-

-

-           RSA_EXPORT (if the public key in the server certificate is

-           longer than 512 bits)

-           DHE_DSS

-           DHE_DSS_EXPORT

-           DHE_RSA

-           DHE_RSA_EXPORT

-           DH_anon

-

-

-       It is not legal to send the server key exchange message for the

-       following key exchange methods:

-

-

-           RSA

-           RSA_EXPORT (when the public key in the server certificate is

-           less than or equal to 512 bits in length)

-           DH_DSS

-           DH_RSA

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 43] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Meaning of this message:

-       This message conveys cryptographic information to allow the

-       client to communicate the premaster secret: either an RSA public

-       key to encrypt the premaster secret with, or a Diffie-Hellman

-       public key with which the client can complete a key exchange

-       (with the result being the premaster secret.)

-

-

-   As additional CipherSuites are defined for TLS which include new key  |

-   exchange algorithms, the server key exchange message will be sent if

-   and only if the certificate type associated with the key exchange

-   algorithm does not provide enough information for the client to

-   exchange a premaster secret.

-

-

- Note: According to current US export law, RSA moduli larger than 512

-       bits may not be used for key exchange in software exported from

-       the US. With this message, the larger RSA keys encoded in

-       certificates may be used to sign temporary shorter RSA keys for

-       the RSA_EXPORT key exchange method.

-

-

-   Structure of this message:

-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;

-

-

-       struct {

-           opaque rsa_modulus<1..2^16-1>;

-           opaque rsa_exponent<1..2^16-1>;

-       } ServerRSAParams;

-

-

-       rsa_modulus

-           The modulus of the server's temporary RSA key.

-

-

-       rsa_exponent

-           The public exponent of the server's temporary RSA key.

-

-

-       struct {

-           opaque dh_p<1..2^16-1>;

-           opaque dh_g<1..2^16-1>;

-           opaque dh_Ys<1..2^16-1>;

-       } ServerDHParams;     /* Ephemeral DH parameters */

-

-

-       dh_p

-           The prime modulus used for the Diffie-Hellman operation.

-

-

-       dh_g

-           The generator used for the Diffie-Hellman operation.

-

-

-       dh_Ys

-           The server's Diffie-Hellman public value (g^X mod p).

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 44] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       struct {

-           select (KeyExchangeAlgorithm) {

-               case diffie_hellman:

-                   ServerDHParams params;

-                   Signature signed_params;

-               case rsa:

-                   ServerRSAParams params;

-                   Signature signed_params;

-           };

-       } ServerKeyExchange;

-

-

-       struct {                                                          |

-           select (KeyExchangeAlgorithm) {                               |

-               case diffie_hellman:                                      |

-                   ServerDHParams params;                                |

-               case rsa:                                                 |

-                   ServerRSAParams params;                               |

-           };                                                            |

-        } ServerParams;                                                  |

-

-

-       params

-           The server's key exchange parameters.

-

-

-       signed_params

-           For non-anonymous key exchanges, a hash of the corresponding

-           params value, with the signature appropriate to that hash

-           applied.

-

-

-       md5_hash

-           MD5(ClientHello.random + ServerHello.random + ServerParams);

-

-

-       sha_hash

-           SHA(ClientHello.random + ServerHello.random + ServerParams);

-

-

-       enum { anonymous, rsa, dsa } SignatureAlgorithm;

-

-

-

-       select (SignatureAlgorithm)                                       |

-       {                                                                 |

-           case anonymous: struct { };                                   |

-           case rsa:

-               digitally-signed struct {

-                   opaque md5_hash[16];

-                   opaque sha_hash[20];

-               };

-           case dsa:

-               digitally-signed struct {

-                   opaque sha_hash[20];

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 45] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-               };

-       } Signature;

-

-

-7.4.4. Certificate request

-

-

-   When this message will be sent:

-       A non-anonymous server can optionally request a certificate from

-       the client, if appropriate for the selected cipher suite. This

-       message, if sent, will immediately follow the Server Key Exchange

-       message (if it is sent; otherwise, the Server Certificate

-       message).

-

-

-   Structure of this message:

-       enum {

-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),

-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),      |

-        fortezza_dms_RESERVED(20),                                       |

-           (255)

-       } ClientCertificateType;

-

-

-       opaque DistinguishedName<1..2^16-1>;

-

-

-       struct {

-           ClientCertificateType certificate_types<1..2^8-1>;

-           DistinguishedName certificate_authorities<0..2^16-1>;         |

-       } CertificateRequest;

-

-

-       certificate_types

-           This field is a list of the types of certificates requested,  |

-           sorted in order of the server's preference.                   |

-

-

-       certificate_authorities

-           A list of the distinguished names of acceptable certificate

-           authorities. These distinguished names may specify a desired

-           distinguished name for a root CA or for a subordinate CA;

-           thus, this message can be used both to describe known roots   |

-           and a desired authorization space. If the                     |

-           certificate_authorities list is empty then the client MAY     |

-           send any certificate of the appropriate                       |

-           ClientCertificateType, unless there is some external          |

-           arrangement to the contrary.                                  |

-

-

-

- Note: Values listed as RESERVED may not be used. They were used in      |

-           SSLv3.

-

-

- Note: DistinguishedName is derived from [X509].

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 46] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

- Note: It is a fatal handshake_failure alert for an anonymous server to

-       request client authentication.                                    |

-

-

-7.4.5. Server hello done

-

-

-   When this message will be sent:

-       The server hello done message is sent by the server to indicate

-       the end of the server hello and associated messages. After

-       sending this message the server will wait for a client response.

-

-

-   Meaning of this message:

-       This message means that the server is done sending messages to

-       support the key exchange, and the client can proceed with its

-       phase of the key exchange.

-

-

-       Upon receipt of the server hello done message the client SHOULD   |

-       verify that the server provided a valid certificate if required

-       and check that the server hello parameters are acceptable.

-

-

-   Structure of this message:

-       struct { } ServerHelloDone;

-

-

-7.4.6. Client certificate

-

-

-   When this message will be sent:

-       This is the first message the client can send after receiving a

-       server hello done message. This message is only sent if the

-       server requests a certificate. If no suitable certificate is

-       available, the client should send a certificate message           |

-       containing no certificates: I.e. the certificate_list structure   |

-       should have a length of zero. If client authentication is         |

-       required by the server for the handshake to continue, it may

-       respond with a fatal handshake failure alert. Client certificates

-       are sent using the Certificate structure defined in Section

-       7.4.2.

-

-

-

- Note: When using a static Diffie-Hellman based key exchange method      |

-       (DH_DSS or DH_RSA), if client authentication is requested, the

-       Diffie-Hellman group and generator encoded in the client's

-       certificate must match the server specified Diffie-Hellman

-       parameters if the client's parameters are to be used for the key

-       exchange.

-

-

-7.4.7. Client key exchange message

-

-

-   When this message will be sent:

-       This message is always sent by the client. It will immediately

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 47] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       follow the client certificate message, if it is sent. Otherwise

-       it will be the first message sent by the client after it receives

-       the server hello done message.

-

-

-   Meaning of this message:

-       With this message, the premaster secret is set, either though

-       direct transmission of the RSA-encrypted secret, or by the

-       transmission of Diffie-Hellman parameters which will allow each

-       side to agree upon the same premaster secret. When the key

-       exchange method is DH_RSA or DH_DSS, client certification has

-       been requested, and the client was able to respond with a

-       certificate which contained a Diffie-Hellman public key whose

-       parameters (group and generator) matched those specified by the   |

-       server in its certificate, this message MUST not contain any

-       data.

-

-

-   Structure of this message:

-       The choice of messages depends on which key exchange method has

-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm

-       definition.

-

-

-       struct {

-           select (KeyExchangeAlgorithm) {

-               case rsa: EncryptedPreMasterSecret;

-               case diffie_hellman: ClientDiffieHellmanPublic;

-           } exchange_keys;

-       } ClientKeyExchange;

-

-

-7.4.7.1. RSA encrypted premaster secret message

-

-

-   Meaning of this message:

-       If RSA is being used for key agreement and authentication, the

-       client generates a 48-byte premaster secret, encrypts it using

-       the public key from the server's certificate or the temporary RSA

-       key provided in a server key exchange message, and sends the

-       result in an encrypted premaster secret message. This structure

-       is a variant of the client key exchange message, not a message in

-       itself.

-

-

-   Structure of this message:

-       struct {

-           ProtocolVersion client_version;

-           opaque random[46];

-       } PreMasterSecret;

-

-

-       client_version

-           The latest (newest) version supported by the client. This is

-           used to detect version roll-back attacks. Upon receiving the  |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 48] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-           premaster secret, the server SHOULD check that this value

-           matches the value transmitted by the client in the client

-           hello message.

-

-

-       random

-           46 securely-generated random bytes.

-

-

-       struct {

-           public-key-encrypted PreMasterSecret pre_master_secret;

-       } EncryptedPreMasterSecret;

-

-

-       pre_master_secret                                                 |

-           This random value is generated by the client and is used to   |

-           generate the master secret, as specified in Section 8.1.      |

-

-

- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used

-       to attack a TLS server which is using PKCS#1 encoded RSA. The

-       attack takes advantage of the fact that by failing in different

-       ways, a TLS server can be coerced into revealing whether a

-       particular message, when decrypted, is properly PKCS#1 formatted

-       or not.

-

-

-       The best way to avoid vulnerability to this attack is to treat

-       incorrectly formatted messages in a manner indistinguishable from

-       correctly formatted RSA blocks. Thus, when it receives an

-       incorrectly formatted RSA block, a server should generate a

-       random 48-byte value and proceed using it as the premaster

-       secret. Thus, the server will act identically whether the         |

-       received RSA block is correctly encoded or not.                   |

-

-

- Implementation Note: public-key-encrypted data is represented as an     |

-       opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted    |

-       PreMaster Secret in a ClientKeyExchange is preceded by two length |

-       bytes. These bytes are redundant in the case of RSA because the   |

-       EncryptedPreMasterSecret is the only data in the                  |

-       ClientKeyExchange and its length can therefore be unambiguously   |

-       determined. The SSLv3 specification was not clear about the       |

-       encoding of public-key-encrypted data and therefore many SSLv3    |

-       implementations do not include the the length bytes, encoding the |

-       RSA encrypted data directly in the ClientKeyExchange message.     |

-

-

-       This specification requires correct encoding of the               |

-       EncryptedPreMasterSecret complete with length bytes. The          |

-       resulting PDU is incompatible with many SSLv3 implementations.    |

-       Implementors upgrading from SSLv3 must modify their               |

-       implementations to generate and accept the correct encoding.      |

-       Implementors who wish to be compatible with both SSLv3 and TLS    |

-       should make their implementation's behavior dependent on the      |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 49] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       protocol version.                                                 |

-

-

- Implementation Note: It is now known that remote timing-based attacks   |

-       on SSL are possible, at least when the client and server are on   |

-       the same LAN. Accordingly, implementations which use static RSA   |

-       keys SHOULD use RSA blinding or some other anti-timing technique, |

-       as described in [TIMING].

-

-

- Note: The version number in the PreMasterSecret is that offered by the  |

-       client, NOT the version negotiated for the connection. This       |

-       feature is designed to prevent rollback attacks. Unfortunately,   |

-       many implementations use the negotiated version instead and       |

-       therefore checking the version number may lead to failure to      |

-       interoperate with such incorrect client implementations. Client   |

-       implementations MUST and Server implementations MAY check the     |

-       version number. In practice, since there are no significant known |

-       security differences between TLS and SSLv3, rollback to SSLv3 is  |

-       not believed to be a serious security risk.  Note that if servers |

-       choose to to check the version number, they should randomize the  |

-       PreMasterSecret in case of error, rather than generate an alert,  |

-       in order to avoid variants on the Bleichenbacher attack. [KPR03]

-

-

-7.4.7.2. Client Diffie-Hellman public value

-

-

-   Meaning of this message:

-       This structure conveys the client's Diffie-Hellman public value

-       (Yc) if it was not already included in the client's certificate.

-       The encoding used for Yc is determined by the enumerated

-       PublicValueEncoding. This structure is a variant of the client

-       key exchange message, not a message in itself.

-

-

-   Structure of this message:

-       enum { implicit, explicit } PublicValueEncoding;

-

-

-       implicit

-           If the client certificate already contains a suitable Diffie-

-           Hellman key, then Yc is implicit and does not need to be sent

-           again. In this case, the Client Key Exchange message will be

-           sent, but will be empty.

-

-

-       explicit

-           Yc needs to be sent.

-

-

-       struct {

-           select (PublicValueEncoding) {

-               case implicit: struct { };

-               case explicit: opaque dh_Yc<1..2^16-1>;

-           } dh_public;

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 50] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       } ClientDiffieHellmanPublic;

-

-

-       dh_Yc

-           The client's Diffie-Hellman public value (Yc).

-

-

-7.4.8. Certificate verify

-

-

-   When this message will be sent:

-       This message is used to provide explicit verification of a client

-       certificate. This message is only sent following a client

-       certificate that has signing capability (i.e. all certificates

-       except those containing fixed Diffie-Hellman parameters). When

-       sent, it will immediately follow the client key exchange message.

-

-

-   Structure of this message:

-       struct {

-            Signature signature;

-       } CertificateVerify;

-

-

-       The Signature type is defined in 7.4.3.

-

-

-       CertificateVerify.signature.md5_hash

-           MD5(handshake_messages);

-

-

-       CertificateVerify.signature.sha_hash                              |

-           SHA(handshake_messages);

-

-

-   Here handshake_messages refers to all handshake messages sent or

-   received starting at client hello up to but not including this

-   message, including the type and length fields of the handshake

-   messages. This is the concatenation of all the Handshake structures

-   as defined in 7.4 exchanged thus far.

-

-

-7.4.9. Finished

-

-

-   When this message will be sent:

-       A finished message is always sent immediately after a change

-       cipher spec message to verify that the key exchange and

-       authentication processes were successful. It is essential that a

-       change cipher spec message be received between the other

-       handshake messages and the Finished message.

-

-

-   Meaning of this message:

-       The finished message is the first protected with the just-

-       negotiated algorithms, keys, and secrets. Recipients of finished  |

-       messages MUST verify that the contents are correct.  Once a side

-       has sent its Finished message and received and validated the

-       Finished message from its peer, it may begin to send and receive

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 51] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       application data over the connection.

-

-

-       struct {

-           opaque verify_data[12];

-       } Finished;

-

-

-       verify_data

-           PRF(master_secret, finished_label, MD5(handshake_messages) +

-           SHA-1(handshake_messages)) [0..11];

-

-

-       finished_label

-           For Finished messages sent by the client, the string "client

-           finished". For Finished messages sent by the server, the

-           string "server finished".

-

-

-       handshake_messages

-           All of the data from all handshake messages up to but not

-           including this message. This is only data visible at the

-           handshake layer and does not include record layer headers.

-           This is the concatenation of all the Handshake structures as

-           defined in 7.4 exchanged thus far.

-

-

-   It is a fatal error if a finished message is not preceded by a change

-   cipher spec message at the appropriate point in the handshake.

-

-

-   The value handshake_messages includes all handshake messages starting |

-   at client hello up to, but not including, this finished message. This

-   may be different from handshake_messages in Section 7.4.8 because it

-   would include the certificate verify message (if sent). Also, the

-   handshake_messages for the finished message sent by the client will

-   be different from that for the finished message sent by the server,

-   because the one which is sent second will include the prior one.

-

-

- Note: Change cipher spec messages, alerts and any other record types

-       are not handshake messages and are not included in the hash

-       computations. Also, Hello Request messages are omitted from

-       handshake hashes.

-

-

-8. Cryptographic computations

-

-

-   In order to begin connection protection, the TLS Record Protocol

-   requires specification of a suite of algorithms, a master secret, and

-   the client and server random values. The authentication, encryption,

-   and MAC algorithms are determined by the cipher_suite selected by the

-   server and revealed in the server hello message. The compression

-   algorithm is negotiated in the hello messages, and the random values

-   are exchanged in the hello messages. All that remains is to calculate

-   the master secret.

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 52] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-8.1. Computing the master secret

-

-

-   For all key exchange methods, the same algorithm is used to convert

-   the pre_master_secret into the master_secret. The pre_master_secret

-   should be deleted from memory once the master_secret has been

-   computed.

-

-

-       master_secret = PRF(pre_master_secret, "master secret",

-                           ClientHello.random + ServerHello.random)

-       [0..47];

-

-

-   The master secret is always exactly 48 bytes in length. The length of

-   the premaster secret will vary depending on key exchange method.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 53] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-8.1.1. RSA

-

-

-   When RSA is used for server authentication and key exchange, a

-   48-byte pre_master_secret is generated by the client, encrypted under

-   the server's public key, and sent to the server. The server uses its

-   private key to decrypt the pre_master_secret. Both parties then

-   convert the pre_master_secret into the master_secret, as specified

-   above.

-

-

-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type

-   1. RSA public key encryption is performed using PKCS #1 block type 2.

-

-

-8.1.2. Diffie-Hellman

-

-

-   A conventional Diffie-Hellman computation is performed. The

-   negotiated key (Z) is used as the pre_master_secret, and is converted

-   into the master_secret, as specified above.  Leading 0 bytes of Z are |

-   stripped before it is used as the pre_master_secret.

-

-

- Note: Diffie-Hellman parameters are specified by the server, and may

-       be either ephemeral or contained within the server's certificate.

-

-

-9. Mandatory Cipher Suites

-

-

-   In the absence of an application profile standard specifying

-   otherwise, a TLS compliant application MUST implement the cipher      |

-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.                                  |

-

-

-   The 40-bit cipher suites are known to be susceptible to exhaustive    |

-   search attack by commercial attackers. Implementations of this        |

-   document SHOULD disable them by default if they are supported at all. |

-   A future version of this document may remove them entirely.

-

-

-10. Application data protocol

-

-

-   Application data messages are carried by the Record Layer and are

-   fragmented, compressed and encrypted based on the current connection

-   state. The messages are treated as transparent data to the record

-   layer.

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 54] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-A. Protocol constant values

-

-

-   This section describes protocol types and constants.

-

-

-A.1. Record layer

-

-

-    struct {

-        uint8 major, minor;

-    } ProtocolVersion;

-

-

-    ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */               |

-

-

-    enum {

-        change_cipher_spec(20), alert(21), handshake(22),

-        application_data(23), (255)

-    } ContentType;

-

-

-    struct {

-        ContentType type;

-        ProtocolVersion version;

-        uint16 length;

-        opaque fragment[TLSPlaintext.length];

-    } TLSPlaintext;

-

-

-    struct {

-        ContentType type;

-        ProtocolVersion version;

-        uint16 length;

-        opaque fragment[TLSCompressed.length];

-    } TLSCompressed;

-

-

-    struct {

-        ContentType type;

-        ProtocolVersion version;

-        uint16 length;

-        select (CipherSpec.cipher_type) {

-            case stream: GenericStreamCipher;

-            case block:  GenericBlockCipher;

-        } fragment;

-    } TLSCiphertext;

-

-

-    stream-ciphered struct {

-        opaque content[TLSCompressed.length];

-        opaque MAC[CipherSpec.hash_size];

-    } GenericStreamCipher;

-

-

-    block-ciphered struct {

-        opaque IV[CipherSpec.block_length];                              |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 55] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-        opaque content[TLSCompressed.length];

-        opaque MAC[CipherSpec.hash_size];

-        uint8 padding[GenericBlockCipher.padding_length];

-        uint8 padding_length;

-    } GenericBlockCipher;

-

-

-A.2. Change cipher specs message

-

-

-    struct {

-        enum { change_cipher_spec(1), (255) } type;

-    } ChangeCipherSpec;

-

-

-A.3. Alert messages

-

-

-    enum { warning(1), fatal(2), (255) } AlertLevel;

-

-

-        enum {

-            close_notify(0),

-            unexpected_message(10),

-            bad_record_mac(20),

-            decryption_failed(21),

-            record_overflow(22),

-            decompression_failure(30),

-            handshake_failure(40),

-         no_certificate_RESERVED (41),                                   |

-            bad_certificate(42),

-            unsupported_certificate(43),

-            certificate_revoked(44),

-            certificate_expired(45),

-            certificate_unknown(46),

-            illegal_parameter(47),

-            unknown_ca(48),

-            access_denied(49),

-            decode_error(50),

-            decrypt_error(51),

-            export_restriction(60),

-            protocol_version(70),

-            insufficient_security(71),

-            internal_error(80),

-            user_canceled(90),

-            no_renegotiation(100),

-            (255)

-        } AlertDescription;

-

-

-    struct {

-        AlertLevel level;

-        AlertDescription description;

-    } Alert;

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 56] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-A.4. Handshake protocol

-

-

-    enum {

-        hello_request(0), client_hello(1), server_hello(2),

-        certificate(11), server_key_exchange (12),

-        certificate_request(13), server_hello_done(14),

-        certificate_verify(15), client_key_exchange(16),

-        finished(20), (255)

-    } HandshakeType;

-

-

-    struct {

-        HandshakeType msg_type;

-        uint24 length;

-        select (HandshakeType) {

-            case hello_request:       HelloRequest;

-            case client_hello:        ClientHello;

-            case server_hello:        ServerHello;

-            case certificate:         Certificate;

-            case server_key_exchange: ServerKeyExchange;

-            case certificate_request: CertificateRequest;

-            case server_hello_done:   ServerHelloDone;

-            case certificate_verify:  CertificateVerify;

-            case client_key_exchange: ClientKeyExchange;

-            case finished:            Finished;

-        } body;

-    } Handshake;

-

-

-A.4.1. Hello messages

-

-

-    struct { } HelloRequest;

-

-

-    struct {

-        uint32 gmt_unix_time;

-        opaque random_bytes[28];

-    } Random;

-

-

-    opaque SessionID<0..32>;

-

-

-    uint8 CipherSuite[2];

-

-

-    enum { null(0), (255) } CompressionMethod;

-

-

-    struct {

-        ProtocolVersion client_version;

-        Random random;

-        SessionID session_id;

-        CipherSuite cipher_suites<2..2^16-1>;

-        CompressionMethod compression_methods<1..2^8-1>;

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 57] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-    } ClientHello;

-

-

-    struct {

-        ProtocolVersion server_version;

-        Random random;

-        SessionID session_id;

-        CipherSuite cipher_suite;

-        CompressionMethod compression_method;

-    } ServerHello;

-

-

-A.4.2. Server authentication and key exchange messages

-

-

-    opaque ASN.1Cert<2^24-1>;

-

-

-    struct {

-        ASN.1Cert certificate_list<0..2^24-1>;                           |

-    } Certificate;

-

-

-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;

-

-

-    struct {

-        opaque RSA_modulus<1..2^16-1>;

-        opaque RSA_exponent<1..2^16-1>;

-    } ServerRSAParams;

-

-

-    struct {

-        opaque DH_p<1..2^16-1>;

-        opaque DH_g<1..2^16-1>;

-        opaque DH_Ys<1..2^16-1>;

-    } ServerDHParams;

-

-

-    struct {

-        select (KeyExchangeAlgorithm) {

-            case diffie_hellman:

-                ServerDHParams params;

-                Signature signed_params;

-            case rsa:

-                ServerRSAParams params;

-                Signature signed_params;

-        };

-    } ServerKeyExchange;

-

-

-    enum { anonymous, rsa, dsa } SignatureAlgorithm;                     |

-

-

-    struct {                                                             |

-        select (KeyExchangeAlgorithm) {                                  |

-            case diffie_hellman:                                         |

-                ServerDHParams params;                                   |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 58] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-            case rsa:                                                    |

-                ServerRSAParams params;                                  |

-        };                                                               |

-     } ServerParams;                                                     |

-

-

-    select (SignatureAlgorithm)

-    {   case anonymous: struct { };

-        case rsa:

-            digitally-signed struct {

-                opaque md5_hash[16];

-                opaque sha_hash[20];

-            };

-        case dsa:

-            digitally-signed struct {

-                opaque sha_hash[20];

-            };

-    } Signature;

-

-

-    enum {

-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),

-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),         |

-     fortezza_dms_RESERVED(20),                                          |

-     (255)                                                               |

-    } ClientCertificateType;

-

-

-    opaque DistinguishedName<1..2^16-1>;

-

-

-    struct {

-        ClientCertificateType certificate_types<1..2^8-1>;

-        DistinguishedName certificate_authorities<0..2^16-1>;            |

-    } CertificateRequest;

-

-

-    struct { } ServerHelloDone;

-

-

-A.4.3. Client authentication and key exchange messages

-

-

-    struct {

-        select (KeyExchangeAlgorithm) {

-            case rsa: EncryptedPreMasterSecret;

-            case diffie_hellman: DiffieHellmanClientPublicValue;

-        } exchange_keys;

-    } ClientKeyExchange;

-

-

-    struct {

-        ProtocolVersion client_version;

-        opaque random[46];

-    } PreMasterSecret;

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 59] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-    struct {

-        public-key-encrypted PreMasterSecret pre_master_secret;

-    } EncryptedPreMasterSecret;

-

-

-    enum { implicit, explicit } PublicValueEncoding;

-

-

-    struct {

-        select (PublicValueEncoding) {

-            case implicit: struct {};

-            case explicit: opaque DH_Yc<1..2^16-1>;

-        } dh_public;

-    } ClientDiffieHellmanPublic;

-

-

-    struct {

-        Signature signature;

-    } CertificateVerify;

-

-

-A.4.4. Handshake finalization message

-

-

-    struct {

-        opaque verify_data[12];

-    } Finished;

-

-

-A.5. The CipherSuite

-

-

-   The following values define the CipherSuite codes used in the client

-   hello and server hello messages.

-

-

-   A CipherSuite defines a cipher specification supported in TLS Version |

-   1.1.

-

-

-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a

-   TLS connection during the first handshake on that channel, but must

-   not be negotiated, as it provides no more protection than an

-   unsecured connection.

-

-

-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };

-

-

-   The following CipherSuite definitions require that the server provide

-   an RSA certificate that can be used for key exchange. The server may

-   request either an RSA or a DSS signature-capable certificate in the

-   certificate request message.

-

-

-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };

-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };

-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };

-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };

-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 60] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };

-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };

-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };

-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };

-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };

-

-

-   The following CipherSuite definitions are used for server-

-   authenticated (and optionally client-authenticated) Diffie-Hellman.

-   DH denotes cipher suites in which the server's certificate contains

-   the Diffie-Hellman parameters signed by the certificate authority

-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman

-   parameters are signed by a DSS or RSA certificate, which has been

-   signed by the CA. The signing algorithm used is specified after the

-   DH or DHE parameter. The server can request an RSA or DSS signature-

-   capable certificate from the client for client authentication or it

-   may request a Diffie-Hellman certificate. Any Diffie-Hellman

-   certificate provided by the client must use the parameters (group and

-   generator) described by the server.

-

-

-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };

-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };

-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };

-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };

-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };

-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };

-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };

-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };

-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };

-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };

-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };

-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };

-

-

-   The following cipher suites are used for completely anonymous Diffie-

-   Hellman communications in which neither party is authenticated. Note

-   that this mode is vulnerable to man-in-the-middle attacks and is

-   therefore deprecated.

-

-

-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };

-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };

-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };

-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };

-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };

-

-

- Note: All cipher suites whose first byte is 0xFF are considered

-       private and can be used for defining local/experimental

-       algorithms. Interoperability of such types is a local matter.

-

-

- Note: Additional cipher suites can be registered by publishing an RFC

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 61] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       which specifies the cipher suites, including the necessary TLS

-       protocol information, including message encoding, premaster

-       secret derivation, symmetric encryption and MAC calculation and

-       appropriate reference information for the algorithms involved.

-       The RFC editor's office may, at its discretion, choose to publish

-       specifications for cipher suites which are not completely

-       described (e.g., for classified algorithms) if it finds the

-       specification to be of technical interest and completely

-       specified.

-

-

- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are

-       reserved to avoid collision with Fortezza-based cipher suites in

-       SSL 3.

-

-

-A.6. The Security Parameters

-

-

-   These security parameters are determined by the TLS Handshake

-   Protocol and provided as parameters to the TLS Record Layer in order

-   to initialize a connection state. SecurityParameters includes:

-

-

-       enum { null(0), (255) } CompressionMethod;

-

-

-       enum { server, client } ConnectionEnd;

-

-

-       enum { null, rc4, rc2, des, 3des, des40, idea }

-       BulkCipherAlgorithm;

-

-

-       enum { stream, block } CipherType;

-

-

-       enum { true, false } IsExportable;

-

-

-       enum { null, md5, sha } MACAlgorithm;

-

-

-   /* The algorithms specified in CompressionMethod,

-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */

-

-

-       struct {

-           ConnectionEnd entity;

-           BulkCipherAlgorithm bulk_cipher_algorithm;

-           CipherType cipher_type;

-           uint8 key_size;

-           uint8 key_material_length;

-           IsExportable is_exportable;

-           MACAlgorithm mac_algorithm;

-           uint8 hash_size;

-           CompressionMethod compression_algorithm;

-           opaque master_secret[48];

-           opaque client_random[32];

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 62] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-           opaque server_random[32];

-       } SecurityParameters;

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 63] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-B. Glossary

-

-

-   application protocol

-       An application protocol is a protocol that normally layers

-       directly on top of the transport layer (e.g., TCP/IP). Examples

-       include HTTP, TELNET, FTP, and SMTP.

-

-

-   asymmetric cipher

-       See public key cryptography.

-

-

-   authentication

-       Authentication is the ability of one entity to determine the

-       identity of another entity.

-

-

-   block cipher

-       A block cipher is an algorithm that operates on plaintext in

-       groups of bits, called blocks. 64 bits is a common block size.

-

-

-   bulk cipher

-       A symmetric encryption algorithm used to encrypt large quantities

-       of data.

-

-

-   cipher block chaining (CBC)

-       CBC is a mode in which every plaintext block encrypted with a

-       block cipher is first exclusive-ORed with the previous ciphertext

-       block (or, in the case of the first block, with the

-       initialization vector). For decryption, every block is first

-       decrypted, then exclusive-ORed with the previous ciphertext block

-       (or IV).

-

-

-   certificate

-       As part of the X.509 protocol (a.k.a. ISO Authentication

-       framework), certificates are assigned by a trusted Certificate

-       Authority and provide a strong binding between a party's identity

-       or some other attributes and its public key.

-

-

-   client

-       The application entity that initiates a TLS connection to a

-       server. This may or may not imply that the client initiated the

-       underlying transport connection. The primary operational

-       difference between the server and client is that the server is

-       generally authenticated, while the client is only optionally

-       authenticated.

-

-

-   client write key

-       The key used to encrypt data written by the client.

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 64] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   client write MAC secret

-       The secret data used to authenticate data written by the client.

-

-

-   connection

-       A connection is a transport (in the OSI layering model

-       definition) that provides a suitable type of service. For TLS,

-       such connections are peer to peer relationships. The connections

-       are transient. Every connection is associated with one session.

-

-

-   Data Encryption Standard

-       DES is a very widely used symmetric encryption algorithm. DES is

-       a block cipher with a 56 bit key and an 8 byte block size. Note

-       that in TLS, for key generation purposes, DES is treated as

-       having an 8 byte key length (64 bits), but it still only provides

-       56 bits of protection. (The low bit of each key byte is presumed

-       to be set to produce odd parity in that key byte.) DES can also

-       be operated in a mode where three independent keys and three

-       encryptions are used for each block of data; this uses 168 bits

-       of key (24 bytes in the TLS key generation method) and provides

-       the equivalent of 112 bits of security. [DES], [3DES]

-

-

-   Digital Signature Standard (DSS)

-       A standard for digital signing, including the Digital Signing

-       Algorithm, approved by the National Institute of Standards and

-       Technology, defined in NIST FIPS PUB 186, "Digital Signature

-       Standard," published May, 1994 by the U.S. Dept. of Commerce.

-       [DSS]

-

-

-   digital signatures                                                    |

-       Digital signatures utilize public key cryptography and one-way

-       hash functions to produce a signature of the data that can be

-       authenticated, and is difficult to forge or repudiate.

-

-

-   handshake

-       An initial negotiation between client and server that establishes

-       the parameters of their transactions.

-

-

-   Initialization Vector (IV)

-       When a block cipher is used in CBC mode, the initialization

-       vector is exclusive-ORed with the first plaintext block prior to

-       encryption.

-

-

-   IDEA

-       A 64-bit block cipher designed by Xuejia Lai and James Massey.

-       [IDEA]

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 65] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Message Authentication Code (MAC)

-       A Message Authentication Code is a one-way hash computed from a

-       message and some secret data. It is difficult to forge without

-       knowing the secret data. Its purpose is to detect if the message

-       has been altered.

-

-

-   master secret

-       Secure secret data used for generating encryption keys, MAC

-       secrets, and IVs.

-

-

-   MD5

-       MD5 is a secure hashing function that converts an arbitrarily

-       long data stream into a digest of fixed size (16 bytes). [MD5]

-

-

-   public key cryptography

-       A class of cryptographic techniques employing two-key ciphers.

-       Messages encrypted with the public key can only be decrypted with

-       the associated private key. Conversely, messages signed with the

-       private key can be verified with the public key.

-

-

-   one-way hash function

-       A one-way transformation that converts an arbitrary amount of

-       data into a fixed-length hash. It is computationally hard to

-       reverse the transformation or to find collisions. MD5 and SHA are

-       examples of one-way hash functions.

-

-

-   RC2

-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.

-       [RSADSI] described in [RC2].

-

-

-   RC4

-       A stream cipher licensed by RSA Data Security [RSADSI]. A

-       compatible cipher is described in [RC4].

-

-

-   RSA

-       A very widely used public-key algorithm that can be used for

-       either encryption or digital signing. [RSA]

-

-

-   salt

-       Non-secret random data used to make export encryption keys resist

-       precomputation attacks.

-

-

-   server

-       The server is the application entity that responds to requests

-       for connections from clients. See also under client.

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 66] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   session

-       A TLS session is an association between a client and a server.

-       Sessions are created by the handshake protocol. Sessions define a

-       set of cryptographic security parameters, which can be shared

-       among multiple connections. Sessions are used to avoid the

-       expensive negotiation of new security parameters for each

-       connection.

-

-

-   session identifier

-       A session identifier is a value generated by a server that

-       identifies a particular session.

-

-

-   server write key

-       The key used to encrypt data written by the server.

-

-

-   server write MAC secret

-       The secret data used to authenticate data written by the server.

-

-

-   SHA

-       The Secure Hash Algorithm is defined in FIPS PUB 180-1. It

-       produces a 20-byte output. Note that all references to SHA

-       actually use the modified SHA-1 algorithm. [SHA]

-

-

-   SSL

-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on

-       SSL Version 3.0

-

-

-   stream cipher

-       An encryption algorithm that converts a key into a

-       cryptographically-strong keystream, which is then exclusive-ORed

-       with the plaintext.

-

-

-   symmetric cipher                                                      |

-       See bulk cipher.

-

-

-   Transport Layer Security (TLS)

-       This protocol; also, the Transport Layer Security working group

-       of the Internet Engineering Task Force (IETF). See "Comments" at

-       the end of this document.

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 67] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-C. CipherSuite definitions

-

-

-CipherSuite                      Is       Key          Cipher      Hash

-                             Exportable Exchange

-

-

-TLS_NULL_WITH_NULL_NULL               * NULL           NULL        NULL

-TLS_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5

-TLS_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA

-TLS_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5

-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5

-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA

-TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5

-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA

-TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA

-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA

-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA

-TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA

-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA

-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA

-TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA

-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA

-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA

-TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA

-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA

-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA

-TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA

-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA

-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA

-TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5

-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5

-TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA

-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA

-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA

-

-

-

-   * Indicates IsExportable is True

-

-

-      Key

-      Exchange

-      Algorithm       Description                        Key size limit

-

-

-      DHE_DSS         Ephemeral DH with DSS signatures   None

-      DHE_DSS_EXPORT  Ephemeral DH with DSS signatures   DH = 512 bits

-      DHE_RSA         Ephemeral DH with RSA signatures   None

-      DHE_RSA_EXPORT  Ephemeral DH with RSA signatures   DH = 512 bits,

-                                                         RSA = none

-      DH_anon         Anonymous DH, no signatures        None

-      DH_anon_EXPORT  Anonymous DH, no signatures        DH = 512 bits

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 68] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-      DH_DSS          DH with DSS-based certificates     None

-      DH_DSS_EXPORT   DH with DSS-based certificates     DH = 512 bits

-      DH_RSA          DH with RSA-based certificates     None

-      DH_RSA_EXPORT   DH with RSA-based certificates     DH = 512 bits,

-                                                         RSA = none

-      NULL            No key exchange                    N/A

-      RSA             RSA key exchange                   None

-      RSA_EXPORT      RSA key exchange                   RSA = 512 bits

-

-

-   Key size limit

-       The key size limit gives the size of the largest public key that

-       can be legally used for encryption or key agreement in            |

-       cipher suites that are exportable.                                |

-

-

-                         Key      Expanded   Effective   IV    Block

-    Cipher       Type  Material Key Material  Key Bits  Size   Size

-

-

-    NULL       * Stream   0          0           0        0     N/A

-    IDEA_CBC     Block   16         16         128        8      8

-    RC2_CBC_40 * Block    5         16          40        8      8

-    RC4_40     * Stream   5         16          40        0     N/A

-    RC4_128      Stream  16         16         128        0     N/A

-    DES40_CBC  * Block    5          8          40        8      8

-    DES_CBC      Block    8          8          56        8      8

-    3DES_EDE_CBC Block   24         24         168        8      8

-

-

-   * Indicates IsExportable is true.

-

-

-   Type

-       Indicates whether this is a stream cipher or a block cipher

-       running in CBC mode.

-

-

-   Key Material

-       The number of bytes from the key_block that are used for

-       generating the write keys.

-

-

-   Expanded Key Material

-       The number of bytes actually fed into the encryption algorithm

-

-

-   Effective Key Bits

-       How much entropy material is in the key material being fed into

-       the encryption routines.

-

-

-   IV Size

-       How much data needs to be generated for the initialization

-       vector. Zero for stream ciphers; equal to the block size for

-       block ciphers.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 69] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Block Size

-       The amount of data a block cipher enciphers in one chunk; a

-       block cipher running in CBC mode can only encrypt an even

-       multiple of its block size.

-

-

-      Hash      Hash      Padding

-    function    Size       Size

-      NULL       0          0

-      MD5        16         48

-      SHA        20         40

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 70] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-D. Implementation Notes

-

-

-   The TLS protocol cannot prevent many common security mistakes. This

-   section provides several recommendations to assist implementors.

-

-

-D.1. Temporary RSA keys

-

-

-   US Export restrictions limit RSA keys used for encryption to 512

-   bits, but do not place any limit on lengths of RSA keys used for

-   signing operations. Certificates often need to be larger than 512

-   bits, since 512-bit RSA keys are not secure enough for high-value

-   transactions or for applications requiring long-term security. Some

-   certificates are also designated signing-only, in which case they

-   cannot be used for key exchange.

-

-

-   When the public key in the certificate cannot be used for encryption,

-   the server signs a temporary RSA key, which is then exchanged. In

-   exportable applications, the temporary RSA key should be the maximum

-   allowable length (i.e., 512 bits). Because 512-bit RSA keys are

-   relatively insecure, they should be changed often. For typical

-   electronic commerce applications, it is suggested that keys be

-   changed daily or every 500 transactions, and more often if possible.

-   Note that while it is acceptable to use the same temporary key for

-   multiple transactions, it must be signed each time it is used.

-

-

-   RSA key generation is a time-consuming process. In many cases, a low-

-   priority process can be assigned the task of key generation.

-

-

-   Whenever a new key is completed, the existing temporary key can be

-   replaced with the new one.

-

-

-D.2. Random Number Generation and Seeding

-

-

-   TLS requires a cryptographically-secure pseudorandom number generator

-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs

-   based on secure hash operations, most notably MD5 and/or SHA, are

-   acceptable, but cannot provide more security than the size of the

-   random number generator state. (For example, MD5-based PRNGs usually

-   provide 128 bits of state.)

-

-

-   To estimate the amount of seed material being produced, add the

-   number of bits of unpredictable information in each seed byte. For

-   example, keystroke timing values taken from a PC compatible's 18.2 Hz

-   timer provide 1 or 2 secure bits each, even though the total size of

-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one

-   would thus require approximately 100 such timer values.

-

-

-D.3. Certificates and authentication

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 71] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Implementations are responsible for verifying the integrity of

-   certificates and should generally support certificate revocation

-   messages. Certificates should always be verified to ensure proper

-   signing by a trusted Certificate Authority (CA). The selection and

-   addition of trusted CAs should be done very carefully. Users should

-   be able to view information about the certificate and root CA.

-

-

-D.4. CipherSuites

-

-

-   TLS supports a range of key sizes and security levels, including some

-   which provide no or minimal security. A proper implementation will

-   probably not support many cipher suites. For example, 40-bit

-   encryption is easily broken, so implementations requiring strong

-   security should not allow 40-bit keys. Similarly, anonymous Diffie-

-   Hellman is strongly discouraged because it cannot prevent man-in-the-

-   middle attacks. Applications should also enforce minimum and maximum

-   key sizes. For example, certificate chains containing 512-bit RSA

-   keys or signatures are not appropriate for high-security

-   applications.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 72] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-E. Backward Compatibility With SSL

-

-

-   For historical reasons and in order to avoid a profligate consumption

-   of reserved port numbers, application protocols which are secured by  |

-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same

-   connection port: for example, the https protocol (HTTP secured by SSL

-   or TLS) uses port 443 regardless of which security protocol it is

-   using. Thus, some mechanism must be determined to distinguish and

-   negotiate among the various protocols.

-

-

-   TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting |

-   both is easy. TLS clients who wish to negotiate with such older       |

-   servers SHOULD send client hello messages using the SSL 3.0 record    |

-   format and client hello structure, sending {3, 2} for the version     |

-   field to note that they support TLS 1.1. If the server supports only  |

-   TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;  |

-   if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.   |

-   The negotiation then proceeds as appropriate for the negotiated

-   protocol.

-

-

-   Similarly, a TLS 1.1  server which wishes to interoperate with TLS    |

-   1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages    |

-   and respond with a SSL 3.0 server hello if an SSL 3.0 client hello    |

-   with a version field of {3, 0} is received, denoting that this client |

-   does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a |

-   version field of {3, 1} is received, the server SHOULD respond with a |

-   TLS 1.0 hello with a version field of {3, 1}.

-

-

-   Whenever a client already knows the highest protocol known to a       |

-   server (for example, when resuming a session), it SHOULD initiate the

-   connection in that native protocol.

-

-

-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL    |

-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept

-   either client hello format if they wish to support SSL 2.0 clients on

-   the same connection port. The only deviations from the Version 2.0

-   specification are the ability to specify a version with a value of

-   three and the support for more ciphering types in the CipherSpec.

-

-

- Warning: The ability to send Version 2.0 client hello messages will be

-          phased out with all due haste. Implementors SHOULD make every  |

-          effort to move forward as quickly as possible. Version 3.0

-          provides better mechanisms for moving to newer versions.

-

-

-   The following cipher specifications are carryovers from SSL Version

-   2.0. These are assumed to use RSA for key exchange and

-   authentication.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 73] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };

-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };

-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };

-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5

-                                                  = { 0x04,0x00,0x80 };

-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };

-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };

-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };

-

-

-   Cipher specifications native to TLS can be included in Version 2.0

-   client hello messages using the syntax below. Any V2CipherSpec

-   element with its first byte equal to zero will be ignored by Version  |

-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD

-   also include the TLS equivalent (see Appendix A.5):

-

-

-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };

-

-

-E.1. Version 2 client hello

-

-

-   The Version 2.0 client hello message is presented below using this

-   document's presentation model. The true definition is still assumed   |

-   to be the SSL Version 2.0 specification. Note that this message MUST  |

-   be sent directly on the wire, not wrapped as an SSLv3 record

-

-

-       uint8 V2CipherSpec[3];

-

-

-       struct {

-           uint16 msg_length;                                            |

-           uint8 msg_type;

-           Version version;

-           uint16 cipher_spec_length;

-           uint16 session_id_length;

-           uint16 challenge_length;

-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];

-           opaque session_id[V2ClientHello.session_id_length];

-           opaque challenge[V2ClientHello.challenge_length;              |

-       } V2ClientHello;

-

-

-   msg_length                                                            |

-       This field is the length of the following data in bytes. The high |

-       bit MUST be 1 and is not part of the length.                      |

-

-

-   msg_type

-       This field, in conjunction with the version field, identifies a   |

-       version 2 client hello message. The value SHOULD be one (1).

-

-

-   version

-       The highest version of the protocol supported by the client

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 74] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-       (equals ProtocolVersion.version, see Appendix A.1).

-

-

-   cipher_spec_length

-       This field is the total length of the field cipher_specs. It      |

-       cannot be zero and MUST be a multiple of the V2CipherSpec length

-       (3).

-

-

-   session_id_length

-       This field MUST have a value of zero.                             |

-

-

-   challenge_length

-       The length in bytes of the client's challenge to the server to    |

-       authenticate itself. When using the SSLv2 backward compatible     |

-       handshake the client MUST use a 32-byte challenge.

-

-

-   cipher_specs

-       This is a list of all CipherSpecs the client is willing and able  |

-       to use. There MUST be at least one CipherSpec acceptable to the

-       server.

-

-

-   session_id

-       This field MUST be empty.                                         |

-

-

-   challenge

-       The client challenge to the server for the server to identify

-       itself is a (nearly) arbitrary length random. The TLS server will

-       right justify the challenge data to become the ClientHello.random

-       data (padded with leading zeroes, if necessary), as specified in

-       this protocol specification. If the length of the challenge is

-       greater than 32 bytes, only the last 32 bytes are used. It is

-       legitimate (but not necessary) for a V3 server to reject a V2

-       ClientHello that has fewer than 16 bytes of challenge data.

-

-

- Note: Requests to resume a TLS session MUST use a TLS client hello.     |

-

-

-E.2. Avoiding man-in-the-middle version rollback

-

-

-   When TLS clients fall back to Version 2.0 compatibility mode, they    |

-   SHOULD use special PKCS #1 block formatting. This is done so that TLS

-   servers will reject Version 2.0 sessions with TLS-capable clients.

-

-

-   When TLS clients are in Version 2.0 compatibility mode, they set the

-   right-hand (least-significant) 8 random bytes of the PKCS padding

-   (not including the terminal null of the padding) for the RSA

-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY

-   to 0x03 (the other padding bytes are random). After decrypting the    |

-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an

-   error if these eight padding bytes are 0x03. Version 2.0 servers

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 75] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   receiving blocks padded in this manner will proceed normally.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 76] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-F. Security analysis

-

-

-   The TLS protocol is designed to establish a secure connection between

-   a client and a server communicating over an insecure channel. This

-   document makes several traditional assumptions, including that

-   attackers have substantial computational resources and cannot obtain

-   secret information from sources outside the protocol. Attackers are

-   assumed to have the ability to capture, modify, delete, replay, and

-   otherwise tamper with messages sent over the communication channel.

-   This appendix outlines how TLS has been designed to resist a variety

-   of attacks.

-

-

-F.1. Handshake protocol

-

-

-   The handshake protocol is responsible for selecting a CipherSpec and

-   generating a Master Secret, which together comprise the primary

-   cryptographic parameters associated with a secure session. The

-   handshake protocol can also optionally authenticate parties who have

-   certificates signed by a trusted certificate authority.

-

-

-F.1.1. Authentication and key exchange

-

-

-   TLS supports three authentication modes: authentication of both

-   parties, server authentication with an unauthenticated client, and

-   total anonymity. Whenever the server is authenticated, the channel is

-   secure against man-in-the-middle attacks, but completely anonymous

-   sessions are inherently vulnerable to such attacks.  Anonymous

-   servers cannot authenticate clients. If the server is authenticated,

-   its certificate message must provide a valid certificate chain

-   leading to an acceptable certificate authority.  Similarly,

-   authenticated clients must supply an acceptable certificate to the

-   server. Each party is responsible for verifying that the other's

-   certificate is valid and has not expired or been revoked.

-

-

-   The general goal of the key exchange process is to create a

-   pre_master_secret known to the communicating parties and not to

-   attackers. The pre_master_secret will be used to generate the

-   master_secret (see Section 8.1). The master_secret is required to     |

-   generate the finished messages, encryption keys, and MAC secrets (see

-   Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished

-   message, parties thus prove that they know the correct

-   pre_master_secret.

-

-

-F.1.1.1. Anonymous key exchange

-

-

-   Completely anonymous sessions can be established using RSA or Diffie-

-   Hellman for key exchange. With anonymous RSA, the client encrypts a

-   pre_master_secret with the server's uncertified public key extracted

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 77] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   from the server key exchange message. The result is sent in a client

-   key exchange message. Since eavesdroppers do not know the server's

-   private key, it will be infeasible for them to decode the             |

-   pre_master_secret.                                                    |

-

-

-   Note: No anonymous RSA Cipher Suites are defined in this document.

-

-

-   With Diffie-Hellman, the server's public parameters are contained in

-   the server key exchange message and the client's are sent in the

-   client key exchange message. Eavesdroppers who do not know the

-   private values should not be able to find the Diffie-Hellman result

-   (i.e. the pre_master_secret).

-

-

- Warning: Completely anonymous connections only provide protection

-          against passive eavesdropping. Unless an independent tamper-

-          proof channel is used to verify that the finished messages

-          were not replaced by an attacker, server authentication is

-          required in environments where active man-in-the-middle

-          attacks are a concern.

-

-

-F.1.1.2. RSA key exchange and authentication

-

-

-   With RSA, key exchange and server authentication are combined. The

-   public key may be either contained in the server's certificate or may

-   be a temporary RSA key sent in a server key exchange message.  When

-   temporary RSA keys are used, they are signed by the server's RSA      |

-   certificate. The signature includes the current ClientHello.random,

-   so old signatures and temporary keys cannot be replayed. Servers may

-   use a single temporary RSA key for multiple negotiation sessions.

-

-

- Note: The temporary RSA key option is useful if servers need large

-       certificates but must comply with government-imposed size limits

-       on keys used for key exchange.

-

-

-   Note that if ephemeral RSA is not used, compromise of the server's    |

-   static RSA key results in a loss of confidentiality for all sessions  |

-   protected under that static key. TLS users desiring Perfect Forward   |

-   Secrecy should use DHE cipher suites. The damage done by exposure of  |

-   a private key can be limited by changing one's private key (and       |

-   certificate) frequently.                                              |

-

-

-   After verifying the server's certificate, the client encrypts a

-   pre_master_secret with the server's public key. By successfully

-   decoding the pre_master_secret and producing a correct finished

-   message, the server demonstrates that it knows the private key

-   corresponding to the server certificate.

-

-

-   When RSA is used for key exchange, clients are authenticated using

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 78] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   the certificate verify message (see Section 7.4.8). The client signs

-   a value derived from the master_secret and all preceding handshake

-   messages. These handshake messages include the server certificate,

-   which binds the signature to the server, and ServerHello.random,

-   which binds the signature to the current handshake process.

-

-

-F.1.1.3. Diffie-Hellman key exchange with authentication

-

-

-   When Diffie-Hellman key exchange is used, the server can either

-   supply a certificate containing fixed Diffie-Hellman parameters or

-   can use the server key exchange message to send a set of temporary

-   Diffie-Hellman parameters signed with a DSS or RSA certificate.

-   Temporary parameters are hashed with the hello.random values before

-   signing to ensure that attackers do not replay old parameters. In

-   either case, the client can verify the certificate or signature to

-   ensure that the parameters belong to the server.

-

-

-   If the client has a certificate containing fixed Diffie-Hellman

-   parameters, its certificate contains the information required to

-   complete the key exchange. Note that in this case the client and

-   server will generate the same Diffie-Hellman result (i.e.,

-   pre_master_secret) every time they communicate. To prevent the

-   pre_master_secret from staying in memory any longer than necessary,

-   it should be converted into the master_secret as soon as possible.

-   Client Diffie-Hellman parameters must be compatible with those

-   supplied by the server for the key exchange to work.

-

-

-   If the client has a standard DSS or RSA certificate or is

-   unauthenticated, it sends a set of temporary parameters to the server

-   in the client key exchange message, then optionally uses a

-   certificate verify message to authenticate itself.

-

-

-   If the same DH keypair is to be used for multiple handshakes, either  |

-   because the client or server has a certificate containing a fixed DH  |

-   keypair or because the server is reusing DH keys, care must be taken  |

-   to prevent small subgroup attacks. Implementations SHOULD follow the  |

-   guidelines found in [SUBGROUP].                                       |

-

-

-   Small subgroup attacks are most easily avoided by using one of the    |

-   DHE ciphersuites and generating a fresh DH private key (X) for each   |

-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be |

-   computed very quickly so the performance cost is minimized.           |

-   Additionally, using a fresh key for each handshake provides Perfect   |

-   Forward Secrecy. Implementations SHOULD generate a new X for each     |

-   handshake when using DHE ciphersuites.                                |

-

-

-F.1.2. Version rollback attacks

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 79] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Because TLS includes substantial improvements over SSL Version 2.0,

-   attackers may try to make TLS-capable clients and servers fall back

-   to Version 2.0. This attack can occur if (and only if) two TLS-

-   capable parties use an SSL 2.0 handshake.

-

-

-   Although the solution using non-random PKCS #1 block type 2 message

-   padding is inelegant, it provides a reasonably secure way for Version

-   3.0 servers to detect the attack. This solution is not secure against

-   attackers who can brute force the key and substitute a new ENCRYPTED-

-   KEY-DATA message containing the same key (but with normal padding)

-   before the application specified wait threshold has expired. Parties

-   concerned about attacks of this scale should not be using 40-bit

-   encryption keys anyway. Altering the padding of the least-significant

-   8 bytes of the PKCS padding does not impact security for the size of

-   the signed hashes and RSA key lengths used in the protocol, since

-   this is essentially equivalent to increasing the input block size by

-   8 bytes.

-

-

-F.1.3. Detecting attacks against the handshake protocol

-

-

-   An attacker might try to influence the handshake exchange to make the

-   parties select different encryption algorithms than they would        |

-   normally chooses. Because many implementations will support 40-bit

-   exportable encryption and some may even support null encryption or

-   MAC algorithms, this attack is of particular concern.

-

-

-   For this attack, an attacker must actively change one or more

-   handshake messages. If this occurs, the client and server will

-   compute different values for the handshake message hashes. As a

-   result, the parties will not accept each others' finished messages.

-   Without the master_secret, the attacker cannot repair the finished

-   messages, so the attack will be discovered.

-

-

-F.1.4. Resuming sessions

-

-

-   When a connection is established by resuming a session, new

-   ClientHello.random and ServerHello.random values are hashed with the

-   session's master_secret. Provided that the master_secret has not been

-   compromised and that the secure hash operations used to produce the

-   encryption keys and MAC secrets are secure, the connection should be

-   secure and effectively independent from previous connections.

-   Attackers cannot use known encryption keys or MAC secrets to

-   compromise the master_secret without breaking the secure hash

-   operations (which use both SHA and MD5).

-

-

-   Sessions cannot be resumed unless both the client and server agree.

-   If either party suspects that the session may have been compromised,

-   or that certificates may have expired or been revoked, it should

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 80] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   force a full handshake. An upper limit of 24 hours is suggested for

-   session ID lifetimes, since an attacker who obtains a master_secret

-   may be able to impersonate the compromised party until the

-   corresponding session ID is retired. Applications that may be run in

-   relatively insecure environments should not write session IDs to

-   stable storage.

-

-

-F.1.5. MD5 and SHA

-

-

-   TLS uses hash functions very conservatively. Where possible, both MD5

-   and SHA are used in tandem to ensure that non-catastrophic flaws in

-   one algorithm will not break the overall protocol.

-

-

-F.2. Protecting application data

-

-

-   The master_secret is hashed with the ClientHello.random and

-   ServerHello.random to produce unique data encryption keys and MAC

-   secrets for each connection.

-

-

-   Outgoing data is protected with a MAC before transmission. To prevent

-   message replay or modification attacks, the MAC is computed from the

-   MAC secret, the sequence number, the message length, the message

-   contents, and two fixed character strings. The message type field is

-   necessary to ensure that messages intended for one TLS Record Layer

-   client are not redirected to another. The sequence number ensures

-   that attempts to delete or reorder messages will be detected. Since

-   sequence numbers are 64-bits long, they should never overflow.

-   Messages from one party cannot be inserted into the other's output,

-   since they use independent MAC secrets. Similarly, the server-write

-   and client-write keys are independent so stream cipher keys are used

-   only once.

-

-

-   If an attacker does break an encryption key, all messages encrypted

-   with it can be read. Similarly, compromise of a MAC key can make

-   message modification attacks possible. Because MACs are also

-   encrypted, message-alteration attacks generally require breaking the

-   encryption algorithm as well as the MAC.

-

-

- Note: MAC secrets may be larger than encryption keys, so messages can

-       remain tamper resistant even if encryption keys are broken.

-

-

-F.3. Explicit IVs                                                        |

-

-

-       [CBCATT] describes a chosen plaintext attack on TLS that depends  |

-       on knowing the IV for a record. Previous versions of TLS [TLS1.0] |

-       used the CBC residue of the previous record as the IV and         |

-       therefore enabled this attack. This version uses an explicit IV   |

-       in order to protect against this attack.                          |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 81] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-F.4 Security of Composite Cipher Modes                                   |

-

-

-       TLS secures transmitted application data via the use of symmetric |

-       encryption and authentication functions defined in the negotiated |

-       ciphersuite.  The objective is to protect both the integrity  and |

-       confidentiality of the transmitted data from malicious actions by |

-       active attackers in the network.  It turns out that the order in  |

-       which encryption and authentication functions are applied to the  |

-       data plays an important role for achieving this goal [ENCAUTH].   |

-

-

-       The most robust method, called encrypt-then-authenticate, first   |

-       applies encryption to the data and then applies a MAC to the      |

-       ciphertext.  This method ensures that the integrity and           |

-       confidentiality goals are obtained with ANY pair of encryption    |

-       and MAC functions provided that the former is secure against      |

-       chosen plaintext attacks and the MAC is secure against chosen-    |

-       message attacks.  TLS uses another method, called authenticate-   |

-       then-encrypt, in which first a MAC is computed on the plaintext   |

-       and then the concatenation of plaintext and MAC is encrypted.     |

-       This method has been proven secure for CERTAIN combinations of    |

-       encryption functions and MAC functions, but is not guaranteed to  |

-       be secure in general. In particular, it has been shown that there |

-       exist perfectly secure encryption functions (secure even in the   |

-       information theoretic sense) that combined with any secure MAC    |

-       function fail to provide the confidentiality goal against an      |

-       active attack.  Therefore, new ciphersuites and operation modes   |

-       adopted into TLS need to be analyzed under the authenticate-then- |

-       encrypt method to verify that they achieve the stated integrity   |

-       and confidentiality goals.                                        |

-

-

-       Currently, the security of the authenticate-then-encrypt method   |

-       has been proven for some important cases.  One is the case of     |

-       stream ciphers in which a computationally unpredictable pad of    |

-       the length of the message plus the length of the MAC tag is       |

-       produced using a pseudo-random generator and this pad is xor-ed   |

-       with the concatenation of plaintext and MAC tag.  The other is    |

-       the case of CBC mode using a secure block cipher.  In this case,  |

-       security can be shown if one applies one CBC encryption pass to   |

-       the concatenation of plaintext and MAC and uses a new,            |

-       independent and unpredictable, IV for each new pair of plaintext  |

-       and MAC.  In previous versions of SSL, CBC mode was used properly |

-       EXCEPT that it used a predictable IV in the form of the last      |

-       block of the previous ciphertext. This made TLS open to chosen    |

-       plaintext attacks.  This verson of the protocol is immune to      |

-       those attacks.  For exact details in the encryption modes proven  |

-       secure see [ENCAUTH].                                             |

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 82] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-F.5 Denial of Service                                                    |

-

-

-       TLS is susceptible to a number of denial of service (DoS)         |

-       attacks.  In particular, an attacker who initiates a large number |

-       of TCP connections can cause a server to consume large amounts of |

-       CPU doing RSA decryption. However, because TLS is generally used  |

-       over TCP, it is difficult for the attacker to hide his point of   |

-       origin if proper TCP SYN randomization is used [SEQNUM] by the    |

-       TCP stack.                                                        |

-

-

-       Because TLS runs over TCP, it is also susceptible to a number of  |

-       denial of service attacks on individual connections. In           |

-       particular, attackers can forge RSTs, terminating connections, or |

-       forge partial TLS records, causing the connection to stall.       |

-       These attacks cannot in general be defended against by a TCP-     |

-       using protocol. Implementors or users who are concerned with this |

-       class of attack should use IPsec AH [AH] or ESP [ESP].            |

-

-

-F.6. Final notes

-

-

-   For TLS to be able to provide a secure connection, both the client

-   and server systems, keys, and applications must be secure. In

-   addition, the implementation must be free of security errors.

-

-

-   The system is only as strong as the weakest key exchange and

-   authentication algorithm supported, and only trustworthy

-   cryptographic functions should be used. Short public keys, 40-bit

-   bulk encryption keys, and anonymous servers should be used with great

-   caution. Implementations and users must be careful when deciding

-   which certificates and certificate authorities are acceptable; a

-   dishonest certificate authority can do tremendous damage.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 83] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-G. Patent Statement

-

-

-   Netscape Communications Corporation (now America Online) has a patent |

-   claim on the Secure Sockets Layer (SSL) work that this standard is    |

-   based on. The Internet Standards Process as defined in RFC 2026       |

-   requests that a statement be obtained from a Patent holder indicating |

-   that a license will be made available to applicants under reasonable  |

-   terms and conditions.

-

-

-       Secure Socket Layer Application Program Apparatus And Method

-       ("SSL"), No. 5,657,390

-

-

-   Netscape Communications has issued the following statement:

-

-

-       Intellectual Property Rights

-

-

-       Secure Sockets Layer

-

-

-       The United States Patent and Trademark Office ("the PTO")

-       recently issued U.S. Patent No. 5,657,390 ("the SSL Patent")  to

-       Netscape for inventions described as Secure Sockets Layers

-       ("SSL"). The IETF is currently considering adopting SSL as a

-       transport protocol with security features.  Netscape encourages

-       the royalty-free adoption and use of the SSL protocol upon the

-       following terms and conditions:

-

-

-         * If you already have a valid SSL Ref license today which

-           includes source code from Netscape, an additional patent

-           license under the SSL patent is not required.

-

-

-         * If you don't have an SSL Ref license, you may have a royalty

-           free license to build implementations covered by the SSL

-           Patent Claims or the IETF TLS specification provided that you

-           do not to assert any patent rights against Netscape or other

-           companies for the implementation of SSL or the IETF TLS

-           recommendation.

-

-

-       What are "Patent Claims":

-

-

-       Patent claims are claims in an issued foreign or domestic patent

-       that:

-

-

-        1) must be infringed in order to implement methods or build

-           products according to the IETF TLS specification;  or

-

-

-        2) patent claims which require the elements of the SSL patent

-           claims and/or their equivalents to be infringed.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 84] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   The Internet Society, Internet Architecture Board, Internet

-   Engineering Steering Group and the Corporation for National Research

-   Initiatives take no position on the validity or scope of the patents

-   and patent applications, nor on the appropriateness of the terms of

-   the assurance. The Internet Society and other groups mentioned above

-   have not made any determination as to any other intellectual property

-   rights which may apply to the practice of this standard.  Any further

-   consideration of these matters is the user's own responsibility.

-

-

-Security Considerations

-

-

-   Security issues are discussed throughout this memo, especially in     |

-   Appendices D, E, and F.

-

-

-Normative References                                                     |

-

-

-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," |

-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.

-

-

-   [DES]    ANSI X3.106, "American National Standard for Information

-            Systems-Data Link Encryption," American National Standards

-            Institute, 1983.

-

-

-   [DH1]    W. Diffie and M. E. Hellman, "New Directions in

-            Cryptography," IEEE Transactions on Information Theory, V.

-            IT-22, n. 6, Jun 1977, pp. 74-84.

-

-

-   [DSS]    NIST FIPS PUB 186, "Digital Signature Standard," National

-            Institute of Standards and Technology, U.S. Department of

-            Commerce, May 18, 1994.

-

-

-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-

-            Hashing for Message Authentication," RFC 2104, February

-            1997.

-

-

-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH

-            Series in Information Processing, v. 1, Konstanz: Hartung-

-            Gorre Verlag, 1992.

-

-

-   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,

-            April 1992.

-

-

-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,

-            April 1992.

-

-

-   [PKCS1]  RSA Laboratories, "PKCS #1: RSA Encryption Standard,"

-            version 1.5, November 1993.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 85] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax

-            Standard," version 1.5, November 1993.

-

-

-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax

-            Standard," version 1.5, November 1993.

-

-

-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet

-            Public Key Infrastructure: Part I: X.509 Certificate and CRL

-            Profile", RFC 2459, January 1999.

-

-

-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption

-            Algorithm", RFC 2268, January 1998.

-

-

-   [RC4]    Thayer, R. and K. Kaukonen, A Stream Cipher Encryption

-            Algorithm, Work in Progress.

-

-

-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for

-            Obtaining Digital Signatures and Public-Key Cryptosystems,"

-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.

-            120-126.

-

-

-   [SHA]    NIST FIPS PUB 180-1, "Secure Hash Standard," National

-            Institute of Standards and Technology, U.S. Department of

-            Commerce, Work in Progress, May 31, 1994.

-

-

-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications

-            Corp., Feb 9, 1995.

-

-

-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",

-            Netscape Communications Corp., Nov 18, 1996.

-

-

-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate          |

-            Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-

-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",  |

-            RFC 2246, January 1999.

-

-

-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,    |

-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC |

-            3546, June 2003.

-   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication

-            Framework". 1988.

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 86] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-Informative References                                                   |

-

-

-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC  |

-            2402, November 1998.                                         |

-

-

-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against        |

-            Protocols Based on RSA Encryption Standard PKCS #1" in       |

-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:  |

-            1-12, 1998.                                                  |

-

-

-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:       |

-            Problems and Countermeasures",                               |

-            http://www.openssl.org/~bodo/tls-cbc.txt.                    |

-

-

-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",   |

-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.                |

-

-

-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication   |

-            for Protecting Communications (Or: How Secure is SSL?)",     |

-            Crypto 2001.                                                 |

-

-

-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security      |

-            Payload (ESP)", RFC 2406, November 1998.                     |

-

-

-   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9, |

-            RFC 959, October 1985.                                       |

-

-

-   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext    |

-            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.          |

-

-

-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based       |

-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,      |

-            March 2003.                                                  |

-   [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782           |

-

-

-   [SCH]    B. Schneier. Applied Cryptography: Protocols, Algorithms,    |

-            and Source Code in C, Published by John Wiley & Sons, Inc.   |

-            1994.                                                        |

-

-

-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",   |

-            RFC 1948, May 1996.                                          |

-

-

-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup    |

-            Attacks on the Diffie-Hellman Key Agreement Method for       |

-            S/MIME", RFC 2785, March 2000.                               |

-

-

-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793, |

-            September 1981.                                              |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 87] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are           |

-            practical", USENIX Security Symposium 2003.                  |

-

-

-   [XDR]    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External

-            Data Representation Standard, August 1995.

-

-

-

-Credits                                                                  |

-

-

-   Working Group Chairs                                                  |

-   Win Treese

-   EMail: treese@acm.org                                                 |

-

-

-   Eric Rescorla                                                         |

-   EMail: ekr@rtfm.com                                                   |

-

-

-

-   Editors

-

-

-   Tim Dierks                Eric Rescorla                               |

-   Google                    RTFM, Inc.                                  |

-

-

-   EMail: tim@dierks.org         EMail: ekr@rtfm.com                     |

-

-

-

-

-   Other contributors

-

-

-   Christopher Allen (co-editor of TLS 1.0)                              |

-   Alacrity Ventures                                                     |

-   ChristopherA@AlacrityVentures.com                                     |

-

-

-   Martin Abadi                                                          |

-   University of California, Santa Cruz                                  |

-   abadi@cs.ucsc.edu                                                     |

-

-

-   Ran Canetti                                                           |

-   IBM                                                                   |

-   canetti@watson.ibm.com                                                |

-

-

-   Taher Elgamal                                                         |

-   taher@securify.com                                                    |

-   Securify                                                              |

-

-

-   Anil Gangolli                                                         |

-   Structured Arts                                                       |

-

-

-   Kipp Hickman                                                          |

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 88] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-   Phil Karlton (co-author of SSLv3)                                     |

-

-

-   Paul Kocher (co-author of SSLv3)                                      |

-   Cryptography Research                                                 |

-   paul@cryptography.com                                                 |

-

-

-   Hugo Krawczyk                                                         |

-   Technion Israel Institute of Technology                               |

-   hugo@ee.technion.ac.il                                                |

-

-

-   Robert Relyea                                                         |

-   Netscape Communications                                               |

-   relyea@netscape.com                                                   |

-

-

-   Jim Roskind                                                           |

-   Netscape Communications                                               |

-   jar@netscape.com                                                      |

-

-

-   Michael Sabin                                                         |

-

-

-   Dan Simon                                                             |

-   Microsoft, Inc.                                                       |

-   dansimon@microsoft.com                                                |

-

-

-   Tom Weinstein                                                         |

-

-

-Comments

-

-

-   The discussion list for the IETF TLS working group is located at the

-   e-mail address <ietf-tls@lists.consensus.com>. Information on the

-   group and information on how to subscribe to the list is at

-   <http://lists.consensus.com/>.

-

-

-   Archives of the list can be found at:

-       <http://www.imc.org/ietf-tls/mail-archive/>

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 89] draft-ietf-tls-rfc2246-bis-06.txt  TLS                        March 2004

-

-

-

-Full Copyright Statement

-

-

-   Copyright (C) The Internet Society (1999).  All Rights Reserved.

-

-

-   This document and translations of it may be copied and furnished to

-   others, and derivative works that comment on or otherwise explain it

-   or assist in its implementation may be prepared, copied, published

-   and distributed, in whole or in part, without restriction of any

-   kind, provided that the above copyright notice and this paragraph are

-   included on all such copies and derivative works.  However, this

-   document itself may not be modified in any way, such as by removing

-   the copyright notice or references to the Internet Society or other

-   Internet organizations, except as needed for the purpose of

-   developing Internet standards in which case the procedures for

-   copyrights defined in the Internet Standards process must be

-   followed, or as required to translate it into languages other than

-   English.

-

-

-   The limited permissions granted above are perpetual and will not be

-   revoked by the Internet Society or its successors or assigns.

-

-

-   This document and the information contained herein is provided on an

-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 90] 
\ No newline at end of file
diff --git a/doc/protocol/draft-ietf-tls-rfc2246-bis-08.txt b/doc/protocol/draft-ietf-tls-rfc2246-bis-08.txt
deleted file mode 100644
index cd2225bcbe..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc2246-bis-08.txt
+++ /dev/null
@@ -1,4967 +0,0 @@
-                                                             Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                                RTFM, Inc.
-<draft-ietf-tls-rfc2246-bis-08.txt>  August 2004 (Expires February 2005)
-
-                            The TLS Protocol
-                              Version 1.1
-
-Status of this Memo
-
-By submitting this Internet-Draft, I certify that any applicable
-patent or other IPR claims of which I am aware have been disclosed,
-and any of which I become aware will be disclosed, in accordance with
-RFC 3668.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-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 a "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999-2004).  All Rights Reserved.
-
-Abstract
-
-   This document specifies Version 1.1 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction
-   5 1.1       Requirements Terminology
-   6 2.        Goals
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   6 3.        Goals of this document
-   7 4.        Presentation language
-   7 4.1.      Basic block size
-   8 4.2.      Miscellaneous
-   8 4.3.      Vectors
-   8 4.4.      Numbers
-   9 4.5.      Enumerateds
-   9 4.6.      Constructed types
-   10 4.6.1.    Variants
-   11 4.7.      Cryptographic attributes
-   12 4.8.      Constants
-   13 5.        HMAC and the pseudorandom function
-   13 6.        The TLS Record Protocol
-   15 6.1.      Connection states
-   16 6.2.      Record layer
-   18 6.2.1.    Fragmentation
-   18 6.2.2.    Record compression and decompression
-   19 6.2.3.    Record payload protection
-   20 6.2.3.1.  Null or standard stream cipher
-   21 6.2.3.2.  CBC block cipher
-   21 6.3.      Key calculation
-   24 6.3.1.    Export key generation example
-   25 7.        The TLS Handshake Protocol
-   26 7.1.      Change cipher spec protocol
-   26 7.2.      Alert protocol
-   27 7.2.1.    Closure alerts
-   28 7.2.2.    Error alerts
-   29 7.3.      Handshake Protocol overview
-   33 7.4.      Handshake protocol
-   36 7.4.1.    Hello messages
-   37 7.4.1.1.  Hello request
-   37 7.4.1.2.  Client hello
-   38 7.4.1.3.  Server hello
-   40 7.4.2.    Server certificate
-   41 7.4.3.    Server key exchange message
-   43 7.4.4.    Certificate request
-   46 7.4.5.    Server hello done
-   47 7.4.6.    Client certificate
-   47 7.4.7.    Client key exchange message
-   48 7.4.7.1.  RSA encrypted premaster secret message
-   48 7.4.7.2.  Client Diffie-Hellman public value
-   50 7.4.8.    Certificate verify
-   51 7.4.9.    Finished
-   52 8.        Cryptographic computations
-   53 8.1.      Computing the master secret
-   53 8.1.1.    RSA
-   54 8.1.2.    Diffie-Hellman
-   54 9.        Mandatory Cipher Suites
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   54 A.        Protocol constant values
-   56 A.1.      Record layer
-   56 A.2.      Change cipher specs message
-   57 A.3.      Alert messages
-   57 A.4.      Handshake protocol
-   58 A.4.1.    Hello messages
-   58 A.4.2.    Server authentication and key exchange messages
-   59 A.4.3.    Client authentication and key exchange messages
-   60 A.4.4.    Handshake finalization message
-   61 A.5.      The CipherSuite
-   61 A.6.      The Security Parameters
-   63 B.        Glossary
-   65 C.        CipherSuite definitions
-   69 D.        Implementation Notes
-   72 D.1.      Temporary RSA keys
-   72 D.2.      Random Number Generation and Seeding
-   72 D.3.      Certificates and authentication
-   72 D.4.      CipherSuites
-   73 E.        Backward Compatibility With SSL
-   74 E.1.      Version 2 client hello
-   75 E.2.      Avoiding man-in-the-middle version rollback
-   76 F.        Security analysis
-   78 F.1.      Handshake protocol
-   78 F.1.1.    Authentication and key exchange
-   78 F.1.1.1.  Anonymous key exchange
-   78 F.1.1.2.  RSA key exchange and authentication
-   79 F.1.1.3.  Diffie-Hellman key exchange with authentication
-   80 F.1.2.    Version rollback attacks
-   80 F.1.3.    Detecting attacks against the handshake protocol
-   81 F.1.4.    Resuming sessions
-   81 F.1.5.    MD5 and SHA
-   82 F.2.      Protecting application data
-   82 F.3.      Explicit IVs
-   82 F.4       Security of Composite Cipher Modes
-   83 F.5       Denial of Service
-   84 F.6.      Final notes
-   84
-
-
-Change history
-
-   Note: Change bars in this draft are from RFC 2246, not draft-00
-   10-Aug-04 ekr@rtfm.com
-    * Added clarifying material about interleaved application data.
-
-   27-Jul-04 ekr@rtfm.com
-    * Premature closes no longer cause a session to be nonresumable.
-      Response to WG consensus.
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-    * Added IANA considerations and registry for cipher suites
-      and ClientCertificateTypes
-
-   26-Jun-03 ekr@rtfm.com
-    * Incorporated Last Call comments from Franke Marcus, Jack Lloyd,
-    Brad Wetmore, and others.
-
-   22-Apr-03 ekr@rtfm.com
-    * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks
-    * cleaned up IV text a bit.
-    * Added discussion of Denial of Service attacks.
-
-   11-Feb-02 ekr@rtfm.com
-    * Clarified the behavior of empty certificate lists [Nelson Bolyard]
-    * Added text explaining the security implications of authenticate
-      then encrypt.
-    * Cleaned up the explicit IV text.
-    * Added some more acknowledgement names
-
-   02-Nov-02 ekr@rtfm.com
-    * Changed this to be TLS 1.1.
-    * Added fixes for the Rogaway and Vaudenay CBC attacks
-    * Separated references into normative and informative
-
-   01-Mar-02 ekr@rtfm.com
-    * Tightened up the language in F.1.1.2 [Peter Watkins]
-    * Fixed smart quotes [Bodo Moeller]
-    * Changed handling of padding errors to prevent CBC-based attack
-      [Bodo Moeller]
-    * Fixed certificate_list spec in the appendix [Aman Sawrup]
-    * Fixed a bug in the V2 definitions [Aman Sawrup]
-    * Fixed S 7.2.1 to point out that you don't need a close notify
-      if you just sent some other fatal alert [Andreas Sterbenz]
-    * Marked alert 41 reserved [Andreas Sterbenz]
-    * Changed S 7.4.2 to point out that 512-bit keys cannot be used for
-      signing [Andreas Sterbenz]
-    * Added reserved client key types from SSLv3 [Andreas Sterbenz]
-    * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz]
-    * Removed RSA patent statement [Andreas Sterbenz]
-    * Removed references to BSAFE and RSAREF [Andreas Sterbenz]
-
-   14-Feb-02 ekr@rtfm.com
-    * Re-converted to I-D from RFC
-    * Made RSA/3DES the mandatory cipher suite.
-    * Added discussion of the EncryptedPMS encoding and PMS version number
-      issues to 7.4.7.1
-    * Removed the requirement in 7.4.1.3 that the Server random must be
-      different from the Client random, since these are randomly generated
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-      and we don't expect servers to reject Server random values which
-      coincidentally are the same as the Client random.
-    * Replaced may/should/must with MAY/SHOULD/MUST where appropriate.
-      In many cases, shoulds became MUSTs, where I believed that was the
-      actual sense of the text. Added an RFC 2119 bulletin.
-   * Clarified the meaning of "empty certificate" message. [Peter Gutmann]
-   * Redid the CertificateRequest grammar to allow no distinguished names.
-     [Peter Gutmann]
-   * Removed the reference to requiring the master secret to generate
-     the CertificateVerify in F.1.1 [Bodo Moeller]
-   * Deprecated EXPORT40.
-   * Fixed a bunch of errors in the SSLv2 backward compatible client hello.
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     - - The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     - - The connection is reliable. Message transport includes a
-       message integrity check using a keyed MAC. Secure hash functions
-       (e.g., SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     - - The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       for at least one of the peers.
-
-     - - The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     - - The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-1.1 Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-       successfully exchange cryptographic parameters without knowledge
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that TLS 1.0 and SSL 3.0 do not interoperate
-   (although TLS 1.0 does incorporate a mechanism by which a TLS
-   implementation can back down to SSL 3.0). This document is intended
-   primarily for readers who will be implementing the protocol and those
-   doing cryptographic analysis of it. The specification has been
-   written with this in mind, and it is intended to reflect the needs of
-   those two groups. For that reason, many of the algorithm-dependent
-   data structures and rules are included in the body of the text (as
-   opposed to in an appendix), providing easier access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively. A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification. Cryptographic keys
-   are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, a 36-byte structure of two hashes (one SHA and one
-   MD5) is signed (encrypted with the private key). It is encoded with
-   PKCS #1 block type 0 or type 1 as described in [PKCS1].
-
-   In DSS, the 20 bytes of the SHA hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-   HMAC can be used with a variety of different hash algorithms. TLS
-   uses it in the handshake with two different algorithms: MD5 and
-   SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   data). Additional hash algorithms can be defined by cipher suites and
-   used to protect record data, but MD5 and SHA-1 are hard coded into
-   the description of the handshaking for this version of the protocol.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In order to make the PRF as secure as possible, it uses two hash
-   algorithms in a way which should guarantee its security if either
-   algorithm remains secure.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by splitting the secret into two halves and
-   using one half to generate data with P_MD5 and the other half to
-   generate data with P_SHA-1, then exclusive-or'ing the outputs of
-   these two expansion functions together.
-
-   S1 and S2 are the two halves of the secret and each is the same
-   length. S1 is taken from the first half of the secret, S2 from the
-   second half. Their length is created by rounding up the length of the
-   overall secret divided by two; thus, if the original secret is an odd
-   number of bytes long, the last byte of S1 will be the same as the
-   first byte of S2.
-
-       L_S = length in bytes of secret;
-       L_S1 = L_S2 = ceil(L_S / 2);
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   The secret is partitioned into two halves (with the possibility of
-   one shared byte) as described above, S1 taking the first L_S1 bytes
-   and S2 the last L_S2 bytes.
-
-   The PRF is then defined as the result of mixing the two pseudorandom
-   streams by exclusive-or'ing them together.
-
-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
-                                  P_SHA-1(S2, label + seed);
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
-   byte outputs, the boundaries of their internal iterations will not be
-   aligned; to generate a 80 byte output will involve P_MD5 being
-   iterated through A(5), while P_SHA-1 will only iterate through A(4).
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.2). If a TLS
-   implementation receives a record type it does not understand, it
-   SHOULD just ignore it. Any protocol designed for use over TLS MUST be
-   carefully designed to deal with all possible attacks against it.
-   Note that because the type and length of a record are not protected
-   by encryption, care SHOULD be taken to minimize the value of traffic
-   analysis of these values.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Handshake Protocol can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block or stream cipher, the block size of
-       the cipher (if appropriate), and whether it is considered an
-       "export" cipher.
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { true, false } IsExportable;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           IsExportable           is_exportable;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-   Once the security parameters have been set and the keys have been
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever the necessary state information
-       is to allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.1, which uses the version { 3, 2 }. The
-       version value 3.2 is historical: TLS version 1.1 is a minor
-       modification to the TLS 1.0 protocol, which was itself a minor
-       modification to the SSL 3.0 protocol, which bears the version
-       value 3.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved. Application data is generally of lower precedence
-       for transmission than other content types and therefore handshake
-       records may be held if application data is pending.  However,
-       records MUST be delivered to the network in the same order as
-       they are protected by the record layer. Recipients MUST receive
-       and process interleaved application layer traffic during
-       handshakes subsequent to the first one on a connection.
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   For block ciphers (such as RC2 or DES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-       IV in order to prevent the attacks described by [CBCATT].
-       We recommend the following equivalently strong procedures.
-       For clarity we use the following notation.
-
-       IV -- the transmitted value of the IV field in the
-           GenericBlockCipher structure.
-       CBC residue -- the last ciphertext block of the previous record
-       mask -- the actual value which the cipher XORs with the
-           plaintext prior to encryption of the first cipher block
-           of the record.
-
-       In prior versions of TLS, there was no IV field and the CBC residue
-       and mask were one and the same.
-
-
-       (1) Generate a cryptographically strong random string R of
-           length CipherSpec.block_length. Place R
-           in the IV field. Set the mask to R. Thus, the first
-           cipher block will be encrypted as E(R XOR Data).
-
-       (2) Generate a cryptographically strong random number R of
-           length CipherSpec.block_length and prepend it to the plaintext
-           prior to encryption. In
-           this case either:
-
-           (a)   The cipher may use a fixed mask such as zero.
-           (b) The CBC residue from the previous record may be used
-               as the mask. This preserves maximum code compatibility
-            with TLS 1.0 and SSL 3. It also has the advantage that
-            it does not require the ability to quickly reset the IV,
-            which is known to be a   problem on some systems.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-            In either case, the data (R || data) is fed into the
-            encryption process. The first cipher block (containing
-            E(mask XOR R) is placed in the IV field. The first
-            block of content contains E(IV XOR data)
-
-       The following alternative procedure MAY be used: However, it has
-       not been demonstrated to be equivalently cryptographically strong
-       to the above procedures. The sender prepends a fixed block F to
-       the plaintext (or alternatively a block generated with a weak
-       PRNG). He then encrypts as in (2) above, using the CBC residue
-       from the previous block as the mask for the prepended block. Note
-       that in this case the mask for the first record transmitted by
-       the application (the Finished) MUST be generated using a
-       cryptographically strong PRNG.
-
-       The decryption operation for all three alternatives is the same.
-       The receiver decrypts the entire GenericBlockCipher structure and
-       then discards the first cipher block, corresponding to the IV
-       component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes long, as long as it
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes (this does not
-          include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-          equal to 6 in order to make the total length an even multiple
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
-       timing attack on CBC padding based on the time required to
-       compute the MAC. In order to defend against this attack,
-       implementations MUST ensure that record processing time is
-       essentially the same whether or not the padding is correct.  In
-       general, the best way to to do this is to compute the MAC even if
-       the padding is incorrect, and only then reject the packet. For
-       instance, if the pad appears to be incorrect the implementation
-       might assume a zero-length pad and then compute the MAC. This
-       leaves a small timing channel, since MAC performance depends to
-       some extent on the size of the data fragment, but it is not
-       believed to be large enough to be exploitable due to the large
-       block size of existing MACs and the small size of the timing
-       signal.
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, which are generated from the master secret in
-   that order. Unused values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source, and the random values provide unencrypted salt
-   material for exportable ciphers.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-
-   Implementation note:
-       The cipher spec which is defined in this document which requires
-       the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
-       keys, 2 x 20 byte MAC secrets, for a total 88 bytes of key
-       material.
-
-   Exportable encryption algorithms (for which CipherSpec.is_exportable
-   is true) require additional processing as follows to derive their
-   final write keys:
-
-       final_client_write_key =
-       PRF(SecurityParameters.client_write_key,
-                                  "client write key",
-                                  SecurityParameters.client_random +
-                                  SecurityParameters.server_random);
-       final_server_write_key =
-       PRF(SecurityParameters.server_write_key,
-                                  "server write key",
-                                  SecurityParameters.client_random +
-                                  SecurityParameters.server_random);
-
-6.3.1. Export key generation example
-
-   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
-   each of the two encryption keys and 16 bytes for each of the MAC
-   keys, for a total of 42 bytes of key material. The PRF output is
-   stored in the key_block. The key_block is partitioned, and the write
-   keys are salted because this is an exportable encryption algorithm.
-
-       key_block               = PRF(master_secret,
-                                     "key expansion",
-                                     server_random +
-                                     client_random)[0..41]
-       client_write_MAC_secret = key_block[0..15]
-       server_write_MAC_secret = key_block[16..31]
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       client_write_key        = key_block[32..36]
-       server_write_key        = key_block[37..41]
-       final_client_write_key  = PRF(client_write_key,
-                                     "client write key",
-                                     client_random +
-                                     server_random)[0..15]
-       final_server_write_key  = PRF(server_write_key,
-                                     "server write key",
-                                     client_random +
-                                     server_random)[0..15]
-
-
-7. The TLS Handshake Protocol
-
-   The TLS Handshake Protocol consists of a suite of three sub-protocols
-   which are used to allow peers to agree upon security parameters for
-   the record layer, authenticate themselves, instantiate negotiated
-   security parameters, and report error conditions to each other.
-
-   The Handshake Protocol is responsible for negotiating a session,
-   which consists of the following items:
-
-   session identifier
-       An arbitrary byte sequence chosen by the server to identify an
-       active or resumable session state.
-
-   peer certificate
-       X509v3 [X509] certificate of the peer. This element of the state
-       may be null.
-
-   compression method
-       The algorithm used to compress data prior to encryption.
-
-   cipher spec
-       Specifies the bulk data encryption algorithm (such as null, DES,
-       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
-       cryptographic attributes such as the hash_size. (See Appendix A.6
-       for formal definition)
-
-   master secret
-       48-byte secret shared between the client and server.
-
-   is resumable
-       A flag indicating whether the session can be used to initiate new
-       connections.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.9).
-
- Note: if a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g. if it has to perform a time consuming public
-   key operation). Thus, a small window of time during which the
-   recipient must buffer the data MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   NB: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also SHOULD be returned if a TLSCiphertext
-       decrypted in an invalid way: either it wasn't an even multiple of
-       the block length, or its padding values, when checked, weren't
-       correct. This message is always fatal.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   decryption_failed
-       This alert MAY be returned if a TLSCiphertext decrypted in an
-       invalid way: either it wasn't an even multiple of the block
-       length, or its padding values, when checked, weren't correct.
-       This message is always fatal.
-
-       NB: Differentiating between bad_record_mac and decryption_failed
-       alerts may permit certain attacks against CBC mode as used in TLS
-       [CBCATT]. It is preferable to uniformly use the bad_record_mac
-       alert to hide the specific type of the error.
-
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not in TLS. It should not be
-       sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction
-       A negotiation not in compliance with export restrictions was
-       detected; for example, attempting to transfer a 1024 bit
-       ephemeral RSA key for the RSA_EXPORT handshake method. This
-       message is always fatal.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     - - Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     - - Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     - - Exchange certificates and cryptographic information to allow
-       the client and server to authenticate themselves.
-
-     - - Generate a master secret from the premaster secret and
-       exchanged random values.
-
-     - - Provide security parameters to the record layer.
-
-     - - Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   However, you SHOULD never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes which are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT) according to the
-       sender's internal clock. Clocks are not required to be set
-       correctly by the basic TLS Protocol; higher level or application
-       protocols may define additional requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-       opaque SessionID<0..32>;
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-       client wishes to generate new security parameters.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-   Forward compatibility note:
-       In the interests of forward compatibility, it is permitted for a
-       client hello message to include extra data after the compression
-       methods. This data MUST be included in the handshake hashes, but
-       must otherwise be ignored. This is the only handshake message for
-       which this is legal; for all other messages, the amount of data
-       in the message MUST match the description of the message
-       precisely.
-
-Note: For the intended use of trailing data in the ClientHello, see RFC
-       3546 [TLSEXT].
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-           CompressionMethod compression_method;
-       } ServerHello;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions this field is the
-       value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will always
-       immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-       certificate. It MUST contain a key which matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       RSA_EXPORT              RSA public key of length greater than
-                               512 bits which can be used for signing,
-                               or a key of 512 bits or shorter which
-                               can be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_DSS_EXPORT          DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DHE_RSA_EXPORT          RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit MUST be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   MUST be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-   As CipherSuites which specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           RSA_EXPORT (if the public key in the server certificate is
-           longer than 512 bits)
-           DHE_DSS
-           DHE_DSS_EXPORT
-           DHE_RSA
-           DHE_RSA_EXPORT
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           RSA_EXPORT (when the public key in the server certificate is
-           less than or equal to 512 bits in length)
-           DH_DSS
-           DH_RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
- Note: According to current US export law, RSA moduli larger than 512
-       bits may not be used for key exchange in software exported from
-       the US. With this message, the larger RSA keys encoded in
-       certificates may be used to sign temporary shorter RSA keys for
-       the RSA_EXPORT key exchange method.
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-               case rsa:
-                   ServerRSAParams params;
-           };
-        } ServerParams;
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       md5_hash
-           MD5(ClientHello.random + ServerHello.random + ServerParams);
-
-       sha_hash
-           SHA(ClientHello.random + ServerHello.random + ServerParams);
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       select (SignatureAlgorithm)
-       {
-           case anonymous: struct { };
-           case rsa:
-               digitally-signed struct {
-                   opaque md5_hash[16];
-                   opaque sha_hash[20];
-               };
-           case dsa:
-               digitally-signed struct {
-                   opaque sha_hash[20];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-               };
-       } Signature;
-
-7.4.4. Certificate request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-        fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
-
- ClientCertificateType values are divided into three groups:
-
-              1. Values from 0 (zero) through 63 decimal (0x3F)
-           inclusive are
-                 reserved for IETF Standards Track protocols.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-              2. Values from 64 decimal (0x40) through 223 decimal
-           (0xDF) inclusive
-                 are reserved for assignment for non-Standards Track
-           methods.
-
-              3. Values from 224 decimal (0xE0) through 255 decimal
-           (0xFF)
-                 inclusive are reserved for private use.
-
-           Additional information describing the role of IANA in the
-           allocation of ClientCertificateType code points is described
-           in Section XXX.
-
-           Note: Values listed as RESERVED may not be used. They were
-           used in SSLv3.
-
- Note: DistinguishedName is derived from [X509].
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.5. Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message the client SHOULD
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client should send a certificate message
-       containing no certificates: I.e. the certificate_list structure
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       should have a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate must match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client key exchange message
-
-   When this message will be sent:
-       This message is always sent by the client. It will immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it will be the first message sent by the client after it receives
-       the server hello done message.
-
-   Meaning of this message:
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters which will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate which contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA encrypted premaster secret message
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate or the temporary RSA
-       key provided in a server key exchange message, and sends the
-       result in an encrypted premaster secret message. This structure
-       is a variant of the client key exchange message, not a message in
-       itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 encoded RSA. The
-       attack takes advantage of the fact that by failing in different
-       ways, a TLS server can be coerced into revealing whether a
-       particular message, when decrypted, is properly PKCS#1 formatted
-       or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
- Implementation Note: public-key-encrypted data is represented as an
-       opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted
-       PreMaster Secret in a ClientKeyExchange is preceded by two length
-       bytes. These bytes are redundant in the case of RSA because the
-       EncryptedPreMasterSecret is the only data in the
-       ClientKeyExchange and its length can therefore be unambiguously
-       determined. The SSLv3 specification was not clear about the
-       encoding of public-key-encrypted data and therefore many SSLv3
-       implementations do not include the the length bytes, encoding the
-       RSA encrypted data directly in the ClientKeyExchange message.
-
-       This specification requires correct encoding of the
-       EncryptedPreMasterSecret complete with length bytes. The
-       resulting PDU is incompatible with many SSLv3 implementations.
-       Implementors upgrading from SSLv3 must modify their
-       implementations to generate and accept the correct encoding.
-       Implementors who wish to be compatible with both SSLv3 and TLS
-       should make their implementation's behavior dependent on the
-       protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-       on SSL are possible, at least when the client and server are on
-       the same LAN. Accordingly, implementations which use static RSA
-       keys SHOULD use RSA blinding or some other anti-timing technique,
-       as described in [TIMING].
-
- Note: The version number in the PreMasterSecret is that offered by the
-       client, NOT the version negotiated for the connection. This
-       feature is designed to prevent rollback attacks. Unfortunately,
-       many implementations use the negotiated version instead and
-       therefore checking the version number may lead to failure to
-       interoperate with such incorrect client implementations. Client
-       implementations MUST and Server implementations MAY check the
-       version number. In practice, since there are no significant known
-       security differences between TLS and SSLv3, rollback to SSLv3 is
-       not believed to be a serious security risk.  Note that if servers
-       choose to to check the version number, they should randomize the
-       PreMasterSecret in case of error, rather than generate an alert,
-       in order to avoid variants on the Bleichenbacher attack. [KPR03]
-
-7.4.7.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the Client Key Exchange message will be
-           sent, but will be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it will immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-       CertificateVerify.signature.md5_hash
-           MD5(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, MD5(handshake_messages) +
-           SHA-1(handshake_messages)) [0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-       handshake_messages
-           All of the data from all handshake messages up to but not
-           including this message. This is only data visible at the
-           handshake layer and does not include record layer headers.
-           This is the concatenation of all the Handshake structures as
-           defined in 7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading 0 bytes of Z are
-   stripped before it is used as the pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-   The 40-bit cipher suites are known to be susceptible to exhaustive
-   search attack by commercial attackers. Implementations of this
-   document SHOULD disable them by default if they are supported at all.
-   A future version of this document may remove them entirely.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-10. IANA Considerations
-
-   Section 7.4.3 describes a registry of ClientCertificateType code
-   points to be maintained by the IANA, as defining a number of such
-   code point identifiers. ClientCertificateType identifiers with values
-   in the range 0-63 (decimal) inclusive are assigned via RFC 2434
-   Standards Action. Values from the range 64-223 (decimal)  inclusive
-   are assigned via RFC 2434 Specification Required.  Identifier values
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   from 224-255 (decimal) inclusive are reserved for RFC 2434 Private
-   Use.
-
-   Section A.5 describes a registry of cipher suite identifiers to be
-   maintained by the IANA, as well as defining a number of such cipher
-   suite identifiers. Cipher suite values with the first byte in the
-   range 0-191 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action. Values with the first byte in the range 192-254 (decimal) are
-   assigned via RFC 2434 Specification Required. Values with the first
-   byte 255 (decimal) are reserved for RFC 2434 Private Use.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-         no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque RSA_modulus<1..2^16-1>;
-        opaque RSA_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque DH_p<1..2^16-1>;
-        opaque DH_g<1..2^16-1>;
-        opaque DH_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-            case rsa:
-                ServerRSAParams params;
-        };
-     } ServerParams;
-
-    select (SignatureAlgorithm)
-    {   case anonymous: struct { };
-        case rsa:
-            digitally-signed struct {
-                opaque md5_hash[16];
-                opaque sha_hash[20];
-            };
-        case dsa:
-            digitally-signed struct {
-                opaque sha_hash[20];
-            };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: DiffieHellmanClientPublicValue;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks and is
-   therefore deprecated.
-
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
- The cipher suite space is divided into three regions:
-
-       1. Cipher suite values with first byte 0x00 (zero)
-          through decimal 191 (0xBF) inclusive are reserved for the IETF
-          Standards Track protocols.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       2. Cipher suite values with first byte decimal 192 (0xC0)
-          through decimal 254 (0xFE) inclusive are reserved
-          for assignment for non-Standards Track methods.
-
-       3. Cipher suite values with first byte 0xFF are
-          reserved for private use.
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section XXX.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { true, false } IsExportable;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           IsExportable is_exportable;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-B. Glossary
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher licensed by RSA Data Security [RSADSI]. A
-       compatible cipher is described in [RC4].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   salt
-       Non-secret random data used to make export encryption keys resist
-       precomputation attacks.
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-C. CipherSuite definitions
-
-CipherSuite                      Is       Key          Cipher      Hash
-                             Exportable Exchange
-
-TLS_NULL_WITH_NULL_NULL               * NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA
-TLS_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-
-
-   * Indicates IsExportable is True
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_DSS_EXPORT  Ephemeral DH with DSS signatures   DH = 512 bits
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DHE_RSA_EXPORT  Ephemeral DH with RSA signatures   DH = 512 bits,
-                                                         RSA = none
-      DH_anon         Anonymous DH, no signatures        None
-      DH_anon_EXPORT  Anonymous DH, no signatures        DH = 512 bits
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-      DH_DSS          DH with DSS-based certificates     None
-      DH_DSS_EXPORT   DH with DSS-based certificates     DH = 512 bits
-      DH_RSA          DH with RSA-based certificates     None
-      DH_RSA_EXPORT   DH with RSA-based certificates     DH = 512 bits,
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-      RSA_EXPORT      RSA key exchange                   RSA = 512 bits
-
-   Key size limit
-       The key size limit gives the size of the largest public key that
-       can be legally used for encryption or key agreement in
-       cipher suites that are exportable.
-
-                         Key      Expanded   Effective   IV    Block
-    Cipher       Type  Material Key Material  Key Bits  Size   Size
-
-    NULL       * Stream   0          0           0        0     N/A
-    IDEA_CBC     Block   16         16         128        8      8
-    RC2_CBC_40 * Block    5         16          40        8      8
-    RC4_40     * Stream   5         16          40        0     N/A
-    RC4_128      Stream  16         16         128        0     N/A
-    DES40_CBC  * Block    5          8          40        8      8
-    DES_CBC      Block    8          8          56        8      8
-    3DES_EDE_CBC Block   24         24         168        8      8
-
-   * Indicates IsExportable is true.
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   Effective Key Bits
-       How much entropy material is in the key material being fed into
-       the encryption routines.
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1. Temporary RSA keys
-
-   US Export restrictions limit RSA keys used for encryption to 512
-   bits, but do not place any limit on lengths of RSA keys used for
-   signing operations. Certificates often need to be larger than 512
-   bits, since 512-bit RSA keys are not secure enough for high-value
-   transactions or for applications requiring long-term security. Some
-   certificates are also designated signing-only, in which case they
-   cannot be used for key exchange.
-
-   When the public key in the certificate cannot be used for encryption,
-   the server signs a temporary RSA key, which is then exchanged. In
-   exportable applications, the temporary RSA key should be the maximum
-   allowable length (i.e., 512 bits). Because 512-bit RSA keys are
-   relatively insecure, they should be changed often. For typical
-   electronic commerce applications, it is suggested that keys be
-   changed daily or every 500 transactions, and more often if possible.
-   Note that while it is acceptable to use the same temporary key for
-   multiple transactions, it must be signed each time it is used.
-
-   RSA key generation is a time-consuming process. In many cases, a low-
-   priority process can be assigned the task of key generation.
-
-   Whenever a new key is completed, the existing temporary key can be
-   replaced with the new one.
-
-D.2. Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-D.3. Certificates and authentication
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.4. CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-the-
-   middle attacks. Applications should also enforce minimum and maximum
-   key sizes. For example, certificate chains containing 512-bit RSA
-   keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-E. Backward Compatibility With SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port: for example, the https protocol (HTTP secured by SSL
-   or TLS) uses port 443 regardless of which security protocol it is
-   using. Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting
-   both is easy. TLS clients who wish to negotiate with such older
-   servers SHOULD send client hello messages using the SSL 3.0 record
-   format and client hello structure, sending {3, 2} for the version
-   field to note that they support TLS 1.1. If the server supports only
-   TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;
-   if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
-   The negotiation then proceeds as appropriate for the negotiated
-   protocol.
-
-   Similarly, a TLS 1.1  server which wishes to interoperate with TLS
-   1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages
-   and respond with a SSL 3.0 server hello if an SSL 3.0 client hello
-   with a version field of {3, 0} is received, denoting that this client
-   does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
-   version field of {3, 1} is received, the server SHOULD respond with a
-   TLS 1.0 hello with a version field of {3, 1}.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors SHOULD make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification. Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       This field is the length of the following data in bytes. The high
-       bit MUST be 1 and is not part of the length.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-       version 2 client hello message. The value SHOULD be one (1).
-
-   version
-       The highest version of the protocol supported by the client
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. When using the SSLv2 backward compatible
-       handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There MUST be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       This field MUST be empty.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   from the server key exchange message. The result is sent in a client
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate. The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed. Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key. TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites. The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly so the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Parties
-   concerned about attacks of this scale should not be using 40-bit
-   encryption keys anyway. Altering the padding of the least-significant
-   8 bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses. Because many implementations will support 40-bit
-   exportable encryption and some may even support null encryption or
-   MAC algorithms, this attack is of particular concern.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5. MD5 and SHA
-
-   TLS uses hash functions very conservatively. Where possible, both MD5
-   and SHA are used in tandem to ensure that non-catastrophic flaws in
-   one algorithm will not break the overall protocol.
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-F.4 Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information theoretic sense) that combined with any secure MAC
-       function fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message plus the length of the MAC tag is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent and unpredictable, IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext. This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-F.5 Denial of Service
-
-       TLS is susceptible to a number of denial of service (DoS)
-       attacks.  In particular, an attacker who initiates a large number
-       of TCP connections can cause a server to consume large amounts of
-       CPU doing RSA decryption. However, because TLS is generally used
-       over TCP, it is difficult for the attacker to hide his point of
-       origin if proper TCP SYN randomization is used [SEQNUM] by the
-       TCP stack.
-
-       Because TLS runs over TCP, it is also susceptible to a number of
-       denial of service attacks on individual connections. In
-       particular, attackers can forge RSTs, terminating connections, or
-       forge partial TLS records, causing the connection to stall.
-       These attacks cannot in general be defended against by a TCP-
-       using protocol. Implementors or users who are concerned with this
-       class of attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-G. Patent Statement
-
-   Netscape Communications Corporation (now America Online) has a patent
-   claim on the Secure Sockets Layer (SSL) work that this standard is
-   based on. The Internet Standards Process as defined in RFC 2026
-   requests that a statement be obtained from a Patent holder indicating
-   that a license will be made available to applicants under reasonable
-   terms and conditions.
-
-       Secure Socket Layer Application Program Apparatus And Method
-       ("SSL"), No. 5,657,390
-
-   Netscape Communications has issued the following statement:
-
-       Intellectual Property Rights
-
-       Secure Sockets Layer
-
-       The United States Patent and Trademark Office ("the PTO")
-       recently issued U.S. Patent No. 5,657,390 ("the SSL Patent")  to
-       Netscape for inventions described as Secure Sockets Layers
-       ("SSL"). The IETF is currently considering adopting SSL as a
-       transport protocol with security features.  Netscape encourages
-       the royalty-free adoption and use of the SSL protocol upon the
-       following terms and conditions:
-
-         * If you already have a valid SSL Ref license today which
-           includes source code from Netscape, an additional patent
-           license under the SSL patent is not required.
-
-         * If you don't have an SSL Ref license, you may have a royalty
-           free license to build implementations covered by the SSL
-           Patent Claims or the IETF TLS specification provided that you
-           do not to assert any patent rights against Netscape or other
-           companies for the implementation of SSL or the IETF TLS
-           recommendation.
-
-       What are "Patent Claims":
-
-       Patent claims are claims in an issued foreign or domestic patent
-       that:
-
-        1) must be infringed in order to implement methods or build
-           products according to the IETF TLS specification;  or
-
-        2) patent claims which require the elements of the SSL patent
-           claims and/or their equivalents to be infringed.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   The Internet Society, Internet Architecture Board, Internet
-   Engineering Steering Group and the Corporation for National Research
-   Initiatives take no position on the validity or scope of the patents
-   and patent applications, nor on the appropriateness of the terms of
-   the assurance. The Internet Society and other groups mentioned above
-   have not made any determination as to any other intellectual property
-   rights which may apply to the practice of this standard.  Any further
-   consideration of these matters is the user's own responsibility.
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-Normative References
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DH1]    W. Diffie and M. E. Hellman, "New Directions in
-            Cryptography," IEEE Transactions on Information Theory, V.
-            IT-22, n. 6, Jun 1977, pp. 74-84.
-
-   [DSS]    NIST FIPS PUB 186, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, May 18, 1994.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
-            April 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1]  RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
-            version 1.5, November 1993.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 2459, January 1999.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [RC4]    Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
-            Algorithm, Work in Progress.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SHA]    NIST FIPS PUB 180-1, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, Work in Progress, May 31, 1994.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.
-   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication
-            Framework". 1988.
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-Informative References
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            2402, November 1998.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 2406, November 1998.
-
-   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
-            RFC 959, October 1985.
-
-   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
-            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-   [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782
-
-   [SCH]    B. Schneier. Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, Published by John Wiley & Sons, Inc.
-            1994.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
-            Data Representation Standard, August 1995.
-
-
-Credits
-
-   Working Group Chairs
-   Win Treese
-   EMail: treese@acm.org
-
-   Eric Rescorla
-   EMail: ekr@rtfm.com
-
-
-   Editors
-
-   Tim Dierks                Eric Rescorla
-   Independent                   RTFM, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@rtfm.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   Structured Arts
-
-   Kipp Hickman
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <ietf-tls@lists.consensus.com>. Information on the
-   group and information on how to subscribe to the list is at
-   <http://lists.consensus.com/>.
-
-   Archives of the list can be found at:
-       <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]draft-ietf-tls-rfc2246-bis-08.txt  TLS                       August 2004
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 92]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc2246-bis-09.txt b/doc/protocol/draft-ietf-tls-rfc2246-bis-09.txt
deleted file mode 100644
index 2a802d6f02..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc2246-bis-09.txt
+++ /dev/null
@@ -1,4807 +0,0 @@
-
-
-                                                              Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                                RTFM, Inc.
-<draft-ietf-tls-rfc2246-bis-09.txt>    December 2004 (Expires June 2005)
-
-                            The TLS Protocol
-                              Version 1.1
-
-Status of this Memo
-
-By submitting this Internet-Draft, I certify that any applicable
-patent or other IPR claims of which I am aware have been disclosed,
-and any of which I become aware will be disclosed, in accordance with
-RFC 3668.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-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 a "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999-2004).  All Rights Reserved.
-
-Abstract
-
-   This document specifies Version 1.1 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction
-   3 1.1       Requirements Terminology
-   4 2.        Goals
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   4 3.        Goals of this document
-   5 4.        Presentation language
-   5 4.1.      Basic block size
-   6 4.2.      Miscellaneous
-   6 4.3.      Vectors
-   6 4.4.      Numbers
-   7 4.5.      Enumerateds
-   7 4.6.      Constructed types
-   8 4.6.1.    Variants
-   9 4.7.      Cryptographic attributes
-   10 4.8.      Constants
-   11 5.        HMAC and the pseudorandom function
-   11 6.        The TLS Record Protocol
-   13 6.1.      Connection states
-   14 6.2.      Record layer
-   16 6.2.1.    Fragmentation
-   16 6.2.2.    Record compression and decompression
-   18 6.2.3.    Record payload protection
-   18 6.2.3.1.  Null or standard stream cipher
-   19 6.2.3.2.  CBC block cipher
-   20 6.3.      Key calculation
-   22 6.3.1.    Export key generation example
-   23 7.        The TLS Handshaking Protocols
-   24 7.1.      Change cipher spec protocol
-   25 7.2.      Alert protocol
-   25 7.2.1.    Closure alerts
-   26 7.2.2.    Error alerts
-   27 7.3.      Handshake Protocol overview
-   30 7.4.      Handshake protocol
-   34 7.4.1.    Hello messages
-   35 7.4.1.1.  Hello request
-   35 7.4.1.2.  Client hello
-   36 7.4.1.3.  Server hello
-   38 7.4.2.    Server certificate
-   39 7.4.3.    Server key exchange message
-   42 7.4.4.    Certificate request
-   45 7.4.5.    Server hello done
-   46 7.4.6.    Client certificate
-   46 7.4.7.    Client key exchange message
-   47 7.4.7.1.  RSA encrypted premaster secret message
-   47 7.4.7.2.  Client Diffie-Hellman public value
-   49 7.4.8.    Certificate verify
-   50 7.4.9.    Finished
-   51 8.        Cryptographic computations
-   52 8.1.      Computing the master secret
-   52 8.1.1.    RSA
-   53 8.1.2.    Diffie-Hellman
-   53 9.        Mandatory Cipher Suites
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   53 A.        Protocol constant values
-   55 A.1.      Record layer
-   55 A.2.      Change cipher specs message
-   56 A.3.      Alert messages
-   56 A.4.      Handshake protocol
-   57 A.4.1.    Hello messages
-   57 A.4.2.    Server authentication and key exchange messages
-   58 A.4.3.    Client authentication and key exchange messages
-   59 A.4.4.    Handshake finalization message
-   60 A.5.      The CipherSuite
-   60 A.6.      The Security Parameters
-   63 B.        Glossary
-   64 C.        CipherSuite definitions
-   68 D.        Implementation Notes
-   71 D.1.      Temporary RSA keys
-   71 D.2.      Random Number Generation and Seeding
-   71 D.3.      Certificates and authentication
-   72 D.4.      CipherSuites
-   72 E.        Backward Compatibility With SSL
-   73 E.1.      Version 2 client hello
-   74 E.2.      Avoiding man-in-the-middle version rollback
-   75 F.        Security analysis
-   77 F.1.      Handshake protocol
-   77 F.1.1.    Authentication and key exchange
-   77 F.1.1.1.  Anonymous key exchange
-   77 F.1.1.2.  RSA key exchange and authentication
-   78 F.1.1.3.  Diffie-Hellman key exchange with authentication
-   79 F.1.2.    Version rollback attacks
-   79 F.1.3.    Detecting attacks against the handshake protocol
-   80 F.1.4.    Resuming sessions
-   80 F.1.5.    MD5 and SHA
-   81 F.2.      Protecting application data
-   81 F.3.      Explicit IVs
-   81 F.4       Security of Composite Cipher Modes
-   82 F.5       Denial of Service
-   83 F.6.      Final notes
-   83
-
-
-Change history
-
-   03-Dec-04 ekr@rtfm.com
-    * Removed export cipher suites
-
-   26-Oct-04 ekr@rtfm.com
-    * Numerous cleanups from Last Call comments
-
-   10-Aug-04 ekr@rtfm.com
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-    * Added clarifying material about interleaved application data.
-
-   27-Jul-04 ekr@rtfm.com
-    * Premature closes no longer cause a session to be nonresumable.
-      Response to WG consensus.
-
-    * Added IANA considerations and registry for cipher suites
-      and ClientCertificateTypes
-
-   26-Jun-03 ekr@rtfm.com
-    * Incorporated Last Call comments from Franke Marcus, Jack Lloyd,
-    Brad Wetmore, and others.
-
-   22-Apr-03 ekr@rtfm.com
-    * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks
-    * cleaned up IV text a bit.
-    * Added discussion of Denial of Service attacks.
-
-   11-Feb-02 ekr@rtfm.com
-    * Clarified the behavior of empty certificate lists [Nelson Bolyard]
-    * Added text explaining the security implications of authenticate
-      then encrypt.
-    * Cleaned up the explicit IV text.
-    * Added some more acknowledgement names
-
-   02-Nov-02 ekr@rtfm.com
-    * Changed this to be TLS 1.1.
-    * Added fixes for the Rogaway and Vaudenay CBC attacks
-    * Separated references into normative and informative
-
-   01-Mar-02 ekr@rtfm.com
-    * Tightened up the language in F.1.1.2 [Peter Watkins]
-    * Fixed smart quotes [Bodo Moeller]
-    * Changed handling of padding errors to prevent CBC-based attack
-      [Bodo Moeller]
-    * Fixed certificate_list spec in the appendix [Aman Sawrup]
-    * Fixed a bug in the V2 definitions [Aman Sawrup]
-    * Fixed S 7.2.1 to point out that you don't need a close notify
-      if you just sent some other fatal alert [Andreas Sterbenz]
-    * Marked alert 41 reserved [Andreas Sterbenz]
-    * Changed S 7.4.2 to point out that 512-bit keys cannot be used for
-      signing [Andreas Sterbenz]
-    * Added reserved client key types from SSLv3 [Andreas Sterbenz]
-    * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz]
-    * Removed RSA patent statement [Andreas Sterbenz]
-    * Removed references to BSAFE and RSAREF [Andreas Sterbenz]
-
-   14-Feb-02 ekr@rtfm.com
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-    * Re-converted to I-D from RFC
-    * Made RSA/3DES the mandatory cipher suite.
-    * Added discussion of the EncryptedPMS encoding and PMS version number
-      issues to 7.4.7.1
-    * Removed the requirement in 7.4.1.3 that the Server random must be
-      different from the Client random, since these are randomly generated
-      and we don't expect servers to reject Server random values which
-      coincidentally are the same as the Client random.
-    * Replaced may/should/must with MAY/SHOULD/MUST where appropriate.
-      In many cases, shoulds became MUSTs, where I believed that was the
-      actual sense of the text. Added an RFC 2119 bulletin.
-   * Clarified the meaning of "empty certificate" message. [Peter Gutmann]
-   * Redid the CertificateRequest grammar to allow no distinguished names.
-     [Peter Gutmann]
-   * Removed the reference to requiring the master secret to generate
-     the CertificateVerify in F.1.1 [Bodo Moeller]
-   * Deprecated EXPORT40.
-   * Fixed a bunch of errors in the SSLv2 backward compatible client hello.
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [RC4], etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-1.1 Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-       successfully exchange cryptographic parameters without knowledge
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that TLS 1.1, TLS 1.0,  and SSL 3.0 do not
-   interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down prior versions. This document
-   is intended primarily for readers who will be implementing the
-   protocol and those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively. A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification. Cryptographic keys
-   are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, a 36-byte structure of two hashes (one SHA and one
-   MD5) is signed (encrypted with the private key). It is encoded with
-   PKCS #1 block type 0 or type 1 as described in [PKCS1].
-
-   In DSS, the 20 bytes of the SHA hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-   HMAC can be used with a variety of different hash algorithms. TLS
-   uses it in the handshake with two different algorithms: MD5 and
-   SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   data). Additional hash algorithms can be defined by cipher suites and
-   used to protect record data, but MD5 and SHA-1 are hard coded into
-   the description of the handshaking for this version of the protocol.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In order to make the PRF as secure as possible, it uses two hash
-   algorithms in a way which should guarantee its security if either
-   algorithm remains secure.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by splitting the secret into two halves and
-   using one half to generate data with P_MD5 and the other half to
-   generate data with P_SHA-1, then exclusive-or'ing the outputs of
-   these two expansion functions together.
-
-   S1 and S2 are the two halves of the secret and each is the same
-   length. S1 is taken from the first half of the secret, S2 from the
-   second half. Their length is created by rounding up the length of the
-   overall secret divided by two; thus, if the original secret is an odd
-   number of bytes long, the last byte of S1 will be the same as the
-   first byte of S2.
-
-       L_S = length in bytes of secret;
-       L_S1 = L_S2 = ceil(L_S / 2);
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   The secret is partitioned into two halves (with the possibility of
-   one shared byte) as described above, S1 taking the first L_S1 bytes
-   and S2 the last L_S2 bytes.
-
-   The PRF is then defined as the result of mixing the two pseudorandom
-   streams by exclusive-or'ing them together.
-
-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
-                                  P_SHA-1(S2, label + seed);
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
-   byte outputs, the boundaries of their internal iterations will not be
-   aligned; to generate a 80 byte output will involve P_MD5 being
-   iterated through A(5), while P_SHA-1 will only iterate through A(4).
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.1). All such
-   values must be defined by RFC 2434 Standards Action.  Section 11 for
-   IANA Considerations for ContentType values.
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it. Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block or stream cipher, the block size of
-       the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever the necessary state information
-       is to allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.1, which uses the version { 3, 2 }. The
-       version value 3.2 is historical: TLS version 1.1 is a minor
-       modification to the TLS 1.0 protocol, which was itself a minor
-       modification to the SSL 3.0 protocol, which bears the version
-       value 3.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved. Application data is generally of higher precedence
-       for transmission than other content types and therefore handshake
-       records may be held if application data is pending.  However,
-       records MUST be delivered to the network in the same order as
-       they are protected by the record layer. Recipients MUST receive
-       and process interleaved application layer traffic during
-       handshakes subsequent to the first one on a connection.
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-   For block ciphers (such as RC2 or DES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-       IV in order to prevent the attacks described by [CBCATT].
-       We recommend the following equivalently strong procedures.
-       For clarity we use the following notation.
-
-       IV -- the transmitted value of the IV field in the
-           GenericBlockCipher structure.
-       CBC residue -- the last ciphertext block of the previous record
-       mask -- the actual value which the cipher XORs with the
-           plaintext prior to encryption of the first cipher block
-           of the record.
-
-       In prior versions of TLS, there was no IV field and the CBC residue
-       and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
-       of [TLS1.0] for details of TLS 1.0 IV handling.
-
-       One of the following two algorithms SHOULD be used to generate the
-       per-record IV:
-
-       (1) Generate a cryptographically strong random string R of
-           length CipherSpec.block_length. Place R
-           in the IV field. Set the mask to R. Thus, the first
-           cipher block will be encrypted as E(R XOR Data).
-
-       (2) Generate a cryptographically strong random number R of
-           length CipherSpec.block_length and prepend it to the plaintext
-           prior to encryption. In
-           this case either:
-
-           (a)   The cipher may use a fixed mask such as zero.
-           (b) The CBC residue from the previous record may be used
-               as the mask. This preserves maximum code compatibility
-            with TLS 1.0 and SSL 3. It also has the advantage that
-            it does not require the ability to quickly reset the IV,
-            which is known to be a   problem on some systems.
-
-            In either case, the data (R || data) is fed into the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-            encryption process. The first cipher block (containing
-            E(mask XOR R) is placed in the IV field. The first
-            block of content contains E(IV XOR data)
-
-       The following alternative procedure MAY be used: However, it has
-       not been demonstrated to be equivalently cryptographically strong
-       to the above procedures. The sender prepends a fixed block F to
-       the plaintext (or alternatively a block generated with a weak
-       PRNG). He then encrypts as in (2) above, using the CBC residue
-       from the previous block as the mask for the prepended block. Note
-       that in this case the mask for the first record transmitted by
-       the application (the Finished) MUST be generated using a
-       cryptographically strong PRNG.
-
-       The decryption operation for all three alternatives is the same.
-       The receiver decrypts the entire GenericBlockCipher structure and
-       then discards the first cipher block, corresponding to the IV
-       component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes long, as long as it
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes (this does not
-          include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
-       timing attack on CBC padding based on the time required to
-       compute the MAC. In order to defend against this attack,
-       implementations MUST ensure that record processing time is
-       essentially the same whether or not the padding is correct.  In
-       general, the best way to to do this is to compute the MAC even if
-       the padding is incorrect, and only then reject the packet. For
-       instance, if the pad appears to be incorrect the implementation
-       might assume a zero-length pad and then compute the MAC. This
-       leaves a small timing channel, since MAC performance depends to
-       some extent on the size of the data fragment, but it is not
-       believed to be large enough to be exploitable due to the large
-       block size of existing MACs and the small size of the timing
-       signal.
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, which are generated from the master secret in
-   that order. Unused values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-
-   Implementation note:
-       The currently defined which requires the most material is
-       AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
-       keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key
-       material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols which are used to allow peers to agree
-       upon security parameters for the record layer, authenticate
-       themselves, instantiate negotiated security parameters, and
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-       An arbitrary byte sequence chosen by the server to identify an
-       active or resumable session state.
-
-   peer certificate
-       X509v3 [X509] certificate of the peer. This element of the state
-       may be null.
-
-   compression method
-       The algorithm used to compress data prior to encryption.
-
-   cipher spec
-       Specifies the bulk data encryption algorithm (such as null, DES,
-       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
-       cryptographic attributes such as the hash_size. (See Appendix A.6
-       for formal definition)
-
-   master secret
-       48-byte secret shared between the client and server.
-
-   is resumable
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       A flag indicating whether the session can be used to initiate new
-       connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.9).
-
- Note: if a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g. if it has to perform a time consuming public
-   key operation). Thus, a small window of time during which the
-   recipient must buffer the data MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   NB: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also MUST be returned if an alert is sent because
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed
-       This alert MAY be returned if a TLSCiphertext decrypted in an
-       invalid way: either it wasn't an even multiple of the block
-       length, or its padding values, when checked, weren't correct.
-       This message is always fatal.
-
-       NB: Differentiating between bad_record_mac and decryption_failed
-       alerts may permit certain attacks against CBC mode as used in TLS
-       [CBCATT]. It is preferable to uniformly use the bad_record_mac
-       alert to hide the specific type of the error.
-
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not in TLS. It should not be
-       sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in TLS 1.0 but not TLS 1.1.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New alerts values MUST be defined by RFC 2434 Standards Action. See
-   Section 11 for IANA Considerations for alert values.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   However, you SHOULD never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message type values MUST be defined via RFC 2434
-   Standards Action. See Section 11 for IANA Considerations for these
-   values.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
- Note: This message MUST NOT be included in the message hashes which are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT) according to the
-       sender's internal clock. Clocks are not required to be set
-       correctly by the basic TLS Protocol; higher level or application
-       protocols may define additional requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-   Forward compatibility note:
-       In the interests of forward compatibility, it is permitted for a
-       client hello message to include extra data after the compression
-       methods. This data MUST be included in the handshake hashes, but
-       must otherwise be ignored. This is the only handshake message for
-       which this is legal; for all other messages, the amount of data
-       in the message MUST match the description of the message
-       precisely.
-
-Note: For the intended use of trailing data in the ClientHello, see RFC
-       3546 [TLSEXT].
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-           CompressionMethod compression_method;
-       } ServerHello;
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions this field is the
-       value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will always
-       immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       certificate. It MUST contain a key which matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit MUST be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   MUST be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-   As CipherSuites which specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-               case rsa:
-                   ServerRSAParams params;
-           };
-        } ServerParams;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       md5_hash
-           MD5(ClientHello.random + ServerHello.random + ServerParams);
-
-       sha_hash
-           SHA(ClientHello.random + ServerHello.random + ServerParams);
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       select (SignatureAlgorithm)
-       {
-           case anonymous: struct { };
-           case rsa:
-               digitally-signed struct {
-                   opaque md5_hash[16];
-                   opaque sha_hash[20];
-               };
-           case dsa:
-               digitally-signed struct {
-                   opaque sha_hash[20];
-               };
-       } Signature;
-
-7.4.4. Certificate request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-        fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
-
- ClientCertificateType values are divided into three groups:
-
-              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-                 reserved for IETF Standards Track protocols.
-
-              2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
-                 are reserved for assignment for non-Standards Track methods.
-
-              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-                 inclusive are reserved for private use.
-
-           Additional information describing the role of IANA in the
-           allocation of ClientCertificateType code points is described
-           in Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were used in SSLv3.
-
- Note: DistinguishedName is derived from [X509]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.5. Server hello done
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message the client SHOULD
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client should send a certificate message
-       containing no certificates: I.e. the certificate_list structure
-       should have a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate must match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client key exchange message
-
-   When this message will be sent:
-       This message is always sent by the client. It will immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it will be the first message sent by the client after it receives
-       the server hello done message.
-
-   Meaning of this message:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters which will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate which contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA encrypted premaster secret message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate or the temporary RSA
-       key provided in a server key exchange message, and sends the
-       result in an encrypted premaster secret message. This structure
-       is a variant of the client key exchange message, not a message in
-       itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 encoded RSA. The
-       attack takes advantage of the fact that by failing in different
-       ways, a TLS server can be coerced into revealing whether a
-       particular message, when decrypted, is properly PKCS#1 formatted
-       or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
- Implementation Note: public-key-encrypted data is represented as an
-       opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted
-       PreMaster Secret in a ClientKeyExchange is preceded by two length
-       bytes. These bytes are redundant in the case of RSA because the
-       EncryptedPreMasterSecret is the only data in the
-       ClientKeyExchange and its length can therefore be unambiguously
-       determined. The SSLv3 specification was not clear about the
-       encoding of public-key-encrypted data and therefore many SSLv3
-       implementations do not include the the length bytes, encoding the
-       RSA encrypted data directly in the ClientKeyExchange message.
-
-       This specification requires correct encoding of the
-       EncryptedPreMasterSecret complete with length bytes. The
-       resulting PDU is incompatible with many SSLv3 implementations.
-       Implementors upgrading from SSLv3 must modify their
-       implementations to generate and accept the correct encoding.
-       Implementors who wish to be compatible with both SSLv3 and TLS
-       should make their implementation's behavior dependent on the
-       protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-       on SSL are possible, at least when the client and server are on
-       the same LAN. Accordingly, implementations which use static RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       keys SHOULD use RSA blinding or some other anti-timing technique,
-       as described in [TIMING].
-
- Note: The version number in the PreMasterSecret is that offered by the
-       client, NOT the version negotiated for the connection. This
-       feature is designed to prevent rollback attacks. Unfortunately,
-       many implementations use the negotiated version instead and
-       therefore checking the version number may lead to failure to
-       interoperate with such incorrect client implementations. Client
-       implementations MUST and Server implementations MAY check the
-       version number. In practice, since there are no significant known
-       security differences between TLS and SSLv3, rollback to SSLv3 is
-       not believed to be a serious security risk.  Note that if servers
-       choose to to check the version number, they should randomize the
-       PreMasterSecret in case of error, rather than generate an alert,
-       in order to avoid variants on the Bleichenbacher attack. [KPR03]
-
-7.4.7.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the Client Key Exchange message will be
-           sent, but will be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it will immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-       CertificateVerify.signature.md5_hash
-           MD5(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       verify_data
-           PRF(master_secret, finished_label, MD5(handshake_messages) +
-           SHA-1(handshake_messages)) [0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading 0 bytes of Z are
-   stripped before it is used as the pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-10. IANA Considerations
-
-   Section 7.4.3 describes a TLS ClientCertificateType Registry to be
-   maintained by the IANA, as defining a number of such code point
-   identifiers. ClientCertificateType identifiers with values in the
-   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action. Values from the range 64-223 (decimal) inclusive are assigned
-   via [RFC 2434] Specification Required.  Identifier values from
-   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
-   The registry will be initially populated with the values in this
-   document.
-
-   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   the IANA, as well as defining a number of such cipher suite
-   identifiers. Cipher suite values with the first byte in the range
-   0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
-   Values with the first byte in the range 192-254 (decimal) are
-   assigned via RFC 2434 Specification Required. Values with the first
-   byte 255 (decimal) are reserved for RFC 2434 Private Use. The
-   registry will be initially populated with the values from this
-   document, [TLSAES], and [TLSKRB].
-
-   Section 6 requires that all ContentType values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS ContentType registry,
-   initially populated with values from this document. Future values
-   MUST be allocated via Standards Action as described in [RFC 2434].
-
-   Section 7.2.2 requires that all Alert values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS Alert registry, initially
-   populated with values from this document and [TLSEXT]. Future values
-   MUST be allocated via Standards Action as described in [RFC 2434].
-
-   Section 7.4 requires that all HandshakeType values be defined by RFC
-   2434 Standards Action. IANA SHOULD create a TLS HandshakeType
-   registry, initially populated with values from this document,
-   [TLSEXT], and [TLSKRB].  Future values MUST be allocated via
-   Standards Action as described in [RFC 2434].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque RSA_modulus<1..2^16-1>;
-        opaque RSA_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque DH_p<1..2^16-1>;
-        opaque DH_g<1..2^16-1>;
-        opaque DH_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-            case rsa:
-                ServerRSAParams params;
-        };
-     } ServerParams;
-
-    select (SignatureAlgorithm)
-    {   case anonymous: struct { };
-        case rsa:
-            digitally-signed struct {
-                opaque md5_hash[16];
-                opaque sha_hash[20];
-            };
-        case dsa:
-            digitally-signed struct {
-                opaque sha_hash[20];
-            };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: DiffieHellmanClientPublicValue;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks and is
-   therefore deprecated.
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.1 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.1 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.1 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.1 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-   The following cipher suites were defined in [TLSAES] and are included
-   here for completeness. See [TLSAES] for details:
-
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
-
- The cipher suite space is divided into three regions:
-
-       1. Cipher suite values with first byte 0x00 (zero)
-          through decimal 191 (0xBF) inclusive are reserved for the IETF
-          Standards Track protocols.
-
-       2. Cipher suite values with first byte decimal 192 (0xC0)
-          through decimal 254 (0xFE) inclusive are reserved
-          for assignment for non-Standards Track methods.
-
-       3. Cipher suite values with first byte 0xFF are
-          reserved for private use.
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section 11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-B. Glossary
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [RC4].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-C. CipherSuite definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-the-
-   middle attacks. Applications should also enforce minimum and maximum
-   key sizes. For example, certificate chains containing 512-bit RSA
-   keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-E. Backward Compatibility With SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port: for example, the https protocol (HTTP secured by SSL
-   or TLS) uses port 443 regardless of which security protocol it is
-   using. Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting
-   both is easy. TLS clients who wish to negotiate with such older
-   servers SHOULD send client hello messages using the SSL 3.0 record
-   format and client hello structure, sending {3, 2} for the version
-   field to note that they support TLS 1.1. If the server supports only
-   TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;
-   if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
-   The negotiation then proceeds as appropriate for the negotiated
-   protocol.
-
-   Similarly, a TLS 1.1  server which wishes to interoperate with TLS
-   1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages
-   and respond with a SSL 3.0 server hello if an SSL 3.0 client hello
-   with a version field of {3, 0} is received, denoting that this client
-   does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
-   version field of {3, 1} is received, the server SHOULD respond with a
-   TLS 1.0 hello with a version field of {3, 1}.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors SHOULD make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
- Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in
-   handshakes for backward compatibility but MUST NOT negotiate them in
-   TLS 1.1 mode.
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification. Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       This field is the length of the following data in bytes. The high
-       bit MUST be 1 and is not part of the length.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-       version 2 client hello message. The value SHOULD be one (1).
-
-   version
-       The highest version of the protocol supported by the client
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. When using the SSLv2 backward compatible
-       handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There MUST be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       This field MUST be empty.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   from the server key exchange message. The result is sent in a client
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate. The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed. Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key. TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites. The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly so the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Parties
-   concerned about attacks of this scale should not be using 40-bit
-   encryption keys anyway. Altering the padding of the least-significant
-   8 bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5. MD5 and SHA
-
-   TLS uses hash functions very conservatively. Where possible, both MD5
-   and SHA are used in tandem to ensure that non-catastrophic flaws in
-   one algorithm will not break the overall protocol.
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-F.4 Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information theoretic sense) that combined with any secure MAC
-       function fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message plus the length of the MAC tag is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent and unpredictable, IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext. This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-F.5 Denial of Service
-
-       TLS is susceptible to a number of denial of service (DoS)
-       attacks.  In particular, an attacker who initiates a large number
-       of TCP connections can cause a server to consume large amounts of
-       CPU doing RSA decryption. However, because TLS is generally used
-       over TCP, it is difficult for the attacker to hide his point of
-       origin if proper TCP SYN randomization is used [SEQNUM] by the
-       TCP stack.
-
-       Because TLS runs over TCP, it is also susceptible to a number of
-       denial of service attacks on individual connections. In
-       particular, attackers can forge RSTs, terminating connections, or
-       forge partial TLS records, causing the connection to stall.
-       These attacks cannot in general be defended against by a TCP-
-       using protocol. Implementors or users who are concerned with this
-       class of attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-Normative References
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
-            April 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1]  J. Jonsson, B. Kaliski, "3447 Public-Key Cryptography
-            Standards (PKCS) #1: RSA Cryptography Specifications Version
-            2.1", RFC 3447, February 2003"
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-            Considerations Section in RFCs", RFC 3434, October 1998.
-
-   [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, Junr 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.        [TLSKRB] A. Medvinsky, M. Hur,
-            "Addition of Kerberos Cipher Suites to Transport Layer
-            Security (TLS)", RFC 2712, October 1999.
-
-
-Informative References
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            2402, November 1998.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 2406, November 1998.
-
-   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
-            RFC 959, October 1985.
-
-   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-            [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller.
-            "Randomness Recommendations for Security", RFC 1750,
-            December 1994.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication
-            Framework". 1988.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
-            Data Representation Standard, August 1995.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-Credits
-
-   Working Group Chairs
-   Win Treese
-   EMail: treese@acm.org
-
-   Eric Rescorla
-   EMail: ekr@rtfm.com
-
-
-   Editors
-
-   Tim Dierks                Eric Rescorla
-   Independent                   RTFM, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@rtfm.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <ietf-tls@lists.consensus.com>. Information on the
-   group and information on how to subscribe to the list is at
-   <http://lists.consensus.com/>.
-
-   Archives of the list can be found at:
-       <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc2246-bis-09.txt  TLS                     December 2004
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc2246-bis-10.txt b/doc/protocol/draft-ietf-tls-rfc2246-bis-10.txt
deleted file mode 100644
index cbd1c03613..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc2246-bis-10.txt
+++ /dev/null
@@ -1,4860 +0,0 @@
-
-                                                              Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                                RTFM, Inc.
-<draft-ietf-tls-rfc2246-bis-10.txt>    April 2005 (Expires October 2005)
-
-                            The TLS Protocol
-                              Version 1.1
-
-Status of this Memo
-
-By submitting this Internet-Draft, I certify that any applicable
-patent or other IPR claims of which I am aware have been disclosed,
-and any of which I become aware will be disclosed, in accordance with
-RFC 3668.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-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 a "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999-2004).  All Rights Reserved.
-
-Abstract
-
-   This document specifies Version 1.1 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction
-   5 1.1       Requirements Terminology
-   6 2.        Goals
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   7 3.        Goals of this document
-   7 4.        Presentation language
-   8 4.1.      Basic block size
-   9 4.2.      Miscellaneous
-   9 4.3.      Vectors
-   9 4.4.      Numbers
-   10 4.5.      Enumerateds
-   10 4.6.      Constructed types
-   11 4.6.1.    Variants
-   12 4.7.      Cryptographic attributes
-   13 4.8.      Constants
-   14 5.        HMAC and the pseudorandom function
-   14 6.        The TLS Record Protocol
-   16 6.1.      Connection states
-   17 6.2.      Record layer
-   19 6.2.1.    Fragmentation
-   19 6.2.2.    Record compression and decompression
-   20 6.2.3.    Record payload protection
-   21 6.2.3.1.  Null or standard stream cipher
-   22 6.2.3.2.  CBC block cipher
-   22 6.3.      Key calculation
-   25 7.        The TLS Handshaking Protocols
-   26 7.1.      Change cipher spec protocol
-   27 7.2.      Alert protocol
-   27 7.2.1.    Closure alerts
-   28 7.2.2.    Error alerts
-   29 7.3.      Handshake Protocol overview
-   32 7.4.      Handshake protocol
-   36 7.4.1.    Hello messages
-   37 7.4.1.1.  Hello request
-   37 7.4.1.2.  Client hello
-   38 7.4.1.3.  Server hello
-   40 7.4.2.    Server certificate
-   41 7.4.3.    Server key exchange message
-   43 7.4.4.    Certificate request
-   45 7.4.5.    Server hello done
-   46 7.4.6.    Client certificate
-   47 7.4.7.    Client key exchange message
-   47 7.4.7.1.  RSA encrypted premaster secret message
-   48 7.4.7.2.  Client Diffie-Hellman public value
-   50 7.4.8.    Certificate verify
-   51 7.4.9.    Finished
-   51 8.        Cryptographic computations
-   52 8.1.      Computing the master secret
-   52 8.1.1.    RSA
-   54 8.1.2.    Diffie-Hellman
-   54 9.        Mandatory Cipher Suites
-   54 A.        Protocol constant values
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   56 A.1.      Record layer
-   56 A.2.      Change cipher specs message
-   57 A.3.      Alert messages
-   57 A.4.      Handshake protocol
-   58 A.4.1.    Hello messages
-   58 A.4.2.    Server authentication and key exchange messages
-   59 A.4.3.    Client authentication and key exchange messages
-   60 A.4.4.    Handshake finalization message
-   61 A.5.      The CipherSuite
-   61 A.6.      The Security Parameters
-   64 B.        Glossary
-   66 C.        CipherSuite definitions
-   70 D.        Implementation Notes
-   72 D.1       Random Number Generation and Seeding
-   72 D.2       Certificates and authentication
-   72 D.3       CipherSuites
-   72 E.        Backward Compatibility With SSL
-   73 E.1.      Version 2 client hello
-   74 E.2.      Avoiding man-in-the-middle version rollback
-   75 F.        Security analysis
-   77 F.1.      Handshake protocol
-   77 F.1.1.    Authentication and key exchange
-   77 F.1.1.1.  Anonymous key exchange
-   77 F.1.1.2.  RSA key exchange and authentication
-   78 F.1.1.3.  Diffie-Hellman key exchange with authentication
-   79 F.1.2.    Version rollback attacks
-   79 F.1.3.    Detecting attacks against the handshake protocol
-   80 F.1.4.    Resuming sessions
-   80 F.1.5.    MD5 and SHA
-   81 F.2.      Protecting application data
-   81 F.3.      Explicit IVs
-   81 F.4       Security of Composite Cipher Modes
-   82 F.5       Denial of Service
-   83 F.6.      Final notes
-   83
-
-
-Change history
-
-   03-Dec-04 ekr@rtfm.com
-    * Removed export cipher suites
-
-   26-Oct-04 ekr@rtfm.com
-    * Numerous cleanups from Last Call comments
-
-   10-Aug-04 ekr@rtfm.com
-    * Added clarifying material about interleaved application data.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   27-Jul-04 ekr@rtfm.com
-    * Premature closes no longer cause a session to be nonresumable.
-      Response to WG consensus.
-
-    * Added IANA considerations and registry for cipher suites
-      and ClientCertificateTypes
-
-   26-Jun-03 ekr@rtfm.com
-    * Incorporated Last Call comments from Franke Marcus, Jack Lloyd,
-    Brad Wetmore, and others.
-
-   22-Apr-03 ekr@rtfm.com
-    * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks
-    * cleaned up IV text a bit.
-    * Added discussion of Denial of Service attacks.
-
-   11-Feb-02 ekr@rtfm.com
-    * Clarified the behavior of empty certificate lists [Nelson Bolyard]
-    * Added text explaining the security implications of authenticate
-      then encrypt.
-    * Cleaned up the explicit IV text.
-    * Added some more acknowledgement names
-
-   02-Nov-02 ekr@rtfm.com
-    * Changed this to be TLS 1.1.
-    * Added fixes for the Rogaway and Vaudenay CBC attacks
-    * Separated references into normative and informative
-
-   01-Mar-02 ekr@rtfm.com
-    * Tightened up the language in F.1.1.2 [Peter Watkins]
-    * Fixed smart quotes [Bodo Moeller]
-    * Changed handling of padding errors to prevent CBC-based attack
-      [Bodo Moeller]
-    * Fixed certificate_list spec in the appendix [Aman Sawrup]
-    * Fixed a bug in the V2 definitions [Aman Sawrup]
-    * Fixed S 7.2.1 to point out that you don't need a close notify
-      if you just sent some other fatal alert [Andreas Sterbenz]
-    * Marked alert 41 reserved [Andreas Sterbenz]
-    * Changed S 7.4.2 to point out that 512-bit keys cannot be used for
-      signing [Andreas Sterbenz]
-    * Added reserved client key types from SSLv3 [Andreas Sterbenz]
-    * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz]
-    * Removed RSA patent statement [Andreas Sterbenz]
-    * Removed references to BSAFE and RSAREF [Andreas Sterbenz]
-
-   14-Feb-02 ekr@rtfm.com
-    * Re-converted to I-D from RFC
-    * Made RSA/3DES the mandatory cipher suite.
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-    * Added discussion of the EncryptedPMS encoding and PMS version number
-      issues to 7.4.7.1
-    * Removed the requirement in 7.4.1.3 that the Server random must be
-      different from the Client random, since these are randomly generated
-      and we don't expect servers to reject Server random values which
-      coincidentally are the same as the Client random.
-    * Replaced may/should/must with MAY/SHOULD/MUST where appropriate.
-      In many cases, shoulds became MUSTs, where I believed that was the
-      actual sense of the text. Added an RFC 2119 bulletin.
-   * Clarified the meaning of "empty certificate" message. [Peter Gutmann]
-   * Redid the CertificateRequest grammar to allow no distinguished names.
-     [Peter Gutmann]
-   * Removed the reference to requiring the master secret to generate
-     the CertificateVerify in F.1.1 [Bodo Moeller]
-   * Deprecated EXPORT40.
-   * Fixed a bunch of errors in the SSLv2 backward compatible client hello.
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [RC4], etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-   This document is a revision of the TLS 1.0 [TLS1.0] protocol which
-   contains some small security improvements, clarifications, and
-   editorial improvements. The major changes are:
-
-     - The implicit Initialization Vector (IV) is replaced with an
-   explicit
-       IV to protect against CBC attacks [CBCATT].
-
-     - Handling of padding errors is changed to use the bad_record_mac
-       alert rather than the decryption_failed alert to protect against
-       CBC attacks.
-
-     - IANA registries are defined for protocol parameters.
-
-     - Premature closes no longer cause a session to be nonresumable.
-
-     - Additional informational notes were added for various new attacks
-       on TLS.
-
-   In addition, a number of minor clarifications and editorial
-   improvements were made.
-
-
-
-1.1 Requirements Terminology
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-       successfully exchange cryptographic parameters without knowledge
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that TLS 1.1, TLS 1.0,  and SSL 3.0 do not
-   interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down prior versions. This document
-   is intended primarily for readers who will be implementing the
-   protocol and those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively. A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification. Cryptographic keys
-   are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, a 36-byte structure of two hashes (one SHA and one
-   MD5) is signed (encrypted with the private key). It is encoded with
-   PKCS #1 block type 0 or type 1 as described in [PKCS1].
-
-   In DSS, the 20 bytes of the SHA hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-   HMAC can be used with a variety of different hash algorithms. TLS
-   uses it in the handshake with two different algorithms: MD5 and
-   SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   data). Additional hash algorithms can be defined by cipher suites and
-   used to protect record data, but MD5 and SHA-1 are hard coded into
-   the description of the handshaking for this version of the protocol.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In order to make the PRF as secure as possible, it uses two hash
-   algorithms in a way which should guarantee its security if either
-   algorithm remains secure.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by splitting the secret into two halves and
-   using one half to generate data with P_MD5 and the other half to
-   generate data with P_SHA-1, then exclusive-or'ing the outputs of
-   these two expansion functions together.
-
-   S1 and S2 are the two halves of the secret and each is the same
-   length. S1 is taken from the first half of the secret, S2 from the
-   second half. Their length is created by rounding up the length of the
-   overall secret divided by two; thus, if the original secret is an odd
-   number of bytes long, the last byte of S1 will be the same as the
-   first byte of S2.
-
-       L_S = length in bytes of secret;
-       L_S1 = L_S2 = ceil(L_S / 2);
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   The secret is partitioned into two halves (with the possibility of
-   one shared byte) as described above, S1 taking the first L_S1 bytes
-   and S2 the last L_S2 bytes.
-
-   The PRF is then defined as the result of mixing the two pseudorandom
-   streams by exclusive-or'ing them together.
-
-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
-                                  P_SHA-1(S2, label + seed);
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
-   byte outputs, the boundaries of their internal iterations will not be
-   aligned; to generate a 80 byte output will involve P_MD5 being
-   iterated through A(5), while P_SHA-1 will only iterate through A(4).
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.1). All such
-   values must be defined by RFC 2434 Standards Action.  Section 11 for
-   IANA Considerations for ContentType values.
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it. Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block or stream cipher, the block size of
-       the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever the necessary state information
-       is to allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.1, which uses the version { 3, 2 }. The
-       version value 3.2 is historical: TLS version 1.1 is a minor
-       modification to the TLS 1.0 protocol, which was itself a minor
-       modification to the SSL 3.0 protocol, which bears the version
-       value 3.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved. Application data is generally of higher precedence
-       for transmission than other content types and therefore handshake
-       records may be held if application data is pending.  However,
-       records MUST be delivered to the network in the same order as
-       they are protected by the record layer. Recipients MUST receive
-       and process interleaved application layer traffic during
-       handshakes subsequent to the first one on a connection.
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-   For block ciphers (such as RC2 or DES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-       IV in order to prevent the attacks described by [CBCATT].
-       We recommend the following equivalently strong procedures.
-       For clarity we use the following notation.
-
-       IV -- the transmitted value of the IV field in the
-           GenericBlockCipher structure.
-       CBC residue -- the last ciphertext block of the previous record
-       mask -- the actual value which the cipher XORs with the
-           plaintext prior to encryption of the first cipher block
-           of the record.
-
-       In prior versions of TLS, there was no IV field and the CBC residue
-       and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
-       of [TLS1.0] for details of TLS 1.0 IV handling.
-
-       One of the following two algorithms SHOULD be used to generate the
-       per-record IV:
-
-       (1) Generate a cryptographically strong random string R of
-           length CipherSpec.block_length. Place R
-           in the IV field. Set the mask to R. Thus, the first
-           cipher block will be encrypted as E(R XOR Data).
-
-       (2) Generate a cryptographically strong random number R of
-           length CipherSpec.block_length and prepend it to the plaintext
-           prior to encryption. In
-           this case either:
-
-           (a)   The cipher may use a fixed mask such as zero.
-           (b) The CBC residue from the previous record may be used
-               as the mask. This preserves maximum code compatibility
-            with TLS 1.0 and SSL 3. It also has the advantage that
-            it does not require the ability to quickly reset the IV,
-            which is known to be a   problem on some systems.
-
-            In either case, the data (R || data) is fed into the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-            encryption process. The first cipher block (containing
-            E(mask XOR R) is placed in the IV field. The first
-            block of content contains E(IV XOR data)
-
-       The following alternative procedure MAY be used: However, it has
-       not been demonstrated to be equivalently cryptographically strong
-       to the above procedures. The sender prepends a fixed block F to
-       the plaintext (or alternatively a block generated with a weak
-       PRNG). He then encrypts as in (2) above, using the CBC residue
-       from the previous block as the mask for the prepended block. Note
-       that in this case the mask for the first record transmitted by
-       the application (the Finished) MUST be generated using a
-       cryptographically strong PRNG.
-
-       The decryption operation for all three alternatives is the same.
-       The receiver decrypts the entire GenericBlockCipher structure and
-       then discards the first cipher block, corresponding to the IV
-       component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes long, as long as it
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes (this does not
-          include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
-       timing attack on CBC padding based on the time required to
-       compute the MAC. In order to defend against this attack,
-       implementations MUST ensure that record processing time is
-       essentially the same whether or not the padding is correct.  In
-       general, the best way to to do this is to compute the MAC even if
-       the padding is incorrect, and only then reject the packet. For
-       instance, if the pad appears to be incorrect the implementation
-       might assume a zero-length pad and then compute the MAC. This
-       leaves a small timing channel, since MAC performance depends to
-       some extent on the size of the data fragment, but it is not
-       believed to be large enough to be exploitable due to the large
-       block size of existing MACs and the small size of the timing
-       signal.
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, which are generated from the master secret in
-   that order. Unused values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-
-   Implementation note:
-       The currently defined which requires the most material is
-       AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
-       keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key
-       material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols which are used to allow peers to agree
-       upon security parameters for the record layer, authenticate
-       themselves, instantiate negotiated security parameters, and
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-       An arbitrary byte sequence chosen by the server to identify an
-       active or resumable session state.
-
-   peer certificate
-       X509v3 [X509] certificate of the peer. This element of the state
-       may be null.
-
-   compression method
-       The algorithm used to compress data prior to encryption.
-
-   cipher spec
-       Specifies the bulk data encryption algorithm (such as null, DES,
-       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
-       cryptographic attributes such as the hash_size. (See Appendix A.6
-       for formal definition)
-
-   master secret
-       48-byte secret shared between the client and server.
-
-   is resumable
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       A flag indicating whether the session can be used to initiate new
-       connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.9).
-
- Note: if a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g. if it has to perform a time consuming public
-   key operation). Thus, a small window of time during which the
-   recipient must buffer the data MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   NB: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also MUST be returned if an alert is sent because
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed
-       This alert MAY be returned if a TLSCiphertext decrypted in an
-       invalid way: either it wasn't an even multiple of the block
-       length, or its padding values, when checked, weren't correct.
-       This message is always fatal.
-
-       NB: Differentiating between bad_record_mac and decryption_failed
-       alerts may permit certain attacks against CBC mode as used in TLS
-       [CBCATT]. It is preferable to uniformly use the bad_record_mac
-       alert to hide the specific type of the error.
-
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not in TLS. It should not be
-       sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in TLS 1.0 but not TLS 1.1.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New alerts values MUST be defined by RFC 2434 Standards Action. See
-   Section 11 for IANA Considerations for alert values.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   However, you SHOULD never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message type values MUST be defined via RFC 2434
-   Standards Action. See Section 11 for IANA Considerations for these
-   values.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
- Note: This message MUST NOT be included in the message hashes which are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT) according to the
-       sender's internal clock. Clocks are not required to be set
-       correctly by the basic TLS Protocol; higher level or application
-       protocols may define additional requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-   Forward compatibility note:
-       In the interests of forward compatibility, it is permitted for a
-       client hello message to include extra data after the compression
-       methods. This data MUST be included in the handshake hashes, but
-       must otherwise be ignored. This is the only handshake message for
-       which this is legal; for all other messages, the amount of data
-       in the message MUST match the description of the message
-       precisely.
-
-Note: For the intended use of trailing data in the ClientHello, see RFC
-       3546 [TLSEXT].
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-           CompressionMethod compression_method;
-       } ServerHello;
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions this field is the
-       value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will always
-       immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       certificate. It MUST contain a key which matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit MUST be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   MUST be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-   As CipherSuites which specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-               case rsa:
-                   ServerRSAParams params;
-           };
-        } ServerParams;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       md5_hash
-           MD5(ClientHello.random + ServerHello.random + ServerParams);
-
-       sha_hash
-           SHA(ClientHello.random + ServerHello.random + ServerParams);
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       select (SignatureAlgorithm)
-       {
-           case anonymous: struct { };
-           case rsa:
-               digitally-signed struct {
-                   opaque md5_hash[16];
-                   opaque sha_hash[20];
-               };
-           case dsa:
-               digitally-signed struct {
-                   opaque sha_hash[20];
-               };
-       } Signature;
-
-7.4.4. Certificate request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-        fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
-
- ClientCertificateType values are divided into three groups:
-
-              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-                 reserved for IETF Standards Track protocols.
-
-              2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
-                 are reserved for assignment for non-Standards Track methods.
-
-              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-                 inclusive are reserved for private use.
-
-           Additional information describing the role of IANA in the
-           allocation of ClientCertificateType code points is described
-           in Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were used in SSLv3.
-
- Note: DistinguishedName is derived from [X509]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.5. Server hello done
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message the client SHOULD
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client should send a certificate message
-       containing no certificates: I.e. the certificate_list structure
-       should have a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate must match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client key exchange message
-
-   When this message will be sent:
-       This message is always sent by the client. It will immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it will be the first message sent by the client after it receives
-       the server hello done message.
-
-   Meaning of this message:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters which will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate which contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA encrypted premaster secret message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate or the temporary RSA
-       key provided in a server key exchange message, and sends the
-       result in an encrypted premaster secret message. This structure
-       is a variant of the client key exchange message, not a message in
-       itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 encoded RSA. The
-       attack takes advantage of the fact that by failing in different
-       ways, a TLS server can be coerced into revealing whether a
-       particular message, when decrypted, is properly PKCS#1 formatted
-       or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
- Implementation Note: public-key-encrypted data is represented as an
-       opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted
-       PreMaster Secret in a ClientKeyExchange is preceded by two length
-       bytes. These bytes are redundant in the case of RSA because the
-       EncryptedPreMasterSecret is the only data in the
-       ClientKeyExchange and its length can therefore be unambiguously
-       determined. The SSLv3 specification was not clear about the
-       encoding of public-key-encrypted data and therefore many SSLv3
-       implementations do not include the the length bytes, encoding the
-       RSA encrypted data directly in the ClientKeyExchange message.
-
-       This specification requires correct encoding of the
-       EncryptedPreMasterSecret complete with length bytes. The
-       resulting PDU is incompatible with many SSLv3 implementations.
-       Implementors upgrading from SSLv3 must modify their
-       implementations to generate and accept the correct encoding.
-       Implementors who wish to be compatible with both SSLv3 and TLS
-       should make their implementation's behavior dependent on the
-       protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-       on SSL are possible, at least when the client and server are on
-       the same LAN. Accordingly, implementations which use static RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       keys SHOULD use RSA blinding or some other anti-timing technique,
-       as described in [TIMING].
-
- Note: The version number in the PreMasterSecret is that offered by the
-       client, NOT the version negotiated for the connection. This
-       feature is designed to prevent rollback attacks. Unfortunately,
-       many implementations use the negotiated version instead and
-       therefore checking the version number may lead to failure to
-       interoperate with such incorrect client implementations. Client
-       implementations MUST and Server implementations MAY check the
-       version number. In practice, since there are no significant known
-       security differences between TLS and SSLv3, rollback to SSLv3 is
-       not believed to be a serious security risk.  Note that if servers
-       choose to to check the version number, they should randomize the
-       PreMasterSecret in case of error, rather than generate an alert,
-       in order to avoid variants on the Bleichenbacher attack. [KPR03]
-
-7.4.7.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the Client Key Exchange message will be
-           sent, but will be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it will immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-       CertificateVerify.signature.md5_hash
-           MD5(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       verify_data
-           PRF(master_secret, finished_label, MD5(handshake_messages) +
-           SHA-1(handshake_messages)) [0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading 0 bytes of Z are
-   stripped before it is used as the pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-10. IANA Considerations
-
-   Section 7.4.3 describes a TLS ClientCertificateType Registry to be
-   maintained by the IANA, as defining a number of such code point
-   identifiers. ClientCertificateType identifiers with values in the
-   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action. Values from the range 64-223 (decimal) inclusive are assigned
-   via [RFC 2434] Specification Required.  Identifier values from
-   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
-   The registry will be initially populated with the values in this
-   document.
-
-   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   the IANA, as well as defining a number of such cipher suite
-   identifiers. Cipher suite values with the first byte in the range
-   0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
-   Values with the first byte in the range 192-254 (decimal) are
-   assigned via RFC 2434 Specification Required. Values with the first
-   byte 255 (decimal) are reserved for RFC 2434 Private Use. The
-   registry will be initially populated with the values from this
-   document, [TLSAES], and [TLSKRB].
-
-   Section 6 requires that all ContentType values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS ContentType registry,
-   initially populated with values from this document. Future values
-   MUST be allocated via Standards Action as described in [RFC 2434].
-
-   Section 7.2.2 requires that all Alert values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS Alert registry, initially
-   populated with values from this document and [TLSEXT]. Future values
-   MUST be allocated via Standards Action as described in [RFC 2434].
-
-   Section 7.4 requires that all HandshakeType values be defined by RFC
-   2434 Standards Action. IANA SHOULD create a TLS HandshakeType
-   registry, initially populated with values from this document,
-   [TLSEXT], and [TLSKRB].  Future values MUST be allocated via
-   Standards Action as described in [RFC 2434].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque RSA_modulus<1..2^16-1>;
-        opaque RSA_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque DH_p<1..2^16-1>;
-        opaque DH_g<1..2^16-1>;
-        opaque DH_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-            case rsa:
-                ServerRSAParams params;
-        };
-     } ServerParams;
-
-    select (SignatureAlgorithm)
-    {   case anonymous: struct { };
-        case rsa:
-            digitally-signed struct {
-                opaque md5_hash[16];
-                opaque sha_hash[20];
-            };
-        case dsa:
-            digitally-signed struct {
-                opaque sha_hash[20];
-            };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: DiffieHellmanClientPublicValue;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks and is
-   therefore deprecated.
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.1 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.1 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.1 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.1 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-   The following cipher suites were defined in [TLSAES] and are included
-   here for completeness. See [TLSAES] for details:
-
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
-
- The cipher suite space is divided into three regions:
-
-       1. Cipher suite values with first byte 0x00 (zero)
-          through decimal 191 (0xBF) inclusive are reserved for the IETF
-          Standards Track protocols.
-
-       2. Cipher suite values with first byte decimal 192 (0xC0)
-          through decimal 254 (0xFE) inclusive are reserved
-          for assignment for non-Standards Track methods.
-
-       3. Cipher suite values with first byte 0xFF are
-          reserved for private use.
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section 11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-B. Glossary
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [RC4].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-C. CipherSuite definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-the-
-   middle attacks. Applications should also enforce minimum and maximum
-   key sizes. For example, certificate chains containing 512-bit RSA
-   keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-E. Backward Compatibility With SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port: for example, the https protocol (HTTP secured by SSL
-   or TLS) uses port 443 regardless of which security protocol it is
-   using. Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting
-   both is easy. TLS clients who wish to negotiate with such older
-   servers SHOULD send client hello messages using the SSL 3.0 record
-   format and client hello structure, sending {3, 2} for the version
-   field to note that they support TLS 1.1. If the server supports only
-   TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;
-   if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
-   The negotiation then proceeds as appropriate for the negotiated
-   protocol.
-
-   Similarly, a TLS 1.1  server which wishes to interoperate with TLS
-   1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages
-   and respond with a SSL 3.0 server hello if an SSL 3.0 client hello
-   with a version field of {3, 0} is received, denoting that this client
-   does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
-   version field of {3, 1} is received, the server SHOULD respond with a
-   TLS 1.0 hello with a version field of {3, 1}.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors SHOULD make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
- Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in
-   handshakes for backward compatibility but MUST NOT negotiate them in
-   TLS 1.1 mode.
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification. Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       This field is the length of the following data in bytes. The high
-       bit MUST be 1 and is not part of the length.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-       version 2 client hello message. The value SHOULD be one (1).
-
-   version
-       The highest version of the protocol supported by the client
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. When using the SSLv2 backward compatible
-       handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There MUST be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       This field MUST be empty.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   from the server key exchange message. The result is sent in a client
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate. The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed. Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key. TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites. The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly so the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Parties
-   concerned about attacks of this scale should not be using 40-bit
-   encryption keys anyway. Altering the padding of the least-significant
-   8 bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5. MD5 and SHA
-
-   TLS uses hash functions very conservatively. Where possible, both MD5
-   and SHA are used in tandem to ensure that non-catastrophic flaws in
-   one algorithm will not break the overall protocol.
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-F.4 Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information theoretic sense) that combined with any secure MAC
-       function fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message plus the length of the MAC tag is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent and unpredictable, IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext. This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-F.5 Denial of Service
-
-       TLS is susceptible to a number of denial of service (DoS)
-       attacks.  In particular, an attacker who initiates a large number
-       of TCP connections can cause a server to consume large amounts of
-       CPU doing RSA decryption. However, because TLS is generally used
-       over TCP, it is difficult for the attacker to hide his point of
-       origin if proper TCP SYN randomization is used [SEQNUM] by the
-       TCP stack.
-
-       Because TLS runs over TCP, it is also susceptible to a number of
-       denial of service attacks on individual connections. In
-       particular, attackers can forge RSTs, terminating connections, or
-       forge partial TLS records, causing the connection to stall.
-       These attacks cannot in general be defended against by a TCP-
-       using protocol. Implementors or users who are concerned with this
-       class of attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-Normative References
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
-            April 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1]  J. Jonsson, B. Kaliski, "3447 Public-Key Cryptography
-            Standards (PKCS) #1: RSA Cryptography Specifications Version
-            2.1", RFC 3447, February 2003"
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-            Considerations Section in RFCs", RFC 3434, October 1998.
-
-   [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, Junr 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.        [TLSKRB] A. Medvinsky, M. Hur,
-            "Addition of Kerberos Cipher Suites to Transport Layer
-            Security (TLS)", RFC 2712, October 1999.
-
-
-Informative References
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            2402, November 1998.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 2406, November 1998.
-
-   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
-            RFC 959, October 1985.
-
-   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-            [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller.
-            "Randomness Recommendations for Security", RFC 1750,
-            December 1994.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication
-            Framework". 1988.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
-            Data Representation Standard, August 1995.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-Credits
-
-   Working Group Chairs
-   Win Treese
-   EMail: treese@acm.org
-
-   Eric Rescorla
-   EMail: ekr@rtfm.com
-
-
-   Editors
-
-   Tim Dierks                Eric Rescorla
-   Independent                   RTFM, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@rtfm.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <ietf-tls@lists.consensus.com>. Information on the
-   group and information on how to subscribe to the list is at
-   <http://lists.consensus.com/>.
-
-   Archives of the list can be found at:
-       <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc2246-bis-10.txt  TLS                        April 2005
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc2246-bis-12.txt b/doc/protocol/draft-ietf-tls-rfc2246-bis-12.txt
deleted file mode 100644
index e21d270969..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc2246-bis-12.txt
+++ /dev/null
@@ -1,4919 +0,0 @@
-
-
-
-
-
-
-                                                              Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                                RTFM, Inc.
-<draft-ietf-tls-rfc2246-bis-12.txt>    June 2005 (Expires December 2005)
-
-                            The TLS Protocol
-                              Version 1.1
-
-Status of this Memo
-
-By submitting this Internet-Draft, each author represents that
-any applicable patent or other IPR claims of which he or she is
-aware have been or will be disclosed, and any of which he or she
-becomes aware will be disclosed, in accordance with Section 6 of
-BCP 79.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-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 a "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document specifies Version 1.1 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction
-   5 1.1       Requirements Terminology
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   6 2.        Goals
-   7 3.        Goals of this document
-   7 4.        Presentation language
-   8 4.1.      Basic block size
-   9 4.2.      Miscellaneous
-   9 4.3.      Vectors
-   9 4.4.      Numbers
-   10 4.5.      Enumerateds
-   10 4.6.      Constructed types
-   11 4.6.1.    Variants
-   12 4.7.      Cryptographic attributes
-   13 4.8.      Constants
-   14 5.        HMAC and the pseudorandom function
-   14 6.        The TLS Record Protocol
-   16 6.1.      Connection states
-   17 6.2.      Record layer
-   19 6.2.1.    Fragmentation
-   19 6.2.2.    Record compression and decompression
-   20 6.2.3.    Record payload protection
-   21 6.2.3.1.  Null or standard stream cipher
-   22 6.2.3.2.  CBC block cipher
-   22 6.3.      Key calculation
-   25 7.        The TLS Handshaking Protocols
-   26 7.1.      Change cipher spec protocol
-   27 7.2.      Alert protocol
-   27 7.2.1.    Closure alerts
-   28 7.2.2.    Error alerts
-   29 7.3.      Handshake Protocol overview
-   32 7.4.      Handshake protocol
-   36 7.4.1.    Hello messages
-   37 7.4.1.1.  Hello request
-   37 7.4.1.2.  Client hello
-   38 7.4.1.3.  Server hello
-   40 7.4.2.    Server certificate
-   41 7.4.3.    Server key exchange message
-   43 7.4.4.    Certificate request
-   45 7.4.5.    Server hello done
-   46 7.4.6.    Client certificate
-   47 7.4.7.    Client key exchange message
-   47 7.4.7.1.  RSA encrypted premaster secret message
-   48 7.4.7.2.  Client Diffie-Hellman public value
-   50 7.4.8.    Certificate verify
-   51 7.4.9.    Finished
-   51 8.        Cryptographic computations
-   52 8.1.      Computing the master secret
-   52 8.1.1.    RSA
-   54 8.1.2.    Diffie-Hellman
-   54 9.        Mandatory Cipher Suites
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   54 A.        Protocol constant values
-   56 A.1.      Record layer
-   56 A.2.      Change cipher specs message
-   57 A.3.      Alert messages
-   57 A.4.      Handshake protocol
-   58 A.4.1.    Hello messages
-   58 A.4.2.    Server authentication and key exchange messages
-   59 A.4.3.    Client authentication and key exchange messages
-   60 A.4.4.    Handshake finalization message
-   61 A.5.      The CipherSuite
-   61 A.6.      The Security Parameters
-   64 B.        Glossary
-   66 C.        CipherSuite definitions
-   70 D.        Implementation Notes
-   72 D.1       Random Number Generation and Seeding
-   72 D.2       Certificates and authentication
-   72 D.3       CipherSuites
-   72 E.        Backward Compatibility With SSL
-   73 E.1.      Version 2 client hello
-   74 E.2.      Avoiding man-in-the-middle version rollback
-   75 F.        Security analysis
-   77 F.1.      Handshake protocol
-   77 F.1.1.    Authentication and key exchange
-   77 F.1.1.1.  Anonymous key exchange
-   77 F.1.1.2.  RSA key exchange and authentication
-   78 F.1.1.3.  Diffie-Hellman key exchange with authentication
-   79 F.1.2.    Version rollback attacks
-   79 F.1.3.    Detecting attacks against the handshake protocol
-   80 F.1.4.    Resuming sessions
-   80 F.1.5.    MD5 and SHA
-   81 F.2.      Protecting application data
-   81 F.3.      Explicit IVs
-   81 F.4       Security of Composite Cipher Modes
-   82 F.5       Denial of Service
-   83 F.6.      Final notes
-   83
-
-
-Change history
-
-   31-Jun-5 ekr@rtfm.com
-    * IETF Last Call comments (minor cleanups)
-
-   03-Dec-04 ekr@rtfm.com
-    * Removed export cipher suites
-
-   26-Oct-04 ekr@rtfm.com
-    * Numerous cleanups from Last Call comments
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   10-Aug-04 ekr@rtfm.com
-    * Added clarifying material about interleaved application data.
-
-   27-Jul-04 ekr@rtfm.com
-    * Premature closes no longer cause a session to be nonresumable.
-      Response to WG consensus.
-
-    * Added IANA considerations and registry for cipher suites
-      and ClientCertificateTypes
-
-   26-Jun-03 ekr@rtfm.com
-    * Incorporated Last Call comments from Franke Marcus, Jack Lloyd,
-    Brad Wetmore, and others.
-
-   22-Apr-03 ekr@rtfm.com
-    * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks
-    * cleaned up IV text a bit.
-    * Added discussion of Denial of Service attacks.
-
-   11-Feb-02 ekr@rtfm.com
-    * Clarified the behavior of empty certificate lists [Nelson Bolyard]
-    * Added text explaining the security implications of authenticate
-      then encrypt.
-    * Cleaned up the explicit IV text.
-    * Added some more acknowledgement names
-
-   02-Nov-02 ekr@rtfm.com
-    * Changed this to be TLS 1.1.
-    * Added fixes for the Rogaway and Vaudenay CBC attacks
-    * Separated references into normative and informative
-
-   01-Mar-02 ekr@rtfm.com
-    * Tightened up the language in F.1.1.2 [Peter Watkins]
-    * Fixed smart quotes [Bodo Moeller]
-    * Changed handling of padding errors to prevent CBC-based attack
-      [Bodo Moeller]
-    * Fixed certificate_list spec in the appendix [Aman Sawrup]
-    * Fixed a bug in the V2 definitions [Aman Sawrup]
-    * Fixed S 7.2.1 to point out that you don't need a close notify
-      if you just sent some other fatal alert [Andreas Sterbenz]
-    * Marked alert 41 reserved [Andreas Sterbenz]
-    * Changed S 7.4.2 to point out that 512-bit keys cannot be used for
-      signing [Andreas Sterbenz]
-    * Added reserved client key types from SSLv3 [Andreas Sterbenz]
-    * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz]
-    * Removed RSA patent statement [Andreas Sterbenz]
-    * Removed references to BSAFE and RSAREF [Andreas Sterbenz]
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   14-Feb-02 ekr@rtfm.com
-    * Re-converted to I-D from RFC
-    * Made RSA/3DES the mandatory cipher suite.
-    * Added discussion of the EncryptedPMS encoding and PMS version number
-      issues to 7.4.7.1
-    * Removed the requirement in 7.4.1.3 that the Server random must be
-      different from the Client random, since these are randomly generated
-      and we don't expect servers to reject Server random values which
-      coincidentally are the same as the Client random.
-    * Replaced may/should/must with MAY/SHOULD/MUST where appropriate.
-      In many cases, shoulds became MUSTs, where I believed that was the
-      actual sense of the text. Added an RFC 2119 bulletin.
-   * Clarified the meaning of "empty certificate" message. [Peter Gutmann]
-   * Redid the CertificateRequest grammar to allow no distinguished names.
-     [Peter Gutmann]
-   * Removed the reference to requiring the master secret to generate
-     the CertificateVerify in F.1.1 [Bodo Moeller]
-   * Deprecated EXPORT40.
-   * Fixed a bunch of errors in the SSLv2 backward compatible client hello.
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-   This document is a revision of the TLS 1.0 [TLS1.0] protocol which
-   contains some small security improvements, clarifications, and
-   editorial improvements. The major changes are:
-
-     - The implicit Initialization Vector (IV) is replaced with an
-   explicit
-       IV to protect against CBC attacks [CBCATT].
-
-     - Handling of padding errors is changed to use the bad_record_mac
-       alert rather than the decryption_failed alert to protect against
-       CBC attacks.
-
-     - IANA registries are defined for protocol parameters.
-
-     - Premature closes no longer cause a session to be nonresumable.
-
-     - Additional informational notes were added for various new attacks
-       on TLS.
-
-   In addition, a number of minor clarifications and editorial
-   improvements were made.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-1.1 Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-       successfully exchange cryptographic parameters without knowledge
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that TLS 1.1, TLS 1.0,  and SSL 3.0 do not
-   interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down prior versions. This document
-   is intended primarily for readers who will be implementing the
-   protocol and those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively. A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification. Cryptographic keys
-   are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, a 36-byte structure of two hashes (one SHA and one
-   MD5) is signed (encrypted with the private key). It is encoded with
-   PKCS #1 block type 0 or type 1 as described in [PKCS1A].
-
-   Note: the standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
-   However, to minimize differences with TLS 1.0 text, we are using the
-   terminology of RFC 2313 [PKCS1A].
-
-   In DSS, the 20 bytes of the SHA hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   HMAC can be used with a variety of different hash algorithms. TLS
-   uses it in the handshake with two different algorithms: MD5 and
-   SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   data). Additional hash algorithms can be defined by cipher suites and
-   used to protect record data, but MD5 and SHA-1 are hard coded into
-   the description of the handshaking for this version of the protocol.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In order to make the PRF as secure as possible, it uses two hash
-   algorithms in a way which should guarantee its security if either
-   algorithm remains secure.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by splitting the secret into two halves and
-   using one half to generate data with P_MD5 and the other half to
-   generate data with P_SHA-1, then exclusive-or'ing the outputs of
-   these two expansion functions together.
-
-   S1 and S2 are the two halves of the secret and each is the same
-   length. S1 is taken from the first half of the secret, S2 from the
-   second half. Their length is created by rounding up the length of the
-   overall secret divided by two; thus, if the original secret is an odd
-   number of bytes long, the last byte of S1 will be the same as the
-   first byte of S2.
-
-       L_S = length in bytes of secret;
-       L_S1 = L_S2 = ceil(L_S / 2);
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   The secret is partitioned into two halves (with the possibility of
-   one shared byte) as described above, S1 taking the first L_S1 bytes
-   and S2 the last L_S2 bytes.
-
-   The PRF is then defined as the result of mixing the two pseudorandom
-   streams by exclusive-or'ing them together.
-
-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
-                                  P_SHA-1(S2, label + seed);
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
-   byte outputs, the boundaries of their internal iterations will not be
-   aligned; to generate a 80 byte output will involve P_MD5 being
-   iterated through A(5), while P_SHA-1 will only iterate through A(4).
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.1). All such
-   values must be defined by RFC 2434 Standards Action.  See section 11
-   for IANA Considerations for ContentType values.
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it. Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block or stream cipher, the block size of
-       the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever the necessary state information
-       is to allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.1, which uses the version { 3, 2 }. The
-       version value 3.2 is historical: TLS version 1.1 is a minor
-       modification to the TLS 1.0 protocol, which was itself a minor
-       modification to the SSL 3.0 protocol, which bears the version
-       value 3.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved. Application data is generally of higher precedence
-       for transmission than other content types and therefore handshake
-       records may be held if application data is pending.  However,
-       records MUST be delivered to the network in the same order as
-       they are protected by the record layer. Recipients MUST receive
-       and process interleaved application layer traffic during
-       handshakes subsequent to the first one on a connection.
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-       IV in order to prevent the attacks described by [CBCATT].
-       We recommend the following equivalently strong procedures.
-       For clarity we use the following notation.
-
-       IV -- the transmitted value of the IV field in the
-           GenericBlockCipher structure.
-       CBC residue -- the last ciphertext block of the previous record
-       mask -- the actual value which the cipher XORs with the
-           plaintext prior to encryption of the first cipher block
-           of the record.
-
-       In prior versions of TLS, there was no IV field and the CBC residue
-       and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
-       of [TLS1.0] for details of TLS 1.0 IV handling.
-
-       One of the following two algorithms SHOULD be used to generate the
-       per-record IV:
-
-       (1) Generate a cryptographically strong random string R of
-           length CipherSpec.block_length. Place R
-           in the IV field. Set the mask to R. Thus, the first
-           cipher block will be encrypted as E(R XOR Data).
-
-       (2) Generate a cryptographically strong random number R of
-           length CipherSpec.block_length and prepend it to the plaintext
-           prior to encryption. In
-           this case either:
-
-           (a)   The cipher may use a fixed mask such as zero.
-           (b) The CBC residue from the previous record may be used
-               as the mask. This preserves maximum code compatibility
-            with TLS 1.0 and SSL 3. It also has the advantage that
-            it does not require the ability to quickly reset the IV,
-            which is known to be a   problem on some systems.
-
-            In either 2(a) or 2(b) the data (R || data) is fed into the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-            encryption process. The first cipher block (containing
-            E(mask XOR R) is placed in the IV field. The first
-            block of content contains E(IV XOR data)
-
-       The following alternative procedure MAY be used: However, it has
-       not been demonstrated to be equivalently cryptographically strong
-       to the above procedures. The sender prepends a fixed block F to
-       the plaintext (or alternatively a block generated with a weak
-       PRNG). He then encrypts as in (2) above, using the CBC residue
-       from the previous block as the mask for the prepended block. Note
-       that in this case the mask for the first record transmitted by
-       the application (the Finished) MUST be generated using a
-       cryptographically strong PRNG.
-
-       The decryption operation for all three alternatives is the same.
-       The receiver decrypts the entire GenericBlockCipher structure and
-       then discards the first cipher block, corresponding to the IV
-       component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes long, as long as it
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes (this does not
-          include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
-       timing attack on CBC padding based on the time required to
-       compute the MAC. In order to defend against this attack,
-       implementations MUST ensure that record processing time is
-       essentially the same whether or not the padding is correct.  In
-       general, the best way to to do this is to compute the MAC even if
-       the padding is incorrect, and only then reject the packet. For
-       instance, if the pad appears to be incorrect the implementation
-       might assume a zero-length pad and then compute the MAC. This
-       leaves a small timing channel, since MAC performance depends to
-       some extent on the size of the data fragment, but it is not
-       believed to be large enough to be exploitable due to the large
-       block size of existing MACs and the small size of the timing
-       signal.
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, which are generated from the master secret in
-   that order. Unused values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-
-   Implementation note:
-       The currently defined which requires the most material is
-       AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
-       keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key
-       material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols which are used to allow peers to agree
-       upon security parameters for the record layer, authenticate
-       themselves, instantiate negotiated security parameters, and
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [X509] certificate of the peer. This element of the
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the hash_size. (See
-         Appendix A.6 for formal definition)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.9).
-
- Note: if a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g. if it has to perform a time consuming public
-   key operation). Thus, a small window of time during which the
-   recipient must buffer the data MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed
-       This alert MAY be returned if a TLSCiphertext decrypted in an
-       invalid way: either it wasn't an even multiple of the block
-       length, or its padding values, when checked, weren't correct.
-       This message is always fatal.
-
-       Note: Differentiating between bad_record_mac and
-       decryption_failed alerts may permit certain attacks against CBC
-       mode as used in TLS [CBCATT]. It is preferable to uniformly use
-       the bad_record_mac alert to hide the specific type of the error.
-
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not in TLS. It should not be
-       sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in TLS 1.0 but not TLS 1.1.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New alerts values MUST be defined by RFC 2434 Standards Action. See
-   Section 11 for IANA Considerations for alert values.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   However, you SHOULD never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message type values MUST be defined via RFC 2434
-   Standards Action. See Section 11 for IANA Considerations for these
-   values.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
- Note: This message MUST NOT be included in the message hashes which are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-   Forward compatibility note:
-       In the interests of forward compatibility, it is permitted for a
-       client hello message to include extra data after the compression
-       methods. This data MUST be included in the handshake hashes, but
-       must otherwise be ignored. This is the only handshake message for
-       which this is legal; for all other messages, the amount of data
-       in the message MUST match the description of the message
-       precisely.
-
-Note: For the intended use of trailing data in the ClientHello, see RFC
-       3546 [TLSEXT].
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-           CompressionMethod compression_method;
-       } ServerHello;
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions this field is the
-       value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will always
-       immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       certificate. It MUST contain a key which matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit MUST be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   MUST be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-   As CipherSuites which specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-               case rsa:
-                   ServerRSAParams params;
-           };
-        } ServerParams;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       md5_hash
-           MD5(ClientHello.random + ServerHello.random + ServerParams);
-
-       sha_hash
-           SHA(ClientHello.random + ServerHello.random + ServerParams);
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       struct {
-           select (SignatureAlgorithm) {
-               case anonymous: struct { };
-               case rsa:
-                   digitally-signed struct {
-                       opaque md5_hash[16];
-                       opaque sha_hash[20];
-                   };
-               case dsa:
-                   digitally-signed struct {
-                       opaque sha_hash[20];
-                   };
-               };
-           };
-       } Signature;
-
-7.4.4. Certificate request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-        fortezza_dms_RESERVED(20),
-           (255)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       } ClientCertificateType;
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
-
- ClientCertificateType values are divided into three groups:
-
-              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-                 reserved for IETF Standards Track protocols.
-
-              2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
-                 are reserved for assignment for non-Standards Track methods.
-
-              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-                 inclusive are reserved for private use.
-
-           Additional information describing the role of IANA in the
-           allocation of ClientCertificateType code points is described
-           in Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were used in SSLv3.
-
- Note: DistinguishedName is derived from [X501]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-7.4.5. Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message the client SHOULD
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client SHOULD send a certificate message
-       containing no certificates. That is, the certificate_list
-       structure has a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate MUST match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client key exchange message
-
-   When this message will be sent:
-       This message is always sent by the client. It MUST immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it MUST be the first message sent by the client after it receives
-       the server hello done message.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   Meaning of this message:
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters which will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate which contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA encrypted premaster secret message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate or the temporary RSA
-       key provided in a server key exchange message, and sends the
-       result in an encrypted premaster secret message. This structure
-       is a variant of the client key exchange message, not a message in
-       itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 v 1.5 encoded RSA.
-       The attack takes advantage of the fact that by failing in
-       different ways, a TLS server can be coerced into revealing
-       whether a particular message, when decrypted, is properly PKCS#1
-       v1.5 formatted or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
-       [PKCS1B] defines a newer version of PKCS#1 encoding that is more
-       secure against the Bleichenbacher attack. However, for maximal
-       compatibility with TLS 1.0, TLS 1.1 retains the original
-       encoding. No variants of the Bleichenbacher attack are known to
-       exist provided that the above recommendations are followed.
-
- Implementation Note: public-key-encrypted data is represented as an
-       opaque vector <0..2^16-1> (see section 4.7). Thus the RSA-
-       encrypted PreMasterSecret in a ClientKeyExchange is preceded by
-       two length bytes. These bytes are redundant in the case of RSA
-       because the EncryptedPreMasterSecret is the only data in the
-       ClientKeyExchange and its length can therefore be unambiguously
-       determined. The SSLv3 specification was not clear about the
-       encoding of public-key-encrypted data and therefore many SSLv3
-       implementations do not include the the length bytes, encoding the
-       RSA encrypted data directly in the ClientKeyExchange message.
-
-       This specification requires correct encoding of the
-       EncryptedPreMasterSecret complete with length bytes. The
-       resulting PDU is incompatible with many SSLv3 implementations.
-       Implementors upgrading from SSLv3 must modify their
-       implementations to generate and accept the correct encoding.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       Implementors who wish to be compatible with both SSLv3 and TLS
-       should make their implementation's behavior dependent on the
-       protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-       on SSL are possible, at least when the client and server are on
-       the same LAN. Accordingly, implementations which use static RSA
-       keys SHOULD use RSA blinding or some other anti-timing technique,
-       as described in [TIMING].
-
- Note: The version number in the PreMasterSecret MUST be the version
-       offered by the client in the ClientHello, not the version
-       negotiated for the connection. This feature is designed to
-       prevent rollback attacks. Unfortunately, many implementations use
-       the negotiated version instead and therefore checking the version
-       number may lead to failure to interoperate with such incorrect
-       client implementations. Client implementations MUST and Server
-       implementations MAY check the version number. In practice, since
-       the TLS handshake MACs prevent downgrade and no good attacks are
-       known on those MACs, ambiguity is not considered a serious
-       security risk.  Note that if servers choose to to check the
-       version number, they should randomize the PreMasterSecret in case
-       of error, rather than generate an alert, in order to avoid
-       variants on the Bleichenbacher attack. [KPR03]
-
-7.4.7.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-       CertificateVerify.signature.md5_hash
-           MD5(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, MD5(handshake_messages) +
-           SHA-1(handshake_messages)) [0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. IANA Considerations
-
-   Section 7.4.3 describes a TLS ClientCertificateType Registry to be
-   maintained by the IANA, as defining a number of such code point
-   identifiers. ClientCertificateType identifiers with values in the
-   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action. Values from the range 64-223 (decimal) inclusive are assigned
-   via [RFC 2434] Specification Required.  Identifier values from
-   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
-   The registry will be initially populated with the values in this
-   document.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
-   the IANA, as well as defining a number of such cipher suite
-   identifiers. Cipher suite values with the first byte in the range
-   0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
-   Values with the first byte in the range 192-254 (decimal) are
-   assigned via RFC 2434 Specification Required. Values with the first
-   byte 255 (decimal) are reserved for RFC 2434 Private Use. The
-   registry will be initially populated with the values from this
-   document, [TLSAES], and [TLSKRB].
-
-   Section 6 requires that all ContentType values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS ContentType registry,
-   initially populated with values from this document. Future values
-   MUST be allocated via Standards Action as described in [RFC 2434].
-
-   Section 7.2.2 requires that all Alert values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS Alert registry, initially
-   populated with values from this document and [TLSEXT]. Future values
-   MUST be allocated via Standards Action as described in [RFC 2434].
-
-   Section 7.4 requires that all HandshakeType values be defined by RFC
-   2434 Standards Action. IANA SHOULD create a TLS HandshakeType
-   registry, initially populated with values from this document,
-   [TLSEXT], and [TLSKRB].  Future values MUST be allocated via
-   Standards Action as described in [RFC 2434].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque rsa_modulus<1..2^16-1>;
-        opaque rsa_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-            case rsa:
-                ServerRSAParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-            case anonymous: struct { };
-            case rsa:
-                digitally-signed struct {
-                    opaque md5_hash[16];
-                    opaque sha_hash[20];
-                };
-            case dsa:
-                digitally-signed struct {
-                    opaque sha_hash[20];
-                };
-            };
-        };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks and is
-   therefore deprecated.
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.1 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.1 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.1 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.1 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-   The following cipher suites were defined in [TLSAES] and are included
-   here for completeness. See [TLSAES] for details:
-
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
-
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
-
- The cipher suite space is divided into three regions:
-
-       1. Cipher suite values with first byte 0x00 (zero)
-          through decimal 191 (0xBF) inclusive are reserved for the IETF
-          Standards Track protocols.
-
-       2. Cipher suite values with first byte decimal 192 (0xC0)
-          through decimal 254 (0xFE) inclusive are reserved
-          for assignment for non-Standards Track methods.
-
-       3. Cipher suite values with first byte 0xFF are
-          reserved for private use.
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section 11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.
-       AES is
-       a block cipher with a 128, 192, or 256 bit keys and a 16 byte
-       block size. [AES] TLS currently only supports the 128 and 256
-       bit key sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-C. CipherSuite definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-the-
-   middle attacks. Applications should also enforce minimum and maximum
-   key sizes. For example, certificate chains containing 512-bit RSA
-   keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-E. Backward Compatibility With SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port: for example, the https protocol (HTTP secured by SSL
-   or TLS) uses port 443 regardless of which security protocol it is
-   using. Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting
-   both is easy. TLS clients who wish to negotiate with such older
-   servers SHOULD send client hello messages using the SSL 3.0 record
-   format and client hello structure, sending {3, 2} for the version
-   field to note that they support TLS 1.1. If the server supports only
-   TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;
-   if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
-   The negotiation then proceeds as appropriate for the negotiated
-   protocol.
-
-   Similarly, a TLS 1.1  server which wishes to interoperate with TLS
-   1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages
-   and respond with a SSL 3.0 server hello if an SSL 3.0 client hello
-   with a version field of {3, 0} is received, denoting that this client
-   does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
-   version field of {3, 1} is received, the server SHOULD respond with a
-   TLS 1.0 hello with a version field of {3, 1}.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors SHOULD make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
- Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in
-   handshakes for backward compatibility but MUST NOT negotiate them in
-   TLS 1.1 mode.
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification. Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       This field is the length of the following data in bytes. The high
-       bit MUST be 1 and is not part of the length.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-       version 2 client hello message. The value SHOULD be one (1).
-
-   version
-       The highest version of the protocol supported by the client
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. When using the SSLv2 backward compatible
-       handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There MUST be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       This field MUST be empty.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   from the server key exchange message. The result is sent in a client
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate. The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed. Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key. TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites. The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly so the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Parties
-   concerned about attacks of this scale should not be using 40-bit
-   encryption keys anyway. Altering the padding of the least-significant
-   8 bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5. MD5 and SHA
-
-   TLS uses hash functions very conservatively. Where possible, both MD5
-   and SHA are used in tandem to ensure that non-catastrophic flaws in
-   one algorithm will not break the overall protocol.
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-F.4 Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information theoretic sense) that combined with any secure MAC
-       function fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message plus the length of the MAC tag is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent and unpredictable, IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext. This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-F.5 Denial of Service
-
-       TLS is susceptible to a number of denial of service (DoS)
-       attacks.  In particular, an attacker who initiates a large number
-       of TCP connections can cause a server to consume large amounts of
-       CPU doing RSA decryption. However, because TLS is generally used
-       over TCP, it is difficult for the attacker to hide his point of
-       origin if proper TCP SYN randomization is used [SEQNUM] by the
-       TCP stack.
-
-       Because TLS runs over TCP, it is also susceptible to a number of
-       denial of service attacks on individual connections. In
-       particular, attackers can forge RSTs, terminating connections, or
-       forge partial TLS records, causing the connection to stall.
-       These attacks cannot in general be defended against by a TCP-
-       using protocol. Implementors or users who are concerned with this
-       class of attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-Normative References
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
-            April 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
-            RSA Cryptography Specifications Version 1.5", RFC 2313,
-            March 1998.
-
-   [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-            Considerations Section in RFCs", RFC 3434, October 1998.
-
-   [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.
-   [TLSKRB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to
-            Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-
-Informative References
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            2402, November 1998.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 2406, November 1998.
-
-   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-            RFC 959, October 1985.
-
-   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
-            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness
-            Recommendations for Security", RFC 1750, December 1994.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [X.501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology -
-            Open Systems Interconnection - The
-
-   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication
-            Framework". 1988.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, "XDR: External Data
-            Representation Standard", RFC 1832, August 1995.
-
-
-Credits
-
-   Working Group Chairs
-   Win Treese
-   EMail: treese@acm.org
-
-   Eric Rescorla
-   EMail: ekr@rtfm.com
-
-
-   Editors
-
-   Tim Dierks                Eric Rescorla
-   Independent                   RTFM, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@rtfm.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <ietf-tls@lists.consensus.com>. Information on the
-   group and information on how to subscribe to the list is at
-   <http://lists.consensus.com/>.
-
-   Archives of the list can be found at:
-       <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc2246-bis-12.txt  TLS                         June 2005
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc2246-bis-13.txt b/doc/protocol/draft-ietf-tls-rfc2246-bis-13.txt
deleted file mode 100644
index 62ac7c5090..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc2246-bis-13.txt
+++ /dev/null
@@ -1,4919 +0,0 @@
-
-
-
-
-
-
-                                                              Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                                RTFM, Inc.
-<draft-ietf-tls-rfc2246-bis-13.txt>    June 2005 (Expires December 2005)
-
-                            The TLS Protocol
-                              Version 1.1
-
-Status of this Memo
-
-By submitting this Internet-Draft, each author represents that
-any applicable patent or other IPR claims of which he or she is
-aware have been or will be disclosed, and any of which he or she
-becomes aware will be disclosed, in accordance with Section 6 of
-BCP 79.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-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 a "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document specifies Version 1.1 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction
-   5 1.1       Differences from TLS 1.0
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   6 1.1       Requirements Terminology
-   7 2.        Goals
-   7 3.        Goals of this document
-   7 4.        Presentation language
-   8 4.1.      Basic block size
-   9 4.2.      Miscellaneous
-   9 4.3.      Vectors
-   9 4.4.      Numbers
-   10 4.5.      Enumerateds
-   10 4.6.      Constructed types
-   11 4.6.1.    Variants
-   12 4.7.      Cryptographic attributes
-   13 4.8.      Constants
-   14 5.        HMAC and the pseudorandom function
-   14 6.        The TLS Record Protocol
-   17 6.1.      Connection states
-   18 6.2.      Record layer
-   20 6.2.1.    Fragmentation
-   20 6.2.2.    Record compression and decompression
-   21 6.2.3.    Record payload protection
-   22 6.2.3.1.  Null or standard stream cipher
-   23 6.2.3.2.  CBC block cipher
-   23 6.3.      Key calculation
-   26 7.        The TLS Handshaking Protocols
-   27 7.1.      Change cipher spec protocol
-   28 7.2.      Alert protocol
-   28 7.2.1.    Closure alerts
-   29 7.2.2.    Error alerts
-   30 7.3.      Handshake Protocol overview
-   33 7.4.      Handshake protocol
-   37 7.4.1.    Hello messages
-   38 7.4.1.1.  Hello request
-   38 7.4.1.2.  Client hello
-   39 7.4.1.3.  Server hello
-   41 7.4.2.    Server certificate
-   42 7.4.3.    Server key exchange message
-   44 7.4.4.    Certificate request
-   46 7.4.5.    Server hello done
-   48 7.4.6.    Client certificate
-   48 7.4.7.    Client key exchange message
-   48 7.4.7.1.  RSA encrypted premaster secret message
-   49 7.4.7.2.  Client Diffie-Hellman public value
-   51 7.4.8.    Certificate verify
-   52 7.4.9.    Finished
-   52 8.        Cryptographic computations
-   53 8.1.      Computing the master secret
-   54 8.1.1.    RSA
-   55 8.1.2.    Diffie-Hellman
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   55 9.        Mandatory Cipher Suites
-   55 A.        Protocol constant values
-   57 A.1.      Record layer
-   57 A.2.      Change cipher specs message
-   58 A.3.      Alert messages
-   58 A.4.      Handshake protocol
-   59 A.4.1.    Hello messages
-   59 A.4.2.    Server authentication and key exchange messages
-   60 A.4.3.    Client authentication and key exchange messages
-   61 A.4.4.    Handshake finalization message
-   62 A.5.      The CipherSuite
-   62 A.6.      The Security Parameters
-   65 B.        Glossary
-   67 C.        CipherSuite definitions
-   71 D.        Implementation Notes
-   73 D.1       Random Number Generation and Seeding
-   73 D.2       Certificates and authentication
-   73 D.3       CipherSuites
-   73 E.        Backward Compatibility With SSL
-   74 E.1.      Version 2 client hello
-   75 E.2.      Avoiding man-in-the-middle version rollback
-   76 F.        Security analysis
-   78 F.1.      Handshake protocol
-   78 F.1.1.    Authentication and key exchange
-   78 F.1.1.1.  Anonymous key exchange
-   78 F.1.1.2.  RSA key exchange and authentication
-   79 F.1.1.3.  Diffie-Hellman key exchange with authentication
-   80 F.1.2.    Version rollback attacks
-   80 F.1.3.    Detecting attacks against the handshake protocol
-   81 F.1.4.    Resuming sessions
-   81 F.1.5.    MD5 and SHA
-   82 F.2.      Protecting application data
-   82 F.3.      Explicit IVs
-   82 F.4       Security of Composite Cipher Modes
-   83 F.5       Denial of Service
-   84 F.6.      Final notes
-   84
-
-
-Change history
-
-   22-Jun-05 ekr@rtfm.com
-    * IESG comments
-    * IANA comments
-    * Cleaned up some references
-
-   31-May-05 ekr@rtfm.com
-    * IETF Last Call comments (minor cleanups)
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   03-Dec-04 ekr@rtfm.com
-    * Removed export cipher suites
-
-   26-Oct-04 ekr@rtfm.com
-    * Numerous cleanups from Last Call comments
-
-   10-Aug-04 ekr@rtfm.com
-    * Added clarifying material about interleaved application data.
-
-   27-Jul-04 ekr@rtfm.com
-    * Premature closes no longer cause a session to be nonresumable.
-      Response to WG consensus.
-
-    * Added IANA considerations and registry for cipher suites
-      and ClientCertificateTypes
-
-   26-Jun-03 ekr@rtfm.com
-    * Incorporated Last Call comments from Franke Marcus, Jack Lloyd,
-    Brad Wetmore, and others.
-
-   22-Apr-03 ekr@rtfm.com
-    * coverage of the Vaudenay, Boneh-Brumley, and KPR attacks
-    * cleaned up IV text a bit.
-    * Added discussion of Denial of Service attacks.
-
-   11-Feb-02 ekr@rtfm.com
-    * Clarified the behavior of empty certificate lists [Nelson Bolyard]
-    * Added text explaining the security implications of authenticate
-      then encrypt.
-    * Cleaned up the explicit IV text.
-    * Added some more acknowledgement names
-
-   02-Nov-02 ekr@rtfm.com
-    * Changed this to be TLS 1.1.
-    * Added fixes for the Rogaway and Vaudenay CBC attacks
-    * Separated references into normative and informative
-
-   01-Mar-02 ekr@rtfm.com
-    * Tightened up the language in F.1.1.2 [Peter Watkins]
-    * Fixed smart quotes [Bodo Moeller]
-    * Changed handling of padding errors to prevent CBC-based attack
-      [Bodo Moeller]
-    * Fixed certificate_list spec in the appendix [Aman Sawrup]
-    * Fixed a bug in the V2 definitions [Aman Sawrup]
-    * Fixed S 7.2.1 to point out that you don't need a close notify
-      if you just sent some other fatal alert [Andreas Sterbenz]
-    * Marked alert 41 reserved [Andreas Sterbenz]
-    * Changed S 7.4.2 to point out that 512-bit keys cannot be used for
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-      signing [Andreas Sterbenz]
-    * Added reserved client key types from SSLv3 [Andreas Sterbenz]
-    * Changed EXPORT40 to "40-bit EXPORT" in S 9 [Andreas Sterbenz]
-    * Removed RSA patent statement [Andreas Sterbenz]
-    * Removed references to BSAFE and RSAREF [Andreas Sterbenz]
-
-   14-Feb-02 ekr@rtfm.com
-    * Re-converted to I-D from RFC
-    * Made RSA/3DES the mandatory cipher suite.
-    * Added discussion of the EncryptedPMS encoding and PMS version number
-      issues to 7.4.7.1
-    * Removed the requirement in 7.4.1.3 that the Server random must be
-      different from the Client random, since these are randomly generated
-      and we don't expect servers to reject Server random values which
-      coincidentally are the same as the Client random.
-    * Replaced may/should/must with MAY/SHOULD/MUST where appropriate.
-      In many cases, shoulds became MUSTs, where I believed that was the
-      actual sense of the text. Added an RFC 2119 bulletin.
-   * Clarified the meaning of "empty certificate" message. [Peter Gutmann]
-   * Redid the CertificateRequest grammar to allow no distinguished names.
-     [Peter Gutmann]
-   * Removed the reference to requiring the master secret to generate
-     the CertificateVerify in F.1.1 [Bodo Moeller]
-   * Deprecated EXPORT40.
-   * Fixed a bunch of errors in the SSLv2 backward compatible client hello.
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-1.1 Differences from TLS 1.0
-   This document is a revision of the TLS 1.0 [TLS1.0] protocol which
-   contains some small security improvements, clarifications, and
-   editorial improvements. The major changes are:
-
-     - The implicit Initialization Vector (IV) is replaced with an
-   explicit
-       IV to protect against CBC attacks [CBCATT].
-
-     - Handling of padding errors is changed to use the bad_record_mac
-       alert rather than the decryption_failed alert to protect against
-       CBC attacks.
-
-     - IANA registries are defined for protocol parameters.
-
-     - Premature closes no longer cause a session to be nonresumable.
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-     - Additional informational notes were added for various new attacks
-       on TLS.
-
-   In addition, a number of minor clarifications and editorial
-   improvements were made.
-
-
-
-1.1 Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-       successfully exchange cryptographic parameters without knowledge
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that TLS 1.1, TLS 1.0,  and SSL 3.0 do not
-   interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down prior versions. This document
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   is intended primarily for readers who will be implementing the
-   protocol and those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively. A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification. Cryptographic keys
-   are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, a 36-byte structure of two hashes (one SHA and one
-   MD5) is signed (encrypted with the private key). It is encoded with
-   PKCS #1 block type 0 or type 1 as described in [PKCS1A].
-
-   Note: the standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
-   However, to minimize differences with TLS 1.0 text, we are using the
-   terminology of RFC 2313 [PKCS1A].
-
-   In DSS, the 20 bytes of the SHA hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1A].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   HMAC can be used with a variety of different hash algorithms. TLS
-   uses it in the handshake with two different algorithms: MD5 and
-   SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   data). Additional hash algorithms can be defined by cipher suites and
-   used to protect record data, but MD5 and SHA-1 are hard coded into
-   the description of the handshaking for this version of the protocol.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In order to make the PRF as secure as possible, it uses two hash
-   algorithms in a way which should guarantee its security if either
-   algorithm remains secure.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by splitting the secret into two halves and
-   using one half to generate data with P_MD5 and the other half to
-   generate data with P_SHA-1, then exclusive-or'ing the outputs of
-   these two expansion functions together.
-
-   S1 and S2 are the two halves of the secret and each is the same
-   length. S1 is taken from the first half of the secret, S2 from the
-   second half. Their length is created by rounding up the length of the
-   overall secret divided by two; thus, if the original secret is an odd
-   number of bytes long, the last byte of S1 will be the same as the
-   first byte of S2.
-
-       L_S = length in bytes of secret;
-       L_S1 = L_S2 = ceil(L_S / 2);
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   The secret is partitioned into two halves (with the possibility of
-   one shared byte) as described above, S1 taking the first L_S1 bytes
-   and S2 the last L_S2 bytes.
-
-   The PRF is then defined as the result of mixing the two pseudorandom
-   streams by exclusive-or'ing them together.
-
-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
-                                  P_SHA-1(S2, label + seed);
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
-   byte outputs, the boundaries of their internal iterations will not be
-   aligned; to generate a 80 byte output will involve P_MD5 being
-   iterated through A(5), while P_SHA-1 will only iterate through A(4).
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.1). All such
-   values must be defined by RFC 2434 Standards Action.  See section 11
-   for IANA Considerations for ContentType values.
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it. Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block or stream cipher, the block size of
-       the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever the necessary state information
-       is to allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.1, which uses the version { 3, 2 }. The
-       version value 3.2 is historical: TLS version 1.1 is a minor
-       modification to the TLS 1.0 protocol, which was itself a minor
-       modification to the SSL 3.0 protocol, which bears the version
-       value 3.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved. Application data is generally of higher precedence
-       for transmission than other content types and therefore handshake
-       records may be held if application data is pending.  However,
-       records MUST be delivered to the network in the same order as
-       they are protected by the record layer. Recipients MUST receive
-       and process interleaved application layer traffic during
-       handshakes subsequent to the first one on a connection.
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-       IV in order to prevent the attacks described by [CBCATT].
-       We recommend the following equivalently strong procedures.
-       For clarity we use the following notation.
-
-       IV -- the transmitted value of the IV field in the
-           GenericBlockCipher structure.
-       CBC residue -- the last ciphertext block of the previous record
-       mask -- the actual value which the cipher XORs with the
-           plaintext prior to encryption of the first cipher block
-           of the record.
-
-       In prior versions of TLS, there was no IV field and the CBC residue
-       and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
-       of [TLS1.0] for details of TLS 1.0 IV handling.
-
-       One of the following two algorithms SHOULD be used to generate the
-       per-record IV:
-
-       (1) Generate a cryptographically strong random string R of
-           length CipherSpec.block_length. Place R
-           in the IV field. Set the mask to R. Thus, the first
-           cipher block will be encrypted as E(R XOR Data).
-
-       (2) Generate a cryptographically strong random number R of
-           length CipherSpec.block_length and prepend it to the plaintext
-           prior to encryption. In
-           this case either:
-
-           (a)   The cipher may use a fixed mask such as zero.
-           (b) The CBC residue from the previous record may be used
-               as the mask. This preserves maximum code compatibility
-            with TLS 1.0 and SSL 3. It also has the advantage that
-            it does not require the ability to quickly reset the IV,
-            which is known to be a   problem on some systems.
-
-            In either 2(a) or 2(b) the data (R || data) is fed into the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-            encryption process. The first cipher block (containing
-            E(mask XOR R) is placed in the IV field. The first
-            block of content contains E(IV XOR data)
-
-       The following alternative procedure MAY be used: However, it has
-       not been demonstrated to be equivalently cryptographically strong
-       to the above procedures. The sender prepends a fixed block F to
-       the plaintext (or alternatively a block generated with a weak
-       PRNG). He then encrypts as in (2) above, using the CBC residue
-       from the previous block as the mask for the prepended block. Note
-       that in this case the mask for the first record transmitted by
-       the application (the Finished) MUST be generated using a
-       cryptographically strong PRNG.
-
-       The decryption operation for all three alternatives is the same.
-       The receiver decrypts the entire GenericBlockCipher structure and
-       then discards the first cipher block, corresponding to the IV
-       component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes long, as long as it
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes (this does not
-          include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
-       timing attack on CBC padding based on the time required to
-       compute the MAC. In order to defend against this attack,
-       implementations MUST ensure that record processing time is
-       essentially the same whether or not the padding is correct.  In
-       general, the best way to to do this is to compute the MAC even if
-       the padding is incorrect, and only then reject the packet. For
-       instance, if the pad appears to be incorrect the implementation
-       might assume a zero-length pad and then compute the MAC. This
-       leaves a small timing channel, since MAC performance depends to
-       some extent on the size of the data fragment, but it is not
-       believed to be large enough to be exploitable due to the large
-       block size of existing MACs and the small size of the timing
-       signal.
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, which are generated from the master secret in
-   that order. Unused values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-
-   Implementation note:
-       The currently defined which requires the most material is
-       AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
-       keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key
-       material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols which are used to allow peers to agree
-       upon security parameters for the record layer, authenticate
-       themselves, instantiate negotiated security parameters, and
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [X509] certificate of the peer. This element of the
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the hash_size. (See
-         Appendix A.6 for formal definition)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.9).
-
- Note: if a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g. if it has to perform a time consuming public
-   key operation). Thus, a small window of time during which the
-   recipient must buffer the data MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed
-       This alert MAY be returned if a TLSCiphertext decrypted in an
-       invalid way: either it wasn't an even multiple of the block
-       length, or its padding values, when checked, weren't correct.
-       This message is always fatal.
-
-       Note: Differentiating between bad_record_mac and
-       decryption_failed alerts may permit certain attacks against CBC
-       mode as used in TLS [CBCATT]. It is preferable to uniformly use
-       the bad_record_mac alert to hide the specific type of the error.
-
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not in TLS. It should not be
-       sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in TLS 1.0 but not TLS 1.1.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New alerts values MUST be defined by RFC 2434 Standards Action. See
-   Section 11 for IANA Considerations for alert values.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   However, you SHOULD never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message type values MUST be defined via RFC 2434
-   Standards Action. See Section 11 for IANA Considerations for these
-   values.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
- Note: This message MUST NOT be included in the message hashes which are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-   Forward compatibility note:
-       In the interests of forward compatibility, it is permitted for a
-       client hello message to include extra data after the compression
-       methods. This data MUST be included in the handshake hashes, but
-       must otherwise be ignored. This is the only handshake message for
-       which this is legal; for all other messages, the amount of data
-       in the message MUST match the description of the message
-       precisely.
-
-Note: For the intended use of trailing data in the ClientHello, see RFC
-       3546 [TLSEXT].
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-           CompressionMethod compression_method;
-       } ServerHello;
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions this field is the
-       value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will always
-       immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       certificate. It MUST contain a key which matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit MUST be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   MUST be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-   As CipherSuites which specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-               case rsa:
-                   ServerRSAParams params;
-           };
-        } ServerParams;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       md5_hash
-           MD5(ClientHello.random + ServerHello.random + ServerParams);
-
-       sha_hash
-           SHA(ClientHello.random + ServerHello.random + ServerParams);
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       struct {
-           select (SignatureAlgorithm) {
-               case anonymous: struct { };
-               case rsa:
-                   digitally-signed struct {
-                       opaque md5_hash[16];
-                       opaque sha_hash[20];
-                   };
-               case dsa:
-                   digitally-signed struct {
-                       opaque sha_hash[20];
-                   };
-               };
-           };
-       } Signature;
-
-7.4.4. Certificate request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-        fortezza_dms_RESERVED(20),
-           (255)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       } ClientCertificateType;
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
-
- ClientCertificateType values are divided into three groups:
-
-              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-                 reserved for IETF Standards Track protocols.
-
-              2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
-                 are reserved for assignment for non-Standards Track methods.
-
-              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-                 inclusive are reserved for private use.
-
-           Additional information describing the role of IANA in the
-           allocation of ClientCertificateType code points is described
-           in Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were used in SSLv3.
-
- Note: DistinguishedName is derived from [X501]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-7.4.5. Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message the client SHOULD
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client SHOULD send a certificate message
-       containing no certificates. That is, the certificate_list
-       structure has a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate MUST match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client key exchange message
-
-   When this message will be sent:
-       This message is always sent by the client. It MUST immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it MUST be the first message sent by the client after it receives
-       the server hello done message.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   Meaning of this message:
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters which will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate which contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA encrypted premaster secret message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate or the temporary RSA
-       key provided in a server key exchange message, and sends the
-       result in an encrypted premaster secret message. This structure
-       is a variant of the client key exchange message, not a message in
-       itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 v 1.5 encoded RSA.
-       The attack takes advantage of the fact that by failing in
-       different ways, a TLS server can be coerced into revealing
-       whether a particular message, when decrypted, is properly PKCS#1
-       v1.5 formatted or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
-       [PKCS1B] defines a newer version of PKCS#1 encoding that is more
-       secure against the Bleichenbacher attack. However, for maximal
-       compatibility with TLS 1.0, TLS 1.1 retains the original
-       encoding. No variants of the Bleichenbacher attack are known to
-       exist provided that the above recommendations are followed.
-
- Implementation Note: public-key-encrypted data is represented as an
-       opaque vector <0..2^16-1> (see section 4.7). Thus the RSA-
-       encrypted PreMasterSecret in a ClientKeyExchange is preceded by
-       two length bytes. These bytes are redundant in the case of RSA
-       because the EncryptedPreMasterSecret is the only data in the
-       ClientKeyExchange and its length can therefore be unambiguously
-       determined. The SSLv3 specification was not clear about the
-       encoding of public-key-encrypted data and therefore many SSLv3
-       implementations do not include the the length bytes, encoding the
-       RSA encrypted data directly in the ClientKeyExchange message.
-
-       This specification requires correct encoding of the
-       EncryptedPreMasterSecret complete with length bytes. The
-       resulting PDU is incompatible with many SSLv3 implementations.
-       Implementors upgrading from SSLv3 must modify their
-       implementations to generate and accept the correct encoding.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       Implementors who wish to be compatible with both SSLv3 and TLS
-       should make their implementation's behavior dependent on the
-       protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-       on SSL are possible, at least when the client and server are on
-       the same LAN. Accordingly, implementations which use static RSA
-       keys SHOULD use RSA blinding or some other anti-timing technique,
-       as described in [TIMING].
-
- Note: The version number in the PreMasterSecret MUST be the version
-       offered by the client in the ClientHello, not the version
-       negotiated for the connection. This feature is designed to
-       prevent rollback attacks. Unfortunately, many implementations use
-       the negotiated version instead and therefore checking the version
-       number may lead to failure to interoperate with such incorrect
-       client implementations. Client implementations MUST and Server
-       implementations MAY check the version number. In practice, since
-       the TLS handshake MACs prevent downgrade and no good attacks are
-       known on those MACs, ambiguity is not considered a serious
-       security risk.  Note that if servers choose to to check the
-       version number, they should randomize the PreMasterSecret in case
-       of error, rather than generate an alert, in order to avoid
-       variants on the Bleichenbacher attack. [KPR03]
-
-7.4.7.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-       CertificateVerify.signature.md5_hash
-           MD5(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, MD5(handshake_messages) +
-           SHA-1(handshake_messages)) [0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. IANA Considerations
-
-   This document describes a number of new registries to be created by
-   IANA. We recommend that they be placed as individual registries items
-   under a common TLS category.
-
-   Section 7.4.3 describes a TLS ClientCertificateType Registry to be
-   maintained by the IANA, as defining a number of such code point
-   identifiers. ClientCertificateType identifiers with values in the
-   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action. Values from the range 64-223 (decimal) inclusive are assigned
-   via [RFC 2434] Specification Required.  Identifier values from
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
-   The registry will be initially populated with the values in this
-   document, Section 7.4.4.
-
-   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
-   the IANA, as well as defining a number of such cipher suite
-   identifiers. Cipher suite values with the first byte in the range
-   0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
-   Values with the first byte in the range 192-254 (decimal) are
-   assigned via RFC 2434 Specification Required. Values with the first
-   byte 255 (decimal) are reserved for RFC 2434 Private Use. The
-   registry will be initially populated with the values from Section A.5
-   of this document, [TLSAES], and Section 3 of [TLSKRB].
-
-   Section 6 requires that all ContentType values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS ContentType registry,
-   initially populated with values from Section 6.2.1 of this document.
-   Future values MUST be allocated via Standards Action as described in
-   [RFC 2434].
-
-   Section 7.2.2 requires that all Alert values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS Alert registry, initially
-   populated with values from Section 7.2 of this document and Section 4
-   of [TLSEXT]. Future values MUST be allocated via Standards Action as
-   described in [RFC 2434].
-
-   Section 7.4 requires that all HandshakeType values be defined by RFC
-   2434 Standards Action. IANA SHOULD create a TLS HandshakeType
-   registry, initially populated with values from Section 7.4 of this
-   document and Section 2.4 of [TLSEXT].  Future values MUST be
-   allocated via Standards Action as described in [RFC2434].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque rsa_modulus<1..2^16-1>;
-        opaque rsa_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-            case rsa:
-                ServerRSAParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-            case anonymous: struct { };
-            case rsa:
-                digitally-signed struct {
-                    opaque md5_hash[16];
-                    opaque sha_hash[20];
-                };
-            case dsa:
-                digitally-signed struct {
-                    opaque sha_hash[20];
-                };
-            };
-        };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks and is
-   therefore deprecated.
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.1 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.1 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.1 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.1 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-   The following cipher suites were defined in [TLSAES] and are included
-   here for completeness. See [TLSAES] for details:
-
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
-
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
-
- The cipher suite space is divided into three regions:
-
-       1. Cipher suite values with first byte 0x00 (zero)
-          through decimal 191 (0xBF) inclusive are reserved for the IETF
-          Standards Track protocols.
-
-       2. Cipher suite values with first byte decimal 192 (0xC0)
-          through decimal 254 (0xFE) inclusive are reserved
-          for assignment for non-Standards Track methods.
-
-       3. Cipher suite values with first byte 0xFF are
-          reserved for private use.
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section 11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.
-       AES is
-       a block cipher with a 128, 192, or 256 bit keys and a 16 byte
-       block size. [AES] TLS currently only supports the 128 and 256
-       bit key sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-C. CipherSuite definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-the-
-   middle attacks. Applications should also enforce minimum and maximum
-   key sizes. For example, certificate chains containing 512-bit RSA
-   keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-E. Backward Compatibility With SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port: for example, the https protocol (HTTP secured by SSL
-   or TLS) uses port 443 regardless of which security protocol it is
-   using. Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting
-   both is easy. TLS clients who wish to negotiate with such older
-   servers SHOULD send client hello messages using the SSL 3.0 record
-   format and client hello structure, sending {3, 2} for the version
-   field to note that they support TLS 1.1. If the server supports only
-   TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;
-   if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
-   The negotiation then proceeds as appropriate for the negotiated
-   protocol.
-
-   Similarly, a TLS 1.1  server which wishes to interoperate with TLS
-   1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages
-   and respond with a SSL 3.0 server hello if an SSL 3.0 client hello
-   with a version field of {3, 0} is received, denoting that this client
-   does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
-   version field of {3, 1} is received, the server SHOULD respond with a
-   TLS 1.0 hello with a version field of {3, 1}.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors SHOULD make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
- Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in
-   handshakes for backward compatibility but MUST NOT negotiate them in
-   TLS 1.1 mode.
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification. Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       This field is the length of the following data in bytes. The high
-       bit MUST be 1 and is not part of the length.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-       version 2 client hello message. The value SHOULD be one (1).
-
-   version
-       The highest version of the protocol supported by the client
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. When using the SSLv2 backward compatible
-       handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There MUST be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       This field MUST be empty.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.8, 7.4.9 and 6.3). By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   from the server key exchange message. The result is sent in a client
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate. The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed. Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key. TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites. The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly so the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Parties
-   concerned about attacks of this scale should not be using 40-bit
-   encryption keys anyway. Altering the padding of the least-significant
-   8 bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5. MD5 and SHA
-
-   TLS uses hash functions very conservatively. Where possible, both MD5
-   and SHA are used in tandem to ensure that non-catastrophic flaws in
-   one algorithm will not break the overall protocol.
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-F.4 Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information theoretic sense) that combined with any secure MAC
-       function fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message plus the length of the MAC tag is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent and unpredictable, IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext. This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-F.5 Denial of Service
-
-       TLS is susceptible to a number of denial of service (DoS)
-       attacks.  In particular, an attacker who initiates a large number
-       of TCP connections can cause a server to consume large amounts of
-       CPU doing RSA decryption. However, because TLS is generally used
-       over TCP, it is difficult for the attacker to hide his point of
-       origin if proper TCP SYN randomization is used [SEQNUM] by the
-       TCP stack.
-
-       Because TLS runs over TCP, it is also susceptible to a number of
-       denial of service attacks on individual connections. In
-       particular, attackers can forge RSTs, terminating connections, or
-       forge partial TLS records, causing the connection to stall.
-       These attacks cannot in general be defended against by a TCP-
-       using protocol. Implementors or users who are concerned with this
-       class of attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-Normative References
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
-            RSA Cryptography Specifications Version 1.5", RFC 2313,
-            March 1998.
-
-   [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-            Considerations Section in RFCs", RFC 3434, October 1998.
-
-   [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.
-   [TLSKRB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to
-            Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-
-Informative References
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            2402, November 1998.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 2406, November 1998.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness
-            Recommendations for Security", RFC 1750, December 1994.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [X501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
-            Open Systems Interconnection - "The Directory -
-            Authentication Framework". 1988.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, "XDR: External Data
-            Representation Standard", RFC 1832, August 1995.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-Credits
-
-   Working Group Chairs
-   Win Treese
-   EMail: treese@acm.org
-
-   Eric Rescorla
-   EMail: ekr@rtfm.com
-
-
-   Editors
-
-   Tim Dierks                Eric Rescorla
-   Independent                   RTFM, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@rtfm.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <ietf-tls@lists.consensus.com>. Information on the
-   group and information on how to subscribe to the list is at
-   <http://lists.consensus.com/>.
-
-   Archives of the list can be found at:
-       <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc2246-bis-13.txt  TLS                         June 2005
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc3546bis-00.txt b/doc/protocol/draft-ietf-tls-rfc3546bis-00.txt
deleted file mode 100644
index 468f6bc6af..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc3546bis-00.txt
+++ /dev/null
@@ -1,1602 +0,0 @@
-
-TLS Working Group                                        S. Blake-Wilson
-Internet-Draft                                                       BCI
-Obsoletes: 3546 (if approved)                                 M. Nystrom
-Updates: 2246                                               RSA Security
-Category: Standards Track                                     D. Hopwood
-Expires: May 2005                                 Independent Consultant
-                                                            J. Mikkelsen
-                                                         Transactionware
-                                                               T. Wright
-                                                                Vodafone
-                                                           November 2004
-
-
-               Transport Layer Security (TLS) Extensions
-                   <draft-ietf-tls-rfc3546bis-00.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire in May 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   The extensions may be used by TLS clients and servers.  The
-   extensions are backwards compatible - communication is possible
-   between TLS 1.0 clients that support the extensions and TLS 1.0
-   servers that do not support the extensions, and vice versa.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 1]
-
-Internet-Draft               TLS Extensions                November 2004
-
-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 BCP 14, RFC 2119
-   [KEYWORDS].
-
-Table of Contents
-
-   1.  Introduction .............................................  2
-   2.  General Extension Mechanisms .............................  4
-       2.1. Extended Client Hello ...............................  5
-       2.2. Extended Server Hello ...............................  5
-       2.3. Hello Extensions ....................................  6
-       2.4. Extensions to the handshake protocol ................  7
-   3.  Specific Extensions ......................................  8
-       3.1. Server Name Indication ..............................  8
-       3.2. Maximum Fragment Length Negotiation ................. 10
-       3.3. Client Certificate URLs ............................. 11
-       3.4. Trusted CA Indication ............................... 14
-       3.5. Truncated HMAC ...................................... 15
-       3.6. Certificate Status Request........................... 16
-   4. Error alerts .............................................. 18
-   5. Procedure for Defining New Extensions...................... 20
-   6.  Security Considerations .................................. 21
-       6.1. Security of server_name ............................. 21
-       6.2. Security of max_fragment_length ..................... 21
-       6.3. Security of client_certificate_url .................. 22
-       6.4. Security of trusted_ca_keys ......................... 23
-       6.5. Security of truncated_hmac .......................... 23
-       6.6. Security of status_request .......................... 24
-   7.  Internationalization Considerations ...................... 24
-   8.  IANA Considerations ...................................... 24
-   9.  Intellectual Property Rights ............................. 26
-   10. Acknowledgments .......................................... 26
-   11. Normative References ..................................... 27
-   12. Informative References ................................... 28
-   13. Authors' Addresses ....................................... 28
-   14. Full Copyright Statement ................................. 29
-
-1. Introduction
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   TLS is now used in an increasing variety of operational environments
-   - many of which were not envisioned when the original design criteria
-   for TLS were determined.  The extensions introduced in this document
-   are designed to enable TLS to operate as effectively as possible in
-   new environments like wireless networks.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 2]
-
-Internet-Draft               TLS Extensions                November 2004
-
-
-   Wireless environments often suffer from a number of constraints not
-   commonly present in wired environments.  These constraints may
-   include bandwidth limitations, computational power limitations,
-   memory limitations, and battery life limitations.
-
-   The extensions described here focus on extending the functionality
-   provided by the TLS protocol message formats.  Other issues, such as
-   the addition of new cipher suites, are deferred.
-
-   Specifically, the extensions described in this document are designed
-   to:
-
-   -  Allow TLS clients to provide to the TLS server the name of the
-      server they are contacting.  This functionality is desirable to
-      facilitate secure connections to servers that host multiple
-      'virtual' servers at a single underlying network address.
-
-   -  Allow TLS clients and servers to negotiate the maximum fragment
-      length to be sent.  This functionality is desirable as a result of
-      memory constraints among some clients, and bandwidth constraints
-      among some access networks.
-
-   -  Allow TLS clients and servers to negotiate the use of client
-      certificate URLs.  This functionality is desirable in order to
-      conserve memory on constrained clients.
-
-   -  Allow TLS clients to indicate to TLS servers which CA root keys
-      they possess.  This functionality is desirable in order to prevent
-      multiple handshake failures involving TLS clients that are only
-      able to store a small number of CA root keys due to memory
-      limitations.
-
-   -  Allow TLS clients and servers to negotiate the use of truncated
-      MACs.  This functionality is desirable in order to conserve
-      bandwidth in constrained access networks.
-
-   -  Allow TLS clients and servers to negotiate that the server sends
-      the client certificate status information (e.g., an Online
-      Certificate Status Protocol (OCSP) [OCSP] response) during a TLS
-      handshake.  This functionality is desirable in order to avoid
-      sending a Certificate Revocation List (CRL) over a constrained
-      access network and therefore save bandwidth.
-
-   In order to support the extensions above, general extension
-   mechanisms for the client hello message and the server hello message
-   are introduced.
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 3]
-
-Internet-Draft               TLS Extensions                November 2004
-
-
-   The extensions described in this document may be used by TLS 1.0
-   clients and TLS 1.0 servers.  The extensions are designed to be
-   backwards compatible - meaning that TLS 1.0 clients that support the
-   extensions can talk to TLS 1.0 servers that do not support the
-   extensions, and vice versa.
-
-   Backwards compatibility is primarily achieved via two considerations:
-
-   -  Clients typically request the use of extensions via the extended
-      client hello message described in Section 2.1. TLS 1.0 [TLS]
-      requires servers to accept extended client hello messages, even if
-      the server does not "understand" the extension.
-
-   -  For the specific extensions described here, no mandatory server
-      response is required when clients request extended functionality.
-
-   Note however, that although backwards compatibility is supported,
-   some constrained clients may be forced to reject communications with
-   servers that do not support the extensions as a result of the limited
-   capabilities of such clients.
-
-   The remainder of this document is organized as follows.  Section 2
-   describes general extension mechanisms for the client hello and
-   server hello handshake messages.  Section 3 describes specific
-   extensions to TLS 1.0.  Section 4 describes new error alerts for use
-   with the TLS extensions.  The final sections of the document address
-   IPR, security considerations, registration of the application/pkix-
-   pkipath MIME type, acknowledgements, and references.
-
-2. General Extension Mechanisms
-
-   This section presents general extension mechanisms for the TLS
-   handshake client hello and server hello messages.
-
-   These general extension mechanisms are necessary in order to enable
-   clients and servers to negotiate whether to use specific extensions,
-   and how to use specific extensions.  The extension formats described
-   are based on [MAILING LIST].
-
-   Section 2.1 specifies the extended client hello message format,
-   Section 2.2 specifies the extended server hello message format, and
-   Section 2.3 describes the actual extension format used with the
-   extended client and server hellos.
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 4]
-
-Internet-Draft               TLS Extensions                November 2004
-
-2.1. Extended Client Hello
-
-   Clients MAY request extended functionality from servers by sending
-   the extended client hello message format in place of the client hello
-   message format.  The extended client hello message format is:
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-1>;
-          CompressionMethod compression_methods<1..2^8-1>;
-          Extension client_hello_extension_list<0..2^16-1>;
-      } ClientHello;
-
-   Here the new "client_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   In the event that a client requests additional functionality using
-   the extended client hello, and this functionality is not supplied by
-   the server, the client MAY abort the handshake.
-
-   Note that [TLS], Section 7.4.1.2, allows additional information to be
-   added to the client hello message.  Thus the use of the extended
-   client hello defined above should not "break" existing TLS 1.0
-   servers.
-
-   A server that supports the extensions mechanism MUST accept only
-   client hello messages in either the original or extended ClientHello
-   format, and (as for all other messages) MUST check that the amount of
-   data in the message precisely matches one of these formats; if not
-   then it MUST send a fatal "decode_error" alert.  This overrides the
-   "Forward compatibility note" in [TLS].
-
-2.2. Extended Server Hello
-
-   The extended server hello message format MAY be sent in place of the
-   server hello message when the client has requested extended
-   functionality via the extended client hello message specified in
-   Section 2.1.  The extended server hello message format is:
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 5]
-
-Internet-Draft               TLS Extensions                November 2004
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          Extension server_hello_extension_list<0..2^16-1>;
-      } ServerHello;
-
-   Here the new "server_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   Note that the extended server hello message is only sent in response
-   to an extended client hello message.  This prevents the possibility
-   that the extended server hello message could "break" existing TLS 1.0
-   clients.
-
-2.3. Hello Extensions
-
-   The extension format for extended client hellos and extended server
-   hellos is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   Here:
-
-   - "extension_type" identifies the particular extension type.
-
-   - "extension_data" contains information specific to the particular
-   extension type.
-
-   The extension types defined in this document are:
-
-      enum {
-          server_name(0), max_fragment_length(1),
-          client_certificate_url(2), trusted_ca_keys(3),
-          truncated_hmac(4), status_request(5), (65535)
-      } ExtensionType;
-
-   The list of defined extension types is maintained by the IANA. The
-   current list can be found at XXX (suggest 
-   http://www.iana.org/assignments/tls-extensions). See sections 5 and
-   8 for more information on how new values are added.
-
-   Note that for all extension types (including those defined in
-   future), the extension type MUST NOT appear in the extended server
-   hello unless the same extension type appeared in the corresponding
-   client hello.  Thus clients MUST abort the handshake if they receive
-   an extension type in the extended server hello that they did not
-   request in the associated (extended) client hello.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 6]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Nonetheless "server initiated" extensions may be provided in the
-   future within this framework by requiring the client to first send an
-   empty extension to indicate that it supports a particular extension.
-
-   Also note that when multiple extensions of different types are
-   present in the extended client hello or the extended server hello,
-   the extensions may appear in any order.  There MUST NOT be more than
-   one extension of the same type.
-
-   Finally note that an extended client hello may be sent both when
-   starting a new session and when requesting session resumption.
-   Indeed a client that requests resumption of a session does not in 
-   general know whether the server will accept this request, and 
-   therefore it SHOULD send an extended client hello if it would normally 
-   do so for a new session. In general the specification of each
-   extension type must include a discussion of the effect of the
-   extension both during new sessions and during resumed sessions.
-
-2.4. Extensions to the handshake protocol
-
-   This document suggests the use of two new handshake messages,
-   "CertificateURL" and "CertificateStatus".  These messages are
-   described in Section 3.3 and Section 3.6, respectively. The new
-   handshake message structure therefore becomes:
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), certificate_url(21), certificate_status(22),
-          (255)
-      } HandshakeType;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 7]
-
-Internet-Draft               TLS Extensions                November 2004
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case certificate_url:     CertificateURL;
-              case certificate_status:  CertificateStatus;
-          } body;
-      } Handshake;
-
-3. Specific Extensions
-
-   This section describes the specific TLS extensions specified in this
-   document.
-
-   Note that any messages associated with these extensions that are sent
-   during the TLS handshake MUST be included in the hash calculations
-   involved in "Finished" messages.
-
-   Note also that all the extensions defined in this Section are
-   relevant only when a session is initiated. When a client includes
-   one or more of the defined extension types in an extended client hello
-   while requesting session resumption:
-
-   - If the resumption request is denied, the use of the extensions
-   is negotiated as normal.  
-
-   - If, on the other hand, the older session is resumed, then the server 
-   MUST ignore the extensions and send a server hello containing none
-   of the extension types; in this case the functionality of these
-   extensions negotiated during the original session initiation is applied
-   to the resumed session.
-
-   Section 3.1 describes the extension of TLS to allow a client to
-   indicate which server it is contacting.  Section 3.2 describes the
-   extension to provide maximum fragment length negotiation.  Section
-   3.3 describes the extension to allow client certificate URLs.
-   Section 3.4 describes the extension to allow a client to indicate
-   which CA root keys it possesses.  Section 3.5 describes the extension
-   to allow the use of truncated HMAC.  Section 3.6 describes the
-   extension to support integration of certificate status information
-   messages into TLS handshakes.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 8]
-
-Internet-Draft               TLS Extensions                November 2004
-
-3.1. Server Name Indication
-
-   [TLS] does not provide a mechanism for a client to tell a server the
-   name of the server it is contacting.  It may be desirable for clients
-   to provide this information to facilitate secure connections to
-   servers that host multiple 'virtual' servers at a single underlying
-   network address.
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-      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;
-
-   Currently the only server names supported are DNS hostnames, however
-   this does not imply any dependency of TLS on DNS, and other name
-   types may be added in the future (by an RFC that Updates this
-   document).  TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client. The hostname is represented as a byte
-   string using UTF-8 encoding [UTF8], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in section 3.1
-   of [IDNA] notwithstanding). If the server needs to match the HostName
-   against names that contain non-US-ASCII characters, it MUST perform
-   the conversion operation described in section 4 of [IDNA], treating
-   the HostName as a "query string" (i.e. the AllowUnassigned flag MUST
-   be set). Note that IDNA allows labels to be separated by any of the
-   Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore
-   servers MUST accept any of these characters as a label separator.  If
-
-Blake-Wilson, et. al.       Standards Track                     [Page 9]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   the server only needs to match the HostName against names containing
-   exclusively ASCII characters, it MUST compare ASCII names case-
-   insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".
-
-   It is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension, MAY use the information contained in the extension to
-   guide its selection of an appropriate certificate to return to the
-   client, and/or other aspects of security policy.  In this event, the
-   server SHALL include an extension of type "server_name" in the
-   (extended) server hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol, then upgrades to TLS, and a server_name extension is sent,
-   then the extension SHOULD contain the same name that was negotiated
-   in the application protocol.  If the server_name is established in
-   the TLS session handshake, the client SHOULD NOT attempt to request a
-   different server name at the application layer.
-
-3.2. Maximum Fragment Length Negotiation
-
-   [TLS] specifies a fixed maximum plaintext fragment length of 2^14
-   bytes.  It may be desirable for constrained clients to negotiate a
-   smaller maximum fragment length due to memory limitations or
-   bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain:
-
-      enum{
-          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-      } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length.  The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 10]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension, MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL contain
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert.  Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent.  Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [TLS] section 6.2.1).  Note that the output
-   of the record layer may be larger.  For example, if the negotiated
-   length is 2^9=512, then for currently defined cipher suites (those
-   defined in [TLS], [KERB], and [AESSUITES]), and when null compression
-   is used, the record layer output can be at most 793 bytes: 5 bytes of
-   headers, 512 bytes of application data, 256 bytes of padding, and 20
-   bytes of MAC.  That means that in this event a TLS record layer peer
-   receiving a TLS record layer message larger than 793 bytes may
-   discard the message and send a "record_overflow" alert, without
-   decrypting the message.
-
-3.3. Client Certificate URLs
-
-   [TLS] specifies that when client authentication is performed, client
-   certificates are sent by clients to servers during the TLS handshake.
-   It may be desirable for constrained clients to send certificate URLs
-   in place of certificates, so that they do not need to store their
-   certificates and can therefore save memory.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 11]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   In order to negotiate to send certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-   (extended) client hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS 1.0 servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension, MAY indicate that they are
-   willing to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message:
-
-      enum {
-          individual_certs(0), pkipath(1), (255)
-      } CertChainType;
-
-      enum {
-          false(0), true(1)
-      } Boolean;
-
-      struct {
-          CertChainType type;
-          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-      } CertificateURL;
-
-      struct {
-          opaque url<1..2^16-1>;
-          Boolean hash_present;
-          select (hash_present) {
-              case false: struct {};
-              case true: SHA1Hash;
-          } hash;
-      } URLAndOptionalHash;
-
-      opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 12]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   When X.509 certificates are used, there are two possibilities:
-
-   -  if CertificateURL.type is "individual_certs", each URL refers to a
-      single DER-encoded X.509v3 certificate, with the URL for the
-      client's certificate first, or
-
-   -  if CertificateURL.type is "pkipath", the list contains a single
-      URL referring to a DER-encoded certificate chain, using the type
-      PkiPath described in Section 8.
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion is
-   either not present or is the SHA-1 hash of the certificate or
-   certificate chain (in the case of X.509 certificates, the DER-encoded
-   certificate or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [TLS] Section 7.4.2), but opposite to the order in which
-   certificates are encoded in PkiPath.  In either case, the self-signed
-   root certificate MAY be omitted from the chain, under the assumption
-   that the server must already possess it in order to validate it.
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs, and then process the
-   certificate chain as usual.  A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-   for certificate URLs, and MAY support other schemes.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
-   when a chain of X.509v3 certificates is returned, the Content-Type is
-   "application/pkix-pkipath" (see Section 8).
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 13]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash.  If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs. The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-3.4. Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys, may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-      struct {
-          TrustedAuthority trusted_authorities_list<0..2^16-1>;
-      } TrustedAuthorities;
-
-      struct {
-          IdentifierType identifier_type;
-          select (identifier_type) {
-              case pre_agreed: struct {};
-              case key_sha1_hash: SHA1Hash;
-              case x509_name: DistinguishedName;
-              case cert_sha1_hash: SHA1Hash;
-          } identifier;
-      } TrustedAuthority;
-
-      enum {
-          pre_agreed(0), key_sha1_hash(1), x509_name(2),
-          cert_sha1_hash(3), (255)
-      } IdentifierType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 14]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses.  Each CA root key is identified via
-   either:
-
-   -  "pre_agreed" - no CA root key identity supplied.
-
-   -  "key_sha1_hash" - contains the SHA-1 hash of the CA root key.  For
-      DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
-      value.  For RSA keys, the hash is of the big-endian byte string
-      representation of the modulus without any initial 0-valued bytes.
-      (This copies the key hash formats deployed in other environments.)
-
-   -  "x509_name" - contains the DER-encoded X.509 DistinguishedName of
-      the CA.
-
-   -  "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded
-      Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer - for example if
-   a particular CA has multiple key pairs - however here we assume this
-   is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension, MAY use the information contained in the extension to
-   guide their selection of an appropriate certificate chain to return
-   to the client.  In this event, the server SHALL include an extension
-   of type "trusted_ca_keys" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-3.5. Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [HMAC] to authenticate record layer
-   communications.  In TLS the entire output of the hash function is
-   used as the MAC tag.  However it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 15]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-   include an extension of type "truncated_hmac" in the extended client
-   hello.  The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension, MAY agree to use a truncated HMAC by including an
-   extension of type "truncated_hmac", with empty "extension_data", in
-   the extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect.  It is strongly recommended that any new cipher
-   suites using other MACs consider the MAC size as an integral part of
-   the cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters.  Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [HMAC].  That is, CipherSpec.hash_size is 10 bytes, and
-   only the first 10 bytes of the HMAC output are transmitted and
-   checked.  Note that this extension does not affect the calculation of
-   the PRF as part of handshaking or key derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-3.6. Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [OCSP] to check the validity of server certificates, in
-   order to avoid transmission of CRLs and therefore save bandwidth on
-   constrained networks.  This extension allows for such information to
-   be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "CertificateStatusRequest" where:
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 16]
-
-Internet-Draft               TLS Extensions                November 2004
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPStatusRequest;
-          } request;
-      } CertificateStatusRequest;
-
-      enum { ocsp(1), (255) } CertificateStatusType;
-
-      struct {
-          ResponderID responder_id_list<0..2^16-1>;
-          Extensions  request_extensions;
-      } OCSPStatusRequest;
-
-      opaque ResponderID<1..2^16-1>;
-      opaque Extensions<0..2^16-1>;
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts.  A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server - e.g., by prior arrangement.  "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [OCSP].  "Extensions" is imported from [PKIX].  A zero-
-   length "request_extensions" value means that there are no extensions
-   (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
-   the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-   Servers that receive a client hello containing the "status_request"
-   extension, MAY return a suitable certificate status response to the
-   client along with their certificate.  If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder, and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages).  If a server returns a
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 17]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPResponse;
-          } response;
-      } CertificateStatus;
-
-      opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [OCSP]).  Note that
-   only one OCSP response may be sent.
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response, and receiving an OCSP response
-   in a "CertificateStatus" message MUST check the OCSP response and
-   abort the handshake if the response is not satisfactory.
-
-4. Error Alerts
-
-   This section defines new error alerts for use with the TLS extensions
-   defined in this document.
-
-   The following new error alerts are defined.  To avoid "breaking"
-   existing clients and servers, these alerts MUST NOT be sent unless
-   the sending party has received an extended hello message from the
-   party they are communicating with.
-
-   -  "unsupported_extension" - this alert is sent by clients that
-      receive an extended server hello containing an extension that they
-      did not put in the corresponding client hello (see Section 2.3).
-      This message is always fatal.
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 18]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   -  "unrecognized_name" - this alert is sent by servers that receive a
-      server_name extension request, but do not recognize the server
-      name.  This message MAY be fatal.
-
-   -  "certificate_unobtainable" - this alert is sent by servers who are
-      unable to retrieve a certificate chain from the URL supplied by
-      the client (see Section 3.3).  This message MAY be fatal - for
-      example if client authentication is required by the server for the
-      handshake to continue and the server is unable to retrieve the
-      certificate chain, it may send a fatal alert.
-
-   -  "bad_certificate_status_response" - this alert is sent by clients
-      that receive an invalid certificate status response (see Section
-      3.6).  This message is always fatal.
-
-   -  "bad_certificate_hash_value" - this alert is sent by servers when
-      a certificate hash does not match a client provided
-      certificate_hash.  This message is always fatal.
-
-   These error alerts are conveyed using the following syntax:
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          /* 41 is not defined, for historical reasons */
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-          export_restriction(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-          no_renegotiation(100),
-          unsupported_extension(110),           /* new */
-          certificate_unobtainable(111),        /* new */
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 19]
-
-Internet-Draft               TLS Extensions                November 2004
-
-          unrecognized_name(112),               /* new */
-          bad_certificate_status_response(113), /* new */
-          bad_certificate_hash_value(114),      /* new */
-          (255)
-      } AlertDescription;
-
-5. Procedure for Defining New Extensions
-
-   The list of extension types, as defined in Section 2.3, is 
-   maintained by the Internet Assigned Numbers Authority (IANA). Thus 
-   an application needs to be made to the IANA in order to obtain a new  
-   extension type value. Since there are subtle (and not so subtle) 
-   interactions that may occur in this protocol between new features and 
-   existing features which may result in a significant reduction in 
-   overall security, new values SHALL be defined only through the IETF 
-   Consensus process specified in [IANA].
-
-   (This means that new assignments can be made only via RFCs approved 
-   by the IESG.)
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-   -  All of the extensions defined in this document follow the
-      convention that for each extension that a client requests and that
-      the server understands, the server replies with an extension of
-      the same type.
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some simply a refusal to support a particular
-      feature.  In general error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should as far as possible be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase. Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 20]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS - particularly since
-      the TLS handshake algorithms have specific protection against
-      version rollback attacks based on the version number, and the
-      possibility of version rollback should be a significant
-      consideration in any major design change.
-
-6. Security Considerations
-
-   Security considerations for the extension mechanism in general, and
-   the design of new extensions, are described in the previous section.
-   A security analysis of each of the extensions defined in this
-   document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art, and address any weaknesses identified.
-
-   Additional security considerations are described in the TLS 1.0 RFC
-   [TLS].
-
-6.1. Security of server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs.  Apart from this, server_name does not appear
-   to introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS - in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed.  It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-6.2. Security of max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages.  However, that does not introduce any security
-   complications that are not already present in TLS, since [TLS]
-   requires implementations to be able to handle fragmented handshake
-   messages.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 21]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Note that as described in section 3.2, once a non-null cipher suite
-   has been activated, the effective maximum fragment length depends on
-   the cipher suite and compression method, as well as on the negotiated
-   max_fragment_length.  This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-6.3. Security of client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes.  The purpose of including
-   hashes and checking them against the retrieved certificate chain, is
-   to ensure that the same property holds when this extension is used -
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances - for example clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client.  Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here.  The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server acting as a client in another URL protocol.  The
-   server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some, possibly weird-looking URL.
-
-   In general this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw.  It also introduces the possibility of denial of service
-   attacks in which an attacker makes many connections to the server,
-   each of which results in the server attempting a connection to the
-   target of the attack.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 22]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet; this could exacerbate the potential security and denial of
-   service problems described above, as well as allowing the existence
-   of internal hosts to be confirmed when they would otherwise be
-   hidden.
-
-   The detailed security concerns involved will depend on the URL
-   schemes supported by the server.  In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server.  In the case of HTTPS, the possibility for loops and
-   deadlocks to be created exists and should be addressed.  In the case
-   of FTP, attacks similar to FTP bounce attacks arise.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than being enabled by
-   default.  It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled, with unusual protocols offering limited security or whose
-   security is not well-understood being avoided.
-
-   As discussed in [URI], URLs that specify ports other than the default
-   may cause problems, as may very long URLs (which are more likely to
-   be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly.  If a request using HTTP (or another caching protocol)
-   goes through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-6.4. Security of trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information.  As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously.  As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-6.5. Security of truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs.  However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 23]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Note that the output length of a MAC need not be as long as the
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after the handshake
-   messages have been authenticated by the hashes in the Finished
-   messages, it is not possible for an active attacker to force
-   negotiation of the truncated HMAC extension where it would not
-   otherwise be used (to the extent that the handshake authentication is
-   secure).  Therefore, in the event that any security problem were
-   found with truncated HMAC in future, if either the client or the
-   server for a given session were updated to take into account the
-   problem, they would be able to veto use of this extension.
-
-6.6. Security of status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension.  A client that requires
-   OCSP validation of certificates SHOULD either contact the OCSP server
-   directly in this case, or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see section 4.4.1 of [OCSP] for further details.
-
-7. Internationalization Considerations
-
-   None of the extensions defined here directly use strings subject to
-   localization.  Domain Name System (DNS) hostnames are encoded using
-   UTF-8.  If future extensions use text strings, then
-   internationalization should be considered in their design.
-
-8. IANA Considerations
-
-   Sections 2.3 and 5 describes a registry of ExtensionType values to be
-   maintained by the IANA. ExtensionType values are to be assigned via 
-   IETF Consensus as defined in RFC 2434 [IANA].
-
-   The MIME type "application/pkix-pkipath" has been registered by the
-   IANA with the following template:
-
-   To: ietf-types@iana.org Subject: Registration of MIME media type
-   application/pkix-pkipath
-
-   MIME media type name: application
-
-   MIME subtype name: pkix-pkipath
-
-   Required parameters: none
-
-Blake-Wilson, et. al.       Standards Track                    [Page 24]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Optional parameters: version (default value is "1")
-
-   Encoding considerations:
-      This MIME type is a DER encoding of the ASN.1 type PkiPath,
-      defined as follows:
-        PkiPath ::= SEQUENCE OF Certificate
-        PkiPath is used to represent a certification path.  Within the
-        sequence, the order of certificates is such that the subject of
-        the first certificate is the issuer of the second certificate,
-        etc.
-
-      This is identical to the definition published in [X509-4th-TC1]; 
-      note that it is different from that in [X509-4th].
-
-      All Certificates MUST conform to [PKIX].  (This should be
-      interpreted as a requirement to encode only PKIX-conformant
-      certificates using this type.  It does not necessarily require
-      that all certificates that are not strictly PKIX-conformant must
-      be rejected by relying parties, although the security consequences
-      of accepting any such certificates should be considered
-      carefully.)
-
-      DER (as opposed to BER) encoding MUST be used.  If this type is
-      sent over a 7-bit transport, base64 encoding SHOULD be used.
-
-   Security considerations:
-      The security considerations of [X509-4th] and [PKIX] (or any
-      updates to them) apply, as well as those of any protocol that uses
-      this type (e.g., TLS).
-
-      Note that this type only specifies a certificate chain that can be
-      assessed for validity according to the relying party's existing
-      configuration of trusted CAs; it is not intended to be used to
-      specify any change to that configuration.
-
-   Interoperability considerations:
-      No specific interoperability problems are known with this type,
-      but for recommendations relating to X.509 certificates in general,
-      see [PKIX].
-
-   Published specification: this memo, and [PKIX].
-
-   Applications which use this media type: TLS.  It may also be used by
-      other protocols, or for general interchange of PKIX certificate
-      chains.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 25]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   Additional information:
-      Magic number(s): DER-encoded ASN.1 can be easily recognized.
-        Further parsing is required to distinguish from other ASN.1
-        types.
-      File extension(s): .pkipath
-      Macintosh File Type Code(s): not specified
-
-   Person & email address to contact for further information:
-      Magnus Nystrom <magnus@rsasecurity.com>
-
-   Intended usage: COMMON
-
-   Author/Change controller:
-      Magnus Nystrom <magnus@rsasecurity.com>
-
-9. Intellectual Property Rights
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in RFC 2028.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this document.  Please address the information to the IETF Executive
-   Director.
-
-10. Acknowledgments
-
-   The authors wish to thank the TLS Working Group and the WAP Security
-   Group.  This document is based on discussion within these groups.
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 26]
-
-Internet-Draft               TLS Extensions                November 2004
-
-11. Normative References
-
-   [HMAC]         Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-                  Keyed-hashing for message authentication", RFC 2104,
-                  February 1997.
-
-   [HTTP]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
-                  Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
-                  Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [IANA]         Narten, T. and H. Alvestrand, "Guidelines for Writing
-                  an IANA Considerations Section in RFCs", RFC 2434,
-                  October 1998.
-
-   [IDNA]         Faltstrom, P., Hoffman, P. and A. Costello,
-                  "Internationalizing Domain Names in Applications
-                  (IDNA)", RFC 3490, March 2003.
-
-   [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [OCSP]         Myers, M., Ankney, R., Malpani, A., Galperin, S. and
-                  C. Adams, "Internet X.509 Public Key Infrastructure:
-                  Online Certificate Status Protocol - OCSP", RFC 2560,
-                  June 1999.
-
-   [PKIOP]        Housley, R. and P. Hoffman, "Internet X.509 Public Key
-                  Infrastructure - Operation Protocols: FTP and HTTP",
-                  RFC 2585, May 1999.
-
-   [PKIX]         Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                  Public Key Infrastructure - Certificate and
-                  Certificate Revocation List (CRL) Profile", RFC 3280,
-                  April 2002.
-
-   [TLS]          Dierks, T. and C. Allen, "The TLS Protocol Version
-                  1.0", RFC 2246, January 1999.
-
-   [URI]          Berners-Lee, T., Fielding, R. and L. Masinter,
-                  "Uniform Resource Identifiers (URI): Generic Syntax",
-                  RFC 2396, August 1998.
-
-   [UTF8]         Yergeau, F., "UTF-8, a transformation format of ISO
-                  10646", RFC 3629, November 2003.
-
-   [X509-4th]     ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-
-                  8:2001, "Information Systems - Open Systems
-                  Interconnection - The Directory:  Public key and
-                  attribute certificate frameworks."
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 27]
-
-Internet-Draft               TLS Extensions                November 2004
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-                  ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
-                  1 to ISO/IEC 9594:8:2001.
-
-12. Informative References
-
-   [KERB]         Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-                  Suites to Transport Layer Security (TLS)", RFC 2712,
-                  October 1999.
-
-   [MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
-                  ClientHello extension mechanism and virtual hosting,"
-                  ietf-tls mailing list posting, August 14, 2000.
-
-   [AESSUITES]    Chown, P., "Advanced Encryption Standard (AES)
-                  Ciphersuites for Transport Layer Security (TLS)", RFC
-                  3268, June 2002.
-
-13. Authors' Addresses
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 28]
-
-Internet-Draft               TLS Extensions                November 2004
-
-14.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (year). This document is subject 
-   to the rights, licenses and restrictions contained in BCP 78, and 
-   except as set forth therein, the authors retain all their rights."
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein are provided on an 
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 29]
-
-
-
diff --git a/doc/protocol/draft-ietf-tls-rfc3546bis-01.txt b/doc/protocol/draft-ietf-tls-rfc3546bis-01.txt
deleted file mode 100644
index 9dd4527527..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc3546bis-01.txt
+++ /dev/null
@@ -1,1582 +0,0 @@
-
-TLS Working Group                                        S. Blake-Wilson
-Internet-Draft                                                       BCI
-Obsoletes: 3546 (if approved)                                 M. Nystrom
-Updates: 2246                                               RSA Security
-Category: Standards Track                                     D. Hopwood
-Expires: November 2005                            Independent Consultant
-                                                            J. Mikkelsen
-                                                         Transactionware
-                                                               T. Wright
-                                                                Vodafone
-                                                                May 2005
-
-               Transport Layer Security (TLS) Extensions
-                   <draft-ietf-tls-rfc3546bis-01.txt>
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.
-
-   By submitting this Internet-Draft, each author represents that any 
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes 
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire in November 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  All Rights Reserved.
-
-Abstract
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   The extensions may be used by TLS clients and servers.  The
-   extensions are backwards compatible - communication is possible
-   between TLS 1.0 clients that support the extensions and TLS 1.0
-   servers that do not support the extensions, and vice versa.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 1]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-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 BCP 14, RFC 2119
-   [KEYWORDS].
-
-Table of Contents
-
-   1.  Introduction .............................................  2
-   2.  General Extension Mechanisms .............................  4
-       2.1. Extended Client Hello ...............................  5
-       2.2. Extended Server Hello ...............................  5
-       2.3. Hello Extensions ....................................  6
-       2.4. Extensions to the handshake protocol ................  7
-   3.  Specific Extensions ......................................  8
-       3.1. Server Name Indication ..............................  8
-       3.2. Maximum Fragment Length Negotiation ................. 10
-       3.3. Client Certificate URLs ............................. 11
-       3.4. Trusted CA Indication ............................... 14
-       3.5. Truncated HMAC ...................................... 15
-       3.6. Certificate Status Request........................... 16
-   4. Error alerts .............................................. 18
-   5. Procedure for Defining New Extensions...................... 20
-   6.  Security Considerations .................................. 21
-       6.1. Security of server_name ............................. 21
-       6.2. Security of max_fragment_length ..................... 21
-       6.3. Security of client_certificate_url .................. 22
-       6.4. Security of trusted_ca_keys ......................... 23
-       6.5. Security of truncated_hmac .......................... 23
-       6.6. Security of status_request .......................... 24
-   7.  Internationalization Considerations ...................... 24
-   8.  IANA Considerations ...................................... 24
-   9.  Intellectual Property Rights ............................. 26
-   10. Acknowledgments .......................................... 26
-   11. Normative References ..................................... 27
-   12. Informative References ................................... 28
-   13. Authors' Addresses ....................................... 28
-   14. Full Copyright Statement ................................. 29
-
-1. Introduction
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   TLS is now used in an increasing variety of operational environments
-   - many of which were not envisioned when the original design criteria
-   for TLS were determined.  The extensions introduced in this document
-   are designed to enable TLS to operate as effectively as possible in
-   new environments like wireless networks.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 2]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Wireless environments often suffer from a number of constraints not
-   commonly present in wired environments.  These constraints may
-   include bandwidth limitations, computational power limitations,
-   memory limitations, and battery life limitations.
-
-   The extensions described here focus on extending the functionality
-   provided by the TLS protocol message formats.  Other issues, such as
-   the addition of new cipher suites, are deferred.
-
-   Specifically, the extensions described in this document:
-
-   -  Allow TLS clients to provide to the TLS server the name of the
-      server they are contacting.  This functionality is desirable to
-      facilitate secure connections to servers that host multiple
-      'virtual' servers at a single underlying network address.
-
-   -  Allow TLS clients and servers to negotiate the maximum fragment
-      length to be sent.  This functionality is desirable as a result of
-      memory constraints among some clients, and bandwidth constraints
-      among some access networks.
-
-   -  Allow TLS clients and servers to negotiate the use of client
-      certificate URLs.  This functionality is desirable in order to
-      conserve memory on constrained clients.
-
-   -  Allow TLS clients to indicate to TLS servers which CA root keys
-      they possess.  This functionality is desirable in order to prevent
-      multiple handshake failures involving TLS clients that are only
-      able to store a small number of CA root keys due to memory
-      limitations.
-
-   -  Allow TLS clients and servers to negotiate the use of truncated
-      MACs.  This functionality is desirable in order to conserve
-      bandwidth in constrained access networks.
-
-   -  Allow TLS clients and servers to negotiate that the server sends
-      the client certificate status information (e.g., an Online
-      Certificate Status Protocol (OCSP) [OCSP] response) during a TLS
-      handshake.  This functionality is desirable in order to avoid
-      sending a Certificate Revocation List (CRL) over a constrained
-      access network and therefore save bandwidth.
-
-   In order to support the extensions above, general extension
-   mechanisms for the client hello message and the server hello message
-   are introduced.
-
-   The extensions described in this document may be used by TLS 1.0
-   clients and TLS 1.0 servers.  The extensions are designed to be
-   backwards compatible - meaning that TLS 1.0 clients that support the
-   extensions can talk to TLS 1.0 servers that do not support the
-   extensions, and vice versa.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 3]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Backwards compatibility is primarily achieved via two considerations:
-
-   -  Clients typically request the use of extensions via the extended
-      client hello message described in Section 2.1. TLS 1.0 [TLS]
-      requires servers to accept extended client hello messages, even if
-      the server does not "understand" the extension.
-
-   -  For the specific extensions described here, no mandatory server
-      response is required when clients request extended functionality.
-
-   Note however, that although backwards compatibility is supported,
-   some constrained clients may be forced to reject communications with
-   servers that do not support the extensions as a result of the limited
-   capabilities of such clients.
-
-   This document is a revision of the RFC3546 [RFC3546]. The only 
-   major change concerns the definition of new extensions. New 
-   extensions can now be defined via the IETF Consensus Process (rather
-   than requiring a standards track RFC). In addition, a few minor 
-   clarifications and editorial improvements were made.
-
-   The remainder of this document is organized as follows.  Section 2
-   describes general extension mechanisms for the client hello and
-   server hello handshake messages.  Section 3 describes specific
-   extensions to TLS 1.0.  Section 4 describes new error alerts for use
-   with the TLS extensions.  The final sections of the document address
-   IPR, security considerations, registration of the 
-   application/pkix-pkipath MIME type, acknowledgements, and references.
-
-2. General Extension Mechanisms
-
-   This section presents general extension mechanisms for the TLS
-   handshake client hello and server hello messages.
-
-   These general extension mechanisms are necessary in order to enable
-   clients and servers to negotiate whether to use specific extensions,
-   and how to use specific extensions.  The extension formats described
-   are based on [MAILING LIST].
-
-   Section 2.1 specifies the extended client hello message format,
-   Section 2.2 specifies the extended server hello message format, and
-   Section 2.3 describes the actual extension format used with the
-   extended client and server hellos.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 4]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-2.1. Extended Client Hello
-
-   Clients MAY request extended functionality from servers by sending
-   the extended client hello message format in place of the client hello
-   message format.  The extended client hello message format is:
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-1>;
-          CompressionMethod compression_methods<1..2^8-1>;
-          Extension client_hello_extension_list<0..2^16-1>;
-      } ClientHello;
-
-   Here the new "client_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   In the event that a client requests additional functionality using
-   the extended client hello, and this functionality is not supplied by
-   the server, the client MAY abort the handshake.
-
-   Note that [TLS], Section 7.4.1.2, allows additional information to be
-   added to the client hello message.  Thus the use of the extended
-   client hello defined above should not "break" existing TLS 1.0
-   servers.
-
-   A server that supports the extensions mechanism MUST accept only
-   client hello messages in either the original or extended ClientHello
-   format, and (as for all other messages) MUST check that the amount of
-   data in the message precisely matches one of these formats; if not
-   then it MUST send a fatal "decode_error" alert.  This overrides the
-   "Forward compatibility note" in [TLS].
-
-2.2. Extended Server Hello
-
-   The extended server hello message format MAY be sent in place of the
-   server hello message when the client has requested extended
-   functionality via the extended client hello message specified in
-   Section 2.1.  The extended server hello message format is:
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 5]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          Extension server_hello_extension_list<0..2^16-1>;
-      } ServerHello;
-
-   Here the new "server_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   Note that the extended server hello message is only sent in response
-   to an extended client hello message.  This prevents the possibility
-   that the extended server hello message could "break" existing TLS 1.0
-   clients.
-
-2.3. Hello Extensions
-
-   The extension format for extended client hellos and extended server
-   hellos is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   Here:
-
-   - "extension_type" identifies the particular extension type.
-
-   - "extension_data" contains information specific to the particular
-   extension type.
-
-   The extension types defined in this document are:
-
-      enum {
-          server_name(0), max_fragment_length(1),
-          client_certificate_url(2), trusted_ca_keys(3),
-          truncated_hmac(4), status_request(5), (65535)
-      } ExtensionType;
-
-   The list of defined extension types is maintained by the IANA. The
-   current list can be found at XXX (suggest 
-   http://www.iana.org/assignments/tls-extensions). See sections 5 and
-   8 for more information on how new values are added.
-
-   Note that for all extension types (including those defined in
-   future), the extension type MUST NOT appear in the extended server
-   hello unless the same extension type appeared in the corresponding
-   client hello.  Thus clients MUST abort the handshake if they receive
-   an extension type in the extended server hello that they did not
-   request in the associated (extended) client hello.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 6]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Nonetheless "server initiated" extensions may be provided in the 
-   future within this framework - such an extension, say of type x, 
-   would require the client to first send an extension of type x in the 
-   (extended) client hello with empty extension_data to indicate that it 
-   supports the extension type.
-
-   Also note that when multiple extensions of different types are
-   present in the extended client hello or the extended server hello,
-   the extensions may appear in any order.  There MUST NOT be more than
-   one extension of the same type.
-
-   Finally note that an extended client hello may be sent both when
-   starting a new session and when requesting session resumption.
-   Indeed a client that requests resumption of a session does not in 
-   general know whether the server will accept this request, and 
-   therefore it SHOULD send an extended client hello if it would 
-   normally do so for a new session. In general the specification of 
-   each extension type must include a discussion of the effect of the
-   extension both during new sessions and during resumed sessions.
-
-2.4. Extensions to the handshake protocol
-
-   This document suggests the use of two new handshake messages,
-   "CertificateURL" and "CertificateStatus".  These messages are
-   described in Section 3.3 and Section 3.6, respectively. The new
-   handshake message structure therefore becomes:
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), certificate_url(21), certificate_status(22),
-          (255)
-      } HandshakeType;
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 7]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case certificate_url:     CertificateURL;
-              case certificate_status:  CertificateStatus;
-          } body;
-      } Handshake;
-
-3. Specific Extensions
-
-   This section describes the specific TLS extensions specified in this
-   document.
-
-   Note that any messages associated with these extensions that are sent
-   during the TLS handshake MUST be included in the hash calculations
-   involved in "Finished" messages.
-
-   Note also that all the extensions defined in this Section are
-   relevant only when a session is initiated. When a client includes
-   one or more of the defined extension types in an extended client
-   hello while requesting session resumption:
-
-   - If the resumption request is denied, the use of the extensions
-   is negotiated as normal.  
-
-   - If, on the other hand, the older session is resumed, then the 
-   server MUST ignore the extensions and send a server hello containing 
-   none of the extension types; in this case the functionality of these
-   extensions negotiated during the original session initiation is 
-   applied to the resumed session.
-
-   Section 3.1 describes the extension of TLS to allow a client to
-   indicate which server it is contacting.  Section 3.2 describes the
-   extension to provide maximum fragment length negotiation.  Section
-   3.3 describes the extension to allow client certificate URLs.
-   Section 3.4 describes the extension to allow a client to indicate
-   which CA root keys it possesses.  Section 3.5 describes the extension
-   to allow the use of truncated HMAC.  Section 3.6 describes the
-   extension to support integration of certificate status information
-   messages into TLS handshakes.
-
-Blake-Wilson, et. al.       Standards Track                     [Page 8]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-3.1. Server Name Indication
-
-   [TLS] does not provide a mechanism for a client to tell a server the
-   name of the server it is contacting.  It may be desirable for clients
-   to provide this information to facilitate secure connections to
-   servers that host multiple 'virtual' servers at a single underlying
-   network address.
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-      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;
-
-   Currently the only server names supported are DNS hostnames, however
-   this does not imply any dependency of TLS on DNS, and other name
-   types may be added in the future (by an RFC that Updates this
-   document).  TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client. The hostname is represented as a byte
-   string using UTF-8 encoding [UTF8], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in section 3.1
-   of [IDNA] notwithstanding). If the server needs to match the HostName
-   against names that contain non-US-ASCII characters, it MUST perform
-   the conversion operation described in section 4 of [IDNA], treating
-   the HostName as a "query string" (i.e. the AllowUnassigned flag MUST
-   be set). Note that IDNA allows labels to be separated by any of the
-   Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore
-   servers MUST accept any of these characters as a label separator.  If
-
-Blake-Wilson, et. al.       Standards Track                     [Page 9]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   the server only needs to match the HostName against names containing
-   exclusively ASCII characters, it MUST compare ASCII names case-
-   insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".
-
-   It is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension, MAY use the information contained in the extension to
-   guide its selection of an appropriate certificate to return to the
-   client, and/or other aspects of security policy.  In this event, the
-   server SHALL include an extension of type "server_name" in the
-   (extended) server hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol, then upgrades to TLS, and a server_name extension is sent,
-   then the extension SHOULD contain the same name that was negotiated
-   in the application protocol.  If the server_name is established in
-   the TLS session handshake, the client SHOULD NOT attempt to request a
-   different server name at the application layer.
-
-3.2. Maximum Fragment Length Negotiation
-
-   [TLS] specifies a fixed maximum plaintext fragment length of 2^14
-   bytes.  It may be desirable for constrained clients to negotiate a
-   smaller maximum fragment length due to memory limitations or
-   bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain:
-
-      enum{
-          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-      } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length.  The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 10]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension, MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL contain
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert.  Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent.  Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [TLS] section 6.2.1).  Note that the output
-   of the record layer may be larger.  For example, if the negotiated
-   length is 2^9=512, then for currently defined cipher suites (those
-   defined in [TLS], [KERB], and [AESSUITES]), and when null compression
-   is used, the record layer output can be at most 793 bytes: 5 bytes of
-   headers, 512 bytes of application data, 256 bytes of padding, and 20
-   bytes of MAC.  That means that in this event a TLS record layer peer
-   receiving a TLS record layer message larger than 793 bytes may
-   discard the message and send a "record_overflow" alert, without
-   decrypting the message.
-
-3.3. Client Certificate URLs
-
-   [TLS] specifies that when client authentication is performed, client
-   certificates are sent by clients to servers during the TLS handshake.
-   It may be desirable for constrained clients to send certificate URLs
-   in place of certificates, so that they do not need to store their
-   certificates and can therefore save memory.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 11]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   In order to negotiate to send certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-   (extended) client hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS 1.0 servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension, MAY indicate that they are
-   willing to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message:
-
-      enum {
-          individual_certs(0), pkipath(1), (255)
-      } CertChainType;
-
-      enum {
-          false(0), true(1)
-      } Boolean;
-
-      struct {
-          CertChainType type;
-          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-      } CertificateURL;
-
-      struct {
-          opaque url<1..2^16-1>;
-          Boolean hash_present;
-          select (hash_present) {
-              case false: struct {};
-              case true: SHA1Hash;
-          } hash;
-      } URLAndOptionalHash;
-
-      opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 12]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   When X.509 certificates are used, there are two possibilities:
-
-   -  if CertificateURL.type is "individual_certs", each URL refers to a
-      single DER-encoded X.509v3 certificate, with the URL for the
-      client's certificate first, or
-
-   -  if CertificateURL.type is "pkipath", the list contains a single
-      URL referring to a DER-encoded certificate chain, using the type
-      PkiPath described in Section 8.
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion is
-   either not present or is the SHA-1 hash of the certificate or
-   certificate chain (in the case of X.509 certificates, the DER-encoded
-   certificate or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [TLS] Section 7.4.2), but opposite to the order in which
-   certificates are encoded in PkiPath.  In either case, the self-signed
-   root certificate MAY be omitted from the chain, under the assumption
-   that the server must already possess it in order to validate it.
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs, and then process the
-   certificate chain as usual.  A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-   for certificate URLs, and MAY support other schemes.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
-   when a chain of X.509v3 certificates is returned, the Content-Type is
-   "application/pkix-pkipath" (see Section 8).
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 13]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash.  If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs. The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-3.4. Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys, may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-      struct {
-          TrustedAuthority trusted_authorities_list<0..2^16-1>;
-      } TrustedAuthorities;
-
-      struct {
-          IdentifierType identifier_type;
-          select (identifier_type) {
-              case pre_agreed: struct {};
-              case key_sha1_hash: SHA1Hash;
-              case x509_name: DistinguishedName;
-              case cert_sha1_hash: SHA1Hash;
-          } identifier;
-      } TrustedAuthority;
-
-      enum {
-          pre_agreed(0), key_sha1_hash(1), x509_name(2),
-          cert_sha1_hash(3), (255)
-      } IdentifierType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 14]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses.  Each CA root key is identified via
-   either:
-
-   -  "pre_agreed" - no CA root key identity supplied.
-
-   -  "key_sha1_hash" - contains the SHA-1 hash of the CA root key.  For
-      DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
-      value.  For RSA keys, the hash is of the big-endian byte string
-      representation of the modulus without any initial 0-valued bytes.
-      (This copies the key hash formats deployed in other environments.)
-
-   -  "x509_name" - contains the DER-encoded X.509 DistinguishedName of
-      the CA.
-
-   -  "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded
-      Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer - for example if
-   a particular CA has multiple key pairs - however here we assume this
-   is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension, MAY use the information contained in the extension to
-   guide their selection of an appropriate certificate chain to return
-   to the client.  In this event, the server SHALL include an extension
-   of type "trusted_ca_keys" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-3.5. Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [HMAC] to authenticate record layer
-   communications.  In TLS the entire output of the hash function is
-   used as the MAC tag.  However it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 15]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-   include an extension of type "truncated_hmac" in the extended client
-   hello.  The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension, MAY agree to use a truncated HMAC by including an
-   extension of type "truncated_hmac", with empty "extension_data", in
-   the extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect.  It is strongly recommended that any new cipher
-   suites using other MACs consider the MAC size as an integral part of
-   the cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters.  Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [HMAC].  That is, CipherSpec.hash_size is 10 bytes, and
-   only the first 10 bytes of the HMAC output are transmitted and
-   checked.  Note that this extension does not affect the calculation of
-   the PRF as part of handshaking or key derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-3.6. Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [OCSP] to check the validity of server certificates, in
-   order to avoid transmission of CRLs and therefore save bandwidth on
-   constrained networks.  This extension allows for such information to
-   be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "CertificateStatusRequest" where:
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 16]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPStatusRequest;
-          } request;
-      } CertificateStatusRequest;
-
-      enum { ocsp(1), (255) } CertificateStatusType;
-
-      struct {
-          ResponderID responder_id_list<0..2^16-1>;
-          Extensions  request_extensions;
-      } OCSPStatusRequest;
-
-      opaque ResponderID<1..2^16-1>;
-      opaque Extensions<0..2^16-1>;
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts.  A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server - e.g., by prior arrangement.  "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [OCSP].  "Extensions" is imported from [PKIX].  A zero-
-   length "request_extensions" value means that there are no extensions
-   (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
-   the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-   Servers that receive a client hello containing the "status_request"
-   extension, MAY return a suitable certificate status response to the
-   client along with their certificate.  If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder, and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages).  If a server returns a
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 17]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPResponse;
-          } response;
-      } CertificateStatus;
-
-      opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [OCSP]).  Note that
-   only one OCSP response may be sent.
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response, and receiving an OCSP response
-   in a "CertificateStatus" message MUST check the OCSP response and
-   abort the handshake if the response is not satisfactory.
-
-4. Error Alerts
-
-   This section defines new error alerts for use with the TLS extensions
-   defined in this document.
-
-   The following new error alerts are defined.  To avoid "breaking"
-   existing clients and servers, these alerts MUST NOT be sent unless
-   the sending party has received an extended hello message from the
-   party they are communicating with.
-
-   -  "unsupported_extension" - this alert is sent by clients that
-      receive an extended server hello containing an extension that they
-      did not put in the corresponding client hello (see Section 2.3).
-      This message is always fatal.
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 18]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   -  "unrecognized_name" - this alert is sent by servers that receive a
-      server_name extension request, but do not recognize the server
-      name.  This message MAY be fatal.
-
-   -  "certificate_unobtainable" - this alert is sent by servers who are
-      unable to retrieve a certificate chain from the URL supplied by
-      the client (see Section 3.3).  This message MAY be fatal - for
-      example if client authentication is required by the server for the
-      handshake to continue and the server is unable to retrieve the
-      certificate chain, it may send a fatal alert.
-
-   -  "bad_certificate_status_response" - this alert is sent by clients
-      that receive an invalid certificate status response (see Section
-      3.6).  This message is always fatal.
-
-   -  "bad_certificate_hash_value" - this alert is sent by servers when
-      a certificate hash does not match a client provided
-      certificate_hash.  This message is always fatal.
-
-   These error alerts are conveyed using the following syntax:
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          /* 41 is not defined, for historical reasons */
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-          export_restriction(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-          no_renegotiation(100),
-          unsupported_extension(110),           /* new */
-          certificate_unobtainable(111),        /* new */
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 19]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-          unrecognized_name(112),               /* new */
-          bad_certificate_status_response(113), /* new */
-          bad_certificate_hash_value(114),      /* new */
-          (255)
-      } AlertDescription;
-
-5. Procedure for Defining New Extensions
-
-   The list of extension types, as defined in Section 2.3, is 
-   maintained by the Internet Assigned Numbers Authority (IANA). Thus 
-   an application needs to be made to the IANA in order to obtain a new  
-   extension type value. Since there are subtle (and not so subtle) 
-   interactions that may occur in this protocol between new features and 
-   existing features which may result in a significant reduction in 
-   overall security, new values SHALL be defined only through the IETF 
-   Consensus process specified in [IANA].
-
-   (This means that new assignments can be made only via RFCs approved 
-   by the IESG.)
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-   -  All of the extensions defined in this document follow the
-      convention that for each extension that a client requests and that
-      the server understands, the server replies with an extension of
-      the same type.
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some simply a refusal to support a particular
-      feature.  In general error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should as far as possible be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase. Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 20]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS - particularly since
-      the TLS handshake algorithms have specific protection against
-      version rollback attacks based on the version number, and the
-      possibility of version rollback should be a significant
-      consideration in any major design change.
-
-6. Security Considerations
-
-   Security considerations for the extension mechanism in general, and
-   the design of new extensions, are described in the previous section.
-   A security analysis of each of the extensions defined in this
-   document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art, and address any weaknesses identified.
-
-   Additional security considerations are described in the TLS 1.0 RFC
-   [TLS].
-
-6.1. Security of server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs.  Apart from this, server_name does not appear
-   to introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS - in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed.  It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-6.2. Security of max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages.  However, that does not introduce any security
-   complications that are not already present in TLS, since [TLS]
-   requires implementations to be able to handle fragmented handshake
-   messages.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 21]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Note that as described in section 3.2, once a non-null cipher suite
-   has been activated, the effective maximum fragment length depends on
-   the cipher suite and compression method, as well as on the negotiated
-   max_fragment_length.  This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-6.3. Security of client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes.  The purpose of including
-   hashes and checking them against the retrieved certificate chain, is
-   to ensure that the same property holds when this extension is used -
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances - for example clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client.  Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here.  The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server acting as a client in another URL protocol.  The
-   server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some, possibly weird-looking URL.
-
-   In general this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw.  It also introduces the possibility of denial of service
-   attacks in which an attacker makes many connections to the server,
-   each of which results in the server attempting a connection to the
-   target of the attack.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 22]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet; this could exacerbate the potential security and denial of
-   service problems described above, as well as allowing the existence
-   of internal hosts to be confirmed when they would otherwise be
-   hidden.
-
-   The detailed security concerns involved will depend on the URL
-   schemes supported by the server.  In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server.  In the case of HTTPS, the possibility for loops and
-   deadlocks to be created exists and should be addressed.  In the case
-   of FTP, attacks similar to FTP bounce attacks arise.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than being enabled by
-   default.  It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled, with unusual protocols offering limited security or whose
-   security is not well-understood being avoided.
-
-   As discussed in [URI], URLs that specify ports other than the default
-   may cause problems, as may very long URLs (which are more likely to
-   be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly.  If a request using HTTP (or another caching protocol)
-   goes through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-6.4. Security of trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information.  As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously.  As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-6.5. Security of truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs.  However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 23]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Note that the output length of a MAC need not be as long as the
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after all handshake
-   messages that affect extension parameters have been authenticated by 
-   the hashes in the Finished messages, it is not possible for an active 
-   attacker to force negotiation of the truncated HMAC extension where it 
-   would not otherwise be used (to the extent that the handshake 
-   authentication is secure).  Therefore, in the event that any security 
-   problem were found with truncated HMAC in future, if either the client 
-   or the server for a given session were updated to take into account 
-   the problem, they would be able to veto use of this extension.
-
-6.6. Security of status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension.  A client that requires
-   OCSP validation of certificates SHOULD either contact the OCSP server
-   directly in this case, or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see section 4.4.1 of [OCSP] for further details.
-
-7. Internationalization Considerations
-
-   None of the extensions defined here directly use strings subject to
-   localization.  Domain Name System (DNS) hostnames are encoded using
-   UTF-8.  If future extensions use text strings, then
-   internationalization should be considered in their design.
-
-8. IANA Considerations
-
-   Sections 2.3 and 5 describes a registry of ExtensionType values to be
-   maintained by the IANA. ExtensionType values are to be assigned via 
-   IETF Consensus as defined in RFC 2434 [IANA].
-
-   The MIME type "application/pkix-pkipath" has been registered by the
-   IANA with the following template:
-
-   To: ietf-types@iana.org Subject: Registration of MIME media type
-   application/pkix-pkipath
-
-   MIME media type name: application
-
-   MIME subtype name: pkix-pkipath
-
-   Required parameters: none
-
-Blake-Wilson, et. al.       Standards Track                    [Page 24]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Optional parameters: version (default value is "1")
-
-   Encoding considerations:
-      This MIME type is a DER encoding of the ASN.1 type PkiPath,
-      defined as follows:
-        PkiPath ::= SEQUENCE OF Certificate
-        PkiPath is used to represent a certification path.  Within the
-        sequence, the order of certificates is such that the subject of
-        the first certificate is the issuer of the second certificate,
-        etc.
-
-      This is identical to the definition published in [X509-4th-TC1]; 
-      note that it is different from that in [X509-4th].
-
-      All Certificates MUST conform to [PKIX].  (This should be
-      interpreted as a requirement to encode only PKIX-conformant
-      certificates using this type.  It does not necessarily require
-      that all certificates that are not strictly PKIX-conformant must
-      be rejected by relying parties, although the security consequences
-      of accepting any such certificates should be considered
-      carefully.)
-
-      DER (as opposed to BER) encoding MUST be used.  If this type is
-      sent over a 7-bit transport, base64 encoding SHOULD be used.
-
-   Security considerations:
-      The security considerations of [X509-4th] and [PKIX] (or any
-      updates to them) apply, as well as those of any protocol that uses
-      this type (e.g., TLS).
-
-      Note that this type only specifies a certificate chain that can be
-      assessed for validity according to the relying party's existing
-      configuration of trusted CAs; it is not intended to be used to
-      specify any change to that configuration.
-
-   Interoperability considerations:
-      No specific interoperability problems are known with this type,
-      but for recommendations relating to X.509 certificates in general,
-      see [PKIX].
-
-   Published specification: this memo, and [PKIX].
-
-   Applications which use this media type: TLS.  It may also be used by
-      other protocols, or for general interchange of PKIX certificate
-      chains.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 25]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   Additional information:
-      Magic number(s): DER-encoded ASN.1 can be easily recognized.
-        Further parsing is required to distinguish from other ASN.1
-        types.
-      File extension(s): .pkipath
-      Macintosh File Type Code(s): not specified
-
-   Person & email address to contact for further information:
-      Magnus Nystrom <magnus@rsasecurity.com>
-
-   Intended usage: COMMON
-
-   Author/Change controller:
-      Magnus Nystrom <magnus@rsasecurity.com>
-
-9. Intellectual Property Rights
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed
-   to pertain to the implementation or use of the technology
-   described in this document or the extent to which any license
-   under such rights might or might not be available; nor does it
-   represent that it has made any independent effort to identify any
-   such rights.  Information on the procedures with respect to rights
-   in RFC documents can be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use
-   of such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository
-   at http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention
-   any copyrights, patents or patent applications, or other
-   proprietary rights that may cover technology that may be required
-   to implement this standard.  Please address the information to the
-   IETF at ietf-ipr@ietf.org.
-
-10. Acknowledgments
-
-   The authors wish to thank the TLS Working Group and the WAP Security
-   Group.  This document is based on discussion within these groups.
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 26]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-11. Normative References
-
-   [HMAC]         Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-                  Keyed-hashing for message authentication", RFC 2104,
-                  February 1997.
-
-   [HTTP]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
-                  Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
-                  Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [IANA]         Narten, T. and H. Alvestrand, "Guidelines for Writing
-                  an IANA Considerations Section in RFCs", RFC 2434,
-                  October 1998.
-
-   [IDNA]         Faltstrom, P., Hoffman, P. and A. Costello,
-                  "Internationalizing Domain Names in Applications
-                  (IDNA)", RFC 3490, March 2003.
-
-   [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [OCSP]         Myers, M., Ankney, R., Malpani, A., Galperin, S. and
-                  C. Adams, "Internet X.509 Public Key Infrastructure:
-                  Online Certificate Status Protocol - OCSP", RFC 2560,
-                  June 1999.
-
-   [PKIOP]        Housley, R. and P. Hoffman, "Internet X.509 Public Key
-                  Infrastructure - Operation Protocols: FTP and HTTP",
-                  RFC 2585, May 1999.
-
-   [PKIX]         Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                  Public Key Infrastructure - Certificate and
-                  Certificate Revocation List (CRL) Profile", RFC 3280,
-                  April 2002.
-
-   [TLS]          Dierks, T. and C. Allen, "The TLS Protocol Version
-                  1.0", RFC 2246, January 1999.
-
-   [URI]          Berners-Lee, T., Fielding, R. and L. Masinter,
-                  "Uniform Resource Identifiers (URI): Generic Syntax",
-                  RFC 2396, August 1998.
-
-   [UTF8]         Yergeau, F., "UTF-8, a transformation format of ISO
-                  10646", RFC 3629, November 2003.
-
-   [X509-4th]     ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-
-                  8:2001, "Information Systems - Open Systems
-                  Interconnection - The Directory:  Public key and
-                  attribute certificate frameworks."
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 27]
-
-Internet-Draft               TLS Extensions                     May 2005
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-                  ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
-                  1 to ISO/IEC 9594:8:2001.
-
-12. Informative References
-
-   [AESSUITES]    Chown, P., "Advanced Encryption Standard (AES)
-                  Ciphersuites for Transport Layer Security (TLS)", RFC
-                  3268, June 2002.
-
-   [KERB]         Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-                  Suites to Transport Layer Security (TLS)", RFC 2712,
-                  October 1999.
-
-   [MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
-                  ClientHello extension mechanism and virtual hosting,"
-                  ietf-tls mailing list posting, August 14, 2000.
-
-   [RFC3546]      S. Blake-Wilson, M.Nystrom, D. Hopwood, J. Mikkelsen,
-                  and T. Wright, "Transport Layer Security (TLS)
-                  Extensions", RFC 3546, June 2003.  
-
-13. Authors' Addresses
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 28]
-
-Internet-Draft               TLS Extensions                November 2004
-
-14.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is
-   subject to the rights, licenses and restrictions contained in BCP
-   78, and except as set forth therein, the authors retain all their
-   rights.
-
-   This document and the information contained herein are provided
-   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
-   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
-   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
-   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
-   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
-   PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 29]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt
deleted file mode 100644
index 1bf30d4cc8..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-01.txt
+++ /dev/null
@@ -1,5994 +0,0 @@
-
-                                                              Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                   Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-01.txt>    June 2006 (Expires December 2006)
-
-                            The TLS Protocol
-                              Version 1.2
-
-Status of this Memo
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction                                                4
-   1.1       Differences from TLS 1.1                                    5
-   1.1       Requirements Terminology                                    5
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   2.        Goals                                                       5
-   3.        Goals of this document                                      6
-   4.        Presentation language                                       6
-   4.1.      Basic block size                                            7
-   4.2.      Miscellaneous                                               7
-   4.3.      Vectors                                                     7
-   4.4.      Numbers                                                     8
-   4.5.      Enumerateds                                                 8
-   4.6.      Constructed types                                           9
-   4.6.1.    Variants                                                    10
-   4.7.      Cryptographic attributes                                    11
-   4.8.      Constants                                                   12
-   5.        HMAC and the pseudorandom function                          12
-   6.        The TLS Record Protocol                                     13
-   6.1.      Connection states                                           14
-   6.2.      Record layer                                                16
-   6.2.1.    Fragmentation                                               16
-   6.2.2.    Record compression and decompression                        18
-   6.2.3.    Record payload protection                                   18
-   6.2.3.1.  Null or standard stream cipher                              19
-   6.2.3.2.  CBC block cipher                                            20
-   6.3.      Key calculation                                             22
-   7.        The TLS Handshaking Protocols                               23
-   7.1.      Change cipher spec protocol                                 25
-   7.2.      Alert protocol                                              25
-   7.2.1.    Closure alerts                                              26
-   7.2.2.    Error alerts                                                27
-   7.3.      Handshake Protocol overview                                 31
-   7.4.      Handshake protocol                                          35
-   7.4.1.    Hello messages                                              36
-   7.4.1.1.  Hello request                                               36
-   7.4.1.2.  Client hello                                                37
-   7.4.1.3.  Server hello                                                40
-   7.4.1.4   Hello Extensions                                            41
-   7.4.1.4.1 Server Name Indication                                      43
-   7.4.1.4.2 Maximum Fragment Length Negotiation                         44
-   7.4.1.4.3 Client Certificate URLs                                     46
-   7.4.1.4.4 Trusted CA Indication                                       46
-   7.4.1.4.5 Truncated HMAC                                              48
-   7.4.1.4.6 Certificate Status Request                                  49
-   7.4.1.4.7 Cert Hash Types                                             50
-   7.4.1.4.8 Procedure for Defining New Extensions                       51
-   7.4.2.    Server certificate                                          52
-   7.4.3.    Server key exchange message                                 53
-   7.4.4.    CertificateStatus                                           56
-   7.4.5.    Certificate request                                         56
-   7.4.6.    Server hello done                                           58
-   7.4.7.    Client certificate                                          59
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   7.4.8.    Client Certificate URLs                                     59
-   7.4.9.    Client key exchange message                                 61
-   7.4.9.1.  RSA encrypted premaster secret message                      62
-   7.4.9.2.  Client Diffie-Hellman public value                          64
-   7.4.10.   Certificate verify                                          65
-   7.4.10.   Finished                                                    65
-   8.        Cryptographic computations                                  66
-   8.1.      Computing the master secret                                 67
-   8.1.1.    RSA                                                         68
-   8.1.2.    Diffie-Hellman                                              68
-   9.        Mandatory Cipher Suites                                     68
-   A.        Protocol constant values                                    72
-   A.1.      Record layer                                                72
-   A.2.      Change cipher specs message                                 73
-   A.3.      Alert messages                                              73
-   A.4.      Handshake protocol                                          75
-   A.4.1.    Hello messages                                              75
-   A.4.2.    Server authentication and key exchange messages             78
-   A.4.3.    Client authentication and key exchange messages             79
-   A.4.4.    Handshake finalization message                              80
-   A.5.      The CipherSuite                                             81
-   A.6.      The Security Parameters                                     84
-   B.        Glossary                                                    85
-   C.        CipherSuite definitions                                     89
-   D.        Implementation Notes                                        91
-   D.1       Random Number Generation and Seeding                        91
-   D.2       Certificates and authentication                             91
-   D.3       CipherSuites                                                91
-   E.        Backward Compatibility With SSL                             92
-   E.1.      Version 2 client hello                                      93
-   E.2.      Avoiding man-in-the-middle version rollback                 94
-   F.        Security analysis                                           96
-   F.1.      Handshake protocol                                          96
-   F.1.1.    Authentication and key exchange                             96
-   F.1.1.1.  Anonymous key exchange                                      96
-   F.1.1.2.  RSA key exchange and authentication                         97
-   F.1.1.3.  Diffie-Hellman key exchange with authentication             98
-   F.1.2.    Version rollback attacks                                    98
-   F.1.3.    Detecting attacks against the handshake protocol            99
-   F.1.4.    Resuming sessions                                           99
-   F.1.5     Extensions                                                  100
-   F.1.5.1   Security of server_name                                     100
-   F.1.5.2   Security of client_certificate_url                          101
-   F.1.5.4.  Security of trusted_ca_keys                                 102
-   F.1.5.5.  Security of truncated_hmac                                  102
-   F.1.5.6.  Security of status_request                                  103
-   F.2.      Protecting application data                                 103
-   F.3.      Explicit IVs                                                104
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   F.4       Security of Composite Cipher Modes                          104
-   F.5       Denial of Service                                           105
-   F.6.      Final notes                                                 105
-
-
-Change history
-
-   18-Feb-06   First draft by ekr@rtfm.com
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-1.1 Differences from TLS 1.1
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-     - Merged in TLS Extensions and AES Cipher Suites from external
-     documents.
-
-     - Replacement of MD5/SHA-1 combination in the PRF
-
-     - Replacement of MD5/SHA-1 combination in the digitally-signed
-     element.
-
-     - Allow the client to indicate which hash functions it supports.
-
-     - Allow the server to indicate which has functions it supports
-
-1.1 Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       successfully exchange cryptographic parameters without knowledge
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down prior versions. This document
-   is intended primarily for readers who will be implementing the
-   protocol and those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively. A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification. Cryptographic keys
-   are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, the output of the chosen hash function is encoded as
-   a PKCS #1 DigestInfo and then signed using block type 01 as described
-   in Section 8.1 as described in [PKCS1A].
-
-   Note: the standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
-   However, to minimize differences with TLS 1.0 text, we are using the
-   terminology of RFC 2313 [PKCS1A].
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1A].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by applying P_hash to the secret S. The hash
-   function used in P MUST be the same hash function selected for the
-   HMAC in the cipher suite.
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.1). All such
-   values must be defined by RFC 2434 Standards Action.  See section 11
-   for IANA Considerations for ContentType values.
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it. Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block or stream cipher, the block size of
-       the cipher (if appropriate).
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever the necessary state information
-       is to allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.2, which uses the version { 3, 3 }. The
-       version value 3.3 is historical, deriving from the use of 3.1 for
-       TLS 1.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved.  Application data is generally of lower precedence
-       for transmission than other content types.  However, records MUST
-       be delivered to the network in the same order as they are
-       protected by the record layer.  Recipients MUST receive and
-       process interleaved application layer traffic during handshakes
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       subsequent to the first one on a connection.
-
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-       IV in order to prevent the attacks described by [CBCATT].
-       We recommend the following equivalently strong procedures.
-       For clarity we use the following notation.
-
-       IV -- the transmitted value of the IV field in the
-           GenericBlockCipher structure.
-       CBC residue -- the last ciphertext block of the previous record
-       mask -- the actual value which the cipher XORs with the
-           plaintext prior to encryption of the first cipher block
-           of the record.
-
-       In prior versions of TLS, there was no IV field and the CBC residue
-       and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
-       of [TLS1.0] for details of TLS 1.0 IV handling.
-
-       One of the following two algorithms SHOULD be used to generate the
-       per-record IV:
-
-       (1) Generate a cryptographically strong random string R of
-           length CipherSpec.block_length. Place R
-           in the IV field. Set the mask to R. Thus, the first
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-           cipher block will be encrypted as E(R XOR Data).
-
-       (2) Generate a cryptographically strong random number R of
-           length CipherSpec.block_length and prepend it to the plaintext
-           prior to encryption. In
-           this case either:
-
-           (a)   The cipher may use a fixed mask such as zero.
-           (b) The CBC residue from the previous record may be used
-               as the mask. This preserves maximum code compatibility
-            with TLS 1.0 and SSL 3. It also has the advantage that
-            it does not require the ability to quickly reset the IV,
-            which is known to be a   problem on some systems.
-
-            In either 2(a) or 2(b) the data (R || data) is fed into the
-            encryption process. The first cipher block (containing
-            E(mask XOR R) is placed in the IV field. The first
-            block of content contains E(IV XOR data)
-
-       The following alternative procedure MAY be used: However, it has
-       not been demonstrated to be equivalently cryptographically strong
-       to the above procedures. The sender prepends a fixed block F to
-       the plaintext (or alternatively a block generated with a weak
-       PRNG). He then encrypts as in (2) above, using the CBC residue
-       from the previous block as the mask for the prepended block. Note
-       that in this case the mask for the first record transmitted by
-       the application (the Finished) MUST be generated using a
-       cryptographically strong PRNG.
-
-       The decryption operation for all three alternatives is the same.
-       The receiver decrypts the entire GenericBlockCipher structure and
-       then discards the first cipher block, corresponding to the IV
-       component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes long, as long as it
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes (this does not
-          include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
-       timing attack on CBC padding based on the time required to
-       compute the MAC. In order to defend against this attack,
-       implementations MUST ensure that record processing time is
-       essentially the same whether or not the padding is correct.  In
-       general, the best way to to do this is to compute the MAC even if
-       the padding is incorrect, and only then reject the packet. For
-       instance, if the pad appears to be incorrect the implementation
-       might assume a zero-length pad and then compute the MAC. This
-       leaves a small timing channel, since MAC performance depends to
-       some extent on the size of the data fragment, but it is not
-       believed to be large enough to be exploitable due to the large
-       block size of existing MACs and the small size of the timing
-       signal.
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, which are generated from the master secret in
-   that order. Unused values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-
-   Implementation note:
-       The currently defined which requires the most material is
-       AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
-       keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key
-       material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols which are used to allow peers to agree
-       upon security parameters for the record layer, authenticate
-       themselves, instantiate negotiated security parameters, and
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [X509] certificate of the peer. This element of the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the hash_size. (See
-         Appendix A.6 for formal definition)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.11
-
- Note: if a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g. if it has to perform a time consuming public
-   key operation). Thus, a small window of time during which the
-   recipient must buffer the data MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           unsupported_extension(110),           /* new */
-           certificate_unobtainable(111),        /* new */
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-           unrecognized_name(112),               /* new */
-           bad_certificate_status_response(113), /* new */
-           bad_certificate_hash_value(114),      /* new */
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed
-       This alert MAY be returned if a TLSCiphertext decrypted in an
-       invalid way: either it wasn't an even multiple of the block
-       length, or its padding values, when checked, weren't correct.
-       This message is always fatal.
-
-       Note: Differentiating between bad_record_mac and
-       decryption_failed alerts may permit certain attacks against CBC
-       mode as used in TLS [CBCATT]. It is preferable to uniformly use
-       the bad_record_mac alert to hide the specific type of the error.
-
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not in TLS. It should not be
-       sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   export_restriction_RESERVED
-       This alert was used in TLS 1.0 but not TLS 1.1.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-       The following error alerts apply only to the extensions described
-       in Section XXX. To avoid "breaking" existing clients and servers,
-       these alerts MUST NOT be sent unless the sending party has
-       received an extended hello message from the party they are
-       communicating with.
-
-   unsupported_extension
-       sent by clients that receive an extended server hello containing
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       an extension that they did not put in the corresponding client
-       hello (see Section 2.3).  This message is always fatal.
-
-   unrecognized_name
-       sent by servers that receive a server_name extension request, but
-       do not recognize the server name.  This message MAY be fatal.
-
-   certificate_unobtainable
-       sent by servers who are unable to retrieve a certificate chain
-       from the URL supplied by the client (see Section 3.3).  This
-       message MAY be fatal - for example if client authentication is
-       required by the server for the handshake to continue and the
-       server is unable to retrieve the certificate chain, it may send a
-       fatal alert.
-
-   bad_certificate_status_response
-       sent by clients that receive an invalid certificate status
-       response (see Section 3.6).  This message is always fatal.
-
-   bad_certificate_hash_value
-       sent by servers when a certificate hash does not match a client
-       provided certificate_hash.  This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New alerts values MUST be defined by RFC 2434 Standards Action. See
-   Section 11 for IANA Considerations for alert values.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   However, you SHOULD never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               CertificateStatus*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      CertificateURL*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), certificate_url(21), certificate_status(22),
-        (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-               case certificate_url:     CertificateURL;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-               case certificate_status:  CertificateStatus;
-           } body;
-       } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message type values MUST be defined via RFC 2434
-   Standards Action. See Section 11 for IANA Considerations for these
-   values.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes which are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   If the client wishes to use extensions (see Section XXX),
-   it may send an ExtendedClientHello:
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-           Extension client_hello_extension_list<0..2^16-1>;
-       } ExtendedClientHello;
-
-   These two messages can be distinguished by determining whether there
-   are bytes following what would be the end of the ClientHello.
-
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-       client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   client_hello_extension_list
-       Clients MAY request extended functionality from servers by
-       sending data in the client_hello_extension_list.  Here the new
-       "client_hello_extension_list" field contains a list of
-       extensions.  The actual "Extension" format is defined in Section
-       XXX.
-
-       In the event that a client requests additional functionality
-       using the extended client hello, and this functionality is not
-       supplied by the server, the client MAY abort the handshake.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       A server that supports the extensions mechanism MUST accept only
-       client hello messages in either the original or extended
-       ClientHello ormat, and (as for all other messages) MUST check
-       that the amount of data in the message precisely matches one of
-       these formats; if not then it MUST send a fatal "decode_error"
-       alert.
-
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-   The server will send this message in response to a client hello
-   message when it was able to find an acceptable set of algorithms. If
-   it cannot find such a match, it will respond with a handshake failure
-   alert.
-
-   Structure of this message:
-   struct {
-       ProtocolVersion server_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suite;
-       CompressionMethod compression_method;
-   } ServerHello;
-
-   If the server is sending an extension, it should use the
-   ExtendedServerHello:
-
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-           CompressionMethod compression_method;
-        Extension server_hello_extension_list<0..2^16-1>;
-       } ExtendedServerHello;
-
-   These two messages can be distinguished by determining whether there
-   are bytes following what would be the end of the ServerHello.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   server_version
-   This field will contain the lower of that suggested by the client in
-   the client hello and the highest supported by the server. For this
-   version of the specification, the version is 3.2 (See Appendix E for
-   details about backward compatibility).
-
-   random
-   This structure is generated by the server and MUST be independently
-   generated from the ClientHello.random.
-
-   session_id
-   This is the identity of the session corresponding to this connection.
-   If the ClientHello.session_id was non-empty, the server will look in
-   its session cache for a match. If a match is found and the server is
-   willing to establish the new connection using the specified session
-   state, the server will respond with the same value as was supplied by
-   the client. This indicates a resumed session and dictates that the
-   parties must proceed directly to the finished messages. Otherwise
-   this field will contain a different value identifying the new
-   session. The server may return an empty session_id to indicate that
-   the session will not be cached and therefore cannot be resumed. If a
-   session is resumed, it must be resumed using the same cipher suite it
-   was originally negotiated with.
-
-   cipher_suite
-   The single cipher suite selected by the server from the list in
-   ClientHello.cipher_suites. For resumed sessions this field is the
-   value from the state of the session being resumed.
-
-   compression_method
-   The single compression algorithm selected by the server from the list
-   in ClientHello.compression_methods. For resumed sessions this field
-   is the value from the resumed session state.
-
-   server_hello_extension_list
-   A list of extensions. Note that only extensions offered by the client
-   can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format for extended client hellos and extended server
-   hellos is:
-
-         struct {
-             ExtensionType extension_type;
-             opaque extension_data<0..2^16-1>;
-         } Extension;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Here:
-
-     - "extension_type" identifies the particular extension type.
-
-     - "extension_data" contains information specific to the particular
-   extension type.
-
-   The extension types defined in this document are:
-
-         enum {
-             server_name(0), max_fragment_length(1),
-             client_certificate_url(2), trusted_ca_keys(3),
-             truncated_hmac(4), status_request(5),
-          cert_hash_types(6), (65535)
-         } ExtensionType;
-
-   The list of defined extension types is maintained by the IANA. The
-   current list can be found at XXX (suggest
-   http://www.iana.org/assignments/tls-extensions). See sections XXX and
-   YYY for more information on how new values are added.
-
-
-   Note that for all extension types (including those defined in
-   future), the extension type MUST NOT appear in the extended server
-   hello unless the same extension type appeared in the corresponding
-   client hello.  Thus clients MUST abort the handshake if they receive
-   an extension type in the extended server hello that they did not
-   request in the associated (extended) client hello.
-
-   Nonetheless "server oriented" extensions may be provided in the
-   future within this framework - such an extension, say of type x,
-   would require the client to first send an extension of type x in the
-   (extended) client hello with empty extension_data to indicate that it
-   supports the extension type. In this case the client is offering the
-   capability to understand the extension type, and the server is taking
-   the client up on its offer.
-
-   Also note that when multiple extensions of different types are
-   present in the extended client hello or the extended server hello,
-   the extensions may appear in any order.  There MUST NOT be more than
-   one extension of the same type.
-
-   An extended client hello may be sent both when starting a new session
-   and when requesting session resumption.  Indeed a client that
-   requests resumption of a session does not in general know whether the
-   server will accept this request, and therefore it SHOULD send an
-   extended client hello if it would normally do so for a new session.
-   In general the specification of each extension type must include a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   discussion of the effect of the extension both during new sessions
-   and during resumed sessions.
-
-   Note also that all the extensions defined in this document are
-   relevant only when a session is initiated. When a client includes one
-   or more of the defined extension types in an extended client hello
-   while requesting session resumption:
-
-     - If the resumption request is denied, the use of the extensions
-       is negotiated as normal.
-
-     - If, on the other hand, the older session is resumed, then the
-       server MUST ignore the extensions and send a server hello
-       containing none of the extension types; in this case the
-       functionality of these extensions negotiated during the original
-       session initiation is applied to the resumed session.
-
-7.4.1.4.1 Server Name Indication
-
-   [TLS1.1] does not provide a mechanism for a client to tell a server
-   the name of the server it is contacting.  It may be desirable for
-   clients to provide this information to facilitate secure connections
-   to servers that host multiple 'virtual' servers at a single
-   underlying network address.
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-         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;
-
-   Currently the only server names supported are DNS hostnames, however
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   this does not imply any dependency of TLS on DNS, and other name
-   types may be added in the future (by an RFC that Updates this
-   document).  TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client. The hostname is represented as a byte
-   string using UTF-8 encoding [UTF8], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in section 3.1
-   of [IDNA] notwithstanding). If the server needs to match the HostName
-   against names that contain non-US-ASCII characters, it MUST perform
-   the conversion operation described in section 4 of [IDNA], treating
-   the HostName as a "query string" (i.e. the AllowUnassigned flag MUST
-   be set). Note that IDNA allows labels to be separated by any of the
-   Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore
-   servers MUST accept any of these characters as a label separator.  If
-   the server only needs to match the HostName against names containing
-   exclusively ASCII characters, it MUST compare ASCII names case-
-   insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".  It
-   is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension, MAY use the information contained in the extension to
-   guide its selection of an appropriate certificate to return to the
-   client, and/or other aspects of security policy.  In this event, the
-   server SHALL include an extension of type "server_name" in the
-   (extended) server hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol, then upgrades to TLS, and a server_name extension is sent,
-   then the extension SHOULD contain the same name that was negotiated
-   in the application protocol.  If the server_name is established in
-   the TLS session handshake, the client SHOULD NOT attempt to request a
-   different server name at the application layer.
-
-7.4.1.4.2 Maximum Fragment Length Negotiation
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   By default, TLS uses fixed maximum plaintext fragment length of 2^14
-   bytes.  It may be desirable for constrained clients to negotiate a
-   smaller maximum fragment length due to memory limitations or
-   bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain:
-
-         enum{
-             2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-         } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length.  The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension, MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL contain
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert.  Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent.  Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [TLS] section 6.2.1).  Note that the output
-   of the record layer may be larger.  For example, if the negotiated
-   length is 2^9=512, then for currently defined cipher suites and when
-   null compression is used, the record layer output can be at most 793
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes
-   of padding, and 20 bytes of MAC.  That means that in this event a TLS
-   record layer peer receiving a TLS record layer message larger than
-   793 bytes may discard the message and send a "record_overflow" alert,
-   without decrypting the message.
-
-7.4.1.4.3 Client Certificate URLs
-
-   Ordinarily, when client authentication is performed, client
-   certificates are sent by clients to servers during the TLS handshake.
-   It may be desirable for constrained clients to send certificate URLs
-   in place of certificates, so that they do not need to store their
-   certificates and can therefore save memory.
-
-   In order to negotiate to send certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-   (extended) client hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS 1.0 servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension, MAY indicate that they are
-   willing to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message.  See
-   Section XXX.
-
-7.4.1.4.4 Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys, may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-         struct {
-             TrustedAuthority trusted_authorities_list<0..2^16-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-         } TrustedAuthorities;
-
-         struct {
-             IdentifierType identifier_type;
-             select (identifier_type) {
-                 case pre_agreed: struct {};
-                 case key_sha1_hash: SHA1Hash;
-                 case x509_name: DistinguishedName;
-                 case cert_sha1_hash: SHA1Hash;
-             } identifier;
-         } TrustedAuthority;
-
-         enum {
-             pre_agreed(0), key_sha1_hash(1), x509_name(2),
-             cert_sha1_hash(3), (255)
-         } IdentifierType;
-
-         opaque DistinguishedName<1..2^16-1>;
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses.  Each CA root key is identified via
-   either:
-
-     -  "pre_agreed" - no CA root key identity supplied.
-
-     -  "key_sha1_hash" - contains the SHA-1 hash of the CA root key.
-   For
-       DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
-       value.  For RSA keys, the hash is of the big-endian byte string
-       representation of the modulus without any initial 0-valued bytes.
-       (This copies the key hash formats deployed in other
-       environments.)
-
-     -  "x509_name" - contains the DER-encoded X.509 DistinguishedName
-       of
-       the CA.
-
-     -  "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded
-       Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer - for example if
-   a particular CA has multiple key pairs - however here we assume this
-   is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension, MAY use the information contained in the extension to
-   guide their selection of an appropriate certificate chain to return
-   to the client.  In this event, the server SHALL include an extension
-   of type "trusted_ca_keys" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-7.4.1.4.5 Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [HMAC] to authenticate record layer
-   communications.  In TLS the entire output of the hash function is
-   used as the MAC tag.  However it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-   include an extension of type "truncated_hmac" in the extended client
-   hello.  The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension, MAY agree to use a truncated HMAC by including an
-   extension of type "truncated_hmac", with empty "extension_data", in
-   the extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect.  It is strongly recommended that any new cipher
-   suites using other MACs consider the MAC size as an integral part of
-   the cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters.  Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [HMAC].  That is, CipherSpec.hash_size is 10 bytes, and
-   only the first 10 bytes of the HMAC output are transmitted and
-   checked.  Note that this extension does not affect the calculation of
-   the PRF as part of handshaking or key derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-7.4.1.4.6 Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [OCSP] to check the validity of server certificates, in
-   order to avoid transmission of CRLs and therefore save bandwidth on
-   constrained networks.  This extension allows for such information to
-   be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "CertificateStatusRequest" where:
-
-         struct {
-             CertificateStatusType status_type;
-             select (status_type) {
-                 case ocsp: OCSPStatusRequest;
-             } request;
-         } CertificateStatusRequest;
-
-         enum { ocsp(1), (255) } CertificateStatusType;
-
-         struct {
-             ResponderID responder_id_list<0..2^16-1>;
-             Extensions  request_extensions;
-         } OCSPStatusRequest;
-
-         opaque ResponderID<1..2^16-1>;
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts.  A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server - e.g., by prior arrangement.  "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [OCSP].  "Extensions" is imported from [PKIX].  A zero-
-   length "request_extensions" value means that there are no extensions
-   (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
-   the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Servers that receive a client hello containing the "status_request"
-   extension, MAY return a suitable certificate status response to the
-   client along with their certificate.  If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder, and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages). Section XXX describes the
-   CertificateStatus message.
-
-7.4.1.4.7 Cert Hash Types
-
-   The client MAY use the "cert_hash_types" to indicate to the server
-   which hash functions may be used in the signature on the server's
-   certificate. The "extension_data" field of this extension contains:
-
-         enum{
-             md5(0), sha1(1), sha256(2), sha512(3), (255)
-         } HashType;
-
-         struct {
-               HashType<255> types;
-         } CertHashTypes;
-
-   These values indicate support for MD5 [MD5], SHA-1, SHA-256, and
-   SHA-512 [SHA] respectively. The server MUST NOT send this extension.
-
-   Clients SHOULD send this extension if they support any algorithm
-   other than SHA-1. If this extension is not used, servers SHOULD
-   assume that the client supports only SHA-1. Note: this is a change
-   from TLS 1.1 where there are no explicit rules but as a practical
-   matter one can assume that the peer supports MD5 and SHA-1.
-
- HashType values are divided into three groups:
-
-      1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-         reserved for IETF Standards Track protocols.
-
-      2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
-         are reserved for assignment for non-Standards Track methods.
-
-      3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-         inclusive are reserved for private use.
-
-   Additional information describing the role of IANA in the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   allocation of HashType code points is described
-   in Section 11.
-
-
-7.4.1.4.8 Procedure for Defining New Extensions
-
-   The list of extension types, as defined in Section 2.3, is
-   maintained by the Internet Assigned Numbers Authority (IANA). Thus
-   an application needs to be made to the IANA in order to obtain a new
-   extension type value. Since there are subtle (and not so subtle)
-   interactions that may occur in this protocol between new features and
-   existing features which may result in a significant reduction in
-   overall security, new values SHALL be defined only through the IETF
-   Consensus process specified in [IANA].
-
-   (This means that new assignments can be made only via RFCs approved
-   by the IESG.)
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-     -  All of the extensions defined in this document follow the
-       convention that for each extension that a client requests and that
-       the server understands, the server replies with an extension of
-       the same type.
-
-     -  Some cases where a server does not agree to an extension are error
-       conditions, and some simply a refusal to support a particular
-       feature.  In general error alerts should be used for the former,
-       and a field in the server extension response for the latter.
-
-     -  Extensions should as far as possible be designed to prevent any
-       attack that forces use (or non-use) of a particular feature by
-       manipulation of handshake messages.  This principle should be
-       followed regardless of whether the feature is believed to cause a
-       security problem.
-
-       Often the fact that the extension fields are included in the
-       inputs to the Finished message hashes will be sufficient, but
-       extreme care is needed when the extension changes the meaning of
-       messages sent in the handshake phase. Designers and implementors
-       should be aware of the fact that until the handshake has been
-       authenticated, active attackers can modify messages and insert,
-       remove, or replace extensions.
-
-     -  It would be technically possible to use extensions to change major
-       aspects of the design of TLS; for example the design of cipher
-       suite negotiation.  This is not recommended; it would be more
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       appropriate to define a new version of TLS - particularly since
-       the TLS handshake algorithms have specific protection against
-       version rollback attacks based on the version number, and the
-       possibility of version rollback should be a significant
-       consideration in any major design change.
-
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will
-       always immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-       certificate. It MUST contain a key which matches the key
-       exchange method, as follows. Unless otherwise specified, the
-       signing
-       algorithm for the certificate MUST be the same as the
-       algorithm for the certificate key. Unless otherwise specified,
-       the public key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit MUST be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   MUST be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-   As CipherSuites which specify new key exchange methods are specified
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-   If the SignatureAlgorithm being used to sign the ServerKeyExchange
-   message is DSA, the hash function used MUST be SHA-1. If the
-   SignatureAlgorithm it must be the same hash function used in the
-   signature of the server's certificate (found in the Certificate)
-   message. This algorithm is denoted Hash below. Hash.length is the
-   length of the output of that algorithm.
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-               case rsa:
-                   ServerRSAParams params;
-           };
-        } ServerParams;
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       hash
-           Hash(ClientHello.random + ServerHello.random + ServerParams)
-
-       sha_hash
-           SHA1(ClientHello.random + ServerHello.random + ServerParams)
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       struct {
-           select (SignatureAlgorithm) {
-               case anonymous: struct { };
-               case rsa:
-                   digitally-signed struct {
-                 opaque hash[Hash.length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-                   };
-               case dsa:
-                   digitally-signed struct {
-                       opaque sha_hash[20];
-                   };
-               };
-           };
-       } Signature;
-
-7.4.4. CertificateStatus
-
-   If a server returns a
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-         struct {
-             CertificateStatusType status_type;
-             select (status_type) {
-                 case ocsp: OCSPResponse;
-             } response;
-         } CertificateStatus;
-
-         opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [OCSP]).  Note that
-   only one OCSP response may be sent.
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response, and receiving an OCSP response
-   in a "CertificateStatus" message MUST check the OCSP response and
-   abort the handshake if the response is not satisfactory.
-
-
-7.4.5. Certificate request
-
-   When this message will be sent:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-        fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-        HashType certificate_hash<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_types
-           A list of the types of certificate types which the client may
-           offer.
-              rsa_sign        a certificate containing an RSA key
-              dss_sign        a certificate containing a DSS key
-              rsa_fixed_dh    a certificate signed with RSA and containing
-                        a static DH key.
-              dss_fixed_dh    a certificate signed with DSS and containing
-                        a static DH key
-
-           Certificate types rsa_sign and dss_sign SHOULD contain
-           certificates signed with the same algorithm. However, this is
-           not required. This is a holdover from TLS 1.0 and 1.1.
-
-
-       certificate_hash
-           A list of acceptable hash algorithms to be used in
-           certificate signatures.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
-
- ClientCertificateType values are divided into three groups:
-
-              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-                 reserved for IETF Standards Track protocols.
-
-              2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
-                 inclusive are reserved for assignment for non-Standards
-                 Track methods.
-
-              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-                 inclusive are reserved for private use.
-
-           Additional information describing the role of IANA in the
-           allocation of ClientCertificateType code points is described
-           in Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were used in
-           SSLv3.
-
-
- Note: DistinguishedName is derived from [X501]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.6. Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       Upon receipt of the server hello done message the client SHOULD
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.7. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client SHOULD send a certificate message
-       containing no certificates. That is, the certificate_list
-       structure has a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate MUST match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.8. Client Certificate URLs
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message.
-
-         enum {
-             individual_certs(0), pkipath(1), (255)
-         } CertChainType;
-
-         enum {
-             false(0), true(1)
-         } Boolean;
-
-         struct {
-             CertChainType type;
-             URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-         } CertificateURL;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-         struct {
-             opaque url<1..2^16-1>;
-             Boolean hash_present;
-             select (hash_present) {
-                 case false: struct {};
-                 case true: SHA1Hash;
-             } hash;
-         } URLAndOptionalHash;
-
-         opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-   When X.509 certificates are used, there are two possibilities:
-
-     -  if CertificateURL.type is "individual_certs", each URL refers to
-       a single DER-encoded X.509v3 certificate, with the URL for the
-       client's certificate first, or
-
-     -  if CertificateURL.type is "pkipath", the list contains a single
-       URL referring to a DER-encoded certificate chain, using the type
-       PkiPath described in Section 8.
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion is
-   either not present or is the SHA-1 hash of the certificate or
-   certificate chain (in the case of X.509 certificates, the DER-encoded
-   certificate or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [TLS] Section 7.4.2), but opposite to the order in which
-   certificates are encoded in PkiPath.  In either case, the self-signed
-   root certificate MAY be omitted from the chain, under the assumption
-   that the server must already possess it in order to validate it.
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs, and then process the
-   certificate chain as usual.  A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   for certificate URLs, and MAY support other schemes. Use of other
-   schemes than "http", "https", or "ftp" may create unexpected
-   problems.
-
-   If the protocol used is HTTP, then the HTTP server can be configured
-   to use the Cache-Control and Expires directives described in [HTTP]
-   to specify whether and for how long certificates or certificate
-   chains should be cached.
-
-   The TLS server is not required to follow HTTP redirects when
-   retrieving the certificates or certificate chain.  The URLs used in
-   this extension SHOULD therefore be chosen not to depend on such
-   redirects.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
-   when a chain of X.509v3 certificates is returned, the Content-Type is
-   "application/pkix-pkipath" (see Section XXX).
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash.  If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs. The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-7.4.9. Client key exchange message
-
-   When this message will be sent:
-   This message is always sent by the client. It MUST immediately follow
-   the client certificate message, if it is sent. Otherwise it MUST be
-   the first message sent by the client after it receives the server
-   hello done message.
-
-   Meaning of this message:
-   With this message, the premaster secret is set, either though direct
-   transmission of the RSA-encrypted secret, or by the transmission of
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Diffie-Hellman parameters which will allow each side to agree upon
-   the same premaster secret. When the key exchange method is DH_RSA or
-   DH_DSS, client certification has been requested, and the client was
-   able to respond with a certificate which contained a Diffie-Hellman
-   public key whose parameters (group and generator) matched those
-   specified by the server in its certificate, this message MUST not
-   contain any data.
-
-   Structure of this message:
-   The choice of messages depends on which key exchange method has been
-   selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition.
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa: EncryptedPreMasterSecret;
-           case diffie_hellman: ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-7.4.9.1. RSA encrypted premaster secret message
-
-   Meaning of this message:
-   If RSA is being used for key agreement and authentication, the client
-   generates a 48-byte premaster secret, encrypts it using the public
-   key from the server's certificate or the temporary RSA key provided
-   in a server key exchange message, and sends the result in an
-   encrypted premaster secret message. This structure is a variant of
-   the client key exchange message, not a message in itself.
-
-   Structure of this message:
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   } PreMasterSecret;
-
-   client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 v 1.5 encoded RSA.
-       The attack takes advantage of the fact that by failing in
-       different ways, a TLS server can be coerced into revealing
-       whether a particular message, when decrypted, is properly PKCS#1
-       v1.5 formatted or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
-       [PKCS1B] defines a newer version of PKCS#1 encoding that is more
-       secure against the Bleichenbacher attack. However, for maximal
-       compatibility with TLS 1.0, TLS 1.1 retains the original
-       encoding. No variants of the Bleichenbacher attack are known to
-       exist provided that the above recommendations are followed.
-
- Implementation Note: public-key-encrypted data is represented as an
-       opaque vector <0..2^16-1> (see section 4.7). Thus the RSA-
-       encrypted PreMasterSecret in a ClientKeyExchange is preceded by
-       two length bytes. These bytes are redundant in the case of RSA
-       because the EncryptedPreMasterSecret is the only data in the
-       ClientKeyExchange and its length can therefore be unambiguously
-       determined. The SSLv3 specification was not clear about the
-       encoding of public-key-encrypted data and therefore many SSLv3
-       implementations do not include the the length bytes, encoding the
-       RSA encrypted data directly in the ClientKeyExchange message.
-
-       This specification requires correct encoding of the
-       EncryptedPreMasterSecret complete with length bytes. The
-       resulting PDU is incompatible with many SSLv3 implementations.
-       Implementors upgrading from SSLv3 must modify their
-       implementations to generate and accept the correct encoding.
-       Implementors who wish to be compatible with both SSLv3 and TLS
-       should make their implementation's behavior dependent on the
-       protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-       on SSL are possible, at least when the client and server are on
-       the same LAN. Accordingly, implementations which use static RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       keys SHOULD use RSA blinding or some other anti-timing technique,
-       as described in [TIMING].
-
- Note: The version number in the PreMasterSecret MUST be the version
-       offered by the client in the ClientHello, not the version
-       negotiated for the connection. This feature is designed to
-       prevent rollback attacks. Unfortunately, many implementations use
-       the negotiated version instead and therefore checking the version
-       number may lead to failure to interoperate with such incorrect
-       client implementations. Client implementations MUST and Server
-       implementations MAY check the version number. In practice, since
-       the TLS handshake MACs prevent downgrade and no good attacks are
-       known on those MACs, ambiguity is not considered a serious
-       security risk.  Note that if servers choose to to check the
-       version number, they should randomize the PreMasterSecret in case
-       of error, rather than generate an alert, in order to avoid
-       variants on the Bleichenbacher attack. [KPR03]
-
-7.4.9.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-7.4.10. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3. If the SignatureAlgorithm
-       is DSA, then the sha_hash value must be used. If it is RSA,
-       the same function (denoted Hash) must be used as was used to
-       create the signature for the client's certificate.
-
-       CertificateVerify.signature.hash
-           Hash(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.10. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, MD5(handshake_messages) +
-           SHA-1(handshake_messages)) [0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.10 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. IANA Considerations
-
-   This document describes a number of new registries to be created by
-   IANA. We recommend that they be placed as individual registries items
-   under a common TLS category.
-
-   Section 7.4.5 describes a TLS HashType Registry to be maintained by
-   the IANA, as defining a number of such code point identifiers.
-   HashType identifiers with values in the range 0-63 (decimal)
-   inclusive are assigned via RFC 2434 Standards Action. Values from the
-   range 64-223 (decimal) inclusive are assigned via [RFC 2434]
-   Specification Required.  Identifier values from 224-255 (decimal)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   inclusive are reserved for RFC 2434 Private Use. The registry will be
-   initially populated with the values in this document, Section 7.4.5.
-
-   Section 7.4.5 describes a TLS ClientCertificateType Registry to be
-   maintained by the IANA, as defining a number of such code point
-   identifiers. ClientCertificateType identifiers with values in the
-   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action. Values from the range 64-223 (decimal) inclusive are assigned
-   via [RFC 2434] Specification Required.  Identifier values from
-   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
-   The registry will be initially populated with the values in this
-   document, Section 7.4.5.
-
-   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
-   the IANA, as well as defining a number of such cipher suite
-   identifiers. Cipher suite values with the first byte in the range
-   0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
-   Values with the first byte in the range 192-254 (decimal) are
-   assigned via RFC 2434 Specification Required. Values with the first
-   byte 255 (decimal) are reserved for RFC 2434 Private Use. The
-   registry will be initially populated with the values from Section A.5
-   of this document, [TLSAES], and Section 3 of [TLSKRB].
-
-   Section 6 requires that all ContentType values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS ContentType registry,
-   initially populated with values from Section 6.2.1 of this document.
-   Future values MUST be allocated via Standards Action as described in
-   [RFC 2434].
-
-   Section 7.2.2 requires that all Alert values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS Alert registry, initially
-   populated with values from Section 7.2 of this document and Section 4
-   of [TLSEXT]. Future values MUST be allocated via Standards Action as
-   described in [RFC 2434].
-
-   Section 7.4 requires that all HandshakeType values be defined by RFC
-   2434 Standards Action. IANA SHOULD create a TLS HandshakeType
-   registry, initially populated with values from Section 7.4 of this
-   document and Section 2.4 of [TLSEXT].  Future values MUST be
-   allocated via Standards Action as described in [RFC2434].
-
-
-11.1 Extensions
-
-   Sections XXX and XXX describes a registry of ExtensionType values to
-   be maintained by the IANA. ExtensionType values are to be assigned
-   via IETF Consensus as defined in RFC 2434 [IANA]. The initial
-   registry corresponds to the definition of "ExtensionType" in Section
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   2.3.
-
-   The MIME type "application/pkix-pkipath" has been registered by the
-   IANA with the following template:
-
-      To: ietf-types@iana.org Subject: Registration of MIME media type
-      application/pkix-pkipath
-
-      MIME media type name: application
-      MIME subtype name: pkix-pkipath
-
-      Optional parameters: version (default value is "1")
-
-      Encoding considerations:
-         This MIME type is a DER encoding of the ASN.1 type PkiPath,
-         defined as follows:
-           PkiPath ::= SEQUENCE OF Certificate
-           PkiPath is used to represent a certification path.  Within the
-           sequence, the order of certificates is such that the subject of
-           the first certificate is the issuer of the second certificate,
-           etc.
-
-         This is identical to the definition published in [X509-4th-TC1];
-         note that it is different from that in [X509-4th].
-
-         All Certificates MUST conform to [PKIX].  (This should be
-         interpreted as a requirement to encode only PKIX-conformant
-         certificates using this type.  It does not necessarily require
-         that all certificates that are not strictly PKIX-conformant must
-         be rejected by relying parties, although the security consequences
-         of accepting any such certificates should be considered
-         carefully.)
-
-         DER (as opposed to BER) encoding MUST be used.  If this type is
-         sent over a 7-bit transport, base64 encoding SHOULD be used.
-
-      Security considerations:
-         The security considerations of [X509-4th] and [PKIX] (or any
-         updates to them) apply, as well as those of any protocol that uses
-         this type (e.g., TLS).
-
-         Note that this type only specifies a certificate chain that can be
-         assessed for validity according to the relying party's existing
-         configuration of trusted CAs; it is not intended to be used to
-         specify any change to that configuration.
-
-      Interoperability considerations:
-         No specific interoperability problems are known with this type,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-         but for recommendations relating to X.509 certificates in general,
-         see [PKIX].
-
-      Published specification: this memo, and [PKIX].
-
-      Applications which use this media type: TLS.  It may also be used by
-         other protocols, or for general interchange of PKIX certificate
-
-      Additional information:
-         Magic number(s): DER-encoded ASN.1 can be easily recognized.
-           Further parsing is required to distinguish from other ASN.1
-           types.
-         File extension(s): .pkipath
-         Macintosh File Type Code(s): not specified
-
-      Person & email address to contact for further information:
-         Magnus Nystrom <magnus@rsasecurity.com>
-
-      Intended usage: COMMON
-
-      Change controller:
-         IESG <iesg@ietf.org>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            unsupported_extension(110),           /* new */
-            certificate_unobtainable(111),        /* new */
-            unrecognized_name(112),               /* new */
-            bad_certificate_status_response(113), /* new */
-            bad_certificate_hash_value(114),      /* new */
-            (255)
-        } AlertDescription;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), certificate_url(21), certificate_status(22),
-     (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-            case certificate_url:     CertificateURL;
-            case certificate_status:  CertificateStatus;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-        Extension client_hello_extension_list<0..2^16-1>;
-    } ClientHello;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-        Extension client_hello_extension_list<0..2^16-1>;
-    } ExtendedClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-     Extension server_hello_extension_list<0..2^16-1>;
-    } ExtendedServerHello;
-
-    struct {
-        ExtensionType extension_type;
-        opaque extension_data<0..2^16-1>;
-    } Extension;
-
-    enum {
-        server_name(0), max_fragment_length(1),
-        client_certificate_url(2), trusted_ca_keys(3),
-        truncated_hmac(4), status_request(5),
-        cert_hash_types(6), (65535)
-    } ExtensionType;
-
-    struct {
-        NameType name_type;
-        select (name_type) {
-            case host_name: HostName;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-        } name;
-    } ServerName;
-
-    enum {
-        host_name(0), (255)
-    } NameType;
-
-    opaque HostName<1..2^16-1>;
-
-    struct {
-        ServerName server_name_list<1..2^16-1>
-    } ServerNameList;
-
-    enum{
-        2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-    } MaxFragmentLength;
-
-    struct {
-        TrustedAuthority trusted_authorities_list<0..2^16-1>;
-    } TrustedAuthorities;
-
-    struct {
-        IdentifierType identifier_type;
-        select (identifier_type) {
-            case pre_agreed: struct {};
-            case key_sha1_hash: SHA1Hash;
-            case x509_name: DistinguishedName;
-            case cert_sha1_hash: SHA1Hash;
-        } identifier;
-    } TrustedAuthority;
-
-    enum {
-        pre_agreed(0), key_sha1_hash(1), x509_name(2),
-        cert_sha1_hash(3), (255)
-    } IdentifierType;
-
-    struct {
-        CertificateStatusType status_type;
-        select (status_type) {
-            case ocsp: OCSPStatusRequest;
-        } request;
-    } CertificateStatusRequest;
-
-    enum { ocsp(1), (255) } CertificateStatusType;
-
-    struct {
-        ResponderID responder_id_list<0..2^16-1>;
-        Extensions  request_extensions;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-    } OCSPStatusRequest;
-
-     opaque ResponderID<1..2^16-1>;
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    struct {
-        CertificateStatusType status_type;
-        select (status_type) {
-            case ocsp: OCSPResponse;
-        } response;
-    } CertificateStatus;
-
-    opaque OCSPResponse<1..2^24-1>;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque rsa_modulus<1..2^16-1>;
-        opaque rsa_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-            case diffie_hellman:
-                ServerDHParams params;
-            case rsa:
-                ServerRSAParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-            case anonymous: struct { };
-            case rsa:
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-            case dsa:
-                digitally-signed struct {
-                    opaque sha_hash[20];
-                };
-            };
-        };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    enum {
-        individual_certs(0), pkipath(1), (255)
-    } CertChainType;
-
-    enum {
-        false(0), true(1)
-    } Boolean;
-
-    struct {
-        CertChainType type;
-        URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-    } CertificateURL;
-
-    struct {
-        opaque url<1..2^16-1>;
-        Boolean hash_present;
-        select (hash_present) {
-            case false: struct {};
-            case true: SHA1Hash;
-        } hash;
-    } URLAndOptionalHash;
-
-    opaque SHA1Hash[20];
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-    CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x2F };
-    CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x35 };
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-    CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA        = { 0x00, 0x30 };
-    CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA        = { 0x00, 0x31 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x32 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x33 };
-    CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
-    CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA        = { 0x00, 0x36 };
-    CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA        = { 0x00, 0x37 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x38 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x39 };
-    CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks and is
-   therefore deprecated.
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.1 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.1 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.1 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.1 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-
- The cipher suite space is divided into three regions:
-
-       1. Cipher suite values with first byte 0x00 (zero)
-          through decimal 191 (0xBF) inclusive are reserved for the IETF
-          Standards Track protocols.
-
-       2. Cipher suite values with first byte decimal 192 (0xC0)
-          through decimal 254 (0xFE) inclusive are reserved
-          for assignment for non-Standards Track methods.
-
-       3. Cipher suite values with first byte 0xFF are
-          reserved for private use.
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section 11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.
-       AES is
-       a block cipher with a 128, 192, or 256 bit keys and a 16 byte
-       block size. [AES] TLS currently only supports the 128 and 256
-       bit key sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-C. CipherSuite definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_SHA                RSA            AES_256_CBC  SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-the-
-   middle attacks. Applications should also enforce minimum and maximum
-   key sizes. For example, certificate chains containing 512-bit RSA
-   keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-E. Backward Compatibility With SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port: for example, the https protocol (HTTP secured by SSL
-   or TLS) uses port 443 regardless of which security protocol it is
-   using. Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting
-   both is easy. TLS clients who wish to negotiate with such older
-   servers SHOULD send client hello messages using the SSL 3.0 record
-   format and client hello structure, sending {3, 2} for the version
-   field to note that they support TLS 1.1. If the server supports only
-   TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello;
-   if it supports TLS 1.1 it will respond with a TLS 1.1 server hello.
-   The negotiation then proceeds as appropriate for the negotiated
-   protocol.
-
-   Similarly, a TLS 1.1  server which wishes to interoperate with TLS
-   1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages
-   and respond with a SSL 3.0 server hello if an SSL 3.0 client hello
-   with a version field of {3, 0} is received, denoting that this client
-   does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a
-   version field of {3, 1} is received, the server SHOULD respond with a
-   TLS 1.0 hello with a version field of {3, 1}.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors SHOULD make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
- Note: TLS 1.2 clients may generate the SSLv2 EXPORT cipher suites in
-   handshakes for backward compatibility but MUST NOT negotiate them in
-   TLS 1.2 mode.
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification. Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       This field is the length of the following data in bytes. The high
-       bit MUST be 1 and is not part of the length.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 92]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       version 2 client hello message. The value SHOULD be one (1).
-
-   version
-       The highest version of the protocol supported by the client
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. When using the SSLv2 backward compatible
-       handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There MUST be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       This field MUST be empty.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 93]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 94]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.10, 7.4.11 and 6.3). By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 95]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   from the server key exchange message. The result is sent in a client
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate. The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed. Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key. TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites. The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 96]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   the certificate verify message (see Section 7.4.10). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly so the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 97]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Parties
-   concerned about attacks of this scale should not be using 40-bit
-   encryption keys anyway. Altering the padding of the least-significant
-   8 bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 98]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5 Extensions
-
-   Security considerations for the extension mechanism in general, and
-   the design of new extensions, are described in the previous section.
-   A security analysis of each of the extensions defined in this
-   document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art, and address any weaknesses identified.
-
-
-F.1.5.1 Security of server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs.  Apart from this, server_name does not appear
-   to introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS - in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed.  It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-   6.2. Security of max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages.  However, that does not introduce any security
-   complications that are not already present in TLS, since [TLS]
-   requires implementations to be able to handle fragmented handshake
-   messages.
-
-   Note that as described in section XXX, once a non-null cipher suite
-   has been activated, the effective maximum fragment length depends on
-   the cipher suite and compression method, as well as on the negotiated
-   max_fragment_length.  This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 99]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-F.1.5.2 Security of client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes.  The purpose of including
-   hashes and checking them against the retrieved certificate chain, is
-   to ensure that the same property holds when this extension is used -
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances - for example clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client.  Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here.  The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server acting as a client in another URL protocol.  The
-   server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some, possibly weird-looking URL.
-
-   In general this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw.  It also introduces the possibility of denial of service
-   attacks in which an attacker makes many connections to the server,
-   each of which results in the server attempting a connection to the
-   target of the attack.
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet; this could exacerbate the potential security and denial of
-   service problems described above, as well as allowing the existence
-   of internal hosts to be confirmed when they would otherwise be
-   hidden.
-
-   The detailed security concerns involved will depend on the URL
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 100]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   schemes supported by the server.  In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server.  In the case of HTTPS, the possibility for loops and
-   deadlocks to be created exists and should be addressed.  In the case
-   of FTP, attacks similar to FTP bounce attacks arise.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than being enabled by
-   default.  It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled, with unusual protocols offering limited security or whose
-   security is not well-understood being avoided.
-
-   As discussed in [URI], URLs that specify ports other than the default
-   may cause problems, as may very long URLs (which are more likely to
-   be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly.  If a request using HTTP (or another caching protocol)
-   goes through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-F.1.5.4. Security of trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information.  As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously.  As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-F.1.5.5. Security of truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs.  However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-   Note that the output length of a MAC need not be as long as the
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after the handshake
-   messages have been authenticated by the hashes in the Finished
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 101]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   messages, it is not possible for an active attacker to force
-   negotiation of the truncated HMAC extension where it would not
-   otherwise be used (to the extent that the handshake authentication is
-   secure).  Therefore, in the event that any security problem were
-   found with truncated HMAC in future, if either the client or the
-   server for a given session were updated to take into account the
-   problem, they would be able to veto use of this extension.
-
-F.1.5.6. Security of status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension.  A client that requires
-   OCSP validation of certificates SHOULD either contact the OCSP server
-   directly in this case, or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see section 4.4.1 of [OCSP] for further details.
-
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 102]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-F.4 Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information theoretic sense) that combined with any secure MAC
-       function fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message plus the length of the MAC tag is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent and unpredictable, IV for each new pair of plaintext
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 103]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext. This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-F.5 Denial of Service
-
-       TLS is susceptible to a number of denial of service (DoS)
-       attacks.  In particular, an attacker who initiates a large number
-       of TCP connections can cause a server to consume large amounts of
-       CPU doing RSA decryption. However, because TLS is generally used
-       over TCP, it is difficult for the attacker to hide his point of
-       origin if proper TCP SYN randomization is used [SEQNUM] by the
-       TCP stack.
-
-       Because TLS runs over TCP, it is also susceptible to a number of
-       denial of service attacks on individual connections. In
-       particular, attackers can forge RSTs, terminating connections, or
-       forge partial TLS records, causing the connection to stall.
-       These attacks cannot in general be defended against by a TCP-
-       using protocol. Implementors or users who are concerned with this
-       class of attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 104]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-Normative References
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [HTTP]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
-            L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
-            Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [IDNA]    Faltstrom, P., Hoffman, P. and A. Costello,
-            "Internationalizing Domain Names in Applications (IDNA)",
-            RFC 3490, March 2003.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [OCSP]   Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-            Adams, "Internet X.509 Public Key Infrastructure: Online
-            Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
-            RSA Cryptography Specifications Version 1.5", RFC 2313,
-            March 1998.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 105]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIOP]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
-            Infrastructure - Operation Protocols: FTP and HTTP", RFC
-            2585, May 1999.
-
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-            Considerations Section in RFCs", RFC 3434, October 1998.
-
-   [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.
-   [TLSKRB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to
-            Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-
-   [URI]    Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-            Resource Identifiers (URI): Generic Syntax", RFC 2396,
-            August 1998.
-
-   [UTF8]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
-            RFC 3629, November 2003.
-
-   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 106]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-            "Information Systems - Open Systems Interconnection - The
-            Directory:  Public key and Attribute certificate
-            frameworks."
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-            ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
-            ISO/IEC 9594:8:2001.
-
-Informative References
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            2402, November 1998.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 2406, November 1998.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness
-            Recommendations for Security", RFC 1750, December 1994.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 107]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and Rescorla, E., "The TLS Protocol, Version
-            1.1", RFC 4346, April, 2006.
-
-   [X501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
-            Open Systems Interconnection - "The Directory -
-            Authentication Framework". 1988.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, "XDR: External Data
-            Representation Standard", RFC 1832, August 1995.
-
-
-Credits
-
-   Working Group Chairs
-   Eric Rescorla
-   EMail: ekr@rtfm.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 108]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Editors
-
-   Tim Dierks                Eric Rescorla
-   Independent                   Network Resonance, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 109]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-       <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 110]draft-ietf-tls-rfc4346-bis-01.txt  TLS                         June 2006
-
-
-   Intellectual Property Statement
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed to
-      pertain to the implementation or use of the technology described in
-      this document or the extent to which any license under such rights
-      might or might not be available; nor does it represent that it has
-      made any independent effort to identify any such rights.  Information
-      on the procedures with respect to rights in RFC documents can be
-      found in BCP 78 and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use of
-      such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository at
-      http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention any
-      copyrights, patents or patent applications, or other proprietary
-      rights that may cover technology that may be required to implement
-      this standard.  Please address the information to the IETF at
-      ietf-ipr@ietf.org.
-
-
-   Disclaimer of Validity
-
-      This document and the information contained herein are provided on an
-      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-      OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-      ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-      INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-      INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-   Copyright Statement
-
-      Copyright (C) The Internet Society (2006).  This document is subject
-      to the rights, licenses and restrictions contained in BCP 78, and
-      except as set forth therein, the authors retain all their rights.
-
-
-   Acknowledgment
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 111]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-02.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-02.txt
deleted file mode 100644
index 4f869f8905..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-02.txt
+++ /dev/null
@@ -1,6105 +0,0 @@
-
-
-
-                                                              Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                   Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-02.txt>    October 2006 (Expires April 2006)
-
-                            The TLS Protocol
-                              Version 1.2
-
-Status of this Memo
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 (2006).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction                                                4
-   1.1       Differences from TLS 1.1                                    5
-   1.1       Requirements Terminology                                    5
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   2.        Goals                                                       5
-   3.        Goals of this document                                      6
-   4.        Presentation language                                       6
-   4.1.      Basic block size                                            7
-   4.2.      Miscellaneous                                               7
-   4.3.      Vectors                                                     7
-   4.4.      Numbers                                                     8
-   4.5.      Enumerateds                                                 8
-   4.6.      Constructed types                                           9
-   4.6.1.    Variants                                                    10
-   4.7.      Cryptographic attributes                                    11
-   4.8.      Constants                                                   12
-   5.        HMAC and the pseudorandom function                          12
-   6.        The TLS Record Protocol                                     14
-   6.1.      Connection states                                           14
-   6.2.      Record layer                                                17
-   6.2.1.    Fragmentation                                               17
-   6.2.2.    Record compression and decompression                        18
-   6.2.3.    Record payload protection                                   19
-   6.2.3.1.  Null or standard stream cipher                              19
-   6.2.3.2.  CBC block cipher                                            20
-   6.2.3.3.  AEAD ciphers                                                23
-   6.3.      Key calculation                                             24
-   7.        The TLS Handshaking Protocols                               24
-   7.1.      Change cipher spec protocol                                 25
-   7.2.      Alert protocol                                              26
-   7.2.1.    Closure alerts                                              27
-   7.2.2.    Error alerts                                                28
-   7.3.      Handshake Protocol overview                                 31
-   7.4.      Handshake protocol                                          35
-   7.4.1.    Hello messages                                              36
-   7.4.1.1.  Hello request                                               36
-   7.4.1.2.  Client hello                                                37
-   7.4.1.3.  Server hello                                                40
-   7.4.1.4   Hello Extensions                                            41
-   7.4.1.4.1 Server Name Indication                                      43
-   7.4.1.4.2 Maximum Fragment Length Negotiation                         44
-   7.4.1.4.3 Client Certificate URLs                                     46
-   7.4.1.4.4 Trusted CA Indication                                       46
-   7.4.1.4.5 Truncated HMAC                                              48
-   7.4.1.4.6 Certificate Status Request                                  49
-   7.4.1.4.7 Cert Hash Types                                             50
-   7.4.1.4.8 Procedure for Defining New Extensions                       51
-   7.4.2.    Server certificate                                          52
-   7.4.3.    Server key exchange message                                 53
-   7.4.4.    CertificateStatus                                           56
-   7.4.5.    Certificate request                                         56
-   7.4.6.    Server hello done                                           58
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   7.4.7.    Client certificate                                          59
-   7.4.8.    Client Certificate URLs                                     59
-   7.4.9.    Client key exchange message                                 61
-   7.4.9.1.  RSA encrypted premaster secret message                      62
-   7.4.9.2.  Client Diffie-Hellman public value                          64
-   7.4.10.   Certificate verify                                          65
-   7.4.10.   Finished                                                    65
-   8.        Cryptographic computations                                  66
-   8.1.      Computing the master secret                                 67
-   8.1.1.    RSA                                                         67
-   8.1.2.    Diffie-Hellman                                              67
-   9.        Mandatory Cipher Suites                                     67
-   A.        Protocol constant values                                    71
-   A.1.      Record layer                                                71
-   A.2.      Change cipher specs message                                 72
-   A.3.      Alert messages                                              72
-   A.4.      Handshake protocol                                          74
-   A.4.1.    Hello messages                                              74
-   A.4.2.    Server authentication and key exchange messages             77
-   A.4.3.    Client authentication and key exchange messages             78
-   A.4.4.    Handshake finalization message                              79
-   A.5.      The CipherSuite                                             80
-   A.6.      The Security Parameters                                     83
-   B.        Glossary                                                    84
-   C.        CipherSuite definitions                                     88
-   D.        Implementation Notes                                        90
-   D.1       Random Number Generation and Seeding                        90
-   D.2       Certificates and authentication                             90
-   D.3       CipherSuites                                                90
-   E.        Backward Compatibility                                      91
-   E.1.      Version 2 client hello                                      92
-   E.2.      Avoiding man-in-the-middle version rollback                 93
-   F.        Security analysis                                           95
-   F.1.      Handshake protocol                                          95
-   F.1.1.    Authentication and key exchange                             95
-   F.1.1.1.  Anonymous key exchange                                      95
-   F.1.1.2.  RSA key exchange and authentication                         96
-   F.1.1.3.  Diffie-Hellman key exchange with authentication             97
-   F.1.2.    Version rollback attacks                                    97
-   F.1.3.    Detecting attacks against the handshake protocol            98
-   F.1.4.    Resuming sessions                                           98
-   F.1.5     Extensions                                                  99
-   F.1.5.1   Security of server_name                                     99
-   F.1.5.2   Security of client_certificate_url                          100
-   F.1.5.4.  Security of trusted_ca_keys                                 101
-   F.1.5.5.  Security of truncated_hmac                                  101
-   F.1.5.6.  Security of status_request                                  102
-   F.2.      Protecting application data                                 102
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   F.3.      Explicit IVs                                                103
-   F.4       Security of Composite Cipher Modes                          103
-   F.5       Denial of Service                                           104
-   F.6.      Final notes                                                 104
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-1.1 Differences from TLS 1.1
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-     - Merged in TLS Extensions and AES Cipher Suites from external
-     documents.
-
-     - Replacement of MD5/SHA-1 combination in the PRF
-
-     - Replacement of MD5/SHA-1 combination in the digitally-signed
-     element.
-
-     - Allow the client to indicate which hash functions it supports.
-
-     - Allow the server to indicate which hash functions it supports
-
-     - Addition of support for authenticated encryption with additional
-     data modes.
-
-1.1 Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-       successfully exchange cryptographic parameters without knowledge
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions.) This
-   document is intended primarily for readers who will be implementing
-   the protocol and those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, the output of the chosen hash function is encoded as
-   a PKCS #1 DigestInfo and then signed using block type 01 as described
-   in Section 8.1 as described in [PKCS1A].
-
-   Note: the standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
-   However, to minimize differences with TLS 1.0 text, we are using the
-   terminology of RFC 2313 [PKCS1A].
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and the output is
-   generally larger than the input in order to accomodate the integrity
-   check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1A].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by applying P_hash to the secret S as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   Unless the cipher suite definition specifies otherwise, the hash
-   function used in P MUST be the same hash function selected for the
-   HMAC in the cipher suite. For existing cipher suites (which use MD5
-   or SHA-1), the hash MUST be SHA-1. New ciphers which do not use HMAC
-   MUST explicitly specify a PRF.
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.1). All such
-   values must be defined by RFC 2434 Standards Action.  See section 11
-   for IANA Considerations for ContentType values.
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it. Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block, stream, or AEAD cipher, the block
-       size of the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
-
-       /* The use of "sha" above is historical and denotes SHA-1 */
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever the necessary state information
-       is to allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       implementation would need to wrap a sequence number it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.2, which uses the version { 3, 3 }. The
-       version value 3.3 is historical, deriving from the use of 3.1 for
-       TLS 1.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved.  Application data is generally of lower precedence
-       for transmission than other content types.  However, records MUST
-       be delivered to the network in the same order as they are
-       protected by the record layer.  Recipients MUST receive and
-       process interleaved application layer traffic during handshakes
-       subsequent to the first one on a connection.
-
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-               case aead: GenericAEADCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       TLS 1.2 uses an explicit IV in order to prevent the attacks described
-       by [CBCATT].  We recommend the following equivalently strong
-       procedures.  For clarity we use the following notation.
-
-       IV -- the transmitted value of the IV field in the
-           GenericBlockCipher structure.
-       CBC residue -- the last ciphertext block of the previous record
-       mask -- the actual value which the cipher XORs with the
-           plaintext prior to encryption of the first cipher block
-           of the record.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       In versions of TLS prior to 1.1, there was no IV field and the CBC residue
-       and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
-       of [TLS1.0] for details of TLS 1.0 IV handling.
-
-       One of the following two algorithms SHOULD be used to generate the
-       per-record IV:
-
-       (1) Generate a cryptographically strong random string R of
-           length CipherSpec.block_length. Place R
-           in the IV field. Set the mask to R. Thus, the first
-           cipher block will be encrypted as E(R XOR Data).
-
-       (2) Generate a cryptographically strong random number R of
-           length CipherSpec.block_length and prepend it to the plaintext
-           prior to encryption. In
-           this case either:
-
-           (a)   The cipher may use a fixed mask such as zero.
-           (b) The CBC residue from the previous record may be used
-               as the mask. This preserves maximum code compatibility
-            with TLS 1.0 and SSL 3. It also has the advantage that
-            it does not require the ability to quickly reset the IV,
-            which is known to be a   problem on some systems.
-
-            In either 2(a) or 2(b) the data (R || data) is fed into the
-            encryption process. The first cipher block (containing
-            E(mask XOR R) is placed in the IV field. The first
-            block of content contains E(IV XOR data)
-
-       The following alternative procedure MAY be used: However, it has
-       not been demonstrated to be equivalently cryptographically strong
-       to the above procedures. The sender prepends a fixed block F to
-       the plaintext (or alternatively a block generated with a weak
-       PRNG). He then encrypts as in (2) above, using the CBC residue
-       from the previous block as the mask for the prepended block. Note
-       that in this case the mask for the first record transmitted by
-       the application (the Finished) MUST be generated using a
-       cryptographically strong PRNG.
-
-       The decryption operation for all three alternatives is the same.
-       The receiver decrypts the entire GenericBlockCipher structure and
-       then discards the first cipher block, corresponding to the IV
-       component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes long, as long as it
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes (this does not
-          include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
-       timing attack on CBC padding based on the time required to
-       compute the MAC. In order to defend against this attack,
-       implementations MUST ensure that record processing time is
-       essentially the same whether or not the padding is correct.  In
-       general, the best way to to do this is to compute the MAC even if
-       the padding is incorrect, and only then reject the packet. For
-       instance, if the pad appears to be incorrect the implementation
-       might assume a zero-length pad and then compute the MAC. This
-       leaves a small timing channel, since MAC performance depends to
-       some extent on the size of the data fragment, but it is not
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       believed to be large enough to be exploitable due to the large
-       block size of existing MACs and the small size of the timing
-       signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-       aead-ciphered struct {
-           opaque IV[CipherSpec.iv_length];
-           opaque aead_output[AEADEncrypted.length];
-       } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, optional IV (depending on
-   the cipher), plaintext, and "additional data" to be included in the
-   authentication check. I.e.,
-
-      AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
-                      additional_data)
-
-   The key is either the client_write_key or the server_write_key.  When
-   AEAD algorithms are used the MAC keys are of zero length and are not
-   used. The length of the IV depends on the cipher suite.  If it is
-   required it MUST be generated using a cryptographically strong random
-   number generator. Note that the IV may be zero length.  The plaintext
-   is the TLSCompressed.fragment. The additional_data is defined as
-   follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   Where "+" denotes concatenation.
-
-   AEADEncrypted.length will generally be larger than
-   TLSCompressed.length, but by an amount that varies with the cipher
-   and the required padding (if any). AEAD algorithms MUST NOT produce
-   an expansion of greater than 1024 bytes.
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   IV, the "additional_data", and the AEADEncrypted value. The output is
-   either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-   TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
-                   TLSCiphertext.type + TLSCiphertext.version +
-                   TLSCiphertext.length);
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, which are generated from the master secret in
-   that order. Unused values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-
-   Implementation note:
-       The currently defined which requires the most material is
-       AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte
-       keys and 2 x 20 byte MAC secrets, for a total 104 bytes of key
-       material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols which are used to allow peers to agree
-       upon security parameters for the record layer, authenticate
-       themselves, instantiate negotiated security parameters, and
-       report error conditions to each other.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [X509] certificate of the peer. This element of the
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the hash_size. (See
-         Appendix A.6 for formal definition)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see section 7.4.11
-
- Note: if a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g. if it has to perform a time consuming public
-   key operation). Thus, a small window of time during which the
-   recipient must buffer the data MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           unsupported_extension(110),           /* new */
-           certificate_unobtainable(111),        /* new */
-           unrecognized_name(112),               /* new */
-           bad_certificate_status_response(113), /* new */
-           bad_certificate_hash_value(114),      /* new */
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed
-       This alert MAY be returned if a TLSCiphertext decrypted in an
-       invalid way: either it wasn't an even multiple of the block
-       length, or its padding values, when checked, weren't correct.
-       This message is always fatal.
-
-       Note: Differentiating between bad_record_mac and
-       decryption_failed alerts may permit certain attacks against CBC
-       mode as used in TLS [CBCATT]. It is preferable to uniformly use
-       the bad_record_mac alert to hide the specific type of the error.
-
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not in TLS. It should not be
-       sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in TLS 1.0 but not TLS 1.1.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       point. This message is always a warning.
-
-       The following error alerts apply only to the extensions described
-       in Section XXX. To avoid "breaking" existing clients and servers,
-       these alerts MUST NOT be sent unless the sending party has
-       received an extended hello message from the party they are
-       communicating with.
-
-   unsupported_extension
-       sent by clients that receive an extended server hello containing
-       an extension that they did not put in the corresponding client
-       hello (see Section 2.3).  This message is always fatal.
-
-   unrecognized_name
-       sent by servers that receive a server_name extension request, but
-       do not recognize the server name.  This message MAY be fatal.
-
-   certificate_unobtainable
-       sent by servers who are unable to retrieve a certificate chain
-       from the URL supplied by the client (see Section 3.3).  This
-       message MAY be fatal - for example if client authentication is
-       required by the server for the handshake to continue and the
-       server is unable to retrieve the certificate chain, it may send a
-       fatal alert.
-
-   bad_certificate_status_response
-       sent by clients that receive an invalid certificate status
-       response (see Section 3.6).  This message is always fatal.
-
-   bad_certificate_hash_value
-       sent by servers when a certificate hash does not match a client
-       provided certificate_hash.  This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New alerts values MUST be defined by RFC 2434 Standards Action. See
-   Section 11 for IANA Considerations for alert values.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   However, you SHOULD never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               CertificateStatus*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      CertificateURL*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), certificate_url(21), certificate_status(22),
-        (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-               case certificate_url:     CertificateURL;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-               case certificate_status:  CertificateStatus;
-           } body;
-       } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message type values MUST be defined via RFC 2434
-   Standards Action. See Section 11 for IANA Considerations for these
-   values.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes which are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   If the client wishes to use extensions (see Section XXX),
-   it may send an ExtendedClientHello:
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-           Extension client_hello_extension_list<0..2^16-1>;
-       } ExtendedClientHello;
-
-   These two messages can be distinguished by determining whether there
-   are bytes following what would be the end of the ClientHello.
-
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.2 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-       client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   client_hello_extension_list
-       Clients MAY request extended functionality from servers by
-       sending data in the client_hello_extension_list.  Here the new
-       "client_hello_extension_list" field contains a list of
-       extensions.  The actual "Extension" format is defined in Section
-       XXX.
-
-       In the event that a client requests additional functionality
-       using the extended client hello, and this functionality is not
-       supplied by the server, the client MAY abort the handshake.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       A server that supports the extensions mechanism MUST accept only
-       client hello messages in either the original or extended
-       ClientHello ormat, and (as for all other messages) MUST check
-       that the amount of data in the message precisely matches one of
-       these formats; if not then it MUST send a fatal "decode_error"
-       alert.
-
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-   The server will send this message in response to a client hello
-   message when it was able to find an acceptable set of algorithms. If
-   it cannot find such a match, it will respond with a handshake failure
-   alert.
-
-   Structure of this message:
-   struct {
-       ProtocolVersion server_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suite;
-       CompressionMethod compression_method;
-   } ServerHello;
-
-   If the server is sending an extension, it should use the
-   ExtendedServerHello:
-
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-           CompressionMethod compression_method;
-           Extension server_hello_extension_list<0..2^16-1>;
-       } ExtendedServerHello;
-
-   These two messages can be distinguished by determining whether there
-   are bytes following what would be the end of the ServerHello.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   server_version
-   This field will contain the lower of that suggested by the client in
-   the client hello and the highest supported by the server. For this
-   version of the specification, the version is 3.2 (See Appendix E for
-   details about backward compatibility).
-
-   random
-   This structure is generated by the server and MUST be independently
-   generated from the ClientHello.random.
-
-   session_id
-   This is the identity of the session corresponding to this connection.
-   If the ClientHello.session_id was non-empty, the server will look in
-   its session cache for a match. If a match is found and the server is
-   willing to establish the new connection using the specified session
-   state, the server will respond with the same value as was supplied by
-   the client. This indicates a resumed session and dictates that the
-   parties must proceed directly to the finished messages. Otherwise
-   this field will contain a different value identifying the new
-   session. The server may return an empty session_id to indicate that
-   the session will not be cached and therefore cannot be resumed. If a
-   session is resumed, it must be resumed using the same cipher suite it
-   was originally negotiated with.
-
-   cipher_suite
-   The single cipher suite selected by the server from the list in
-   ClientHello.cipher_suites. For resumed sessions this field is the
-   value from the state of the session being resumed.
-
-   compression_method
-   The single compression algorithm selected by the server from the list
-   in ClientHello.compression_methods. For resumed sessions this field
-   is the value from the resumed session state.
-
-   server_hello_extension_list
-   A list of extensions. Note that only extensions offered by the client
-   can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format for extended client hellos and extended server
-   hellos is:
-
-         struct {
-             ExtensionType extension_type;
-             opaque extension_data<0..2^16-1>;
-         } Extension;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Here:
-
-     - "extension_type" identifies the particular extension type.
-
-     - "extension_data" contains information specific to the particular
-   extension type.
-
-   The extension types defined in this document are:
-
-         enum {
-             server_name(0), max_fragment_length(1),
-             client_certificate_url(2), trusted_ca_keys(3),
-             truncated_hmac(4), status_request(5),
-             cert_hash_types(6), (65535)
-         } ExtensionType;
-
-   The list of defined extension types is maintained by the IANA. The
-   current list can be found at (http://www.iana.org/assignments/tls-
-   extensions). See sections 7.4.1.4.8 and 11.1 for more information on
-   how new values are added.
-
-   Note that for all extension types (including those defined in
-   future), the extension type MUST NOT appear in the extended server
-   hello unless the same extension type appeared in the corresponding
-   client hello.  Thus clients MUST abort the handshake if they receive
-   an extension type in the extended server hello that they did not
-   request in the associated (extended) client hello.
-
-   Nonetheless "server oriented" extensions may be provided in the
-   future within this framework - such an extension, say of type x,
-   would require the client to first send an extension of type x in the
-   (extended) client hello with empty extension_data to indicate that it
-   supports the extension type. In this case the client is offering the
-   capability to understand the extension type, and the server is taking
-   the client up on its offer.
-
-   Also note that when multiple extensions of different types are
-   present in the extended client hello or the extended server hello,
-   the extensions may appear in any order.  There MUST NOT be more than
-   one extension of the same type.
-
-   An extended client hello may be sent both when starting a new session
-   and when requesting session resumption.  Indeed a client that
-   requests resumption of a session does not in general know whether the
-   server will accept this request, and therefore it SHOULD send an
-   extended client hello if it would normally do so for a new session.
-   In general the specification of each extension type must include a
-   discussion of the effect of the extension both during new sessions
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   and during resumed sessions.
-
-   Note also that all the extensions defined in this document are
-   relevant only when a session is initiated. When a client includes one
-   or more of the defined extension types in an extended client hello
-   while requesting session resumption:
-
-     - If the resumption request is denied, the use of the extensions
-       is negotiated as normal.
-
-     - If, on the other hand, the older session is resumed, then the
-       server MUST ignore the extensions and send a server hello
-       containing none of the extension types; in this case the
-       functionality of these extensions negotiated during the original
-       session initiation is applied to the resumed session.
-
-7.4.1.4.1 Server Name Indication
-
-   [TLS1.1] does not provide a mechanism for a client to tell a server
-   the name of the server it is contacting.  It may be desirable for
-   clients to provide this information to facilitate secure connections
-   to servers that host multiple 'virtual' servers at a single
-   underlying network address.
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-         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;
-
-   Currently the only server names supported are DNS hostnames, however
-   this does not imply any dependency of TLS on DNS, and other name
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   types may be added in the future (by an RFC that Updates this
-   document).  TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client. The hostname is represented as a byte
-   string using UTF-8 encoding [UTF8], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in section 3.1
-   of [IDNA] notwithstanding). If the server needs to match the HostName
-   against names that contain non-US-ASCII characters, it MUST perform
-   the conversion operation described in section 4 of [IDNA], treating
-   the HostName as a "query string" (i.e. the AllowUnassigned flag MUST
-   be set). Note that IDNA allows labels to be separated by any of the
-   Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore
-   servers MUST accept any of these characters as a label separator.  If
-   the server only needs to match the HostName against names containing
-   exclusively ASCII characters, it MUST compare ASCII names case-
-   insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".  It
-   is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension, MAY use the information contained in the extension to
-   guide its selection of an appropriate certificate to return to the
-   client, and/or other aspects of security policy.  In this event, the
-   server SHALL include an extension of type "server_name" in the
-   (extended) server hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol, then upgrades to TLS, and a server_name extension is sent,
-   then the extension SHOULD contain the same name that was negotiated
-   in the application protocol.  If the server_name is established in
-   the TLS session handshake, the client SHOULD NOT attempt to request a
-   different server name at the application layer.
-
-7.4.1.4.2 Maximum Fragment Length Negotiation
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   By default, TLS uses fixed maximum plaintext fragment length of 2^14
-   bytes.  It may be desirable for constrained clients to negotiate a
-   smaller maximum fragment length due to memory limitations or
-   bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain:
-
-         enum{
-             2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-         } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length.  The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension, MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL contain
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert.  Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent.  Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [TLS] section 6.2.1).  Note that the output
-   of the record layer may be larger.  For example, if the negotiated
-   length is 2^9=512, then for currently defined cipher suites and when
-   null compression is used, the record layer output can be at most 793
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes
-   of padding, and 20 bytes of MAC.  That means that in this event a TLS
-   record layer peer receiving a TLS record layer message larger than
-   793 bytes may discard the message and send a "record_overflow" alert,
-   without decrypting the message.
-
-7.4.1.4.3 Client Certificate URLs
-
-   Ordinarily, when client authentication is performed, client
-   certificates are sent by clients to servers during the TLS handshake.
-   It may be desirable for constrained clients to send certificate URLs
-   in place of certificates, so that they do not need to store their
-   certificates and can therefore save memory.
-
-   In order to negotiate to send certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-   (extended) client hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS 1.0 servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension, MAY indicate that they are
-   willing to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message.  See
-   Section XXX.
-
-7.4.1.4.4 Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys, may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-         struct {
-             TrustedAuthority trusted_authorities_list<0..2^16-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-         } TrustedAuthorities;
-
-         struct {
-             IdentifierType identifier_type;
-             select (identifier_type) {
-                 case pre_agreed: struct {};
-                 case key_sha1_hash: SHA1Hash;
-                 case x509_name: DistinguishedName;
-                 case cert_sha1_hash: SHA1Hash;
-             } identifier;
-         } TrustedAuthority;
-
-         enum {
-             pre_agreed(0), key_sha1_hash(1), x509_name(2),
-             cert_sha1_hash(3), (255)
-         } IdentifierType;
-
-         opaque DistinguishedName<1..2^16-1>;
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses.  Each CA root key is identified via
-   either:
-
-     -  "pre_agreed" - no CA root key identity supplied.
-
-     -  "key_sha1_hash" - contains the SHA-1 hash of the CA root key.
-   For
-       DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
-       value.  For RSA keys, the hash is of the big-endian byte string
-       representation of the modulus without any initial 0-valued bytes.
-       (This copies the key hash formats deployed in other
-       environments.)
-
-     -  "x509_name" - contains the DER-encoded X.509 DistinguishedName
-       of
-       the CA.
-
-     -  "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded
-       Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer - for example if
-   a particular CA has multiple key pairs - however here we assume this
-   is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension, MAY use the information contained in the extension to
-   guide their selection of an appropriate certificate chain to return
-   to the client.  In this event, the server SHALL include an extension
-   of type "trusted_ca_keys" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-7.4.1.4.5 Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [HMAC] to authenticate record layer
-   communications.  In TLS the entire output of the hash function is
-   used as the MAC tag.  However it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-   include an extension of type "truncated_hmac" in the extended client
-   hello.  The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension, MAY agree to use a truncated HMAC by including an
-   extension of type "truncated_hmac", with empty "extension_data", in
-   the extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect.  It is strongly recommended that any new cipher
-   suites using other MACs consider the MAC size as an integral part of
-   the cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters.  Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [HMAC].  That is, CipherSpec.hash_size is 10 bytes, and
-   only the first 10 bytes of the HMAC output are transmitted and
-   checked.  Note that this extension does not affect the calculation of
-   the PRF as part of handshaking or key derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-7.4.1.4.6 Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [OCSP] to check the validity of server certificates, in
-   order to avoid transmission of CRLs and therefore save bandwidth on
-   constrained networks.  This extension allows for such information to
-   be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "CertificateStatusRequest" where:
-
-         struct {
-             CertificateStatusType status_type;
-             select (status_type) {
-                 case ocsp: OCSPStatusRequest;
-             } request;
-         } CertificateStatusRequest;
-
-         enum { ocsp(1), (255) } CertificateStatusType;
-
-         struct {
-             ResponderID responder_id_list<0..2^16-1>;
-             Extensions  request_extensions;
-         } OCSPStatusRequest;
-
-         opaque ResponderID<1..2^16-1>;
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts.  A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server - e.g., by prior arrangement.  "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [OCSP].  "Extensions" is imported from [PKIX].  A zero-
-   length "request_extensions" value means that there are no extensions
-   (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
-   the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Servers that receive a client hello containing the "status_request"
-   extension, MAY return a suitable certificate status response to the
-   client along with their certificate.  If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder, and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages). Section XXX describes the
-   CertificateStatus message.
-
-7.4.1.4.7 Cert Hash Types
-
-   The client MAY use the "cert_hash_types" to indicate to the server
-   which hash functions may be used in the signature on the server's
-   certificate. The "extension_data" field of this extension contains:
-
-         enum{
-             md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
-         } HashType;
-
-         struct {
-               HashType<255> types;
-         } CertHashTypes;
-
-   These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
-   and SHA-512 [SHA] respectively. The server MUST NOT send this
-   extension.
-
-   Clients SHOULD send this extension if they support any algorithm
-   other than SHA-1. If this extension is not used, servers SHOULD
-   assume that the client supports only SHA-1. Note: this is a change
-   from TLS 1.1 where there are no explicit rules but as a practical
-   matter one can assume that the peer supports MD5 and SHA-1.
-
- HashType values are divided into three groups:
-
-      1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-         reserved for IETF Standards Track protocols.
-
-      2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
-         are reserved for assignment for non-Standards Track methods.
-
-      3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-         inclusive are reserved for private use.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Additional information describing the role of IANA in the
-   allocation of HashType code points is described
-   in Section 11.
-
-
-7.4.1.4.8 Procedure for Defining New Extensions
-
-   The list of extension types, as defined in Section 2.3, is
-   maintained by the Internet Assigned Numbers Authority (IANA). Thus
-   an application needs to be made to the IANA in order to obtain a new
-   extension type value. Since there are subtle (and not so subtle)
-   interactions that may occur in this protocol between new features and
-   existing features which may result in a significant reduction in
-   overall security, new values SHALL be defined only through the IETF
-   Consensus process specified in [IANA].
-
-   (This means that new assignments can be made only via RFCs approved
-   by the IESG.)
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-     -  All of the extensions defined in this document follow the
-       convention that for each extension that a client requests and that
-       the server understands, the server replies with an extension of
-       the same type.
-
-     -  Some cases where a server does not agree to an extension are error
-       conditions, and some simply a refusal to support a particular
-       feature.  In general error alerts should be used for the former,
-       and a field in the server extension response for the latter.
-
-     -  Extensions should as far as possible be designed to prevent any
-       attack that forces use (or non-use) of a particular feature by
-       manipulation of handshake messages.  This principle should be
-       followed regardless of whether the feature is believed to cause a
-       security problem.
-
-       Often the fact that the extension fields are included in the
-       inputs to the Finished message hashes will be sufficient, but
-       extreme care is needed when the extension changes the meaning of
-       messages sent in the handshake phase. Designers and implementors
-       should be aware of the fact that until the handshake has been
-       authenticated, active attackers can modify messages and insert,
-       remove, or replace extensions.
-
-     -  It would be technically possible to use extensions to change major
-       aspects of the design of TLS; for example the design of cipher
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       suite negotiation.  This is not recommended; it would be more
-       appropriate to define a new version of TLS - particularly since
-       the TLS handshake algorithms have specific protection against
-       version rollback attacks based on the version number, and the
-       possibility of version rollback should be a significant
-       consideration in any major design change.
-
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will
-       always immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-       certificate. It MUST contain a key which matches the key
-       exchange method, as follows. Unless otherwise specified, the
-       signing
-       algorithm for the certificate MUST be the same as the
-       algorithm for the certificate key. Unless otherwise specified,
-       the public key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit MUST be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   MUST be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   As CipherSuites which specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-   If the SignatureAlgorithm being used to sign the ServerKeyExchange
-   message is DSA, the hash function used MUST be SHA-1. If the
-   SignatureAlgorithm it must be the same hash function used in the
-   signature of the server's certificate (found in the Certificate)
-   message. This algorithm is denoted Hash below. Hash.length is the
-   length of the output of that algorithm.
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-               case rsa:
-                   ServerRSAParams params;
-           };
-        } ServerParams;
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       hash
-           Hash(ClientHello.random + ServerHello.random + ServerParams)
-
-       sha_hash
-           SHA1(ClientHello.random + ServerHello.random + ServerParams)
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       struct {
-           select (SignatureAlgorithm) {
-               case anonymous: struct { };
-               case rsa:
-                   digitally-signed struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-                 opaque hash[Hash.length];
-                   };
-               case dsa:
-                   digitally-signed struct {
-                       opaque sha_hash[20];
-                   };
-               };
-           };
-       } Signature;
-
-7.4.4. CertificateStatus
-
-   If a server returns a
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-         struct {
-             CertificateStatusType status_type;
-             select (status_type) {
-                 case ocsp: OCSPResponse;
-             } response;
-         } CertificateStatus;
-
-         opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [OCSP]).  Note that
-   only one OCSP response may be sent.
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response, and receiving an OCSP response
-   in a "CertificateStatus" message MUST check the OCSP response and
-   abort the handshake if the response is not satisfactory.
-
-
-7.4.5. Certificate request
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-           rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-           fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           HashType certificate_hash<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_types
-           A list of the types of certificate types which the client may
-           offer.
-              rsa_sign        a certificate containing an RSA key
-              dss_sign        a certificate containing a DSS key
-              rsa_fixed_dh    a certificate signed with RSA and containing
-                              a static DH key.
-              dss_fixed_dh    a certificate signed with DSS and containing
-                              a static DH key
-
-           Certificate types rsa_sign and dss_sign SHOULD contain
-           certificates signed with the same algorithm. However, this is
-           not required. This is a holdover from TLS 1.0 and 1.1.
-
-
-       certificate_hash
-           A list of acceptable hash algorithms to be used in
-           certificate signatures.
-
-       certificate_authorities
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
- ClientCertificateType values are divided into three groups:
-
-              1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-                 reserved for IETF Standards Track protocols.
-
-              2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
-                 inclusive are reserved for assignment for non-Standards
-                 Track methods.
-
-              3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-                 inclusive are reserved for private use.
-
-           Additional information describing the role of IANA in the
-           allocation of ClientCertificateType code points is described
-           in Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were used in
-           SSLv3.
-
-
- Note: DistinguishedName is derived from [X501]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.6. Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       Upon receipt of the server hello done message the client SHOULD
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.7. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client SHOULD send a certificate message
-       containing no certificates. That is, the certificate_list
-       structure has a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate MUST match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.8. Client Certificate URLs
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message.
-
-         enum {
-             individual_certs(0), pkipath(1), (255)
-         } CertChainType;
-
-         enum {
-             false(0), true(1)
-         } Boolean;
-
-         struct {
-             CertChainType type;
-             URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-         } CertificateURL;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-         struct {
-             opaque url<1..2^16-1>;
-             Boolean hash_present;
-             select (hash_present) {
-                 case false: struct {};
-                 case true: SHA1Hash;
-             } hash;
-         } URLAndOptionalHash;
-
-         opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-   When X.509 certificates are used, there are two possibilities:
-
-     -  if CertificateURL.type is "individual_certs", each URL refers to
-       a single DER-encoded X.509v3 certificate, with the URL for the
-       client's certificate first, or
-
-     -  if CertificateURL.type is "pkipath", the list contains a single
-       URL referring to a DER-encoded certificate chain, using the type
-       PkiPath described in Section 8.
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion is
-   either not present or is the SHA-1 hash of the certificate or
-   certificate chain (in the case of X.509 certificates, the DER-encoded
-   certificate or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [TLS] Section 7.4.2), but opposite to the order in which
-   certificates are encoded in PkiPath.  In either case, the self-signed
-   root certificate MAY be omitted from the chain, under the assumption
-   that the server must already possess it in order to validate it.
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs, and then process the
-   certificate chain as usual.  A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   for certificate URLs, and MAY support other schemes. Use of other
-   schemes than "http", "https", or "ftp" may create unexpected
-   problems.
-
-   If the protocol used is HTTP, then the HTTP server can be configured
-   to use the Cache-Control and Expires directives described in [HTTP]
-   to specify whether and for how long certificates or certificate
-   chains should be cached.
-
-   The TLS server is not required to follow HTTP redirects when
-   retrieving the certificates or certificate chain.  The URLs used in
-   this extension SHOULD therefore be chosen not to depend on such
-   redirects.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
-   when a chain of X.509v3 certificates is returned, the Content-Type is
-   "application/pkix-pkipath" (see Section XXX).
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash.  If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs. The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-7.4.9. Client key exchange message
-
-   When this message will be sent:
-   This message is always sent by the client. It MUST immediately follow
-   the client certificate message, if it is sent. Otherwise it MUST be
-   the first message sent by the client after it receives the server
-   hello done message.
-
-   Meaning of this message:
-   With this message, the premaster secret is set, either though direct
-   transmission of the RSA-encrypted secret, or by the transmission of
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Diffie-Hellman parameters which will allow each side to agree upon
-   the same premaster secret. When the key exchange method is DH_RSA or
-   DH_DSS, client certification has been requested, and the client was
-   able to respond with a certificate which contained a Diffie-Hellman
-   public key whose parameters (group and generator) matched those
-   specified by the server in its certificate, this message MUST not
-   contain any data.
-
-   Structure of this message:
-   The choice of messages depends on which key exchange method has been
-   selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition.
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa: EncryptedPreMasterSecret;
-           case diffie_hellman: ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-7.4.9.1. RSA encrypted premaster secret message
-
-   Meaning of this message:
-   If RSA is being used for key agreement and authentication, the client
-   generates a 48-byte premaster secret, encrypts it using the public
-   key from the server's certificate or the temporary RSA key provided
-   in a server key exchange message, and sends the result in an
-   encrypted premaster secret message. This structure is a variant of
-   the client key exchange message, not a message in itself.
-
-   Structure of this message:
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   } PreMasterSecret;
-
-   client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 v 1.5 encoded RSA.
-       The attack takes advantage of the fact that by failing in
-       different ways, a TLS server can be coerced into revealing
-       whether a particular message, when decrypted, is properly PKCS#1
-       v1.5 formatted or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
-       [PKCS1B] defines a newer version of PKCS#1 encoding that is more
-       secure against the Bleichenbacher attack. However, for maximal
-       compatibility with TLS 1.0, TLS 1.1 retains the original
-       encoding. No variants of the Bleichenbacher attack are known to
-       exist provided that the above recommendations are followed.
-
- Implementation Note: public-key-encrypted data is represented as an
-       opaque vector <0..2^16-1> (see section 4.7). Thus the RSA-
-       encrypted PreMasterSecret in a ClientKeyExchange is preceded by
-       two length bytes. These bytes are redundant in the case of RSA
-       because the EncryptedPreMasterSecret is the only data in the
-       ClientKeyExchange and its length can therefore be unambiguously
-       determined. The SSLv3 specification was not clear about the
-       encoding of public-key-encrypted data and therefore many SSLv3
-       implementations do not include the the length bytes, encoding the
-       RSA encrypted data directly in the ClientKeyExchange message.
-
-       This specification requires correct encoding of the
-       EncryptedPreMasterSecret complete with length bytes. The
-       resulting PDU is incompatible with many SSLv3 implementations.
-       Implementors upgrading from SSLv3 must modify their
-       implementations to generate and accept the correct encoding.
-       Implementors who wish to be compatible with both SSLv3 and TLS
-       should make their implementation's behavior dependent on the
-       protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-       on SSL are possible, at least when the client and server are on
-       the same LAN. Accordingly, implementations which use static RSA
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       keys SHOULD use RSA blinding or some other anti-timing technique,
-       as described in [TIMING].
-
- Note: The version number in the PreMasterSecret MUST be the version
-       offered by the client in the ClientHello.version, not the version
-       negotiated for the connection. This feature is designed to
-       prevent rollback attacks. Unfortunately, many implementations use
-       the negotiated version instead and therefore checking the version
-       number may lead to failure to interoperate with such incorrect
-       client implementations. Client implementations MUST and Server
-       implementations MAY check the version number. In practice, since
-       the TLS handshake MACs prevent downgrade and no good attacks are
-       known on those MACs, ambiguity is not considered a serious
-       security risk.  Note that if servers choose to to check the
-       version number, they should randomize the PreMasterSecret in case
-       of error, rather than generate an alert, in order to avoid
-       variants on the Bleichenbacher attack. [KPR03]
-
-7.4.9.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-7.4.10. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3. If the SignatureAlgorithm
-       is DSA, then the sha_hash value must be used. If it is RSA,
-       the same function (denoted Hash) must be used as was used to
-       create the signature for the client's certificate.
-
-       CertificateVerify.signature.hash
-           Hash(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.10. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, Hash(handshake_messages))[0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-           Hash denotes the negotiated hash used for the PRF. If a new
-           PRF is defined, then this hash MUST be specified.
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.10 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one which is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   the master secret.
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. IANA Considerations
-
-   This document describes a number of new registries to be created by
-   IANA. We recommend that they be placed as individual registries items
-   under a common TLS category.
-
-   Section 7.4.5 describes a TLS HashType Registry to be maintained by
-   the IANA, as defining a number of such code point identifiers.
-   HashType identifiers with values in the range 0-63 (decimal)
-   inclusive are assigned via RFC 2434 Standards Action. Values from the
-   range 64-223 (decimal) inclusive are assigned via [RFC 2434]
-   Specification Required.  Identifier values from 224-255 (decimal)
-   inclusive are reserved for RFC 2434 Private Use. The registry will be
-   initially populated with the values in this document, Section 7.4.5.
-
-   Section 7.4.5 describes a TLS ClientCertificateType Registry to be
-   maintained by the IANA, as defining a number of such code point
-   identifiers. ClientCertificateType identifiers with values in the
-   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action. Values from the range 64-223 (decimal) inclusive are assigned
-   via [RFC 2434] Specification Required.  Identifier values from
-   224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
-   The registry will be initially populated with the values in this
-   document, Section 7.4.5.
-
-   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
-   the IANA, as well as defining a number of such cipher suite
-   identifiers. Cipher suite values with the first byte in the range
-   0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
-   Values with the first byte in the range 192-254 (decimal) are
-   assigned via RFC 2434 Specification Required. Values with the first
-   byte 255 (decimal) are reserved for RFC 2434 Private Use. The
-   registry will be initially populated with the values from Section A.5
-   of this document, [TLSAES], and Section 3 of [TLSKRB].
-
-   Section 6 requires that all ContentType values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS ContentType registry,
-   initially populated with values from Section 6.2.1 of this document.
-   Future values MUST be allocated via Standards Action as described in
-   [RFC 2434].
-
-   Section 7.2.2 requires that all Alert values be defined by RFC 2434
-   Standards Action. IANA SHOULD create a TLS Alert registry, initially
-   populated with values from Section 7.2 of this document and Section 4
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   of [TLSEXT]. Future values MUST be allocated via Standards Action as
-   described in [RFC 2434].
-
-   Section 7.4 requires that all HandshakeType values be defined by RFC
-   2434 Standards Action. IANA SHOULD create a TLS HandshakeType
-   registry, initially populated with values from Section 7.4 of this
-   document and Section 2.4 of [TLSEXT].  Future values MUST be
-   allocated via Standards Action as described in [RFC2434].
-
-
-11.1 Extensions
-
-   Sections XXX and XXX describes a registry of ExtensionType values to
-   be maintained by the IANA. ExtensionType values are to be assigned
-   via IETF Consensus as defined in RFC 2434 [IANA]. The initial
-   registry corresponds to the definition of "ExtensionType" in Section
-   2.3.
-
-   The MIME type "application/pkix-pkipath" has been registered by the
-   IANA with the following template:
-
-      To: ietf-types@iana.org Subject: Registration of MIME media type
-      application/pkix-pkipath
-
-      MIME media type name: application
-      MIME subtype name: pkix-pkipath
-
-      Optional parameters: version (default value is "1")
-
-      Encoding considerations:
-         This MIME type is a DER encoding of the ASN.1 type PkiPath,
-         defined as follows:
-           PkiPath ::= SEQUENCE OF Certificate
-           PkiPath is used to represent a certification path.  Within the
-           sequence, the order of certificates is such that the subject of
-           the first certificate is the issuer of the second certificate,
-           etc.
-
-         This is identical to the definition published in [X509-4th-TC1];
-         note that it is different from that in [X509-4th].
-
-         All Certificates MUST conform to [PKIX].  (This should be
-         interpreted as a requirement to encode only PKIX-conformant
-         certificates using this type.  It does not necessarily require
-         that all certificates that are not strictly PKIX-conformant must
-         be rejected by relying parties, although the security consequences
-         of accepting any such certificates should be considered
-         carefully.)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-         DER (as opposed to BER) encoding MUST be used.  If this type is
-         sent over a 7-bit transport, base64 encoding SHOULD be used.
-
-      Security considerations:
-         The security considerations of [X509-4th] and [PKIX] (or any
-         updates to them) apply, as well as those of any protocol that uses
-         this type (e.g., TLS).
-
-         Note that this type only specifies a certificate chain that can be
-         assessed for validity according to the relying party's existing
-         configuration of trusted CAs; it is not intended to be used to
-         specify any change to that configuration.
-
-      Interoperability considerations:
-         No specific interoperability problems are known with this type,
-         but for recommendations relating to X.509 certificates in general,
-         see [PKIX].
-
-      Published specification: this memo, and [PKIX].
-
-      Applications which use this media type: TLS.  It may also be used by
-         other protocols, or for general interchange of PKIX certificate
-
-      Additional information:
-         Magic number(s): DER-encoded ASN.1 can be easily recognized.
-           Further parsing is required to distinguish from other ASN.1
-           types.
-         File extension(s): .pkipath
-         Macintosh File Type Code(s): not specified
-
-      Person & email address to contact for further information:
-         Magnus Nystrom <magnus@rsasecurity.com>
-
-      Intended usage: COMMON
-
-      Change controller:
-         IESG <iesg@ietf.org>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-    aead-ciphered struct {
-        opaque IV[CipherSpec.iv_length];
-        opaque aead_output[AEADEncrypted.length];
-    } GenericAEADCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            unsupported_extension(110),           /* new */
-            certificate_unobtainable(111),        /* new */
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-            unrecognized_name(112),               /* new */
-            bad_certificate_status_response(113), /* new */
-            bad_certificate_hash_value(114),      /* new */
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), certificate_url(21), certificate_status(22),
-     (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-            case certificate_url:     CertificateURL;
-            case certificate_status:  CertificateStatus;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-        Extension client_hello_extension_list<0..2^16-1>;
-    } ClientHello;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-        Extension client_hello_extension_list<0..2^16-1>;
-    } ExtendedClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-     Extension server_hello_extension_list<0..2^16-1>;
-    } ExtendedServerHello;
-
-    struct {
-        ExtensionType extension_type;
-        opaque extension_data<0..2^16-1>;
-    } Extension;
-
-    enum {
-        server_name(0), max_fragment_length(1),
-        client_certificate_url(2), trusted_ca_keys(3),
-        truncated_hmac(4), status_request(5),
-        cert_hash_types(6), (65535)
-    } ExtensionType;
-
-    struct {
-        NameType name_type;
-        select (name_type) {
-            case host_name: HostName;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-        } name;
-    } ServerName;
-
-    enum {
-        host_name(0), (255)
-    } NameType;
-
-    opaque HostName<1..2^16-1>;
-
-    struct {
-        ServerName server_name_list<1..2^16-1>
-    } ServerNameList;
-
-    enum{
-        2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-    } MaxFragmentLength;
-
-    struct {
-        TrustedAuthority trusted_authorities_list<0..2^16-1>;
-    } TrustedAuthorities;
-
-    struct {
-        IdentifierType identifier_type;
-        select (identifier_type) {
-            case pre_agreed: struct {};
-            case key_sha1_hash: SHA1Hash;
-            case x509_name: DistinguishedName;
-            case cert_sha1_hash: SHA1Hash;
-        } identifier;
-    } TrustedAuthority;
-
-    enum {
-        pre_agreed(0), key_sha1_hash(1), x509_name(2),
-        cert_sha1_hash(3), (255)
-    } IdentifierType;
-
-    struct {
-        CertificateStatusType status_type;
-        select (status_type) {
-            case ocsp: OCSPStatusRequest;
-        } request;
-    } CertificateStatusRequest;
-
-    enum { ocsp(1), (255) } CertificateStatusType;
-
-    struct {
-        ResponderID responder_id_list<0..2^16-1>;
-        Extensions  request_extensions;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-    } OCSPStatusRequest;
-
-     opaque ResponderID<1..2^16-1>;
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    struct {
-        CertificateStatusType status_type;
-        select (status_type) {
-            case ocsp: OCSPResponse;
-        } response;
-    } CertificateStatus;
-
-    opaque OCSPResponse<1..2^24-1>;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque rsa_modulus<1..2^16-1>;
-        opaque rsa_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-            case diffie_hellman:
-                ServerDHParams params;
-            case rsa:
-                ServerRSAParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-            case anonymous: struct { };
-            case rsa:
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-            case dsa:
-                digitally-signed struct {
-                    opaque sha_hash[20];
-                };
-            };
-        };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    enum {
-        individual_certs(0), pkipath(1), (255)
-    } CertChainType;
-
-    enum {
-        false(0), true(1)
-    } Boolean;
-
-    struct {
-        CertChainType type;
-        URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-    } CertificateURL;
-
-    struct {
-        opaque url<1..2^16-1>;
-        Boolean hash_present;
-        select (hash_present) {
-            case false: struct {};
-            case true: SHA1Hash;
-        } hash;
-    } URLAndOptionalHash;
-
-    opaque SHA1Hash[20];
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-    CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x2F };
-    CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x35 };
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-    CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA        = { 0x00, 0x30 };
-    CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA        = { 0x00, 0x31 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x32 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x33 };
-    CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
-    CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA        = { 0x00, 0x36 };
-    CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA        = { 0x00, 0x37 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x38 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x39 };
-    CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks and is
-   therefore deprecated.
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.1 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.1 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.1 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.1 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-
- The cipher suite space is divided into three regions:
-
-       1. Cipher suite values with first byte 0x00 (zero)
-          through decimal 191 (0xBF) inclusive are reserved for the IETF
-          Standards Track protocols.
-
-       2. Cipher suite values with first byte decimal 192 (0xC0)
-          through decimal 254 (0xFE) inclusive are reserved
-          for assignment for non-Standards Track methods.
-
-       3. Cipher suite values with first byte 0xFF are
-          reserved for private use.
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section 11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.
-       AES is
-       a block cipher with a 128, 192, or 256 bit keys and a 16 byte
-       block size. [AES] TLS currently only supports the 128 and 256
-       bit key sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-C. CipherSuite definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_SHA                RSA            AES_256_CBC  SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-the-
-   middle attacks. Applications should also enforce minimum and maximum
-   key sizes. For example, certificate chains containing 512-bit RSA
-   keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-E. Backward Compatibility
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS, SSL 3.0, and SSL 2.0 all frequently share the same connection
-   port: for example, the https protocol (HTTP secured by SSL or TLS)
-   uses port 443 regardless of which security protocol it is using.
-   Thus, some mechanism must be determined to distinguish and negotiate
-   among the various protocols.
-
-   TLS versions 1.2, 1.1, 1.0, and SSL 3.0 are very similar; thus,
-   supporting them all at the same time is relatively easy. TLS clients
-   who wish to negotiate with such older servers SHOULD send client
-   hello messages using the SSL 3.0 record format and client hello
-   structure, sending {3, 3} for the client version field to note that
-   they support TLS 1.2 and {3, 0} for the record version field (because
-   the SSLv3 record format is being used--although the cleartext record
-   format is the same for all versions).  If the server supports only a
-   downrev version it will respond with a downrev 3.0 server hello; if
-   it supports TLS 1.2 it will respond with a TLS 1.2 server hello. The
-   negotiation then proceeds as appropriate for the negotiated protocol.
-
-   Similarly, a TLS 1.2  server which wishes to interoperate with
-   downrev clients SHOULD accept downrev client hello messages and
-   respond with appropriate version fields. Note that the version in the
-   server hello message and in the record header are the same.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors SHOULD make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
- Note: TLS 1.2 clients may generate the SSLv2 EXPORT cipher suites in
-   handshakes for backward compatibility but MUST NOT negotiate them in
-   TLS 1.2 mode.
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification. Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       This field is the length of the following data in bytes. The high
-       bit MUST be 1 and is not part of the length.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-       version 2 client hello message. The value SHOULD be one (1).
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 92]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   version
-       The highest version of the protocol supported by the client
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. When using the SSLv2 backward compatible
-       handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There MUST be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       This field MUST be empty.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 93]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 94]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.10, 7.4.11 and 6.3). By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 95]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   from the server key exchange message. The result is sent in a client
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate. The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed. Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key. TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites. The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 96]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   the certificate verify message (see Section 7.4.10). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly so the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version rollback attacks
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 97]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Parties
-   concerned about attacks of this scale should not be using 40-bit
-   encryption keys anyway. Altering the padding of the least-significant
-   8 bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 98]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5 Extensions
-
-   Security considerations for the extension mechanism in general, and
-   the design of new extensions, are described in the previous section.
-   A security analysis of each of the extensions defined in this
-   document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art, and address any weaknesses identified.
-
-
-F.1.5.1 Security of server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs.  Apart from this, server_name does not appear
-   to introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS - in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed.  It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-   6.2. Security of max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages.  However, that does not introduce any security
-   complications that are not already present in TLS, since [TLS]
-   requires implementations to be able to handle fragmented handshake
-   messages.
-
-   Note that as described in section XXX, once a non-null cipher suite
-   has been activated, the effective maximum fragment length depends on
-   the cipher suite and compression method, as well as on the negotiated
-   max_fragment_length.  This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 99]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-F.1.5.2 Security of client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes.  The purpose of including
-   hashes and checking them against the retrieved certificate chain, is
-   to ensure that the same property holds when this extension is used -
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances - for example clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client.  Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here.  The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server acting as a client in another URL protocol.  The
-   server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some, possibly weird-looking URL.
-
-   In general this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw.  It also introduces the possibility of denial of service
-   attacks in which an attacker makes many connections to the server,
-   each of which results in the server attempting a connection to the
-   target of the attack.
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet; this could exacerbate the potential security and denial of
-   service problems described above, as well as allowing the existence
-   of internal hosts to be confirmed when they would otherwise be
-   hidden.
-
-   The detailed security concerns involved will depend on the URL
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 100]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   schemes supported by the server.  In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server.  In the case of HTTPS, the possibility for loops and
-   deadlocks to be created exists and should be addressed.  In the case
-   of FTP, attacks similar to FTP bounce attacks arise.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than being enabled by
-   default.  It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled, with unusual protocols offering limited security or whose
-   security is not well-understood being avoided.
-
-   As discussed in [URI], URLs that specify ports other than the default
-   may cause problems, as may very long URLs (which are more likely to
-   be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly.  If a request using HTTP (or another caching protocol)
-   goes through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-F.1.5.4. Security of trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information.  As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously.  As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-F.1.5.5. Security of truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs.  However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-   Note that the output length of a MAC need not be as long as the
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after the handshake
-   messages have been authenticated by the hashes in the Finished
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 101]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   messages, it is not possible for an active attacker to force
-   negotiation of the truncated HMAC extension where it would not
-   otherwise be used (to the extent that the handshake authentication is
-   secure).  Therefore, in the event that any security problem were
-   found with truncated HMAC in future, if either the client or the
-   server for a given session were updated to take into account the
-   problem, they would be able to veto use of this extension.
-
-F.1.5.6. Security of status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension.  A client that requires
-   OCSP validation of certificates SHOULD either contact the OCSP server
-   directly in this case, or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see section 4.4.1 of [OCSP] for further details.
-
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 102]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-F.4 Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information theoretic sense) that combined with any secure MAC
-       function fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message plus the length of the MAC tag is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent and unpredictable, IV for each new pair of plaintext
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 103]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext. This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-F.5 Denial of Service
-
-       TLS is susceptible to a number of denial of service (DoS)
-       attacks.  In particular, an attacker who initiates a large number
-       of TCP connections can cause a server to consume large amounts of
-       CPU doing RSA decryption. However, because TLS is generally used
-       over TCP, it is difficult for the attacker to hide his point of
-       origin if proper TCP SYN randomization is used [SEQNUM] by the
-       TCP stack.
-
-       Because TLS runs over TCP, it is also susceptible to a number of
-       denial of service attacks on individual connections. In
-       particular, attackers can forge RSTs, terminating connections, or
-       forge partial TLS records, causing the connection to stall.
-       These attacks cannot in general be defended against by a TCP-
-       using protocol. Implementors or users who are concerned with this
-       class of attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 104]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-Normative References
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [HTTP]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
-            L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
-            Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [IDNA]    Faltstrom, P., Hoffman, P. and A. Costello,
-            "Internationalizing Domain Names in Applications (IDNA)",
-            RFC 3490, March 2003.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [OCSP]   Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-            Adams, "Internet X.509 Public Key Infrastructure: Online
-            Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
-            RSA Cryptography Specifications Version 1.5", RFC 2313,
-            March 1998.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 105]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIOP]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
-            Infrastructure - Operation Protocols: FTP and HTTP", RFC
-            2585, May 1999.
-
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-            Considerations Section in RFCs", RFC 3434, October 1998.
-
-   [TLSAES] Chown, P. "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M, Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.
-   [TLSKRB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to
-            Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-
-   [URI]    Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-            Resource Identifiers (URI): Generic Syntax", RFC 2396,
-            August 1998.
-
-   [UTF8]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
-            RFC 3629, November 2003.
-
-   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 106]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-            "Information Systems - Open Systems Interconnection - The
-            Directory:  Public key and Attribute certificate
-            frameworks."
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-            ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
-            ISO/IEC 9594:8:2001.
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "Authenticated Encryption", July 2006, draft-
-            mcgrew-auth-enc-00.txt.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            2402, November 1998.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [CCM]     "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 2406, November 1998.
-
-   [GCM]    "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 107]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM] D. Eastlake 3rd, S. Crocker, J. Schiller. "Randomness
-            Recommendations for Security", RFC 1750, December 1994.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] R. Zuccherato, "Methods for Avoiding the Small-Subgroup
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLS1.0] Dierks, T., and Allen, C., "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and Rescorla, E., "The TLS Protocol, Version
-            1.1", RFC 4346, April, 2006.
-
-   [X501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
-            Open Systems Interconnection - "The Directory -
-            Authentication Framework". 1988.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, "XDR: External Data
-            Representation Standard", RFC 1832, August 1995.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 108]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-Credits
-
-   Working Group Chairs
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 109]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 110]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-       <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 111]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-   Intellectual Property Statement
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed to
-      pertain to the implementation or use of the technology described in
-      this document or the extent to which any license under such rights
-      might or might not be available; nor does it represent that it has
-      made any independent effort to identify any such rights.  Information
-      on the procedures with respect to rights in RFC documents can be
-      found in BCP 78 and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use of
-      such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository at
-      http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention any
-      copyrights, patents or patent applications, or other proprietary
-      rights that may cover technology that may be required to implement
-      this standard.  Please address the information to the IETF at
-      ietf-ipr@ietf.org.
-
-
-   Disclaimer of Validity
-
-      This document and the information contained herein are provided on an
-      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-      OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-      ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-      INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-      INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-   Copyright Statement
-
-      Copyright (C) The Internet Society (2006).  This document is subject
-      to the rights, licenses and restrictions contained in BCP 78, and
-      except as set forth therein, the authors retain all their rights.
-
-
-   Acknowledgment
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 112]draft-ietf-tls-rfc4346-bis-02.txt  TLS                      October 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 113]
-
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-03.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-03.txt
deleted file mode 100644
index e41c5b412b..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-03.txt
+++ /dev/null
@@ -1,5189 +0,0 @@
-
-
-
-
-
-
-                                                              Tim Dierks
-                                                             Independent
-                                                           Eric Rescorla
-INTERNET-DRAFT                                   Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-03.txt>  March 2007 (Expires September 2007)
-
-                            The TLS Protocol
-                              Version 1.2
-
-Status of this Memo
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2007).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction                                                3
-   1.1       Requirements Terminology                                    4
-   1.2       Major Differences from TLS 1.1                              5
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   2.        Goals                                                       5
-   3.        Goals of This Document                                      6
-   4.        Presentation Language                                       6
-   4.1.      Basic Block Size                                            6
-   4.2.      Miscellaneous                                               7
-   4.3.      Vectors                                                     7
-   4.4.      Numbers                                                     8
-   4.5.      Enumerateds                                                 8
-   4.6.      Constructed Types                                           9
-   4.6.1.    Variants                                                    9
-   4.7.      Cryptographic Attributes                                    10
-   4.8.      Constants                                                   12
-   5.        HMAC and the Pseudorandom fFunction                         12
-   6.        The TLS Record Protocol                                     14
-   6.1.      Connection States                                           14
-   6.2.      Record layer                                                17
-   6.2.1.    Fragmentation                                               17
-   6.2.2.    Record Compression and Decompression                        18
-   6.2.3.    Record Payload Protection                                   19
-   6.2.3.1.  Null or Standard Stream Cipher                              19
-   6.2.3.2.  CBC Block Cipher                                            20
-   6.2.3.3.  AEAD ciphers                                                22
-   6.3.      Key Calculation                                             23
-   7.        The TLS Handshaking Protocols                               24
-   7.1.      Change Cipher Spec Protocol                                 25
-   7.2.      Alert Protocol                                              25
-   7.2.1.    Closure Alerts                                              26
-   7.2.2.    Error Alerts                                                27
-   7.3.      Handshake Protocol Overview                                 30
-   7.4.      Handshake Protocol                                          34
-   7.4.1.    Hello Messages                                              35
-   7.4.1.1.  Hello Request                                               35
-   7.4.1.2.  Client Hello                                                36
-   7.4.1.3.  Server Hello                                                39
-   7.4.1.4   Hello Extensions                                            40
-   7.4.1.4.1 Cert Hash Types                                             42
-   7.4.2.    Server Certificate                                          42
-   7.4.3.    Server Key Exchange Message                                 44
-   7.4.4.    Certificate Request                                         46
-   7.4.5     Server hello done                                           47
-   7.4.6.    Client Certificate                                          48
-   7.4.7.    Client Key Exchange Message                                 48
-   7.4.7.1.  RSA Encrypted Premaster Secret Message                      49
-   7.4.7.1.  Client Diffie-Hellman Public Value                          51
-   7.4.8.    Certificate verify                                          52
-   7.4.9.    Finished                                                    52
-   8.        Cryptographic Computations                                  53
-   8.1.      Computing the Master Secret                                 54
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   8.1.1.    RSA                                                         54
-   8.1.2.    Diffie-Hellman                                              54
-   9.        Mandatory Cipher Suites                                     54
-   A.        Protocol Constant Values                                    58
-   A.1.      Record Layer                                                58
-   A.2.      Change Cipher Specs Message                                 59
-   A.3.      Alert Messages                                              59
-   A.4.      Handshake Protocol                                          61
-   A.4.1.    Hello Messages                                              61
-   A.4.2.    Server Authentication and Key Exchange Messages             62
-   A.4.3.    Client Authentication and Key Exchange Messages             63
-   A.4.4.    Handshake Finalization Message                              64
-   A.5.      The CipherSuite                                             64
-   A.6.      The Security Parameters                                     67
-   B.        Glossary                                                    69
-   C.        CipherSuite Definitions                                     73
-   D.        Implementation Notes                                        75
-   D.1       Random Number Generation and Seeding                        75
-   D.2       Certificates and Authentication                             75
-   D.3       CipherSuites                                                75
-   E.        Backward Compatibility                                      76
-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0                  76
-   E.2       Compatibility with SSL 2.0                                  77
-   E.2.      Avoiding Man-in-the-Middle Version Rollback                 79
-   F.        Security Analysis                                           80
-   F.1.      Handshake Protocol                                          80
-   F.1.1.    Authentication and Key Exchange                             80
-   F.1.1.1.  Anonymous Key Exchange                                      80
-   F.1.1.2.  RSA Key Exchange and Authentication                         81
-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication             81
-   F.1.2.    Version Rollback Attacks                                    82
-   F.1.3.    Detecting Attacks Against the Handshake Protocol            83
-   F.1.4.    Resuming Sessions                                           83
-   F.1.5     Extensions                                                  83
-   F.2.      Protecting Application Data                                 84
-   F.3.      Explicit IVs                                                84
-   F.4.      Security of Composite Cipher Modes                          84
-   F.5       Denial of Service                                           85
-   F.6.      Final Notes                                                 86
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-   of protocols which run on top of TLS.
-
-1.1 Requirements Terminology
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   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 [RFC2119].
-
-1.2 Major Differences from TLS 1.1
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-     - Merged in TLS Extensions definition and AES Cipher Suites from
-     external documents.
-
-     - Replacement of MD5/SHA-1 combination in the PRF. Addition
-     of cipher-suite specified PRFs.
-
-     - Replacement of MD5/SHA-1 combination in the digitally-signed
-     element.
-
-     - Allow the client to indicate which hash functions it supports
-     for digital signature.
-
-     - Allow the server to indicate which hash functions it supports
-     for digital signature.
-
-     - Addition of support for authenticated encryption with additional
-     data modes.
-
-     - Tightened up a number of requirements.
-
-     - The usual clarifications and editorial work.
-
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that can successfully exchange
-       cryptographic parameters without knowledge of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: preventing
-       the need to create a new protocol (and risking the introduction
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       of possible new weaknesses) and avoiding the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions). This
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only; it has
-   no have general application beyond that particular goal.
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e., 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream, a multi-byte item (a numeric in the
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type, T' that is a fixed-
-   length vector of type T is
-
-       T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream. The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length. A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two-byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17-byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors. In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic Attributes
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B].  As
-   discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for
-   digest algorithms without parameters (which include SHA-1) the
-   DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but
-   implementations MUST accept both without parameters and with NULL
-   parameters. Note that earlier versions of TLS used a different RSA
-   signature scheme which did not include a DigestInfo encoding.
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and the output is
-   generally larger than the input in order to accomodate the integrity
-   check value.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1B].
-
-   In the following example
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   the contents of hash are used as input for the signing algorithm, and
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to two bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   because the algorithm and key used for the signing are known prior to
-   encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the Pseudorandom fFunction
-
-   A number of operations in the TLS record and handshake layer requires
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction TLS provides for this operation is known as
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   HMAC and is described in [HMAC]. Cipher suites MAY define their own
-   MACs.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-   We define one PRF, based on HMAC, which is used for all cipher suites
-   in this document. Cipher suites MAY define their own PRFs.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 is being used to
-   create 64 bytes of data, it will have to be iterated 4 times (through
-   A(4)), creating 80 bytes of output data; the last 16 bytes of the
-   final iteration will then be discarded, leaving 64 bytes of output
-   data.
-
-   TLS's PRF is created by applying P_hash to the secret S as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   All the cipher suites defined in this document and in TLS documents
-   prior to this document MUST use SHA-256 as the basis for their PRF.
-   New cipher suites MUST specify a PRF and in general SHOULD use the
-   TLS PRF with SHA-256 or a stronger standard hash function.
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, and then
-   delivered to higher-level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. New record type values are assigned
-   by IANA as described in Section 11.
-
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it.  Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.  Implementations MUST not
-   send record types not defined in this document unless negotiated by
-   some extension.
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys for the
-   connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state that has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block, stream, or AEAD cipher, and the
-       block size of the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash that is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48-byte secret shared between the two peers in the connection.
-
-   client random
-       A 32-byte value provided by the client.
-
-   server random
-       A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
-
-       /* The use of "sha" above is historical and denotes SHA-1 */
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  enc_key_length;
-           uint8                  block_length;
-           uint8                  iv_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  mac_length;
-           uint8                  mac_key_length;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever state information is necessary to
-       allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection, as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number, it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record transmitted under a
-       particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher-level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.2, which uses the version { 3, 3 }. The
-       version value 3.3 is historical, deriving from the use of 3.1 for
-       TLS 1.0. (See Appendix A.1).  Note that a client that supports
-       multiple versions of TLS may not know what version will be
-       employed before it receives ServerHello.  See Appendix E for
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       discussion about what record layer version number should be
-       employed for ClientHello.
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length MUST not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher-level protocol
-       specified by the type field.
-
-       Implementations MUST not send zero-length fragments of Handshake,
-       Alert, or Change Cipher Spec content types. Zero-length fragments
-       of Application data MAY be sent as they are potentially useful as
-       a traffic analysis countermeasure.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved.  Application data is generally of lower precedence
-       for transmission than other content types.  However, records MUST
-       be delivered to the network in the same order as they are
-       protected by the record layer.  Recipients MUST receive and
-       process interleaved application layer traffic during handshakes
-       subsequent to the first one on a connection.
-
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record Payload Protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (SecurityParameters.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-               case aead: GenericAEADCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted,
-   and the MAC size is zero, implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   SecurityParameters.mac_length.
-
-6.2.3.2. CBC Block Cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-       block-ciphered struct {
-           opaque IV[SecurityParameters.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   IV
-       TLS 1.2 uses an explicit IV in order to prevent the attacks
-       described by [CBCATT]. The IV SHOULD be chosen at random and MUST
-       be unpredictable.  In order to decrypt, thereceiver decrypts the
-       entire GenericBlockCipher structure and then discards the first
-       cipher block, corresponding to the IV component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes, as long as it results
-       in the TLSCiphertext.length being an integral multiple of the
-       block length. Lengths longer than necessary might be desirable to
-       frustrate attacks on a protocol based on analysis of the lengths
-       of exchanged messages. Each uint8 in the padding data vector MUST
-       be filled with the padding length value. The receiver MUST check
-       this padding and SHOULD use the bad_record_mac alert to indicate
-       padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, SecurityParameters.mac_length, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, then the length before padding is 82 bytes (this does
-          not include the IV, which may or may not be encrypted, as
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise, it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
- Implementation Note: Canvel et al. [CBCTIME] have demonstrated a timing
-       attack on CBC padding based on the time required to compute the
-       MAC. In order to defend against this attack, implementations MUST
-       ensure that record processing time is essentially the same
-       whether or not the padding is correct.  In general, the best way
-       to do this is to compute the MAC even if the padding is
-       incorrect, and only then reject the packet. For instance, if the
-       pad appears to be incorrect, the implementation might assume a
-       zero-length pad and then compute the MAC. This leaves a small
-       timing channel, since MAC performance depends to some extent on
-       the size of the data fragment, but it is not believed to be large
-       enough to be exploitable, due to the large block size of existing
-       MACs and the small size of the timing signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-       aead-ciphered struct {
-           opaque IV[SecurityParameters.iv_length];
-           opaque aead_output[AEADEncrypted.length];
-       } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD].  These inputs are as follows.
-
-   The key is either the client_write_key or the server_write_key.  The
-   MAC key will be of length zero.
-
-   The nonce supplied to the AEAD operations is determined by the IV in
-   aead-ciphered struct. Each IV used in distinct invocations of the
-   AEAD encryption operation MUST be distinct, for any fixed value of
-   the key.  Implementations SHOULD use the recommended nonce formation
-   method of [AEAD] to generate IVs, and MAY use any other method that
-   meets this requirement.  The length of the IV depends on the AEAD
-   cipher; that length MAY be zero. Note that in many cases it is
-   appropriate to use the partially implicit nonce technique of S 3.2.1
-   of AEAD, in which case the client_write_iv and server_write_iv should
-   be used as the "fixed-common".
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  AEADEncrypted.length will generally be larger
-   than TLSCompressed.length, but by an amount that varies with the AEAD
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-      AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
-                      additional_data)
-
-   Where "+" denotes concatenation.
-
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   IV, the "additional_data", and the AEADEncrypted value. The output is
-   either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-   TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
-                   TLSCiphertext.type + TLSCiphertext.version +
-                   TLSCiphertext.length);
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, each of which is generated from the master secret
-   in that order. Unused values are empty.
-
-   When keys and MAC secrets are generated, the master secret is used as
-   an entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.mac_key_length]
-       server_write_MAC_secret[SecurityParameters.mac_key_length]
-       client_write_key[SecurityParameters.enc_key_length]
-       server_write_key[SecurityParameters.enc_key_length]
-
-
-   Implementation note:
-       The currently defined cipher suite which requires the most
-       material is AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x
-       32 byte keys and 2 x 20 byte MAC secrets, for a total 104 bytes
-       of key material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols that are used to allow peers to agree
-       upon security parameters for the record layer, to authenticate
-       themselves, to instantiate negotiated security parameters, and to
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [X509] certificate of the peer. This element of the
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the hash_size. (See
-         Appendix A.6 for formal definition,)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see Section 7.4.11
-
- Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g., if it has to perform a time consuming public
-   key operation). Thus, a small window of time, during which the
-   recipient must buffer the data, MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed_RESERVED(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED(41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           unsupported_extension(110),           /* new */
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed. The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed_RESERVED
-       This alert was used in some earlier versions of TLS, and may have
-       permitted certain attacks against the CBC mode [CBCATT].  It MUST
-       NOT be sent by compliant implementations.
-
-   record_overflow
-       A TLSCiphertext record was received that had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g., data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not any version of TLS.  It MUST
-       NOT be sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in some earlier versions of TLS.  It MUST NOT
-       be sent by compliant implementations.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized but not supported. (For example, old protocol versions
-       might be avoided for security reasons). This message is always
-       fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol (such as a memory allocation failure) makes it
-       impossible to continue. This message is always fatal.
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert.
-       At that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate is where a server has spawned a process to satisfy a
-       request; the process might receive security parameters (key
-       length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   unsupported_extension
-       sent by clients that receive an extended server hello containing
-       an extension that they did not put in the corresponding client
-       hello (see Section 2.3).  This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not.  However, all messages which are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New Alert values are assigned by IANA as described in Section 11.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-     -  Exchange certificates and cryptographic information to allow the
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man in the middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support. The protocol has been designed to
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection. The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require. The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 48 to 128 bytes in
-   length.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g., if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Next,
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify possession of the private
-   key in the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   Cipher Spec. At this point, the handshake is complete, and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               CertificateStatus*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      CertificateURL*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   perform a full handshake.
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20)
-        (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message that is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message types are assigned by IANA as described in
-   Section 11.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello Request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message is not intended to
-       establish which side is the client or server but merely to
-       initiate a new negotiation. Servers SHOULD not send a
-       HelloRequest immediately upon the client's initial connection.
-       It is the client's job to send a ClientHello at that time.
-
-       This message will be ignored by the client if the client is
-       currently negotiating a session. This message may be ignored by
-       the client if it does not wish to renegotiate a session, or the
-       client may, if it wishes, respond with a no_renegotiation alert.
-       Since handshake messages are intended to have transmission
-       precedence over application data, it is expected that the
-       negotiation will begin before no more than a few records are
-       received from the client. If the server sends a hello request but
-       does not receive a client hello in response, it may close the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes that are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-   Structure of this message:
-       The client hello message includes a random structure, which is
-       used later in the protocol.
-
-       struct {
-          uint32 gmt_unix_time;
-          opaque random_bytes[28];
-       } Random;
-
-   gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher-
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable-length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or from another currently active connection. The second
-   option is useful if the client only wishes to update the random
-   structures and derived values of a connection, and the third option
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   makes it possible to establish several independent secure connections
-   without repeating the full handshake protocol. These independent
-   connections may occur sequentially or simultaneously; a SessionID
-   becomes valid when the handshake negotiating it completes with the
-   exchange of Finished messages and persists until it is removed due to
-   aging or because a fatal error was encountered on a connection
-   associated with the session. The actual contents of the SessionID are
-   defined by the server.
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-           select (extensions_present) {
-               case false:
-                   struct {};
-               case true:
-                   Extension extensions<0..2^16-1>;
-           }
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       } ClientHello;
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block. The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello. Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field but is used for compatibility with TLS before
-   extensions were defined.
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.3 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available, or it
-       the client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it MUST include
-       the compression_method from that session. This vector MUST
-       contain, and all implementations MUST support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   client_hello_extension_list
-       Clients MAY request extended functionality from servers by
-       sending data in the client_hello_extension_list.  Here the new
-       "client_hello_extension_list" field contains a list of
-       extensions.  The actual "Extension" format is defined in Section
-       7.4.1.4.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-   client MAY abort the handshake.  A server that supports the
-   extensions mechanism MUST accept only client hello messages in either
-   the original (TLS 1.0/TLS 1.1) ClientHello or the extended
-   ClientHello format defined in this document, and (as for all other
-   messages) MUST check that the amount of data in the message precisely
-   matches one of these formats; if not then it MUST send a fatal
-   "decode_error" alert.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-
-7.4.1.3. Server Hello
-
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-           struct {
-               ProtocolVersion server_version;
-               Random random;
-               SessionID session_id;
-               CipherSuite cipher_suite;
-               CompressionMethod compression_method;
-               select (extensions_present) {
-                   case false:
-                       struct {};
-                   case true:
-                       Extension extensions<0..2^16-1>;
-               }
-           } ServerHello;
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.2.  (See
-       Appendix E for details about backward compatibility.)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with. Note that there is no requirement
-       that the server resume any session even if it had formerly
-       provided a session_id. Client MUST be prepared to do a full
-       negotiation -- including negotiating new cipher suites -- during
-       any handshake.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions, this field is
-       the value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-   server_hello_extension_list
-       A list of extensions. Note that only extensions offered by the
-       client can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format is:
-
-         struct {
-             ExtensionType extension_type;
-             opaque extension_data<0..2^16-1>;
-         } Extension;
-
-         enum {
-             cert_hash_types(TBD-BY-IANA), (65535)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-         } ExtensionType;
-
-
-   Here:
-
-     - "extension_type" identifies the particular extension type.
-
-     - "extension_data" contains information specific to the particular
-   extension type.
-
-   The list of extension types, as defined in Section 2.3, is maintained
-   by the Internet Assigned Numbers Authority (IANA). Thus an
-   application needs to be made to the IANA in order to obtain a new
-   extension type value. Since there are subtle (and not so subtle)
-   interactions that may occur in this protocol between new features and
-   existing features which may result in a significant reduction in
-   overall security, new values SHALL be defined only through the IETF
-   Consensus process specified in [IANA].  (This means that new
-   assignments can be made only via RFCs approved by the IESG.) The
-   initial set of extensions is defined in a companion document [TBD].
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-     -  Some cases where a server does not agree to an extension are
-   error
-       conditions, and some simply a refusal to support a particular
-       feature.  In general error alerts should be used for the former,
-       and a field in the server extension response for the latter.
-
-     -  Extensions should as far as possible be designed to prevent any
-       attack that forces use (or non-use) of a particular feature by
-       manipulation of handshake messages.  This principle should be
-       followed regardless of whether the feature is believed to cause a
-       security problem.
-
-       Often the fact that the extension fields are included in the
-       inputs to the Finished message hashes will be sufficient, but
-       extreme care is needed when the extension changes the meaning of
-       messages sent in the handshake phase. Designers and implementors
-       should be aware of the fact that until the handshake has been
-       authenticated, active attackers can modify messages and insert,
-       remove, or replace extensions.
-
-     -  It would be technically possible to use extensions to change
-       major aspects of the design of TLS; for example the design of
-       cipher suite negotiation.  This is not recommended; it would be
-       more appropriate to define a new version of TLS - particularly
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       since the TLS handshake algorithms have specific protection
-       against version rollback attacks based on the version number, and
-       the possibility of version rollback should be a significant
-       consideration in any major design change.
-
-7.4.1.4.1 Cert Hash Types
-
-       The client MAY use the "cert_hash_types" to indicate to the
-       server which hash functions may be used in the signature on the
-       server's certificate. The "extension_data" field of this
-       extension contains:
-
-             enum{
-                 md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
-             } HashType;
-
-             struct {
-                   HashType types<255>;
-             } CertHashTypes;
-
-   These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
-   and SHA-512 [SHA] respectively. The server MUST NOT send this
-   extension.
-
-   Clients SHOULD send this extension if they support any algorithm
-   other than SHA-1. If this extension is not used, servers SHOULD
-   assume that the client supports only SHA-1. Note: this is a change
-   from TLS 1.1 where there are no explicit rules but as a practical
-   matter one can assume that the peer supports MD5 and SHA-1.
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method uses certificates for authentication (this
-       includes all key exchange methods defined in this document except
-       DH_anon).  This message will always immediately follow the server
-       hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-       certificate. It MUST contain a key that matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key that can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles, and key and cryptographic formats are
-   defined by the IETF PKIX working group [PKIX]. When a key usage
-   extension is present, the digitalSignature bit MUST be set for the
-   key to be eligible for signing, as described above, and the
-   keyEncipherment bit MUST be present to allow encryption, as described
-   above. The keyAgreement bit must be set on Diffie-Hellman
-   certificates.
-
-   As CipherSuites that specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate that specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret) or a public key for
-       some other algorithm.
-
-   As additional CipherSuites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-   If the SignatureAlgorithm being used to sign the ServerKeyExchange
-   message is DSA, the hash function used MUST be SHA-1. If the
-   SignatureAlgorithm it must be the same hash function used in the
-   signature of the server's certificate (found in the Certificate)
-   message. This algorithm is denoted Hash below. Hash.length is the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   length of the output of that algorithm.
-
-   Structure of this message:
-       enum { diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-           };
-        } ServerParams;
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       hash
-           Hash(ClientHello.random + ServerHello.random + ServerParams)
-
-       sha_hash
-           SHA1(ClientHello.random + ServerHello.random + ServerParams)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       struct {
-           select (SignatureAlgorithm) {
-               case anonymous: struct { };
-               case rsa:
-                   digitally-signed struct {
-                       opaque hash[Hash.length];
-                   };
-               case dsa:
-                   digitally-signed struct {
-                       opaque sha_hash[20];
-                   };
-               };
-           };
-       } Signature;
-
-7.4.4. Certificate Request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-           rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-           fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           HashType certificate_hash<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       certificate_types
-           A list of the types of certificate types which the client may
-           offer.
-              rsa_sign        a certificate containing an RSA key
-              dss_sign        a certificate containing a DSS key
-              rsa_fixed_dh    a certificate signed with RSA and containing
-                              a static DH key.
-              dss_fixed_dh    a certificate signed with DSS and containing
-                              a static DH key
-
-           Certificate types rsa_sign and dss_sign SHOULD contain
-           certificates signed with the same algorithm. However, this is
-           not required. This is a holdover from TLS 1.0 and 1.1.
-
-
-       certificate_hash
-           A list of acceptable hash algorithms to be used in
-           certificate signatures.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
- New ClientCertificateType values are assigned by IANA as described in
-           Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were
-           used in SSLv3.
-
-
- Note: DistinguishedName is derived from [X501]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.5 Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       sending this message, the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message, the client SHOULD
-       verify that the server provided a valid certificate, if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client Certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client SHOULD send a certificate message
-       containing no certificates. That is, the certificate_list
-       structure has a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate MUST match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client Key Exchange Message
-
-   When this message will be sent:
-       This message is always sent by the client. It MUST immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it MUST be the first message sent by the client after it receives
-       the server hello done message.
-
-   Meaning of this message:
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters that will allow each
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate that contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate and sends the result
-       in an encrypted premaster secret message. This structure is a
-       variant of the client key exchange message and is not a message
-       in itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
-   An attack discovered by Daniel Bleichenbacher [BLEI] can be used to
-   attack a TLS server which is using PKCS#1 v 1.5 encoded RSA. The
-   attack takes advantage of the fact that by failing in different ways,
-   a TLS server can be coerced into revealing whether a particular
-   message, when decrypted, is properly PKCS#1 v1.5 formatted or not.
-
-   In order to avoid this vulnerability, implementations MUST treat
-   incorrectly formatted messages in a manner indistinguishable from
-   correctly formatted RSA blocks. Thus, when it receives an incorrectly
-   formatted RSA block, a server should generate a random 48-byte value
-   and proceed using it as the premaster secret. Thus, the server will
-   act identically whether the received RSA block is correctly encoded
-   or not.
-
-   [PKCS1B] defines a newer version of PKCS#1 encoding that is more
-   secure against the Bleichenbacher attack. However, for maximal
-   compatibility with TLS 1.0, TLS 1.1 retains the original encoding. No
-   variants of the Bleichenbacher attack are known to exist provided
-   that the above recommendations are followed.
-
- Implementation Note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes. These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined. The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the the length bytes, encoding the RSA encrypted data
-   directly in the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes. The resulting
-   PDU is incompatible with many SSLv3 implementations. Implementors
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding. Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-   behavior dependent on the protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-   on SSL are possible, at least when the client and server are on the
-   same LAN. Accordingly, implementations that use static RSA keys MUST
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
- Note: The version number in the PreMasterSecret MUST be the version
-   offered by the client in the ClientHello.version, not the version
-   negotiated for the connection. This feature is designed to prevent
-   rollback attacks. Unfortunately, many implementations use the
-   negotiated version instead and therefore checking the version number
-   may lead to failure to interoperate with such incorrect client
-   implementations. Client implementations MUST and Server
-   implementations MAY check the version number. In practice, since the
-   TLS handshake MACs prevent downgrade and no good attacks are known on
-   those MACs, ambiguity is not considered a serious security risk.
-   Note that if servers choose to to check the version number, they MUST
-   randomize the PreMasterSecret in case of error, rather than generate
-   an alert, in order to avoid variants on the Bleichenbacher attack.
-   [KPR03]
-
-7.4.7.1. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, and not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but it MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3. If the SignatureAlgorithm
-       is DSA, then the sha_hash value must be used. If it is RSA,
-       the same function (denoted Hash) must be used as was used to
-       create the signature for the client's certificate.
-
-       CertificateVerify.signature.hash
-           Hash(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, Hash(handshake_messages))[0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-           Hash denotes the negotiated hash used for the PRF. If a new
-           PRF is defined, then this hash MUST be specified.
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.9 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and, any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   the master secret.
-
-8.1. Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-11. Security Considerations
-
-   Security issues are discussed throughoutthis memo, especially in
-   Appendices D, E, and F.
-
-12. IANA Considerations
-
-   This document uses several registries that were originally created in
-   [RFC4346]. IANA is requested to update (has updated) these to
-   reference this document. The registries and their allocation policies
-   (unchanged from [RFC4346]) are listed below.
-
-   o  TLS ClientCertificateType Identifiers Registry: Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434]. Values in the range 64-223
-      (decimal) inclusive are assigned Specification Required
-      [RFC2434]. Values from 224-255 (decimal) inclusive are
-      reserved for Private Use [RFC2434].
-
-   o  TLS Cipher Suite Registry: Future values with the first byte
-      in the range 0-191 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values with the first byte in
-      the range 192-254 (decimal) are assigned via Specification
-      Required [RFC2434]. Values with the first byte 255 (decimal)
-      are reserved for Private Use [RFC2434].
-
-   o  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   o  TLS Alert Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   o  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA is requested to update (has updated) it to reference this
-   document.  The registry and its allocation policy (unchanged from
-   [RFC4366]) is listed below:.
-
-   o  TLS ExtensionType Registry: Future values are allocated
-      via IETF Consensus [RFC2434]
-
-   In addition, this document defines one new registry to be maintained
-   by IANA:
-
-   o  TLS HashType Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.7.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-      Future values in the range 0-63 (decimal) inclusive are
-      assigned via Standards Action [RFC2434].  Values in the
-      range 64-223 (decimal) inclusive are assigned via
-      Specification Required [RFC2434].  Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   This document defines one new TLS extension, cert_hash_type, which is
-   to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
-   registry.
-
-
-12.1 Extensions
-
-   Section 11 describes a registry of ExtensionType values to be
-   maintained by the IANA. ExtensionType values are to be assigned via
-   IETF Consensus as defined in RFC 2434 [IANA]. The initial registry
-   corresponds to the definition of "ExtensionType" in Section 2.3.
-
-   The MIME type "application/pkix-pkipath" has been registered by the
-   IANA with the following template:
-
-      To: ietf-types@iana.org Subject: Registration of MIME media type
-      application/pkix-pkipath
-
-      MIME media type name: application
-      MIME subtype name: pkix-pkipath
-
-      Optional parameters: version (default value is "1")
-
-      Encoding considerations:
-         This MIME type is a DER encoding of the ASN.1 type PkiPath,
-         defined as follows:
-           PkiPath ::= SEQUENCE OF Certificate
-           PkiPath is used to represent a certification path.  Within the
-           sequence, the order of certificates is such that the subject of
-           the first certificate is the issuer of the second certificate,
-           etc.
-
-         This is identical to the definition published in [X509-4th-TC1];
-         note that it is different from that in [X509-4th].
-
-         All Certificates MUST conform to [PKIX].  (This should be
-         interpreted as a requirement to encode only PKIX-conformant
-         certificates using this type.  It does not necessarily require
-         that all certificates that are not strictly PKIX-conformant must
-         be rejected by relying parties, although the security consequences
-         of accepting any such certificates should be considered
-         carefully.)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-         DER (as opposed to BER) encoding MUST be used.  If this type is
-         sent over a 7-bit transport, base64 encoding SHOULD be used.
-
-      Security considerations:
-         The security considerations of [X509-4th] and [PKIX] (or any
-         updates to them) apply, as well as those of any protocol that uses
-         this type (e.g., TLS).
-
-         Note that this type only specifies a certificate chain that can be
-         assessed for validity according to the relying party's existing
-         configuration of trusted CAs; it is not intended to be used to
-         specify any change to that configuration.
-
-      Interoperability considerations:
-         No specific interoperability problems are known with this type,
-         but for recommendations relating to X.509 certificates in general,
-         see [PKIX].
-
-      Published specification: this memo, and [PKIX].
-
-      Applications which use this media type: TLS.  It may also be used by
-         other protocols, or for general interchange of PKIX certificate
-
-      Additional information:
-         Magic number(s): DER-encoded ASN.1 can be easily recognized.
-           Further parsing is required to distinguish from other ASN.1
-           types.
-         File extension(s): .pkipath
-         Macintosh File Type Code(s): not specified
-
-      Person & email address to contact for further information:
-         Magnus Nystrom <magnus@rsasecurity.com>
-
-      Intended usage: COMMON
-
-      Change controller:
-         IESG <iesg@ietf.org>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-Appendix A. Protocol Constant Values
-
-   This section describes protocol types and constants.
-
-A.1. Record Layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (SecurityParameters.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-            case aead: GenericAEADCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[SecurityParameters.mac_length];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-        opaque IV[SecurityParameters.block_length];
-        opaque content[TLSCompressed.length];
-        opaque MAC[SecurityParameters.mac_length];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-    aead-ciphered struct {
-        opaque IV[SecurityParameters.iv_length];
-        opaque aead_output[AEADEncrypted.length];
-    } GenericAEADCipher;
-
-A.2. Change Cipher Specs Message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED (41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            unsupported_extension(110),           /* new */
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-A.4. Handshake Protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20)
-     (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello Messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-        CompressionMethod compression_methods<1..2^8-1>;
-        Extension client_hello_extension_list<0..2^16-1>;
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-    struct {
-        ExtensionType extension_type;
-        opaque extension_data<0..2^16-1>;
-    } Extension;
-
-    enum {
-        cert_hash_types(TBD-BY-IANA), (65535)
-    } ExtensionType;
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    struct {
-        CertificateStatusType status_type;
-        select (status_type) {
-            case ocsp: OCSPResponse;
-        } response;
-    } CertificateStatus;
-
-    opaque OCSPResponse<1..2^24-1>;
-
-    enum { diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-            case anonymous: struct { };
-            case rsa:
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-            case dsa:
-                digitally-signed struct {
-                    opaque sha_hash[20];
-                };
-            };
-        };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-    struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-    CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x2F };
-    CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x35 };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-    CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA        = { 0x00, 0x30 };
-    CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA        = { 0x00, 0x31 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x32 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x33 };
-    CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA        = { 0x00, 0x36 };
-    CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA        = { 0x00, 0x37 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x38 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x39 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks.  Using
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   this mode therefore is of limited use: These ciphersuites MUST NOT be
-   used by TLS 1.2 implementations unless the application layer has
-   specifically requested to allow anonymous key exchange.  (Anonymous
-   key exchange may sometimes be acceptable, for example, to support
-   opportunistic encryption when no set-up for authentication is in
-   place, or when TLS is used as part of more complex security protocols
-   that have other means to ensure authentication.)
-
-     CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00, 0x18 };
-     CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00, 0x1A };
-     CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x1B };
-     CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
-     CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.2 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.2 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.2 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.2 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-
- New cipher suite values are assigned by IANA as described in Section
-   11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 enc_key_length;
-           uint8 block_length;
-           uint8 iv_length;
-           MACAlgorithm mac_algorithm;
-           uint8 mac_length;
-           uint8 mac_key_length;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.  AES is a
-       block cipher with a 128, 192, or 256 bit keys and a 16 byte block
-       size. [AES] TLS currently only supports the 128 and 256 bit key
-       sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-       A symmetric encryption algorithm that simultaneously provides
-       confidentiality and message integrity.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer-to-peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard", published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters that can be shared among
-       multiple connections. Sessions are used to avoid the expensive
-       negotiation of new security parameters for each connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-Appendix C. CipherSuite Definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_SHA                RSA            AES_256_CBC  SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm.
-
-   IV Size
-       The amount of data needed to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. Seeding a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-Appendix E. Backward Compatibility
-
-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client support the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version. If the server does not support this
-   version, it will respond with ServerHello containing an older version
-   number. If the client agrees to use this version, the negotiation
-   will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing version number
-   smaller than the highest supported version. If the server wishes to
-   negotiate with old clients, it will proceed as appropriate for the
-   highest version supported by the server that is not greater than
-   ClientHello.client_version. For example, if the server supports TLS
-   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing
-   to use) only versions greater than client_version, it MUST send a
-   "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
- Note: some server implementations are known to implement version
-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   that simply close the connection when the client offers a version
-   newer than TLS 1.0. Also, it is known that some servers will refuse
-   connection if any TLS extensions are included in ClientHello.
-   Interoperability with such buggy servers is a complex topic beyond
-   the scope of this document, and may require multiple connection
-   attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed). Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number. Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version. No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2 Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
-   contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS ciphersuites in the
-   CIPHER-SPECS-DATA field as described below.
-
-Warning: The ability to send version 2.0 CLIENT-HELLO messages will be
-   phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-   However, even TLS servers that do not support SSL 2.0 SHOULD accept
-   version 2.0 CLIENT-HELLO messages. The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions. Note that this message MUST be sent directly on the wire,
-   not wrapped as a TLS record. For the purposes of calculating Finished
-   and CertificateVerify, the msg_length field is not considered to be a
-   part of the handshake message.
-
-       uint8 V2CipherSpec[3];
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       The highest bit MUST be 1; the remaining bits contain the
-       length of the following data in bytes.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-       version 2 client hello message. The value SHOULD be one (1).
-
-   version
-       Equal to ClientHello.client_version.
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero. MUST be zero for a client
-       that claims to support TLS 1.2.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. Historically, permissible values are between
-       16 and 32 bytes inclusive. When using the SSLv2 backward
-       compatible handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. In addition to the 2.0 cipher specs defined in [SSL2],
-       this includes the TLS cipher suites normally sent in
-       ClientHello.cipher_suites, each cipher suite prefixed by a zero
-       byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
-       {0x00,0x00,0x0A}.
-
-   session_id
-       This field MUST be empty.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   challenge
-       Corresponds to ClientHello.random. If the challenge length is
-       less than 32, the TLS server will pad the data with leading
-       (note: not trailing) zero bytes to make it 32 bytes long.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.9 and 6.3). By sending a correct finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-   from the server key exchange message. The result is sent in a client
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key. TLS
-   users desiring Perfect Forward Secrecy should use DHE cipher suites.
-   The damage done by exposure of a private key can be limited by
-   changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.9). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly, therefore the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Altering
-   the padding of the least significant 8 bytes of the PKCS padding does
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   not impact security for the size of the signed hashes and RSA key
-   lengths used in the protocol, since this is essentially equivalent to
-   increasing the input block size by 8 bytes.
-
-F.1.3. Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5 Extensions
-
-   Security considerations for the extension mechanism in general, and
-   the design of new extensions, are described in the previous section.
-   A security analysis of each of the extensions defined in this
-   document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art, and address any weaknesses identified.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64 bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent, so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-F.4. Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions, provided that the former is secure against
-       chosen plaintext attacks and the MAC is secure against chosen-
-       message attacks.  TLS uses another method, called authenticate-
-       then-encrypt, in which first a MAC is computed on the plaintext
-       and then the concatenation of plaintext and MAC is encrypted.
-       This method has been proven secure for CERTAIN combinations of
-       encryption functions and MAC functions, but is not guaranteed to
-       be secure in general. In particular, it has been shown that there
-       exist perfectly secure encryption functions (secure even in the
-       information-theoretic sense) that combined with any secure MAC
-       function, fail to provide the confidentiality goal against an
-       active attack.  Therefore, new ciphersuites and operation modes
-       adopted into TLS need to be analyzed under the authenticate-then-
-       encrypt method to verify that they achieve the stated integrity
-       and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message, plus the length of the MAC tag, is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent, and unpredictable, IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext.  This made TLS open to chosen
-       plaintext attacks.  This verson of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure see [ENCAUTH].
-
-F.5 Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption. However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections. In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys and
-   anonymous servers should be used with great caution. Implementations
-   and users must be careful when deciding which certificates and
-   certificate authorities are acceptable; a dishonest certificate
-   authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-
-Changes in This Version
-
-   [RFC Editor: Please delete this]
-
-     - Forbid decryption_failed [issue 5]
-
-     - Fix CertHashTypes declaration [issue 20]
-
-     - Fix client_version in 7.4.1.2 [issue 19]
-
-     - Require Bleichenbacher and timing attack protection [issues 17
-   and
-     12].
-
-     - Merged RFC-editor changes back in.
-
-     - Editorial changes from NIST [issue 8]
-
-     - Clarified the meaning of HelloRequest [issue 39]
-
-     - Editorial nits from Peter Williams [issue 35]
-
-     - Made maximum fragment size a MUST [issue 9]
-
-     - Clarified that resumption is not mandatory and servers may
-     refuse [issue 37]
-
-     - Fixed identifier for cert_hash_types [issue 38]
-
-     - Forbid sending unknown record types [issue 11]
-
-     - Clarify that DH parameters and other integers are unsigned [issue
-   28]
-
-     - Clarify when a server Certificate is sent [isssue 29]
-
-     - Prohibit zero-length fragments [issue 10]
-
-     - Fix reference for DES/3DES [issue 18]
-
-     - Clean up some notes on deprecated alerts [issue 6]
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-     - Remove ephemeral RSA [issue 3]
-
-     - Stripped out discussion of how to generate the IV and replaced it
-   with a randomness/unpredictability requirement [issue 7]
-
-     - Replaced the PKCS#1 text with references to PKCS#1 v2. This also
-   includes DigestInfo encoding [issues 1 and 22]
-
-     - Removed extension definitions and merged the ExtendedHello
-   definitions [issues 31 and 32]
-
-     - Replaced CipherSpec references with SecurityParameters references
-   [issue 2]
-
-     - Cleaned up IANA text [issues 33 and 34]
-
-     - Cleaned up backward compatibility text [issue 25]
-
-Normative References
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   National Institute of Standards and Tecnology,
-            "Recommendation for the Triple Data Encryption Algorithm
-            (TDEA) Block Cipher", NIST Special Publication 800-67, May
-            2004.
-
-   [DES]    National Institute of Standards and Technology, "Data
-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication", RFC 2104, February
-            1997.
-
-   [HTTP]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
-            L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
-            Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   [IDNA]    Faltstrom, P., Hoffman, P. and A. Costello,
-            "Internationalizing Domain Names in Applications (IDNA)",
-            RFC 3490, March 2003.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [OCSP]   Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
-            Adams, "Internet X.509 Public Key Infrastructure: Online
-            Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIOP]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
-            Infrastructure - Operation Protocols: FTP and HTTP", RFC
-            2585, May 1999.
-
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, March 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,
-            October 1998.
-
-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   [TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-            Suites to Transport Layer Security (TLS)", RFC 2712, October
-            1999.
-
-   [URI]    Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-            Resource Identifiers (URI): Generic Syntax", RFC 2396,
-            August 1998.
-
-   [UTF8]   Yergeau, F., "UTF-8, a transformation format of ISO 10646",
-            RFC 3629, November 2003.
-
-   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
-            "Information Systems - Open Systems Interconnection - The
-            Directory:  Public key and Attribute certificate
-            frameworks."
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-            ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
-            ISO/IEC 9594:8:2001.
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "Authenticated Encryption", July 2006, draft-
-            mcgrew-auth-enc-00.txt.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            4302, December 2005.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [CCM]     "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 4303, December 2005.
-
-   [GCM]    "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
-            Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-            1.1", RFC 4346, April, 2006.
-
-   [X501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
-            Open Systems Interconnection - "The Directory -
-            Authentication Framework". 1988.
-
-   [XDR]    Srinivansan, R., Sun Microsystems, "XDR: External Data
-            Representation Standard", RFC 1832, August 1995.
-
-
-Credits
-
-   Working Group Chairs
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 92]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 93]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-       <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 94]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-   Full Copyright Statement
-
-      Copyright (C) The IETF Trust (2007).
-
-      This document is subject to the rights, licenses and restrictions
-      contained in BCP 78, and except as set forth therein, the authors
-      retain all their rights.
-
-      This document and the information contained herein are provided on an
-      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-      OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-      OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-   Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed to
-      pertain to the implementation or use of the technology described in
-      this document or the extent to which any license under such rights
-      might or might not be available; nor does it represent that it has
-      made any independent effort to identify any such rights.  Information
-      on the procedures with respect to rights in RFC documents can be
-      found in BCP 78 and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use of
-      such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository at
-      http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention any
-      copyrights, patents or patent applications, or other proprietary
-      rights that may cover technology that may be required to implement
-      this standard.  Please address the information to the IETF at
-      ietf-ipr@ietf.org.
-
-
-   Acknowledgment
-
-      Funding for the RFC Editor function is provided by the IETF
-      Administrative Support Activity (IASA).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 95]draft-ietf-tls-rfc4346-bis-03.txt  TLS                        March 2007
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 96]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-04.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-04.txt
deleted file mode 100644
index 8952fbe826..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-04.txt
+++ /dev/null
@@ -1,5184 +0,0 @@
-
-INTERNET-DRAFT                                                Tim Dierks
-Obsoletes (if approved): 4346                                Independent
-Intended status:  Proposed Standard                        Eric Rescorla
-                                                 Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-04.txt>     July 2007 (Expires January 2008)
-
-                            The TLS Protocol
-                              Version 1.2
-
-Status of this Memo
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2007).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction                                                3
-   1.1       Requirements Terminology                                    5
-   1.2       Major Differences from TLS 1.1                              5
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   2.        Goals                                                       5
-   3.        Goals of This Document                                      6
-   4.        Presentation Language                                       6
-   4.1.      Basic Block Size                                            7
-   4.2.      Miscellaneous                                               7
-   4.3.      Vectors                                                     7
-   4.4.      Numbers                                                     8
-   4.5.      Enumerateds                                                 9
-   4.6.      Constructed Types                                           9
-   4.6.1.    Variants                                                    10
-   4.7.      Cryptographic Attributes                                    11
-   4.8.      Constants                                                   12
-   5.        HMAC and the Pseudorandom fFunction                         13
-   6.        The TLS Record Protocol                                     14
-   6.1.      Connection States                                           14
-   6.2.      Record layer                                                17
-   6.2.1.    Fragmentation                                               17
-   6.2.2.    Record Compression and Decompression                        18
-   6.2.3.    Record Payload Protection                                   19
-   6.2.3.1.  Null or Standard Stream Cipher                              20
-   6.2.3.2.  CBC Block Cipher                                            20
-   6.2.3.3.  AEAD ciphers                                                22
-   6.3.      Key Calculation                                             23
-   7.        The TLS Handshaking Protocols                               24
-   7.1.      Change Cipher Spec Protocol                                 25
-   7.2.      Alert Protocol                                              26
-   7.2.1.    Closure Alerts                                              27
-   7.2.2.    Error Alerts                                                27
-   7.3.      Handshake Protocol Overview                                 31
-   7.4.      Handshake Protocol                                          35
-   7.4.1.    Hello Messages                                              36
-   7.4.1.1.  Hello Request                                               36
-   7.4.1.2.  Client Hello                                                37
-   7.4.1.3.  Server Hello                                                40
-   7.4.1.4   Hello Extensions                                            41
-   7.4.1.4.1 Cert Hash Types                                             43
-   7.4.2.    Server Certificate                                          43
-   7.4.3.    Server Key Exchange Message                                 45
-   7.4.4.    Certificate Request                                         47
-   7.4.5     Server hello done                                           49
-   7.4.6.    Client Certificate                                          49
-   7.4.7.    Client Key Exchange Message                                 49
-   7.4.7.1.  RSA Encrypted Premaster Secret Message                      50
-   7.4.7.1.  Client Diffie-Hellman Public Value                          53
-   7.4.8.    Certificate verify                                          53
-   7.4.9.    Finished                                                    54
-   8.        Cryptographic Computations                                  55
-   8.1.      Computing the Master Secret                                 55
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   8.1.1.    RSA                                                         56
-   8.1.2.    Diffie-Hellman                                              56
-   9.        Mandatory Cipher Suites                                     56
-   10.       Application Data Protocol                                   56
-   11.       Security Considerations                                     56
-   12.       IANA Considerations                                         57
-   A.        Protocol Constant Values                                    59
-   A.1.      Record Layer                                                59
-   A.2.      Change Cipher Specs Message                                 60
-   A.3.      Alert Messages                                              60
-   A.4.      Handshake Protocol                                          62
-   A.4.1.    Hello Messages                                              62
-   A.4.2.    Server Authentication and Key Exchange Messages             63
-   A.4.3.    Client Authentication and Key Exchange Messages             65
-   A.4.4.    Handshake Finalization Message                              65
-   A.5.      The CipherSuite                                             65
-   A.6.      The Security Parameters                                     68
-   B.        Glossary                                                    70
-   C.        CipherSuite Definitions                                     74
-   D.        Implementation Notes                                        76
-   D.1       Random Number Generation and Seeding                        76
-   D.2       Certificates and Authentication                             76
-   D.3       CipherSuites                                                76
-   E.        Backward Compatibility                                      77
-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0                  77
-   E.2       Compatibility with SSL 2.0                                  78
-   E.2.      Avoiding Man-in-the-Middle Version Rollback                 80
-   F.        Security Analysis                                           81
-   F.1.      Handshake Protocol                                          81
-   F.1.1.    Authentication and Key Exchange                             81
-   F.1.1.1.  Anonymous Key Exchange                                      81
-   F.1.1.2.  RSA Key Exchange and Authentication                         82
-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication             82
-   F.1.2.    Version Rollback Attacks                                    83
-   F.1.3.    Detecting Attacks Against the Handshake Protocol            84
-   F.1.4.    Resuming Sessions                                           84
-   F.1.5     Extensions                                                  85
-   F.2.      Protecting Application Data                                 85
-   F.3.      Explicit IVs                                                85
-   F.4.      Security of Composite Cipher Modes                          86
-   F.5       Denial of Service                                           87
-   F.6.      Final Notes                                                 87
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   of protocols that run on top of TLS.
-
-1.1 Requirements Terminology
-
-   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 [RFC2119].
-
-1.2 Major Differences from TLS 1.1
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-     - Merged in TLS Extensions definition and AES Cipher Suites from
-     external documents.
-
-     - Replacement of MD5/SHA-1 combination in the PRF. Addition
-     of cipher-suite specified PRFs.
-
-     - Replacement of MD5/SHA-1 combination in the digitally-signed
-     element.
-
-     - Allow the client to indicate which hash functions it supports
-     for digital signature.
-
-     - Allow the server to indicate which hash functions it supports
-     for digital signature.
-
-     - Addition of support for authenticated encryption with additional
-     data modes.
-
-     - Tightened up a number of requirements.
-
-     - The usual clarifications and editorial work.
-
-     - Added some guidance that DH groups should be checked.
-
-     - Cleaned up description of Bleichenbacher/Klima attack defenses.
-
-     - Tighter checking of EncryptedPreMasterSecret version numbers.
-
-     - Stronger language about when alerts MUST be sent.
-
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that can successfully exchange
-       cryptographic parameters without knowledge of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: preventing
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and avoiding the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions). This
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e., 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-       T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream. The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length. A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two-byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17-byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors. In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-         ...
-         Tn fn;
-       } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, an
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic Attributes
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
-   discussed in [PKCS1], the DigestInfo MUST be DER encoded and for
-   digest algorithms without parameters (which include SHA-1) the
-   DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
-   implementations MUST accept both without parameters and with NULL
-   parameters. Note that earlier versions of TLS used a different RSA
-   signature scheme which did not include a DigestInfo encoding.
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and the output is
-   generally larger than the input in order to accomodate the integrity
-   check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1].
-
-   In the following example
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   the contents of hash are used as input for the signing algorithm, and
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes, would be equal to two bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   because the algorithm and key used for the signing are known prior to
-   encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-       struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the Pseudorandom fFunction
-
-   A number of operations in the TLS record and handshake layer requires
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction TLS provides for this operation is known as
-   HMAC and is described in [HMAC]. Cipher suites MAY define their own
-   MACs.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-   We define one PRF, based on HMAC, which is used for all cipher suites
-   in this document. Cipher suites MAY define their own PRFs.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 is being used to
-   create 64 bytes of data, it will have to be iterated 4 times (through
-   A(4)), creating 80 bytes of output data; the last 16 bytes of the
-   final iteration will then be discarded, leaving 64 bytes of output
-   data.
-
-   TLS's PRF is created by applying P_hash to the secret S as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   All the cipher suites defined in this document and in TLS documents
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   prior to this document MUST use SHA-256 as the basis for their PRF.
-   New cipher suites MUST specify a PRF and in general SHOULD use the
-   TLS PRF with SHA-256 or a stronger standard hash function.
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-   higher-level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. New record type values are assigned
-   by IANA as described in Section 11.
-
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it.  Any protocol designed for use
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.  Implementations MUST not
-   send record types not defined in this document unless negotiated by
-   some extension.
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, an encryption
-   algorithm, and MAC algorithm. In addition, the parameters for these
-   algorithms are known: the MAC secret and the bulk encryption keys for
-   the connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state that has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block, stream, or AEAD cipher, and the
-       block size of the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the value returned by the MAC
-       algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48-byte secret shared between the two peers in the connection.
-
-   client random
-       A 32-byte value provided by the client.
-
-   server random
-       A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
-
-       /* The use of "sha" above is historical and denotes SHA-1 */
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  enc_key_length;
-           uint8                  block_length;
-           uint8                  iv_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  mac_length;
-           uint8                  mac_key_length;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever state information is necessary to
-       allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection, as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number, it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record transmitted under a
-       particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher-level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.2, which uses the version { 3, 3 }. The
-       version value 3.3 is historical, deriving from the use of 3.1 for
-       TLS 1.0. (See Appendix A.1).  Note that a client that supports
-       multiple versions of TLS may not know what version will be
-       employed before it receives ServerHello.  See Appendix E for
-       discussion about what record layer version number should be
-       employed for ClientHello.
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length MUST not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher-level protocol
-       specified by the type field.
-
-       Implementations MUST not send zero-length fragments of Handshake,
-       Alert, or Change Cipher Spec content types. Zero-length fragments
-       of Application data MAY be sent as they are potentially useful as
-       a traffic analysis countermeasure.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved.  Application data is generally of lower precedence
-       for transmission than other content types.  However, records MUST
-       be delivered to the network in the same order as they are
-       protected by the record layer.  Recipients MUST receive and
-       process interleaved application layer traffic during handshakes
-       subsequent to the first one on a connection.
-
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record Payload Protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (SecurityParameters.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-               case aead: GenericAEADCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       The version field is identical to TLSCompressed.version.
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted,
-   and the MAC size is zero, implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   SecurityParameters.mac_length.
-
-6.2.3.2. CBC Block Cipher
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-       block-ciphered struct {
-           opaque IV[SecurityParameters.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       TLS 1.2 uses an explicit IV in order to prevent the attacks
-       described by [CBCATT]. The IV SHOULD be chosen at random and MUST
-       be unpredictable.  In order to decrypt, thereceiver decrypts the
-       entire GenericBlockCipher structure and then discards the first
-       cipher block, corresponding to the IV component.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes, as long as it results
-       in the TLSCiphertext.length being an integral multiple of the
-       block length. Lengths longer than necessary might be desirable to
-       frustrate attacks on a protocol that are based on analysis of the
-       lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and SHOULD use the bad_record_mac alert
-       to indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, SecurityParameters.mac_length, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, then the length before padding is 82 bytes (this does
-          not include the IV, which may or may not be encrypted, as
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-          discussed above). Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise, it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et al. [CBCTIME] have demonstrated a timing
-       attack on CBC padding based on the time required to compute the
-       MAC. In order to defend against this attack, implementations MUST
-       ensure that record processing time is essentially the same
-       whether or not the padding is correct.  In general, the best way
-       to do this is to compute the MAC even if the padding is
-       incorrect, and only then reject the packet. For instance, if the
-       pad appears to be incorrect, the implementation might assume a
-       zero-length pad and then compute the MAC. This leaves a small
-       timing channel, since MAC performance depends to some extent on
-       the size of the data fragment, but it is not believed to be large
-       enough to be exploitable, due to the large block size of existing
-       MACs and the small size of the timing signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-       aead-ciphered struct {
-           opaque IV[SecurityParameters.iv_length];
-           opaque aead_output[AEADEncrypted.length];
-       } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD].  These inputs are as follows.
-
-   The key is either the client_write_key or the server_write_key.  The
-   MAC key will be of length zero.
-
-   The nonce supplied to the AEAD operations is determined by the IV in
-   aead-ciphered struct. Each IV used in distinct invocations of the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   AEAD encryption operation MUST be distinct, for any fixed value of
-   the key.  Implementations SHOULD use the recommended nonce formation
-   method of [AEAD] to generate IVs, and MAY use any other method that
-   meets this requirement.  The length of the IV depends on the AEAD
-   cipher; that length MAY be zero. Note that in many cases it is
-   appropriate to use the partially implicit nonce technique of S 3.2.1
-   of AEAD, in which case the client_write_iv and server_write_iv should
-   be used as the "fixed-common".
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  AEADEncrypted.length will generally be larger
-   than TLSCompressed.length, but by an amount that varies with the AEAD
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-      AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
-                      additional_data)
-
-   Where "+" denotes concatenation.
-
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   IV, the "additional_data", and the AEADEncrypted value. The output is
-   either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-   TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
-                   TLSCiphertext.type + TLSCiphertext.version +
-                   TLSCiphertext.length);
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, each of which is generated from the master secret
-   in that order. Unused values are empty.
-
-   When keys and MAC secrets are generated, the master secret is used as
-   an entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.mac_key_length]
-       server_write_MAC_secret[SecurityParameters.mac_key_length]
-       client_write_key[SecurityParameters.enc_key_length]
-       server_write_key[SecurityParameters.enc_key_length]
-
-
-   Implementation note:
-       The currently defined cipher suite which requires the most
-       material is AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x
-       32 byte keys and 2 x 20 byte MAC secrets, for a total 104 bytes
-       of key material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols that are used to allow peers to agree
-       upon security parameters for the record layer, to authenticate
-       themselves, to instantiate negotiated security parameters, and to
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [X509] certificate of the peer. This element of the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the mac_length. (See
-         Appendix A.6 for formal definition.)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see Section 7.4.11
-
- Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g., if it has to perform a time consuming public
-   key operation). Thus, a small window of time, during which the
-   recipient must buffer the data, MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed_RESERVED(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED(41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           unsupported_extension(110),           /* new */
-           (255)
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error Alerts
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed.
-
-   Whenever an implementation encounters a condition which is defined as
-   a fatal alert, it MUST send the appropriate alert prior to closing
-   the connection. In cases where an implementation chooses to send an
-   alert which MAY be a warning alert but intends to close the
-   connection immediately afterwards, it MUST send that alert at the
-   fatal alert level.
-
-   If an alert with a level of warning is sent and received, generally
-   the connection can continue normally.  If the receiving party decides
-   not to proceed with the connection (e.g., after having received a
-   no_renegotiation alert that it is not willing to accept), it SHOULD
-   send a fatal alert to terminate the connection.
-
-
-   The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed_RESERVED
-       This alert was used in some earlier versions of TLS, and may have
-       permitted certain attacks against the CBC mode [CBCATT].  It MUST
-       NOT be sent by compliant implementations.
-
-   record_overflow
-       A TLSCiphertext record was received that had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g., data
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not any version of TLS.  It MUST
-       NOT be sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in some earlier versions of TLS.  It MUST NOT
-       be sent by compliant implementations.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized but not supported. (For example, old protocol versions
-       might be avoided for security reasons). This message is always
-       fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol (such as a memory allocation failure) makes it
-       impossible to continue. This message is always fatal.
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert.
-       At that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate is where a server has spawned a process to satisfy a
-       request; the process might receive security parameters (key
-       length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   unsupported_extension
-       sent by clients that receive an extended server hello containing
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       an extension that they did not put in the corresponding client
-       hello (see Section 2.3).  This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not.  However, all messages that are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New Alert values are assigned by IANA as described in Section 11.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man in the middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support. The protocol has been designed to
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection. The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require. The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g., if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Next,
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify possession of the private
-   key in the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Cipher Spec. At this point, the handshake is complete, and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               CertificateStatus*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20)
-        (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message that is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message types are assigned by IANA as described in
-   Section 11.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello Request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message is not intended to
-       establish which side is the client or server but merely to
-       initiate a new negotiation. Servers SHOULD not send a
-       HelloRequest immediately upon the client's initial connection.
-       It is the client's job to send a ClientHello at that time.
-
-       This message will be ignored by the client if the client is
-       currently negotiating a session. This message may be ignored by
-       the client if it does not wish to renegotiate a session, or the
-       client may, if it wishes, respond with a no_renegotiation alert.
-       Since handshake messages are intended to have transmission
-       precedence over application data, it is expected that the
-       negotiation will begin before no more than a few records are
-       received from the client. If the server sends a hello request but
-       does not receive a client hello in response, it may close the
-       connection with a fatal alert.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   After sending a hello request, servers SHOULD not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes that are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-   Structure of this message:
-       The client hello message includes a random structure, which is
-       used later in the protocol.
-
-       struct {
-          uint32 gmt_unix_time;
-          opaque random_bytes[28];
-       } Random;
-
-   gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher-
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable-length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or from another currently active connection. The second
-   option is useful if the client only wishes to update the random
-   structures and derived values of a connection, and the third option
-   makes it possible to establish several independent secure connections
-   without repeating the full handshake protocol. These independent
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   connections may occur sequentially or simultaneously; a SessionID
-   becomes valid when the handshake negotiating it completes with the
-   exchange of Finished messages and persists until it is removed due to
-   aging or because a fatal error was encountered on a connection
-   associated with the session. The actual contents of the SessionID are
-   defined by the server.
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-           select (extensions_present) {
-               case false:
-                   struct {};
-               case true:
-                   Extension extensions<0..2^16-1>;
-           }
-       } ClientHello;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block. The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello. Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field but is used for compatibility with TLS before
-   extensions were defined.
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.3 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available, or it
-       the client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it MUST include
-       the compression_method from that session. This vector MUST
-       contain, and all implementations MUST support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   client_hello_extension_list
-       Clients MAY request extended functionality from servers by
-       sending data in the client_hello_extension_list.  Here the new
-       "client_hello_extension_list" field contains a list of
-       extensions.  The actual "Extension" format is defined in Section
-       7.4.1.4.
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   client MAY abort the handshake.  A server that supports the
-   extensions mechanism MUST accept only client hello messages in either
-   the original (TLS 1.0/TLS 1.1) ClientHello or the extended
-   ClientHello format defined in this document, and (as for all other
-   messages) MUST check that the amount of data in the message precisely
-   matches one of these formats; if not then it MUST send a fatal
-   "decode_error" alert.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-
-7.4.1.3. Server Hello
-
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-           struct {
-               ProtocolVersion server_version;
-               Random random;
-               SessionID session_id;
-               CipherSuite cipher_suite;
-               CompressionMethod compression_method;
-               select (extensions_present) {
-                   case false:
-                       struct {};
-                   case true:
-                       Extension extensions<0..2^16-1>;
-               }
-           } ServerHello;
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.3.  (See
-       Appendix E for details about backward compatibility.)
-
-   random
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with. Note that there is no requirement
-       that the server resume any session even if it had formerly
-       provided a session_id. Client MUST be prepared to do a full
-       negotiation -- including negotiating new cipher suites -- during
-       any handshake.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions, this field is
-       the value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-   server_hello_extension_list
-       A list of extensions. Note that only extensions offered by the
-       client can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format is:
-
-         struct {
-             ExtensionType extension_type;
-             opaque extension_data<0..2^16-1>;
-         } Extension;
-
-         enum {
-             signature_hash_types(TBD-BY-IANA), (65535)
-         } ExtensionType;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Here:
-
-     - "extension_type" identifies the particular extension type.
-
-     - "extension_data" contains information specific to the particular
-   extension type.
-
-   The list of extension types, as defined in Section 2.3, is maintained
-   by the Internet Assigned Numbers Authority (IANA). Thus an
-   application needs to be made to the IANA in order to obtain a new
-   extension type value. Since there are subtle (and not so subtle)
-   interactions that may occur in this protocol between new features and
-   existing features which may result in a significant reduction in
-   overall security, new values SHALL be defined only through the IETF
-   Consensus process specified in [IANA].  (This means that new
-   assignments can be made only via RFCs approved by the IESG.) The
-   initial set of extensions is defined in a companion document [TBD].
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-     -  Some cases where a server does not agree to an extension are
-   error
-       conditions, and some simply a refusal to support a particular
-       feature.  In general error alerts should be used for the former,
-       and a field in the server extension response for the latter.
-
-     -  Extensions should as far as possible be designed to prevent any
-       attack that forces use (or non-use) of a particular feature by
-       manipulation of handshake messages.  This principle should be
-       followed regardless of whether the feature is believed to cause a
-       security problem.
-
-       Often the fact that the extension fields are included in the
-       inputs to the Finished message hashes will be sufficient, but
-       extreme care is needed when the extension changes the meaning of
-       messages sent in the handshake phase. Designers and implementors
-       should be aware of the fact that until the handshake has been
-       authenticated, active attackers can modify messages and insert,
-       remove, or replace extensions.
-
-     -  It would be technically possible to use extensions to change
-       major aspects of the design of TLS; for example the design of
-       cipher suite negotiation.  This is not recommended; it would be
-       more appropriate to define a new version of TLS - particularly
-       since the TLS handshake algorithms have specific protection
-       against version rollback attacks based on the version number, and
-       the possibility of version rollback should be a significant
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       consideration in any major design change.
-
-7.4.1.4.1 Cert Hash Types
-
-       The client MAY use the "signature_hash_types" to indicate to the
-       server which hash functions may be used in digital signatures.
-       The "extension_data" field of this extension contains:
-
-             enum{
-                 md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
-             } HashType;
-
-             struct {
-                   HashType types<1..255>;
-             } SignatureHashTypes;
-
-   These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
-   and SHA-512 [SHA] respectively. The server MUST NOT send this
-   extension. The values are indicated in descending order of
-   preference.
-
-   Clients SHOULD send this extension if they support any algorithm
-   other than SHA-1. If this extension is not used, servers SHOULD
-   assume that the client supports only SHA-1. Note: this is a change
-   from TLS 1.1 where there are no explicit rules but as a practical
-   matter one can assume that the peer supports MD5 and SHA-1.
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method uses certificates for authentication (this
-       includes all key exchange methods defined in this document except
-       DH_anon).  This message will always immediately follow the server
-       hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-       certificate. It MUST contain a key that matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key that can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles and key and cryptographic formats are
-   defined by the IETF PKIX working group [PKIX]. When a key usage
-   extension is present, the digitalSignature bit MUST be set for the
-   key to be eligible for signing, as described above, and the
-   keyEncipherment bit MUST be present to allow encryption, as described
-   above. The keyAgreement bit must be set on Diffie-Hellman
-   certificates.
-
-   As CipherSuites that specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate that specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret) or a public key for
-       some other algorithm.
-
-   As additional CipherSuites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-   If the client has offered the SignatureHashTypes extension, the hash
-   function MUST be one of those listed in that extension. Otherwise it
-   MUST be assumed that only SHA-1 is supported.
-
-   If the SignatureAlgorithm being used to sign the ServerKeyExchange
-   message is DSA, the hash algorithm MUST be SHA-1.  [TODO: This is
-   incorrect. What it should say is that it must be specified in the
-   SPKI of the cert. However, I don't believe this is actually defined.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Rather, the DSA certs just say dsa. We need new certs to say
-   dsaWithSHAXXX.]
-
-   If the SignatureAlgorithm is RSA, then any hash function accepted by
-   the client MAY be used. The selected hash function MUST be indicated
-   in the digest_algorithm field of the signature structure.
-
-   The hash algorithm is denoted Hash below. Hash.length is the length
-   of the output of that algorithm.
-
-   Structure of this message:
-       enum { diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-           };
-        } ServerParams;
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-           params value, with the signature appropriate to that hash
-           applied.
-
-       hash
-           Hash(ClientHello.random + ServerHello.random + ServerParams)
-
-       sha_hash
-           SHA1(ClientHello.random + ServerHello.random + ServerParams)
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       struct {
-           select (SignatureAlgorithm) {
-               case anonymous: struct { };
-               case rsa:
-                   HashType digest_algorithm;       // NEW
-                   digitally-signed struct {
-                       opaque hash[Hash.length];
-                   };
-               case dsa:
-                   digitally-signed struct {
-                       opaque sha_hash[20];
-                   };
-               };
-           };
-       } Signature;
-
-7.4.4. Certificate Request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-           rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-           fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           HashType certificate_hash<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_types
-           A list of the types of certificate types which the client may
-           offer.
-              rsa_sign        a certificate containing an RSA key
-              dss_sign        a certificate containing a DSS key
-              rsa_fixed_dh    a certificate signed with RSA and containing
-                              a static DH key.
-              dss_fixed_dh    a certificate signed with DSS and containing
-                              a static DH key
-
-           Certificate types rsa_sign and dss_sign SHOULD contain
-           certificates signed with the same algorithm. However, this is
-           not required. This is a holdover from TLS 1.0 and 1.1.
-
-
-       certificate_hash
-           A list of acceptable hash algorithms to be used in signatures
-           in both the client certificate and the CertificateVerify.
-           These algorithms are listed in descending order of
-           preference.
-
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space. If the
-           certificate_authorities list is empty then the client MAY
-           send any certificate of the appropriate
-           ClientCertificateType, unless there is some external
-           arrangement to the contrary.
-
- New ClientCertificateType values are assigned by IANA as described in
-           Section 11.
-
-           Note: Values listed as RESERVED may not be used. They were
-           used in SSLv3.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
- Note: DistinguishedName is derived from [X501]. DistinguishedNames are
-           represented in DER-encoded format.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.5 Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message, the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message, the client SHOULD
-       verify that the server provided a valid certificate, if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client Certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client SHOULD send a certificate message
-       containing no certificates. That is, the certificate_list
-       structure has a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate MUST match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client Key Exchange Message
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   When this message will be sent:
-       This message is always sent by the client. It MUST immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it MUST be the first message sent by the client after it receives
-       the server hello done message.
-
-   Meaning of this message:
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters that will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate that contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate and sends the result
-       in an encrypted premaster secret message. This structure is a
-       variant of the client key exchange message and is not a message
-       in itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server SHOULD check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: The version number in the PreMasterSecret is the version offered
-           by the client in the ClientHello.client_version, not the
-           version negotiated for the connection.  This feature is
-           designed to prevent rollback attacks.  Unfortunately, some
-           old implementations use the negotiated version instead and
-           therefore checking the version number may lead to failure to
-           interoperate with such incorrect client implementations.
-
-           Client implementations MUST always send the correct version
-           number in PreMasterSecret. If ClientHello.client_version is
-           TLS 1.1 or higher, server implementations MUST check the
-           version number as described in the note below. If the version
-           number is earlier than 1.0, server implementations SHOULD
-           check the version number, but MAY have a configuration option
-           to disable the check. Note that if the check fails, the
-           PreMasterSecret SHOULD be randomized as described below.
-
-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
-   [KPR03] can be used to attack a TLS server that reveals whether a
-   particular message, when decrypted, is properly PKCS#1 formatted,
-   contains a valid PreMasterSecret structure, or has the correct
-   version number.
-
-   The best way to avoid these vulnerabilities is to treat incorrectly
-   formatted messages in a manner indistinguishable from correctly
-   formatted RSA blocks. In other words:
-
-        1. Generate a string R of 46 random bytes
-
-        2. Decrypt the message M
-
-        3. If the PKCS#1 padding is not correct, or the length of
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-           message M is not exactly 48 bytes:
-              premaster secret = ClientHello.client_version || R
-           else If ClientHello.client_version <= TLS 1.0, and
-           version number check is explicitly disabled:
-              premaster secret = M
-           else:
-              premaster secret = ClientHello.client_version || M[2..47]
-
-   In any case, a TLS server MUST NOT generate an alert if processing an
-   RSA-encrypted premaster secret message fails, or the version number
-   is not as expected. Instead, it MUST continue the handshake with a
-   randomly generated premaster secret.  It may be useful to log the
-   real cause of failure for troubleshooting purposes; however, care
-   must be taken to avoid leaking the information to an attacker
-   (though, e.g., timing, log files, or other channels.
-
-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
-   against the Bleichenbacher attack. However, for maximal compatibility
-   with earlier versions of TLS, this specification uses the RSAES-
-   PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
-   to exist provided that the above recommendations are followed.
-
- Implementation Note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes. These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined. The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the the length bytes, encoding the RSA encrypted data
-   directly in the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes. The resulting
-   PDU is incompatible with many SSLv3 implementations. Implementors
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding. Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-   behavior dependent on the protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-   on SSL are possible, at least when the client and server are on the
-   same LAN. Accordingly, implementations that use static RSA keys MUST
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-7.4.7.1. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, and not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but it MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       The hash function MUST be one of the algorithms offered in the
-       CertificateRequest message.
-
-       If the SignatureAlgorithm being used to sign the ServerKeyExchange
-       message is DSA, the hash function used MUST be SHA-1.
-       [TODO: This is incorrect. What it should say is that it must
-       be specified in the SPKI of the cert. However, I don't believe
-       this is actually defined. Rather, the DSA certs just say
-       dsa. We need new certs to say dsaWithSHAXXX]
-
-       If the SignatureAlgorithm is RSA, then any of the functions offered
-       by the server may be used. The selected hash function MUST be
-       indicated in the digest_algorithm field of the signature structure.
-
-       The hash algorithm is denoted Hash below.
-
-       CertificateVerify.signature.hash
-           Hash(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       verify_data
-           PRF(master_secret, finished_label, Hash(handshake_messages))[0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-           Hash denotes the negotiated hash used for the PRF. If a new
-           PRF is defined, then this hash MUST be specified.
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.9 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts and, any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the Master Secret
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. Security Considerations
-
-   Security issues are discussed throughoutthis memo, especially in
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Appendices D, E, and F.
-
-12. IANA Considerations
-
-   This document uses several registries that were originally created in
-   [RFC4346]. IANA is requested to update (has updated) these to
-   reference this document. The registries and their allocation policies
-   (unchanged from [RFC4346]) are listed below.
-
-   o  TLS ClientCertificateType Identifiers Registry: Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434]. Values in the range 64-223
-      (decimal) inclusive are assigned Specification Required
-      [RFC2434]. Values from 224-255 (decimal) inclusive are
-      reserved for Private Use [RFC2434].
-
-   o  TLS Cipher Suite Registry: Future values with the first byte
-      in the range 0-191 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values with the first byte in
-      the range 192-254 (decimal) are assigned via Specification
-      Required [RFC2434]. Values with the first byte 255 (decimal)
-      are reserved for Private Use [RFC2434].
-
-   o  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   o  TLS Alert Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   o  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA is requested to update (has updated) it to reference this
-   document.  The registry and its allocation policy (unchanged from
-   [RFC4366]) is listed below:.
-
-   o  TLS ExtensionType Registry: Future values are allocated
-      via IETF Consensus [RFC2434]
-
-   In addition, this document defines one new registry to be maintained
-   by IANA:
-
-   o  TLS HashType Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.7.
-      Future values in the range 0-63 (decimal) inclusive are
-      assigned via Standards Action [RFC2434].  Values in the
-      range 64-223 (decimal) inclusive are assigned via
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-      Specification Required [RFC2434].  Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   This document defines one new TLS extension, cert_hash_type, which is
-   to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
-   registry.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-Appendix A. Protocol Constant Values
-
-   This section describes protocol types and constants.
-
-A.1. Record Layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (SecurityParameters.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-            case aead: GenericAEADCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[SecurityParameters.mac_length];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-        opaque IV[SecurityParameters.block_length];
-        opaque content[TLSCompressed.length];
-        opaque MAC[SecurityParameters.mac_length];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-    aead-ciphered struct {
-        opaque IV[SecurityParameters.iv_length];
-        opaque aead_output[AEADEncrypted.length];
-    } GenericAEADCipher;
-
-A.2. Change Cipher Specs Message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed_RESERVED(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED(41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            unsupported_extension(110),           /* new */
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-A.4. Handshake Protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20)
-     (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello Messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-        CompressionMethod compression_methods<1..2^8-1>;
-        select (extensions_present) {
-            case false:
-                struct {};
-            case true:
-                Extension extensions<0..2^16-1>;
-        }
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-        select (extensions_present) {
-            case false:
-                struct {};
-            case true:
-                Extension extensions<0..2^16-1>;
-        }
-    } ServerHello;
-
-    struct {
-        ExtensionType extension_type;
-        opaque extension_data<0..2^16-1>;
-    } Extension;
-
-    enum {
-        signature_hash_types(TBD-BY-IANA), (65535)
-    } ExtensionType;
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-            case anonymous: struct { };
-            case rsa:
-                HashType digest_algorithm;       // NEW
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-            case dsa:
-                digitally-signed struct {
-                    opaque sha_hash[20];
-                };
-            };
-        };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   not be negotiated, as it provides no more protection than an
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-    CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x2F };
-    CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x35 };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-    CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA        = { 0x00, 0x30 };
-    CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA        = { 0x00, 0x31 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x32 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x33 };
-    CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA        = { 0x00, 0x36 };
-    CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA        = { 0x00, 0x37 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x38 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x39 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks.  Using
-   this mode therefore is of limited use: These ciphersuites MUST NOT be
-   used by TLS 1.2 implementations unless the application layer has
-   specifically requested to allow anonymous key exchange.  (Anonymous
-   key exchange may sometimes be acceptable, for example, to support
-   opportunistic encryption when no set-up for authentication is in
-   place, or when TLS is used as part of more complex security protocols
-   that have other means to ensure authentication.)
-
-     CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00, 0x18 };
-     CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00, 0x1A };
-     CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x1B };
-     CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
-     CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.2 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.2 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.2 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness. See [TLSKRB] for details:
-
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
-    CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
-    CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
-    CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
-    CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness. TLS 1.2 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A
-   };
-    CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B
-   };
-
-
- New cipher suite values are assigned by IANA as described in Section
-   11.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       BulkCipherAlgorithm;
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 enc_key_length;
-           uint8 block_length;
-           uint8 iv_length;
-           MACAlgorithm mac_algorithm;
-           uint8 mac_length;
-           uint8 mac_key_length;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.  AES is a
-       block cipher with a 128, 192, or 256 bit keys and a 16 byte block
-       size. [AES] TLS currently only supports the 128 and 256 bit key
-       sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-       A symmetric encryption algorithm that simultaneously provides
-       confidentiality and message integrity.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer-to-peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard", published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters that can be shared among
-       multiple connections. Sessions are used to avoid the expensive
-       negotiation of new security parameters for each connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-Appendix C. CipherSuite Definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_SHA                RSA            AES_256_CBC  SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-      RSA             RSA key exchange                   None
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm.
-
-   IV Size
-       The amount of data needed to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-Appendix E. Backward Compatibility
-
-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client support the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version. If the server does not support this
-   version, it will respond with ServerHello containing an older version
-   number. If the client agrees to use this version, the negotiation
-   will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing version number
-   smaller than the highest supported version. If the server wishes to
-   negotiate with old clients, it will proceed as appropriate for the
-   highest version supported by the server that is not greater than
-   ClientHello.client_version. For example, if the server supports TLS
-   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing
-   to use) only versions greater than client_version, it MUST send a
-   "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
- Note: some server implementations are known to implement version
-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   that simply close the connection when the client offers a version
-   newer than TLS 1.0. Also, it is known that some servers will refuse
-   connection if any TLS extensions are included in ClientHello.
-   Interoperability with such buggy servers is a complex topic beyond
-   the scope of this document, and may require multiple connection
-   attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed). Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number. Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version. No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2 Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
-   contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS ciphersuites in the
-   CIPHER-SPECS-DATA field as described below.
-
-Warning: The ability to send version 2.0 CLIENT-HELLO messages will be
-   phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-   However, even TLS servers that do not support SSL 2.0 SHOULD accept
-   version 2.0 CLIENT-HELLO messages. The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions. Note that this message MUST be sent directly on the wire,
-   not wrapped as a TLS record. For the purposes of calculating Finished
-   and CertificateVerify, the msg_length field is not considered to be a
-   part of the handshake message.
-
-       uint8 V2CipherSpec[3];
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       The highest bit MUST be 1; the remaining bits contain the
-       length of the following data in bytes.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-       version 2 client hello message. The value MUST be one (1).
-
-   version
-       Equal to ClientHello.client_version.
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero for a client that claims to
-       support TLS 1.2.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. Historically, permissible values are between
-       16 and 32 bytes inclusive. When using the SSLv2 backward
-       compatible handshake the client SHOULD use a 32 byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. In addition to the 2.0 cipher specs defined in [SSL2],
-       this includes the TLS cipher suites normally sent in
-       ClientHello.cipher_suites, each cipher suite prefixed by a zero
-       byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
-       {0x00,0x00,0x0A}.
-
-   session_id
-       This field MUST be empty.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   challenge
-       Corresponds to ClientHello.random. If the challenge length is
-       less than 32, the TLS server will pad the data with leading
-       (note: not trailing) zero bytes to make it 32 bytes long.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.2. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   MUST use special PKCS#1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
-   the right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).
-
-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
-   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
-   padding bytes are 0x03. If they are not, the server SHOULD generate a
-   random value for SECRET-KEY-DATA, and continue the handshake (which
-   will eventually fail since the keys will not match).  Note that
-   reporting the error situation to the client could make the server
-   vulnerable to attacks described in [BLEI].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.9 and 6.3). By sending a correct finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-   from the server key exchange message. The result is sent in a client
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key. TLS
-   users desiring Perfect Forward Secrecy should use DHE cipher suites.
-   The damage done by exposure of a private key can be limited by
-   changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.9). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly, therefore the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-   Because TLS allows the server to provide arbitrary DH groups, the
-   client SHOULD verify the correctness of the DH group. [TODO: provide
-   a reference to some document describing how] and that it is of
-   suitable size as defined by local policy. The client SHOULD also
-   verify that the DH public exponent appears to be of adequate size.
-   The server MAY choose to assist the client by providing a known
-   group, such as those defined in [IKEALG] or [MODP]. These can be
-   verified by simple comparison.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Altering
-   the padding of the least significant 8 bytes of the PKCS padding does
-   not impact security for the size of the signed hashes and RSA key
-   lengths used in the protocol, since this is essentially equivalent to
-   increasing the input block size by 8 bytes.
-
-F.1.3. Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-F.1.5 Extensions
-
-   Security considerations for the extension mechanism in general, and
-   the design of new extensions, are described in the previous section.
-   A security analysis of each of the extensions defined in this
-   document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art, and address any weaknesses identified.
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64 bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent, so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-F.4. Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions, provided that the former is secure against
-       chosen plaintext attacks and that the MAC is secure against
-       chosen-message attacks.  TLS uses another method, called
-       authenticate-then-encrypt, in which first a MAC is computed on
-       the plaintext and then the concatenation of plaintext and MAC is
-       encrypted.  This method has been proven secure for CERTAIN
-       combinations of encryption functions and MAC functions, but it is
-       not guaranteed to be secure in general. In particular, it has
-       been shown that there exist perfectly secure encryption functions
-       (secure even in the information-theoretic sense) that combined
-       with any secure MAC function, fail to provide the confidentiality
-       goal against an active attack.  Therefore, new ciphersuites and
-       operation modes adopted into TLS need to be analyzed under the
-       authenticate-then-encrypt method to verify that they achieve the
-       stated integrity and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message, plus the length of the MAC tag, is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent, and unpredictable IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext.  This made TLS open to chosen
-       plaintext attacks.  This version of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure, see [ENCAUTH].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-F.5 Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption. However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections. In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6. Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys and
-   anonymous servers should be used with great caution. Implementations
-   and users must be careful when deciding which certificates and
-   certificate authorities are acceptable; a dishonest certificate
-   authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-
-Changes in This Version
-
-   [RFC Editor: Please delete this]
-
-     - Added some guidance about checking DH groups and exponents.
-     [Issues 15 and 43]
-
-     - DigestInfo now MUST be NULL but must be accepted either way
-     per discussion in Prague [Issue 22]
-
-     - Improved versions of Bleichenbacher/Klima/Version number
-     text for the EPMS (due to Eronen) [Issue 17]
-
-     - Cleaned up SSLv2 backward compatibility text [Issue 25]
-
-     - Improvements to signature hash agility text [Issue 41].
-     Still not completely fixed.
-
-     - Changed cert_hash_types to signature hash types and indicated a
-   preference order.
-
-     - Strengthened language about when alerts are required. Note
-     that it is still legal under some circumstances to close
-     a connection with no alert.
-
-Normative References
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   National Institute of Standards and Tecnology,
-            "Recommendation for the Triple Data Encryption Algorithm
-            (TDEA) Block Cipher", NIST Special Publication 800-67, May
-            2004.
-
-   [DES]    National Institute of Standards and Technology, "Data
-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication", RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, March 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2ed", Published by John Wiley & Sons,
-            Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,
-            October 1998.
-
-   [URI]    Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-            Resource Identifiers (URI): Generic Syntax", RFC 2396,
-            August 1998.
-
-   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
-            "Information Systems - Open Systems Interconnection - The
-            Directory:  Public key and Attribute certificate
-            frameworks."
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-            ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-            ISO/IEC 9594:8:2001.
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "Authenticated Encryption", February 2007,
-            draft-mcgrew-auth-enc-02.txt.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            4302, December 2005.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
-            http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [CCM]     "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 4303, December 2005.
-
-   [GCM]    "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
-
-   [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
-            Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
-            2005.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [MODP]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-            Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
-            3526, May 2003.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
-            Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            3546, June 2003.
-
-   [TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-            Suites to Transport Layer Security (TLS)", RFC 2712, October
-            1999.
-
-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-            1.1", RFC 4346, April, 2006.
-
-   [X501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
-            Open Systems Interconnection - "The Directory -
-            Authentication Framework". 1988.
-
-   [XDR]    Srinivansan, R., Sun Microsystems, "XDR: External Data
-            Representation Standard", RFC 1832, August 1995.
-
-
-Credits
-
-   Working Group Chairs
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 92]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 93]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-       <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 94]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-   Full Copyright Statement
-
-      Copyright (C) The IETF Trust (2007).
-
-      This document is subject to the rights, licenses and restrictions
-      contained in BCP 78, and except as set forth therein, the authors
-      retain all their rights.
-
-      This document and the information contained herein are provided on an
-      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-      OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-      OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-   Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed to
-      pertain to the implementation or use of the technology described in
-      this document or the extent to which any license under such rights
-      might or might not be available; nor does it represent that it has
-      made any independent effort to identify any such rights.  Information
-      on the procedures with respect to rights in RFC documents can be
-      found in BCP 78 and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use of
-      such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository at
-      http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention any
-      copyrights, patents or patent applications, or other proprietary
-      rights that may cover technology that may be required to implement
-      this standard.  Please address the information to the IETF at
-      ietf-ipr@ietf.org.
-
-
-   Acknowledgment
-
-      Funding for the RFC Editor function is provided by the IETF
-      Administrative Support Activity (IASA).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 95]draft-ietf-tls-rfc4346-bis-04.txt  TLS                         June 2007
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 96]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-05.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-05.txt
deleted file mode 100644
index 210a7c95b5..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-05.txt
+++ /dev/null
@@ -1,5188 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                Tim Dierks
-Obsoletes (if approved):  RFC 3268, 4346, 4366              Independent
-Intended status:  Proposed Standard                        Eric Rescorla
-                                                 Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-05.txt>  September 2007 (Expires March 2008)
-
-              The Transport Layer Security (TLS) Protocol
-                              Version 1.2
-
-Status of this Memo
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2007).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction                                                3
-   1.1       Requirements Terminology                                    5
-   1.2       Major Differences from TLS 1.1                              5
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   2.        Goals                                                       6
-   3.        Goals of This Document                                      6
-   4.        Presentation Language                                       7
-   4.1.      Basic Block Size                                            7
-   4.2.      Miscellaneous                                               7
-   4.3.      Vectors                                                     7
-   4.4.      Numbers                                                     8
-   4.5.      Enumerateds                                                 9
-   4.6.      Constructed Types                                           10
-   4.6.1.    Variants                                                    10
-   4.7.      Cryptographic Attributes                                    11
-   4.8.      Constants                                                   12
-   5.        HMAC and the Pseudorandom Function                          13
-   6.        The TLS Record Protocol                                     14
-   6.1.      Connection States                                           15
-   6.2.      Record layer                                                17
-   6.2.1.    Fragmentation                                               17
-   6.2.2.    Record Compression and Decompression                        19
-   6.2.3.    Record Payload Protection                                   19
-   6.2.3.1.  Null or Standard Stream Cipher                              20
-   6.2.3.2.  CBC Block Cipher                                            21
-   6.2.3.3.  AEAD ciphers                                                22
-   6.3.      Key Calculation                                             24
-   7.        The TLS Handshaking Protocols                               25
-   7.1.      Change Cipher Spec Protocol                                 25
-   7.2.      Alert Protocol                                              26
-   7.2.1.    Closure Alerts                                              27
-   7.2.2.    Error Alerts                                                28
-   7.3.      Handshake Protocol Overview                                 31
-   7.4.      Handshake Protocol                                          34
-   7.4.1.    Hello Messages                                              35
-   7.4.1.1.  Hello Request                                               35
-   7.4.1.2.  Client Hello                                                36
-   7.4.1.3.  Server Hello                                                39
-   7.4.1.4   Hello Extensions                                            41
-   7.4.1.4.1 Cert Hash Types                                             42
-   7.4.2.    Server Certificate                                          42
-   7.4.3.    Server Key Exchange Message                                 44
-   7.4.4.    Certificate Request                                         46
-   7.4.5     Server hello done                                           48
-   7.4.6.    Client Certificate                                          48
-   7.4.7.    Client Key Exchange Message                                 49
-   7.4.7.1.  RSA Encrypted Premaster Secret Message                      49
-   7.4.7.2.  Client Diffie-Hellman Public Value                          52
-   7.4.8.    Certificate verify                                          52
-   7.4.9.    Finished                                                    53
-   8.        Cryptographic Computations                                  55
-   8.1.      Computing the Master Secret                                 55
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   8.1.1.    RSA                                                         55
-   8.1.2.    Diffie-Hellman                                              55
-   9.        Mandatory Cipher Suites                                     56
-   10.       Application Data Protocol                                   56
-   11.       Security Considerations                                     56
-   12.       IANA Considerations                                         56
-   A.        Protocol Constant Values                                    58
-   A.1.      Record Layer                                                58
-   A.2.      Change Cipher Specs Message                                 59
-   A.3.      Alert Messages                                              59
-   A.4.      Handshake Protocol                                          61
-   A.4.1.    Hello Messages                                              61
-   A.4.2.    Server Authentication and Key Exchange Messages             62
-   A.4.3.    Client Authentication and Key Exchange Messages             64
-   A.4.4.    Handshake Finalization Message                              64
-   A.5.      The CipherSuite                                             64
-   A.6.      The Security Parameters                                     67
-   B.        Glossary                                                    68
-   C.        CipherSuite Definitions                                     72
-   D.        Implementation Notes                                        74
-   D.1       Random Number Generation and Seeding                        74
-   D.2       Certificates and Authentication                             74
-   D.3       CipherSuites                                                74
-   D.4       Implementation Pitfalls                                     74
-   E.        Backward Compatibility                                      77
-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0                  77
-   E.2       Compatibility with SSL 2.0                                  78
-   E.3.      Avoiding Man-in-the-Middle Version Rollback                 80
-   F.        Security Analysis                                           81
-   F.1.      Handshake Protocol                                          81
-   F.1.1.    Authentication and Key Exchange                             81
-   F.1.1.1.  Anonymous Key Exchange                                      81
-   F.1.1.2.  RSA Key Exchange and Authentication                         82
-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication             82
-   F.1.2.    Version Rollback Attacks                                    83
-   F.1.3.    Detecting Attacks Against the Handshake Protocol            84
-   F.1.4.    Resuming Sessions                                           84
-   F.2.      Protecting Application Data                                 85
-   F.3.      Explicit IVs                                                85
-   F.4.      Security of Composite Cipher Modes                          85
-   F.5       Denial of Service                                           86
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-   of protocols that run on top of TLS.
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-1.1 Requirements Terminology
-
-   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 [RFC2119].
-
-1.2 Major Differences from TLS 1.1
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-     - Merged in TLS Extensions definition and AES Cipher Suites from
-     external documents [TLSEXT] and [TLSAES].
-
-     - Replacement of MD5/SHA-1 combination in the PRF. Addition
-     of cipher-suite specified PRFs.
-
-     - Replacement of MD5/SHA-1 combination in the digitally-signed
-     element.
-
-     - Allow the client to indicate which hash functions it supports
-     for digital signature.
-
-     - Allow the server to indicate which hash functions it supports
-     for digital signature.
-
-     - Addition of support for authenticated encryption with additional
-     data modes.
-
-     - Tightened up a number of requirements.
-
-     - The usual clarifications and editorial work.
-
-     - Added some guidance that DH groups should be checked.
-
-     - Cleaned up description of Bleichenbacher/Klima attack defenses.
-
-     - Tighter checking of EncryptedPreMasterSecret version numbers.
-
-     - Stronger language about when alerts MUST be sent.
-
-     - Added an Implementation Pitfalls sections
-
-     - Harmonized the requirement to send an empty certificate list
-     after certificate_request even when no certs are available.
-
-     - Made the verify_data length depend on the cipher suite.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-     - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
-     cipher suite.
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that can successfully exchange
-       cryptographic parameters without knowledge of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: preventing
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and avoiding the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions). This
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   security.
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e., 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-       T T'[n];
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream. The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length. A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two-byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17-byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors. In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, an
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic Attributes
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
-   discussed in [PKCS1], the DigestInfo MUST be DER encoded and for
-   digest algorithms without parameters (which include SHA-1) the
-   DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
-   implementations MUST accept both without parameters and with NULL
-   parameters. Note that earlier versions of TLS used a different RSA
-   signature scheme which did not include a DigestInfo encoding.
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and the output is
-   generally larger than the input in order to accomodate the integrity
-   check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the encryption
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1].
-
-   In the following example
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   the contents of hash are used as input for the signing algorithm, and
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes, would be equal to two bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   because the algorithm and key used for the signing are known prior to
-   encoding or decoding this structure.
-
-4.8. Constants
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the Pseudorandom Function
-
-   The TLS record layer uses a keyed Message Authentication Code (MAC)
-   to protect message integrity. The cipher suites defined in this
-   document use a construction known as HMAC, described in [HMAC], which
-   is based on a hash function. Other cipher suites MAY define their own
-   MAC constructions, if needed.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In this section, we define one PRF, based on HMAC. This PRF with the
-   SHA-256 hash function is used for all cipher suites defined in this
-   document and in TLS documents published prior to this document. New
-   cipher suites MUST explicitly specify a PRF and in general SHOULD use
-   the TLS PRF with SHA-256 or a stronger standard hash function.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 is being used to
-   create 64 bytes of data, it will have to be iterated 4 times (through
-   A(4)), creating 80 bytes of output data; the last 16 bytes of the
-   final iteration will then be discarded, leaving 64 bytes of output
-   data.
-
-   TLS's PRF is created by applying P_hash to the secret S as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-   higher-level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. New record type values are assigned
-   by IANA as described in Section 12.
-
-   Implementations MUST NOT send record types not defined in this
-   document unless negotiated by some extension.  If a TLS
-   implementation receives an unexpected record type, it MUST send a
-   unexpected_message alert."
-
-   Any protocol designed for use over TLS MUST be carefully designed to
-   deal with all possible attacks against it.  Note that because the
-   type and length of a record are not protected by encryption, care
-   SHOULD be taken to minimize the value of traffic analysis of these
-   values.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, an encryption
-   algorithm, and a MAC algorithm. In addition, the parameters for these
-   algorithms are known: the MAC secret and the bulk encryption keys for
-   the connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state that has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block, stream, or AEAD cipher, and the
-       block size of the cipher (if appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the value returned by the MAC
-       algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48-byte secret shared between the two peers in the connection.
-
-   client random
-       A 32-byte value provided by the client.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   server random
-       A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
-
-       /* The use of "sha" above is historical and denotes SHA-1 */
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  enc_key_length;
-           uint8                  block_length;
-           uint8                  fixed_iv_length;
-           uint8                  record_iv_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  mac_length;
-           uint8                  mac_key_length;
-           uint8                  verify_data_length;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever state information is necessary to
-       allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection, as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number, it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record transmitted under a
-       particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher-level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.2, which uses the version { 3, 3 }. The
-       version value 3.3 is historical, deriving from the use of 3.1 for
-       TLS 1.0. (See Appendix A.1).  Note that a client that supports
-       multiple versions of TLS may not know what version will be
-       employed before it receives ServerHello.  See Appendix E for
-       discussion about what record layer version number should be
-       employed for ClientHello.
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length MUST NOT exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher-level protocol
-       specified by the type field.
-
-       Implementations MUST NOT send zero-length fragments of Handshake,
-       Alert, or Change Cipher Spec content types. Zero-length fragments
-       of Application data MAY be sent as they are potentially useful as
-       a traffic analysis countermeasure.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved.  Application data is generally of lower precedence
-       for transmission than other content types.  However, records MUST
-       be delivered to the network in the same order as they are
-       protected by the record layer.  Recipients MUST receive and
-       process interleaved application layer traffic during handshakes
-       subsequent to the first one on a connection.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length MUST NOT exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record Payload Protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (SecurityParameters.cipher_type) {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-               case aead: GenericAEADCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length MUST NOT exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       MAC(MAC_write_secret, seq_num + TLSCompressed.type +
-               TLSCompressed.version + TLSCompressed.length +
-               TLSCompressed.fragment);
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted,
-   and the MAC size is zero, implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   SecurityParameters.mac_length.
-
-6.2.3.2. CBC Block Cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-   struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       block-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       };
-   } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       The Initialization Vector (IV) SHOULD be chosen at random, and
-       MUST be unpredictable. Note that in versions of TLS prior to 1.1,
-       there was no IV field, and the last ciphertext block of the
-       previous record (the "CBC residue") was used as the IV. This was
-       changed to prevent the attacks described in [CBCATT]. For block
-       ciphers, the IV length is of length
-       SecurityParameters.record_iv_length which is equal to the
-       SecurityParameters.block_size.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes, as long as it results
-       in the TLSCiphertext.length being an integral multiple of the
-       block length. Lengths longer than necessary might be desirable to
-       frustrate attacks on a protocol that are based on analysis of the
-       lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and MUST use the bad_record_mac alert to
-       indicate padding errors.
-
-   padding_length
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of one more than the sum of SecurityParameters.block_length,
-   TLSCompressed.length, SecurityParameters.mac_length, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, then the length before padding is 82 bytes (this does
-          not include the IV. Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise, it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et al. [CBCTIME] have demonstrated a timing
-       attack on CBC padding based on the time required to compute the
-       MAC. In order to defend against this attack, implementations MUST
-       ensure that record processing time is essentially the same
-       whether or not the padding is correct.  In general, the best way
-       to do this is to compute the MAC even if the padding is
-       incorrect, and only then reject the packet. For instance, if the
-       pad appears to be incorrect, the implementation might assume a
-       zero-length pad and then compute the MAC. This leaves a small
-       timing channel, since MAC performance depends to some extent on
-       the size of the data fragment, but it is not believed to be large
-       enough to be exploitable, due to the large block size of existing
-       MACs and the small size of the timing signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-      struct {
-         opaque nonce_explicit[SecurityParameters.record_iv_length];
-
-         aead-ciphered struct {
-             opaque content[TLSCompressed.length];
-         };
-      } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD].  These inputs are as follows.
-
-   The key is either the client_write_key or the server_write_key.  No
-   MAC key is used.
-
-   Each AEAD cipher suite has to specify how the nonce supplied to the
-   AEAD operation is constructed, and what is the length of the
-   GenericAEADCipher.nonce_explicit part. In many cases, it is
-   appropriate to use the partially implicit nonce technique described
-   in Section 3.2.1 of [AEAD]; in this case, the implicit part SHOULD be
-   derived from key_block as client_write_iv and server_write_iv (as
-   described in Section 6.3), and the explicit part is included in
-   GenericAEAEDCipher.nonce_explicit.
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   Where "+" denotes concatenation.
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  The length will generally be larger than
-   TLSCompressed.length, but by an amount that varies with the AEAD
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-      AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
-                      additional_data)
-
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   IV, the "additional_data", and the AEADEncrypted value. The output is
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-   TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
-                                         additional_data)
-
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, each of which is generated from the master secret
-   in that order. Unused values are empty.
-
-   When keys and MAC secrets are generated, the master secret is used as
-   an entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.mac_key_length]
-       server_write_MAC_secret[SecurityParameters.mac_key_length]
-       client_write_key[SecurityParameters.enc_key_length]
-       server_write_key[SecurityParameters.enc_key_length]
-       client_write_IV[SecurityParameters.fixed_iv_length]
-       server_write_IV[SecurityParameters.fixed_iv_length]
-
-   The client_write_IV and server_write_IV are only generated for
-   implicit nonce techniques as described in Section 3.2.1 of [AEAD].
-
-   Implementation note:
-       The currently defined cipher suite which requires the most
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       material is AES_256_CBC_SHA. It requires 2 x 32 byte keys and 2 x
-       20 byte MAC secrets, for a total 104 bytes of key material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols that are used to allow peers to agree
-       upon security parameters for the record layer, to authenticate
-       themselves, to instantiate negotiated security parameters, and to
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [PKIX] certificate of the peer. This element of the
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the mac_length. (See
-         Appendix A.6 for formal definition.)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent.
-
- Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g., if it has to perform a time consuming public
-   key operation). Thus, a small window of time, during which the
-   recipient must buffer the data, MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed_RESERVED(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED(41),
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           unsupported_extension(110),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed.
-
-   Whenever an implementation encounters a condition which is defined as
-   a fatal alert, it MUST send the appropriate alert prior to closing
-   the connection. In cases where an implementation chooses to send an
-   alert which MAY be a warning alert but intends to close the
-   connection immediately afterwards, it MUST send that alert at the
-   fatal alert level.
-
-   If an alert with a level of warning is sent and received, generally
-   the connection can continue normally.  If the receiving party decides
-   not to proceed with the connection (e.g., after having received a
-   no_renegotiation alert that it is not willing to accept), it SHOULD
-   send a fatal alert to terminate the connection.
-
-
-   The following error alerts are defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed_RESERVED
-       This alert was used in some earlier versions of TLS, and may have
-       permitted certain attacks against the CBC mode [CBCATT].  It MUST
-       NOT be sent by compliant implementations.
-
-   record_overflow
-       A TLSCiphertext record was received that had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g., data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not any version of TLS.  It MUST
-       NOT be sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in some earlier versions of TLS.  It MUST NOT
-       be sent by compliant implementations.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized but not supported. (For example, old protocol versions
-       might be avoided for security reasons). This message is always
-       fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol (such as a memory allocation failure) makes it
-       impossible to continue. This message is always fatal.
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert.
-       At that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate is where a server has spawned a process to satisfy a
-       request; the process might receive security parameters (key
-       length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   unsupported_extension
-       sent by clients that receive an extended server hello containing
-       an extension that they did not put in the corresponding client
-       hello. This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not.  However, all messages that are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New Alert values are assigned by IANA as described in Section 12.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man in the middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support. The protocol has been designed to
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection. The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require. The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 46 bytes upwards.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   message may be sent, if it is required (e.g., if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Next,
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client MUST send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify possession of the private
-   key in the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-   Cipher Spec. At this point, the handshake is complete, and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other than
-   TLS_NULL_WITH_NULL_NULL is established).
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message that is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message types are assigned by IANA as described in
-   Section 12.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello Request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message is not intended to
-       establish which side is the client or server but merely to
-       initiate a new negotiation. Servers SHOULD NOT send a
-       HelloRequest immediately upon the client's initial connection.
-       It is the client's job to send a ClientHello at that time.
-
-       This message will be ignored by the client if the client is
-       currently negotiating a session. This message may be ignored by
-       the client if it does not wish to renegotiate a session, or the
-       client may, if it wishes, respond with a no_renegotiation alert.
-       Since handshake messages are intended to have transmission
-       precedence over application data, it is expected that the
-       negotiation will begin before no more than a few records are
-       received from the client. If the server sends a hello request but
-       does not receive a client hello in response, it may close the
-       connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD NOT repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes that are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-   Structure of this message:
-       The client hello message includes a random structure, which is
-       used later in the protocol.
-
-       struct {
-          uint32 gmt_unix_time;
-          opaque random_bytes[28];
-       } Random;
-
-   gmt_unix_time
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher-
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable-length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or from another currently active connection. The second
-   option is useful if the client only wishes to update the random
-   structures and derived values of a connection, and the third option
-   makes it possible to establish several independent secure connections
-   without repeating the full handshake protocol. These independent
-   connections may occur sequentially or simultaneously; a SessionID
-   becomes valid when the handshake negotiating it completes with the
-   exchange of Finished messages and persists until it is removed due to
-   aging or because a fatal error was encountered on a connection
-   associated with the session. The actual contents of the SessionID are
-   defined by the server.
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST NOT place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-2>;
-           CompressionMethod compression_methods<1..2^8-1>;
-           select (extensions_present) {
-               case false:
-                   struct {};
-               case true:
-                   Extension extensions<0..2^16-1>;
-           };
-       } ClientHello;
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block. The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello. Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field but is used for compatibility with TLS before
-   extensions were defined.
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.3 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available, or it
-       the client wishes to generate new security parameters.
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it MUST include
-       the compression_method from that session. This vector MUST
-       contain, and all implementations MUST support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   client_hello_extension_list
-       Clients MAY request extended functionality from servers by
-       sending data in the client_hello_extension_list.  Here the new
-       "client_hello_extension_list" field contains a list of
-       extensions.  The actual "Extension" format is defined in Section
-       7.4.1.4.
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-   client MAY abort the handshake.  A server that supports the
-   extensions mechanism MUST accept only client hello messages in either
-   the original (TLS 1.0/TLS 1.1) ClientHello or the extended
-   ClientHello format defined in this document, and (as for all other
-   messages) MUST check that the amount of data in the message precisely
-   matches one of these formats; if not then it MUST send a fatal
-   "decode_error" alert.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-
-7.4.1.3. Server Hello
-
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-           struct {
-               ProtocolVersion server_version;
-               Random random;
-               SessionID session_id;
-               CipherSuite cipher_suite;
-               CompressionMethod compression_method;
-               select (extensions_present) {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-                   case false:
-                       struct {};
-                   case true:
-                       Extension extensions<0..2^16-1>;
-               };
-           } ServerHello;
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.3.  (See
-       Appendix E for details about backward compatibility.)
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with. Note that there is no requirement
-       that the server resume any session even if it had formerly
-       provided a session_id. Client MUST be prepared to do a full
-       negotiation -- including negotiating new cipher suites -- during
-       any handshake.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions, this field is
-       the value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       this field is the value from the resumed session state.
-
-   server_hello_extension_list
-       A list of extensions. Note that only extensions offered by the
-       client can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format is:
-
-         struct {
-             ExtensionType extension_type;
-             opaque extension_data<0..2^16-1>;
-         } Extension;
-
-         enum {
-             signature_hash_types(TBD-BY-IANA), (65535)
-         } ExtensionType;
-
-
-   Here:
-
-     - "extension_type" identifies the particular extension type.
-
-     - "extension_data" contains information specific to the particular
-   extension type.
-
-   The initial set of extensions is defined in a companion document
-   [TLSEXT]. The list of extension types is maintained by IANA as
-   described in Section 12.
-
-   There are subtle (and not so subtle) interactions that may occur in
-   this protocol between new features and existing features which may
-   result in a significant reduction in overall security, The following
-   considerations should be taken into account when designing new
-   extensions:
-
-     -  Some cases where a server does not agree to an extension are
-   error
-       conditions, and some simply a refusal to support a particular
-       feature.  In general error alerts should be used for the former,
-       and a field in the server extension response for the latter.
-
-     -  Extensions should as far as possible be designed to prevent any
-       attack that forces use (or non-use) of a particular feature by
-       manipulation of handshake messages.  This principle should be
-       followed regardless of whether the feature is believed to cause a
-       security problem.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       Often the fact that the extension fields are included in the
-       inputs to the Finished message hashes will be sufficient, but
-       extreme care is needed when the extension changes the meaning of
-       messages sent in the handshake phase. Designers and implementors
-       should be aware of the fact that until the handshake has been
-       authenticated, active attackers can modify messages and insert,
-       remove, or replace extensions.
-
-     -  It would be technically possible to use extensions to change
-       major aspects of the design of TLS; for example the design of
-       cipher suite negotiation.  This is not recommended; it would be
-       more appropriate to define a new version of TLS - particularly
-       since the TLS handshake algorithms have specific protection
-       against version rollback attacks based on the version number, and
-       the possibility of version rollback should be a significant
-       consideration in any major design change.
-
-7.4.1.4.1 Cert Hash Types
-
-       The client MAY use the "signature_hash_types" to indicate to the
-       server which hash functions may be used in digital signatures.
-       The "extension_data" field of this extension contains:
-
-             enum{
-                 md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
-             } HashType;
-
-             struct {
-                   HashType types<1..255>;
-             } SignatureHashTypes;
-
-   These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
-   and SHA-512 [SHA] respectively. The server MUST NOT send this
-   extension. The values are indicated in descending order of
-   preference.
-
-   Clients SHOULD send this extension if they support any algorithm
-   other than SHA-1. If this extension is not used, servers SHOULD
-   assume that the client supports only SHA-1. Note: this is a change
-   from TLS 1.1 where there are no explicit rules but as a practical
-   matter one can assume that the peer supports MD5 and SHA-1.
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method uses certificates for authentication (this
-       includes all key exchange methods defined in this document except
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       DH_anon).  This message will always immediately follow the server
-       hello message.
-
-   Meaning of this message:
-       The certificate type MUST be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-       certificate. It MUST contain a key that matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-       algorithm for the certificate MUST be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key MAY be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate MUST
-                               allow the key to be used for encryption.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_RSA                 RSA public key that can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate MUST be RSA.
-
-   All certificate profiles and key and cryptographic formats are
-   defined by the IETF PKIX working group [PKIX]. When a key usage
-   extension is present, the digitalSignature bit MUST be set for the
-   key to be eligible for signing, as described above, and the
-   keyEncipherment bit MUST be present to allow encryption, as described
-   above. The keyAgreement bit must be set on Diffie-Hellman
-   certificates.
-
-   As CipherSuites that specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate that specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret) or a public key for
-       some other algorithm.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   As additional CipherSuites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-   If the client has offered the SignatureHashTypes extension, the hash
-   function MUST be one of those listed in that extension. Otherwise it
-   MUST be assumed that only SHA-1 is supported.
-
-   If the SignatureAlgorithm being used to sign the ServerKeyExchange
-   message is DSA, the hash algorithm MUST be SHA-1.  [TODO: This is
-   incorrect. What it should say is that it must be specified in the
-   SPKI of the cert. However, I don't believe this is actually defined.
-   Rather, the DSA certs just say dsa. We need new certs to say
-   dsaWithSHAXXX.]
-
-   If the SignatureAlgorithm is RSA, then any hash function accepted by
-   the client MAY be used. The selected hash function MUST be indicated
-   in the digest_algorithm field of the signature structure.
-
-   The hash algorithm is denoted Hash below. Hash.length is the length
-   of the output of that algorithm.
-
-   Structure of this message:
-       enum { diffie_hellman, rsa} KeyExchangeAlgorithm;
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-           };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-           };
-        } ServerParams;
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       hash
-           Hash(ClientHello.random + ServerHello.random + ServerParams)
-
-       sha_hash
-           SHA1(ClientHello.random + ServerHello.random + ServerParams)
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-       struct {
-           select (SignatureAlgorithm) {
-               case anonymous: struct { };
-               case rsa:
-                   HashType digest_algorithm;       // NEW
-                   digitally-signed struct {
-                       opaque hash[Hash.length];
-                   };
-               case dsa:
-                   digitally-signed struct {
-                       opaque sha_hash[20];
-                   };
-               };
-           };
-       } Signature;
-
-7.4.4. Certificate Request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-           rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-           fortezza_dms_RESERVED(20),
-           (255)
-       } ClientCertificateType;
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           HashType certificate_hash<1..2^8-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-           This field is a list of the types of certificates requested,
-           sorted in order of the server's preference.
-
-       certificate_types
-           A list of the types of certificate types which the client may
-           offer.
-              rsa_sign        a certificate containing an RSA key
-              dss_sign        a certificate containing a DSS key
-              rsa_fixed_dh    a certificate signed with RSA and containing
-                              a static DH key.
-              dss_fixed_dh    a certificate signed with DSS and containing
-                              a static DH key
-
-           Certificate types rsa_sign and dss_sign SHOULD contain
-           certificates signed with the same algorithm. However, this is
-           not required. This is a holdover from TLS 1.0 and 1.1.
-
-
-       certificate_hash
-           A list of acceptable hash algorithms to be used in signatures
-           in both the client certificate and the CertificateVerify.
-           These algorithms are listed in descending order of
-           preference.
-
-
-       certificate_authorities
-           A list of the distinguished names [X501] of acceptable
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-           certificateauthorities, represented in DER-encoded format.
-           These distinguished names may specify a desired distinguished
-           name for a root CA or for a subordinate CA; thus, this
-           message can be used both to describe known roots and a
-           desired authorization space. If the certificate_authorities
-           list is empty then the client MAY send any certificate of the
-           appropriate ClientCertificateType, unless there is some
-           external arrangement to the contrary.
-
- New ClientCertificateType values are assigned by IANA as described in
-           Section 12.
-
-           Note: Values listed as RESERVED may not be used. They were
-           used in SSLv3.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-7.4.5 Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message, the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message, the client SHOULD
-       verify that the server provided a valid certificate, if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client Certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client MUST send a certificate message containing
-       no certificates. That is, the certificate_list structure has a
-       length of zero. If client authentication is required by the
-       server for the handshake to continue, it may respond with a fatal
-       handshake failure alert. Client certificates are sent using the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       Certificate structure defined in Section 7.4.2.
-
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate MUST match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client Key Exchange Message
-
-   When this message will be sent:
-       This message is always sent by the client. It MUST immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it MUST be the first message sent by the client after it receives
-       the server hello done message.
-
-   Meaning of this message:
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters that will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate that contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message MUST NOT contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate and sends the result
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       in an encrypted premaster secret message. This structure is a
-       variant of the client key exchange message and is not a message
-       in itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks.
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
- Note: The version number in the PreMasterSecret is the version offered
-           by the client in the ClientHello.client_version, not the
-           version negotiated for the connection.  This feature is
-           designed to prevent rollback attacks.  Unfortunately, some
-           old implementations use the negotiated version instead and
-           therefore checking the version number may lead to failure to
-           interoperate with such incorrect client implementations.
-
-           Client implementations MUST always send the correct version
-           number in PreMasterSecret. If ClientHello.client_version is
-           TLS 1.1 or higher, server implementations MUST check the
-           version number as described in the note below. If the version
-           number is earlier than 1.0, server implementations SHOULD
-           check the version number, but MAY have a configuration option
-           to disable the check. Note that if the check fails, the
-           PreMasterSecret SHOULD be randomized as described below.
-
-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
-   [KPR03] can be used to attack a TLS server that reveals whether a
-   particular message, when decrypted, is properly PKCS#1 formatted,
-   contains a valid PreMasterSecret structure, or has the correct
-   version number.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   The best way to avoid these vulnerabilities is to treat incorrectly
-   formatted messages in a manner indistinguishable from correctly
-   formatted RSA blocks. In other words:
-
-        1. Generate a string R of 46 random bytes
-
-        2. Decrypt the message M
-
-        3. If the PKCS#1 padding is not correct, or the length of
-           message M is not exactly 48 bytes:
-              premaster secret = ClientHello.client_version || R
-           else If ClientHello.client_version <= TLS 1.0, and
-           version number check is explicitly disabled:
-              premaster secret = M
-           else:
-              premaster secret = ClientHello.client_version || M[2..47]
-
-   In any case, a TLS server MUST NOT generate an alert if processing an
-   RSA-encrypted premaster secret message fails, or the version number
-   is not as expected. Instead, it MUST continue the handshake with a
-   randomly generated premaster secret.  It may be useful to log the
-   real cause of failure for troubleshooting purposes; however, care
-   must be taken to avoid leaking the information to an attacker
-   (though, e.g., timing, log files, or other channels.)
-
-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
-   against the Bleichenbacher attack. However, for maximal compatibility
-   with earlier versions of TLS, this specification uses the RSAES-
-   PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
-   to exist provided that the above recommendations are followed.
-
- Implementation Note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes. These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined. The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the the length bytes, encoding the RSA encrypted data
-   directly in the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes. The resulting
-   PDU is incompatible with many SSLv3 implementations. Implementors
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding. Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   behavior dependent on the protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-   on TLS are possible, at least when the client and server are on the
-   same LAN. Accordingly, implementations that use static RSA keys MUST
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
-
-7.4.7.2. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, and not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but it MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-
-       The hash function MUST be one of the algorithms offered in the
-       CertificateRequest message.
-
-       If the SignatureAlgorithm being used to sign the ServerKeyExchange
-       message is DSA, the hash function used MUST be SHA-1.
-       [TODO: This is incorrect. What it should say is that it must
-       be specified in the SPKI of the cert. However, I don't believe
-       this is actually defined. Rather, the DSA certs just say
-       dsa. We need new certs to say dsaWithSHAXXX]
-
-       If the SignatureAlgorithm is RSA, then any of the functions offered
-       by the server may be used. The selected hash function MUST be
-       indicated in the digest_algorithm field of the signature structure.
-
-       The hash algorithm is denoted Hash below.
-
-       CertificateVerify.signature.hash
-           Hash(handshake_messages);
-
-       CertificateVerify.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[SecurityParameters.verify_data_length];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, Hash(handshake_messages))
-           [0..SecurityParameters.verify_data_length-1];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-           Hash denotes the negotiated hash used for the PRF. If a new
-           PRF is defined, then this hash MUST be specified.
-
-           In previous versions of TLS, the verify_data was always 12
-           octets long. In the current version of TLS, it depends on the
-           cipher suite. Any cipher suite which does not explicitly
-           specify SecurityParameters.verify_data_length has a
-           SecurityParameters.verify_data_length equal to 12. This
-           includes all existing cipher suites.  Note that this
-           representation has the same encoding as with previous
-           versions.
-
-           Future cipher suites MAY specify other lengths but such
-           length MUST be at least 12 bytes.
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts, and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_AES_128_CBC_SHA.
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-12. IANA Considerations
-
-   This document uses several registries that were originally created in
-   [RFC4346]. IANA is requested to update (has updated) these to
-   reference this document. The registries and their allocation policies
-   (unchanged from [TLS1.1]) are listed below.
-
-   o  TLS ClientCertificateType Identifiers Registry: Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434]. Values in the range 64-223
-      (decimal) inclusive are assigned Specification Required
-      [RFC2434]. Values from 224-255 (decimal) inclusive are
-      reserved for Private Use [RFC2434].
-
-   o  TLS Cipher Suite Registry: Future values with the first byte
-      in the range 0-191 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values with the first byte in
-      the range 192-254 (decimal) are assigned via Specification
-      Required [RFC2434]. Values with the first byte 255 (decimal)
-      are reserved for Private Use [RFC2434].
-
-   o  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   o  TLS Alert Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   o  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA is requested to update (has updated) it to reference this
-   document.  The registry and its allocation policy (unchanged from
-   [RFC4366]) is listed below:.
-
-   o  TLS ExtensionType Registry: Future values are allocated
-      via IETF Consensus [RFC2434]
-
-   In addition, this document defines one new registry to be maintained
-   by IANA:
-
-   o  TLS HashType Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.7.
-      Future values in the range 0-63 (decimal) inclusive are
-      assigned via Standards Action [RFC2434].  Values in the
-      range 64-223 (decimal) inclusive are assigned via
-      Specification Required [RFC2434].  Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   This document defines one new TLS extension, cert_hash_type, which is
-   to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
-   registry.
-
-   This document also uses the TLS Compression Method Identifiers
-   Registry, defined in [RFC3749].  IANA is requested to allocate value
-   0 for the "null" compression method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-Appendix A. Protocol Constant Values
-
-   This section describes protocol types and constants.
-
-A.1. Record Layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (SecurityParameters.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-            case aead: GenericAEADCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[SecurityParameters.mac_length];
-    } GenericStreamCipher;
-
-    struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-        opaque IV[SecurityParameters.record_iv_length];
-        block-ciphered struct {
-            opaque content[TLSCompressed.length];
-            opaque MAC[SecurityParameters.mac_length];
-            uint8 padding[GenericBlockCipher.padding_length];
-            uint8 padding_length;
-        };
-    } GenericBlockCipher;
-
-    aead-ciphered struct {
-        opaque IV[SecurityParameters.iv_length];
-        opaque aead_output[AEADEncrypted.length];
-    } GenericAEADCipher;
-
-A.2. Change Cipher Specs Message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed_RESERVED(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED(41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-            no_renegotiation(100),
-            unsupported_extension(110),           /* new */
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-A.4. Handshake Protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20)
-     (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello Messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-        CompressionMethod compression_methods<1..2^8-1>;
-        select (extensions_present) {
-            case false:
-                struct {};
-            case true:
-                Extension extensions<0..2^16-1>;
-        };
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-        select (extensions_present) {
-            case false:
-                struct {};
-            case true:
-                Extension extensions<0..2^16-1>;
-        };
-    } ServerHello;
-
-    struct {
-        ExtensionType extension_type;
-        opaque extension_data<0..2^16-1>;
-    } Extension;
-
-    enum {
-        signature_hash_types(TBD-BY-IANA), (65535)
-    } ExtensionType;
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-        }
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-            case anonymous: struct { };
-            case rsa:
-                HashType digest_algorithm;       // NEW
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-            case dsa:
-                digitally-signed struct {
-                    opaque sha_hash[20];
-                };
-            };
-        };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-     rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-     fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-    struct {
-        opaque verify_data[SecurityParameters.verify_data_length];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.2.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   not be negotiated, as it provides no more protection than an
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-    CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x2F };
-    CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x35 };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-    CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA        = { 0x00, 0x30 };
-    CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA        = { 0x00, 0x31 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x32 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x33 };
-    CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA        = { 0x00, 0x36 };
-    CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA        = { 0x00, 0x37 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x38 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x39 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks.  Using
-   this mode therefore is of limited use: These ciphersuites MUST NOT be
-   used by TLS 1.2 implementations unless the application layer has
-   specifically requested to allow anonymous key exchange.  (Anonymous
-   key exchange may sometimes be acceptable, for example, to support
-   opportunistic encryption when no set-up for authentication is in
-   place, or when TLS is used as part of more complex security protocols
-   that have other means to ensure authentication.)
-
-     CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00, 0x18 };
-     CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00, 0x1A };
-     CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x1B };
-     CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
-     CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.2 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.2 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.2 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
- New cipher suite values are assigned by IANA as described in Section
-   12.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 enc_key_length;
-           uint8 block_length;
-        uint8 fixed_iv_length;
-           uint8 record_iv_length;
-           MACAlgorithm mac_algorithm;
-           uint8 mac_length;
-           uint8 mac_key_length;
-           uint8 verify_data_length;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.  AES is a
-       block cipher with a 128, 192, or 256 bit keys and a 16 byte block
-       size. [AES] TLS currently only supports the 128 and 256 bit key
-       sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-       A symmetric encryption algorithm that simultaneously provides
-       confidentiality and message integrity.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer-to-peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard", published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest, described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters that can be shared among
-       multiple connections. Sessions are used to avoid the expensive
-       negotiation of new security parameters for each connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-Appendix C. CipherSuite Definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_CBC_SHA            RSA            AES_256_CBC  SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC4_128      Stream  16         16         0     N/A
-    DES_CBC      Block    8          8         8      8
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm.
-
-   IV Size
-       The amount of data needed to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers (this is equal to SecurityParameters.record_iv_length).
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably SHA-1, are acceptable,
-   but cannot provide more security than the size of the random number
-   generator state.
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-D.4 Implementation Pitfalls
-
-   Implementation experience has shown that certain parts of earlier TLS
-   specifications are not easy to understand, and have been a source of
-   interoperability and security problems. Many of these areas have been
-   clarified in this document, but this appendix contains a short list
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   of the most important things that require special attention from
-   implementors.
-
-   TLS protocol issues:
-
-   o  Do you correctly handle handshake messages that are fragmented
-      to multiple TLS records (see Section 6.2.1)? Including corner
-      cases like a ClientHello that is split to several small
-      fragments?
-
-   o  Do you ignore the TLS record layer version number in all TLS
-      records before ServerHello (see Appendix E.1)?
-
-   o  Do you handle TLS extensions in ClientHello correctly,
-      including omitting the extensions field completely?
-
-   o  Do you support renegotiation, both client and server initiated?
-      While renegotiation this is an optional feature, supporting
-      it is highly recommended.
-
-   o  When the server has requested a client certificate, but no
-      suitable certificate is available, do you correctly send
-      an empty Certificate message, instead of omitting the whole
-      message (see Section 7.4.6)?
-
-   Cryptographic details:
-
-   o  In RSA-encrypted Premaster Secret,  do you correctly send and
-      verify the version number? When an error is encountered, do
-      you continue the handshake to avoid the Bleichenbacher
-      attack (see Section 7.4.7.1)?
-
-   o  What countermeasures do you use to prevent timing attacks against
-      RSA decryption and signing operations (see Section 7.4.7.1)?
-
-   o  When verifying RSA signatures, do you accept both NULL and
-      missing parameters (see Section 4.7)? Do you verify that the
-      RSA padding doesn't have additional data after the hash value?
-      [FI06]
-
-   o  When using Diffie-Hellman key exchange, do you correctly strip
-      leading zero bytes from the negotiated key (see Section 8.1.2)?
-
-   o  Does your TLS client check that the Diffie-Hellman parameters
-      sent by the server are acceptable (see Section F.1.1.3)?
-
-   o  How do you generate unpredictable IVs for CBC mode ciphers
-      (see Section 6.2.3.2)?
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   o  How do you address CBC mode timing attacks (Section 6.2.3.2)?
-
-   o  Do you use a strong and, most importantly, properly seeded
-      random number generator (see Appendix D.1) for generating the
-      premaster secret (for RSA key exchange), Diffie-Hellman private
-      values, the DSA "k" parameter, and other security-critical
-      values?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-Appendix E. Backward Compatibility
-
-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client support the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version. If the server does not support this
-   version, it will respond with ServerHello containing an older version
-   number. If the client agrees to use this version, the negotiation
-   will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing version number
-   smaller than the highest supported version. If the server wishes to
-   negotiate with old clients, it will proceed as appropriate for the
-   highest version supported by the server that is not greater than
-   ClientHello.client_version. For example, if the server supports TLS
-   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing
-   to use) only versions greater than client_version, it MUST send a
-   "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
- Note: some server implementations are known to implement version
-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   that simply close the connection when the client offers a version
-   newer than TLS 1.0. Also, it is known that some servers will refuse
-   connection if any TLS extensions are included in ClientHello.
-   Interoperability with such buggy servers is a complex topic beyond
-   the scope of this document, and may require multiple connection
-   attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed). Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number. Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version. No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2 Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
-   contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS ciphersuites in the
-   CIPHER-SPECS-DATA field as described below.
-
-Warning: The ability to send version 2.0 CLIENT-HELLO messages will be
-   phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-   However, even TLS servers that do not support SSL 2.0 SHOULD accept
-   version 2.0 CLIENT-HELLO messages. The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions. Note that this message MUST be sent directly on the wire,
-   not wrapped as a TLS record. For the purposes of calculating Finished
-   and CertificateVerify, the msg_length field is not considered to be a
-   part of the handshake message.
-
-       uint8 V2CipherSpec[3];
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       The highest bit MUST be 1; the remaining bits contain the
-       length of the following data in bytes.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-       version 2 client hello message. The value MUST be one (1).
-
-   version
-       Equal to ClientHello.client_version.
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero for a client that claims to
-       support TLS 1.2.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. Historically, permissible values are between
-       16 and 32 bytes inclusive. When using the SSLv2 backward
-       compatible handshake the client SHOULD use a 32 byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. In addition to the 2.0 cipher specs defined in [SSL2],
-       this includes the TLS cipher suites normally sent in
-       ClientHello.cipher_suites, each cipher suite prefixed by a zero
-       byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
-       {0x00,0x00,0x0A}.
-
-   session_id
-       This field MUST be empty.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   challenge
-       Corresponds to ClientHello.random. If the challenge length is
-       less than 32, the TLS server will pad the data with leading
-       (note: not trailing) zero bytes to make it 32 bytes long.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.3. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   MUST use special PKCS#1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
-   the right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).
-
-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
-   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
-   padding bytes are 0x03. If they are not, the server SHOULD generate a
-   random value for SECRET-KEY-DATA, and continue the handshake (which
-   will eventually fail since the keys will not match).  Note that
-   reporting the error situation to the client could make the server
-   vulnerable to attacks described in [BLEI].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.9 and 6.3). By sending a correct finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange. With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-   from the server key exchange message. The result is sent in a client
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   key exchange message. Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key. TLS
-   users desiring Perfect Forward Secrecy should use DHE cipher suites.
-   The damage done by exposure of a private key can be limited by
-   changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.9). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly, therefore the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-   Because TLS allows the server to provide arbitrary DH groups, the
-   client SHOULD verify the correctness of the DH group. [TODO: provide
-   a reference to some document describing how] and that it is of
-   suitable size as defined by local policy. The client SHOULD also
-   verify that the DH public exponent appears to be of adequate size.
-   The server MAY choose to assist the client by providing a known
-   group, such as those defined in [IKEALG] or [MODP]. These can be
-   verified by simple comparison.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Altering
-   the padding of the least significant 8 bytes of the PKCS padding does
-   not impact security for the size of the signed hashes and RSA key
-   lengths used in the protocol, since this is essentially equivalent to
-   increasing the input block size by 8 bytes.
-
-F.1.3. Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations.
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64 bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent, so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-       [CBCATT] describes a chosen plaintext attack on TLS that depends
-       on knowing the IV for a record. Previous versions of TLS [TLS1.0]
-       used the CBC residue of the previous record as the IV and
-       therefore enabled this attack. This version uses an explicit IV
-       in order to protect against this attack.
-
-F.4. Security of Composite Cipher Modes
-
-       TLS secures transmitted application data via the use of symmetric
-       encryption and authentication functions defined in the negotiated
-       ciphersuite.  The objective is to protect both the integrity  and
-       confidentiality of the transmitted data from malicious actions by
-       active attackers in the network.  It turns out that the order in
-       which encryption and authentication functions are applied to the
-       data plays an important role for achieving this goal [ENCAUTH].
-
-       The most robust method, called encrypt-then-authenticate, first
-       applies encryption to the data and then applies a MAC to the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-       ciphertext.  This method ensures that the integrity and
-       confidentiality goals are obtained with ANY pair of encryption
-       and MAC functions, provided that the former is secure against
-       chosen plaintext attacks and that the MAC is secure against
-       chosen-message attacks.  TLS uses another method, called
-       authenticate-then-encrypt, in which first a MAC is computed on
-       the plaintext and then the concatenation of plaintext and MAC is
-       encrypted.  This method has been proven secure for CERTAIN
-       combinations of encryption functions and MAC functions, but it is
-       not guaranteed to be secure in general. In particular, it has
-       been shown that there exist perfectly secure encryption functions
-       (secure even in the information-theoretic sense) that combined
-       with any secure MAC function, fail to provide the confidentiality
-       goal against an active attack.  Therefore, new ciphersuites and
-       operation modes adopted into TLS need to be analyzed under the
-       authenticate-then-encrypt method to verify that they achieve the
-       stated integrity and confidentiality goals.
-
-       Currently, the security of the authenticate-then-encrypt method
-       has been proven for some important cases.  One is the case of
-       stream ciphers in which a computationally unpredictable pad of
-       the length of the message, plus the length of the MAC tag, is
-       produced using a pseudo-random generator and this pad is xor-ed
-       with the concatenation of plaintext and MAC tag.  The other is
-       the case of CBC mode using a secure block cipher.  In this case,
-       security can be shown if one applies one CBC encryption pass to
-       the concatenation of plaintext and MAC and uses a new,
-       independent, and unpredictable IV for each new pair of plaintext
-       and MAC.  In previous versions of SSL, CBC mode was used properly
-       EXCEPT that it used a predictable IV in the form of the last
-       block of the previous ciphertext.  This made TLS open to chosen
-       plaintext attacks.  This version of the protocol is immune to
-       those attacks.  For exact details in the encryption modes proven
-       secure, see [ENCAUTH].
-
-F.5 Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption. However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections. In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH] or ESP [ESP].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-
-Changes in This Version
-
-   [RFC Editor: Please delete this]
-
-     - Added compression methods to the IANA considerations.
-
-     - Misc. editorial changes/clarifications
-
-     - Added an Implementation Pitfalls sections
-     [Issue 26]
-
-     - Harmonized the requirement to send an empty certificate list
-     after certificate_request even when no certs are available.
-     [Issue 48]
-
-     - Made the verify_data length depend on the cipher suite
-     [Issue 49]
-
-     - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
-     cipher suite [Issue 56]
-
-
-Normative References
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   National Institute of Standards and Technology,
-            "Recommendation for the Triple Data Encryption Algorithm
-            (TDEA) Block Cipher", NIST Special Publication 800-67, May
-            2004.
-
-   [DES]    National Institute of Standards and Technology, "Data
-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.  PKI
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication", RFC 2104, February
-            1997.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
-            Public Key Infrastructure Certificate and Certificate
-            Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, March 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2nd ed.", Published by John Wiley &
-            Sons, Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,
-            October 1998.
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "Authenticated Encryption", February 2007,
-            draft-mcgrew-auth-enc-02.txt.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            4302, December 2005.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
-            "Password Interception in a SSL/TLS Channel", Advances in
-            Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
-
-   [CCM]     "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/800-38C/SP800-38C.pdf
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 4303, December 2005.
-
-   [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
-            implementation error", ietf-openpgp@imc.org mailing list, 27
-            August 2006, http://www.imc.org/ietf-openpgp/mail-
-            archive/msg14307.html.
-
-   [GCM]     "NIST Special Publication 800-38D DRAFT (June, 2007):
-            Recommendation for Block Cipher Modes of Operation:
-            Galois/Counter Mode (GCM) and GMAC"
-
-   [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
-            Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
-            2005.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [MODP]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-            Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
-            3526, May 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-            "Randomness Requirements for Security", BCP 106, RFC 4086,
-            June 2005.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
-            Compression Methods", RFC 3749, May 2004.
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            4366, April 2006.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
-            Protocol", Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSEXT], Eastlake, D.E.,  "Transport Layer Security (TLS)
-            Extensions: Extension Definitions", July 2007, draft-ietf-
-            tls-rfc4366-bis-00.txt.
-
-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
-            1.1", RFC 4346, April, 2006.
-
-   [X501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [XDR]    Srinivansan, R., Sun Microsystems, "XDR: External Data
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-            Representation Standard", RFC 1832, August 1995.
-
-
-Credits
-
-   Working Group Chairs
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 92]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Alfred Hoenes
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 93]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-       <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 94]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-   Full Copyright Statement
-
-      Copyright (C) The IETF Trust (2007).
-
-      This document is subject to the rights, licenses and restrictions
-      contained in BCP 78, and except as set forth therein, the authors
-      retain all their rights.
-
-      This document and the information contained herein are provided on an
-      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-      OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-      OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-   Intellectual Property
-
-      The IETF takes no position regarding the validity or scope of any
-      Intellectual Property Rights or other rights that might be claimed to
-      pertain to the implementation or use of the technology described in
-      this document or the extent to which any license under such rights
-      might or might not be available; nor does it represent that it has
-      made any independent effort to identify any such rights.  Information
-      on the procedures with respect to rights in RFC documents can be
-      found in BCP 78 and BCP 79.
-
-      Copies of IPR disclosures made to the IETF Secretariat and any
-      assurances of licenses to be made available, or the result of an
-      attempt made to obtain a general license or permission for the use of
-      such proprietary rights by implementers or users of this
-      specification can be obtained from the IETF on-line IPR repository at
-      http://www.ietf.org/ipr.
-
-      The IETF invites any interested party to bring to its attention any
-      copyrights, patents or patent applications, or other proprietary
-      rights that may cover technology that may be required to implement
-      this standard.  Please address the information to the IETF at
-      ietf-ipr@ietf.org.
-
-
-   Acknowledgment
-
-      Funding for the RFC Editor function is provided by the IETF
-      Administrative Support Activity (IASA).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 95]draft-ietf-tls-rfc4346-bis-05.txt  TLS                         June 2007
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 96]
\ No newline at end of file
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-06.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-06.txt
deleted file mode 100644
index 7b2208a1bb..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-06.txt
+++ /dev/null
@@ -1,5349 +0,0 @@
-
-
-
-
-
-INTERNET-DRAFT                                                Tim Dierks
-Obsoletes (if approved):  RFC 3268, 4346, 4366              Independent
-Intended status:  Proposed Standard                        Eric Rescorla
-                                                 Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-06.txt>    October 2007 (Expires April 2008)
-
-              The Transport Layer Security (TLS) Protocol
-                              Version 1.2
-
-Status of this Memo
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2007).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.        Introduction                                             3
-   1.1       Requirements Terminology                                 5
-   1.2       Major Differences from TLS 1.1                           5
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 1]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   2.        Goals                                                    6
-   3.        Goals of This Document                                   6
-   4.        Presentation Language                                    7
-   4.1.      Basic Block Size                                         7
-   4.2.      Miscellaneous                                            7
-   4.3.      Vectors                                                  7
-   4.4.      Numbers                                                  8
-   4.5.      Enumerateds                                              9
-   4.6.      Constructed Types                                        10
-   4.6.1.    Variants                                                 10
-   4.7.      Cryptographic Attributes                                 11
-   4.8.      Constants                                                13
-   5.        HMAC and the Pseudorandom Function                       13
-   6.        The TLS Record Protocol                                  14
-   6.1.      Connection States                                        15
-   6.2.      Record layer                                             17
-   6.2.1.    Fragmentation                                            17
-   6.2.2.    Record Compression and Decompression                     19
-   6.2.3.    Record Payload Protection                                19
-   6.2.3.1.  Null or Standard Stream Cipher                           20
-   6.2.3.2.  CBC Block Cipher                                         21
-   6.2.3.3.  AEAD ciphers                                             23
-   6.3.      Key Calculation                                          24
-   7.        The TLS Handshaking Protocols                            25
-   7.1.      Change Cipher Spec Protocol                              25
-   7.2.      Alert Protocol                                           26
-   7.2.1.    Closure Alerts                                           27
-   7.2.2.    Error Alerts                                             28
-   7.3.      Handshake Protocol Overview                              31
-   7.4.      Handshake Protocol                                       34
-   7.4.1.    Hello Messages                                           35
-   7.4.1.1.  Hello Request                                            36
-   7.4.1.2.  Client Hello                                             36
-   7.4.1.3.  Server Hello                                             39
-   7.4.1.4   Hello Extensions                                         41
-   7.4.1.4.1 Signature Hash Algorithms                                42
-   7.4.2.    Server Certificate                                       43
-   7.4.3.    Server Key Exchange Message                              46
-   7.4.4.    Certificate Request                                      49
-   7.4.5     Server hello done                                        50
-   7.4.6.    Client Certificate                                       51
-   7.4.7.    Client Key Exchange Message                              52
-   7.4.7.1.  RSA Encrypted Premaster Secret Message                   53
-   7.4.7.2.  Client Diffie-Hellman Public Value                       55
-   7.4.8.    Certificate verify                                       56
-   7.4.9.    Finished                                                 57
-   8.        Cryptographic Computations                               58
-   8.1.      Computing the Master Secret                              58
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 2]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   8.1.1.    RSA                                                      59
-   8.1.2.    Diffie-Hellman                                           59
-   9.        Mandatory Cipher Suites                                  59
-   10.       Application Data Protocol                                59
-   11.       Security Considerations                                  59
-   12.       IANA Considerations                                      59
-   A.        Protocol Constant Values                                 62
-   A.1.      Record Layer                                             62
-   A.2.      Change Cipher Specs Message                              63
-   A.3.      Alert Messages                                           63
-   A.4.      Handshake Protocol                                       65
-   A.4.1.    Hello Messages                                           65
-   A.4.2.    Server Authentication and Key Exchange Messages          67
-   A.4.3.    Client Authentication and Key Exchange Messages          68
-   A.4.4.    Handshake Finalization Message                           68
-   A.5.      The CipherSuite                                          69
-   A.6.      The Security Parameters                                  71
-   B.        Glossary                                                 73
-   C.        CipherSuite Definitions                                  77
-   D.        Implementation Notes                                     79
-   D.1       Random Number Generation and Seeding                     79
-   D.2       Certificates and Authentication                          79
-   D.3       CipherSuites                                             79
-   D.4       Implementation Pitfalls                                  79
-   E.        Backward Compatibility                                   82
-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0               82
-   E.2       Compatibility with SSL 2.0                               83
-   E.3.      Avoiding Man-in-the-Middle Version Rollback              85
-   F.        Security Analysis                                        86
-   F.1.      Handshake Protocol                                       86
-   F.1.1.    Authentication and Key Exchange                          86
-   F.1.1.1.  Anonymous Key Exchange                                   86
-   F.1.1.2.  RSA Key Exchange and Authentication                      87
-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication          87
-   F.1.2.    Version Rollback Attacks                                 88
-   F.1.3.    Detecting Attacks Against the Handshake Protocol         89
-   F.1.4.    Resuming Sessions                                        89
-   F.2.      Protecting Application Data                              89
-   F.3.      Explicit IVs                                             90
-   F.4.      Security of Composite Cipher Modes                       90
-   F.5       Denial of Service                                        91
-   F.6       Final Notes                                              92
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 3]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     -  The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     -  The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     -  The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     -  The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     -  The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 4]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   of protocols that run on top of TLS.
-
-1.1 Requirements Terminology
-
-   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 [REQ].
-
-1.2 Major Differences from TLS 1.1
-
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-     - Merged in TLS Extensions definition and AES Cipher Suites from
-     external documents [TLSEXT] and [TLSAES].
-
-     - Replacement of MD5/SHA-1 combination in the PRF. Addition
-     of cipher-suite specified PRFs.
-
-     - Replacement of MD5/SHA-1 combination in the digitally-signed
-     element.
-
-     - Substantial cleanup to the clients and servers ability to
-     specify which digest and signature algorithms they will
-     accept. Note that this also relaxes some of the constraints
-     on signature and digest algorithms from previous versions of
-     TLS.
-
-     - Addition of support for authenticated encryption with additional
-     data modes.
-
-     - Tightened up a number of requirements.
-
-     - Added some guidance that DH groups should be checked for size.
-
-     - Cleaned up description of Bleichenbacher/Klima attack defenses.
-
-     - Tighter checking of EncryptedPreMasterSecret version numbers.
-
-     - Stronger language about when alerts MUST be sent.
-
-     - Added an Implementation Pitfalls sections
-
-     - Harmonized the requirement to send an empty certificate list
-     after certificate_request even when no certs are available.
-
-     - Made the verify_data length depend on the cipher suite.
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 5]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-     - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
-     cipher suite.
-
-     - The usual clarifications and editorial work.
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that can successfully exchange
-       cryptographic parameters without knowledge of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: preventing
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and avoiding the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions). This
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 6]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e., 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 7]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream. The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length. A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two-byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17-byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 8]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors. In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-
-
-
-Dierks & Rescorla            Standards Track                     [Page 9]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 10]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, an
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic Attributes
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
-   discussed in [PKCS1], the DigestInfo MUST be DER encoded and for
-   digest algorithms without parameters (which include SHA-1) the
-   DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
-   implementations MUST accept both without parameters and with NULL
-   parameters. Note that earlier versions of TLS used a different RSA
-   signature scheme which did not include a DigestInfo encoding.
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 11]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
- Note: In current terminology, DSA refers to the Digital Signature
-   Algorithm and DSS refers to the NIST standard. For historical
-   reasons, this document uses DSS and DSA interchangeably
-   to refer to the DSA algorithm, as was done in SSLv3.
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and the output is
-   generally larger than the input in order to accomodate the integrity
-   check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the encryption
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1].
-
-   In the following example
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   the contents of hash are used as input for the signing algorithm, and
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes, would be equal to two bytes for
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 12]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   because the algorithm and key used for the signing are known prior to
-   encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the Pseudorandom Function
-
-   The TLS record layer uses a keyed Message Authentication Code (MAC)
-   to protect message integrity. The cipher suites defined in this
-   document use a construction known as HMAC, described in [HMAC], which
-   is based on a hash function. Other cipher suites MAY define their own
-   MAC constructions, if needed.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In this section, we define one PRF, based on HMAC. This PRF with the
-   SHA-256 hash function is used for all cipher suites defined in this
-   document and in TLS documents published prior to this document when
-   TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
-   PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger
-   standard hash function.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 13]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 is being used to
-   create 64 bytes of data, it will have to be iterated 4 times (through
-   A(4)), creating 80 bytes of output data; the last 16 bytes of the
-   final iteration will then be discarded, leaving 64 bytes of output
-   data.
-
-   TLS's PRF is created by applying P_hash to the secret as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-   higher-level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. New record type values are assigned
-   by IANA as described in Section 12.
-
-   Implementations MUST NOT send record types not defined in this
-   document unless negotiated by some extension.  If a TLS
-   implementation receives an unexpected record type, it MUST send an
-   unexpected_message alert.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 14]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   Any protocol designed for use over TLS MUST be carefully designed to
-   deal with all possible attacks against it.  Note that because the
-   type and length of a record are not protected by encryption, care
-   SHOULD be taken to minimize the value of traffic analysis of these
-   values.
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, an encryption
-   algorithm, and a MAC algorithm. In addition, the parameters for these
-   algorithms are known: the MAC secret and the bulk encryption keys for
-   the connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state that has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block, stream, or AEAD cipher, and the
-       block size and fixed initialization vector size of the cipher (if
-       appropriate).
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the value returned by the MAC
-       algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 15]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   master secret
-       A 48-byte secret shared between the two peers in the connection.
-
-   client random
-       A 32-byte value provided by the client.
-
-   server random
-       A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, idea, aes }
-         BulkCipherAlgorithm;
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
-            hmac_sha512} MACAlgorithm;
-
-       /* The use of "sha" above is historical and denotes SHA-1 */
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  enc_key_length;
-           uint8                  block_length;
-           uint8                  fixed_iv_length;
-           uint8                  record_iv_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  mac_length;
-           uint8                  mac_key_length;
-           uint8                  verify_data_length;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following six items:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 16]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-       client write IV
-       server write IV
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. For stream ciphers,
-       this will also contain whatever state information is necessary to
-       allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection, as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number MUST be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-       implementation would need to wrap a sequence number, it must
-       renegotiate instead. A sequence number is incremented after each
-       record: specifically, the first record transmitted under a
-       particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 17]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher-level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.2, which uses the version { 3, 3 }. The
-       version value 3.3 is historical, deriving from the use of 3.1 for
-       TLS 1.0. (See Appendix A.1).  Note that a client that supports
-       multiple versions of TLS may not know what version will be
-       employed before it receives ServerHello.  See Appendix E for
-       discussion about what record layer version number should be
-       employed for ClientHello.
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length MUST NOT exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher-level protocol
-       specified by the type field.
-
-       Implementations MUST NOT send zero-length fragments of Handshake,
-       Alert, or Change Cipher Spec content types. Zero-length fragments
-       of Application data MAY be sent as they are potentially useful as
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 18]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       a traffic analysis countermeasure.
-
- Note: Data of different TLS Record layer content types MAY be
-       interleaved.  Application data is generally of lower precedence
-       for transmission than other content types.  However, records MUST
-       be delivered to the network in the same order as they are
-       protected by the record layer.  Recipients MUST receive and
-       process interleaved application layer traffic during handshakes
-       subsequent to the first one on a connection.
-
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length MUST NOT exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record Payload Protection
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 19]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (SecurityParameters.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-               case aead: GenericAEADCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length MUST NOT exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       MAC(MAC_write_secret, seq_num + TLSCompressed.type +
-               TLSCompressed.version + TLSCompressed.length +
-               TLSCompressed.fragment);
-
-   where "+" denotes concatenation.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 20]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   seq_num
-       The sequence number for this record.
-
-   MAC
-       The MAC algorithm specified by SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted,
-   and the MAC size is zero, implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   SecurityParameters.mac_length.
-
-6.2.3.2. CBC Block Cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-   struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       block-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       };
-   } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-       The Initialization Vector (IV) SHOULD be chosen at random, and
-       MUST be unpredictable. Note that in versions of TLS prior to 1.1,
-       there was no IV field, and the last ciphertext block of the
-       previous record (the "CBC residue") was used as the IV. This was
-       changed to prevent the attacks described in [CBCATT]. For block
-       ciphers, the IV length is of length
-       SecurityParameters.record_iv_length which is equal to the
-       SecurityParameters.block_size.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding MAY be any length up to 255 bytes, as long as it results
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 21]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       in the TLSCiphertext.length being an integral multiple of the
-       block length. Lengths longer than necessary might be desirable to
-       frustrate attacks on a protocol that are based on analysis of the
-       lengths of exchanged messages. Each uint8 in the padding data
-       vector MUST be filled with the padding length value. The receiver
-       MUST check this padding and MUST use the bad_record_mac alert to
-       indicate padding errors.
-
-   padding_length
-       The padding length MUST be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of SecurityParameters.block_length, TLSCompressed.length,
-   SecurityParameters.mac_length, and padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, then the length before padding is 82 bytes (this does
-          not include the IV. Thus, the padding length modulo 8 must be
-          equal to 6 in order to make the total length an even multiple
-          of 8 bytes (the block length). The padding length can be 6,
-          14, 22, and so on, through 254. If the padding length were the
-          minimum necessary, 6, the padding would be 6 bytes, each
-          containing the value 6.  Thus, the last 8 octets of the
-          GenericBlockCipher before block encryption would be xx 06 06
-          06 06 06 06 06, where xx is the last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining),
-       it is critical that the entire plaintext of the record be known
-       before any ciphertext is transmitted. Otherwise, it is possible
-       for the attacker to mount the attack described in [CBCATT].
-
- Implementation Note: Canvel et al. [CBCTIME] have demonstrated a timing
-       attack on CBC padding based on the time required to compute the
-       MAC. In order to defend against this attack, implementations MUST
-       ensure that record processing time is essentially the same
-       whether or not the padding is correct.  In general, the best way
-       to do this is to compute the MAC even if the padding is
-       incorrect, and only then reject the packet. For instance, if the
-       pad appears to be incorrect, the implementation might assume a
-       zero-length pad and then compute the MAC. This leaves a small
-       timing channel, since MAC performance depends to some extent on
-       the size of the data fragment, but it is not believed to be large
-       enough to be exploitable, due to the large block size of existing
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 22]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       MACs and the small size of the timing signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-      struct {
-         opaque nonce_explicit[SecurityParameters.record_iv_length];
-
-         aead-ciphered struct {
-             opaque content[TLSCompressed.length];
-         };
-      } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD]. The key is either the
-   client_write_key or the server_write_key.  No MAC key is used.
-
-   Each AEAD cipher suite has to specify how the nonce supplied to the
-   AEAD operation is constructed, and what is the length of the
-   GenericAEADCipher.nonce_explicit part. In many cases, it is
-   appropriate to use the partially implicit nonce technique described
-   in Section 3.2.1 of [AEAD]; in this case, the implicit part SHOULD be
-   derived from key_block as client_write_iv and server_write_iv (as
-   described in Section 6.3), and the explicit part is included in
-   GenericAEAEDCipher.nonce_explicit.
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   Where "+" denotes concatenation.
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  The length will generally be larger than
-   TLSCompressed.length, but by an amount that varies with the AEAD
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 23]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-      AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
-                      additional_data)
-
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   IV, the "additional_data", and the AEADEncrypted value. The output is
-   either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-   TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
-                                         additional_data)
-
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6). CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, each of which is generated from the master secret
-   in that order. Unused values are empty.
-
-   When keys and MAC secrets are generated, the master secret is used as
-   an entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.mac_key_length]
-       server_write_MAC_secret[SecurityParameters.mac_key_length]
-       client_write_key[SecurityParameters.enc_key_length]
-       server_write_key[SecurityParameters.enc_key_length]
-       client_write_IV[SecurityParameters.fixed_iv_length]
-       server_write_IV[SecurityParameters.fixed_iv_length]
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 24]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   The client_write_IV and server_write_IV are only generated for
-   implicit nonce techniques as described in Section 3.2.1 of [AEAD].
-
-   Implementation note:
-       The currently defined cipher suite which requires the most
-       material is AES_256_CBC_SHA. It requires 2 x 32 byte keys and 2 x
-       20 byte MAC secrets, for a total 104 bytes of key material.
-
-7. The TLS Handshaking Protocols
-
-       TLS has three subprotocols that are used to allow peers to agree
-       upon security parameters for the record layer, to authenticate
-       themselves, to instantiate negotiated security parameters, and to
-       report error conditions to each other.
-
-       The Handshake Protocol is responsible for negotiating a session,
-       which consists of the following items:
-
-       session identifier
-         An arbitrary byte sequence chosen by the server to identify an
-         active or resumable session state.
-
-       peer certificate
-         X509v3 [PKIX] certificate of the peer. This element of the
-         state may be null.
-
-       compression method
-         The algorithm used to compress data prior to encryption.
-
-       cipher spec
-         Specifies the bulk data encryption algorithm (such as null,
-         DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
-         defines cryptographic attributes such as the mac_length. (See
-         Appendix A.6 for formal definition.)
-
-       master secret
-         48-byte secret shared between the client and server.
-
-       is resumable
-         A flag indicating whether the session can be used to initiate
-         new connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 25]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent.
-
- Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g., if it has to perform a time consuming public
-   key operation). Thus, a small window of time, during which the
-   recipient must buffer the data, MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 26]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-           decryption_failed_RESERVED(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED(41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           unsupported_extension(110),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 27]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed.
-
-   Whenever an implementation encounters a condition which is defined as
-   a fatal alert, it MUST send the appropriate alert prior to closing
-   the connection. In cases where an implementation chooses to send an
-   alert which may be a warning alert but intends to close the
-   connection immediately afterwards, it MUST send that alert at the
-   fatal alert level.
-
-   If an alert with a level of warning is sent and received, generally
-   the connection can continue normally.  If the receiving party decides
-   not to proceed with the connection (e.g., after having received a
-   no_renegotiation alert that it is not willing to accept), it SHOULD
-   send a fatal alert to terminate the connection.
-
-
-   The following error alerts are defined:
-
-   unexpected_message
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 28]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This alert also MUST be returned if an alert is sent because
-       a TLSCiphertext decrypted in an invalid way: either it wasn't an
-       even multiple of the block length, or its padding values, when
-       checked, weren't correct. This message is always fatal.
-
-   decryption_failed_RESERVED
-       This alert was used in some earlier versions of TLS, and may have
-       permitted certain attacks against the CBC mode [CBCATT].  It MUST
-       NOT be sent by compliant implementations.
-
-   record_overflow
-       A TLSCiphertext record was received that had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g., data
-       that would expand to excessive length). This message is always
-       fatal.
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-       This alert was used in SSLv3 but not any version of TLS.  It MUST
-       NOT be sent by compliant implementations.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 29]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This message is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn't be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-   export_restriction_RESERVED
-       This alert was used in some earlier versions of TLS.  It MUST NOT
-       be sent by compliant implementations.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized but not supported. (For example, old protocol versions
-       might be avoided for security reasons). This message is always
-       fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol (such as a memory allocation failure) makes it
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 30]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       impossible to continue. This message is always fatal.
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert.
-       At that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate is where a server has spawned a process to satisfy a
-       request; the process might receive security parameters (key
-       length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   unsupported_extension
-       sent by clients that receive an extended server hello containing
-       an extension that they did not put in the corresponding client
-       hello. This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not.  However, all messages that are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New Alert values are assigned by IANA as described in Section 12.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     -  Exchange hello messages to agree on algorithms, exchange random
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 31]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       values, and check for session resumption.
-
-     -  Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     -  Exchange certificates and cryptographic information to allow the
-       client and server to authenticate themselves.
-
-     -  Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     -  Provide security parameters to the record layer.
-
-     -  Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man in the middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support. The protocol has been designed to
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection. The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require. The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 32]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 46 bytes upwards.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g., if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Next,
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client MUST send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify possession of the private
-   key in the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-   Cipher Spec. At this point, the handshake is complete, and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other than
-   TLS_NULL_WITH_NULL_NULL is established).
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 33]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 34]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message that is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which SHOULD be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message types are assigned by IANA as described in
-   Section 12.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 35]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-7.4.1.1. Hello Request
-
-   When this message will be sent:
-       The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message is not intended to
-       establish which side is the client or server but merely to
-       initiate a new negotiation. Servers SHOULD NOT send a
-       HelloRequest immediately upon the client's initial connection.
-       It is the client's job to send a ClientHello at that time.
-
-       This message will be ignored by the client if the client is
-       currently negotiating a session. This message may be ignored by
-       the client if it does not wish to renegotiate a session, or the
-       client may, if it wishes, respond with a no_renegotiation alert.
-       Since handshake messages are intended to have transmission
-       precedence over application data, it is expected that the
-       negotiation will begin before no more than a few records are
-       received from the client. If the server sends a hello request but
-       does not receive a client hello in response, it may close the
-       connection with a fatal alert.
-
-   After sending a hello request, servers SHOULD NOT repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message MUST NOT be included in the message hashes that are
-       maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-   Structure of this message:
-       The client hello message includes a random structure, which is
-       used later in the protocol.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 36]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       struct {
-          uint32 gmt_unix_time;
-          opaque random_bytes[28];
-       } Random;
-
-   gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT, ignoring leap
-       seconds) according to the sender's internal clock. Clocks are not
-       required to be set correctly by the basic TLS Protocol; higher-
-       level or application protocols may define additional
-       requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable-length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or from another currently active connection. The second
-   option is useful if the client only wishes to update the random
-   structures and derived values of a connection, and the third option
-   makes it possible to establish several independent secure connections
-   without repeating the full handshake protocol. These independent
-   connections may occur sequentially or simultaneously; a SessionID
-   becomes valid when the handshake negotiating it completes with the
-   exchange of Finished messages and persists until it is removed due to
-   aging or because a fatal error was encountered on a connection
-   associated with the session. The actual contents of the SessionID are
-   defined by the server.
-
-       opaque SessionID<0..32>;
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers MUST NOT place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 37]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-2>;
-           CompressionMethod compression_methods<1..2^8-1>;
-           select (extensions_present) {
-               case false:
-                   struct {};
-               case true:
-                   Extension extensions<0..2^16-1>;
-           };
-       } ClientHello;
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block. The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello. Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field but is used for compatibility with TLS before
-   extensions were defined.
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This SHOULD be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.3 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field is empty if no session_id is available, or it the
-       client wishes to generate new security parameters.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 38]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector MUST include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it MUST include
-       the compression_method from that session. This vector MUST
-       contain, and all implementations MUST support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   client_hello_extension_list
-       Clients MAY request extended functionality from servers by
-       sending data in the client_hello_extension_list.  Here the new
-       "client_hello_extension_list" field contains a list of
-       extensions.  The actual "Extension" format is defined in Section
-       7.4.1.4.
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-   client MAY abort the handshake.  A server that supports the
-   extensions mechanism MUST accept client hello messages in either the
-   original (TLS 1.0/TLS 1.1) ClientHello or the extended ClientHello
-   format defined in this document, and (as for all other messages) MUST
-   check that the amount of data in the message precisely matches one of
-   these formats; if not then it MUST send a fatal "decode_error" alert.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-
-7.4.1.3. Server Hello
-
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-           struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 39]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-               ProtocolVersion server_version;
-               Random random;
-               SessionID session_id;
-               CipherSuite cipher_suite;
-               CompressionMethod compression_method;
-               select (extensions_present) {
-                   case false:
-                       struct {};
-                   case true:
-                       Extension extensions<0..2^16-1>;
-               };
-           } ServerHello;
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.3.  (See
-       Appendix E for details about backward compatibility.)
-
-   random
-       This structure is generated by the server and MUST be
-       independently generated from the ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with. Note that there is no requirement
-       that the server resume any session even if it had formerly
-       provided a session_id. Client MUST be prepared to do a full
-       negotiation -- including negotiating new cipher suites -- during
-       any handshake.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 40]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       ClientHello.cipher_suites. For resumed sessions, this field is
-       the value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-   server_hello_extension_list
-       A list of extensions. Note that only extensions offered by the
-       client can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format is:
-
-         struct {
-             ExtensionType extension_type;
-             opaque extension_data<0..2^16-1>;
-         } Extension;
-
-         enum {
-             signature_hash_algorithms(TBD-BY-IANA), (65535)
-         } ExtensionType;
-
-
-   Here:
-
-     - "extension_type" identifies the particular extension type.
-
-     - "extension_data" contains information specific to the particular
-   extension type.
-
-   The initial set of extensions is defined in a companion document
-   [TLSEXT]. The list of extension types is maintained by IANA as
-   described in Section 12.
-
-   There are subtle (and not so subtle) interactions that may occur in
-   this protocol between new features and existing features which may
-   result in a significant reduction in overall security, The following
-   considerations should be taken into account when designing new
-   extensions:
-
-     -  Some cases where a server does not agree to an extension are
-       error conditions, and some simply a refusal to support a
-       particular feature.  In general error alerts should be used for
-       the former, and a field in the server extension response for the
-       latter.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 41]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-     -  Extensions should as far as possible be designed to prevent any
-       attack that forces use (or non-use) of a particular feature by
-       manipulation of handshake messages.  This principle should be
-       followed regardless of whether the feature is believed to cause a
-       security problem.
-
-       Often the fact that the extension fields are included in the
-       inputs to the Finished message hashes will be sufficient, but
-       extreme care is needed when the extension changes the meaning of
-       messages sent in the handshake phase. Designers and implementors
-       should be aware of the fact that until the handshake has been
-       authenticated, active attackers can modify messages and insert,
-       remove, or replace extensions.
-
-     -  It would be technically possible to use extensions to change
-       major aspects of the design of TLS; for example the design of
-       cipher suite negotiation.  This is not recommended; it would be
-       more appropriate to define a new version of TLS - particularly
-       since the TLS handshake algorithms have specific protection
-       against version rollback attacks based on the version number, and
-       the possibility of version rollback should be a significant
-       consideration in any major design change.
-
-7.4.1.4.1 Signature Hash Algorithms
-
-   The client MAY use the "signature_hash_algorithms" to indicate to the
-   server which signature/hash algorithm pairs may be used in digital
-   signatures. The "extension_data" field of this extension contains a
-   "supported_signature_algorithms" value.
-
-       enum{
-           none(0), md5(1), sha1(2), sha256(3), sha384(4),
-           sha512(5), (255)
-       } HashAlgorithm;
-
-       enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
-
-       struct {
-             HashAlgorithm hash;
-          SignatureAlgorithm signature;
-       } SignatureAndHashAlgorithm;
-
-       SignatureAndHashAlgorithm
-         supported_signature_algorithms<2..2^16-1>;
-
-   Each SignatureAndHashAlgorithm value lists a single digest/signature
-   pair which the client is willing to verify. The values are indicated
-   in descending order of preference.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 42]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
- Note: Because not all signature algorithms and hash algorithms may be
-   accepted by an implementation (e.g., DSA with SHA-1, but not
-   SHA-256), algorithms here are listed in pairs.
-
-   hash
-       This field indicates the hash algorithm which may be used. The
-       values indicate support for undigested data, MD5 [MD5], SHA-1,
-       SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none"
-       value is provided for future extensibility, in case of a
-       signature algorithm which does not require hashing before
-       signing.
-
-   signature
-       This field indicates the signature algorithm which may be used.
-       The values indicate anonymous signatures, RSA [PKCS1] and DSA
-       [DSS] respectively. The "anonymous" value is meaningless in this
-       context but used later in the specification. It MUST NOT appear
-       in this extension.
-
-   The semantics of this extension are somewhat complicated because the
-   cipher suite indicates permissible signature algorithms but not
-   digest algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate
-   rules.
-
-   Clients SHOULD send this extension if they support any digest
-   algorithm other than SHA-1. If this extension is not used, servers
-   SHOULD assume that the client supports only SHA-1. Note: this is a
-   change from TLS 1.1 where there are no explicit rules but as a
-   practical matter one can assume that the peer supports MD5 and SHA-1.
-
-   Servers MUST NOT send this extension.
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-       The server MUST send a certificate whenever the agreed-upon key
-       exchange method uses certificates for authentication (this
-       includes all key exchange methods defined in this document except
-       DH_anon).  This message will always immediately follow the server
-       hello message.
-
-   Meaning of this message:
-       This message conveys the server's certificate to the client. The
-       certificate MUST be appropriate for the negotiated cipher suite's
-       key exchange algorithm, and any negotiated extensions.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 43]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-   certificate_list
-
-       This is a sequence (chain) of certificates. The sender's
-       certificate MUST come first in the list. Each following
-       certificate MUST directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate that specifies the
-       root certificate authority MAY optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-   The following rules apply to the certificates sent by the server:
-
-   -  The certificate type MUST be X.509v3, unless explicitly
-      negotiated otherwise (e.g., [TLSPGP]).
-
-   -  The certificate's public key (and associated restrictions)
-      MUST be compatible with the selected key exchange
-      algorithm.
-
-      Key Exchange Alg.  Certificate Key Type
-
-      RSA                RSA public key; the certificate MUST
-      RSA_PSK            allow the key to be used for encryption
-                         (the keyEncipherment bit MUST be set
-                         if the key usage extension is present).
-                         Note: RSA_PSK is defined in [TLSPSK].
-
-      DHE_RSA            RSA public key; the certificate MUST
-      ECDHE_RSA          allow the key to be used for signing
-                         (the digitalSignature bit MUST be set
-                         if the key usage extension is present)
-                         with the signature scheme and hash
-                         algorithm that will be employed in the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 44]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-                         server key exchange message.
-
-      DHE_DSS            DSA public key; the certificate MUST
-                         allow the key to be used for signing with
-                         the hash algorithm that will be employed
-                         in the server key exchange message.
-
-      DH_DSS             Diffie-Hellman public key; the
-      DH_RSA             keyAgreement bit MUST be set if the
-                         key usage extension is present.
-
-      ECDH_ECDSA         ECDH-capable public key; the public key
-      ECDH_RSA           MUST use a curve and point format supported
-                         by the client, as described in [TLSECC].
-
-      ECDHE_ECDSA        ECDSA-capable public key; the certificate
-                         MUST allow the key to be used for signing
-                         with the hash algorithm that will be
-                         employed in the server key exchange
-                         message. The public key MUST use a curve
-                         and point format supported by the client,
-                         as described in  [TLSECC].
-
-   -  The "server_name" and "trusted_ca_keys" extensions
-      [4366bis] are used to guide certificate selection.
-
-   If the client provided a "signature_algorithms" extension, then all
-   certificates provided by the server MUST be signed by a
-   digest/signature algorithm pair that appears in that extension.  Note
-   that this implies that a certificate containing a key for one
-   signature algorithm MAY be signed using a different signature
-   algorithm (for instance, an RSA key signed with a DSA key.) This is a
-   departure from TLS 1.1, which required that the algorithms be the
-   same.  Note that this also implies that the DH_DS, DH_RSA,
-   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
-   algorithm used to sign the certificate. Fixed DH certificates MAY be
-   signed with any digest/signature algorithm pair appearing in the
-   extension.  The naming is historical.
-
-   If no "signature_algorithms" extension is present, the end-entity
-   certificate MUST be signed as follows:
-
-      Key Exchange Alg.  Signature Algorithm Used by Issuer
-
-      RSA                RSA (RSASSA-PKCS1-v1_5)
-      DHE_RSA
-      DH_RSA
-      RSA_PSK
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 45]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-      ECDH_RSA
-      ECDHE_RSA
-
-      DHE_DSS            DSA
-      DH_DSS
-
-      ECDH_ECDSA         ECDSA
-      ECDHE_ECDSA
-
-   If the server has multiple certificates, it chooses one of them based
-   on the above-mentioned criteria (in addition to other criteria, such
-   as transport layer endpoint, local configuration and preferences,
-   etc.).
-
-   Note that there are certificates that use algorithms and/or algorithm
-   combinations that cannot be currently used with TLS.  For example, a
-   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
-   SubjectPublicKeyInfo) cannot be used because TLS defines no
-   corresponding signature algorithm.
-
-   As CipherSuites that specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 46]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret) or a public key for
-       some other algorithm.
-
-   Structure of this message:
-       enum { diffie_hellman, rsa} KeyExchangeAlgorithm;
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-           };
-        } ServerParams;
-
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 47]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       hash
-           Hash(ClientHello.random + ServerHello.random + ServerParams)
-
-
-       struct {
-           select (SignatureAlgorithm) {
-             case anonymous: struct { };
-               case rsa:
-                 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                 digitally-signed struct {
-                     opaque hash[Hash.length];
-                 };
-               case dsa:
-                 SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                 digitally-signed struct {
-                     opaque hash[Hash.length];
-                 };
-               };
-           };
-       } Signature;
-
-   If the client has offered the "signature_algorithms" extension, the
-   signature algorithm and digest algorithm MUST be a pair listed in
-   that extension. Note that there is a possibility for inconsistencies
-   here. For instance, the client might offer DHE_DSS key exchange but
-   omit any DSS pairs from its "signature_algorithms" extension.  In
-   order to negotiate correctly, the server MUST check any candidate
-   cipher suites against the "signature_algorithms" extension before
-   selecting them. This is somewhat inelegant but is a compromise
-   designed to minimize changes to the original cipher suite design.
-
-   If no "signature_algorithms" extension is present, the server MUST
-   use SHA-1 as the hash algorithm.
-
-   In addition, the digest and signature algorithms MUST be compatible
-   with the key in the client's end-entity certificate.  RSA keys MAY be
-   used with any permitted digest algorithm.
-
-   Because DSA signatures do not contain any secure indication of digest
-   algorithm, it must be unambiguous which digest algorithm is to be
-   used with any key.  DSA keys specified with Object Identifier
-   1 2 840 10040 4 1 MUST only be used with SHA-1.  Future revisions of
-   [PKIX] MAY define new object identifiers for DSA with other digest
-   algorithms.
-
-   The hash algorithm is denoted Hash below. Hash.length is the length
-   of the output of that algorithm.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 48]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   As additional CipherSuites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-7.4.4. Certificate Request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-           rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-           fortezza_dms_RESERVED(20), (255)
-       } ClientCertificateType;
-
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           SignatureAndHashAlgorithm
-             supported_signature_algorithms<2^16-1>;
-           DistinguishedName certificate_authorities<0..2^16-1>;
-       } CertificateRequest;
-
-
-   certificate_types
-       A list of the types of certificate types which the client may
-       offer.
-          rsa_sign        a certificate containing an RSA key
-          dss_sign        a certificate containing a DSS key
-          rsa_fixed_dh    a certificate containing a static DH key.
-          dss_fixed_dh    a certificate containing a static DH key
-
-   supported_signature_algorithms
-       A list of the digest/signature algorithm pairs that the server is
-       able to verify, listed in descending order of preference.
-
-   certificate_authorities
-       A list of the distinguished names [X501] of acceptable
-       certificate_authorities, represented in DER-encoded format. These
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 49]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       distinguished names may specify a desired distinguished name for
-       a root CA or for a subordinate CA; thus, this message can be used
-       both to describe known roots and a desired authorization space.
-       If the certificate_authorities list is empty then the client MAY
-       send any certificate of the appropriate ClientCertificateType,
-       unless there is some external arrangement to the contrary.
-
-   The interaction of the certificate_types and
-   supported_signature_algorithms fields is somewhat complicated.
-   certificate_types has been present in TLS since SSLv3, but was
-   somewhat underspecified. Much of its functionality is superseded by
-   supported_signature_algorithms. The following rules apply:
-
-     -  Any certificates provided by the client MUST be signed using
-       a digest/signature algorithm pair found in
-       supported_signature_types.
-
-     - The end-entity certificate provided by the client MUST contain a
-       key which is compatible with certificate_types. If the key is a
-       signature key, it MUST be usable with some digest/signature
-       algorithm pair in supported_signature_types.
-
-     - For historical reasons, the names of some client certificate
-       types include the algorithm used to sign the certificate.  For
-       example, in earlier versions of TLS, rsa_fixed_dh meant a
-       certificate signed with RSA and containing a static DH key.  In
-       TLS 1.2, this functionality has been obsoleted by the
-       signature_types field, and the certificate type no longer
-       restricts the algorithm used to sign the certificate.  For
-       example, if the server sends dss_fixed_dh certificate type and
-       {dss_sha1, rsa_sha1} signature types, the client MAY to reply
-       with a certificate containing a static DH key, signed with RSA-
-       SHA1.
-
-   New ClientCertificateType values are assigned by IANA as described in
-   Section 12.
-
- Note: Values listed as RESERVED may not be used. They were used in
-   SSLv3.
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client authentication.
-
-
-7.4.5 Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 50]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       the end of the server hello and associated messages. After
-       sending this message, the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message, the client SHOULD
-       verify that the server provided a valid certificate, if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-7.4.6. Client Certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client SHOULD send a certificate message
-       containing no certificates. That is, the certificate_list
-       structure has a length of zero. If client authentication is
-       required by the server for the handshake to continue, it may
-       respond with a fatal handshake failure alert. Client certificates
-       are sent using the Certificate structure defined in Section
-       7.4.2.
-
-   Meaning of this message:
-       This message conveys the client's certificate to the server; the
-       server will use it when verifying the certificate verify message
-       (when the client authentication is based on signing), or
-       calculate the premaster secret (for non-ephemeral Diffie-
-       Hellman).  The certificate MUST be appropriate for the negotiated
-       cipher suite's key exchange algorithm, and any negotiated
-       extensions.
-
-       In particular:
-
-       -  The certificate type MUST be X.509v3, unless explicitly
-          negotiated otherwise (e.g. [TLSPGP]).
-
-       -  The certificate's public key (and associated restrictions)
-          has to be compatible with the certificate  types listed in
-          CertificateRequest:
-
-          Client Cert. Type   Certificate Key Type
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 51]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-          rsa_sign            RSA public key; the certificate MUST allow
-                              the key to be used for signing with the
-                              signature scheme and hash algorithm that
-                              will be employed in the certificate verify
-                              message.
-
-          dss_sign            DSA public key; the certificate MUST allow
-                              the key to be used for signing with the
-                              hash algorithm that will be employed in
-                              the certificate verify message.
-
-          ecdsa_sign          ECDSA-capable public key; the certificate
-                              MUST allow the key to be used for signing
-                              with the hash algorithm that will be
-                              employed in the certificate verify
-                              message; the public key MUST use a
-                              curve and point format supported by the
-                              server.
-
-          rsa_fixed_dh        Diffie-Hellman public key; MUST use
-          dss_fixed_dh        the same parameters as server's key.
-
-          rsa_fixed_ecdh      ECDH-capable public key; MUST use
-          ecdsa_fixed_ecdh    the same curve as server's key, and
-                              MUST use a point format supported by
-
-       -  If the certificate_authorities list in the certificate
-          request message was non-empty, the certificate SHOULD be
-          issued by one of the listed CAs.
-
-       -  The certificates MUST be signed using an acceptable digest/
-          signature algorithm pair, as described in Section 7.4.4. Note
-          that this relaxes the constraints on certificate signing
-          algorithms found in prior versions of TLS.
-
-   Note that as with the server certificate, there are certificates that
-   use algorithms/algorithm combinations that cannot be currently used
-   with TLS.
-
-7.4.7. Client Key Exchange Message
-
-   When this message will be sent:
-   This message is always sent by the client. It MUST immediately follow
-   the client certificate message, if it is sent. Otherwise it MUST be
-   the first message sent by the client after it receives the server
-   hello done message.
-
-   Meaning of this message:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 52]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   With this message, the premaster secret is set, either though direct
-   transmission of the RSA-encrypted secret, or by the transmission of
-   Diffie-Hellman parameters that will allow each side to agree upon the
-   same premaster secret. When the key exchange method is DH_RSA or
-   DH_DSS, client certification has been requested, and the client was
-   able to respond with a certificate that contained a Diffie-Hellman
-   public key whose parameters (group and generator) matched those
-   specified by the server in its certificate, this message MUST NOT
-   contain any data.
-
-   Structure of this message:
-   The choice of messages depends on which key exchange method has been
-   selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition.
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa: EncryptedPreMasterSecret;
-           case diffie_hellman: ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-   If RSA is being used for key agreement and authentication, the client
-   generates a 48-byte premaster secret, encrypts it using the public
-   key from the server's certificate and sends the result in an
-   encrypted premaster secret message. This structure is a variant of
-   the client key exchange message and is not a message in itself.
-
-   Structure of this message:
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   } PreMasterSecret;
-
-   client_version
-
-       The latest (newest) version supported by the client. This is
-       used to detect version roll-back attacks.
-
-   random
-       46 securely-generated random bytes.
-
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 53]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   pre_master_secret
-
-       This random value is generated by the client and is used to
-       generate the master secret, as specified in Section 8.1.
-
-   Note: The version number in the PreMasterSecret is the version
-       offered by the client in the ClientHello.client_version, not the
-       version negotiated for the connection.  This feature is designed
-       to prevent rollback attacks.  Unfortunately, some old
-       implementations use the negotiated version instead and therefore
-       checking the version number may lead to failure to interoperate
-       with such incorrect client implementations.
-
-       Client implementations MUST always send the correct version
-       number in PreMasterSecret. If ClientHello.client_version is TLS
-       1.1 or higher, server implementations MUST check the version
-       number as described in the note below. If the version number is
-       earlier than 1.0, server implementations SHOULD check the version
-       number, but MAY have a configuration option to disable the check.
-       Note that if the check fails, the PreMasterSecret SHOULD be
-       randomized as described below.
-
-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
-   [KPR03] can be used to attack a TLS server that reveals whether a
-   particular message, when decrypted, is properly PKCS#1 formatted,
-   contains a valid PreMasterSecret structure, or has the correct
-   version number.
-
-   The best way to avoid these vulnerabilities is to treat incorrectly
-   formatted messages in a manner indistinguishable from correctly
-   formatted RSA blocks. In other words:
-
-        1. Generate a string R of 46 random bytes
-
-        2. Decrypt the message M
-
-        3. If the PKCS#1 padding is not correct, or the length of
-           message M is not exactly 48 bytes:
-              premaster secret = ClientHello.client_version || R
-           else If ClientHello.client_version <= TLS 1.0, and
-           version number check is explicitly disabled:
-              premaster secret = M
-           else:
-              premaster secret = ClientHello.client_version || M[2..47]
-
-   In any case, a TLS server MUST NOT generate an alert if processing an
-   RSA-encrypted premaster secret message fails, or the version number
-   is not as expected. Instead, it MUST continue the handshake with a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 54]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   randomly generated premaster secret.  It may be useful to log the
-   real cause of failure for troubleshooting purposes; however, care
-   must be taken to avoid leaking the information to an attacker
-   (though, e.g., timing, log files, or other channels.)
-
-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
-   against the Bleichenbacher attack. However, for maximal compatibility
-   with earlier versions of TLS, this specification uses the RSAES-
-   PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
-   to exist provided that the above recommendations are followed.
-
- Implementation Note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes. These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined. The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the the length bytes, encoding the RSA encrypted data
-   directly in the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes. The resulting
-   PDU is incompatible with many SSLv3 implementations. Implementors
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding. Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-   behavior dependent on the protocol version.
-
- Implementation Note: It is now known that remote timing-based attacks
-   on TLS are possible, at least when the client and server are on the
-   same LAN. Accordingly, implementations that use static RSA keys MUST
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
-
-7.4.7.2. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, and not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 55]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       implicit
-           If the client certificate already contains a suitable Diffie-
-           Hellman key, then Yc is implicit and does not need to be sent
-           again. In this case, the client key exchange message will be
-           sent, but it MUST be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-       The Signature type is defined in 7.4.3.
-
-       The hash algorithm is denoted Hash below.
-
-       CertificateVerify.signature.hash = Hash(handshake_messages);
-
-       The digest and signature algorithms MUST be one of those present
-       in the supported_signature_algorithms field of the
-       CertificateRequest message. In addition, the digest and signature
-       algorithms MUST be compatible with the key in the client's end-
-       entity certificate.  RSA keys MAY be used with any permitted
-       digest algorithm.
-
-       Because DSA signatures do not contain any secure indication of
-       digest algorithm, it must be unambiguous which digest algorithm
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 56]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       is to be used with any key.  DSA keys specified with Object
-       Identifier 1 2 840 10040 4 1 MUST only be used with SHA-1.
-       Future revisions of [PKIX] MAY define new object identifiers for
-       DSA with other digest algorithms.
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages MUST verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[SecurityParameters.verify_data_length];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, Hash(handshake_messages))
-           [0..SecurityParameters.verify_data_length-1];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-           Hash denotes the negotiated hash used for the PRF. If a new
-           PRF is defined, then this hash MUST be specified.
-
-           In previous versions of TLS, the verify_data was always 12
-           octets long. In the current version of TLS, it depends on the
-           cipher suite. Any cipher suite which does not explicitly
-           specify SecurityParameters.verify_data_length has a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 57]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-           SecurityParameters.verify_data_length equal to 12. This
-           includes all existing cipher suites.  Note that this
-           representation has the same encoding as with previous
-           versions. Future cipher suites MAY specify other lengths but
-           such length MUST be at least 12 bytes.
-
-       handshake_messages
-           All of the data from all messages in this handshake (not
-           including any HelloRequest messages) up to but not including
-           this message. This is only data visible at the handshake
-           layer and does not include record layer headers.  This is the
-           concatenation of all the Handshake structures as defined in
-           7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
- Note: Change cipher spec messages, alerts, and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 58]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
- Note: Diffie-Hellman parameters are specified by the server and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_AES_128_CBC_SHA.
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-12. IANA Considerations
-
-   This document uses several registries that were originally created in
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 59]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   [TLS1.1]. IANA is requested to update (has updated) these to
-   reference this document. The registries and their allocation policies
-   (unchanged from [TLS1.1]) are listed below.
-
-   -  TLS ClientCertificateType Identifiers Registry: Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434]. Values in the range 64-223
-      (decimal) inclusive are assigned Specification Required
-      [RFC2434]. Values from 224-255 (decimal) inclusive are
-      reserved for Private Use [RFC2434].
-
-   -  TLS Cipher Suite Registry: Future values with the first byte
-      in the range 0-191 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values with the first byte in
-      the range 192-254 (decimal) are assigned via Specification
-      Required [RFC2434]. Values with the first byte 255 (decimal)
-      are reserved for Private Use [RFC2434].
-
-   -  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   -  TLS Alert Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   -  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA is requested to update (has updated) it to reference this
-   document.  The registry and its allocation policy (unchanged from
-   [RFC4366]) is listed below:.
-
-   -  TLS ExtensionType Registry: Future values are allocated
-      via IETF Consensus [RFC2434]
-
-   In addition, this document defines one new registry to be maintained
-   by IANA:
-
-   -  TLS SignatureAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.
-      Future values in the range 0-63 (decimal) inclusive are
-      assigned via Standards Action [RFC2434].  Values in the
-      range 64-223 (decimal) inclusive are assigned via
-      Specification Required [RFC2434].  Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   -  TLS HashAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 60]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-      Future values in the range 0-63 (decimal) inclusive are
-      assigned via Standards Action [RFC2434].  Values in the
-      range 64-223 (decimal) inclusive are assigned via
-      Specification Required [RFC2434].  Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   This document defines one new TLS extension, cert_hash_type, which is
-   to be (has been) allocated value TBD-BY-IANA in the TLS ExtensionType
-   registry.
-
-   This document also uses the TLS Compression Method Identifiers
-   Registry, defined in [RFC3749].  IANA is requested to allocate value
-   0 for the "null" compression method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 61]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-Appendix A. Protocol Constant Values
-
-   This section describes protocol types and constants.
-
-A.1. Record Layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (SecurityParameters.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-            case aead: GenericAEADCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[SecurityParameters.mac_length];
-    } GenericStreamCipher;
-
-    struct {
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 62]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-        opaque IV[SecurityParameters.record_iv_length];
-        block-ciphered struct {
-            opaque content[TLSCompressed.length];
-            opaque MAC[SecurityParameters.mac_length];
-            uint8 padding[GenericBlockCipher.padding_length];
-            uint8 padding_length;
-        };
-    } GenericBlockCipher;
-
-    aead-ciphered struct {
-        opaque IV[SecurityParameters.record_iv_length];
-        opaque aead_output[AEADEncrypted.length];
-    } GenericAEADCipher;
-
-A.2. Change Cipher Specs Message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed_RESERVED(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            no_certificate_RESERVED(41),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction_RESERVED(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 63]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-            no_renegotiation(100),
-            unsupported_extension(110),           /* new */
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 64]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-A.4. Handshake Protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20)
-     (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello Messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 65]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-        CompressionMethod compression_methods<1..2^8-1>;
-        select (extensions_present) {
-            case false:
-                struct {};
-            case true:
-                Extension extensions<0..2^16-1>;
-        };
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-        select (extensions_present) {
-            case false:
-                struct {};
-            case true:
-                Extension extensions<0..2^16-1>;
-        };
-    } ServerHello;
-
-    struct {
-        ExtensionType extension_type;
-        opaque extension_data<0..2^16-1>;
-    } Extension;
-
-    enum {
-        signature_hash_algorithms(TBD-BY-IANA), (65535)
-    } ExtensionType;
-
-    enum{
-        none(0), md5(1), sha1(2), sha256(3), sha384(4),
-        sha512(5), (255)
-    } HashAlgorithm;
-
-    enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
-
-    struct {
-          HashAlgorithm hash;
-       SignatureAlgorithm signature;
-    } SignatureAndHashAlgorithm;
-
-    SignatureAndHashAlgorithm
-      supported_signature_algorithms<2..2^16-1>;
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 66]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<0..2^24-1>;
-    } Certificate;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque dh_p<1..2^16-1>;
-        opaque dh_g<1..2^16-1>;
-        opaque dh_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-        }
-    } ServerKeyExchange;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-        };
-    } ServerParams;
-
-    struct {
-        select (SignatureAlgorithm) {
-          case anonymous: struct { };
-            case rsa:
-                SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-            case dsa:
-                SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-            };
-        };
-    } Signature;
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 67]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-        fortezza_dms_RESERVED(20),
-     (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<0..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: ClientDiffieHellmanPublic;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 68]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-    struct {
-        opaque verify_data[SecurityParameters.verify_data_length];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.2.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-    CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA           = { 0x00, 0x2F };
-    CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA           = { 0x00, 0x35 };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 69]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-    CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA        = { 0x00, 0x30 };
-    CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA        = { 0x00, 0x31 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA       = { 0x00, 0x32 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA       = { 0x00, 0x33 };
-    CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA        = { 0x00, 0x36 };
-    CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA        = { 0x00, 0x37 };
-    CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA       = { 0x00, 0x38 };
-    CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA       = { 0x00, 0x39 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks.  Using
-   this mode therefore is of limited use: These ciphersuites MUST NOT be
-   used by TLS 1.2 implementations unless the application layer has
-   specifically requested to allow anonymous key exchange.  (Anonymous
-   key exchange may sometimes be acceptable, for example, to support
-   opportunistic encryption when no set-up for authentication is in
-   place, or when TLS is used as part of more complex security protocols
-   that have other means to ensure authentication.)
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00, 0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00, 0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00, 0x1B };
-    CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA       = { 0x00, 0x34 };
-    CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA       = { 0x00, 0x3A };
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.2 implementations MUST NOT negotiate these
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 70]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   cipher suites in TLS 1.2 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.2 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
- New cipher suite values are assigned by IANA as described in Section
-   12.
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block, aead } CipherType;
-
-       enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
-         hmac_sha512} MACAlgorithm;
-
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 71]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 enc_key_length;
-           uint8 block_length;
-        uint8 fixed_iv_length;
-           uint8 record_iv_length;
-           MACAlgorithm mac_algorithm;
-           uint8 mac_length;
-           uint8 mac_key_length;
-           uint8 verify_data_length;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 72]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-       AES is a widely used symmetric encryption algorithm.  AES is a
-       block cipher with a 128, 192, or 256 bit keys and a 16 byte block
-       size. [AES] TLS currently only supports the 128 and 256 bit key
-       sizes.
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-       A symmetric encryption algorithm that simultaneously provides
-       confidentiality and message integrity.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 73]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer-to-peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard", published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 74]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest, described in [RC2].
-
-   RC4
-       A stream cipher invented by Ron Rivest. A compatible cipher is
-       described in [SCH].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 75]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters that can be shared among
-       multiple connections. Sessions are used to avoid the expensive
-       negotiation of new security parameters for each connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 76]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-Appendix C. CipherSuite Definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_CBC_SHA            RSA            AES_256_CBC  SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DH_anon         Anonymous DH, no signatures        None
-      DH_DSS          DH with DSS-based certificates     None
-      DH_RSA          DH with RSA-based certificates     None
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 77]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC4_128      Stream  16         16         0     N/A
-    DES_CBC      Block    8          8         8      8
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm.
-
-   IV Size
-       The amount of data needed to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers (this is equal to
-       SecurityParameters.record_iv_length).
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 78]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably SHA-1, are acceptable,
-   but cannot provide more security than the size of the random number
-   generator state.
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-D.4 Implementation Pitfalls
-
-   Implementation experience has shown that certain parts of earlier TLS
-   specifications are not easy to understand, and have been a source of
-   interoperability and security problems. Many of these areas have been
-   clarified in this document, but this appendix contains a short list
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 79]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   of the most important things that require special attention from
-   implementors.
-
-   TLS protocol issues:
-
-   -  Do you correctly handle handshake messages that are fragmented
-      to multiple TLS records (see Section 6.2.1)? Including corner
-      cases like a ClientHello that is split to several small
-      fragments?
-
-   -  Do you ignore the TLS record layer version number in all TLS
-      records before ServerHello (see Appendix E.1)?
-
-   -  Do you handle TLS extensions in ClientHello correctly,
-      including omitting the extensions field completely?
-
-   -  Do you support renegotiation, both client and server initiated?
-      While renegotiation this is an optional feature, supporting
-      it is highly recommended.
-
-   -  When the server has requested a client certificate, but no
-      suitable certificate is available, do you correctly send
-      an empty Certificate message, instead of omitting the whole
-      message (see Section 7.4.6)?
-
-   Cryptographic details:
-
-   -  In RSA-encrypted Premaster Secret,  do you correctly send and
-      verify the version number? When an error is encountered, do
-      you continue the handshake to avoid the Bleichenbacher
-      attack (see Section 7.4.7.1)?
-
-   -  What countermeasures do you use to prevent timing attacks against
-      RSA decryption and signing operations (see Section 7.4.7.1)?
-
-   -  When verifying RSA signatures, do you accept both NULL and
-      missing parameters (see Section 4.7)? Do you verify that the
-      RSA padding doesn't have additional data after the hash value?
-      [FI06]
-
-   -  When using Diffie-Hellman key exchange, do you correctly strip
-      leading zero bytes from the negotiated key (see Section 8.1.2)?
-
-   -  Does your TLS client check that the Diffie-Hellman parameters
-      sent by the server are acceptable (see Section F.1.1.3)?
-
-   -  How do you generate unpredictable IVs for CBC mode ciphers
-      (see Section 6.2.3.2)?
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 80]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   -  How do you address CBC mode timing attacks (Section 6.2.3.2)?
-
-   -  Do you use a strong and, most importantly, properly seeded
-      random number generator (see Appendix D.1) for generating the
-      premaster secret (for RSA key exchange), Diffie-Hellman private
-      values, the DSA "k" parameter, and other security-critical
-      values?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 81]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-Appendix E. Backward Compatibility
-
-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client support the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version. If the server does not support this
-   version, it will respond with ServerHello containing an older version
-   number. If the client agrees to use this version, the negotiation
-   will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing version number
-   smaller than the highest supported version. If the server wishes to
-   negotiate with old clients, it will proceed as appropriate for the
-   highest version supported by the server that is not greater than
-   ClientHello.client_version. For example, if the server supports TLS
-   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing
-   to use) only versions greater than client_version, it MUST send a
-   "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
- Note: some server implementations are known to implement version
-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 82]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   that simply close the connection when the client offers a version
-   newer than TLS 1.0. Also, it is known that some servers will refuse
-   connection if any TLS extensions are included in ClientHello.
-   Interoperability with such buggy servers is a complex topic beyond
-   the scope of this document, and may require multiple connection
-   attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed). Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number. Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version. No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2 Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
-   contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS ciphersuites in the
-   CIPHER-SPECS-DATA field as described below.
-
-Warning: The ability to send version 2.0 CLIENT-HELLO messages will be
-   phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-   However, even TLS servers that do not support SSL 2.0 SHOULD accept
-   version 2.0 CLIENT-HELLO messages. The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions. Note that this message MUST be sent directly on the wire,
-   not wrapped as a TLS record. For the purposes of calculating Finished
-   and CertificateVerify, the msg_length field is not considered to be a
-   part of the handshake message.
-
-       uint8 V2CipherSpec[3];
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 83]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-       struct {
-           uint16 msg_length;
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           opaque challenge[V2ClientHello.challenge_length;
-       } V2ClientHello;
-
-   msg_length
-       The highest bit MUST be 1; the remaining bits contain the
-       length of the following data in bytes.
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-       version 2 client hello message. The value MUST be one (1).
-
-   version
-       Equal to ClientHello.client_version.
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and MUST be a multiple of the V2CipherSpec length
-       (3).
-
-   session_id_length
-       This field MUST have a value of zero for a client that claims to
-       support TLS 1.2.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. Historically, permissible values are between
-       16 and 32 bytes inclusive. When using the SSLv2 backward
-       compatible handshake the client SHOULD use a 32 byte challenge.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. In addition to the 2.0 cipher specs defined in [SSL2],
-       this includes the TLS cipher suites normally sent in
-       ClientHello.cipher_suites, each cipher suite prefixed by a zero
-       byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
-       {0x00,0x00,0x0A}.
-
-   session_id
-       This field MUST be empty.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 84]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   challenge
-       Corresponds to ClientHello.random. If the challenge length is
-       less than 32, the TLS server will pad the data with leading
-       (note: not trailing) zero bytes to make it 32 bytes long.
-
- Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.3. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   MUST use special PKCS#1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
-   the right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).
-
-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
-   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
-   padding bytes are 0x03. If they are not, the server SHOULD generate a
-   random value for SECRET-KEY-DATA, and continue the handshake (which
-   will eventually fail since the keys will not match).  Note that
-   reporting the error situation to the client could make the server
-   vulnerable to attacks described in [BLEI].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 85]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.9 and 6.3). By sending a correct finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using Diffie-Hellman
-   for key exchange. The server's public parameters are contained in the
-   server key exchange message and the client's are sent in the client
-   key exchange message. Eavesdroppers who do not know the private
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 86]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   values should not be able to find the Diffie-Hellman result (i.e. the
-   pre_master_secret).
-
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key. TLS
-   users desiring Perfect Forward Secrecy should use DHE cipher suites.
-   The damage done by exposure of a private key can be limited by
-   changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from all preceding handshake messages. These
-   handshake messages include the server certificate, which binds the
-   signature to the server, and ServerHello.random, which binds the
-   signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 87]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly, therefore the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-   Because TLS allows the server to provide arbitrary DH groups, the
-   client should verify that the DH group is of suitable size as defined
-   by local policy. The client SHOULD also verify that the DH public
-   exponent appears to be of adequate size. [KEYSIZ] provides a useful
-   guide to the strength of various group sizes.  The server MAY choose
-   to assist the client by providing a known group, such as those
-   defined in [IKEALG] or [MODP]. These can be verified by simple
-   comparison.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Altering
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 88]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   the padding of the least significant 8 bytes of the PKCS padding does
-   not impact security for the size of the signed hashes and RSA key
-   lengths used in the protocol, since this is essentially equivalent to
-   increasing the input block size by 8 bytes.
-
-F.1.3. Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations.
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 89]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64 bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent, so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-   [CBCATT] describes a chosen plaintext attack on TLS that depends on
-   knowing the IV for a record. Previous versions of TLS [TLS1.0] used
-   the CBC residue of the previous record as the IV and therefore
-   enabled this attack. This version uses an explicit IV in order to
-   protect against this attack.
-
-F.4. Security of Composite Cipher Modes
-
-   TLS secures transmitted application data via the use of symmetric
-   encryption and authentication functions defined in the negotiated
-   ciphersuite.  The objective is to protect both the integrity and
-   confidentiality of the transmitted data from malicious actions by
-   active attackers in the network.  It turns out that the order in
-   which encryption and authentication functions are applied to the data
-   plays an important role for achieving this goal [ENCAUTH].
-
-   The most robust method, called encrypt-then-authenticate, first
-   applies encryption to the data and then applies a MAC to the
-   ciphertext.  This method ensures that the integrity and
-   confidentiality goals are obtained with ANY pair of encryption and
-   MAC functions, provided that the former is secure against chosen
-   plaintext attacks and that the MAC is secure against chosen-message
-   attacks.  TLS uses another method, called authenticate-then-encrypt,
-   in which first a MAC is computed on the plaintext and then the
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 90]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   concatenation of plaintext and MAC is encrypted.  This method has
-   been proven secure for CERTAIN combinations of encryption functions
-   and MAC functions, but it is not guaranteed to be secure in general.
-   In particular, it has been shown that there exist perfectly secure
-   encryption functions (secure even in the information-theoretic sense)
-   that combined with any secure MAC function, fail to provide the
-   confidentiality goal against an active attack.  Therefore, new
-   ciphersuites and operation modes adopted into TLS need to be analyzed
-   under the authenticate-then-encrypt method to verify that they
-   achieve the stated integrity and confidentiality goals.
-
-   Currently, the security of the authenticate-then-encrypt method has
-   been proven for some important cases.  One is the case of stream
-   ciphers in which a computationally unpredictable pad of the length of
-   the message, plus the length of the MAC tag, is produced using a
-   pseudo-random generator and this pad is xor-ed with the concatenation
-   of plaintext and MAC tag.  The other is the case of CBC mode using a
-   secure block cipher.  In this case, security can be shown if one
-   applies one CBC encryption pass to the concatenation of plaintext and
-   MAC and uses a new, independent, and unpredictable IV for each new
-   pair of plaintext and MAC.  In versions of TLS prior to 1.1, CBC mode
-   was used properly EXCEPT that it used a predictable IV in the form of
-   the last block of the previous ciphertext.  This made TLS open to
-   chosen plaintext attacks.  This version of the protocol is immune to
-   those attacks.  For exact details in the encryption modes proven
-   secure, see [ENCAUTH].
-
-F.5 Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption. However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections. In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH] or ESP [ESP].
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 91]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-F.6 Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys and
-   anonymous servers should be used with great caution. Implementations
-   and users must be careful when deciding which certificates and
-   certificate authorities are acceptable; a dishonest certificate
-   authority can do tremendous damage.
-
-Changes in This Version
-
-   [RFC Editor: Please delete this]
-
-   - Redid the hash function advertisements for CertificateRequest
-     and the client-side extension. They are now pairs of
-     hash/signature and the semantics are clearly defined for
-     all uses of signatures (hopefully). [Issue 41]
-
-   - Clarified the DH group checking per list discussion [Issue 35]
-
-   - Added a note about DSS vs. DSA [Issue 58]
-
-   - Editorial issues [Issue 59]
-
-   - Cleaned up certificate text in 7.4.2 and 7.4.6 [Issue 57]
-
-Normative References
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   National Institute of Standards and Technology,
-            "Recommendation for the Triple Data Encryption Algorithm
-            (TDEA) Block Cipher", NIST Special Publication 800-67, May
-            2004.
-
-   [DES]    National Institute of Standards and Technology, "Data
-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 92]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication", RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
-            Public Key Infrastructure Certificate and Certificate
-            Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, March 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2nd ed.", Published by John Wiley &
-            Sons, Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,
-            October 1998.
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "Authenticated Encryption", February 2007,
-            draft-mcgrew-auth-enc-02.txt.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            4302, December 2005.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 93]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
-            "Password Interception in a SSL/TLS Channel", Advances in
-            Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
-
-   [CCM]     "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/800-38C/
-            SP800-38C.pdf
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]     Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 4303, December 2005.
-
-   [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on
-            implementation error", ietf-openpgp@imc.org mailing list, 27
-            August 2006, http://www.imc.org/ietf-openpgp/mail-
-            archive/msg14307.html.
-
-   [GCM]     "NIST Special Publication 800-38D DRAFT (June, 2007):
-            Recommendation for Block Cipher Modes of Operation:
-            Galois/Counter Mode (GCM) and GMAC"
-
-   [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
-            Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
-            2005.
-
-   [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
-            Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
-            April 2004.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [MODP]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-            Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
-            3526, May 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 94]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-            "Randomness Requirements for Security", BCP 106, RFC 4086,
-            June 2005.
-
-   [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
-            Compression Methods", RFC 3749, May 2004.
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            4366, April 2006.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
-            Protocol", Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
-            Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
-            Suites for Transport Layer Security (TLS)", RFC 4492, May
-            2006.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 95]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   [TLSEXT] Eastlake, D.E.,  "Transport Layer Security (TLS) Extensions:
-            Extension Definitions", July 2007, draft-ietf-tls-
-            rfc4366-bis-00.txt.
-
-   [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
-            authentication", draft-ietf-tls-openpgp-keys-11, July 2006.
-
-   [TLSPSK]  Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites
-            for Transport Layer Security (TLS)", RFC 4279, December
-            2005.
-
-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
-            1.1", RFC 4346, April, 2006.
-
-   [X501] ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [XDR]   Eisler, M., "External Data Representation Standard", RFC
-            4506, May 2006.
-
-
-Credits
-
-   Working Group Chairs
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 96]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Alfred Hoenes
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 97]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-       <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 98]draft-ietf-tls-rfc4346-bis-06.txt  TLS                      October 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 99]
\ No newline at end of file
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-07.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-07.txt
deleted file mode 100644
index ff8164bc5e..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-07.txt
+++ /dev/null
@@ -1,5544 +0,0 @@
-
-
-INTERNET-DRAFT                                                Tim Dierks
-Obsoletes (if approved): RFC 3268, 4346, 4366                Independent
-Intended status:  Proposed Standard                        Eric Rescorla
-                                                 Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-07.txt>     November 2007 (Expires May 2008)
-
-
-              The Transport Layer Security (TLS) Protocol
-                              Version 1.2
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2007).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 1]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Table of Contents
-
-   1.        Introduction                                             4
-   1.1.      Requirements Terminology                                 5
-   1.2.      Major Differences from TLS 1.1                           5
-   2.        Goals                                                    6
-   3.        Goals of This Document                                   6
-   4.        Presentation Language                                    7
-   4.1.      Basic Block Size                                         7
-   4.2.      Miscellaneous                                            7
-   4.3.      Vectors                                                  8
-   4.4.      Numbers                                                  9
-   4.5.      Enumerateds                                              9
-   4.6.      Constructed Types                                        10
-   4.6.1.    Variants                                                 10
-   4.7.      Cryptographic Attributes                                 11
-   4.8.      Constants                                                13
-   5.        HMAC and the Pseudorandom Function                       13
-   6.        The TLS Record Protocol                                  14
-   6.1.      Connection States                                        15
-   6.2.      Record layer                                             18
-   6.2.1.    Fragmentation                                            18
-   6.2.2.    Record Compression and Decompression                     19
-   6.2.3.    Record Payload Protection                                20
-   6.2.3.1.  Null or Standard Stream Cipher                           21
-   6.2.3.2.  CBC Block Cipher                                         21
-   6.2.3.3.  AEAD ciphers                                             23
-   6.3.      Key Calculation                                          24
-   7.        The TLS Handshaking Protocols                            25
-   7.1.      Change Cipher Spec Protocol                              26
-   7.2.      Alert Protocol                                           27
-   7.2.1.    Closure Alerts                                           28
-   7.2.2.    Error Alerts                                             29
-   7.3.      Handshake Protocol Overview                              32
-   7.4.      Handshake Protocol                                       35
-   7.4.1.    Hello Messages                                           36
-   7.4.1.1.  Hello Request                                            36
-   7.4.1.2.  Client Hello                                             37
-   7.4.1.3.  Server Hello                                             40
-   7.4.1.4   Hello Extensions                                         42
-   7.4.1.4.1 Signature Algorithms                                     43
-   7.4.2.    Server Certificate                                       44
-   7.4.3.    Server Key Exchange Message                              47
-   7.4.4.    Certificate Request                                      49
-   7.4.5     Server hello done                                        51
-   7.4.6.    Client Certificate                                       52
-   7.4.7.    Client Key Exchange Message                              53
-   7.4.7.1.  RSA Encrypted Premaster Secret Message                   54
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 2]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   7.4.7.2.  Client Diffie-Hellman Public Value                       56
-   7.4.8.    Certificate verify                                       57
-   7.4.9.    Finished                                                 58
-   8.        Cryptographic Computations                               59
-   8.1.      Computing the Master Secret                              60
-   8.1.1.    RSA                                                      60
-   8.1.2.    Diffie-Hellman                                           60
-   9.        Mandatory Cipher Suites                                  60
-   10.       Application Data Protocol                                60
-   11.       Security Considerations                                  60
-   12.       IANA Considerations                                      61
-   A.        Protocol Constant Values                                 63
-   A.1.      Record Layer                                             63
-   A.2.      Change Cipher Specs Message                              64
-   A.3.      Alert Messages                                           64
-   A.4.      Handshake Protocol                                       65
-   A.4.1.    Hello Messages                                           65
-   A.4.2.    Server Authentication and Key Exchange Messages          67
-   A.4.3.    Client Authentication and Key Exchange Messages          68
-   A.4.4.    Handshake Finalization Message                           69
-   A.5.      The CipherSuite                                          69
-   A.6.      The Security Parameters                                  72
-   B.        Glossary                                                 73
-   C.        CipherSuite Definitions                                  77
-   D.        Implementation Notes                                     79
-   D.1       Random Number Generation and Seeding                     79
-   D.2       Certificates and Authentication                          79
-   D.3       CipherSuites                                             79
-   D.4       Implementation Pitfalls                                  79
-   E.        Backward Compatibility                                   82
-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0               82
-   E.2       Compatibility with SSL 2.0                               83
-   E.3.      Avoiding Man-in-the-Middle Version Rollback              85
-   F.        Security Analysis                                        86
-   F.1.      Handshake Protocol                                       86
-   F.1.1.    Authentication and Key Exchange                          86
-   F.1.1.1.  Anonymous Key Exchange                                   86
-   F.1.1.2.  RSA Key Exchange and Authentication                      87
-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication          87
-   F.1.2.    Version Rollback Attacks                                 88
-   F.1.3.    Detecting Attacks Against the Handshake Protocol         89
-   F.1.4.    Resuming Sessions                                        89
-   F.2.      Protecting Application Data                              89
-   F.3.      Explicit IVs                                             90
-   F.4.      Security of Composite Cipher Modes                       90
-   F.5       Denial of Service                                        91
-   F.6       Final Notes                                              91
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 3]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-   -  The connection is private. Symmetric cryptography is used for
-      data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
-      this symmetric encryption are generated uniquely for each
-      connection and are based on a secret negotiated by another
-      protocol (such as the TLS Handshake Protocol). The Record Protocol
-      can also be used without encryption.
-
-   -  The connection is reliable. Message transport includes a message
-      integrity check using a keyed MAC. Secure hash functions (e.g.,
-      SHA, MD5, etc.) are used for MAC computations. The Record Protocol
-      can operate without a MAC, but is generally only used in this mode
-      while another protocol is using the Record Protocol as a transport
-      for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-   -  The peer's identity can be authenticated using asymmetric, or
-      public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-      authentication can be made optional, but is generally required for
-      at least one of the peers.
-
-   -  The negotiation of a shared secret is secure: the negotiated
-      secret is unavailable to eavesdroppers, and for any authenticated
-      connection the secret cannot be obtained, even by an attacker who
-      can place himself in the middle of the connection.
-
-   -  The negotiation is reliable: no attacker can modify the
-      negotiation communication without being detected by the parties to
-      the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS Protocol
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 4]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-   of protocols that run on top of TLS.
-
-1.1. Requirements Terminology
-
-   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 [REQ].
-
-1.2. Major Differences from TLS 1.1
-
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-   -  The MD5/SHA-1 combination in the PRF has been replaced with cipher
-      suite specified PRFs. All cipher suites in this document use
-      P_SHA256.
-
-   -  The MD5/SHA-1 combination in the digitally-signed element has been
-      replaced with a single hash.
-
-   -  Substantial cleanup to the clients and servers ability to specify
-      which hash and signature algorithms they will accept. Note that
-      this also relaxes some of the constraints on signature and hash
-      algorithms from previous versions of TLS.
-
-   -  Addition of support for authenticated encryption with additional
-      data modes.
-
-   -  TLS Extensions definition and AES Cipher Suites were merged in
-      from external [TLSEXT] and [TLSAES].
-
-   -  Tighter checking of EncryptedPreMasterSecret version numbers.
-
-   -  Tightened up a number of requirements.
-
-   -  Verify_data length now depends on the cipher suite (default is
-      still 12).
-
-   -  Cleaned up description of Bleichenbacher/Klima attack defenses.
-
-   -  Alerts MUST now be sent in many cases.
-   -  After a certificate_request, if no certificates are available,
-      clients now MUST send an empty certificate list.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 5]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   -  TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
-      cipher suite.
-
-   -  IDEE and DES are now deprecated.
-
-   -  Support for the SSLv2 backward-compatible hello is now a MAY, not
-      a SHOULD. This will probably become a SHOULD NOT in the future.
-
-   -  Added an Implementation Pitfalls sections
-
-   -  The usual clarifications and editorial work.
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-   1. Cryptographic security: TLS should be used to establish a secure
-      connection between two parties.
-
-   2. Interoperability: Independent programmers should be able to
-      develop applications utilizing TLS that can successfully exchange
-      cryptographic parameters without knowledge of one another's code.
-
-   3. Extensibility: TLS seeks to provide a framework into which new
-      public key and bulk encryption methods can be incorporated as
-      necessary. This will also accomplish two sub-goals: preventing the
-      need to create a new protocol (and risking the introduction of
-      possible new weaknesses) and avoiding the need to implement an
-      entire new security library.
-
-   4. Relative efficiency: Cryptographic operations tend to be highly
-      CPU intensive, particularly public key operations. For this
-      reason, the TLS protocol has incorporated an optional session
-      caching scheme to reduce the number of connections that need to be
-      established from scratch. Additionally, care has been taken to
-      reduce network activity.
-
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions). This
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it. The
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 6]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e., 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-      value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-              ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 7]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-      T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-      opaque Datum[3];      /* three uninterpreted bytes */
-      Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream. The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length. A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-      T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two-byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17-byte vector of uint16 would be illegal).
-
-      opaque mandatory<300..400>;
-            /* length field is 2 bytes, cannot be empty */
-      uint16 longer<0..800>;
-            /* zero to 400 16-bit unsigned integers */
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 8]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-      uint8 uint16[2];
-      uint8 uint24[3];
-      uint8 uint32[4];
-      uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors. In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-      enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-      enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-      enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 9]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-      Color color = Color.blue;     /* overspecified, legal */
-      Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-      enum { low, medium, high } Amount;
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ...
-          Tn fn;
-      } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ....
-          Tn fn;
-          select (E) {
-              case e1: Te1;
-              case e2: Te2;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 10]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-              ....
-              case en: Ten;
-          } [[fv]];
-      } [[Tv]];
-
-   For example:
-
-      enum { apple, orange } VariantTag;
-      struct {
-          uint16 number;
-          opaque string<0..10>; /* variable length */
-      } V1;
-      struct {
-          uint32 number;
-          opaque string[10];    /* fixed length */
-      } V2;
-      struct {
-          select (VariantTag) { /* value of selector is implicit */
-              case apple: V1;   /* VariantBody, tag = apple */
-              case orange: V2;  /* VariantBody, tag = orange */
-          } variant_body;       /* optional label on variant */
-      } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, an
-
-      orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic Attributes
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 11]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
-   discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash
-   algorithms without parameters (which include SHA-1) the
-   DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
-   implementations MUST accept both without parameters and with NULL
-   parameters. Note that earlier versions of TLS used a different RSA
-   signature scheme which did not include a DigestInfo encoding.
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-      Dss-Sig-Value ::= SEQUENCE {
-          r INTEGER,
-          s INTEGER
-      }
-
-   Note: In current terminology, DSA refers to the Digital Signature
-   Algorithm and DSS refers to the NIST standard. For historical
-   reasons, this document uses DSS and DSA interchangeably
-   to refer to the DSA algorithm, as was done in SSLv3.
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and aead-ciphered
-   output is generally larger than the input in order to accomodate the
-   integrity check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the encryption
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 12]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   In the following example
-
-      stream-ciphered struct {
-          uint8 field1;
-          uint8 field2;
-          digitally-signed opaque hash[20];
-      } UserType;
-
-   the contents of hash are used as input for the signing algorithm, and
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes, would be equal to two bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   because the algorithm and key used for the signing are known prior to
-   encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-      struct {
-          uint8 f1;
-          uint8 f2;
-      } Example1;
-
-      Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-
-5. HMAC and the Pseudorandom Function
-
-   The TLS record layer uses a keyed Message Authentication Code (MAC)
-   to protect message integrity. The cipher suites defined in this
-   document use a construction known as HMAC, described in [HMAC], which
-   is based on a hash function. Other cipher suites MAY define their own
-   MAC constructions, if needed.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In this section, we define one PRF, based on HMAC. This PRF with the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 13]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   SHA-256 hash function is used for all cipher suites defined in this
-   document and in TLS documents published prior to this document when
-   TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
-   PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger
-   standard hash function.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-      P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                             HMAC_hash(secret, A(2) + seed) +
-                             HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-
-      A(0) = seed
-      A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 is being used to
-   create 64 bytes of data, it will have to be iterated 4 times (through
-   A(4)), creating 80 bytes of output data; the last 16 bytes of the
-   final iteration will then be discarded, leaving 64 bytes of output
-   data.
-
-   TLS's PRF is created by applying P_hash to the secret as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-      73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 14]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   higher-level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. New record type values are assigned
-   by IANA as described in Section 12.
-
-   Implementations MUST NOT send record types not defined in this
-   document unless negotiated by some extension.  If a TLS
-   implementation receives an unexpected record type, it MUST send an
-   unexpected_message alert.
-
-   Any protocol designed for use over TLS MUST be carefully designed to
-   deal with all possible attacks against it.  Note that because the
-   type and length of a record are not protected by encryption, care
-   SHOULD be taken to minimize the value of traffic analysis of these
-   values.
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, an encryption
-   algorithm, and a MAC algorithm. In addition, the parameters for these
-   algorithms are known: the MAC key and the bulk encryption keys for
-   the connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state that has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-      Whether this entity is considered the "client" or the "server" in
-      this connection.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 15]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   PRF algorithm
-      An algorithm used to generate keys from the master secret (see
-      Sections 5 and 6.3).
-
-   bulk encryption algorithm
-      An algorithm to be used for bulk encryption. This specification
-      includes the key size of this algorithm, whether it is a block,
-      stream, or AEAD cipher, the block size of the cipher (if
-      appropriate), and the lengths of explicit and implicit
-      initialization vectors (or nonces).
-
-   MAC algorithm
-      An algorithm to be used for message authentication. This
-      specification includes the size of the value returned by the MAC
-      algorithm.
-
-   compression algorithm
-      An algorithm to be used for data compression. This specification
-      must include all information the algorithm requires to do
-      compression.
-
-   master secret
-      A 48-byte secret shared between the two peers in the connection.
-
-   client random
-      A 32-byte value provided by the client.
-
-   server random
-      A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-      enum { server, client } ConnectionEnd;
-
-      enum { tls_prf_sha256 } PRFAlgorithm;
-
-      enum { null, rc4, 3des, aes }
-        BulkCipherAlgorithm;
-
-      enum { stream, block, aead } CipherType;
-
-      enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
-           hmac_sha512} MACAlgorithm;
-
-      /* The use of "sha" above is historical and denotes SHA-1 */
-
-      enum { null(0), (255) } CompressionMethod;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 16]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      /* The algorithms specified in CompressionMethod,
-         BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-      struct {
-          ConnectionEnd          entity;
-          PRFAlgorithm           prf_algorithm;
-          BulkCipherAlgorithm    bulk_cipher_algorithm;
-          CipherType             cipher_type;
-          uint8                  enc_key_length;
-          uint8                  block_length;
-          uint8                  fixed_iv_length;
-          uint8                  record_iv_length;
-          MACAlgorithm           mac_algorithm;
-          uint8                  mac_length;
-          uint8                  mac_key_length;
-          CompressionMethod      compression_algorithm;
-          opaque                 master_secret[48];
-          opaque                 client_random[32];
-          opaque                 server_random[32];
-      } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following six items (some of which are not required by all ciphers,
-   and are thus empty):
-
-      client write MAC key
-      server write MAC key
-      client write encryption key
-      server write encryption key
-      client write IV
-      server write IV
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-      The current state of the compression algorithm.
-
-   cipher state
-      The current state of the encryption algorithm. This will consist
-      of the scheduled key for that connection. For stream ciphers, this
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 17]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      will also contain whatever state information is necessary to allow
-      the stream to continue to encrypt or decrypt data.
-
-   MAC key
-      The MAC key for this connection, as generated above.
-
-   sequence number
-      Each connection state contains a sequence number, which is
-      maintained separately for read and write states. The sequence
-      number MUST be set to zero whenever a connection state is made the
-      active state. Sequence numbers are of type uint64 and may not
-      exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-      implementation would need to wrap a sequence number, it must
-      renegotiate instead. A sequence number is incremented after each
-      record: specifically, the first record transmitted under a
-      particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-      struct {
-          uint8 major, minor;
-      } ProtocolVersion;
-
-      enum {
-          change_cipher_spec(20), alert(21), handshake(22),
-          application_data(23), (255)
-      } ContentType;
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          opaque fragment[TLSPlaintext.length];
-      } TLSPlaintext;
-
-   type
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 18]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      The higher-level protocol used to process the enclosed fragment.
-
-   version
-      The version of the protocol being employed. This document
-      describes TLS Version 1.2, which uses the version { 3, 3 }. The
-      version value 3.3 is historical, deriving from the use of 3.1 for
-      TLS 1.0. (See Appendix A.1).  Note that a client that supports
-      multiple versions of TLS may not know what version will be
-      employed before it receives ServerHello.  See Appendix E for
-      discussion about what record layer version number should be
-      employed for ClientHello.
-
-   length
-      The length (in bytes) of the following TLSPlaintext.fragment.  The
-      length MUST NOT exceed 2^14.
-
-   fragment
-      The application data. This data is transparent and treated as an
-      independent block to be dealt with by the higher-level protocol
-      specified by the type field.
-
-   Implementations MUST NOT send zero-length fragments of Handshake,
-   Alert, or Change Cipher Spec content types. Zero-length fragments of
-   Application data MAY be sent as they are potentially useful as a
-   traffic analysis countermeasure.
-
-   Note: Data of different TLS Record layer content types MAY be
-   interleaved.  Application data is generally of lower precedence for
-   transmission than other content types.  However, records MUST be
-   delivered to the network in the same order as they are protected by
-   the record layer.  Recipients MUST receive and process interleaved
-   application layer traffic during handshakes subsequent to the first
-   one on a connection.
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 19]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      struct {
-          ContentType type;       /* same as TLSPlaintext.type */
-          ProtocolVersion version;/* same as TLSPlaintext.version */
-          uint16 length;
-          opaque fragment[TLSCompressed.length];
-      } TLSCompressed;
-
-   length
-      The length (in bytes) of the following TLSCompressed.fragment.
-      The length MUST NOT exceed 2^14 + 1024.
-
-   fragment
-      The compressed form of TLSPlaintext.fragment.
-
-   Note: A CompressionMethod.null operation is an identity operation; no
-   fields are altered.
-
-   Implementation note: Decompression functions are responsible for
-   ensuring that messages cannot cause internal buffer overflows.
-
-6.2.3. Record Payload Protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          select (SecurityParameters.cipher_type) {
-              case stream: GenericStreamCipher;
-              case block:  GenericBlockCipher;
-              case aead:   GenericAEADCipher;
-          } fragment;
-      } TLSCiphertext;
-
-   type
-      The type field is identical to TLSCompressed.type.
-
-   version
-      The version field is identical to TLSCompressed.version.
-
-   length
-      The length (in bytes) of the following TLSCiphertext.fragment.
-      The length MUST NOT exceed 2^14 + 2048.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 20]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   fragment
-      The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-      stream-ciphered struct {
-          opaque content[TLSCompressed.length];
-          opaque MAC[SecurityParameters.mac_length];
-      } GenericStreamCipher;
-
-   The MAC is generated as:
-
-      MAC(MAC_write_secret, seq_num +
-                            TLSCompressed.type +
-                            TLSCompressed.version +
-                            TLSCompressed.length +
-                            TLSCompressed.fragment);
-
-   where "+" denotes concatenation.
-
-   seq_num
-      The sequence number for this record.
-
-   MAC
-      The MAC algorithm specified by SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted,
-   and the MAC size is zero, implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   SecurityParameters.mac_length.
-
-6.2.3.2. CBC Block Cipher
-
-   For block ciphers (such as 3DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 21]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      struct {
-          opaque IV[SecurityParameters.record_iv_length];
-          block-ciphered struct {
-              opaque content[TLSCompressed.length];
-              opaque MAC[SecurityParameters.mac_length];
-              uint8 padding[GenericBlockCipher.padding_length];
-              uint8 padding_length;
-          };
-      } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-      The Initialization Vector (IV) SHOULD be chosen at random, and
-      MUST be unpredictable. Note that in versions of TLS prior to 1.1,
-      there was no IV field, and the last ciphertext block of the
-      previous record (the "CBC residue") was used as the IV. This was
-      changed to prevent the attacks described in [CBCATT]. For block
-      ciphers, the IV length is of length
-      SecurityParameters.record_iv_length which is equal to the
-      SecurityParameters.block_size.
-
-   padding
-      Padding that is added to force the length of the plaintext to be
-      an integral multiple of the block cipher's block length. The
-      padding MAY be any length up to 255 bytes, as long as it results
-      in the TLSCiphertext.length being an integral multiple of the
-      block length. Lengths longer than necessary might be desirable to
-      frustrate attacks on a protocol that are based on analysis of the
-      lengths of exchanged messages. Each uint8 in the padding data
-      vector MUST be filled with the padding length value. The receiver
-      MUST check this padding and MUST use the bad_record_mac alert to
-      indicate padding errors.
-
-   padding_length
-      The padding length MUST be such that the total size of the
-      GenericBlockCipher structure is a multiple of the cipher's block
-      length. Legal values range from zero to 255, inclusive. This
-      length specifies the length of the padding field exclusive of the
-      padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of SecurityParameters.block_length, TLSCompressed.length,
-   SecurityParameters.mac_length, and padding_length.
-
-   Example: If the block length is 8 bytes, the content length
-   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
-   then the length before padding is 82 bytes (this does not include the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 22]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   IV. Thus, the padding length modulo 8 must be equal to 6 in order to
-   make the total length an even multiple of 8 bytes (the block length).
-   The padding length can be 6, 14, 22, and so on, through 254. If the
-   padding length were the minimum necessary, 6, the padding would be 6
-   bytes, each containing the value 6.  Thus, the last 8 octets of the
-   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
-   06 06, where xx is the last octet of the MAC.
-
-   Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
-   critical that the entire plaintext of the record be known before any
-   ciphertext is transmitted. Otherwise, it is possible for the attacker
-   to mount the attack described in [CBCATT].
-
-   Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
-   timing attack on CBC padding based on the time required to compute
-   the MAC. In order to defend against this attack, implementations MUST
-   ensure that record processing time is essentially the same whether or
-   not the padding is correct.  In general, the best way to do this is
-   to compute the MAC even if the padding is incorrect, and only then
-   reject the packet. For instance, if the pad appears to be incorrect,
-   the implementation might assume a zero-length pad and then compute
-   the MAC. This leaves a small timing channel, since MAC performance
-   depends to some extent on the size of the data fragment, but it is
-   not believed to be large enough to be exploitable, due to the large
-   block size of existing MACs and the small size of the timing signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-      struct {
-         opaque nonce_explicit[SecurityParameters.record_iv_length];
-         aead-ciphered struct {
-             opaque content[TLSCompressed.length];
-         };
-      } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD]. The key is either the
-   client_write_key or the server_write_key.  No MAC key is used.
-
-   Each AEAD cipher suite MUST specify how the nonce supplied to the
-   AEAD operation is constructed, and what is the length of the
-   GenericAEADCipher.nonce_explicit part. In many cases, it is
-   appropriate to use the partially implicit nonce technique described
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 23]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
-   the explicit part. In this case, the implicit part SHOULD be derived
-   from key_block as client_write_iv and server_write_iv (as described
-   in Section 6.3), and the explicit part is included in
-   GenericAEAEDCipher.nonce_explicit.
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   Where "+" denotes concatenation.
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  The length will generally be larger than
-   TLSCompressed.length, but by an amount that varies with the AEAD
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-      AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
-                                   additional_data)
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   IV, the "additional_data", and the AEADEncrypted value. The output is
-   either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-      TLSCompressed.fragment = AEAD-Decrypt(write_key, IV,
-                                            AEADEncrypted,
-                                            additional_data)
-
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generates keys required
-   by the current connection state (see Appendix A.6) from the security
-   parameters provided by the handshake protocol.
-
-   The master secret is expanded into a sequence of secure bytes, which
-   is then split to a client write MAC key, a server write MAC key, a
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 24]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   client write encryption key, and a server write encryption key. Each
-   of these is generated from the byte sequence in that order.  Unused
-   values are empty.  Some AEAD ciphers may additionally require a
-   client write IV and a server write IV (see Section 6.2.3.3).
-
-   When keys and MAC keys are generated, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-      key_block = PRF(SecurityParameters.master_secret,
-                      "key expansion",
-                      SecurityParameters.server_random +
-                      SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-      client_write_MAC_key[SecurityParameters.mac_key_length]
-      server_write_MAC_key[SecurityParameters.mac_key_length]
-      client_write_key[SecurityParameters.enc_key_length]
-      server_write_key[SecurityParameters.enc_key_length]
-      client_write_IV[SecurityParameters.fixed_iv_length]
-      server_write_IV[SecurityParameters.fixed_iv_length]
-
-   The client_write_IV and server_write_IV are only generated for
-   implicit nonce techniques as described in Section 3.2.1 of [AEAD].
-
-   Implementation note: The currently defined cipher suite which
-   requires the most material is AES_256_CBC_SHA. It requires 2 x 32
-   byte keys and 2 x 20 byte MAC keys, for a total 104 bytes of key
-   material.
-
-7. The TLS Handshaking Protocols
-
-   TLS has three subprotocols that are used to allow peers to agree upon
-   security parameters for the record layer, to authenticate themselves,
-   to instantiate negotiated security parameters, and to report error
-   conditions to each other.
-
-   The Handshake Protocol is responsible for negotiating a session,
-   which consists of the following items:
-
-   session identifier
-      An arbitrary byte sequence chosen by the server to identify an
-      active or resumable session state.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 25]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   peer certificate
-      X509v3 [PKIX] certificate of the peer. This element of the state
-      may be null.
-
-   compression method
-      The algorithm used to compress data prior to encryption.
-
-   cipher spec
-      Specifies the bulk data encryption algorithm (such as null, DES,
-      etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
-      cryptographic attributes such as the mac_length. (See Appendix A.6
-      for formal definition.)
-
-   master secret
-      48-byte secret shared between the client and server.
-
-   is resumable
-      A flag indicating whether the session can be used to initiate new
-      connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-      struct {
-          enum { change_cipher_spec(1), (255) } type;
-      } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 26]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g., if it has to perform a time consuming public
-   key operation). Thus, a small window of time, during which the
-   recipient must buffer the data, MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-      enum { warning(1), fatal(2), (255) } AlertLevel;
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed_RESERVED(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          no_certificate_RESERVED(41),
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-          export_restriction_RESERVED(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 27]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-          no_renegotiation(100),
-          unsupported_extension(110),
-          (255)
-      } AlertDescription;
-
-      struct {
-          AlertLevel level;
-          AlertDescription description;
-      } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-   pending data before destroying the transport.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 28]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-7.2.2. Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed.
-
-   Whenever an implementation encounters a condition which is defined as
-   a fatal alert, it MUST send the appropriate alert prior to closing
-   the connection. In cases where an implementation chooses to send an
-   alert which may be a warning alert but intends to close the
-   connection immediately afterwards, it MUST send that alert at the
-   fatal alert level.
-
-   If an alert with a level of warning is sent and received, generally
-   the connection can continue normally.  If the receiving party decides
-   not to proceed with the connection (e.g., after having received a
-   no_renegotiation alert that it is not willing to accept), it SHOULD
-   send a fatal alert to terminate the connection.
-
-
-   The following error alerts are defined:
-
-   unexpected_message
-      An inappropriate message was received. This alert is always fatal
-      and should never be observed in communication between proper
-      implementations.
-
-   bad_record_mac
-      This alert is returned if a record is received with an incorrect
-      MAC. This alert also MUST be returned if an alert is sent because
-      a TLSCiphertext decrypted in an invalid way: either it wasn't an
-      even multiple of the block length, or its padding values, when
-      checked, weren't correct. This message is always fatal.
-
-   decryption_failed_RESERVED
-      This alert was used in some earlier versions of TLS, and may have
-      permitted certain attacks against the CBC mode [CBCATT].  It MUST
-      NOT be sent by compliant implementations.
-
-   record_overflow
-      A TLSCiphertext record was received that had a length more than
-      2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-      with more than 2^14+1024 bytes. This message is always fatal.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 29]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   decompression_failure
-      The decompression function received improper input (e.g., data
-      that would expand to excessive length). This message is always
-      fatal.
-
-   handshake_failure
-      Reception of a handshake_failure alert message indicates that the
-      sender was unable to negotiate an acceptable set of security
-      parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-      This alert was used in SSLv3 but not any version of TLS.  It MUST
-      NOT be sent by compliant implementations.
-
-   bad_certificate
-      A certificate was corrupt, contained signatures that did not
-      verify correctly, etc.
-
-   unsupported_certificate
-      A certificate was of an unsupported type.
-
-   certificate_revoked
-      A certificate was revoked by its signer.
-
-   certificate_expired
-      A certificate has expired or is not currently valid.
-
-   certificate_unknown
-      Some other (unspecified) issue arose in processing the
-      certificate, rendering it unacceptable.
-
-   illegal_parameter
-      A field in the handshake was out of range or inconsistent with
-      other fields. This message is always fatal.
-
-   unknown_ca
-      A valid certificate chain or partial chain was received, but the
-      certificate was not accepted because the CA certificate could not
-      be located or couldn't be matched with a known, trusted CA.  This
-      message is always fatal.
-
-   access_denied
-      A valid certificate was received, but when access control was
-      applied, the sender decided not to proceed with negotiation.  This
-      message is always fatal.
-
-   decode_error
-      A message could not be decoded because some field was out of the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 30]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      specified range or the length of the message was incorrect. This
-      message is always fatal.
-
-   decrypt_error
-      A handshake cryptographic operation failed, including being unable
-      to correctly verify a signature, decrypt a key exchange, or
-      validate a finished message.
-
-   export_restriction_RESERVED
-      This alert was used in some earlier versions of TLS.  It MUST NOT
-      be sent by compliant implementations.
-
-   protocol_version
-      The protocol version the client has attempted to negotiate is
-      recognized but not supported. (For example, old protocol versions
-      might be avoided for security reasons). This message is always
-      fatal.
-
-   insufficient_security
-      Returned instead of handshake_failure when a negotiation has
-      failed specifically because the server requires ciphers more
-      secure than those supported by the client. This message is always
-      fatal.
-
-   internal_error
-      An internal error unrelated to the peer or the correctness of the
-      protocol (such as a memory allocation failure) makes it impossible
-      to continue. This message is always fatal.
-
-   user_canceled
-      This handshake is being canceled for some reason unrelated to a
-      protocol failure. If the user cancels an operation after the
-      handshake is complete, just closing the connection by sending a
-      close_notify is more appropriate. This alert should be followed by
-      a close_notify. This message is generally a warning.
-
-   no_renegotiation
-      Sent by the client in response to a hello request or by the server
-      in response to a client hello after initial handshaking.  Either
-      of these would normally lead to renegotiation; when that is not
-      appropriate, the recipient should respond with this alert.  At
-      that point, the original requester can decide whether to proceed
-      with the connection. One case where this would be appropriate is
-      where a server has spawned a process to satisfy a request; the
-      process might receive security parameters (key length,
-      authentication, etc.) at startup and it might be difficult to
-      communicate changes to these parameters after that point. This
-      message is always a warning.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 31]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   unsupported_extension
-      sent by clients that receive an extended server hello containing
-      an extension that they did not put in the corresponding client
-      hello. This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not.  However, all messages that are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New Alert values are assigned by IANA as described in Section 12.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-   -  Exchange hello messages to agree on algorithms, exchange random
-      values, and check for session resumption.
-
-   -  Exchange the necessary cryptographic parameters to allow the
-      client and server to agree on a premaster secret.
-
-   -  Exchange certificates and cryptographic information to allow the
-      client and server to authenticate themselves.
-
-   -  Generate a master secret from the premaster secret and exchanged
-      random values.
-
-   -  Provide security parameters to the record layer.
-
-   -  Allow the client and server to verify that their peer has
-      calculated the same security parameters and that the handshake
-      occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man in the middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support. The protocol has been designed to
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 32]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection. The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require. The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 46 bytes upwards.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g., if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Next,
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client MUST send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify possession of the private
-   key in the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 33]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-   Cipher Spec. At this point, the handshake is complete, and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other than
-   TLS_NULL_WITH_NULL_NULL is established).
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-   Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-   independent TLS Protocol content type, and is not actually a TLS
-   handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 34]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 35]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-          } body;
-      } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message that is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which SHOULD be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message types are assigned by IANA as described in
-   Section 12.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello Request
-
-   When this message will be sent:
-
-      The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-
-      Hello request is a simple notification that the client should
-      begin the negotiation process anew by sending a client hello
-      message when convenient. This message is not intended to establish
-      which side is the client or server but merely to initiate a new
-      negotiation. Servers SHOULD NOT send a HelloRequest immediately
-      upon the client's initial connection.  It is the client's job to
-      send a ClientHello at that time.
-
-      This message will be ignored by the client if the client is
-      currently negotiating a session. This message may be ignored by
-      the client if it does not wish to renegotiate a session, or the
-      client may, if it wishes, respond with a no_renegotiation alert.
-      Since handshake messages are intended to have transmission
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 36]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      precedence over application data, it is expected that the
-      negotiation will begin before no more than a few records are
-      received from the client. If the server sends a hello request but
-      does not receive a client hello in response, it may close the
-      connection with a fatal alert.
-
-      After sending a hello request, servers SHOULD NOT repeat the
-      request until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-
-      struct { } HelloRequest;
-
-   Note: This message MUST NOT be included in the message hashes that
-   are maintained throughout the handshake and used in the finished
-   messages and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-
-      When a client first connects to a server it is required to send
-      the client hello as its first message. The client can also send a
-      client hello in response to a hello request or on its own
-      initiative in order to renegotiate the security parameters in an
-      existing connection.
-
-   Structure of this message:
-
-      The client hello message includes a random structure, which is
-      used later in the protocol.
-
-         struct {
-             uint32 gmt_unix_time;
-             opaque random_bytes[28];
-         } Random;
-
-      gmt_unix_time
-         The current time and date in standard UNIX 32-bit format
-         (seconds since the midnight starting Jan 1, 1970, GMT, ignoring
-         leap seconds) according to the sender's internal clock. Clocks
-         are not required to be set correctly by the basic TLS Protocol;
-         higher-level or application protocols may define additional
-         requirements.
-
-      random_bytes
-         28 bytes generated by a secure random number generator.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 37]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   The client hello message includes a variable-length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or from another currently active connection. The second
-   option is useful if the client only wishes to update the random
-   structures and derived values of a connection, and the third option
-   makes it possible to establish several independent secure connections
-   without repeating the full handshake protocol. These independent
-   connections may occur sequentially or simultaneously; a SessionID
-   becomes valid when the handshake negotiating it completes with the
-   exchange of Finished messages and persists until it is removed due to
-   aging or because a fatal error was encountered on a connection
-   associated with the session. The actual contents of the SessionID are
-   defined by the server.
-
-      opaque SessionID<0..32>;
-
-   Warning: Because the SessionID is transmitted without encryption or
-   immediate MAC protection, servers MUST NOT place confidential
-   information in session identifiers or let the contents of fake
-   session identifiers cause any breach of security. (Note that the
-   content of the handshake as a whole, including the SessionID, is
-   protected by the Finished messages exchanged at the end of the
-   handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-      uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-      enum { null(0), (255) } CompressionMethod;
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-2>;
-          CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 38]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-          select (extensions_present) {
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ClientHello;
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block. The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello. Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field but is used for compatibility with TLS before
-   extensions were defined.
-
-   client_version
-      The version of the TLS protocol by which the client wishes to
-      communicate during this session. This SHOULD be the latest
-      (highest valued) version supported by the client. For this version
-      of the specification, the version will be 3.3 (See Appendix E for
-      details about backward compatibility).
-
-   random
-      A client-generated random structure.
-
-   session_id
-      The ID of a session the client wishes to use for this connection.
-      This field is empty if no session_id is available, or it the
-      client wishes to generate new security parameters.
-
-   cipher_suites
-      This is a list of the cryptographic options supported by the
-      client, with the client's first preference first. If the
-      session_id field is not empty (implying a session resumption
-      request) this vector MUST include at least the cipher_suite from
-      that session. Values are defined in Appendix A.5.
-
-   compression_methods
-      This is a list of the compression methods supported by the client,
-      sorted by client preference. If the session_id field is not empty
-      (implying a session resumption request) it MUST include the
-      compression_method from that session. This vector MUST contain,
-      and all implementations MUST support, CompressionMethod.null.
-      Thus, a client and server will always be able to agree on a
-      compression method.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 39]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   client_hello_extension_list
-      Clients MAY request extended functionality from servers by sending
-      data in the client_hello_extension_list.  Here the new
-      "client_hello_extension_list" field contains a list of extensions.
-      The actual "Extension" format is defined in Section 7.4.1.4.
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-   client MAY abort the handshake.  A server that supports the
-   extensions mechanism MUST accept client hello messages in either the
-   original (TLS 1.0/TLS 1.1) ClientHello or the extended ClientHello
-   format defined in this document, and (as for all other messages) MUST
-   check that the amount of data in the message precisely matches one of
-   these formats; if not then it MUST send a fatal "decode_error" alert.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-7.4.1.3. Server Hello
-
-   When this message will be sent:
-
-      The server will send this message in response to a client hello
-      message when it was able to find an acceptable set of algorithms.
-      If it cannot find such a match, it will respond with a handshake
-      failure alert.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          select (extensions_present) {
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ServerHello;
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 40]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   server_version
-      This field will contain the lower of that suggested by the client
-      in the client hello and the highest supported by the server. For
-      this version of the specification, the version is 3.3.  (See
-      Appendix E for details about backward compatibility.)
-
-   random
-      This structure is generated by the server and MUST be
-      independently generated from the ClientHello.random.
-
-   session_id
-      This is the identity of the session corresponding to this
-      connection. If the ClientHello.session_id was non-empty, the
-      server will look in its session cache for a match. If a match is
-      found and the server is willing to establish the new connection
-      using the specified session state, the server will respond with
-      the same value as was supplied by the client. This indicates a
-      resumed session and dictates that the parties must proceed
-      directly to the finished messages. Otherwise this field will
-      contain a different value identifying the new session. The server
-      may return an empty session_id to indicate that the session will
-      not be cached and therefore cannot be resumed. If a session is
-      resumed, it must be resumed using the same cipher suite it was
-      originally negotiated with. Note that there is no requirement that
-      the server resume any session even if it had formerly provided a
-      session_id. Client MUST be prepared to do a full negotiation --
-      including negotiating new cipher suites -- during any handshake.
-
-   cipher_suite
-      The single cipher suite selected by the server from the list in
-      ClientHello.cipher_suites. For resumed sessions, this field is the
-      value from the state of the session being resumed.
-
-   compression_method
-      The single compression algorithm selected by the server from the
-      list in ClientHello.compression_methods. For resumed sessions this
-      field is the value from the resumed session state.
-
-   server_hello_extension_list
-      A list of extensions. Note that only extensions offered by the
-      client can appear in the server's list.
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 41]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-7.4.1.4 Hello Extensions
-
-   The extension format is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-      enum {
-          signature_algorithms(TBD-BY-IANA), (65535)
-      } ExtensionType;
-
-   Here:
-
-   -  "extension_type" identifies the particular extension type.
-
-   -  "extension_data" contains information specific to the particular
-      extension type.
-
-   The initial set of extensions is defined in a companion document
-   [TLSEXT]. The list of extension types is maintained by IANA as
-   described in Section 12.
-
-   There are subtle (and not so subtle) interactions that may occur in
-   this protocol between new features and existing features which may
-   result in a significant reduction in overall security, The following
-   considerations should be taken into account when designing new
-   extensions:
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some simply a refusal to support a particular
-      feature.  In general error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should as far as possible be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase. Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 42]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS - particularly since
-      the TLS handshake algorithms have specific protection against
-      version rollback attacks based on the version number, and the
-      possibility of version rollback should be a significant
-      consideration in any major design change.
-
-7.4.1.4.1 Signature Algorithms
-
-   The client MAY use the "signature_algorithms" extension to indicate
-   to the server which signature/hash algorithm pairs may be used in
-   digital signatures. The "extension_data" field of this extension
-   contains a "supported_signature_algorithms" value.
-
-      enum {
-          none(0), md5(1), sha1(2), sha256(3), sha384(4),
-          sha512(5), (255)
-      } HashAlgorithm;
-
-      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
-        SignatureAlgorithm;
-
-      struct {
-            HashAlgorithm hash;
-            SignatureAlgorithm signature;
-      } SignatureAndHashAlgorithm;
-
-      SignatureAndHashAlgorithm
-        supported_signature_algorithms<2..2^16-1>;
-
-   Each SignatureAndHashAlgorithm value lists a single hash/signature
-   pair which the client is willing to verify. The values are indicated
-   in descending order of preference.
-
-   Note: Because not all signature algorithms and hash algorithms may be
-   accepted by an implementation (e.g., DSA with SHA-1, but not
-   SHA-256), algorithms here are listed in pairs.
-
-   hash
-      This field indicates the hash algorithm which may be used. The
-      values indicate support for unhashed data, MD5 [MD5], SHA-1,
-      SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value
-      is provided for future extensibility, in case of a signature
-      algorithm which does not require hashing before signing.
-
-   signature
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 43]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      This field indicates the signature algorithm which may be used.
-      The values indicate anonymous signatures, RSA [PKCS1] and DSA
-      [DSS] respectively. The "anonymous" value is meaningless in this
-      context but used later in the specification. It MUST NOT appear in
-      this extension.
-
-   The semantics of this extension are somewhat complicated because the
-   cipher suite indicates permissible signature algorithms but not hash
-   algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
-
-   Clients SHOULD send this extension if they support any hash algorithm
-   other than SHA-1.
-
-   If the client does not send the signature_algorithms extension, the
-   server SHOULD assume the following:
-
-   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
-   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
-   the value (sha1,rsa).
-
-   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
-   DH_DSS), behave as if the client had sent the value (sha1,dsa).
-
-   -  If the negotiated key exchnage algorithm is one of (ECDH_ECDSA,
-   ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).
-
-   Note: this is a change from TLS 1.1 where there are no explicit rules
-   but as a practical matter one can assume that the peer supports MD5
-   and SHA-1.
-
-   Servers MUST NOT send this extension.
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-
-      The server MUST send a certificate whenever the agreed-upon key
-      exchange method uses certificates for authentication (this
-      includes all key exchange methods defined in this document except
-      DH_anon).  This message will always immediately follow the server
-      hello message.
-
-   Meaning of this message:
-
-      This message conveys the server's certificate to the client. The
-      certificate MUST be appropriate for the negotiated cipher suite's
-      key exchange algorithm, and any negotiated extensions.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 44]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   Structure of this message:
-
-      opaque ASN.1Cert<1..2^24-1>;
-
-      struct {
-          ASN.1Cert certificate_list<0..2^24-1>;
-      } Certificate;
-
-   certificate_list
-      This is a sequence (chain) of certificates. The sender's
-      certificate MUST come first in the list. Each following
-      certificate MUST directly certify the one preceding it. Because
-      certificate validation requires that root keys be distributed
-      independently, the self-signed certificate that specifies the root
-      certificate authority MAY optionally be omitted from the chain,
-      under the assumption that the remote end must already possess it
-      in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
-   Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-   vector because PKCS #6 [PKCS6] extended certificates are not used.
-   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
-   of parsing the list more difficult.
-
-   The following rules apply to the certificates sent by the server:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g., [TLSPGP]).
-
-   -  The certificate's public key (and associated restrictions) MUST be
-      compatible with the selected key exchange algorithm.
-
-      Key Exchange Alg.  Certificate Key Type
-
-      RSA                RSA public key; the certificate MUST
-      RSA_PSK            allow the key to be used for encryption
-                         (the keyEncipherment bit MUST be set
-                         if the key usage extension is present).
-                         Note: RSA_PSK is defined in [TLSPSK].
-
-      DHE_RSA            RSA public key; the certificate MUST
-      ECDHE_RSA          allow the key to be used for signing
-                         (the digitalSignature bit MUST be set
-                         if the key usage extension is present)
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 45]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-                         with the signature scheme and hash
-                         algorithm that will be employed in the
-                         server key exchange message.
-
-      DHE_DSS            DSA public key; the certificate MUST
-                         allow the key to be used for signing with
-                         the hash algorithm that will be employed
-                         in the server key exchange message.
-
-      DH_DSS             Diffie-Hellman public key; the
-      DH_RSA             keyAgreement bit MUST be set if the
-                         key usage extension is present.
-
-      ECDH_ECDSA         ECDH-capable public key; the public key
-      ECDH_RSA           MUST use a curve and point format supported
-                         by the client, as described in [TLSECC].
-
-      ECDHE_ECDSA        ECDSA-capable public key; the certificate
-                         MUST allow the key to be used for signing
-                         with the hash algorithm that will be
-                         employed in the server key exchange
-                         message. The public key MUST use a curve
-                         and point format supported by the client,
-                         as described in  [TLSECC].
-
-   -  The "server_name" and "trusted_ca_keys" extensions [4366bis] are
-      used to guide certificate selection.
-
-   If the client provided a "signature_algorithms" extension, then all
-   certificates provided by the server MUST be signed by a
-   hash/signature algorithm pair that appears in that extension.  Note
-   that this implies that a certificate containing a key for one
-   signature algorithm MAY be signed using a different signature
-   algorithm (for instance, an RSA key signed with a DSA key.) This is a
-   departure from TLS 1.1, which required that the algorithms be the
-   same.  Note that this also implies that the DH_DSS, DH_RSA,
-   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
-   algorithm used to sign the certificate. Fixed DH certificates MAY be
-   signed with any hash/signature algorithm pair appearing in the
-   extension.  The naming is historical.
-
-   If the server has multiple certificates, it chooses one of them based
-   on the above-mentioned criteria (in addition to other criteria, such
-   as transport layer endpoint, local configuration and preferences,
-   etc.).
-
-   Note that there are certificates that use algorithms and/or algorithm
-   combinations that cannot be currently used with TLS.  For example, a
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 46]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
-   SubjectPublicKeyInfo) cannot be used because TLS defines no
-   corresponding signature algorithm.
-
-   As CipherSuites that specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-
-      This message will be sent immediately after the server certificate
-      message (or the server hello message, if this is an anonymous
-      negotiation).
-
-      The server key exchange message is sent by the server only when
-      the server certificate message (if sent) does not contain enough
-      data to allow the client to exchange a premaster secret. This is
-      true for the following key exchange methods:
-
-         DHE_DSS
-         DHE_RSA
-         DH_anon
-
-      It is not legal to send the server key exchange message for the
-      following key exchange methods:
-
-         RSA
-         DH_DSS
-         DH_RSA
-
-   Meaning of this message:
-
-      This message conveys cryptographic information to allow the client
-      to communicate the premaster secret: a Diffie-Hellman public key
-      with which the client can complete a key exchange (with the result
-      being the premaster secret) or a public key for some other
-      algorithm.
-
-   Structure of this message:
-
-      enum { diffie_hellman, rsa } KeyExchangeAlgorithm;
-
-      struct {
-          opaque dh_p<1..2^16-1>;
-          opaque dh_g<1..2^16-1>;
-          opaque dh_Ys<1..2^16-1>;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 47]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      } ServerDHParams;     /* Ephemeral DH parameters */
-
-      dh_p
-         The prime modulus used for the Diffie-Hellman operation.
-
-      dh_g
-         The generator used for the Diffie-Hellman operation.
-
-      dh_Ys
-         The server's Diffie-Hellman public value (g^X mod p).
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                  ServerDHParams params;
-                  Signature signed_params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                  ServerDHParams params;
-          };
-      } ServerParams;
-
-
-      params
-         The server's key exchange parameters.
-
-      signed_params
-         For non-anonymous key exchanges, a hash of the corresponding
-         params value, with the signature appropriate to that hash
-         applied.
-
-      hash
-         Hash(ClientHello.random + ServerHello.random + ServerParams)
-         where Hash is the chosen hash value and Hash.length is
-         its output.
-
-      struct {
-          select (SignatureAlgorithm) {
-            case anonymous: struct { };
-              case rsa:
-                SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 48]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-              case dsa:
-                SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-              };
-          };
-      } Signature;
-
-   If the client has offered the "signature_algorithms" extension, the
-   signature algorithm and hash algorithm MUST be a pair listed in that
-   extension. Note that there is a possibility for inconsistencies here.
-   For instance, the client might offer DHE_DSS key exchange but omit
-   any DSS pairs from its "signature_algorithms" extension.  In order to
-   negotiate correctly, the server MUST check any candidate cipher
-   suites against the "signature_algorithms" extension before selecting
-   them. This is somewhat inelegant but is a compromise designed to
-   minimize changes to the original cipher suite design.
-
-   If no "signature_algorithms" extension is present, the server MUST
-   use SHA-1 as the hash algorithm.
-
-   In addition, the hash and signature algorithms MUST be compatible
-   with the key in the server's end-entity certificate.  RSA keys MAY be
-   used with any permitted hash algorithm, subject to restrictions in
-   the certificate, if any.
-
-   Because DSA signatures do not contain any secure indication of hash
-   algorithm, there is a risk of hash substitution if multiple hashes
-   may be used with any key. Currently, DSS [DSS] may only be used with
-   SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
-   digest algorithms, as well as guidance as to which digest algorithms
-   should be used with each key size. In addition, future revisions of
-   [PKIX] may specify mechanisms for certificates to indicate which
-   digest algorithms are to be used with DSA.
-
-   As additional CipherSuites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-7.4.4. Certificate Request
-
-   When this message will be sent:
-
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 49]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-
-      enum {
-          rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-          rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-          fortezza_dms_RESERVED(20), (255)
-      } ClientCertificateType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-      struct {
-          ClientCertificateType certificate_types<1..2^8-1>;
-          SignatureAndHashAlgorithm
-            supported_signature_algorithms<2^16-1>;
-          DistinguishedName certificate_authorities<0..2^16-1>;
-      } CertificateRequest;
-
-   certificate_types
-      A list of the types of certificate types which the client may
-      offer.
-
-         rsa_sign        a certificate containing an RSA key
-         dss_sign        a certificate containing a DSS key
-         rsa_fixed_dh    a certificate containing a static DH key.
-         dss_fixed_dh    a certificate containing a static DH key
-
-   supported_signature_algorithms
-      A list of the hash/signature algorithm pairs that the server is
-      able to verify, listed in descending order of preference.
-
-   certificate_authorities
-      A list of the distinguished names [X501] of acceptable
-      certificate_authorities, represented in DER-encoded format. These
-      distinguished names may specify a desired distinguished name for a
-      root CA or for a subordinate CA; thus, this message can be used
-      both to describe known roots and a desired authorization space. If
-      the certificate_authorities list is empty then the client MAY send
-      any certificate of the appropriate ClientCertificateType, unless
-      there is some external arrangement to the contrary.
-
-   The interaction of the certificate_types and
-   supported_signature_algorithms fields is somewhat complicated.
-   certificate_types has been present in TLS since SSLv3, but was
-   somewhat underspecified. Much of its functionality is superseded by
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 50]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   supported_signature_algorithms. The following rules apply:
-
-   -  Any certificates provided by the client MUST be signed using a
-      hash/signature algorithm pair found in supported_signature_types.
-
-   -  The end-entity certificate provided by the client MUST contain a
-      key which is compatible with certificate_types. If the key is a
-      signature key, it MUST be usable with some hash/signature
-      algorithm pair in supported_signature_types.
-
-   -  For historical reasons, the names of some client certificate types
-      include the algorithm used to sign the certificate.  For example,
-      in earlier versions of TLS, rsa_fixed_dh meant a certificate
-      signed with RSA and containing a static DH key.  In TLS 1.2, this
-      functionality has been obsoleted by the signature_types field, and
-      the certificate type no longer restricts the algorithm used to
-      sign the certificate.  For example, if the server sends
-      dss_fixed_dh certificate type and {dss_sha1, rsa_sha1} signature
-      types, the client MAY to reply with a certificate containing a
-      static DH key, signed with RSA-SHA1.
-
-   New ClientCertificateType values are assigned by IANA as described in
-   Section 12.
-
-   Note: Values listed as RESERVED may not be used. They were used in
-   SSLv3.
-
-   Note: It is a fatal handshake_failure alert for an anonymous server
-   to request client authentication.
-
-7.4.5 Server hello done
-
-   When this message will be sent:
-
-      The server hello done message is sent by the server to indicate
-      the end of the server hello and associated messages. After sending
-      this message, the server will wait for a client response.
-
-   Meaning of this message:
-
-      This message means that the server is done sending messages to
-      support the key exchange, and the client can proceed with its
-      phase of the key exchange.
-
-      Upon receipt of the server hello done message, the client SHOULD
-      verify that the server provided a valid certificate, if required
-      and check that the server hello parameters are acceptable.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 51]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   Structure of this message:
-
-      struct { } ServerHelloDone;
-
-7.4.6. Client Certificate
-
-   When this message will be sent:
-
-      This is the first message the client can send after receiving a
-      server hello done message. This message is only sent if the server
-      requests a certificate. If no suitable certificate is available,
-      the client MUST send a certificate message containing no
-      certificates. That is, the certificate_list structure has a length
-      of zero. If client authentication is required by the server for
-      the handshake to continue, it may respond with a fatal handshake
-      failure alert. Client certificates are sent using the Certificate
-      structure defined in Section 7.4.2.
-
-   Meaning of this message:
-
-      This message conveys the client's certificate to the server; the
-      server will use it when verifying the certificate verify message
-      (when the client authentication is based on signing), or calculate
-      the premaster secret (for non-ephemeral Diffie-Hellman).  The
-      certificate MUST be appropriate for the negotiated cipher suite's
-      key exchange algorithm, and any negotiated extensions.
-
-   In particular:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g. [TLSPGP]).
-
-   -  The certificate's public key (and associated restrictions) has to
-      be compatible with the certificate types listed in
-      CertificateRequest:
-
-      Client Cert. Type   Certificate Key Type
-
-      rsa_sign            RSA public key; the certificate MUST allow
-                          the key to be used for signing with the
-                          signature scheme and hash algorithm that
-                          will be employed in the certificate verify
-                          message.
-
-      dss_sign            DSA public key; the certificate MUST allow
-                          the key to be used for signing with the
-                          hash algorithm that will be employed in
-                          the certificate verify message.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 52]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      ecdsa_sign          ECDSA-capable public key; the certificate
-                          MUST allow the key to be used for signing
-                          with the hash algorithm that will be
-                          employed in the certificate verify
-                          message; the public key MUST use a
-                          curve and point format supported by the
-                          server.
-
-      rsa_fixed_dh        Diffie-Hellman public key; MUST use
-      dss_fixed_dh        the same parameters as server's key.
-
-      rsa_fixed_ecdh      ECDH-capable public key; MUST use
-      ecdsa_fixed_ecdh    the same curve as server's key, and
-                          MUST use a point format supported by
-
-   -  If the certificate_authorities list in the certificate request
-      message was non-empty, the certificate SHOULD be issued by one of
-      the listed CAs.
-
-   -  The certificates MUST be signed using an acceptable hash/
-      signature algorithm pair, as described in Section 7.4.4. Note that
-      this relaxes the constraints on certificate signing algorithms
-      found in prior versions of TLS.
-
-   Note that as with the server certificate, there are certificates that
-   use algorithms/algorithm combinations that cannot be currently used
-   with TLS.
-
-7.4.7. Client Key Exchange Message
-
-   When this message will be sent:
-
-      This message is always sent by the client. It MUST immediately
-      follow the client certificate message, if it is sent. Otherwise it
-      MUST be the first message sent by the client after it receives the
-      server hello done message.
-
-   Meaning of this message:
-
-      With this message, the premaster secret is set, either though
-      direct transmission of the RSA-encrypted secret, or by the
-      transmission of Diffie-Hellman parameters that will allow each
-      side to agree upon the same premaster secret.
-
-      When the client is using an ephemeral Diffie-Hellman exponent,
-      then this message contains the client's Diffie-Hellman public
-      value. If the client is sending a certificate containing a static
-      DH exponent (i.e., it is doing fixed_dh client authentication)
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 53]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      then this message MUST be sent but MUST be empty.
-
-
-   Structure of this message:
-
-      The choice of messages depends on which key exchange method has
-      been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-      definition.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-
-      If RSA is being used for key agreement and authentication, the
-      client generates a 48-byte premaster secret, encrypts it using the
-      public key from the server's certificate and sends the result in
-      an encrypted premaster secret message. This structure is a variant
-      of the client key exchange message and is not a message in itself.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion client_version;
-          opaque random[46];
-      } PreMasterSecret;
-
-      client_version
-         The latest (newest) version supported by the client. This is
-         used to detect version roll-back attacks.
-
-      random
-         46 securely-generated random bytes.
-
-      struct {
-          public-key-encrypted PreMasterSecret pre_master_secret;
-      } EncryptedPreMasterSecret;
-
-      pre_master_secret
-         This random value is generated by the client and is used to
-         generate the master secret, as specified in Section 8.1.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 54]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   Note: The version number in the PreMasterSecret is the version
-   offered by the client in the ClientHello.client_version, not the
-   version negotiated for the connection.  This feature is designed to
-   prevent rollback attacks.  Unfortunately, some old implementations
-   use the negotiated version instead and therefore checking the version
-   number may lead to failure to interoperate with such incorrect client
-   implementations.
-
-   Client implementations MUST always send the correct version number in
-   PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
-   server implementations MUST check the version number as described in
-   the note below. If the version number is earlier than 1.0, server
-   implementations SHOULD check the version number, but MAY have a
-   configuration option to disable the check. Note that if the check
-   fails, the PreMasterSecret SHOULD be randomized as described below.
-
-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
-   [KPR03] can be used to attack a TLS server that reveals whether a
-   particular message, when decrypted, is properly PKCS#1 formatted,
-   contains a valid PreMasterSecret structure, or has the correct
-   version number.
-
-   The best way to avoid these vulnerabilities is to treat incorrectly
-   formatted messages in a manner indistinguishable from correctly
-   formatted RSA blocks. In other words:
-
-      1. Generate a string R of 46 random bytes
-
-      2. Decrypt the message M
-
-      3. If the PKCS#1 padding is not correct, or the length of
-         message M is not exactly 48 bytes:
-            premaster secret = ClientHello.client_version || R
-         else If ClientHello.client_version <= TLS 1.0, and
-         version number check is explicitly disabled:
-            premaster secret = M
-         else:
-            premaster secret = ClientHello.client_version || M[2..47]
-
-   In any case, a TLS server MUST NOT generate an alert if processing an
-   RSA-encrypted premaster secret message fails, or the version number
-   is not as expected. Instead, it MUST continue the handshake with a
-   randomly generated premaster secret.  It may be useful to log the
-   real cause of failure for troubleshooting purposes; however, care
-   must be taken to avoid leaking the information to an attacker
-   (though, e.g., timing, log files, or other channels.)
-
-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 55]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   against the Bleichenbacher attack. However, for maximal compatibility
-   with earlier versions of TLS, this specification uses the RSAES-
-   PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
-   to exist provided that the above recommendations are followed.
-
-   Implementation Note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes. These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined. The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the the length bytes, encoding the RSA encrypted data
-   directly in the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes. The resulting
-   PDU is incompatible with many SSLv3 implementations. Implementors
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding. Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-   behavior dependent on the protocol version.
-
-   Implementation Note: It is now known that remote timing-based attacks
-   on TLS are possible, at least when the client and server are on the
-   same LAN. Accordingly, implementations that use static RSA keys MUST
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
-
-7.4.7.2. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-
-      This structure conveys the client's Diffie-Hellman public value
-      (Yc) if it was not already included in the client's certificate.
-      The encoding used for Yc is determined by the enumerated
-      PublicValueEncoding. This structure is a variant of the client key
-      exchange message, and not a message in itself.
-
-   Structure of this message:
-
-      enum { implicit, explicit } PublicValueEncoding;
-
-      implicit
-         If the client has sent a certificate which contains a suitable
-         Diffie-Hellman key (for fixed_dh client authentication) then Yc
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 56]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-         is implicit and does not need to be sent again. In this case,
-         the client key exchange message will be sent, but it MUST be
-         empty.
-
-      explicit
-         Yc needs to be sent.
-
-      struct {
-          select (PublicValueEncoding) {
-              case implicit: struct { };
-              case explicit: opaque dh_Yc<1..2^16-1>;
-          } dh_public;
-      } ClientDiffieHellmanPublic;
-
-      dh_Yc
-         The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-
-      This message is used to provide explicit verification of a client
-      certificate. This message is only sent following a client
-      certificate that has signing capability (i.e. all certificates
-      except those containing fixed Diffie-Hellman parameters). When
-      sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-
-      struct {
-           Signature signature;
-      } CertificateVerify;
-
-      The Signature type is defined in 7.4.3.
-
-      The hash algorithm is denoted Hash below.
-
-      CertificateVerify.signature.hash = Hash(handshake_messages);
-
-   The hash and signature algorithms MUST be one of those present in the
-   supported_signature_algorithms field of the CertificateRequest
-   message. In addition, the hash and signature algorithms MUST be
-   compatible with the key in the client's end-entity certificate.  RSA
-   keys MAY be used with any permitted hash algorith, subject to
-   restrictions in the certificate, if any.
-
-   Because DSA signatures do not contain any secure indication of hash
-   algorithm, there is a risk of hash substitution if multiple hashes
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 57]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   may be used with any key. Currently, DSS [DSS] may only be used with
-   SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
-   digest algorithms, as well as guidance as to which digest algorithms
-   should be used with each key size. In addition, future revisions of
-   [PKIX] may specify mechanisms for certificates to indicate which
-   digest algorithms are to be used with DSA.
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-
-      A finished message is always sent immediately after a change
-      cipher spec message to verify that the key exchange and
-      authentication processes were successful. It is essential that a
-      change cipher spec message be received between the other handshake
-      messages and the Finished message.
-
-   Meaning of this message:
-
-      The finished message is the first protected with the just-
-      negotiated algorithms, keys, and secrets. Recipients of finished
-      messages MUST verify that the contents are correct.  Once a side
-      has sent its Finished message and received and validated the
-      Finished message from its peer, it may begin to send and receive
-      application data over the connection.
-
-   Structure of this message:
-
-      struct {
-          opaque verify_data[verify_data_length];
-      } Finished;
-
-      verify_data
-         PRF(master_secret, finished_label, Hash(handshake_messages))
-            [0..verify_data_length-1];
-
-      finished_label
-         For Finished messages sent by the client, the string "client
-         finished". For Finished messages sent by the server, the string
-         "server finished".
-
-      Hash denotes a Hash of the handshake messages. For the PRF defined
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 58]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      in Section 5, the Hash MUST be the Hash used as the basis for the
-      PRF. Any cipher suite which defines a different PRF MUST also
-      define the Hash to use in the Finished computation.
-
-      In previous versions of TLS, the verify_data was always 12 octets
-      long. In the current version of TLS, it depends on the cipher
-      suite. Any cipher suite which does not explicitly specify
-      verify_data_length has a verify_data_length equal to 12. This
-      includes all existing cipher suites.  Note that this
-      representation has the same encoding as with previous versions.
-      Future cipher suites MAY specify other lengths but such length
-      MUST be at least 12 bytes.
-
-      handshake_messages
-         All of the data from all messages in this handshake (not
-         including any HelloRequest messages) up to but not including
-         this message. This is only data visible at the handshake layer
-         and does not include record layer headers.  This is the
-         concatenation of all the Handshake structures as defined in
-         7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
-   Note: Change cipher spec messages, alerts, and any other record types
-   are not handshake messages and are not included in the hash
-   computations. Also, Hello Request messages are omitted from handshake
-   hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 59]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-8.1. Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-      master_secret = PRF(pre_master_secret, "master secret",
-                          ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
-   Note: Diffie-Hellman parameters are specified by the server and may
-   be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_AES_128_CBC_SHA.
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. Security Considerations
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 60]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-12. IANA Considerations
-
-   This document uses several registries that were originally created in
-   [TLS1.1]. IANA is requested to update (has updated) these to
-   reference this document. The registries and their allocation policies
-   (unchanged from [TLS1.1]) are listed below.
-
-   -  TLS ClientCertificateType Identifiers Registry: Future values in
-      the range 0-63 (decimal) inclusive are assigned via Standards
-      Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
-      are assigned Specification Required [RFC2434]. Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   -  TLS Cipher Suite Registry: Future values with the first byte in
-      the range 0-191 (decimal) inclusive are assigned via Standards
-      Action [RFC2434].  Values with the first byte in the range 192-254
-      (decimal) are assigned via Specification Required [RFC2434].
-      Values with the first byte 255 (decimal) are reserved for Private
-      Use [RFC2434].
-
-   -  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   -  TLS Alert Registry: Future values are allocated via Standards
-      Action [RFC2434].
-
-   -  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA is requested to update (has updated) it to reference this
-   document.  The registry and its allocation policy (unchanged from
-   [RFC4366]) is listed below:
-
-   -  TLS ExtensionType Registry: Future values are allocated via IETF
-      Consensus [RFC2434]
-
-   In addition, this document defines two new registries to be
-   maintained by IANA:
-
-   -  TLS SignatureAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 61]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-   -  TLS HashAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-   This document defines one new TLS extension, signature_algorithms,
-   which is to be (has been) allocated value TBD-BY-IANA in the TLS
-   ExtensionType registry.
-
-   This document also uses the TLS Compression Method Identifiers
-   Registry, defined in [RFC3749].  IANA is requested to allocate value
-   0 for the "null" compression method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 62]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Appendix A. Protocol Constant Values
-
-   This section describes protocol types and constants.
-
-A.1. Record Layer
-
-   struct {
-       uint8 major, minor;
-   } ProtocolVersion;
-
-   ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-   enum {
-       change_cipher_spec(20), alert(21), handshake(22),
-       application_data(23), (255)
-   } ContentType;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSPlaintext.length];
-   } TLSPlaintext;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSCompressed.length];
-   } TLSCompressed;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       select (SecurityParameters.cipher_type) {
-           case stream: GenericStreamCipher;
-           case block:  GenericBlockCipher;
-           case aead:   GenericAEADCipher;
-       } fragment;
-   } TLSCiphertext;
-
-   stream-ciphered struct {
-       opaque content[TLSCompressed.length];
-       opaque MAC[SecurityParameters.mac_length];
-   } GenericStreamCipher;
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 63]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       block-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       };
-   } GenericBlockCipher;
-
-   aead-ciphered struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       opaque aead_output[AEADEncrypted.length];
-   } GenericAEADCipher;
-
-A.2. Change Cipher Specs Message
-
-   struct {
-       enum { change_cipher_spec(1), (255) } type;
-   } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-   enum { warning(1), fatal(2), (255) } AlertLevel;
-
-   enum {
-       close_notify(0),
-       unexpected_message(10),
-       bad_record_mac(20),
-       decryption_failed_RESERVED(21),
-       record_overflow(22),
-       decompression_failure(30),
-       handshake_failure(40),
-       no_certificate_RESERVED(41),
-       bad_certificate(42),
-       unsupported_certificate(43),
-       certificate_revoked(44),
-       certificate_expired(45),
-       certificate_unknown(46),
-       illegal_parameter(47),
-       unknown_ca(48),
-       access_denied(49),
-       decode_error(50),
-       decrypt_error(51),
-       export_restriction_RESERVED(60),
-       protocol_version(70),
-       insufficient_security(71),
-       internal_error(80),
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 64]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-       user_canceled(90),
-       no_renegotiation(100),
-       unsupported_extension(110),           /* new */
-       (255)
-   } AlertDescription;
-
-   struct {
-       AlertLevel level;
-       AlertDescription description;
-   } Alert;
-
-A.4. Handshake Protocol
-
-   enum {
-       hello_request(0), client_hello(1), server_hello(2),
-       certificate(11), server_key_exchange (12),
-       certificate_request(13), server_hello_done(14),
-       certificate_verify(15), client_key_exchange(16),
-       finished(20)
-       (255)
-   } HandshakeType;
-
-   struct {
-       HandshakeType msg_type;
-       uint24 length;
-       select (HandshakeType) {
-           case hello_request:       HelloRequest;
-           case client_hello:        ClientHello;
-           case server_hello:        ServerHello;
-           case certificate:         Certificate;
-           case server_key_exchange: ServerKeyExchange;
-           case certificate_request: CertificateRequest;
-           case server_hello_done:   ServerHelloDone;
-           case certificate_verify:  CertificateVerify;
-           case client_key_exchange: ClientKeyExchange;
-           case finished:            Finished;
-       } body;
-   } Handshake;
-
-A.4.1. Hello Messages
-
-   struct { } HelloRequest;
-
-   struct {
-       uint32 gmt_unix_time;
-       opaque random_bytes[28];
-   } Random;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 65]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   opaque SessionID<0..32>;
-
-   uint8 CipherSuite[2];
-
-   enum { null(0), (255) } CompressionMethod;
-
-   struct {
-       ProtocolVersion client_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suites<2..2^16-2>;
-       CompressionMethod compression_methods<1..2^8-1>;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ClientHello;
-
-   struct {
-       ProtocolVersion server_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suite;
-       CompressionMethod compression_method;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ServerHello;
-
-   struct {
-       ExtensionType extension_type;
-       opaque extension_data<0..2^16-1>;
-   } Extension;
-
-   enum {
-       signature_algorithms(TBD-BY-IANA), (65535)
-   } ExtensionType;
-
-   enum{
-       none(0), md5(1), sha1(2), sha256(3), sha384(4),
-       sha512(5), (255)
-   } HashAlgorithm;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 66]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
-
-   struct {
-         HashAlgorithm hash;
-         SignatureAlgorithm signature;
-   } SignatureAndHashAlgorithm;
-
-   SignatureAndHashAlgorithm
-    supported_signature_algorithms<2..2^16-1>;
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-   opaque ASN.1Cert<2^24-1>;
-
-   struct {
-       ASN.1Cert certificate_list<0..2^24-1>;
-   } Certificate;
-
-   enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-   struct {
-       opaque dh_p<1..2^16-1>;
-       opaque dh_g<1..2^16-1>;
-       opaque dh_Ys<1..2^16-1>;
-   } ServerDHParams;
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case diffie_hellman:
-               ServerDHParams params;
-               Signature signed_params;
-       }
-   } ServerKeyExchange;
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case diffie_hellman:
-               ServerDHParams params;
-       };
-   } ServerParams;
-
-   struct {
-       select (SignatureAlgorithm) {
-         case anonymous: struct { };
-           case rsa:
-               SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-               digitally-signed struct {
-                   opaque hash[Hash.length];
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 67]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-               };
-           case dsa:
-               SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-               digitally-signed struct {
-                   opaque hash[Hash.length];
-               };
-           };
-       };
-   } Signature;
-
-   enum {
-       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-       fortezza_dms_RESERVED(20),
-       (255)
-   } ClientCertificateType;
-
-   opaque DistinguishedName<1..2^16-1>;
-
-   struct {
-       ClientCertificateType certificate_types<1..2^8-1>;
-       DistinguishedName certificate_authorities<0..2^16-1>;
-   } CertificateRequest;
-
-   struct { } ServerHelloDone;
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa: EncryptedPreMasterSecret;
-           case diffie_hellman: ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   } PreMasterSecret;
-
-   struct {
-       public-key-encrypted PreMasterSecret pre_master_secret;
-   } EncryptedPreMasterSecret;
-
-   enum { implicit, explicit } PublicValueEncoding;
-
-   struct {
-       select (PublicValueEncoding) {
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 68]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-           case implicit: struct {};
-           case explicit: opaque DH_Yc<1..2^16-1>;
-       } dh_public;
-   } ClientDiffieHellmanPublic;
-
-   struct {
-       Signature signature;
-   } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-   struct {
-       opaque verify_data[verify_data_length];
-   } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.2.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-      CipherSuite TLS_NULL_WITH_NULL_NULL               = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either any signature-capable certificate in the certificate
-   request message.
-
-      CipherSuite TLS_RSA_WITH_NULL_MD5                 = { 0x00,0x01 };
-      CipherSuite TLS_RSA_WITH_NULL_SHA                 = { 0x00,0x02 };
-      CipherSuite TLS_RSA_WITH_RC4_128_MD5              = { 0x00,0x04 };
-      CipherSuite TLS_RSA_WITH_RC4_128_SHA              = { 0x00,0x05 };
-      CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA         = { 0x00,0x0A };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x35 };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 69]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   parameters are signed by a a signature-capable certificate, which has
-   been signed by the CA. The signing algorithm used is specified after
-   the DH or DHE parameter. The server can request any signature-capable
-   certificate from the client for client authentication or it may
-   request a Diffie-Hellman certificate. Any Diffie-Hellman certificate
-   provided by the client must use the parameters (group and generator)
-   described by the server.
-
-
-      CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x0D };
-      CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x10 };
-      CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x13 };
-      CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x16 };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks.  Using
-   this mode therefore is of limited use: These ciphersuites MUST NOT be
-   used by TLS 1.2 implementations unless the application layer has
-   specifically requested to allow anonymous key exchange.  (Anonymous
-   key exchange may sometimes be acceptable, for example, to support
-   opportunistic encryption when no set-up for authentication is in
-   place, or when TLS is used as part of more complex security protocols
-   that have other means to ensure authentication.)
-
-      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
-      CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-   SSLv3, TLS 1.0, and TLS 1.1 supported DES and IDEA. DES had a 56-bit
-   key which is too weak for modern use. Triple-DES (3DES) has an
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 70]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   effective key strength of 112 bits and is still acceptable.  IDEA and
-   is no longer in wide use. Cipher suites using RC2, DES, and IDEA are
-   hereby deprecated for TLS 1.2. TLS 1.2 implementations MUST NOT
-   negotiate these cipher suites in TLS 1.2 mode. However, for backward
-   compatibility they may be offered in the ClientHello for use with TLS
-   1.0 or SSLv3 only servers. TLS 1.2 clients MUST check that the server
-   did not choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-   CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA             = { 0x00,0x07 };
-   CipherSuite TLS_RSA_WITH_DES_CBC_SHA              = { 0x00,0x09 };
-   CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA           = { 0x00,0x0C };
-   CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA           = { 0x00,0x0F };
-   CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA          = { 0x00,0x15 };
-   CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA          = { 0x00,0x12 };
-   CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA          = { 0x00,0x1A };
-
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.2 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.2 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.2 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-      CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5        = { 0x00,0x03 };
-      CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    = { 0x00,0x06 };
-      CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     = { 0x00,0x08 };
-      CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x0B };
-      CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x0E };
-      CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
-      CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
-      CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    = { 0x00,0x17 };
-      CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
-
-   New cipher suite values are assigned by IANA as described in Section
-   12.
-
-   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 71]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-   enum { null(0), (255) } CompressionMethod;
-
-   enum { server, client } ConnectionEnd;
-
-   enum { tls_prf_sha256 } PRFAlgorithm;
-
-   enum { null, rc4, 3des, aes }
-   BulkCipherAlgorithm;
-
-   enum { stream, block, aead } CipherType;
-
-   enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
-     hmac_sha512} MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-   struct {
-       ConnectionEnd          entity;
-       PRFAlgorithm           prf_algorithm;
-       BulkCipherAlgorithm    bulk_cipher_algorithm;
-       CipherType             cipher_type;
-       uint8                  enc_key_length;
-       uint8                  block_length;
-       uint8                  fixed_iv_length;
-       uint8                  record_iv_length;
-       MACAlgorithm           mac_algorithm;
-       uint8                  mac_length;
-       uint8                  mac_key_length;
-       CompressionMethod      compression_algorithm;
-       opaque                 master_secret[48];
-       opaque                 client_random[32];
-       opaque                 server_random[32];
-   } SecurityParameters;
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 72]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-      AES is a widely used symmetric encryption algorithm.  AES is a
-      block cipher with a 128, 192, or 256 bit keys and a 16 byte block
-      size. [AES] TLS currently only supports the 128 and 256 bit key
-      sizes.
-
-   application protocol
-      An application protocol is a protocol that normally layers
-      directly on top of the transport layer (e.g., TCP/IP). Examples
-      include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-      See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-      A symmetric encryption algorithm that simultaneously provides
-      confidentiality and message integrity.
-
-   authentication
-      Authentication is the ability of one entity to determine the
-      identity of another entity.
-
-   block cipher
-      A block cipher is an algorithm that operates on plaintext in
-      groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-      A symmetric encryption algorithm used to encrypt large quantities
-      of data.
-
-   cipher block chaining (CBC)
-      CBC is a mode in which every plaintext block encrypted with a
-      block cipher is first exclusive-ORed with the previous ciphertext
-      block (or, in the case of the first block, with the initialization
-      vector). For decryption, every block is first decrypted, then
-      exclusive-ORed with the previous ciphertext block (or IV).
-
-   certificate
-      As part of the X.509 protocol (a.k.a. ISO Authentication
-      framework), certificates are assigned by a trusted Certificate
-      Authority and provide a strong binding between a party's identity
-      or some other attributes and its public key.
-
-   client
-      The application entity that initiates a TLS connection to a
-      server. This may or may not imply that the client initiated the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 73]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      underlying transport connection. The primary operational
-      difference between the server and client is that the server is
-      generally authenticated, while the client is only optionally
-      authenticated.
-
-   client write key
-      The key used to encrypt data written by the client.
-
-   client write MAC key
-      The secret data used to authenticate data written by the client.
-
-   connection
-      A connection is a transport (in the OSI layering model definition)
-      that provides a suitable type of service. For TLS, such
-      connections are peer-to-peer relationships. The connections are
-      transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-      DES is a very widely used symmetric encryption algorithm. DES is a
-      block cipher with a 56 bit key and an 8 byte block size. Note that
-      in TLS, for key generation purposes, DES is treated as having an 8
-      byte key length (64 bits), but it still only provides 56 bits of
-      protection. (The low bit of each key byte is presumed to be set to
-      produce odd parity in that key byte.) DES can also be operated in
-      a mode where three independent keys and three encryptions are used
-      for each block of data; this uses 168 bits of key (24 bytes in the
-      TLS key generation method) and provides the equivalent of 112 bits
-      of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-      A standard for digital signing, including the Digital Signing
-      Algorithm, approved by the National Institute of Standards and
-      Technology, defined in NIST FIPS PUB 186, "Digital Signature
-      Standard", published May, 1994 by the U.S. Dept. of Commerce.
-      [DSS]
-
-   digital signatures
-      Digital signatures utilize public key cryptography and one-way
-      hash functions to produce a signature of the data that can be
-      authenticated, and is difficult to forge or repudiate.
-
-   handshake
-      An initial negotiation between client and server that establishes
-      the parameters of their transactions.
-
-   Initialization Vector (IV)
-      When a block cipher is used in CBC mode, the initialization vector
-      is exclusive-ORed with the first plaintext block prior to
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 74]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      encryption.
-
-   IDEA
-      A 64-bit block cipher designed by Xuejia Lai and James Massey.
-      [IDEA]
-
-   Message Authentication Code (MAC)
-      A Message Authentication Code is a one-way hash computed from a
-      message and some secret data. It is difficult to forge without
-      knowing the secret data. Its purpose is to detect if the message
-      has been altered.
-
-   master secret
-      Secure secret data used for generating encryption keys, MAC
-      secrets, and IVs.
-
-   MD5
-      MD5 is a secure hashing function that converts an arbitrarily long
-      data stream into a hash of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-      A class of cryptographic techniques employing two-key ciphers.
-      Messages encrypted with the public key can only be decrypted with
-      the associated private key. Conversely, messages signed with the
-      private key can be verified with the public key.
-
-   one-way hash function
-      A one-way transformation that converts an arbitrary amount of data
-      into a fixed-length hash. It is computationally hard to reverse
-      the transformation or to find collisions. MD5 and SHA are examples
-      of one-way hash functions.
-
-   RC2
-      A block cipher developed by Ron Rivest, described in [RC2].
-
-   RC4
-      A stream cipher invented by Ron Rivest. A compatible cipher is
-      described in [SCH].
-
-   RSA
-      A very widely used public-key algorithm that can be used for
-      either encryption or digital signing. [RSA]
-
-   server
-      The server is the application entity that responds to requests for
-      connections from clients. See also under client.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 75]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   session
-      A TLS session is an association between a client and a server.
-      Sessions are created by the handshake protocol. Sessions define a
-      set of cryptographic security parameters that can be shared among
-      multiple connections. Sessions are used to avoid the expensive
-      negotiation of new security parameters for each connection.
-
-   session identifier
-      A session identifier is a value generated by a server that
-      identifies a particular session.
-
-   server write key
-      The key used to encrypt data written by the server.
-
-   server write MAC key
-      The secret data used to authenticate data written by the server.
-
-   SHA
-      The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-      produces a 20-byte output. Note that all references to SHA
-      actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-      Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-      SSL Version 3.0
-
-   stream cipher
-      An encryption algorithm that converts a key into a
-      cryptographically strong keystream, which is then exclusive-ORed
-      with the plaintext.
-
-   symmetric cipher
-      See bulk cipher.
-
-   Transport Layer Security (TLS)
-      This protocol; also, the Transport Layer Security working group of
-      the Internet Engineering Task Force (IETF). See "Comments" at the
-      end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 76]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Appendix C. CipherSuite Definitions
-
-CipherSuite                             Key          Cipher      Hash
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_CBC_SHA            RSA            AES_256_CBC  SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-
-
-                     Key      Expanded     IV    Block
-Cipher       Type  Material Key Material   Size   Size
-
-NULL         Stream   0          0         0     N/A
-RC4_128      Stream  16         16         0     N/A
-3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-      Indicates whether this is a stream cipher or a block cipher
-      running in CBC mode.
-
-   Key Material
-      The number of bytes from the key_block that are used for
-      generating the write keys.
-
-   Expanded Key Material
-      The number of bytes actually fed into the encryption algorithm.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 77]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   IV Size
-      The amount of data needed to be generated for the initialization
-      vector. Zero for stream ciphers; equal to the block size for block
-      ciphers (this is equal to SecurityParameters.record_iv_length).
-
-   Block Size
-      The amount of data a block cipher enciphers in one chunk; a block
-      cipher running in CBC mode can only encrypt an even multiple of
-      its block size.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 78]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably SHA-1, are acceptable,
-   but cannot provide more security than the size of the random number
-   generator state.
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-D.4 Implementation Pitfalls
-
-   Implementation experience has shown that certain parts of earlier TLS
-   specifications are not easy to understand, and have been a source of
-   interoperability and security problems. Many of these areas have been
-   clarified in this document, but this appendix contains a short list
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 79]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   of the most important things that require special attention from
-   implementors.
-
-   TLS protocol issues:
-
-   -  Do you correctly handle handshake messages that are fragmented
-      to multiple TLS records (see Section 6.2.1)? Including corner
-      cases like a ClientHello that is split to several small
-      fragments?
-
-   -  Do you ignore the TLS record layer version number in all TLS
-      records before ServerHello (see Appendix E.1)?
-
-   -  Do you handle TLS extensions in ClientHello correctly,
-      including omitting the extensions field completely?
-
-   -  Do you support renegotiation, both client and server initiated?
-      While renegotiation is an optional feature, supporting
-      it is highly recommended.
-
-   -  When the server has requested a client certificate, but no
-      suitable certificate is available, do you correctly send
-      an empty Certificate message, instead of omitting the whole
-      message (see Section 7.4.6)?
-
-   Cryptographic details:
-
-   -  In RSA-encrypted Premaster Secret,  do you correctly send and
-      verify the version number? When an error is encountered, do
-      you continue the handshake to avoid the Bleichenbacher
-      attack (see Section 7.4.7.1)?
-
-   -  What countermeasures do you use to prevent timing attacks against
-      RSA decryption and signing operations (see Section 7.4.7.1)?
-
-   -  When verifying RSA signatures, do you accept both NULL and
-      missing parameters (see Section 4.7)? Do you verify that the
-      RSA padding doesn't have additional data after the hash value?
-      [FI06]
-
-   -  When using Diffie-Hellman key exchange, do you correctly strip
-      leading zero bytes from the negotiated key (see Section 8.1.2)?
-
-   -  Does your TLS client check that the Diffie-Hellman parameters
-      sent by the server are acceptable (see Section F.1.1.3)?
-
-   -  How do you generate unpredictable IVs for CBC mode ciphers
-      (see Section 6.2.3.2)?
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 80]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   -  How do you address CBC mode timing attacks (Section 6.2.3.2)?
-
-   -  Do you use a strong and, most importantly, properly seeded
-      random number generator (see Appendix D.1) for generating the
-      premaster secret (for RSA key exchange), Diffie-Hellman private
-      values, the DSA "k" parameter, and other security-critical
-      values?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 81]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Appendix E. Backward Compatibility
-
-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client support the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version. If the server does not support this
-   version, it will respond with ServerHello containing an older version
-   number. If the client agrees to use this version, the negotiation
-   will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing version number
-   smaller than the highest supported version. If the server wishes to
-   negotiate with old clients, it will proceed as appropriate for the
-   highest version supported by the server that is not greater than
-   ClientHello.client_version. For example, if the server supports TLS
-   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing
-   to use) only versions greater than client_version, it MUST send a
-   "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   Note: some server implementations are known to implement version
-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 82]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   that simply close the connection when the client offers a version
-   newer than TLS 1.0. Also, it is known that some servers will refuse
-   connection if any TLS extensions are included in ClientHello.
-   Interoperability with such buggy servers is a complex topic beyond
-   the scope of this document, and may require multiple connection
-   attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed). Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number. Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version. No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2 Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
-   contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS ciphersuites in the
-   CIPHER-SPECS-DATA field as described below.
-
-   Warning: The ability to send version 2.0 CLIENT-HELLO messages will
-   be phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-   However, even TLS servers that do not support SSL 2.0 MAY accept
-   version 2.0 CLIENT-HELLO messages. The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions. Note that this message MUST be sent directly on the wire,
-   not wrapped as a TLS record. For the purposes of calculating Finished
-   and CertificateVerify, the msg_length field is not considered to be a
-   part of the handshake message.
-
-      uint8 V2CipherSpec[3];
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 83]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-      struct {
-          uint16 msg_length;
-          uint8 msg_type;
-          Version version;
-          uint16 cipher_spec_length;
-          uint16 session_id_length;
-          uint16 challenge_length;
-          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-          opaque session_id[V2ClientHello.session_id_length];
-          opaque challenge[V2ClientHello.challenge_length;
-      } V2ClientHello;
-
-   msg_length
-      The highest bit MUST be 1; the remaining bits contain the length
-      of the following data in bytes.
-
-   msg_type
-      This field, in conjunction with the version field, identifies a
-      version 2 client hello message. The value MUST be one (1).
-
-   version
-      Equal to ClientHello.client_version.
-
-   cipher_spec_length
-      This field is the total length of the field cipher_specs. It
-      cannot be zero and MUST be a multiple of the V2CipherSpec length
-      (3).
-
-   session_id_length
-      This field MUST have a value of zero for a client that claims to
-      support TLS 1.2.
-
-   challenge_length
-      The length in bytes of the client's challenge to the server to
-      authenticate itself. Historically, permissible values are between
-      16 and 32 bytes inclusive. When using the SSLv2 backward
-      compatible handshake the client SHOULD use a 32 byte challenge.
-
-   cipher_specs
-      This is a list of all CipherSpecs the client is willing and able
-      to use. In addition to the 2.0 cipher specs defined in [SSL2],
-      this includes the TLS cipher suites normally sent in
-      ClientHello.cipher_suites, each cipher suite prefixed by a zero
-      byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
-      {0x00,0x00,0x0A}.
-
-   session_id
-      This field MUST be empty.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 84]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   challenge
-      Corresponds to ClientHello.random. If the challenge length is less
-      than 32, the TLS server will pad the data with leading (note: not
-      trailing) zero bytes to make it 32 bytes long.
-
-   Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.3. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   MUST use special PKCS#1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
-   the right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).
-
-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
-   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
-   padding bytes are 0x03. If they are not, the server SHOULD generate a
-   random value for SECRET-KEY-DATA, and continue the handshake (which
-   will eventually fail since the keys will not match).  Note that
-   reporting the error situation to the client could make the server
-   vulnerable to attacks described in [BLEI].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 85]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC keys (see
-   Sections 7.4.9 and 6.3). By sending a correct finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using Diffie-Hellman
-   for key exchange. The server's public parameters are contained in the
-   server key exchange message and the client's are sent in the client
-   key exchange message. Eavesdroppers who do not know the private
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 86]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   values should not be able to find the Diffie-Hellman result (i.e. the
-   pre_master_secret).
-
-   Warning: Completely anonymous connections only provide protection
-   against passive eavesdropping. Unless an independent tamper-proof
-   channel is used to verify that the finished messages were not
-   replaced by an attacker, server authentication is required in
-   environments where active man-in-the-middle attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key. TLS
-   users desiring Perfect Forward Secrecy should use DHE cipher suites.
-   The damage done by exposure of a private key can be limited by
-   changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from all preceding handshake messages. These
-   handshake messages include the server certificate, which binds the
-   signature to the server, and ServerHello.random, which binds the
-   signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 87]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly, therefore the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE ciphersuites.
-
-   Because TLS allows the server to provide arbitrary DH groups, the
-   client should verify that the DH group is of suitable size as defined
-   by local policy. The client SHOULD also verify that the DH public
-   exponent appears to be of adequate size. [KEYSIZ] provides a useful
-   guide to the strength of various group sizes.  The server MAY choose
-   to assist the client by providing a known group, such as those
-   defined in [IKEALG] or [MODP]. These can be verified by simple
-   comparison.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Altering
-   the padding of the least significant 8 bytes of the PKCS padding does
-   not impact security for the size of the signed hashes and RSA key
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 88]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   lengths used in the protocol, since this is essentially equivalent to
-   increasing the input block size by 8 bytes.
-
-F.1.3. Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC keys are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations.
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC key, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 89]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64 bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC keys. Similarly, the server-write and
-   client-write keys are independent, so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
-   Note: MAC keys may be larger than encryption keys, so messages can
-   remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-   [CBCATT] describes a chosen plaintext attack on TLS that depends on
-   knowing the IV for a record. Previous versions of TLS [TLS1.0] used
-   the CBC residue of the previous record as the IV and therefore
-   enabled this attack. This version uses an explicit IV in order to
-   protect against this attack.
-
-F.4. Security of Composite Cipher Modes
-
-   TLS secures transmitted application data via the use of symmetric
-   encryption and authentication functions defined in the negotiated
-   ciphersuite.  The objective is to protect both the integrity and
-   confidentiality of the transmitted data from malicious actions by
-   active attackers in the network.  It turns out that the order in
-   which encryption and authentication functions are applied to the data
-   plays an important role for achieving this goal [ENCAUTH].
-
-   The most robust method, called encrypt-then-authenticate, first
-   applies encryption to the data and then applies a MAC to the
-   ciphertext.  This method ensures that the integrity and
-   confidentiality goals are obtained with ANY pair of encryption and
-   MAC functions, provided that the former is secure against chosen
-   plaintext attacks and that the MAC is secure against chosen-message
-   attacks.  TLS uses another method, called authenticate-then-encrypt,
-   in which first a MAC is computed on the plaintext and then the
-   concatenation of plaintext and MAC is encrypted.  This method has
-   been proven secure for CERTAIN combinations of encryption functions
-   and MAC functions, but it is not guaranteed to be secure in general.
-   In particular, it has been shown that there exist perfectly secure
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 90]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   encryption functions (secure even in the information-theoretic sense)
-   that combined with any secure MAC function, fail to provide the
-   confidentiality goal against an active attack.  Therefore, new
-   ciphersuites and operation modes adopted into TLS need to be analyzed
-   under the authenticate-then-encrypt method to verify that they
-   achieve the stated integrity and confidentiality goals.
-
-   Currently, the security of the authenticate-then-encrypt method has
-   been proven for some important cases.  One is the case of stream
-   ciphers in which a computationally unpredictable pad of the length of
-   the message, plus the length of the MAC tag, is produced using a
-   pseudo-random generator and this pad is xor-ed with the concatenation
-   of plaintext and MAC tag.  The other is the case of CBC mode using a
-   secure block cipher.  In this case, security can be shown if one
-   applies one CBC encryption pass to the concatenation of plaintext and
-   MAC and uses a new, independent, and unpredictable IV for each new
-   pair of plaintext and MAC.  In versions of TLS prior to 1.1, CBC mode
-   was used properly EXCEPT that it used a predictable IV in the form of
-   the last block of the previous ciphertext.  This made TLS open to
-   chosen plaintext attacks.  This version of the protocol is immune to
-   those attacks.  For exact details in the encryption modes proven
-   secure, see [ENCAUTH].
-
-F.5 Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption. However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections. In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6 Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 91]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   cryptographic functions should be used. Short public keys and
-   anonymous servers should be used with great caution. Implementations
-   and users must be careful when deciding which certificates and
-   certificate authorities are acceptable; a dishonest certificate
-   authority can do tremendous damage.
-
-Changes in This Version
-
-   [RFC Editor: Please delete this]
-
-   - SSLv2 backward compatibility downgraded to MAY
-
-   - Altered DSA hash rules to more closely match FIPS186-3 and
-     PKIX, plus remove OID restriction.
-
-   - verify_length no longer in SecurityParameters
-
-   - Moved/cleaned up cert selection text for server cert
-     when signature_algorithms is not specified.
-
-   - Other editorial changes.
-
-Normative References
-
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   National Institute of Standards and Technology,
-            "Recommendation for the Triple Data Encryption Algorithm
-            (TDEA) Block Cipher", NIST Special Publication 800-67, May
-            2004.
-
-   [DES]    National Institute of Standards and Technology, "Data
-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication", RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 92]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1]  J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
-            Public Key Infrastructure Certificate and Certificate
-            Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, March 1998.
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2nd ed.", Published by John Wiley &
-            Sons, Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,
-            October 1998.
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "Authenticated Encryption", February 2007,
-            draft-mcgrew-auth-enc-02.txt.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            4302, December 2005.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
-            "Password Interception in a SSL/TLS Channel", Advances in
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 93]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-            Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
-
-   [CCM]    "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/800-38C/
-            SP800-38C.pdf
-
-   [DSS-3]  NIST FIPS PUB 186-3 Draft, "Digital Signature Standard,"
-            National Institute of Standards and Technology, U.S.
-            Department of Commerce, 2006.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]    Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 4303, December 2005.
-
-   [FI06]   Hal Finney, "Bleichenbacher's RSA signature forgery based on
-            implementation error", ietf-openpgp@imc.org mailing list, 27
-            August 2006, http://www.imc.org/ietf-openpgp/mail-
-            archive/msg14307.html.
-
-   [GCM]    "NIST Special Publication 800-38D DRAFT (June, 2007):
-            Recommendation for Block Cipher Modes of Operation:
-            Galois/Counter Mode (GCM) and GMAC"
-
-   [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
-            Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
-            2005.
-
-   [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
-            Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
-            April 2004.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [MODP]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-            Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
-            3526, May 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 94]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
-            Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
-            Compression Methods", RFC 3749, May 2004.
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            4366, April 2006.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
-            Protocol", Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
-            Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
-            Suites for Transport Layer Security (TLS)", RFC 4492, May
-            2006.
-
-   [TLSEXT] Eastlake, D.E.,  "Transport Layer Security (TLS) Extensions:
-            Extension Definitions", July 2007, draft-ietf-tls-
-            rfc4366-bis-00.txt.
-
-   [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
-            authentication", draft-ietf-tls-openpgp-keys-11, July 2006.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 95]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for
-            Transport Layer Security (TLS)", RFC 4279, December 2005.
-
-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
-            1.1", RFC 4346, April, 2006.
-
-   [X501]   ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [XDR]    Eisler, M., "External Data Representation Standard", RFC
-            4506, May 2006.
-
-
-Credits
-
-   Working Group Chairs
-
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 96]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Alfred Hoenes
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   IBM
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 97]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-   <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 98]
-
-draft-ietf-tls-rfc4346-bis-07.txt  TLS                     November 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 99]
-
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-08.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-08.txt
deleted file mode 100644
index b18c3de33b..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-08.txt
+++ /dev/null
@@ -1,5660 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                Tim Dierks
-Obsoletes (if approved): RFC 3268, 4346, 4366                Independent
-Updates (if approved): RFC 4492                            Eric Rescorla
-Intended status:  Proposed Standard              Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-08.txt>     January 2008 (Expires July 2008)
-
-
-              The Transport Layer Security (TLS) Protocol
-                              Version 1.2
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2008).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 1]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Table of Contents
-
-   1.        Introduction                                             4
-   1.1.      Requirements Terminology                                 5
-   1.2.      Major Differences from TLS 1.1                           5
-   2.        Goals                                                    6
-   3.        Goals of This Document                                   6
-   4.        Presentation Language                                    7
-   4.1.      Basic Block Size                                         7
-   4.2.      Miscellaneous                                            7
-   4.3.      Vectors                                                  8
-   4.4.      Numbers                                                  9
-   4.5.      Enumerateds                                              9
-   4.6.      Constructed Types                                        10
-   4.6.1.    Variants                                                 10
-   4.7.      Cryptographic Attributes                                 11
-   4.8.      Constants                                                13
-   5.        HMAC and the Pseudorandom Function                       13
-   6.        The TLS Record Protocol                                  14
-   6.1.      Connection States                                        15
-   6.2.      Record layer                                             18
-   6.2.1.    Fragmentation                                            18
-   6.2.2.    Record Compression and Decompression                     19
-   6.2.3.    Record Payload Protection                                20
-   6.2.3.1.  Null or Standard Stream Cipher                           21
-   6.2.3.2.  CBC Block Cipher                                         21
-   6.2.3.3.  AEAD ciphers                                             23
-   6.3.      Key Calculation                                          24
-   7.        The TLS Handshaking Protocols                            25
-   7.1.      Change Cipher Spec Protocol                              26
-   7.2.      Alert Protocol                                           27
-   7.2.1.    Closure Alerts                                           28
-   7.2.2.    Error Alerts                                             29
-   7.3.      Handshake Protocol Overview                              32
-   7.4.      Handshake Protocol                                       35
-   7.4.1.    Hello Messages                                           36
-   7.4.1.1.  Hello Request                                            36
-   7.4.1.2.  Client Hello                                             37
-   7.4.1.3.  Server Hello                                             40
-   7.4.1.4   Hello Extensions                                         42
-   7.4.1.4.1 Signature Algorithms                                     43
-   7.4.2.    Server Certificate                                       45
-   7.4.3.    Server Key Exchange Message                              47
-   7.4.4.    Certificate Request                                      50
-   7.4.5     Server hello done                                        52
-   7.4.6.    Client Certificate                                       52
-   7.4.7.    Client Key Exchange Message                              54
-   7.4.7.1.  RSA Encrypted Premaster Secret Message                   54
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 2]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   7.4.7.2.  Client Diffie-Hellman Public Value                       57
-   7.4.8.    Certificate verify                                       57
-   7.4.9.    Finished                                                 58
-   8.        Cryptographic Computations                               60
-   8.1.      Computing the Master Secret                              60
-   8.1.1.    RSA                                                      61
-   8.1.2.    Diffie-Hellman                                           61
-   9.        Mandatory Cipher Suites                                  61
-   10.       Application Data Protocol                                61
-   11.       Security Considerations                                  61
-   12.       IANA Considerations                                      61
-   A.        Protocol Constant Values                                 64
-   A.1.      Record Layer                                             64
-   A.2.      Change Cipher Specs Message                              65
-   A.3.      Alert Messages                                           65
-   A.4.      Handshake Protocol                                       66
-   A.4.1.    Hello Messages                                           66
-   A.4.2.    Server Authentication and Key Exchange Messages          68
-   A.4.3.    Client Authentication and Key Exchange Messages          69
-   A.4.4.    Handshake Finalization Message                           70
-   A.5.      The Cipher Suite                                         70
-   A.6.      The Security Parameters                                  73
-   B.        Glossary                                                 75
-   C.        Cipher Suite Definitions                                 79
-   D.        Implementation Notes                                     81
-   D.1       Random Number Generation and Seeding                     81
-   D.2       Certificates and Authentication                          81
-   D.3       Cipher Suites                                            81
-   D.4       Implementation Pitfalls                                  81
-   E.        Backward Compatibility                                   84
-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0               84
-   E.2       Compatibility with SSL 2.0                               85
-   E.3.      Avoiding Man-in-the-Middle Version Rollback              87
-   F.        Security Analysis                                        88
-   F.1.      Handshake Protocol                                       88
-   F.1.1.    Authentication and Key Exchange                          88
-   F.1.1.1.  Anonymous Key Exchange                                   88
-   F.1.1.2.  RSA Key Exchange and Authentication                      89
-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication          89
-   F.1.2.    Version Rollback Attacks                                 90
-   F.1.3.    Detecting Attacks Against the Handshake Protocol         91
-   F.1.4.    Resuming Sessions                                        91
-   F.2.      Protecting Application Data                              91
-   F.3.      Explicit IVs                                             92
-   F.4.      Security of Composite Cipher Modes                       92
-   F.5       Denial of Service                                        93
-   F.6       Final Notes                                              93
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 3]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-   -  The connection is private. Symmetric cryptography is used for
-      data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for
-      this symmetric encryption are generated uniquely for each
-      connection and are based on a secret negotiated by another
-      protocol (such as the TLS Handshake Protocol). The Record Protocol
-      can also be used without encryption.
-
-   -  The connection is reliable. Message transport includes a message
-      integrity check using a keyed MAC. Secure hash functions (e.g.,
-      SHA, MD5, etc.) are used for MAC computations. The Record Protocol
-      can operate without a MAC, but is generally only used in this mode
-      while another protocol is using the Record Protocol as a transport
-      for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-   -  The peer's identity can be authenticated using asymmetric, or
-      public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-      authentication can be made optional, but is generally required for
-      at least one of the peers.
-
-   -  The negotiation of a shared secret is secure: the negotiated
-      secret is unavailable to eavesdroppers, and for any authenticated
-      connection the secret cannot be obtained, even by an attacker who
-      can place himself in the middle of the connection.
-
-   -  The negotiation is reliable: no attacker can modify the
-      negotiation communication without being detected by the parties to
-      the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS Protocol
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 4]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-   of protocols that run on top of TLS.
-
-1.1. Requirements Terminology
-
-   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 [REQ].
-
-1.2. Major Differences from TLS 1.1
-
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-   -  The MD5/SHA-1 combination in the PRF has been replaced with cipher
-      suite specified PRFs. All cipher suites in this document use
-      P_SHA256.
-
-   -  The MD5/SHA-1 combination in the digitally-signed element has been
-      replaced with a single hash.
-
-   -  Substantial cleanup to the clients and servers ability to specify
-      which hash and signature algorithms they will accept. Note that
-      this also relaxes some of the constraints on signature and hash
-      algorithms from previous versions of TLS.
-
-   -  Addition of support for authenticated encryption with additional
-      data modes.
-
-   -  TLS Extensions definition and AES Cipher Suites were merged in
-      from external [TLSEXT] and [TLSAES].
-
-   -  Tighter checking of EncryptedPreMasterSecret version numbers.
-
-   -  Tightened up a number of requirements.
-
-   -  Verify_data length now depends on the cipher suite (default is
-      still 12).
-
-   -  Cleaned up description of Bleichenbacher/Klima attack defenses.
-
-   -  Alerts MUST now be sent in many cases.
-   -  After a certificate_request, if no certificates are available,
-      clients now MUST send an empty certificate list.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 5]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   -  TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
-      cipher suite.
-
-   -  Added HMAC-SHA256 cipher suites
-
-   -  IDEA and DES are now deprecated.
-
-   -  Support for the SSLv2 backward-compatible hello is now a MAY, not
-      a SHOULD. This will probably become a SHOULD NOT in the future.
-
-   -  Added an Implementation Pitfalls sections
-
-   -  The usual clarifications and editorial work.
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-   1. Cryptographic security: TLS should be used to establish a secure
-      connection between two parties.
-
-   2. Interoperability: Independent programmers should be able to
-      develop applications utilizing TLS that can successfully exchange
-      cryptographic parameters without knowledge of one another's code.
-
-   3. Extensibility: TLS seeks to provide a framework into which new
-      public key and bulk encryption methods can be incorporated as
-      necessary. This will also accomplish two sub-goals: preventing the
-      need to create a new protocol (and risking the introduction of
-      possible new weaknesses) and avoiding the need to implement an
-      entire new security library.
-
-   4. Relative efficiency: Cryptographic operations tend to be highly
-      CPU intensive, particularly public key operations. For this
-      reason, the TLS protocol has incorporated an optional session
-      caching scheme to reduce the number of connections that need to be
-      established from scratch. Additionally, care has been taken to
-      reduce network activity.
-
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions). This
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 6]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e., 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-      value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-              ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 7]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-      T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-      opaque Datum[3];      /* three uninterpreted bytes */
-      Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream. The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length. A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-      T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two-byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17-byte vector of uint16 would be illegal).
-
-      opaque mandatory<300..400>;
-            /* length field is 2 bytes, cannot be empty */
-      uint16 longer<0..800>;
-            /* zero to 400 16-bit unsigned integers */
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 8]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-      uint8 uint16[2];
-      uint8 uint24[3];
-      uint8 uint32[4];
-      uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors. In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-      enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-      enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-      enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 9]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-      Color color = Color.blue;     /* overspecified, legal */
-      Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-      enum { low, medium, high } Amount;
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ...
-          Tn fn;
-      } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ....
-          Tn fn;
-          select (E) {
-              case e1: Te1;
-              case e2: Te2;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 10]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-              ....
-              case en: Ten;
-          } [[fv]];
-      } [[Tv]];
-
-   For example:
-
-      enum { apple, orange } VariantTag;
-      struct {
-          uint16 number;
-          opaque string<0..10>; /* variable length */
-      } V1;
-      struct {
-          uint32 number;
-          opaque string[10];    /* fixed length */
-      } V2;
-      struct {
-          select (VariantTag) { /* value of selector is implicit */
-              case apple: V1;   /* VariantBody, tag = apple */
-              case orange: V2;  /* VariantBody, tag = orange */
-          } variant_body;       /* optional label on variant */
-      } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, an
-
-      orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic Attributes
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 11]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
-   discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash
-   algorithms without parameters (which include SHA-1) the
-   DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but
-   implementations MUST accept both without parameters and with NULL
-   parameters. Note that earlier versions of TLS used a different RSA
-   signature scheme which did not include a DigestInfo encoding.
-
-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-      Dss-Sig-Value ::= SEQUENCE {
-          r INTEGER,
-          s INTEGER
-      }
-
-   Note: In current terminology, DSA refers to the Digital Signature
-   Algorithm and DSS refers to the NIST standard. For historical
-   reasons, this document uses DSS and DSA interchangeably
-   to refer to the DSA algorithm, as was done in SSLv3.
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and aead-ciphered
-   output is generally larger than the input in order to accomodate the
-   integrity check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the encryption
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1].
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 12]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   In the following example
-
-      stream-ciphered struct {
-          uint8 field1;
-          uint8 field2;
-          digitally-signed opaque hash[20];
-      } UserType;
-
-   the contents of hash are used as input for the signing algorithm, and
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes, would be equal to two bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   because the algorithm and key used for the signing are known prior to
-   encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-      struct {
-          uint8 f1;
-          uint8 f2;
-      } Example1;
-
-      Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-
-5. HMAC and the Pseudorandom Function
-
-   The TLS record layer uses a keyed Message Authentication Code (MAC)
-   to protect message integrity. The cipher suites defined in this
-   document use a construction known as HMAC, described in [HMAC], which
-   is based on a hash function. Other cipher suites MAY define their own
-   MAC constructions, if needed.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In this section, we define one PRF, based on HMAC. This PRF with the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 13]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   SHA-256 hash function is used for all cipher suites defined in this
-   document and in TLS documents published prior to this document when
-   TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
-   PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger
-   standard hash function.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-      P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                             HMAC_hash(secret, A(2) + seed) +
-                             HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-
-      A(0) = seed
-      A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA256 is being used to
-   create 80 bytes of data, it will have to be iterated three times
-   (through A(3)), creating 96 bytes of output data; the last 16 bytes
-   of the final iteration will then be discarded, leaving 80 bytes of
-   output data.
-
-   TLS's PRF is created by applying P_hash to the secret as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-      73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 14]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   higher-level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. New record type values are assigned
-   by IANA as described in Section 12.
-
-   Implementations MUST NOT send record types not defined in this
-   document unless negotiated by some extension.  If a TLS
-   implementation receives an unexpected record type, it MUST send an
-   unexpected_message alert.
-
-   Any protocol designed for use over TLS MUST be carefully designed to
-   deal with all possible attacks against it.  Note that because the
-   type and length of a record are not protected by encryption, care
-   SHOULD be taken to minimize the value of traffic analysis of these
-   values.
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, an encryption
-   algorithm, and a MAC algorithm. In addition, the parameters for these
-   algorithms are known: the MAC key and the bulk encryption keys for
-   the connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Change Cipher Spec can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state that has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-      Whether this entity is considered the "client" or the "server" in
-      this connection.
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 15]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   PRF algorithm
-      An algorithm used to generate keys from the master secret (see
-      Sections 5 and 6.3).
-
-   bulk encryption algorithm
-      An algorithm to be used for bulk encryption. This specification
-      includes the key size of this algorithm, whether it is a block,
-      stream, or AEAD cipher, the block size of the cipher (if
-      appropriate), and the lengths of explicit and implicit
-      initialization vectors (or nonces).
-
-   MAC algorithm
-      An algorithm to be used for message authentication. This
-      specification includes the size of the value returned by the MAC
-      algorithm.
-
-   compression algorithm
-      An algorithm to be used for data compression. This specification
-      must include all information the algorithm requires to do
-      compression.
-
-   master secret
-      A 48-byte secret shared between the two peers in the connection.
-
-   client random
-      A 32-byte value provided by the client.
-
-   server random
-      A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-      enum { server, client } ConnectionEnd;
-
-      enum { tls_prf_sha256 } PRFAlgorithm;
-
-      enum { null, rc4, 3des, aes }
-        BulkCipherAlgorithm;
-
-      enum { stream, block, aead } CipherType;
-
-      enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
-           hmac_sha512} MACAlgorithm;
-
-      /* The use of "sha" above is historical and denotes SHA-1 */
-
-      enum { null(0), (255) } CompressionMethod;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 16]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      /* The algorithms specified in CompressionMethod,
-         BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-      struct {
-          ConnectionEnd          entity;
-          PRFAlgorithm           prf_algorithm;
-          BulkCipherAlgorithm    bulk_cipher_algorithm;
-          CipherType             cipher_type;
-          uint8                  enc_key_length;
-          uint8                  block_length;
-          uint8                  fixed_iv_length;
-          uint8                  record_iv_length;
-          MACAlgorithm           mac_algorithm;
-          uint8                  mac_length;
-          uint8                  mac_key_length;
-          CompressionMethod      compression_algorithm;
-          opaque                 master_secret[48];
-          opaque                 client_random[32];
-          opaque                 server_random[32];
-      } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following six items (some of which are not required by all ciphers,
-   and are thus empty):
-
-      client write MAC key
-      server write MAC key
-      client write encryption key
-      server write encryption key
-      client write IV
-      server write IV
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-      The current state of the compression algorithm.
-
-   cipher state
-      The current state of the encryption algorithm. This will consist
-      of the scheduled key for that connection. For stream ciphers, this
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 17]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      will also contain whatever state information is necessary to allow
-      the stream to continue to encrypt or decrypt data.
-
-   MAC key
-      The MAC key for this connection, as generated above.
-
-   sequence number
-      Each connection state contains a sequence number, which is
-      maintained separately for read and write states. The sequence
-      number MUST be set to zero whenever a connection state is made the
-      active state. Sequence numbers are of type uint64 and may not
-      exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-      implementation would need to wrap a sequence number, it must
-      renegotiate instead. A sequence number is incremented after each
-      record: specifically, the first record transmitted under a
-      particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-      struct {
-          uint8 major;
-          uint8 minor;
-      } ProtocolVersion;
-
-      enum {
-          change_cipher_spec(20), alert(21), handshake(22),
-          application_data(23), (255)
-      } ContentType;
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          opaque fragment[TLSPlaintext.length];
-      } TLSPlaintext;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 18]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   type
-      The higher-level protocol used to process the enclosed fragment.
-
-   version
-      The version of the protocol being employed. This document
-      describes TLS Version 1.2, which uses the version { 3, 3 }. The
-      version value 3.3 is historical, deriving from the use of 3.1 for
-      TLS 1.0. (See Appendix A.1).  Note that a client that supports
-      multiple versions of TLS may not know what version will be
-      employed before it receives ServerHello.  See Appendix E for
-      discussion about what record layer version number should be
-      employed for ClientHello.
-
-   length
-      The length (in bytes) of the following TLSPlaintext.fragment.  The
-      length MUST NOT exceed 2^14.
-
-   fragment
-      The application data. This data is transparent and treated as an
-      independent block to be dealt with by the higher-level protocol
-      specified by the type field.
-
-   Implementations MUST NOT send zero-length fragments of Handshake,
-   Alert, or Change Cipher Spec content types. Zero-length fragments of
-   Application data MAY be sent as they are potentially useful as a
-   traffic analysis countermeasure.
-
-   Note: Data of different TLS Record layer content types MAY be
-   interleaved.  Application data is generally of lower precedence for
-   transmission than other content types.  However, records MUST be
-   delivered to the network in the same order as they are protected by
-   the record layer.  Recipients MUST receive and process interleaved
-   application layer traffic during handshakes subsequent to the first
-   one on a connection.
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 19]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-      struct {
-          ContentType type;       /* same as TLSPlaintext.type */
-          ProtocolVersion version;/* same as TLSPlaintext.version */
-          uint16 length;
-          opaque fragment[TLSCompressed.length];
-      } TLSCompressed;
-
-   length
-      The length (in bytes) of the following TLSCompressed.fragment.
-      The length MUST NOT exceed 2^14 + 1024.
-
-   fragment
-      The compressed form of TLSPlaintext.fragment.
-
-   Note: A CompressionMethod.null operation is an identity operation; no
-   fields are altered.
-
-   Implementation note: Decompression functions are responsible for
-   ensuring that messages cannot cause internal buffer overflows.
-
-6.2.3. Record Payload Protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          select (SecurityParameters.cipher_type) {
-              case stream: GenericStreamCipher;
-              case block:  GenericBlockCipher;
-              case aead:   GenericAEADCipher;
-          } fragment;
-      } TLSCiphertext;
-
-   type
-      The type field is identical to TLSCompressed.type.
-
-   version
-      The version field is identical to TLSCompressed.version.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 20]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   length
-      The length (in bytes) of the following TLSCiphertext.fragment.
-      The length MUST NOT exceed 2^14 + 2048.
-
-   fragment
-      The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-      stream-ciphered struct {
-          opaque content[TLSCompressed.length];
-          opaque MAC[SecurityParameters.mac_length];
-      } GenericStreamCipher;
-
-   The MAC is generated as:
-
-      MAC(MAC_write_key, seq_num +
-                            TLSCompressed.type +
-                            TLSCompressed.version +
-                            TLSCompressed.length +
-                            TLSCompressed.fragment);
-
-   where "+" denotes concatenation.
-
-   seq_num
-      The sequence number for this record.
-
-   MAC
-      The MAC algorithm specified by SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted,
-   and the MAC size is zero, implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   SecurityParameters.mac_length.
-
-6.2.3.2. CBC Block Cipher
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 21]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   For block ciphers (such as 3DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-      struct {
-          opaque IV[SecurityParameters.record_iv_length];
-          block-ciphered struct {
-              opaque content[TLSCompressed.length];
-              opaque MAC[SecurityParameters.mac_length];
-              uint8 padding[GenericBlockCipher.padding_length];
-              uint8 padding_length;
-          };
-      } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-      The Initialization Vector (IV) SHOULD be chosen at random, and
-      MUST be unpredictable. Note that in versions of TLS prior to 1.1,
-      there was no IV field, and the last ciphertext block of the
-      previous record (the "CBC residue") was used as the IV. This was
-      changed to prevent the attacks described in [CBCATT]. For block
-      ciphers, the IV length is of length
-      SecurityParameters.record_iv_length which is equal to the
-      SecurityParameters.block_size.
-
-   padding
-      Padding that is added to force the length of the plaintext to be
-      an integral multiple of the block cipher's block length. The
-      padding MAY be any length up to 255 bytes, as long as it results
-      in the TLSCiphertext.length being an integral multiple of the
-      block length. Lengths longer than necessary might be desirable to
-      frustrate attacks on a protocol that are based on analysis of the
-      lengths of exchanged messages. Each uint8 in the padding data
-      vector MUST be filled with the padding length value. The receiver
-      MUST check this padding and MUST use the bad_record_mac alert to
-      indicate padding errors.
-
-   padding_length
-      The padding length MUST be such that the total size of the
-      GenericBlockCipher structure is a multiple of the cipher's block
-      length. Legal values range from zero to 255, inclusive. This
-      length specifies the length of the padding field exclusive of the
-      padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of SecurityParameters.block_length, TLSCompressed.length,
-   SecurityParameters.mac_length, and padding_length.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 22]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   Example: If the block length is 8 bytes, the content length
-   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
-   then the length before padding is 82 bytes (this does not include the
-   IV. Thus, the padding length modulo 8 must be equal to 6 in order to
-   make the total length an even multiple of 8 bytes (the block length).
-   The padding length can be 6, 14, 22, and so on, through 254. If the
-   padding length were the minimum necessary, 6, the padding would be 6
-   bytes, each containing the value 6.  Thus, the last 8 octets of the
-   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
-   06 06, where xx is the last octet of the MAC.
-
-   Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
-   critical that the entire plaintext of the record be known before any
-   ciphertext is transmitted. Otherwise, it is possible for the attacker
-   to mount the attack described in [CBCATT].
-
-   Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
-   timing attack on CBC padding based on the time required to compute
-   the MAC. In order to defend against this attack, implementations MUST
-   ensure that record processing time is essentially the same whether or
-   not the padding is correct.  In general, the best way to do this is
-   to compute the MAC even if the padding is incorrect, and only then
-   reject the packet. For instance, if the pad appears to be incorrect,
-   the implementation might assume a zero-length pad and then compute
-   the MAC. This leaves a small timing channel, since MAC performance
-   depends to some extent on the size of the data fragment, but it is
-   not believed to be large enough to be exploitable, due to the large
-   block size of existing MACs and the small size of the timing signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-      struct {
-         opaque nonce_explicit[SecurityParameters.record_iv_length];
-         aead-ciphered struct {
-             opaque content[TLSCompressed.length];
-         };
-      } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD]. The key is either the
-   client_write_key or the server_write_key.  No MAC key is used.
-
-   Each AEAD cipher suite MUST specify how the nonce supplied to the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 23]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   AEAD operation is constructed, and what is the length of the
-   GenericAEADCipher.nonce_explicit part. In many cases, it is
-   appropriate to use the partially implicit nonce technique described
-   in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
-   the explicit part. In this case, the implicit part SHOULD be derived
-   from key_block as client_write_iv and server_write_iv (as described
-   in Section 6.3), and the explicit part is included in
-   GenericAEAEDCipher.nonce_explicit.
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   Where "+" denotes concatenation.
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  The length will generally be larger than
-   TLSCompressed.length, but by an amount that varies with the AEAD
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-      AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext,
-                                   additional_data)
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   nonce, the "additional_data", and the AEADEncrypted value. The output
-   is either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-      TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
-                                            AEADEncrypted,
-                                            additional_data)
-
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generates keys required
-   by the current connection state (see Appendix A.6) from the security
-   parameters provided by the handshake protocol.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 24]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   The master secret is expanded into a sequence of secure bytes, which
-   is then split to a client write MAC key, a server write MAC key, a
-   client write encryption key, and a server write encryption key. Each
-   of these is generated from the byte sequence in that order.  Unused
-   values are empty.  Some AEAD ciphers may additionally require a
-   client write IV and a server write IV (see Section 6.2.3.3).
-
-   When keys and MAC keys are generated, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-      key_block = PRF(SecurityParameters.master_secret,
-                      "key expansion",
-                      SecurityParameters.server_random +
-                      SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-      client_write_MAC_key[SecurityParameters.mac_key_length]
-      server_write_MAC_key[SecurityParameters.mac_key_length]
-      client_write_key[SecurityParameters.enc_key_length]
-      server_write_key[SecurityParameters.enc_key_length]
-      client_write_IV[SecurityParameters.fixed_iv_length]
-      server_write_IV[SecurityParameters.fixed_iv_length]
-
-   The client_write_IV and server_write_IV are only generated for
-   implicit nonce techniques as described in Section 3.2.1 of [AEAD].
-
-   Implementation note: The currently defined cipher suite which
-   requires the most material is AES_256_CBC_SHA. It requires 2 x 32
-   byte keys and 2 x 20 byte MAC keys, for a total 104 bytes of key
-   material.
-
-7. The TLS Handshaking Protocols
-
-   TLS has three subprotocols that are used to allow peers to agree upon
-   security parameters for the record layer, to authenticate themselves,
-   to instantiate negotiated security parameters, and to report error
-   conditions to each other.
-
-   The Handshake Protocol is responsible for negotiating a session,
-   which consists of the following items:
-
-   session identifier
-      An arbitrary byte sequence chosen by the server to identify an
-      active or resumable session state.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 25]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   peer certificate
-      X509v3 [PKIX] certificate of the peer. This element of the state
-      may be null.
-
-   compression method
-      The algorithm used to compress data prior to encryption.
-
-   cipher spec
-      Specifies the bulk data encryption algorithm (such as null, DES,
-      etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
-      cryptographic attributes such as the mac_length. (See Appendix A.6
-      for formal definition.)
-
-   master secret
-      48-byte secret shared between the client and server.
-
-   is resumable
-      A flag indicating whether the session can be used to initiate new
-      connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-      struct {
-          enum { change_cipher_spec(1), (255) } type;
-      } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 26]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g., if it has to perform a time consuming public
-   key operation). Thus, a small window of time, during which the
-   recipient must buffer the data, MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier MUST be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-      enum { warning(1), fatal(2), (255) } AlertLevel;
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed_RESERVED(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          no_certificate_RESERVED(41),
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-          export_restriction_RESERVED(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 27]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-          no_renegotiation(100),
-          unsupported_extension(110),
-          (255)
-      } AlertDescription;
-
-      struct {
-          AlertLevel level;
-          AlertDescription description;
-      } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-   pending data before destroying the transport.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 28]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-7.2.2. Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed.
-
-   Whenever an implementation encounters a condition which is defined as
-   a fatal alert, it MUST send the appropriate alert prior to closing
-   the connection. For all errors where an alert level is not explicitly
-   specified, the sending party MAY determine at its discretion whether
-   to treat this as a fatal error or not. If the implementation chooses
-   to send an alert but intends to close the connection immediately
-   afterwards, it MUST send that alert at the fatal alert level.
-
-   If an alert with a level of warning is sent and received, generally
-   the connection can continue normally.  If the receiving party decides
-   not to proceed with the connection (e.g., after having received a
-   no_renegotiation alert that it is not willing to accept), it SHOULD
-   send a fatal alert to terminate the connection. Given this, the
-   sending party cannot, in general, know how the receiving party will
-   behave. Therefore, warning alerts are not very useful when the
-   sending party wants to continue the connection, and thus are
-   sometimes omitted. For example, if a peer decides to accept an
-   expired certificate (perhaps after confirming this with the user) and
-   wants to continue the connection, it would not generally send a
-   certificate_expired alert.
-
-   The following error alerts are defined:
-
-   unexpected_message
-      An inappropriate message was received. This alert is always fatal
-      and should never be observed in communication between proper
-      implementations.
-
-   bad_record_mac
-      This alert is returned if a record is received with an incorrect
-      MAC. This alert also MUST be returned if an alert is sent because
-      a TLSCiphertext decrypted in an invalid way: either it wasn't an
-      even multiple of the block length, or its padding values, when
-      checked, weren't correct. This message is always fatal and should
-      never be observed in communication between proper implementations
-      (except when messages were corrupted in the network).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 29]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   decryption_failed_RESERVED
-      This alert was used in some earlier versions of TLS, and may have
-      permitted certain attacks against the CBC mode [CBCATT].  It MUST
-      NOT be sent by compliant implementations.
-
-   record_overflow
-      A TLSCiphertext record was received that had a length more than
-      2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-      with more than 2^14+1024 bytes. This message is always fatal and
-      should never be observed in communication between proper
-      implementations (except when messages were corrupted in the
-      network).
-
-   decompression_failure
-      The decompression function received improper input (e.g., data
-      that would expand to excessive length). This message is always
-      fatal and should never be observed in communication between proper
-      implementations.
-
-   handshake_failure
-      Reception of a handshake_failure alert message indicates that the
-      sender was unable to negotiate an acceptable set of security
-      parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-      This alert was used in SSLv3 but not any version of TLS.  It MUST
-      NOT be sent by compliant implementations.
-
-   bad_certificate
-      A certificate was corrupt, contained signatures that did not
-      verify correctly, etc.
-
-   unsupported_certificate
-      A certificate was of an unsupported type.
-
-   certificate_revoked
-      A certificate was revoked by its signer.
-
-   certificate_expired
-      A certificate has expired or is not currently valid.
-
-   certificate_unknown
-      Some other (unspecified) issue arose in processing the
-      certificate, rendering it unacceptable.
-
-   illegal_parameter
-      A field in the handshake was out of range or inconsistent with
-      other fields. This message is always fatal.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 30]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   unknown_ca
-      A valid certificate chain or partial chain was received, but the
-      certificate was not accepted because the CA certificate could not
-      be located or couldn't be matched with a known, trusted CA.  This
-      message is always fatal.
-
-   access_denied
-      A valid certificate was received, but when access control was
-      applied, the sender decided not to proceed with negotiation.  This
-      message is always fatal.
-
-   decode_error
-      A message could not be decoded because some field was out of the
-      specified range or the length of the message was incorrect. This
-      message is always fatal and should never be observed in
-      communication between proper implementations (except when messages
-      were corrupted in the network).
-
-
-   decrypt_error
-      A handshake cryptographic operation failed, including being unable
-      to correctly verify a signature or validate a finished message.
-      This message is always fatal.
-
-   export_restriction_RESERVED
-      This alert was used in some earlier versions of TLS.  It MUST NOT
-      be sent by compliant implementations.
-
-   protocol_version
-      The protocol version the client has attempted to negotiate is
-      recognized but not supported. (For example, old protocol versions
-      might be avoided for security reasons). This message is always
-      fatal.
-
-   insufficient_security
-      Returned instead of handshake_failure when a negotiation has
-      failed specifically because the server requires ciphers more
-      secure than those supported by the client. This message is always
-      fatal.
-
-   internal_error
-      An internal error unrelated to the peer or the correctness of the
-      protocol (such as a memory allocation failure) makes it impossible
-      to continue. This message is always fatal.
-
-   user_canceled
-      This handshake is being canceled for some reason unrelated to a
-      protocol failure. If the user cancels an operation after the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 31]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      handshake is complete, just closing the connection by sending a
-      close_notify is more appropriate. This alert should be followed by
-      a close_notify. This message is generally a warning.
-
-   no_renegotiation
-      Sent by the client in response to a hello request or by the server
-      in response to a client hello after initial handshaking.  Either
-      of these would normally lead to renegotiation; when that is not
-      appropriate, the recipient should respond with this alert.  At
-      that point, the original requester can decide whether to proceed
-      with the connection. One case where this would be appropriate is
-      where a server has spawned a process to satisfy a request; the
-      process might receive security parameters (key length,
-      authentication, etc.) at startup and it might be difficult to
-      communicate changes to these parameters after that point. This
-      message is always a warning.
-
-   unsupported_extension
-      sent by clients that receive an extended server hello containing
-      an extension that they did not put in the corresponding client
-      hello. This message is always fatal.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not.  However, all messages that are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New Alert values are assigned by IANA as described in Section 12.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-   -  Exchange hello messages to agree on algorithms, exchange random
-      values, and check for session resumption.
-
-   -  Exchange the necessary cryptographic parameters to allow the
-      client and server to agree on a premaster secret.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 32]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   -  Exchange certificates and cryptographic information to allow the
-      client and server to authenticate themselves.
-
-   -  Generate a master secret from the premaster secret and exchanged
-      random values.
-
-   -  Provide security parameters to the record layer.
-
-   -  Allow the client and server to verify that their peer has
-      calculated the same security parameters and that the handshake
-      occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man in the middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support. The protocol has been designed to
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection. The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require. The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 46 bytes upwards.
-
-   Following the hello messages, the server will send its certificate,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 33]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g., if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Next,
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client MUST send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify possession of the private
-   key in the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-   Cipher Spec. At this point, the handshake is complete, and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other than
-   TLS_NULL_WITH_NULL_NULL is established).
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 34]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   always sent.
-
-   Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-   independent TLS Protocol content type, and is not actually a TLS
-   handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 35]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-          } body;
-      } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message that is not bound by these ordering rules is the Hello
-   Request message, which can be sent at any time, but which SHOULD be
-   ignored by the client if it arrives in the middle of a handshake.
-
-   New Handshake message types are assigned by IANA as described in
-   Section 12.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello Request
-
-   When this message will be sent:
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 36]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-
-      Hello request is a simple notification that the client should
-      begin the negotiation process anew by sending a client hello
-      message when convenient. This message is not intended to establish
-      which side is the client or server but merely to initiate a new
-      negotiation. Servers SHOULD NOT send a HelloRequest immediately
-      upon the client's initial connection.  It is the client's job to
-      send a ClientHello at that time.
-
-      This message will be ignored by the client if the client is
-      currently negotiating a session. This message may be ignored by
-      the client if it does not wish to renegotiate a session, or the
-      client may, if it wishes, respond with a no_renegotiation alert.
-      Since handshake messages are intended to have transmission
-      precedence over application data, it is expected that the
-      negotiation will begin before no more than a few records are
-      received from the client. If the server sends a hello request but
-      does not receive a client hello in response, it may close the
-      connection with a fatal alert.
-
-      After sending a hello request, servers SHOULD NOT repeat the
-      request until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-
-      struct { } HelloRequest;
-
-   Note: This message MUST NOT be included in the message hashes that
-   are maintained throughout the handshake and used in the finished
-   messages and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-
-      When a client first connects to a server it is required to send
-      the client hello as its first message. The client can also send a
-      client hello in response to a hello request or on its own
-      initiative in order to renegotiate the security parameters in an
-      existing connection.
-
-   Structure of this message:
-
-      The client hello message includes a random structure, which is
-      used later in the protocol.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 37]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-         struct {
-             uint32 gmt_unix_time;
-             opaque random_bytes[28];
-         } Random;
-
-      gmt_unix_time
-         The current time and date in standard UNIX 32-bit format
-         (seconds since the midnight starting Jan 1, 1970, GMT, ignoring
-         leap seconds) according to the sender's internal clock. Clocks
-         are not required to be set correctly by the basic TLS Protocol;
-         higher-level or application protocols may define additional
-         requirements.
-
-      random_bytes
-         28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable-length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-   connection, or from another currently active connection. The second
-   option is useful if the client only wishes to update the random
-   structures and derived values of a connection, and the third option
-   makes it possible to establish several independent secure connections
-   without repeating the full handshake protocol. These independent
-   connections may occur sequentially or simultaneously; a SessionID
-   becomes valid when the handshake negotiating it completes with the
-   exchange of Finished messages and persists until it is removed due to
-   aging or because a fatal error was encountered on a connection
-   associated with the session. The actual contents of the SessionID are
-   defined by the server.
-
-      opaque SessionID<0..32>;
-
-   Warning: Because the SessionID is transmitted without encryption or
-   immediate MAC protection, servers MUST NOT place confidential
-   information in session identifiers or let the contents of fake
-   session identifiers cause any breach of security. (Note that the
-   content of the handshake as a whole, including the SessionID, is
-   protected by the Finished messages exchanged at the end of the
-   handshake.)
-
-   The cipher suite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each cipher suite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 38]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-      uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-      enum { null(0), (255) } CompressionMethod;
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-2>;
-          CompressionMethod compression_methods<1..2^8-1>;
-          select (extensions_present) {
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ClientHello;
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block. The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello. Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field but is used for compatibility with TLS before
-   extensions were defined.
-
-   client_version
-      The version of the TLS protocol by which the client wishes to
-      communicate during this session. This SHOULD be the latest
-      (highest valued) version supported by the client. For this version
-      of the specification, the version will be 3.3 (See Appendix E for
-      details about backward compatibility).
-
-   random
-      A client-generated random structure.
-
-   session_id
-      The ID of a session the client wishes to use for this connection.
-      This field is empty if no session_id is available, or it the
-      client wishes to generate new security parameters.
-
-   cipher_suites
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 39]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      This is a list of the cryptographic options supported by the
-      client, with the client's first preference first. If the
-      session_id field is not empty (implying a session resumption
-      request) this vector MUST include at least the cipher_suite from
-      that session. Values are defined in Appendix A.5.
-
-   compression_methods
-      This is a list of the compression methods supported by the client,
-      sorted by client preference. If the session_id field is not empty
-      (implying a session resumption request) it MUST include the
-      compression_method from that session. This vector MUST contain,
-      and all implementations MUST support, CompressionMethod.null.
-      Thus, a client and server will always be able to agree on a
-      compression method.
-
-   extensions
-      Clients MAY request extended functionality from servers by sending
-      data in the extensions Here the new "extensions" field contains a
-      list of extensions.  The actual "Extension" format is defined in
-      Section 7.4.1.4.
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-   client MAY abort the handshake.  A server MUST accept client hello
-   messages both with and without the extensions field, and (as for all
-   other messages) MUST check that the amount of data in the message
-   precisely matches one of these formats; if not, then it MUST send a
-   fatal "decode_error" alert.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-7.4.1.3. Server Hello
-
-   When this message will be sent:
-
-      The server will send this message in response to a client hello
-      message when it was able to find an acceptable set of algorithms.
-      If it cannot find such a match, it will respond with a handshake
-      failure alert.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 40]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          select (extensions_present) {
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ServerHello;
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-   server_version
-      This field will contain the lower of that suggested by the client
-      in the client hello and the highest supported by the server. For
-      this version of the specification, the version is 3.3.  (See
-      Appendix E for details about backward compatibility.)
-
-   random
-      This structure is generated by the server and MUST be
-      independently generated from the ClientHello.random.
-
-   session_id
-      This is the identity of the session corresponding to this
-      connection. If the ClientHello.session_id was non-empty, the
-      server will look in its session cache for a match. If a match is
-      found and the server is willing to establish the new connection
-      using the specified session state, the server will respond with
-      the same value as was supplied by the client. This indicates a
-      resumed session and dictates that the parties must proceed
-      directly to the finished messages. Otherwise this field will
-      contain a different value identifying the new session. The server
-      may return an empty session_id to indicate that the session will
-      not be cached and therefore cannot be resumed. If a session is
-      resumed, it must be resumed using the same cipher suite it was
-      originally negotiated with. Note that there is no requirement that
-      the server resume any session even if it had formerly provided a
-      session_id. Client MUST be prepared to do a full negotiation --
-      including negotiating new cipher suites -- during any handshake.
-
-   cipher_suite
-      The single cipher suite selected by the server from the list in
-      ClientHello.cipher_suites. For resumed sessions, this field is the
-      value from the state of the session being resumed.
-
-   compression_method
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 41]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      The single compression algorithm selected by the server from the
-      list in ClientHello.compression_methods. For resumed sessions this
-      field is the value from the resumed session state.
-
-   extensions
-      A list of extensions. Note that only extensions offered by the
-      client can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-      enum {
-          signature_algorithms(TBD-BY-IANA), (65535)
-      } ExtensionType;
-
-   Here:
-
-   -  "extension_type" identifies the particular extension type.
-
-   -  "extension_data" contains information specific to the particular
-      extension type.
-
-   The initial set of extensions is defined in a companion document
-   [TLSEXT]. The list of extension types is maintained by IANA as
-   described in Section 12.
-
-   There are subtle (and not so subtle) interactions that may occur in
-   this protocol between new features and existing features which may
-   result in a significant reduction in overall security, The following
-   considerations should be taken into account when designing new
-   extensions:
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some simply a refusal to support a particular
-      feature.  In general error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should as far as possible be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 42]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase. Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS - particularly since
-      the TLS handshake algorithms have specific protection against
-      version rollback attacks based on the version number, and the
-      possibility of version rollback should be a significant
-      consideration in any major design change.
-
-7.4.1.4.1 Signature Algorithms
-
-   The client uses the "signature_algorithms" extension to indicate to
-   the server which signature/hash algorithm pairs may be used in
-   digital signatures. The "extension_data" field of this extension
-   contains a "supported_signature_algorithms" value.
-
-      enum {
-          none(0), md5(1), sha1(2), sha256(3), sha384(4),
-          sha512(5), (255)
-      } HashAlgorithm;
-
-      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
-        SignatureAlgorithm;
-
-      struct {
-            HashAlgorithm hash;
-            SignatureAlgorithm signature;
-      } SignatureAndHashAlgorithm;
-
-      SignatureAndHashAlgorithm
-        supported_signature_algorithms<2..2^16-2>;
-
-   Each SignatureAndHashAlgorithm value lists a single hash/signature
-   pair which the client is willing to verify. The values are indicated
-   in descending order of preference.
-
-   Note: Because not all signature algorithms and hash algorithms may be
-   accepted by an implementation (e.g., DSA with SHA-1, but not
-   SHA-256), algorithms here are listed in pairs.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 43]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   hash
-      This field indicates the hash algorithm which may be used. The
-      values indicate support for unhashed data, MD5 [MD5], SHA-1,
-      SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value
-      is provided for future extensibility, in case of a signature
-      algorithm which does not require hashing before signing.
-
-   signature
-      This field indicates the signature algorithm which may be used.
-      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
-      [PKCS1] and DSA [DSS] respectively. The "anonymous" value is
-      meaningless in this context but used in Section 7.4.3. It MUST NOT
-      appear in this extension.
-
-   The semantics of this extension are somewhat complicated because the
-   cipher suite indicates permissible signature algorithms but not hash
-   algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
-
-   If the client supports only the default hash and signature algorithms
-   (listed in this section), it MAY omit the signature_algorithms
-   extension. If the client does not support the default algorithms, or
-   supports other hash and signature algorithms (and it is willing to
-   use them for verifying messages sent by server; server certificates
-   and server key exchange), it MUST send the signature_algorithms
-   extension listing the algorithms it is willing to accept.
-
-   If the client does not send the signature_algorithms extension, the
-   server MUST assume the following:
-
-   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
-   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
-   the value (sha1,rsa).
-
-   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
-   DH_DSS), behave as if the client had sent the value (sha1,dsa).
-
-   -  If the negotiated key exchnage algorithm is one of (ECDH_ECDSA,
-   ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).
-
-   Note: this is a change from TLS 1.1 where there are no explicit rules
-   but as a practical matter one can assume that the peer supports MD5
-   and SHA-1.
-
-   Note: this extension is not meaningful for TLS versions prior to 1.2.
-   Clients MUST NOT offer it if they are offering prior versions.
-   However, even if clients do offer it, the rules specified in [TLSEXT]
-   require servers to ignore extensions they do not understand.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 44]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   Servers MUST NOT send this extension. TLS servers MUST support
-   receiving this extension.
-
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-
-      The server MUST send a certificate whenever the agreed-upon key
-      exchange method uses certificates for authentication (this
-      includes all key exchange methods defined in this document except
-      DH_anon).  This message will always immediately follow the server
-      hello message.
-
-   Meaning of this message:
-
-      This message conveys the server's certificate chain to the client.
-      The certificate MUST be appropriate for the negotiated cipher
-      suite's key exchange algorithm, and any negotiated extensions.
-
-   Structure of this message:
-
-      opaque ASN.1Cert<1..2^24-1>;
-
-      struct {
-          ASN.1Cert certificate_list<0..2^24-1>;
-      } Certificate;
-
-   certificate_list
-      This is a sequence (chain) of certificates. The sender's
-      certificate MUST come first in the list. Each following
-      certificate MUST directly certify the one preceding it. Because
-      certificate validation requires that root keys be distributed
-      independently, the self-signed certificate that specifies the root
-      certificate authority MAY optionally be omitted from the chain,
-      under the assumption that the remote end must already possess it
-      in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
-   Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-   vector because PKCS #6 [PKCS6] extended certificates are not used.
-   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
-   of parsing the list more difficult.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 45]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   The following rules apply to the certificates sent by the server:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g., [TLSPGP]).
-
-   -  The end entity certificate's public key (and associated
-      restrictions) MUST be compatible with the selected key exchange
-      algorithm.
-
-      Key Exchange Alg.  Certificate Key Type
-
-      RSA                RSA public key; the certificate MUST
-      RSA_PSK            allow the key to be used for encryption
-                         (the keyEncipherment bit MUST be set
-                         if the key usage extension is present).
-                         Note: RSA_PSK is defined in [TLSPSK].
-
-      DHE_RSA            RSA public key; the certificate MUST
-      ECDHE_RSA          allow the key to be used for signing
-                         (the digitalSignature bit MUST be set
-                         if the key usage extension is present)
-                         with the signature scheme and hash
-                         algorithm that will be employed in the
-                         server key exchange message.
-
-      DHE_DSS            DSA public key; the certificate MUST
-                         allow the key to be used for signing with
-                         the hash algorithm that will be employed
-                         in the server key exchange message.
-
-      DH_DSS             Diffie-Hellman public key; the
-      DH_RSA             keyAgreement bit MUST be set if the
-                         key usage extension is present.
-
-      ECDH_ECDSA         ECDH-capable public key; the public key
-      ECDH_RSA           MUST use a curve and point format supported
-                         by the client, as described in [TLSECC].
-
-      ECDHE_ECDSA        ECDSA-capable public key; the certificate
-                         MUST allow the key to be used for signing
-                         with the hash algorithm that will be
-                         employed in the server key exchange
-                         message. The public key MUST use a curve
-                         and point format supported by the client,
-                         as described in  [TLSECC].
-
-   -  The "server_name" and "trusted_ca_keys" extensions [4366bis] are
-      used to guide certificate selection.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 46]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   If the client provided a "signature_algorithms" extension, then all
-   certificates provided by the server MUST be signed by a
-   hash/signature algorithm pair that appears in that extension.  Note
-   that this implies that a certificate containing a key for one
-   signature algorithm MAY be signed using a different signature
-   algorithm (for instance, an RSA key signed with a DSA key.) This is a
-   departure from TLS 1.1, which required that the algorithms be the
-   same.  Note that this also implies that the DH_DSS, DH_RSA,
-   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
-   algorithm used to sign the certificate. Fixed DH certificates MAY be
-   signed with any hash/signature algorithm pair appearing in the
-   extension.  The naming is historical.
-
-   If the server has multiple certificates, it chooses one of them based
-   on the above-mentioned criteria (in addition to other criteria, such
-   as transport layer endpoint, local configuration and preferences,
-   etc.). If the server has a single certificate it SHOULD attempt to
-   validate that it meets these criteria.
-
-   Note that there are certificates that use algorithms and/or algorithm
-   combinations that cannot be currently used with TLS.  For example, a
-   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
-   SubjectPublicKeyInfo) cannot be used because TLS defines no
-   corresponding signature algorithm.
-
-   As cipher suites that specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-
-      This message will be sent immediately after the server certificate
-      message (or the server hello message, if this is an anonymous
-      negotiation).
-
-      The server key exchange message is sent by the server only when
-      the server certificate message (if sent) does not contain enough
-      data to allow the client to exchange a premaster secret. This is
-      true for the following key exchange methods:
-
-         DHE_DSS
-         DHE_RSA
-         DH_anon
-
-      It is not legal to send the server key exchange message for the
-      following key exchange methods:
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 47]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-         RSA
-         DH_DSS
-         DH_RSA
-
-   Meaning of this message:
-
-      This message conveys cryptographic information to allow the client
-      to communicate the premaster secret: a Diffie-Hellman public key
-      with which the client can complete a key exchange (with the result
-      being the premaster secret) or a public key for some other
-      algorithm.
-
-   Structure of this message:
-
-      enum { diffie_hellman, rsa } KeyExchangeAlgorithm;
-
-      struct {
-          opaque dh_p<1..2^16-1>;
-          opaque dh_g<1..2^16-1>;
-          opaque dh_Ys<1..2^16-1>;
-      } ServerDHParams;     /* Ephemeral DH parameters */
-
-      dh_p
-         The prime modulus used for the Diffie-Hellman operation.
-
-      dh_g
-         The generator used for the Diffie-Hellman operation.
-
-      dh_Ys
-         The server's Diffie-Hellman public value (g^X mod p).
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                  ServerDHParams params;
-                  Signature signed_params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                  ServerDHParams params;
-          };
-      } ServerParams;
-
-
-      params
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 48]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-         The server's key exchange parameters.
-
-      signed_params
-         For non-anonymous key exchanges, a hash of the corresponding
-         params value, with the signature appropriate to that hash
-         applied.
-
-      hash
-         Hash(ClientHello.random + ServerHello.random + ServerParams)
-         where Hash is the chosen hash value and Hash.length is
-         its output.
-
-      struct {
-          select (SignatureAlgorithm) {
-            case anonymous: struct { };
-              case rsa:
-                SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-              case dsa:
-                SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-                digitally-signed struct {
-                    opaque hash[Hash.length];
-                };
-              };
-          };
-      } Signature;
-
-   If the client has offered the "signature_algorithms" extension, the
-   signature algorithm and hash algorithm MUST be a pair listed in that
-   extension. Note that there is a possibility for inconsistencies here.
-   For instance, the client might offer DHE_DSS key exchange but omit
-   any DSS pairs from its "signature_algorithms" extension.  In order to
-   negotiate correctly, the server MUST check any candidate cipher
-   suites against the "signature_algorithms" extension before selecting
-   them. This is somewhat inelegant but is a compromise designed to
-   minimize changes to the original cipher suite design.
-
-   In addition, the hash and signature algorithms MUST be compatible
-   with the key in the server's end-entity certificate.  RSA keys MAY be
-   used with any permitted hash algorithm, subject to restrictions in
-   the certificate, if any.
-
-   Because DSA signatures do not contain any secure indication of hash
-   algorithm, there is a risk of hash substitution if multiple hashes
-   may be used with any key. Currently, DSS [DSS] may only be used with
-   SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 49]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   digest algorithms, as well as guidance as to which digest algorithms
-   should be used with each key size. In addition, future revisions of
-   [PKIX] may specify mechanisms for certificates to indicate which
-   digest algorithms are to be used with DSA.
-
-   As additional cipher suites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-7.4.4. Certificate Request
-
-   When this message will be sent:
-
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-   Structure of this message:
-
-      enum {
-          rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-          rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-          fortezza_dms_RESERVED(20), (255)
-      } ClientCertificateType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-      struct {
-          ClientCertificateType certificate_types<1..2^8-1>;
-          SignatureAndHashAlgorithm
-            supported_signature_algorithms<2^16-1>;
-          DistinguishedName certificate_authorities<0..2^16-1>;
-      } CertificateRequest;
-
-   certificate_types
-      A list of the types of certificate types which the client may
-      offer.
-
-         rsa_sign        a certificate containing an RSA key
-         dss_sign        a certificate containing a DSS key
-         rsa_fixed_dh    a certificate containing a static DH key.
-         dss_fixed_dh    a certificate containing a static DH key
-
-   supported_signature_algorithms
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 50]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      A list of the hash/signature algorithm pairs that the server is
-      able to verify, listed in descending order of preference.
-
-   certificate_authorities
-      A list of the distinguished names [X501] of acceptable
-      certificate_authorities, represented in DER-encoded format. These
-      distinguished names may specify a desired distinguished name for a
-      root CA or for a subordinate CA; thus, this message can be used
-      both to describe known roots and a desired authorization space. If
-      the certificate_authorities list is empty then the client MAY send
-      any certificate of the appropriate ClientCertificateType, unless
-      there is some external arrangement to the contrary.
-
-   The interaction of the certificate_types and
-   supported_signature_algorithms fields is somewhat complicated.
-   certificate_types has been present in TLS since SSLv3, but was
-   somewhat underspecified. Much of its functionality is superseded by
-   supported_signature_algorithms. The following rules apply:
-
-   -  Any certificates provided by the client MUST be signed using a
-      hash/signature algorithm pair found in
-      supported_signature_algorithms.
-
-   -  The end-entity certificate provided by the client MUST contain a
-      key which is compatible with certificate_types. If the key is a
-      signature key, it MUST be usable with some hash/signature
-      algorithm pair in supported_signature_algorithms.
-
-   -  For historical reasons, the names of some client certificate types
-      include the algorithm used to sign the certificate.  For example,
-      in earlier versions of TLS, rsa_fixed_dh meant a certificate
-      signed with RSA and containing a static DH key.  In TLS 1.2, this
-      functionality has been obsoleted by the
-      supported_signature_algorithms, and the certificate type no longer
-      restricts the algorithm used to sign the certificate.  For
-      example, if the server sends dss_fixed_dh certificate type and
-      {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
-      with a certificate containing a static DH key, signed with RSA-
-      SHA1.
-
-   New ClientCertificateType values are assigned by IANA as described in
-   Section 12.
-
-   Note: Values listed as RESERVED may not be used. They were used in
-   SSLv3.
-
-   Note: It is a fatal handshake_failure alert for an anonymous server
-   to request client authentication.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 51]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-7.4.5 Server hello done
-
-   When this message will be sent:
-
-      The server hello done message is sent by the server to indicate
-      the end of the server hello and associated messages. After sending
-      this message, the server will wait for a client response.
-
-   Meaning of this message:
-
-      This message means that the server is done sending messages to
-      support the key exchange, and the client can proceed with its
-      phase of the key exchange.
-
-      Upon receipt of the server hello done message, the client SHOULD
-      verify that the server provided a valid certificate, if required
-      and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-
-      struct { } ServerHelloDone;
-
-7.4.6. Client Certificate
-
-   When this message will be sent:
-
-      This is the first message the client can send after receiving a
-      server hello done message. This message is only sent if the server
-      requests a certificate. If no suitable certificate is available,
-      the client MUST send a certificate message containing no
-      certificates. That is, the certificate_list structure has a length
-      of zero.  If the client does not send any certificates, the server
-      MAY at its discretion either continue the handshake without client
-      authentication, or respond with a fatal handshake_failure alert.
-      Also, if some aspect of the certificate chain was unacceptable
-      (e.g., it was not signed by a known, trusted CA), the server MAY
-      at its discretion either continue the handshake (considering the
-      client unauthenticated) or send a fatal alert.
-
-      Client certificates are sent using the Certificate structure
-      defined in Section 7.4.2.
-
-   Meaning of this message:
-
-      This message conveys the client's certificate chain to the server;
-      the server will use it when verifying the certificate verify
-      message (when the client authentication is based on signing), or
-      calculate the premaster secret (for non-ephemeral Diffie-Hellman).
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 52]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      The certificate MUST be appropriate for the negotiated cipher
-      suite's key exchange algorithm, and any negotiated extensions.
-
-   In particular:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g. [TLSPGP]).
-
-   -  The end-entity certificate's public key (and associated
-      restrictions) has to be compatible with the certificate types
-      listed in CertificateRequest:
-
-      Client Cert. Type   Certificate Key Type
-
-      rsa_sign            RSA public key; the certificate MUST allow
-                          the key to be used for signing with the
-                          signature scheme and hash algorithm that
-                          will be employed in the certificate verify
-                          message.
-
-      dss_sign            DSA public key; the certificate MUST allow
-                          the key to be used for signing with the
-                          hash algorithm that will be employed in
-                          the certificate verify message.
-
-      ecdsa_sign          ECDSA-capable public key; the certificate
-                          MUST allow the key to be used for signing
-                          with the hash algorithm that will be
-                          employed in the certificate verify
-                          message; the public key MUST use a
-                          curve and point format supported by the
-                          server.
-
-      rsa_fixed_dh        Diffie-Hellman public key; MUST use
-      dss_fixed_dh        the same parameters as server's key.
-
-      rsa_fixed_ecdh      ECDH-capable public key; MUST use
-      ecdsa_fixed_ecdh    the same curve as server's key, and
-                          MUST use a point format supported by
-                    the server.
-
-   -  If the certificate_authorities list in the certificate request
-      message was non-empty, one of the certificates in the certificate
-      chain SHOULD be issued by one of the listed CAs.
-
-   -  The certificates MUST be signed using an acceptable hash/
-      signature algorithm pair, as described in Section 7.4.4. Note that
-      this relaxes the constraints on certificate signing algorithms
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 53]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      found in prior versions of TLS.
-
-   Note that as with the server certificate, there are certificates that
-   use algorithms/algorithm combinations that cannot be currently used
-   with TLS.
-
-7.4.7. Client Key Exchange Message
-
-   When this message will be sent:
-
-      This message is always sent by the client. It MUST immediately
-      follow the client certificate message, if it is sent. Otherwise it
-      MUST be the first message sent by the client after it receives the
-      server hello done message.
-
-   Meaning of this message:
-
-      With this message, the premaster secret is set, either though
-      direct transmission of the RSA-encrypted secret, or by the
-      transmission of Diffie-Hellman parameters that will allow each
-      side to agree upon the same premaster secret.
-
-      When the client is using an ephemeral Diffie-Hellman exponent,
-      then this message contains the client's Diffie-Hellman public
-      value. If the client is sending a certificate containing a static
-      DH exponent (i.e., it is doing fixed_dh client authentication)
-      then this message MUST be sent but MUST be empty.
-
-
-   Structure of this message:
-
-      The choice of messages depends on which key exchange method has
-      been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-      definition.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-
-      If RSA is being used for key agreement and authentication, the
-      client generates a 48-byte premaster secret, encrypts it using the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 54]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      public key from the server's certificate and sends the result in
-      an encrypted premaster secret message. This structure is a variant
-      of the client key exchange message and is not a message in itself.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion client_version;
-          opaque random[46];
-      } PreMasterSecret;
-
-      client_version
-         The latest (newest) version supported by the client. This is
-         used to detect version roll-back attacks.
-
-      random
-         46 securely-generated random bytes.
-
-      struct {
-          public-key-encrypted PreMasterSecret pre_master_secret;
-      } EncryptedPreMasterSecret;
-
-      pre_master_secret
-         This random value is generated by the client and is used to
-         generate the master secret, as specified in Section 8.1.
-
-   Note: The version number in the PreMasterSecret is the version
-   offered by the client in the ClientHello.client_version, not the
-   version negotiated for the connection.  This feature is designed to
-   prevent rollback attacks.  Unfortunately, some old implementations
-   use the negotiated version instead and therefore checking the version
-   number may lead to failure to interoperate with such incorrect client
-   implementations.
-
-   Client implementations MUST always send the correct version number in
-   PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
-   server implementations MUST check the version number as described in
-   the note below. If the version number is 1.0 or earlier, server
-   implementations SHOULD check the version number, but MAY have a
-   configuration option to disable the check. Note that if the check
-   fails, the PreMasterSecret SHOULD be randomized as described below.
-
-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
-   [KPR03] can be used to attack a TLS server that reveals whether a
-   particular message, when decrypted, is properly PKCS#1 formatted,
-   contains a valid PreMasterSecret structure, or has the correct
-   version number.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 55]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   The best way to avoid these vulnerabilities is to treat incorrectly
-   formatted messages in a manner indistinguishable from correctly
-   formatted RSA blocks. In other words:
-
-      1. Generate a string R of 46 random bytes
-
-      2. Decrypt the message M
-
-      3. If the PKCS#1 padding is not correct, or the length of
-         message M is not exactly 48 bytes:
-            premaster secret = ClientHello.client_version || R
-         else If ClientHello.client_version <= TLS 1.0, and
-         version number check is explicitly disabled:
-            premaster secret = M
-         else:
-            premaster secret = ClientHello.client_version || M[2..47]
-
-   In any case, a TLS server MUST NOT generate an alert if processing an
-   RSA-encrypted premaster secret message fails, or the version number
-   is not as expected. Instead, it MUST continue the handshake with a
-   randomly generated premaster secret.  It may be useful to log the
-   real cause of failure for troubleshooting purposes; however, care
-   must be taken to avoid leaking the information to an attacker
-   (through, e.g., timing, log files, or other channels.)
-
-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
-   against the Bleichenbacher attack. However, for maximal compatibility
-   with earlier versions of TLS, this specification uses the RSAES-
-   PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
-   to exist provided that the above recommendations are followed.
-
-   Implementation Note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes. These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined. The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the the length bytes, encoding the RSA encrypted data
-   directly in the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes. The resulting
-   PDU is incompatible with many SSLv3 implementations. Implementors
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding. Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 56]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   behavior dependent on the protocol version.
-
-   Implementation Note: It is now known that remote timing-based attacks
-   on TLS are possible, at least when the client and server are on the
-   same LAN. Accordingly, implementations that use static RSA keys MUST
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
-
-7.4.7.2. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-
-      This structure conveys the client's Diffie-Hellman public value
-      (Yc) if it was not already included in the client's certificate.
-      The encoding used for Yc is determined by the enumerated
-      PublicValueEncoding. This structure is a variant of the client key
-      exchange message, and not a message in itself.
-
-   Structure of this message:
-
-      enum { implicit, explicit } PublicValueEncoding;
-
-      implicit
-         If the client has sent a certificate which contains a suitable
-         Diffie-Hellman key (for fixed_dh client authentication) then Yc
-         is implicit and does not need to be sent again. In this case,
-         the client key exchange message will be sent, but it MUST be
-         empty.
-
-      explicit
-         Yc needs to be sent.
-
-      struct {
-          select (PublicValueEncoding) {
-              case implicit: struct { };
-              case explicit: opaque dh_Yc<1..2^16-1>;
-          } dh_public;
-      } ClientDiffieHellmanPublic;
-
-      dh_Yc
-         The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-
-      This message is used to provide explicit verification of a client
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 57]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      certificate. This message is only sent following a client
-      certificate that has signing capability (i.e. all certificates
-      except those containing fixed Diffie-Hellman parameters). When
-      sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-
-      struct {
-           SignatureAndHashAlgorithm signature_algorithm;
-           digitally-signed struct {
-               opaque handshake_messages[handshake_messages_length];
-           }
-      } CertificateVerify;
-
-      Here handshake_messages refers to all handshake messages sent or
-      received starting at client hello up to but not including this
-      message, including the type and length fields of the handshake
-      messages. This is the concatenation of all the Handshake
-      structures as defined in 7.4 exchanged thus far. Note that this
-      requires both sides to either buffer the messages or compute
-      running hashes for all potential hash algorithms up to the time of
-      the CertificateVerify computation. Servers can minimize this
-      computation cost by offering a restricted set of digest algorithms
-      in the CertificateRequest message.
-
-      The hash and signature algorithms used in the signature MUST be
-      one of those present in the supported_signature_algorithms field
-      of the CertificateRequest message. In addition, the hash and
-      signature algorithms MUST be compatible with the key in the
-      client's end-entity certificate.  RSA keys MAY be used with any
-      permitted hash algorith, subject to restrictions in the
-      certificate, if any.
-
-      Because DSA signatures do not contain any secure indication of
-      hash algorithm, there is a risk of hash substitution if multiple
-      hashes may be used with any key. Currently, DSS [DSS] may only be
-      used with SHA-1. Future revisions of DSS [DSS-3] are expected to
-      allow other digest algorithms, as well as guidance as to which
-      digest algorithms should be used with each key size. In addition,
-      future revisions of [PKIX] may specify mechanisms for certificates
-      to indicate which digest algorithms are to be used with DSA.
-
-
-7.4.9. Finished
-
-   When this message will be sent:
-
-      A finished message is always sent immediately after a change
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 58]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      cipher spec message to verify that the key exchange and
-      authentication processes were successful. It is essential that a
-      change cipher spec message be received between the other handshake
-      messages and the Finished message.
-
-   Meaning of this message:
-
-      The finished message is the first protected with the just-
-      negotiated algorithms, keys, and secrets. Recipients of finished
-      messages MUST verify that the contents are correct.  Once a side
-      has sent its Finished message and received and validated the
-      Finished message from its peer, it may begin to send and receive
-      application data over the connection.
-
-   Structure of this message:
-
-      struct {
-          opaque verify_data[verify_data_length];
-      } Finished;
-
-      verify_data
-         PRF(master_secret, finished_label, Hash(handshake_messages))
-            [0..verify_data_length-1];
-
-      finished_label
-         For Finished messages sent by the client, the string "client
-         finished". For Finished messages sent by the server, the string
-         "server finished".
-
-      Hash denotes a Hash of the handshake messages. For the PRF defined
-      in Section 5, the Hash MUST be the Hash used as the basis for the
-      PRF. Any cipher suite which defines a different PRF MUST also
-      define the Hash to use in the Finished computation.
-
-      In previous versions of TLS, the verify_data was always 12 octets
-      long. In the current version of TLS, it depends on the cipher
-      suite. Any cipher suite which does not explicitly specify
-      verify_data_length has a verify_data_length equal to 12. This
-      includes all existing cipher suites.  Note that this
-      representation has the same encoding as with previous versions.
-      Future cipher suites MAY specify other lengths but such length
-      MUST be at least 12 bytes.
-
-      handshake_messages
-         All of the data from all messages in this handshake (not
-         including any HelloRequest messages) up to but not including
-         this message. This is only data visible at the handshake layer
-         and does not include record layer headers.  This is the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 59]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-         concatenation of all the Handshake structures as defined in
-         7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the certificate verify message (if sent). Also, the
-   handshake_messages for the finished message sent by the client will
-   be different from that for the finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
-   Note: Change cipher spec messages, alerts, and any other record types
-   are not handshake messages and are not included in the hash
-   computations. Also, Hello Request messages are omitted from handshake
-   hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-      master_secret = PRF(pre_master_secret, "master secret",
-                          ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 60]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
-   Note: Diffie-Hellman parameters are specified by the server and may
-   be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_AES_128_CBC_SHA.
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-12. IANA Considerations
-
-   This document uses several registries that were originally created in
-   [TLS1.1]. IANA is requested to update (has updated) these to
-   reference this document. The registries and their allocation policies
-   (unchanged from [TLS1.1]) are listed below.
-
-   -  TLS ClientCertificateType Identifiers Registry: Future values in
-      the range 0-63 (decimal) inclusive are assigned via Standards
-      Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 61]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      are assigned Specification Required [RFC2434]. Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   - TLS Cipher Suite Registry: Future values with the first byte in the
-      range 0-191 (decimal) inclusive are assigned via Standards Action
-      [RFC2434].  Values with the first byte in the range 192-254
-      (decimal) are assigned via Specification Required [RFC2434].
-      Values with the first byte 255 (decimal) are reserved for Private
-      Use [RFC2434]. This document defines several new HMAC-SHA256 based
-      cipher suites, whose values (in Appendix A.5) are to be (have
-      been) allocated from the TLS Cipher Suite registry.
-
-   -  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   -  TLS Alert Registry: Future values are allocated via Standards
-      Action [RFC2434].
-
-   -  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA is requested to update (has updated) it to reference this
-   document.  The registry and its allocation policy (unchanged from
-   [RFC4366]) is listed below:
-
-   -  TLS ExtensionType Registry: Future values are allocated via IETF
-      Consensus [RFC2434]
-
-   In addition, this document defines two new registries to be
-   maintained by IANA:
-
-   -  TLS SignatureAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-   -  TLS HashAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 62]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   This document defines one new TLS extension, signature_algorithms,
-   which is to be (has been) allocated value TBD-BY-IANA in the TLS
-   ExtensionType registry.
-
-   This document also uses the TLS Compression Method Identifiers
-   Registry, defined in [RFC3749].  IANA is requested to allocate value
-   0 for the "null" compression method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 63]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Appendix A. Protocol Constant Values
-
-   This section describes protocol types and constants.
-
-A.1. Record Layer
-
-   struct {
-       uint8 major;
-       uint8 minor;
-   } ProtocolVersion;
-
-   ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-   enum {
-       change_cipher_spec(20), alert(21), handshake(22),
-       application_data(23), (255)
-   } ContentType;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSPlaintext.length];
-   } TLSPlaintext;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSCompressed.length];
-   } TLSCompressed;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       select (SecurityParameters.cipher_type) {
-           case stream: GenericStreamCipher;
-           case block:  GenericBlockCipher;
-           case aead:   GenericAEADCipher;
-       } fragment;
-   } TLSCiphertext;
-
-   stream-ciphered struct {
-       opaque content[TLSCompressed.length];
-       opaque MAC[SecurityParameters.mac_length];
-   } GenericStreamCipher;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 64]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       block-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       };
-   } GenericBlockCipher;
-
-   aead-ciphered struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       opaque aead_output[AEADEncrypted.length];
-   } GenericAEADCipher;
-
-A.2. Change Cipher Specs Message
-
-   struct {
-       enum { change_cipher_spec(1), (255) } type;
-   } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-   enum { warning(1), fatal(2), (255) } AlertLevel;
-
-   enum {
-       close_notify(0),
-       unexpected_message(10),
-       bad_record_mac(20),
-       decryption_failed_RESERVED(21),
-       record_overflow(22),
-       decompression_failure(30),
-       handshake_failure(40),
-       no_certificate_RESERVED(41),
-       bad_certificate(42),
-       unsupported_certificate(43),
-       certificate_revoked(44),
-       certificate_expired(45),
-       certificate_unknown(46),
-       illegal_parameter(47),
-       unknown_ca(48),
-       access_denied(49),
-       decode_error(50),
-       decrypt_error(51),
-       export_restriction_RESERVED(60),
-       protocol_version(70),
-       insufficient_security(71),
-       internal_error(80),
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 65]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-       user_canceled(90),
-       no_renegotiation(100),
-       unsupported_extension(110),           /* new */
-       (255)
-   } AlertDescription;
-
-   struct {
-       AlertLevel level;
-       AlertDescription description;
-   } Alert;
-
-A.4. Handshake Protocol
-
-   enum {
-       hello_request(0), client_hello(1), server_hello(2),
-       certificate(11), server_key_exchange (12),
-       certificate_request(13), server_hello_done(14),
-       certificate_verify(15), client_key_exchange(16),
-       finished(20)
-       (255)
-   } HandshakeType;
-
-   struct {
-       HandshakeType msg_type;
-       uint24 length;
-       select (HandshakeType) {
-           case hello_request:       HelloRequest;
-           case client_hello:        ClientHello;
-           case server_hello:        ServerHello;
-           case certificate:         Certificate;
-           case server_key_exchange: ServerKeyExchange;
-           case certificate_request: CertificateRequest;
-           case server_hello_done:   ServerHelloDone;
-           case certificate_verify:  CertificateVerify;
-           case client_key_exchange: ClientKeyExchange;
-           case finished:            Finished;
-       } body;
-   } Handshake;
-
-A.4.1. Hello Messages
-
-   struct { } HelloRequest;
-
-   struct {
-       uint32 gmt_unix_time;
-       opaque random_bytes[28];
-   } Random;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 66]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   opaque SessionID<0..32>;
-
-   uint8 CipherSuite[2];
-
-   enum { null(0), (255) } CompressionMethod;
-
-   struct {
-       ProtocolVersion client_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suites<2..2^16-2>;
-       CompressionMethod compression_methods<1..2^8-1>;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ClientHello;
-
-   struct {
-       ProtocolVersion server_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suite;
-       CompressionMethod compression_method;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ServerHello;
-
-   struct {
-       ExtensionType extension_type;
-       opaque extension_data<0..2^16-1>;
-   } Extension;
-
-   enum {
-       signature_algorithms(TBD-BY-IANA), (65535)
-   } ExtensionType;
-
-   enum{
-       none(0), md5(1), sha1(2), sha256(3), sha384(4),
-       sha512(5), (255)
-   } HashAlgorithm;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 67]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
-
-   struct {
-         HashAlgorithm hash;
-         SignatureAlgorithm signature;
-   } SignatureAndHashAlgorithm;
-
-   SignatureAndHashAlgorithm
-    supported_signature_algorithms<2..2^16-1>;
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-   opaque ASN.1Cert<2^24-1>;
-
-   struct {
-       ASN.1Cert certificate_list<0..2^24-1>;
-   } Certificate;
-
-   enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-   struct {
-       opaque dh_p<1..2^16-1>;
-       opaque dh_g<1..2^16-1>;
-       opaque dh_Ys<1..2^16-1>;
-   } ServerDHParams;
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case diffie_hellman:
-               ServerDHParams params;
-               Signature signed_params;
-       }
-   } ServerKeyExchange;
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case diffie_hellman:
-               ServerDHParams params;
-       };
-   } ServerParams;
-
-   struct {
-       select (SignatureAlgorithm) {
-         case anonymous: struct { };
-           case rsa:
-               SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-               digitally-signed struct {
-                   opaque hash[Hash.length];
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 68]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-               };
-           case dsa:
-               SignatureAndHashAlgorithm signature_algorithm; /*NEW*/
-               digitally-signed struct {
-                   opaque hash[Hash.length];
-               };
-           };
-       };
-   } Signature;
-
-   enum {
-       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-       fortezza_dms_RESERVED(20),
-       (255)
-   } ClientCertificateType;
-
-   opaque DistinguishedName<1..2^16-1>;
-
-   struct {
-       ClientCertificateType certificate_types<1..2^8-1>;
-       DistinguishedName certificate_authorities<0..2^16-1>;
-   } CertificateRequest;
-
-   struct { } ServerHelloDone;
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa: EncryptedPreMasterSecret;
-           case diffie_hellman: ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   } PreMasterSecret;
-
-   struct {
-       public-key-encrypted PreMasterSecret pre_master_secret;
-   } EncryptedPreMasterSecret;
-
-   enum { implicit, explicit } PublicValueEncoding;
-
-   struct {
-       select (PublicValueEncoding) {
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 69]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-           case implicit: struct {};
-           case explicit: opaque DH_Yc<1..2^16-1>;
-       } dh_public;
-   } ClientDiffieHellmanPublic;
-
-   struct {
-       Signature signature;
-   } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-   struct {
-       opaque verify_data[verify_data_length];
-   } Finished;
-
-A.5. The Cipher Suite
-
-   The following values define the cipher suite codes used in the client
-   hello and server hello messages.
-
-   A cipher suite defines a cipher specification supported in TLS
-   Version 1.2.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-      CipherSuite TLS_NULL_WITH_NULL_NULL               = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request any signature-capable certificate in the certificate request
-   message.
-
-      CipherSuite TLS_RSA_WITH_NULL_MD5                 = { 0x00,0x01 };
-      CipherSuite TLS_RSA_WITH_NULL_SHA                 = { 0x00,0x02 };
-      CipherSuite TLS_RSA_WITH_NULL_SHA256              = { 0x00,TBD1 };
-      CipherSuite TLS_RSA_WITH_RC4_128_MD5              = { 0x00,0x04 };
-      CipherSuite TLS_RSA_WITH_RC4_128_SHA              = { 0x00,0x05 };
-      CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA         = { 0x00,0x0A };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x35 };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256       = { 0x00,TBD2 };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256       = { 0x00,TBD3 };
-
-
-   The following cipher suite definitions are used for server-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 70]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a a signature-capable certificate, which has
-   been signed by the CA. The signing algorithm used by the server is
-   specified after the DHE parameter. The server can request any
-   signature-capable certificate from the client for client
-   authentication or it may request a Diffie-Hellman certificate. Any
-   Diffie-Hellman certificate provided by the client must use the
-   parameters (group and generator) described by the server.
-
-
-      CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x0D };
-      CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x10 };
-      CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x13 };
-      CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x16 };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00, TBD4 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00, TBD5 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00, TBD6 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00, TBD7 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256    = { 0x00, TBD8 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256    = { 0x00, TBD9 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   = { 0x00, TBD10 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   = { 0x00, TBD11 };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks.  Using
-   this mode therefore is of limited use: These cipher suites MUST NOT
-   be used by TLS 1.2 implementations unless the application layer has
-   specifically requested to allow anonymous key exchange.  (Anonymous
-   key exchange may sometimes be acceptable, for example, to support
-   opportunistic encryption when no set-up for authentication is in
-   place, or when TLS is used as part of more complex security protocols
-   that have other means to ensure authentication.)
-
-      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
-      CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 71]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00, TBD12 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00, TBD13 };
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-   SSLv3, TLS 1.0, and TLS 1.1 supported DES and IDEA. DES had a 56-bit
-   key which is too weak for modern use. Triple-DES (3DES) has an
-   effective key strength of 112 bits and is still acceptable.  IDEA and
-   is no longer in wide use. Cipher suites using RC2, DES, and IDEA are
-   hereby deprecated for TLS 1.2. TLS 1.2 implementations MUST NOT
-   negotiate these cipher suites in TLS 1.2 mode. However, for backward
-   compatibility they may be offered in the ClientHello for use with TLS
-   1.0 or SSLv3 only servers. TLS 1.2 clients MUST check that the server
-   did not choose one of these cipher suites during the handshake. These
-   cipher suites are listed below for informational purposes and to
-   reserve the numbers.
-
-   CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA             = { 0x00,0x07 };
-   CipherSuite TLS_RSA_WITH_DES_CBC_SHA              = { 0x00,0x09 };
-   CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA           = { 0x00,0x0C };
-   CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA           = { 0x00,0x0F };
-   CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA          = { 0x00,0x15 };
-   CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA          = { 0x00,0x12 };
-   CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA          = { 0x00,0x1A };
-
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms. A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations. Due to advances in computer performance, these
-   algorithms are now unacceptably weak and export restrictions have
-   since been loosened. TLS 1.2 implementations MUST NOT negotiate these
-   cipher suites in TLS 1.2 mode. However, for backward compatibility
-   they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
-   only servers. TLS 1.2 clients MUST check that the server did not
-   choose one of these cipher suites during the handshake. These
-   ciphersuites are listed below for informational purposes and to
-   reserve the numbers.
-
-      CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5        = { 0x00,0x03 };
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 72]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    = { 0x00,0x06 };
-      CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     = { 0x00,0x08 };
-      CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x0B };
-      CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x0E };
-      CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
-      CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
-      CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    = { 0x00,0x17 };
-      CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
-
-   New cipher suite values are assigned by IANA as described in Section
-   12.
-
-   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-   enum { null(0), (255) } CompressionMethod;
-
-   enum { server, client } ConnectionEnd;
-
-   enum { tls_prf_sha256 } PRFAlgorithm;
-
-   enum { null, rc4, 3des, aes }
-   BulkCipherAlgorithm;
-
-   enum { stream, block, aead } CipherType;
-
-   enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,
-     hmac_sha512} MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-   struct {
-       ConnectionEnd          entity;
-       PRFAlgorithm           prf_algorithm;
-       BulkCipherAlgorithm    bulk_cipher_algorithm;
-       CipherType             cipher_type;
-       uint8                  enc_key_length;
-       uint8                  block_length;
-       uint8                  fixed_iv_length;
-       uint8                  record_iv_length;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 73]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-       MACAlgorithm           mac_algorithm;
-       uint8                  mac_length;
-       uint8                  mac_key_length;
-       CompressionMethod      compression_algorithm;
-       opaque                 master_secret[48];
-       opaque                 client_random[32];
-       opaque                 server_random[32];
-   } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 74]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-      AES is a widely used symmetric encryption algorithm.  AES is a
-      block cipher with a 128, 192, or 256 bit keys and a 16 byte block
-      size. [AES] TLS currently only supports the 128 and 256 bit key
-      sizes.
-
-   application protocol
-      An application protocol is a protocol that normally layers
-      directly on top of the transport layer (e.g., TCP/IP). Examples
-      include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-      See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-      A symmetric encryption algorithm that simultaneously provides
-      confidentiality and message integrity.
-
-   authentication
-      Authentication is the ability of one entity to determine the
-      identity of another entity.
-
-   block cipher
-      A block cipher is an algorithm that operates on plaintext in
-      groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-      A symmetric encryption algorithm used to encrypt large quantities
-      of data.
-
-   cipher block chaining (CBC)
-      CBC is a mode in which every plaintext block encrypted with a
-      block cipher is first exclusive-ORed with the previous ciphertext
-      block (or, in the case of the first block, with the initialization
-      vector). For decryption, every block is first decrypted, then
-      exclusive-ORed with the previous ciphertext block (or IV).
-
-   certificate
-      As part of the X.509 protocol (a.k.a. ISO Authentication
-      framework), certificates are assigned by a trusted Certificate
-      Authority and provide a strong binding between a party's identity
-      or some other attributes and its public key.
-
-   client
-      The application entity that initiates a TLS connection to a
-      server. This may or may not imply that the client initiated the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 75]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      underlying transport connection. The primary operational
-      difference between the server and client is that the server is
-      generally authenticated, while the client is only optionally
-      authenticated.
-
-   client write key
-      The key used to encrypt data written by the client.
-
-   client write MAC key
-      The secret data used to authenticate data written by the client.
-
-   connection
-      A connection is a transport (in the OSI layering model definition)
-      that provides a suitable type of service. For TLS, such
-      connections are peer-to-peer relationships. The connections are
-      transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-      DES is a very widely used symmetric encryption algorithm. DES is a
-      block cipher with a 56 bit key and an 8 byte block size. Note that
-      in TLS, for key generation purposes, DES is treated as having an 8
-      byte key length (64 bits), but it still only provides 56 bits of
-      protection. (The low bit of each key byte is presumed to be set to
-      produce odd parity in that key byte.) DES can also be operated in
-      a mode where three independent keys and three encryptions are used
-      for each block of data; this uses 168 bits of key (24 bytes in the
-      TLS key generation method) and provides the equivalent of 112 bits
-      of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-      A standard for digital signing, including the Digital Signing
-      Algorithm, approved by the National Institute of Standards and
-      Technology, defined in NIST FIPS PUB 186, "Digital Signature
-      Standard", published May, 1994 by the U.S. Dept. of Commerce.
-      [DSS]
-
-   digital signatures
-      Digital signatures utilize public key cryptography and one-way
-      hash functions to produce a signature of the data that can be
-      authenticated, and is difficult to forge or repudiate.
-
-   handshake
-      An initial negotiation between client and server that establishes
-      the parameters of their transactions.
-
-   Initialization Vector (IV)
-      When a block cipher is used in CBC mode, the initialization vector
-      is exclusive-ORed with the first plaintext block prior to
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 76]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      encryption.
-
-   IDEA
-      A 64-bit block cipher designed by Xuejia Lai and James Massey.
-      [IDEA]
-
-   Message Authentication Code (MAC)
-      A Message Authentication Code is a one-way hash computed from a
-      message and some secret data. It is difficult to forge without
-      knowing the secret data. Its purpose is to detect if the message
-      has been altered.
-
-   master secret
-      Secure secret data used for generating encryption keys, MAC
-      secrets, and IVs.
-
-   MD5
-      MD5 is a secure hashing function that converts an arbitrarily long
-      data stream into a hash of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-      A class of cryptographic techniques employing two-key ciphers.
-      Messages encrypted with the public key can only be decrypted with
-      the associated private key. Conversely, messages signed with the
-      private key can be verified with the public key.
-
-   one-way hash function
-      A one-way transformation that converts an arbitrary amount of data
-      into a fixed-length hash. It is computationally hard to reverse
-      the transformation or to find collisions. MD5 and SHA are examples
-      of one-way hash functions.
-
-   RC2
-      A block cipher developed by Ron Rivest, described in [RC2].
-
-   RC4
-      A stream cipher invented by Ron Rivest. A compatible cipher is
-      described in [SCH].
-
-   RSA
-      A very widely used public-key algorithm that can be used for
-      either encryption or digital signing. [RSA]
-
-   server
-      The server is the application entity that responds to requests for
-      connections from clients. See also under client.
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 77]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   session
-      A TLS session is an association between a client and a server.
-      Sessions are created by the handshake protocol. Sessions define a
-      set of cryptographic security parameters that can be shared among
-      multiple connections. Sessions are used to avoid the expensive
-      negotiation of new security parameters for each connection.
-
-   session identifier
-      A session identifier is a value generated by a server that
-      identifies a particular session.
-
-   server write key
-      The key used to encrypt data written by the server.
-
-   server write MAC key
-      The secret data used to authenticate data written by the server.
-
-   SHA
-      The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-      produces a 20-byte output. Note that all references to SHA
-      actually use the modified SHA-1 algorithm. [SHA]
-
-   SHA-256
-      The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-      produces a 32-byte output.
-
-   SSL
-      Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-      SSL Version 3.0
-
-   stream cipher
-      An encryption algorithm that converts a key into a
-      cryptographically strong keystream, which is then exclusive-ORed
-      with the plaintext.
-
-   symmetric cipher
-      See bulk cipher.
-
-   Transport Layer Security (TLS)
-      This protocol; also, the Transport Layer Security working group of
-      the Internet Engineering Task Force (IETF). See "Comments" at the
-      end of this document.
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 78]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Appendix C. Cipher Suite Definitions
-
-Cipher Suite                            Key          Cipher        Mac
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                   RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA            NULL         SHA
-TLS_RSA_WITH_NULL_SHA256                RSA            NULL         SHA256
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA            AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_CBC_SHA            RSA            AES_256_CBC  SHA
-TLS_RSA_WITH_AES_128_CBC_SHA256         RSA            AES_128_CBC  SHA256
-TLS_RSA_WITH_AES_256_CBC_SHA256         RSA            AES_256_CBC  SHA256
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS         AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA         AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS        AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA        AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon        AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS         AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA         AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS        AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA        AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon        AES_256_CBC  SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA256      DH_DSS         AES_128_CBC  SHA256
-TLS_DH_RSA_WITH_AES_128_CBC_SHA256      DH_RSA         AES_128_CBC  SHA256
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA256     DHE_DSS        AES_128_CBC  SHA256
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA256     DHE_RSA        AES_128_CBC  SHA256
-TLS_DH_anon_WITH_AES_128_CBC_SHA256     DH_anon        AES_128_CBC  SHA256
-TLS_DH_DSS_WITH_AES_256_CBC_SHA256      DH_DSS         AES_256_CBC  SHA256
-TLS_DH_RSA_WITH_AES_256_CBC_SHA256      DH_RSA         AES_256_CBC  SHA256
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA256     DHE_DSS        AES_256_CBC  SHA256
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA256     DHE_RSA        AES_256_CBC  SHA256
-TLS_DH_anon_WITH_AES_256_CBC_SHA256     DH_anon        AES_256_CBC  SHA256
-
-
-                     Key      Expanded     IV    Block
-Cipher       Type  Material Key Material   Size   Size
-
-NULL         Stream   0          0         0     N/A
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 79]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-RC4_128      Stream  16         16         0     N/A
-3DES_EDE_CBC Block   24         24         8      8
-AES_128_CBC  Block   16         16         16    16
-AES_256_CBC  Block   32         32         16    16
-
-
-MAC       Algorithm    mac_length  mac_key_length
-
-NULL      N/A          0           0
-MD5       HMAC-MD5     16          16
-SHA       HMAC-SHA1    20          20
-SHA256    HMAC-SHA256  32          32
-
-   Type
-      Indicates whether this is a stream cipher or a block cipher
-      running in CBC mode.
-
-   Key Material
-      The number of bytes from the key_block that are used for
-      generating the write keys.
-
-   Expanded Key Material
-      The number of bytes actually fed into the encryption algorithm.
-
-   IV Size
-      The amount of data needed to be generated for the initialization
-      vector. Zero for stream ciphers; equal to the block size for block
-      ciphers (this is equal to SecurityParameters.record_iv_length).
-
-   Block Size
-      The amount of data a block cipher enciphers in one chunk; a block
-      cipher running in CBC mode can only encrypt an even multiple of
-      its block size.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 80]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably SHA-1, are acceptable,
-   but cannot provide more security than the size of the random number
-   generator state.
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 Cipher Suites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-D.4 Implementation Pitfalls
-
-   Implementation experience has shown that certain parts of earlier TLS
-   specifications are not easy to understand, and have been a source of
-   interoperability and security problems. Many of these areas have been
-   clarified in this document, but this appendix contains a short list
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 81]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   of the most important things that require special attention from
-   implementors.
-
-   TLS protocol issues:
-
-   -  Do you correctly handle handshake messages that are fragmented
-      to multiple TLS records (see Section 6.2.1)? Including corner
-      cases like a ClientHello that is split to several small
-      fragments? Do you fragment handshake messages that exceed the
-      maximum fragment size? In particular, the certificate and
-      certificate request handshake messages can be large enough to
-      require fragmentation.
-
-   -  Do you ignore the TLS record layer version number in all TLS
-      records before ServerHello (see Appendix E.1)?
-
-   -  Do you handle TLS extensions in ClientHello correctly,
-      including omitting the extensions field completely?
-
-   -  Do you support renegotiation, both client and server initiated?
-      While renegotiation is an optional feature, supporting
-      it is highly recommended.
-
-   -  When the server has requested a client certificate, but no
-      suitable certificate is available, do you correctly send
-      an empty Certificate message, instead of omitting the whole
-      message (see Section 7.4.6)?
-
-   Cryptographic details:
-
-   -  In RSA-encrypted Premaster Secret,  do you correctly send and
-      verify the version number? When an error is encountered, do
-      you continue the handshake to avoid the Bleichenbacher
-      attack (see Section 7.4.7.1)?
-
-   -  What countermeasures do you use to prevent timing attacks against
-      RSA decryption and signing operations (see Section 7.4.7.1)?
-
-   -  When verifying RSA signatures, do you accept both NULL and
-      missing parameters (see Section 4.7)? Do you verify that the
-      RSA padding doesn't have additional data after the hash value?
-      [FI06]
-
-   -  When using Diffie-Hellman key exchange, do you correctly strip
-      leading zero bytes from the negotiated key (see Section 8.1.2)?
-
-   -  Does your TLS client check that the Diffie-Hellman parameters
-      sent by the server are acceptable (see Section F.1.1.3)?
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 82]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   -  How do you generate unpredictable IVs for CBC mode ciphers
-      (see Section 6.2.3.2)?
-
-   -  Do you accept long CBC mode padding (up to 255 bytes; see
-      Section 6.2.3.2)?
-
-   -  How do you address CBC mode timing attacks (Section 6.2.3.2)?
-
-   -  Do you use a strong and, most importantly, properly seeded
-      random number generator (see Appendix D.1) for generating the
-      premaster secret (for RSA key exchange), Diffie-Hellman private
-      values, the DSA "k" parameter, and other security-critical
-      values?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 83]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Appendix E. Backward Compatibility
-
-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client support the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version. If the server does not support this
-   version, it will respond with ServerHello containing an older version
-   number. If the client agrees to use this version, the negotiation
-   will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing version number
-   smaller than the highest supported version. If the server wishes to
-   negotiate with old clients, it will proceed as appropriate for the
-   highest version supported by the server that is not greater than
-   ClientHello.client_version. For example, if the server supports TLS
-   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing
-   to use) only versions greater than client_version, it MUST send a
-   "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   Note: some server implementations are known to implement version
-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 84]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   that simply close the connection when the client offers a version
-   newer than TLS 1.0. Also, it is known that some servers will refuse
-   connection if any TLS extensions are included in ClientHello.
-   Interoperability with such buggy servers is a complex topic beyond
-   the scope of this document, and may require multiple connection
-   attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed). Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number. Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version. No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2 Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
-   contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS cipher suites in the
-   CIPHER-SPECS-DATA field as described below.
-
-   Warning: The ability to send version 2.0 CLIENT-HELLO messages will
-   be phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-   However, even TLS servers that do not support SSL 2.0 MAY accept
-   version 2.0 CLIENT-HELLO messages. The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions. Note that this message MUST be sent directly on the wire,
-   not wrapped as a TLS record. For the purposes of calculating Finished
-   and CertificateVerify, the msg_length field is not considered to be a
-   part of the handshake message.
-
-      uint8 V2CipherSpec[3];
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 85]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-      struct {
-          uint16 msg_length;
-          uint8 msg_type;
-          Version version;
-          uint16 cipher_spec_length;
-          uint16 session_id_length;
-          uint16 challenge_length;
-          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-          opaque session_id[V2ClientHello.session_id_length];
-          opaque challenge[V2ClientHello.challenge_length;
-      } V2ClientHello;
-
-   msg_length
-      The highest bit MUST be 1; the remaining bits contain the length
-      of the following data in bytes.
-
-   msg_type
-      This field, in conjunction with the version field, identifies a
-      version 2 client hello message. The value MUST be one (1).
-
-   version
-      Equal to ClientHello.client_version.
-
-   cipher_spec_length
-      This field is the total length of the field cipher_specs. It
-      cannot be zero and MUST be a multiple of the V2CipherSpec length
-      (3).
-
-   session_id_length
-      This field MUST have a value of zero for a client that claims to
-      support TLS 1.2.
-
-   challenge_length
-      The length in bytes of the client's challenge to the server to
-      authenticate itself. Historically, permissible values are between
-      16 and 32 bytes inclusive. When using the SSLv2 backward
-      compatible handshake the client SHOULD use a 32 byte challenge.
-
-   cipher_specs
-      This is a list of all CipherSpecs the client is willing and able
-      to use. In addition to the 2.0 cipher specs defined in [SSL2],
-      this includes the TLS cipher suites normally sent in
-      ClientHello.cipher_suites, each cipher suite prefixed by a zero
-      byte. For example, TLS cipher suite {0x00,0x0A} would be sent as
-      {0x00,0x00,0x0A}.
-
-   session_id
-      This field MUST be empty.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 86]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   challenge
-      Corresponds to ClientHello.random. If the challenge length is less
-      than 32, the TLS server will pad the data with leading (note: not
-      trailing) zero bytes to make it 32 bytes long.
-
-   Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.3. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   MUST use special PKCS#1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
-   the right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).
-
-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
-   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
-   padding bytes are 0x03. If they are not, the server SHOULD generate a
-   random value for SECRET-KEY-DATA, and continue the handshake (which
-   will eventually fail since the keys will not match).  Note that
-   reporting the error situation to the client could make the server
-   vulnerable to attacks described in [BLEI].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 87]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC keys (see
-   Sections 7.4.9 and 6.3). By sending a correct finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using Diffie-Hellman
-   for key exchange. The server's public parameters are contained in the
-   server key exchange message and the client's are sent in the client
-   key exchange message. Eavesdroppers who do not know the private
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 88]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   values should not be able to find the Diffie-Hellman result (i.e. the
-   pre_master_secret).
-
-   Warning: Completely anonymous connections only provide protection
-   against passive eavesdropping. Unless an independent tamper-proof
-   channel is used to verify that the finished messages were not
-   replaced by an attacker, server authentication is required in
-   environments where active man-in-the-middle attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key. TLS
-   users desiring Perfect Forward Secrecy should use DHE cipher suites.
-   The damage done by exposure of a private key can be limited by
-   changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from all preceding handshake messages. These
-   handshake messages include the server certificate, which binds the
-   signature to the server, and ServerHello.random, which binds the
-   signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 89]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE cipher suites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly, therefore the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE cipher suites.
-
-   Because TLS allows the server to provide arbitrary DH groups, the
-   client should verify that the DH group is of suitable size as defined
-   by local policy. The client SHOULD also verify that the DH public
-   exponent appears to be of adequate size. [KEYSIZ] provides a useful
-   guide to the strength of various group sizes.  The server MAY choose
-   to assist the client by providing a known group, such as those
-   defined in [IKEALG] or [MODP]. These can be verified by simple
-   comparison.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Altering
-   the padding of the least significant 8 bytes of the PKCS padding does
-   not impact security for the size of the signed hashes and RSA key
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 90]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   lengths used in the protocol, since this is essentially equivalent to
-   increasing the input block size by 8 bytes.
-
-F.1.3. Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC keys are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations.
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC key, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 91]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64 bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC keys. Similarly, the server-write and
-   client-write keys are independent, so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
-   Note: MAC keys may be larger than encryption keys, so messages can
-   remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-   [CBCATT] describes a chosen plaintext attack on TLS that depends on
-   knowing the IV for a record. Previous versions of TLS [TLS1.0] used
-   the CBC residue of the previous record as the IV and therefore
-   enabled this attack. This version uses an explicit IV in order to
-   protect against this attack.
-
-F.4. Security of Composite Cipher Modes
-
-   TLS secures transmitted application data via the use of symmetric
-   encryption and authentication functions defined in the negotiated
-   cipher suite.  The objective is to protect both the integrity and
-   confidentiality of the transmitted data from malicious actions by
-   active attackers in the network.  It turns out that the order in
-   which encryption and authentication functions are applied to the data
-   plays an important role for achieving this goal [ENCAUTH].
-
-   The most robust method, called encrypt-then-authenticate, first
-   applies encryption to the data and then applies a MAC to the
-   ciphertext.  This method ensures that the integrity and
-   confidentiality goals are obtained with ANY pair of encryption and
-   MAC functions, provided that the former is secure against chosen
-   plaintext attacks and that the MAC is secure against chosen-message
-   attacks.  TLS uses another method, called authenticate-then-encrypt,
-   in which first a MAC is computed on the plaintext and then the
-   concatenation of plaintext and MAC is encrypted.  This method has
-   been proven secure for CERTAIN combinations of encryption functions
-   and MAC functions, but it is not guaranteed to be secure in general.
-   In particular, it has been shown that there exist perfectly secure
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 92]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   encryption functions (secure even in the information-theoretic sense)
-   that combined with any secure MAC function, fail to provide the
-   confidentiality goal against an active attack.  Therefore, new cipher
-   suites and operation modes adopted into TLS need to be analyzed under
-   the authenticate-then-encrypt method to verify that they achieve the
-   stated integrity and confidentiality goals.
-
-   Currently, the security of the authenticate-then-encrypt method has
-   been proven for some important cases.  One is the case of stream
-   ciphers in which a computationally unpredictable pad of the length of
-   the message, plus the length of the MAC tag, is produced using a
-   pseudo-random generator and this pad is xor-ed with the concatenation
-   of plaintext and MAC tag.  The other is the case of CBC mode using a
-   secure block cipher.  In this case, security can be shown if one
-   applies one CBC encryption pass to the concatenation of plaintext and
-   MAC and uses a new, independent, and unpredictable IV for each new
-   pair of plaintext and MAC.  In versions of TLS prior to 1.1, CBC mode
-   was used properly EXCEPT that it used a predictable IV in the form of
-   the last block of the previous ciphertext.  This made TLS open to
-   chosen plaintext attacks.  This version of the protocol is immune to
-   those attacks.  For exact details in the encryption modes proven
-   secure, see [ENCAUTH].
-
-F.5 Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption. However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections. In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6 Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 93]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   cryptographic functions should be used. Short public keys and
-   anonymous servers should be used with great caution. Implementations
-   and users must be careful when deciding which certificates and
-   certificate authorities are acceptable; a dishonest certificate
-   authority can do tremendous damage.
-
-Changes in This Version
-   [RFC Editor: Please delete this]
-
-   - Added a new pitfall about fragmenting messages when necessary
-     [Issue #71]
-
-   - Added Updates: RFC 4492 [Issue #83]
-
-   - Long CBC padding pitfall [Issue #73]
-
-   - Fixed ProtocolVersion structure [Issue #79]
-
-   - Cleaned up extensions text [Issue #78]
-
-   - Clarified alerts some [Issue #85]
-
-   - Added AES to the table in Appendix C [Issue #72]
-
-   - Tightened up when signature_algorithms is used
-     (it is now a MUST if you support other than SHA-1)
-     and the interpretation when it is absent is also a MUST
-     [Issue #67]
-
-   - Cleaned up "cipher suite" so it's always two words outside
-     of when it refers to the syntactic type [Issue #68]
-
-   - Misc editorial.
-
-   - Added support for SHA256 cipher suites
-
-   - Clarified warning alert behavior and client certificate omission
-   behavior [Issue #84]
-
-Normative References
-
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   National Institute of Standards and Technology,
-            "Recommendation for the Triple Data Encryption Algorithm
-            (TDEA) Block Cipher", NIST Special Publication 800-67, May
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 94]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-            2004.
-
-   [DES]    National Institute of Standards and Technology, "Data
-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication", RFC 2104, February
-            1997.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1]  J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
-            Public Key Infrastructure Certificate and Certificate
-            Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2nd ed.", Published by John Wiley &
-            Sons, Inc. 1996.
-
-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce., August 2001.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,
-            October 1998.
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "Authenticated Encryption", February 2007,
-            draft-mcgrew-auth-enc-02.txt.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            4302, December 2005.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 95]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
-            "Password Interception in a SSL/TLS Channel", Advances in
-            Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
-
-   [CCM]    "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/800-38C/
-            SP800-38C.pdf
-
-   [DSS-3]  NIST FIPS PUB 186-3 Draft, "Digital Signature Standard,"
-            National Institute of Standards and Technology, U.S.
-            Department of Commerce, 2006.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]    Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 4303, December 2005.
-
-   [FI06]   Hal Finney, "Bleichenbacher's RSA signature forgery based on
-            implementation error", ietf-openpgp@imc.org mailing list, 27
-            August 2006, http://www.imc.org/ietf-openpgp/mail-
-            archive/msg14307.html.
-
-   [GCM]    "NIST Special Publication 800-38D DRAFT (June, 2007):
-            Recommendation for Block Cipher Modes of Operation:
-            Galois/Counter Mode (GCM) and GMAC"
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
-            Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
-            2005.
-
-   [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
-            Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 96]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-            April 2004.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [MODP]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-            Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
-            3526, May 2003.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
-            Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, March 1998.
-
-   [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
-            Compression Methods", RFC 3749, May 2004.
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            4366, April 2006.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
-            Protocol", Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 97]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
-            Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
-            Suites for Transport Layer Security (TLS)", RFC 4492, May
-            2006.
-
-   [TLSEXT] Eastlake, D.E.,  "Transport Layer Security (TLS) Extensions:
-            Extension Definitions", July 2007, draft-ietf-tls-
-            rfc4366-bis-00.txt.
-
-   [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
-            authentication", RFC 5081, November 2007.
-
-   [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for
-            Transport Layer Security (TLS)", RFC 4279, December 2005.
-
-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
-            1.1", RFC 4346, April, 2006.
-
-   [X501]   ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [XDR]    Eisler, M., "External Data Representation Standard", RFC
-            4506, May 2006.
-
-
-Credits
-
-   Working Group Chairs
-
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 98]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Alfred Hoenes
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 99]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   IBM
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-   <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                  [Page 100]
-
-draft-ietf-tls-rfc4346-bis-08.txt  TLS                     January, 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                  [Page 101]
-
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-09.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-09.txt
deleted file mode 100644
index f6b6e2e374..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-09.txt
+++ /dev/null
@@ -1,5656 +0,0 @@
-INTERNET-DRAFT                                                Tim Dierks

-Obsoletes (if approved): RFC 3268, 4346, 4366                Independent

-Updates (if approved): RFC 4492                            Eric Rescorla

-Intended status:  Proposed Standard              Network Resonance, Inc.

-<draft-ietf-tls-rfc4346-bis-09.txt>  February 2008 (Expires August 2008)

-

-

-              The Transport Layer Security (TLS) Protocol

-                              Version 1.2

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups.  Note that

-   other groups may also distribute working documents as Internet-

-   Drafts.

-

-   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 IETF Trust (2008).

-

-Abstract

-

-   This document specifies Version 1.2 of the Transport Layer Security

-   (TLS) protocol. The TLS protocol provides communications security

-   over the Internet. The protocol allows client/server applications to

-   communicate in a way that is designed to prevent eavesdropping,

-   tampering, or message forgery.

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 1]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Table of Contents

-

-   1.        Introduction                                             4

-   1.1.      Requirements Terminology                                 5

-   1.2.      Major Differences from TLS 1.1                           5

-   2.        Goals                                                    6

-   3.        Goals of This Document                                   7

-   4.        Presentation Language                                    7

-   4.1.      Basic Block Size                                         7

-   4.2.      Miscellaneous                                            7

-   4.3.      Vectors                                                  8

-   4.4.      Numbers                                                  9

-   4.5.      Enumerateds                                              9

-   4.6.      Constructed Types                                        10

-   4.6.1.    Variants                                                 10

-   4.7.      Cryptographic Attributes                                 11

-   4.8.      Constants                                                13

-   5.        HMAC and the Pseudorandom Function                       14

-   6.        The TLS Record Protocol                                  15

-   6.1.      Connection States                                        16

-   6.2.      Record layer                                             18

-   6.2.1.    Fragmentation                                            19

-   6.2.2.    Record Compression and Decompression                     20

-   6.2.3.    Record Payload Protection                                21

-   6.2.3.1.  Null or Standard Stream Cipher                           21

-   6.2.3.2.  CBC Block Cipher                                         22

-   6.2.3.3.  AEAD ciphers                                             24

-   6.3.      Key Calculation                                          25

-   7.        The TLS Handshaking Protocols                            26

-   7.1.      Change Cipher Spec Protocol                              27

-   7.2.      Alert Protocol                                           27

-   7.2.1.    Closure Alerts                                           28

-   7.2.2.    Error Alerts                                             29

-   7.3.      Handshake Protocol Overview                              33

-   7.4.      Handshake Protocol                                       36

-   7.4.1.    Hello Messages                                           37

-   7.4.1.1.  Hello Request                                            37

-   7.4.1.2.  Client Hello                                             38

-   7.4.1.3.  Server Hello                                             41

-   7.4.1.4   Hello Extensions                                         42

-   7.4.1.4.1 Signature Algorithms                                     43

-   7.4.2.    Server Certificate                                       45

-   7.4.3.    Server Key Exchange Message                              47

-   7.4.4.    Certificate Request                                      50

-   7.4.5     Server hello done                                        51

-   7.4.6.    Client Certificate                                       52

-   7.4.7.    Client Key Exchange Message                              54

-   7.4.7.1.  RSA Encrypted Premaster Secret Message                   54

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 2]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   7.4.7.2.  Client Diffie-Hellman Public Value                       57

-   7.4.8.    Certificate verify                                       58

-   7.4.9.    Finished                                                 58

-   8.        Cryptographic Computations                               60

-   8.1.      Computing the Master Secret                              60

-   8.1.1.    RSA                                                      61

-   8.1.2.    Diffie-Hellman                                           61

-   9.        Mandatory Cipher Suites                                  61

-   10.       Application Data Protocol                                61

-   11.       Security Considerations                                  61

-   12.       IANA Considerations                                      61

-   A.        Protocol Constant Values                                 64

-   A.1.      Record Layer                                             64

-   A.2.      Change Cipher Specs Message                              65

-   A.3.      Alert Messages                                           65

-   A.4.      Handshake Protocol                                       66

-   A.4.1.    Hello Messages                                           66

-   A.4.2.    Server Authentication and Key Exchange Messages          68

-   A.4.3.    Client Authentication and Key Exchange Messages          69

-   A.4.4.    Handshake Finalization Message                           70

-   A.5.      The Cipher Suite                                         70

-   A.6.      The Security Parameters                                  72

-   A.7.      Changes to RFC 4492                                      73

-   B.        Glossary                                                 73

-   C.        Cipher Suite Definitions                                 78

-   D.        Implementation Notes                                     80

-   D.1       Random Number Generation and Seeding                     80

-   D.2       Certificates and Authentication                          80

-   D.3       Cipher Suites                                            80

-   D.4       Implementation Pitfalls                                  80

-   E.        Backward Compatibility                                   83

-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0               83

-   E.2       Compatibility with SSL 2.0                               84

-   E.3.      Avoiding Man-in-the-Middle Version Rollback              86

-   F.        Security Analysis                                        87

-   F.1.      Handshake Protocol                                       87

-   F.1.1.    Authentication and Key Exchange                          87

-   F.1.1.1.  Anonymous Key Exchange                                   87

-   F.1.1.2.  RSA Key Exchange and Authentication                      88

-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication          88

-   F.1.2.    Version Rollback Attacks                                 89

-   F.1.3.    Detecting Attacks Against the Handshake Protocol         90

-   F.1.4.    Resuming Sessions                                        90

-   F.2.      Protecting Application Data                              90

-   F.3.      Explicit IVs                                             91

-   F.4.      Security of Composite Cipher Modes                       91

-   F.5       Denial of Service                                        92

-   F.6       Final Notes                                              92

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 3]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-1. Introduction

-

-   The primary goal of the TLS Protocol is to provide privacy and data

-   integrity between two communicating applications. The protocol is

-   composed of two layers: the TLS Record Protocol and the TLS Handshake

-   Protocol. At the lowest level, layered on top of some reliable

-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The

-   TLS Record Protocol provides connection security that has two basic

-   properties:

-

-   -  The connection is private. Symmetric cryptography is used for

-      data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for

-      this symmetric encryption are generated uniquely for each

-      connection and are based on a secret negotiated by another

-      protocol (such as the TLS Handshake Protocol). The Record Protocol

-      can also be used without encryption.

-

-   -  The connection is reliable. Message transport includes a message

-      integrity check using a keyed MAC. Secure hash functions (e.g.,

-      SHA, MD5, etc.) are used for MAC computations. The Record Protocol

-      can operate without a MAC, but is generally only used in this mode

-      while another protocol is using the Record Protocol as a transport

-      for negotiating security parameters.

-

-   The TLS Record Protocol is used for encapsulation of various higher-

-   level protocols. One such encapsulated protocol, the TLS Handshake

-   Protocol, allows the server and client to authenticate each other and

-   to negotiate an encryption algorithm and cryptographic keys before

-   the application protocol transmits or receives its first byte of

-   data. The TLS Handshake Protocol provides connection security that

-   has three basic properties:

-

-   -  The peer's identity can be authenticated using asymmetric, or

-      public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This

-      authentication can be made optional, but is generally required for

-      at least one of the peers.

-

-   -  The negotiation of a shared secret is secure: the negotiated

-      secret is unavailable to eavesdroppers, and for any authenticated

-      connection the secret cannot be obtained, even by an attacker who

-      can place himself in the middle of the connection.

-

-   -  The negotiation is reliable: no attacker can modify the

-      negotiation communication without being detected by the parties to

-      the communication.

-

-   One advantage of TLS is that it is application protocol independent.

-   Higher-level protocols can layer on top of the TLS Protocol

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 4]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   transparently. The TLS standard, however, does not specify how

-   protocols add security with TLS; the decisions on how to initiate TLS

-   handshaking and how to interpret the authentication certificates

-   exchanged are left to the judgment of the designers and implementors

-   of protocols that run on top of TLS.

-

-1.1. Requirements Terminology

-

-   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 [REQ].

-

-1.2. Major Differences from TLS 1.1

-

-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which

-   contains improved flexibility, particularly for negotiation of

-   cryptographic algorithms. The major changes are:

-

-   -  The MD5/SHA-1 combination in the PRF has been replaced with cipher

-      suite specified PRFs. All cipher suites in this document use

-      P_SHA256.

-

-   -  The MD5/SHA-1 combination in the digitally-signed element has been

-      replaced with a single hash. Signed elements now include a field

-      that explicitly specifies the hash algorithm used.

-

-   -  Substantial cleanup to the clients and servers ability to specify

-      which hash and signature algorithms they will accept. Note that

-      this also relaxes some of the constraints on signature and hash

-      algorithms from previous versions of TLS.

-

-   -  Addition of support for authenticated encryption with additional

-      data modes.

-

-   -  TLS Extensions definition and AES Cipher Suites were merged in

-      from external [TLSEXT] and [TLSAES].

-

-   -  Tighter checking of EncryptedPreMasterSecret version numbers.

-

-   -  Tightened up a number of requirements.

-

-   -  Verify_data length now depends on the cipher suite (default is

-      still 12).

-

-   -  Cleaned up description of Bleichenbacher/Klima attack defenses.

-

-   -  Alerts MUST now be sent in many cases.

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 5]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   -  After a certificate_request, if no certificates are available,

-      clients now MUST send an empty certificate list.

-

-   -  TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement

-      cipher suite.

-

-   -  Added HMAC-SHA256 cipher suites

-

-   -  Removed IDEA and DES cipher suites. They are now deprecated and

-      will be documented in a separate document.

-

-   -  Support for the SSLv2 backward-compatible hello is now a MAY, not

-      a SHOULD, with sending it a SHOULD not.  Support will probably

-      become a SHOULD NOT in the future.

-

-   - Added limited "fall-through" to the presentation language to allow

-      multiple case arms to have the same encoding.

-

-   -  Added an Implementation Pitfalls sections

-

-   -  The usual clarifications and editorial work.

-

-2. Goals

-

-   The goals of TLS Protocol, in order of their priority, are as

-   follows:

-

-   1. Cryptographic security: TLS should be used to establish a secure

-      connection between two parties.

-

-   2. Interoperability: Independent programmers should be able to

-      develop applications utilizing TLS that can successfully exchange

-      cryptographic parameters without knowledge of one another's code.

-

-   3. Extensibility: TLS seeks to provide a framework into which new

-      public key and bulk encryption methods can be incorporated as

-      necessary. This will also accomplish two sub-goals: preventing the

-      need to create a new protocol (and risking the introduction of

-      possible new weaknesses) and avoiding the need to implement an

-      entire new security library.

-

-   4. Relative efficiency: Cryptographic operations tend to be highly

-      CPU intensive, particularly public key operations. For this

-      reason, the TLS protocol has incorporated an optional session

-      caching scheme to reduce the number of connections that need to be

-      established from scratch. Additionally, care has been taken to

-      reduce network activity.

-

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 6]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-3. Goals of This Document

-

-   This document and the TLS protocol itself are based on the SSL 3.0

-   Protocol Specification as published by Netscape. The differences

-   between this protocol and SSL 3.0 are not dramatic, but they are

-   significant enough that the various versions of TLS and SSL 3.0 do

-   not interoperate (although each protocol incorporates a mechanism by

-   which an implementation can back down to prior versions). This

-   document is intended primarily for readers who will be implementing

-   the protocol and for those doing cryptographic analysis of it. The

-   specification has been written with this in mind, and it is intended

-   to reflect the needs of those two groups. For that reason, many of

-   the algorithm-dependent data structures and rules are included in the

-   body of the text (as opposed to in an appendix), providing easier

-   access to them.

-

-   This document is not intended to supply any details of service

-   definition or of interface definition, although it does cover select

-   areas of policy as they are required for the maintenance of solid

-   security.

-

-

-4. Presentation Language

-

-   This document deals with the formatting of data in an external

-   representation. The following very basic and somewhat casually

-   defined presentation syntax will be used. The syntax draws from

-   several sources in its structure. Although it resembles the

-   programming language "C" in its syntax and XDR [XDR] in both its

-   syntax and intent, it would be risky to draw too many parallels. The

-   purpose of this presentation language is to document TLS only; it has

-   no general application beyond that particular goal.

-

-4.1. Basic Block Size

-

-   The representation of all data items is explicitly specified. The

-   basic data block size is one byte (i.e., 8 bits). Multiple byte data

-   items are concatenations of bytes, from left to right, from top to

-   bottom. From the bytestream, a multi-byte item (a numeric in the

-   example) is formed (using C notation) by:

-

-      value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |

-              ... | byte[n-1];

-

-   This byte ordering for multi-byte values is the commonplace network

-   byte order or big endian format.

-

-4.2. Miscellaneous

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 7]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   Comments begin with "/*" and end with "*/".

-

-   Optional components are denoted by enclosing them in "[[ ]]" double

-   brackets.

-

-   Single-byte entities containing uninterpreted data are of type

-   opaque.

-

-4.3. Vectors

-

-   A vector (single dimensioned array) is a stream of homogeneous data

-   elements. The size of the vector may be specified at documentation

-   time or left unspecified until runtime. In either case, the length

-   declares the number of bytes, not the number of elements, in the

-   vector. The syntax for specifying a new type, T', that is a fixed-

-   length vector of type T is

-

-      T T'[n];

-

-   Here, T' occupies n bytes in the data stream, where n is a multiple

-   of the size of T. The length of the vector is not included in the

-   encoded stream.

-

-   In the following example, Datum is defined to be three consecutive

-   bytes that the protocol does not interpret, while Data is three

-   consecutive Datum, consuming a total of nine bytes.

-

-      opaque Datum[3];      /* three uninterpreted bytes */

-      Datum Data[9];        /* 3 consecutive 3 byte vectors */

-

-   Variable-length vectors are defined by specifying a subrange of legal

-   lengths, inclusively, using the notation <floor..ceiling>.  When

-   these are encoded, the actual length precedes the vector's contents

-   in the byte stream. The length will be in the form of a number

-   consuming as many bytes as required to hold the vector's specified

-   maximum (ceiling) length. A variable-length vector with an actual

-   length field of zero is referred to as an empty vector.

-

-      T T'<floor..ceiling>;

-

-   In the following example, mandatory is a vector that must contain

-   between 300 and 400 bytes of type opaque. It can never be empty. The

-   actual length field consumes two bytes, a uint16, sufficient to

-   represent the value 400 (see Section 4.4). On the other hand, longer

-   can represent up to 800 bytes of data, or 400 uint16 elements, and it

-   may be empty. Its encoding will include a two-byte actual length

-   field prepended to the vector. The length of an encoded vector must

-   be an even multiple of the length of a single element (for example, a

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 8]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   17-byte vector of uint16 would be illegal).

-

-      opaque mandatory<300..400>;

-            /* length field is 2 bytes, cannot be empty */

-      uint16 longer<0..800>;

-            /* zero to 400 16-bit unsigned integers */

-

-4.4. Numbers

-

-   The basic numeric data type is an unsigned byte (uint8). All larger

-   numeric data types are formed from fixed-length series of bytes

-   concatenated as described in Section 4.1 and are also unsigned. The

-   following numeric types are predefined.

-

-      uint8 uint16[2];

-      uint8 uint24[3];

-      uint8 uint32[4];

-      uint8 uint64[8];

-

-   All values, here and elsewhere in the specification, are stored in

-   "network" or "big-endian" order; the uint32 represented by the hex

-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.

-

-   Note that in some cases (e.g., DH parameters) it is necessary to

-   represent integers as opaque vectors. In such cases, they are

-   represented as unsigned integers (i.e., leading zero octets are not

-   required even if the most significant bit is set).

-

-4.5. Enumerateds

-

-   An additional sparse data type is available called enum. A field of

-   type enum can only assume the values declared in the definition.

-   Each definition is a different type. Only enumerateds of the same

-   type may be assigned or compared. Every element of an enumerated must

-   be assigned a value, as demonstrated in the following example.  Since

-   the elements of the enumerated are not ordered, they can be assigned

-   any unique value, in any order.

-

-      enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

-

-   Enumerateds occupy as much space in the byte stream as would its

-   maximal defined ordinal value. The following definition would cause

-   one byte to be used to carry fields of type Color.

-

-      enum { red(3), blue(5), white(7) } Color;

-

-   One may optionally specify a value without its associated tag to

-   force the width definition without defining a superfluous element.

-

-

-

-Dierks & Rescorla            Standards Track                    [Page 9]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   In the following example, Taste will consume two bytes in the data

-   stream but can only assume the values 1, 2, or 4.

-

-      enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

-

-   The names of the elements of an enumeration are scoped within the

-   defined type. In the first example, a fully qualified reference to

-   the second element of the enumeration would be Color.blue. Such

-   qualification is not required if the target of the assignment is well

-   specified.

-

-      Color color = Color.blue;     /* overspecified, legal */

-      Color color = blue;           /* correct, type implicit */

-

-   For enumerateds that are never converted to external representation,

-   the numerical information may be omitted.

-

-      enum { low, medium, high } Amount;

-

-4.6. Constructed Types

-

-   Structure types may be constructed from primitive types for

-   convenience. Each specification declares a new, unique type. The

-   syntax for definition is much like that of C.

-

-      struct {

-          T1 f1;

-          T2 f2;

-          ...

-          Tn fn;

-      } [[T]];

-

-   The fields within a structure may be qualified using the type's name,

-   with a syntax much like that available for enumerateds. For example,

-   T.f2 refers to the second field of the previous declaration.

-   Structure definitions may be embedded.

-

-4.6.1. Variants

-

-   Defined structures may have variants based on some knowledge that is

-   available within the environment. The selector must be an enumerated

-   type that defines the possible variants the structure defines. There

-   must be a case arm for every element of the enumeration declared in

-   the select. Case arms have limited fall-through: if two case arms

-   follow in immediate succession with no fields in between, then they

-   both contain the same fields.  Thus, in the example below, "orange"

-   and "banana" both contain V2. Note that this is a new piece of syntax

-   in TLS 1.2.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 10]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   The body of the variant structure may be given a label for reference.

-   The mechanism by which the variant is selected at runtime is not

-   prescribed by the presentation language.

-

-      struct {

-          T1 f1;

-          T2 f2;

-          ....

-          Tn fn;

-           select (E) {

-               case e1: Te1;

-               case e2: Te2;

-               case e3: case e4: Te3;

-               ....

-               case en: Ten;

-           } [[fv]];

-      } [[Tv]];

-

-   For example:

-

-      enum { apple, orange, banana } VariantTag;

-

-      struct {

-          uint16 number;

-          opaque string<0..10>; /* variable length */

-      } V1;

-

-      struct {

-          uint32 number;

-          opaque string[10];    /* fixed length */

-      } V2;

-

-      struct {

-          select (VariantTag) { /* value of selector is implicit */

-              case apple:

-                V1;   /* VariantBody, tag = apple */

-              case orange:

-           case banana:

-                V2;   /* VariantBody, tag = orange or banana */

-          } variant_body;       /* optional label on variant */

-      } VariantRecord;

-

-

-4.7. Cryptographic Attributes

-

-   The five cryptographic operations digital signing, stream cipher

-   encryption, block cipher encryption, authenticated encryption with

-   additional data (AEAD) encryption and public key encryption are

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 11]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   designated digitally-signed, stream-ciphered, block-ciphered, aead-

-   ciphered, and public-key-encrypted, respectively. A field's

-   cryptographic processing is specified by prepending an appropriate

-   key word designation before the field's type specification.

-   Cryptographic keys are implied by the current session state (see

-   Section 6.1).

-

-   A digitally-signed element is encoded as a struct DigitallySigned:

-

-       struct {

-          SignatureAndHashAlgorithm algorithm;

-          opaque signature<0..2^16-1>;

-       } DigitallySigned;

-

-   The algorithm field specifies the algorithm used (see Section

-   7.4.1.4.1 for the definition of this field.)  Note that the

-   introduction of the algorithm field is a change from previous

-   versions.  The signature is a digital signature using those

-   algorithms over the contents of the element. The contents themselves

-   do not appear on the wire but are simply calculated.  The length of

-   the signature is specified by the signing algorithm and key.

-

-   In RSA signing, the opaque vector contains the signature generated

-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As

-   discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash

-   algorithms without parameters (which include SHA-1) the

-   DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but

-   implementations MUST accept both without parameters and with NULL

-   parameters. Note that earlier versions of TLS used a different RSA

-   signature scheme which did not include a DigestInfo encoding.

-

-   In DSS, the 20 bytes of the SHA-1 hash are run directly through the

-   Digital Signing Algorithm with no additional hashing. This produces

-   two values, r and s. The DSS signature is an opaque vector, as above,

-   the contents of which are the DER encoding of:

-

-      Dss-Sig-Value ::= SEQUENCE {

-          r INTEGER,

-          s INTEGER

-      }

-

-   Note: In current terminology, DSA refers to the Digital Signature

-   Algorithm and DSS refers to the NIST standard. For historical

-   reasons, this document uses DSS and DSA interchangeably

-   to refer to the DSA algorithm, as was done in SSLv3.

-

-   In stream cipher encryption, the plaintext is exclusive-ORed with an

-   identical amount of output generated from a cryptographically secure

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 12]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   keyed pseudorandom number generator.

-

-   In block cipher encryption, every block of plaintext encrypts to a

-   block of ciphertext. All block cipher encryption is done in CBC

-   (Cipher Block Chaining) mode, and all items that are block-ciphered

-   will be an exact multiple of the cipher block length.

-

-   In AEAD encryption, the plaintext is simultaneously encrypted and

-   integrity protected. The input may be of any length and aead-ciphered

-   output is generally larger than the input in order to accomodate the

-   integrity check value.

-

-   In public key encryption, a public key algorithm is used to encrypt

-   data in such a way that it can be decrypted only with the matching

-   private key. A public-key-encrypted element is encoded as an opaque

-   vector <0..2^16-1>, where the length is specified by the encryption

-   algorithm and key.

-

-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme

-   defined in [PKCS1].

-

-   In the following example

-

-      stream-ciphered struct {

-          uint8 field1;

-          uint8 field2;

-          digitally-signed opaque {

-         uint8 field3<0..255>;

-         uint8 field4;

-          };

-      } UserType;

-

-

-   The contents of the inner struct (field3 and field4) are used as

-   input for the signature/hash algorithm, and then the entire structure

-   is encrypted with a stream cipher. The length of this structure, in

-   bytes, would be equal to two bytes for field1 and field2, plus two

-   bytes for the signature and hash algorithm, plus two bytes for the

-   length of the signature, plus the length of the output of the signing

-   algorithm. This is known because the algorithm and key used for the

-   signing are known prior to encoding or decoding this structure.

-

-4.8. Constants

-

-   Typed constants can be defined for purposes of specification by

-   declaring a symbol of the desired type and assigning values to it.

-   Under-specified types (opaque, variable length vectors, and

-   structures that contain opaque) cannot be assigned values. No fields

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 13]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   of a multi-element structure or vector may be elided.

-

-   For example:

-

-      struct {

-          uint8 f1;

-          uint8 f2;

-      } Example1;

-

-      Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */

-

-

-5. HMAC and the Pseudorandom Function

-

-   The TLS record layer uses a keyed Message Authentication Code (MAC)

-   to protect message integrity. The cipher suites defined in this

-   document use a construction known as HMAC, described in [HMAC], which

-   is based on a hash function. Other cipher suites MAY define their own

-   MAC constructions, if needed.

-

-   In addition, a construction is required to do expansion of secrets

-   into blocks of data for the purposes of key generation or validation.

-   This pseudo-random function (PRF) takes as input a secret, a seed,

-   and an identifying label and produces an output of arbitrary length.

-

-   In this section, we define one PRF, based on HMAC. This PRF with the

-   SHA-256 hash function is used for all cipher suites defined in this

-   document and in TLS documents published prior to this document when

-   TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a

-   PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger

-   standard hash function.

-

-   First, we define a data expansion function, P_hash(secret, data) that

-   uses a single hash function to expand a secret and seed into an

-   arbitrary quantity of output:

-

-      P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +

-                             HMAC_hash(secret, A(2) + seed) +

-                             HMAC_hash(secret, A(3) + seed) + ...

-

-   Where + indicates concatenation.

-

-   A() is defined as:

-

-      A(0) = seed

-      A(i) = HMAC_hash(secret, A(i-1))

-

-   P_hash can be iterated as many times as is necessary to produce the

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 14]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   required quantity of data. For example, if P_SHA256 is being used to

-   create 80 bytes of data, it will have to be iterated three times

-   (through A(3)), creating 96 bytes of output data; the last 16 bytes

-   of the final iteration will then be discarded, leaving 80 bytes of

-   output data.

-

-   TLS's PRF is created by applying P_hash to the secret as:

-

-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)

-

-   The label is an ASCII string. It should be included in the exact form

-   it is given without a length byte or trailing null character.  For

-   example, the label "slithy toves" would be processed by hashing the

-   following bytes:

-

-      73 6C 69 74 68 79 20 74 6F 76 65 73

-

-

-6. The TLS Record Protocol

-

-   The TLS Record Protocol is a layered protocol. At each layer,

-   messages may include fields for length, description, and content.

-   The Record Protocol takes messages to be transmitted, fragments the

-   data into manageable blocks, optionally compresses the data, applies

-   a MAC, encrypts, and transmits the result. Received data is

-   decrypted, verified, decompressed, reassembled, and then delivered to

-   higher-level clients.

-

-   Four record protocol clients are described in this document: the

-   handshake protocol, the alert protocol, the change cipher spec

-   protocol, and the application data protocol. In order to allow

-   extension of the TLS protocol, additional record types can be

-   supported by the record protocol. New record type values are assigned

-   by IANA as described in Section 12.

-

-   Implementations MUST NOT send record types not defined in this

-   document unless negotiated by some extension.  If a TLS

-   implementation receives an unexpected record type, it MUST send an

-   unexpected_message alert.

-

-   Any protocol designed for use over TLS MUST be carefully designed to

-   deal with all possible attacks against it.  Note that because the

-   type and length of a record are not protected by encryption, care

-   SHOULD be taken to minimize the value of traffic analysis of these

-   values.

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 15]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-6.1. Connection States

-

-   A TLS connection state is the operating environment of the TLS Record

-   Protocol. It specifies a compression algorithm, an encryption

-   algorithm, and a MAC algorithm. In addition, the parameters for these

-   algorithms are known: the MAC key and the bulk encryption keys for

-   the connection in both the read and the write directions. Logically,

-   there are always four connection states outstanding: the current read

-   and write states, and the pending read and write states. All records

-   are processed under the current read and write states. The security

-   parameters for the pending states can be set by the TLS Handshake

-   Protocol, and the Change Cipher Spec can selectively make either of

-   the pending states current, in which case the appropriate current

-   state is disposed of and replaced with the pending state; the pending

-   state is then reinitialized to an empty state. It is illegal to make

-   a state that has not been initialized with security parameters a

-   current state. The initial current state always specifies that no

-   encryption, compression, or MAC will be used.

-

-   The security parameters for a TLS Connection read and write state are

-   set by providing the following values:

-

-   connection end

-      Whether this entity is considered the "client" or the "server" in

-      this connection.

-

-   PRF algorithm

-      An algorithm used to generate keys from the master secret (see

-      Sections 5 and 6.3).

-

-   bulk encryption algorithm

-      An algorithm to be used for bulk encryption. This specification

-      includes the key size of this algorithm, whether it is a block,

-      stream, or AEAD cipher, the block size of the cipher (if

-      appropriate), and the lengths of explicit and implicit

-      initialization vectors (or nonces).

-

-   MAC algorithm

-      An algorithm to be used for message authentication. This

-      specification includes the size of the value returned by the MAC

-      algorithm.

-

-   compression algorithm

-      An algorithm to be used for data compression. This specification

-      must include all information the algorithm requires to do

-      compression.

-

-   master secret

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 16]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      A 48-byte secret shared between the two peers in the connection.

-

-   client random

-      A 32-byte value provided by the client.

-

-   server random

-      A 32-byte value provided by the server.

-

-   These parameters are defined in the presentation language as:

-

-      enum { server, client } ConnectionEnd;

-

-      enum { tls_prf_sha256 } PRFAlgorithm;

-

-      enum { null, rc4, 3des, aes }

-        BulkCipherAlgorithm;

-

-      enum { stream, block, aead } CipherType;

-

-      enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,

-           hmac_sha512} MACAlgorithm;

-

-      /* The use of "sha" above is historical and denotes SHA-1 */

-

-      enum { null(0), (255) } CompressionMethod;

-

-      /* The algorithms specified in CompressionMethod,

-         BulkCipherAlgorithm, and MACAlgorithm may be added to. */

-

-      struct {

-          ConnectionEnd          entity;

-          PRFAlgorithm           prf_algorithm;

-          BulkCipherAlgorithm    bulk_cipher_algorithm;

-          CipherType             cipher_type;

-          uint8                  enc_key_length;

-          uint8                  block_length;

-          uint8                  fixed_iv_length;

-          uint8                  record_iv_length;

-          MACAlgorithm           mac_algorithm;

-          uint8                  mac_length;

-          uint8                  mac_key_length;

-          CompressionMethod      compression_algorithm;

-          opaque                 master_secret[48];

-          opaque                 client_random[32];

-          opaque                 server_random[32];

-      } SecurityParameters;

-

-   The record layer will use the security parameters to generate the

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 17]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   following six items (some of which are not required by all ciphers,

-   and are thus empty):

-

-      client write MAC key

-      server write MAC key

-      client write encryption key

-      server write encryption key

-      client write IV

-      server write IV

-

-   The client write parameters are used by the server when receiving and

-   processing records and vice-versa. The algorithm used for generating

-   these items from the security parameters is described in Section 6.3.

-

-   Once the security parameters have been set and the keys have been

-   generated, the connection states can be instantiated by making them

-   the current states. These current states MUST be updated for each

-   record processed. Each connection state includes the following

-   elements:

-

-   compression state

-      The current state of the compression algorithm.

-

-   cipher state

-      The current state of the encryption algorithm. This will consist

-      of the scheduled key for that connection. For stream ciphers, this

-      will also contain whatever state information is necessary to allow

-      the stream to continue to encrypt or decrypt data.

-

-   MAC key

-      The MAC key for this connection, as generated above.

-

-   sequence number

-      Each connection state contains a sequence number, which is

-      maintained separately for read and write states. The sequence

-      number MUST be set to zero whenever a connection state is made the

-      active state. Sequence numbers are of type uint64 and may not

-      exceed 2^64-1. Sequence numbers do not wrap. If a TLS

-      implementation would need to wrap a sequence number, it must

-      renegotiate instead. A sequence number is incremented after each

-      record: specifically, the first record transmitted under a

-      particular connection state MUST use sequence number 0.

-

-6.2. Record layer

-

-   The TLS Record Layer receives uninterpreted data from higher layers

-   in non-empty blocks of arbitrary size.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 18]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-6.2.1. Fragmentation

-

-   The record layer fragments information blocks into TLSPlaintext

-   records carrying data in chunks of 2^14 bytes or less. Client message

-   boundaries are not preserved in the record layer (i.e., multiple

-   client messages of the same ContentType MAY be coalesced into a

-   single TLSPlaintext record, or a single message MAY be fragmented

-   across several records).

-

-      struct {

-          uint8 major;

-          uint8 minor;

-      } ProtocolVersion;

-

-      enum {

-          change_cipher_spec(20), alert(21), handshake(22),

-          application_data(23), (255)

-      } ContentType;

-

-      struct {

-          ContentType type;

-          ProtocolVersion version;

-          uint16 length;

-          opaque fragment[TLSPlaintext.length];

-      } TLSPlaintext;

-

-   type

-      The higher-level protocol used to process the enclosed fragment.

-

-   version

-      The version of the protocol being employed. This document

-      describes TLS Version 1.2, which uses the version { 3, 3 }. The

-      version value 3.3 is historical, deriving from the use of 3.1 for

-      TLS 1.0. (See Appendix A.1).  Note that a client that supports

-      multiple versions of TLS may not know what version will be

-      employed before it receives the ServerHello.  See Appendix E for

-      discussion about what record layer version number should be

-      employed for ClientHello.

-

-   length

-      The length (in bytes) of the following TLSPlaintext.fragment.  The

-      length MUST NOT exceed 2^14.

-

-   fragment

-      The application data. This data is transparent and treated as an

-      independent block to be dealt with by the higher-level protocol

-      specified by the type field.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 19]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   Implementations MUST NOT send zero-length fragments of Handshake,

-   Alert, or Change Cipher Spec content types. Zero-length fragments of

-   Application data MAY be sent as they are potentially useful as a

-   traffic analysis countermeasure.

-

-   Note: Data of different TLS Record layer content types MAY be

-   interleaved.  Application data is generally of lower precedence for

-   transmission than other content types.  However, records MUST be

-   delivered to the network in the same order as they are protected by

-   the record layer.  Recipients MUST receive and process interleaved

-   application layer traffic during handshakes subsequent to the first

-   one on a connection.

-

-6.2.2. Record Compression and Decompression

-

-   All records are compressed using the compression algorithm defined in

-   the current session state. There is always an active compression

-   algorithm; however, initially it is defined as

-   CompressionMethod.null. The compression algorithm translates a

-   TLSPlaintext structure into a TLSCompressed structure. Compression

-   functions are initialized with default state information whenever a

-   connection state is made active.

-

-   Compression must be lossless and may not increase the content length

-   by more than 1024 bytes. If the decompression function encounters a

-   TLSCompressed.fragment that would decompress to a length in excess of

-   2^14 bytes, it MUST report a fatal decompression failure error.

-

-      struct {

-          ContentType type;       /* same as TLSPlaintext.type */

-          ProtocolVersion version;/* same as TLSPlaintext.version */

-          uint16 length;

-          opaque fragment[TLSCompressed.length];

-      } TLSCompressed;

-

-   length

-      The length (in bytes) of the following TLSCompressed.fragment.

-      The length MUST NOT exceed 2^14 + 1024.

-

-   fragment

-      The compressed form of TLSPlaintext.fragment.

-

-   Note: A CompressionMethod.null operation is an identity operation; no

-   fields are altered.

-

-   Implementation note: Decompression functions are responsible for

-   ensuring that messages cannot cause internal buffer overflows.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 20]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-6.2.3. Record Payload Protection

-

-   The encryption and MAC functions translate a TLSCompressed structure

-   into a TLSCiphertext. The decryption functions reverse the process.

-   The MAC of the record also includes a sequence number so that

-   missing, extra, or repeated messages are detectable.

-

-      struct {

-          ContentType type;

-          ProtocolVersion version;

-          uint16 length;

-          select (SecurityParameters.cipher_type) {

-              case stream: GenericStreamCipher;

-              case block:  GenericBlockCipher;

-              case aead:   GenericAEADCipher;

-          } fragment;

-      } TLSCiphertext;

-

-   type

-      The type field is identical to TLSCompressed.type.

-

-   version

-      The version field is identical to TLSCompressed.version.

-

-   length

-      The length (in bytes) of the following TLSCiphertext.fragment.

-      The length MUST NOT exceed 2^14 + 2048.

-

-   fragment

-      The encrypted form of TLSCompressed.fragment, with the MAC.

-

-6.2.3.1. Null or Standard Stream Cipher

-

-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)

-   convert TLSCompressed.fragment structures to and from stream

-   TLSCiphertext.fragment structures.

-

-      stream-ciphered struct {

-          opaque content[TLSCompressed.length];

-          opaque MAC[SecurityParameters.mac_length];

-      } GenericStreamCipher;

-

-   The MAC is generated as:

-

-      MAC(MAC_write_key, seq_num +

-                            TLSCompressed.type +

-                            TLSCompressed.version +

-                            TLSCompressed.length +

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 21]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-                            TLSCompressed.fragment);

-

-   where "+" denotes concatenation.

-

-   seq_num

-      The sequence number for this record.

-

-   MAC

-      The MAC algorithm specified by SecurityParameters.mac_algorithm.

-

-   Note that the MAC is computed before encryption. The stream cipher

-   encrypts the entire block, including the MAC. For stream ciphers that

-   do not use a synchronization vector (such as RC4), the stream cipher

-   state from the end of one record is simply used on the subsequent

-   packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption

-   consists of the identity operation (i.e., the data is not encrypted,

-   and the MAC size is zero, implying that no MAC is used).

-   TLSCiphertext.length is TLSCompressed.length plus

-   SecurityParameters.mac_length.

-

-6.2.3.2. CBC Block Cipher

-

-   For block ciphers (such as 3DES, or AES), the encryption and MAC

-   functions convert TLSCompressed.fragment structures to and from block

-   TLSCiphertext.fragment structures.

-

-      struct {

-          opaque IV[SecurityParameters.record_iv_length];

-          block-ciphered struct {

-              opaque content[TLSCompressed.length];

-              opaque MAC[SecurityParameters.mac_length];

-              uint8 padding[GenericBlockCipher.padding_length];

-              uint8 padding_length;

-          };

-      } GenericBlockCipher;

-

-   The MAC is generated as described in Section 6.2.3.1.

-

-   IV

-      The Initialization Vector (IV) SHOULD be chosen at random, and

-      MUST be unpredictable. Note that in versions of TLS prior to 1.1,

-      there was no IV field, and the last ciphertext block of the

-      previous record (the "CBC residue") was used as the IV. This was

-      changed to prevent the attacks described in [CBCATT]. For block

-      ciphers, the IV length is of length

-      SecurityParameters.record_iv_length which is equal to the

-      SecurityParameters.block_size.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 22]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   padding

-      Padding that is added to force the length of the plaintext to be

-      an integral multiple of the block cipher's block length. The

-      padding MAY be any length up to 255 bytes, as long as it results

-      in the TLSCiphertext.length being an integral multiple of the

-      block length. Lengths longer than necessary might be desirable to

-      frustrate attacks on a protocol that are based on analysis of the

-      lengths of exchanged messages. Each uint8 in the padding data

-      vector MUST be filled with the padding length value. The receiver

-      MUST check this padding and MUST use the bad_record_mac alert to

-      indicate padding errors.

-

-   padding_length

-      The padding length MUST be such that the total size of the

-      GenericBlockCipher structure is a multiple of the cipher's block

-      length. Legal values range from zero to 255, inclusive. This

-      length specifies the length of the padding field exclusive of the

-      padding_length field itself.

-

-   The encrypted data length (TLSCiphertext.length) is one more than the

-   sum of SecurityParameters.block_length, TLSCompressed.length,

-   SecurityParameters.mac_length, and padding_length.

-

-   Example: If the block length is 8 bytes, the content length

-   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,

-   then the length before padding is 82 bytes (this does not include the

-   IV. Thus, the padding length modulo 8 must be equal to 6 in order to

-   make the total length an even multiple of 8 bytes (the block length).

-   The padding length can be 6, 14, 22, and so on, through 254. If the

-   padding length were the minimum necessary, 6, the padding would be 6

-   bytes, each containing the value 6.  Thus, the last 8 octets of the

-   GenericBlockCipher before block encryption would be xx 06 06 06 06 06

-   06 06, where xx is the last octet of the MAC.

-

-   Note: With block ciphers in CBC mode (Cipher Block Chaining), it is

-   critical that the entire plaintext of the record be known before any

-   ciphertext is transmitted. Otherwise, it is possible for the attacker

-   to mount the attack described in [CBCATT].

-

-   Implementation Note: Canvel et al. [CBCTIME] have demonstrated a

-   timing attack on CBC padding based on the time required to compute

-   the MAC. In order to defend against this attack, implementations MUST

-   ensure that record processing time is essentially the same whether or

-   not the padding is correct.  In general, the best way to do this is

-   to compute the MAC even if the padding is incorrect, and only then

-   reject the packet. For instance, if the pad appears to be incorrect,

-   the implementation might assume a zero-length pad and then compute

-   the MAC. This leaves a small timing channel, since MAC performance

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 23]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   depends to some extent on the size of the data fragment, but it is

-   not believed to be large enough to be exploitable, due to the large

-   block size of existing MACs and the small size of the timing signal.

-

-6.2.3.3. AEAD ciphers

-

-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function

-   converts TLSCompressed.fragment structures to and from AEAD

-   TLSCiphertext.fragment structures.

-

-      struct {

-         opaque nonce_explicit[SecurityParameters.record_iv_length];

-         aead-ciphered struct {

-             opaque content[TLSCompressed.length];

-         };

-      } GenericAEADCipher;

-

-   AEAD ciphers take as input a single key, a nonce, a plaintext, and

-   "additional data" to be included in the authentication check, as

-   described in Section 2.1 of [AEAD]. The key is either the

-   client_write_key or the server_write_key.  No MAC key is used.

-

-   Each AEAD cipher suite MUST specify how the nonce supplied to the

-   AEAD operation is constructed, and what is the length of the

-   GenericAEADCipher.nonce_explicit part. In many cases, it is

-   appropriate to use the partially implicit nonce technique described

-   in Section 3.2.1 of [AEAD]; with record_iv_length being the length of

-   the explicit part. In this case, the implicit part SHOULD be derived

-   from key_block as client_write_iv and server_write_iv (as described

-   in Section 6.3), and the explicit part is included in

-   GenericAEAEDCipher.nonce_explicit.

-

-   The plaintext is the TLSCompressed.fragment.

-

-   The additional authenticated data, which we denote as

-   additional_data, is defined as follows:

-

-      additional_data = seq_num + TLSCompressed.type +

-                        TLSCompressed.version + TLSCompressed.length;

-

-   Where "+" denotes concatenation.

-

-   The aead_output consists of the ciphertext output by the AEAD

-   encryption operation.  The length will generally be larger than

-   TLSCompressed.length, but by an amount that varies with the AEAD

-   cipher.  Since the ciphers might incorporate padding, the amount of

-   overhead could vary with different TLSCompressed.length values.  Each

-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 24]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   Symbolically,

-

-      AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext,

-                                   additional_data)

-

-   In order to decrypt and verify, the cipher takes as input the key,

-   nonce, the "additional_data", and the AEADEncrypted value. The output

-   is either the plaintext or an error indicating that the decryption

-   failed. There is no separate integrity check.  I.e.,

-

-      TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,

-                                            AEADEncrypted,

-                                            additional_data)

-

-

-   If the decryption fails, a fatal bad_record_mac alert MUST be

-   generated.

-

-6.3. Key Calculation

-

-   The Record Protocol requires an algorithm to generates keys required

-   by the current connection state (see Appendix A.6) from the security

-   parameters provided by the handshake protocol.

-

-   The master secret is expanded into a sequence of secure bytes, which

-   is then split to a client write MAC key, a server write MAC key, a

-   client write encryption key, and a server write encryption key. Each

-   of these is generated from the byte sequence in that order.  Unused

-   values are empty.  Some AEAD ciphers may additionally require a

-   client write IV and a server write IV (see Section 6.2.3.3).

-

-   When keys and MAC keys are generated, the master secret is used as an

-   entropy source.

-

-   To generate the key material, compute

-

-      key_block = PRF(SecurityParameters.master_secret,

-                      "key expansion",

-                      SecurityParameters.server_random +

-                      SecurityParameters.client_random);

-

-   until enough output has been generated. Then the key_block is

-   partitioned as follows:

-

-      client_write_MAC_key[SecurityParameters.mac_key_length]

-      server_write_MAC_key[SecurityParameters.mac_key_length]

-      client_write_key[SecurityParameters.enc_key_length]

-      server_write_key[SecurityParameters.enc_key_length]

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 25]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      client_write_IV[SecurityParameters.fixed_iv_length]

-      server_write_IV[SecurityParameters.fixed_iv_length]

-

-   Currently, the client_write_IV and server_write_IV are only generated

-   for implicit nonce techniques as described in Section 3.2.1 of

-   [AEAD].

-

-   Implementation note: The currently defined cipher suite which

-   requires the most material is AES_256_CBC_SHA256. It requires 2 x 32

-   byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key

-   material.

-

-7. The TLS Handshaking Protocols

-

-   TLS has three subprotocols that are used to allow peers to agree upon

-   security parameters for the record layer, to authenticate themselves,

-   to instantiate negotiated security parameters, and to report error

-   conditions to each other.

-

-   The Handshake Protocol is responsible for negotiating a session,

-   which consists of the following items:

-

-   session identifier

-      An arbitrary byte sequence chosen by the server to identify an

-      active or resumable session state.

-

-   peer certificate

-      X509v3 [PKIX] certificate of the peer. This element of the state

-      may be null.

-

-   compression method

-      The algorithm used to compress data prior to encryption.

-

-   cipher spec

-      Specifies the bulk data encryption algorithm (such as null, DES,

-      etc.) and a MAC algorithm (such as MD5 or SHA). It also defines

-      cryptographic attributes such as the mac_length. (See Appendix A.6

-      for formal definition.)

-

-   master secret

-      48-byte secret shared between the client and server.

-

-   is resumable

-      A flag indicating whether the session can be used to initiate new

-      connections.

-

-   These items are then used to create security parameters for use by

-   the Record Layer when protecting application data. Many connections

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 26]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   can be instantiated using the same session through the resumption

-   feature of the TLS Handshake Protocol.

-

-7.1. Change Cipher Spec Protocol

-

-   The change cipher spec protocol exists to signal transitions in

-   ciphering strategies. The protocol consists of a single message,

-   which is encrypted and compressed under the current (not the pending)

-   connection state. The message consists of a single byte of value 1.

-

-      struct {

-          enum { change_cipher_spec(1), (255) } type;

-      } ChangeCipherSpec;

-

-   The change cipher spec message is sent by both the client and the

-   server to notify the receiving party that subsequent records will be

-   protected under the newly negotiated CipherSpec and keys. Reception

-   of this message causes the receiver to instruct the Record Layer to

-   immediately copy the read pending state into the read current state.

-   Immediately after sending this message, the sender MUST instruct the

-   record layer to make the write pending state the write active state.

-   (See Section 6.1.) The change cipher spec message is sent during the

-   handshake after the security parameters have been agreed upon, but

-   before the verifying finished message is sent.

-

-   Note: If a rehandshake occurs while data is flowing on a connection,

-   the communicating parties may continue to send data using the old

-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new

-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec

-   does not know that the other side has finished computing the new

-   keying material (e.g., if it has to perform a time consuming public

-   key operation). Thus, a small window of time, during which the

-   recipient must buffer the data, MAY exist. In practice, with modern

-   machines this interval is likely to be fairly short.

-

-7.2. Alert Protocol

-

-   One of the content types supported by the TLS Record layer is the

-   alert type. Alert messages convey the severity of the message and a

-   description of the alert. Alert messages with a level of fatal result

-   in the immediate termination of the connection. In this case, other

-   connections corresponding to the session may continue, but the

-   session identifier MUST be invalidated, preventing the failed session

-   from being used to establish new connections. Like other messages,

-   alert messages are encrypted and compressed, as specified by the

-   current connection state.

-

-      enum { warning(1), fatal(2), (255) } AlertLevel;

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 27]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      enum {

-          close_notify(0),

-          unexpected_message(10),

-          bad_record_mac(20),

-          decryption_failed_RESERVED(21),

-          record_overflow(22),

-          decompression_failure(30),

-          handshake_failure(40),

-          no_certificate_RESERVED(41),

-          bad_certificate(42),

-          unsupported_certificate(43),

-          certificate_revoked(44),

-          certificate_expired(45),

-          certificate_unknown(46),

-          illegal_parameter(47),

-          unknown_ca(48),

-          access_denied(49),

-          decode_error(50),

-          decrypt_error(51),

-          export_restriction_RESERVED(60),

-          protocol_version(70),

-          insufficient_security(71),

-          internal_error(80),

-          user_canceled(90),

-          no_renegotiation(100),

-          unsupported_extension(110),

-          (255)

-      } AlertDescription;

-

-      struct {

-          AlertLevel level;

-          AlertDescription description;

-      } Alert;

-

-7.2.1. Closure Alerts

-

-   The client and the server must share knowledge that the connection is

-   ending in order to avoid a truncation attack. Either party may

-   initiate the exchange of closing messages.

-

-   close_notify

-       This message notifies the recipient that the sender will not send

-       any more messages on this connection. Note that as of TLS 1.1,

-       failure to properly close a connection no longer requires that a

-       session not be resumed. This is a change from TLS 1.0 to conform

-       with widespread implementation practice.

-

-   Either party may initiate a close by sending a close_notify alert.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 28]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   Any data received after a closure alert is ignored.

-

-   Unless some other fatal alert has been transmitted, each party is

-   required to send a close_notify alert before closing the write side

-   of the connection. The other party MUST respond with a close_notify

-   alert of its own and close down the connection immediately,

-   discarding any pending writes. It is not required for the initiator

-   of the close to wait for the responding close_notify alert before

-   closing the read side of the connection.

-

-   If the application protocol using TLS provides that any data may be

-   carried over the underlying transport after the TLS connection is

-   closed, the TLS implementation must receive the responding

-   close_notify alert before indicating to the application layer that

-   the TLS connection has ended. If the application protocol will not

-   transfer any additional data, but will only close the underlying

-   transport connection, then the implementation MAY choose to close the

-   transport without waiting for the responding close_notify. No part of

-   this standard should be taken to dictate the manner in which a usage

-   profile for TLS manages its data transport, including when

-   connections are opened or closed.

-

-   Note: It is assumed that closing a connection reliably delivers

-   pending data before destroying the transport.

-

-7.2.2. Error Alerts

-

-   Error handling in the TLS Handshake protocol is very simple. When an

-   error is detected, the detecting party sends a message to the other

-   party.  Upon transmission or receipt of a fatal alert message, both

-   parties immediately close the connection. Servers and clients MUST

-   forget any session-identifiers, keys, and secrets associated with a

-   failed connection. Thus, any connection terminated with a fatal alert

-   MUST NOT be resumed.

-

-   Whenever an implementation encounters a condition which is defined as

-   a fatal alert, it MUST send the appropriate alert prior to closing

-   the connection. For all errors where an alert level is not explicitly

-   specified, the sending party MAY determine at its discretion whether

-   to treat this as a fatal error or not. If the implementation chooses

-   to send an alert but intends to close the connection immediately

-   afterwards, it MUST send that alert at the fatal alert level.

-

-   If an alert with a level of warning is sent and received, generally

-   the connection can continue normally.  If the receiving party decides

-   not to proceed with the connection (e.g., after having received a

-   no_renegotiation alert that it is not willing to accept), it SHOULD

-   send a fatal alert to terminate the connection. Given this, the

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 29]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   sending party cannot, in general, know how the receiving party will

-   behave. Therefore, warning alerts are not very useful when the

-   sending party wants to continue the connection, and thus are

-   sometimes omitted. For example, if a peer decides to accept an

-   expired certificate (perhaps after confirming this with the user) and

-   wants to continue the connection, it would not generally send a

-   certificate_expired alert.

-

-   The following error alerts are defined:

-

-   unexpected_message

-      An inappropriate message was received. This alert is always fatal

-      and should never be observed in communication between proper

-      implementations.

-

-   bad_record_mac

-      This alert is returned if a record is received with an incorrect

-      MAC. This alert also MUST be returned if an alert is sent because

-      a TLSCiphertext decrypted in an invalid way: either it wasn't an

-      even multiple of the block length, or its padding values, when

-      checked, weren't correct. This message is always fatal and should

-      never be observed in communication between proper implementations

-      (except when messages were corrupted in the network).

-

-   decryption_failed_RESERVED

-      This alert was used in some earlier versions of TLS, and may have

-      permitted certain attacks against the CBC mode [CBCATT].  It MUST

-      NOT be sent by compliant implementations.

-

-   record_overflow

-      A TLSCiphertext record was received that had a length more than

-      2^14+2048 bytes, or a record decrypted to a TLSCompressed record

-      with more than 2^14+1024 bytes. This message is always fatal and

-      should never be observed in communication between proper

-      implementations (except when messages were corrupted in the

-      network).

-

-   decompression_failure

-      The decompression function received improper input (e.g., data

-      that would expand to excessive length). This message is always

-      fatal and should never be observed in communication between proper

-      implementations.

-

-   handshake_failure

-      Reception of a handshake_failure alert message indicates that the

-      sender was unable to negotiate an acceptable set of security

-      parameters given the options available. This is a fatal error.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 30]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   no_certificate_RESERVED

-      This alert was used in SSLv3 but not any version of TLS.  It MUST

-      NOT be sent by compliant implementations.

-

-   bad_certificate

-      A certificate was corrupt, contained signatures that did not

-      verify correctly, etc.

-

-   unsupported_certificate

-      A certificate was of an unsupported type.

-

-   certificate_revoked

-      A certificate was revoked by its signer.

-

-   certificate_expired

-      A certificate has expired or is not currently valid.

-

-   certificate_unknown

-      Some other (unspecified) issue arose in processing the

-      certificate, rendering it unacceptable.

-

-   illegal_parameter

-      A field in the handshake was out of range or inconsistent with

-      other fields. This message is always fatal.

-

-   unknown_ca

-      A valid certificate chain or partial chain was received, but the

-      certificate was not accepted because the CA certificate could not

-      be located or couldn't be matched with a known, trusted CA.  This

-      message is always fatal.

-

-   access_denied

-      A valid certificate was received, but when access control was

-      applied, the sender decided not to proceed with negotiation.  This

-      message is always fatal.

-

-   decode_error

-      A message could not be decoded because some field was out of the

-      specified range or the length of the message was incorrect. This

-      message is always fatal and should never be observed in

-      communication between proper implementations (except when messages

-      were corrupted in the network).

-

-

-   decrypt_error

-      A handshake cryptographic operation failed, including being unable

-      to correctly verify a signature or validate a finished message.

-      This message is always fatal.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 31]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   export_restriction_RESERVED

-      This alert was used in some earlier versions of TLS.  It MUST NOT

-      be sent by compliant implementations.

-

-   protocol_version

-      The protocol version the client has attempted to negotiate is

-      recognized but not supported. (For example, old protocol versions

-      might be avoided for security reasons). This message is always

-      fatal.

-

-   insufficient_security

-      Returned instead of handshake_failure when a negotiation has

-      failed specifically because the server requires ciphers more

-      secure than those supported by the client. This message is always

-      fatal.

-

-   internal_error

-      An internal error unrelated to the peer or the correctness of the

-      protocol (such as a memory allocation failure) makes it impossible

-      to continue. This message is always fatal.

-

-   user_canceled

-      This handshake is being canceled for some reason unrelated to a

-      protocol failure. If the user cancels an operation after the

-      handshake is complete, just closing the connection by sending a

-      close_notify is more appropriate. This alert should be followed by

-      a close_notify. This message is generally a warning.

-

-   no_renegotiation

-      Sent by the client in response to a hello request or by the server

-      in response to a client hello after initial handshaking.  Either

-      of these would normally lead to renegotiation; when that is not

-      appropriate, the recipient should respond with this alert.  At

-      that point, the original requester can decide whether to proceed

-      with the connection. One case where this would be appropriate is

-      where a server has spawned a process to satisfy a request; the

-      process might receive security parameters (key length,

-      authentication, etc.) at startup and it might be difficult to

-      communicate changes to these parameters after that point. This

-      message is always a warning.

-

-   unsupported_extension

-      sent by clients that receive an extended server hello containing

-      an extension that they did not put in the corresponding client

-      hello. This message is always fatal.

-

-   New Alert values are assigned by IANA as described in Section 12.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 32]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-7.3. Handshake Protocol Overview

-

-   The cryptographic parameters of the session state are produced by the

-   TLS Handshake Protocol, which operates on top of the TLS Record

-   Layer. When a TLS client and server first start communicating, they

-   agree on a protocol version, select cryptographic algorithms,

-   optionally authenticate each other, and use public-key encryption

-   techniques to generate shared secrets.

-

-   The TLS Handshake Protocol involves the following steps:

-

-   -  Exchange hello messages to agree on algorithms, exchange random

-      values, and check for session resumption.

-

-   -  Exchange the necessary cryptographic parameters to allow the

-      client and server to agree on a premaster secret.

-

-   -  Exchange certificates and cryptographic information to allow the

-      client and server to authenticate themselves.

-

-   -  Generate a master secret from the premaster secret and exchanged

-      random values.

-

-   -  Provide security parameters to the record layer.

-

-   -  Allow the client and server to verify that their peer has

-      calculated the same security parameters and that the handshake

-      occurred without tampering by an attacker.

-

-   Note that higher layers should not be overly reliant on whether TLS

-   always negotiates the strongest possible connection between two

-   peers.  There are a number of ways in which a man in the middle

-   attacker can attempt to make two entities drop down to the least

-   secure method they support. The protocol has been designed to

-   minimize this risk, but there are still attacks available: for

-   example, an attacker could block access to the port a secure service

-   runs on, or attempt to get the peers to negotiate an unauthenticated

-   connection. The fundamental rule is that higher levels must be

-   cognizant of what their security requirements are and never transmit

-   information over a channel less secure than what they require. The

-   TLS protocol is secure in that any cipher suite offers its promised

-   level of security: if you negotiate 3DES with a 1024 bit RSA key

-   exchange with a host whose certificate you have verified, you can

-   expect to be that secure.

-

-   These goals are achieved by the handshake protocol, which can be

-   summarized as follows: The client sends a client hello message to

-   which the server must respond with a server hello message, or else a

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 33]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   fatal error will occur and the connection will fail. The client hello

-   and server hello are used to establish security enhancement

-   capabilities between client and server. The client hello and server

-   hello establish the following attributes: Protocol Version, Session

-   ID, Cipher Suite, and Compression Method. Additionally, two random

-   values are generated and exchanged: ClientHello.random and

-   ServerHello.random.

-

-   The actual key exchange uses up to four messages: the server

-   certificate, the server key exchange, the client certificate, and the

-   client key exchange. New key exchange methods can be created by

-   specifying a format for these messages and by defining the use of the

-   messages to allow the client and server to agree upon a shared

-   secret. This secret MUST be quite long; currently defined key

-   exchange methods exchange secrets that range from 46 bytes upwards.

-

-   Following the hello messages, the server will send its certificate,

-   if it is to be authenticated. Additionally, a server key exchange

-   message may be sent, if it is required (e.g., if their server has no

-   certificate, or if its certificate is for signing only). If the

-   server is authenticated, it may request a certificate from the

-   client, if that is appropriate to the cipher suite selected. Next,

-   the server will send the server hello done message, indicating that

-   the hello-message phase of the handshake is complete. The server will

-   then wait for a client response. If the server has sent a certificate

-   request message, the client MUST send the certificate message. The

-   client key exchange message is now sent, and the content of that

-   message will depend on the public key algorithm selected between the

-   client hello and the server hello. If the client has sent a

-   certificate with signing ability, a digitally-signed certificate

-   verify message is sent to explicitly verify possession of the private

-   key in the certificate.

-

-   At this point, a change cipher spec message is sent by the client,

-   and the client copies the pending Cipher Spec into the current Cipher

-   Spec. The client then immediately sends the finished message under

-   the new algorithms, keys, and secrets. In response, the server will

-   send its own change cipher spec message, transfer the pending to the

-   current Cipher Spec, and send its finished message under the new

-   Cipher Spec. At this point, the handshake is complete, and the client

-   and server may begin to exchange application layer data. (See flow

-   chart below.) Application data MUST NOT be sent prior to the

-   completion of the first handshake (before a cipher suite other than

-   TLS_NULL_WITH_NULL_NULL is established).

-

-      Client                                               Server

-

-      ClientHello                  -------->

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 34]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-                                                      ServerHello

-                                                     Certificate*

-                                               ServerKeyExchange*

-                                              CertificateRequest*

-                                   <--------      ServerHelloDone

-      Certificate*

-      ClientKeyExchange

-      CertificateVerify*

-      [ChangeCipherSpec]

-      Finished                     -------->

-                                               [ChangeCipherSpec]

-                                   <--------             Finished

-      Application Data             <------->     Application Data

-

-             Fig. 1. Message flow for a full handshake

-

-   * Indicates optional or situation-dependent messages that are not

-   always sent.

-

-   Note: To help avoid pipeline stalls, ChangeCipherSpec is an

-   independent TLS Protocol content type, and is not actually a TLS

-   handshake message.

-

-   When the client and server decide to resume a previous session or

-   duplicate an existing session (instead of negotiating new security

-   parameters), the message flow is as follows:

-

-   The client sends a ClientHello using the Session ID of the session to

-   be resumed. The server then checks its session cache for a match.  If

-   a match is found, and the server is willing to re-establish the

-   connection under the specified session state, it will send a

-   ServerHello with the same Session ID value. At this point, both

-   client and server MUST send change cipher spec messages and proceed

-   directly to finished messages. Once the re-establishment is complete,

-   the client and server MAY begin to exchange application layer data.

-   (See flow chart below.) If a Session ID match is not found, the

-   server generates a new session ID and the TLS client and server

-   perform a full handshake.

-

-      Client                                                Server

-

-      ClientHello                   -------->

-                                                       ServerHello

-                                                [ChangeCipherSpec]

-                                    <--------             Finished

-      [ChangeCipherSpec]

-      Finished                      -------->

-      Application Data              <------->     Application Data

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 35]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-          Fig. 2. Message flow for an abbreviated handshake

-

-   The contents and significance of each message will be presented in

-   detail in the following sections.

-

-7.4. Handshake Protocol

-

-   The TLS Handshake Protocol is one of the defined higher-level clients

-   of the TLS Record Protocol. This protocol is used to negotiate the

-   secure attributes of a session. Handshake messages are supplied to

-   the TLS Record Layer, where they are encapsulated within one or more

-   TLSPlaintext structures, which are processed and transmitted as

-   specified by the current active session state.

-

-      enum {

-          hello_request(0), client_hello(1), server_hello(2),

-          certificate(11), server_key_exchange (12),

-          certificate_request(13), server_hello_done(14),

-          certificate_verify(15), client_key_exchange(16),

-          finished(20), (255)

-      } HandshakeType;

-

-      struct {

-          HandshakeType msg_type;    /* handshake type */

-          uint24 length;             /* bytes in message */

-          select (HandshakeType) {

-              case hello_request:       HelloRequest;

-              case client_hello:        ClientHello;

-              case server_hello:        ServerHello;

-              case certificate:         Certificate;

-              case server_key_exchange: ServerKeyExchange;

-              case certificate_request: CertificateRequest;

-              case server_hello_done:   ServerHelloDone;

-              case certificate_verify:  CertificateVerify;

-              case client_key_exchange: ClientKeyExchange;

-              case finished:            Finished;

-          } body;

-      } Handshake;

-

-   The handshake protocol messages are presented below in the order they

-   MUST be sent; sending handshake messages in an unexpected order

-   results in a fatal error. Unneeded handshake messages can be omitted,

-   however. Note one exception to the ordering: the Certificate message

-   is used twice in the handshake (from server to client, then from

-   client to server), but described only in its first position. The one

-   message that is not bound by these ordering rules is the Hello

-   Request message, which can be sent at any time, but which SHOULD be

-   ignored by the client if it arrives in the middle of a handshake.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 36]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   New Handshake message types are assigned by IANA as described in

-   Section 12.

-

-7.4.1. Hello Messages

-

-   The hello phase messages are used to exchange security enhancement

-   capabilities between the client and server. When a new session

-   begins, the Record Layer's connection state encryption, hash, and

-   compression algorithms are initialized to null. The current

-   connection state is used for renegotiation messages.

-

-7.4.1.1. Hello Request

-

-   When this message will be sent:

-

-      The hello request message MAY be sent by the server at any time.

-

-   Meaning of this message:

-

-      Hello request is a simple notification that the client should

-      begin the negotiation process anew by sending a client hello

-      message when convenient. This message is not intended to establish

-      which side is the client or server but merely to initiate a new

-      negotiation. Servers SHOULD NOT send a HelloRequest immediately

-      upon the client's initial connection.  It is the client's job to

-      send a ClientHello at that time.

-

-      This message will be ignored by the client if the client is

-      currently negotiating a session. This message may be ignored by

-      the client if it does not wish to renegotiate a session, or the

-      client may, if it wishes, respond with a no_renegotiation alert.

-      Since handshake messages are intended to have transmission

-      precedence over application data, it is expected that the

-      negotiation will begin before no more than a few records are

-      received from the client. If the server sends a hello request but

-      does not receive a client hello in response, it may close the

-      connection with a fatal alert.

-

-      After sending a hello request, servers SHOULD NOT repeat the

-      request until the subsequent handshake negotiation is complete.

-

-   Structure of this message:

-

-      struct { } HelloRequest;

-

-   Note: This message MUST NOT be included in the message hashes that

-   are maintained throughout the handshake and used in the finished

-   messages and the certificate verify message.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 37]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-7.4.1.2. Client Hello

-

-   When this message will be sent:

-

-      When a client first connects to a server it is required to send

-      the client hello as its first message. The client can also send a

-      client hello in response to a hello request or on its own

-      initiative in order to renegotiate the security parameters in an

-      existing connection.

-

-   Structure of this message:

-

-      The client hello message includes a random structure, which is

-      used later in the protocol.

-

-         struct {

-             uint32 gmt_unix_time;

-             opaque random_bytes[28];

-         } Random;

-

-      gmt_unix_time

-         The current time and date in standard UNIX 32-bit format

-         (seconds since the midnight starting Jan 1, 1970, GMT, ignoring

-         leap seconds) according to the sender's internal clock. Clocks

-         are not required to be set correctly by the basic TLS Protocol;

-         higher-level or application protocols may define additional

-         requirements.

-

-      random_bytes

-         28 bytes generated by a secure random number generator.

-

-   The client hello message includes a variable-length session

-   identifier. If not empty, the value identifies a session between the

-   same client and server whose security parameters the client wishes to

-   reuse. The session identifier MAY be from an earlier connection, this

-   connection, or from another currently active connection. The second

-   option is useful if the client only wishes to update the random

-   structures and derived values of a connection, and the third option

-   makes it possible to establish several independent secure connections

-   without repeating the full handshake protocol. These independent

-   connections may occur sequentially or simultaneously; a SessionID

-   becomes valid when the handshake negotiating it completes with the

-   exchange of Finished messages and persists until it is removed due to

-   aging or because a fatal error was encountered on a connection

-   associated with the session. The actual contents of the SessionID are

-   defined by the server.

-

-      opaque SessionID<0..32>;

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 38]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   Warning: Because the SessionID is transmitted without encryption or

-   immediate MAC protection, servers MUST NOT place confidential

-   information in session identifiers or let the contents of fake

-   session identifiers cause any breach of security. (Note that the

-   content of the handshake as a whole, including the SessionID, is

-   protected by the Finished messages exchanged at the end of the

-   handshake.)

-

-   The cipher suite list, passed from the client to the server in the

-   client hello message, contains the combinations of cryptographic

-   algorithms supported by the client in order of the client's

-   preference (favorite choice first). Each cipher suite defines a key

-   exchange algorithm, a bulk encryption algorithm (including secret key

-   length), a MAC algorithm, and a PRF.  The server will select a cipher

-   suite or, if no acceptable choices are presented, return a handshake

-   failure alert and close the connection.  If the list contains cipher

-   suites the server does not recognize, support, or wish to use, the

-   server MUST ignore those cipher suites, and process the remaining

-   ones as usual.

-

-      uint8 CipherSuite[2];    /* Cryptographic suite selector */

-

-   The client hello includes a list of compression algorithms supported

-   by the client, ordered according to the client's preference.

-

-      enum { null(0), (255) } CompressionMethod;

-

-      struct {

-          ProtocolVersion client_version;

-          Random random;

-          SessionID session_id;

-          CipherSuite cipher_suites<2..2^16-2>;

-          CompressionMethod compression_methods<1..2^8-1>;

-          select (extensions_present) {

-              case false:

-                  struct {};

-              case true:

-                  Extension extensions<0..2^16-1>;

-          };

-      } ClientHello;

-

-   TLS allows extensions to follow the compression_methods field in an

-   extensions block. The presence of extensions can be detected by

-   determining whether there are bytes following the compression_methods

-   at the end of the ClientHello. Note that this method of detecting

-   optional data differs from the normal TLS method of having a

-   variable-length field but is used for compatibility with TLS before

-   extensions were defined.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 39]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   client_version

-      The version of the TLS protocol by which the client wishes to

-      communicate during this session. This SHOULD be the latest

-      (highest valued) version supported by the client. For this version

-      of the specification, the version will be 3.3 (See Appendix E for

-      details about backward compatibility).

-

-   random

-      A client-generated random structure.

-

-   session_id

-      The ID of a session the client wishes to use for this connection.

-      This field is empty if no session_id is available, or it the

-      client wishes to generate new security parameters.

-

-   cipher_suites

-      This is a list of the cryptographic options supported by the

-      client, with the client's first preference first. If the

-      session_id field is not empty (implying a session resumption

-      request) this vector MUST include at least the cipher_suite from

-      that session. Values are defined in Appendix A.5.

-

-   compression_methods

-      This is a list of the compression methods supported by the client,

-      sorted by client preference. If the session_id field is not empty

-      (implying a session resumption request) it MUST include the

-      compression_method from that session. This vector MUST contain,

-      and all implementations MUST support, CompressionMethod.null.

-      Thus, a client and server will always be able to agree on a

-      compression method.

-

-   extensions

-      Clients MAY request extended functionality from servers by sending

-      data in the extensions Here the new "extensions" field contains a

-      list of extensions.  The actual "Extension" format is defined in

-      Section 7.4.1.4.

-

-   In the event that a client requests additional functionality using

-   extensions, and this functionality is not supplied by the server, the

-   client MAY abort the handshake.  A server MUST accept client hello

-   messages both with and without the extensions field, and (as for all

-   other messages) MUST check that the amount of data in the message

-   precisely matches one of these formats; if not, then it MUST send a

-   fatal "decode_error" alert.

-

-   After sending the client hello message, the client waits for a server

-   hello message. Any other handshake message returned by the server

-   except for a hello request is treated as a fatal error.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 40]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-7.4.1.3. Server Hello

-

-   When this message will be sent:

-

-      The server will send this message in response to a client hello

-      message when it was able to find an acceptable set of algorithms.

-      If it cannot find such a match, it will respond with a handshake

-      failure alert.

-

-   Structure of this message:

-

-      struct {

-          ProtocolVersion server_version;

-          Random random;

-          SessionID session_id;

-          CipherSuite cipher_suite;

-          CompressionMethod compression_method;

-          select (extensions_present) {

-              case false:

-                  struct {};

-              case true:

-                  Extension extensions<0..2^16-1>;

-          };

-      } ServerHello;

-

-   The presence of extensions can be detected by determining whether

-   there are bytes following the compression_method field at the end of

-   the ServerHello.

-

-   server_version

-      This field will contain the lower of that suggested by the client

-      in the client hello and the highest supported by the server. For

-      this version of the specification, the version is 3.3.  (See

-      Appendix E for details about backward compatibility.)

-

-   random

-      This structure is generated by the server and MUST be

-      independently generated from the ClientHello.random.

-

-   session_id

-      This is the identity of the session corresponding to this

-      connection. If the ClientHello.session_id was non-empty, the

-      server will look in its session cache for a match. If a match is

-      found and the server is willing to establish the new connection

-      using the specified session state, the server will respond with

-      the same value as was supplied by the client. This indicates a

-      resumed session and dictates that the parties must proceed

-      directly to the finished messages. Otherwise this field will

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 41]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      contain a different value identifying the new session. The server

-      may return an empty session_id to indicate that the session will

-      not be cached and therefore cannot be resumed. If a session is

-      resumed, it must be resumed using the same cipher suite it was

-      originally negotiated with. Note that there is no requirement that

-      the server resume any session even if it had formerly provided a

-      session_id. Client MUST be prepared to do a full negotiation --

-      including negotiating new cipher suites -- during any handshake.

-

-   cipher_suite

-      The single cipher suite selected by the server from the list in

-      ClientHello.cipher_suites. For resumed sessions, this field is the

-      value from the state of the session being resumed.

-

-   compression_method

-      The single compression algorithm selected by the server from the

-      list in ClientHello.compression_methods. For resumed sessions this

-      field is the value from the resumed session state.

-

-   extensions

-      A list of extensions. Note that only extensions offered by the

-      client can appear in the server's list.

-

-7.4.1.4 Hello Extensions

-

-   The extension format is:

-

-      struct {

-          ExtensionType extension_type;

-          opaque extension_data<0..2^16-1>;

-      } Extension;

-

-      enum {

-          signature_algorithms(TBD-BY-IANA), (65535)

-      } ExtensionType;

-

-   Here:

-

-   -  "extension_type" identifies the particular extension type.

-

-   -  "extension_data" contains information specific to the particular

-      extension type.

-

-   The initial set of extensions is defined in a companion document

-   [TLSEXT]. The list of extension types is maintained by IANA as

-   described in Section 12.

-

-   There are subtle (and not so subtle) interactions that may occur in

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 42]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   this protocol between new features and existing features which may

-   result in a significant reduction in overall security, The following

-   considerations should be taken into account when designing new

-   extensions:

-

-   -  Some cases where a server does not agree to an extension are error

-      conditions, and some simply a refusal to support a particular

-      feature.  In general error alerts should be used for the former,

-      and a field in the server extension response for the latter.

-

-   -  Extensions should as far as possible be designed to prevent any

-      attack that forces use (or non-use) of a particular feature by

-      manipulation of handshake messages.  This principle should be

-      followed regardless of whether the feature is believed to cause a

-      security problem.

-

-      Often the fact that the extension fields are included in the

-      inputs to the Finished message hashes will be sufficient, but

-      extreme care is needed when the extension changes the meaning of

-      messages sent in the handshake phase. Designers and implementors

-      should be aware of the fact that until the handshake has been

-      authenticated, active attackers can modify messages and insert,

-      remove, or replace extensions.

-

-   -  It would be technically possible to use extensions to change major

-      aspects of the design of TLS; for example the design of cipher

-      suite negotiation.  This is not recommended; it would be more

-      appropriate to define a new version of TLS - particularly since

-      the TLS handshake algorithms have specific protection against

-      version rollback attacks based on the version number, and the

-      possibility of version rollback should be a significant

-      consideration in any major design change.

-

-7.4.1.4.1 Signature Algorithms

-

-   The client uses the "signature_algorithms" extension to indicate to

-   the server which signature/hash algorithm pairs may be used in

-   digital signatures. The "extension_data" field of this extension

-   contains a "supported_signature_algorithms" value.

-

-      enum {

-          none(0), md5(1), sha1(2), sha256(3), sha384(4),

-          sha512(5), (255)

-      } HashAlgorithm;

-

-      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }

-        SignatureAlgorithm;

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 43]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      struct {

-            HashAlgorithm hash;

-            SignatureAlgorithm signature;

-      } SignatureAndHashAlgorithm;

-

-      SignatureAndHashAlgorithm

-        supported_signature_algorithms<2..2^16-2>;

-

-   Each SignatureAndHashAlgorithm value lists a single hash/signature

-   pair which the client is willing to verify. The values are indicated

-   in descending order of preference.

-

-   Note: Because not all signature algorithms and hash algorithms may be

-   accepted by an implementation (e.g., DSA with SHA-1, but not

-   SHA-256), algorithms here are listed in pairs.

-

-   hash

-      This field indicates the hash algorithm which may be used. The

-      values indicate support for unhashed data, MD5 [MD5], SHA-1,

-      SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value

-      is provided for future extensibility, in case of a signature

-      algorithm which does not require hashing before signing.

-

-   signature

-      This field indicates the signature algorithm which may be used.

-      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5

-      [PKCS1] and DSA [DSS] respectively. The "anonymous" value is

-      meaningless in this context but used in Section 7.4.3. It MUST NOT

-      appear in this extension.

-

-   The semantics of this extension are somewhat complicated because the

-   cipher suite indicates permissible signature algorithms but not hash

-   algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.

-

-   If the client supports only the default hash and signature algorithms

-   (listed in this section), it MAY omit the signature_algorithms

-   extension. If the client does not support the default algorithms, or

-   supports other hash and signature algorithms (and it is willing to

-   use them for verifying messages sent by server; server certificates

-   and server key exchange), it MUST send the signature_algorithms

-   extension listing the algorithms it is willing to accept.

-

-   If the client does not send the signature_algorithms extension, the

-   server MUST assume the following:

-

-   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,

-   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent

-   the value (sha1,rsa).

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 44]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   -  If the negotiated key exchange algorithm is one of (DHE_DSS,

-   DH_DSS), behave as if the client had sent the value (sha1,dsa).

-

-   -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,

-   ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).

-

-   Note: this is a change from TLS 1.1 where there are no explicit rules

-   but as a practical matter one can assume that the peer supports MD5

-   and SHA-1.

-

-   Note: this extension is not meaningful for TLS versions prior to 1.2.

-   Clients MUST NOT offer it if they are offering prior versions.

-   However, even if clients do offer it, the rules specified in [TLSEXT]

-   require servers to ignore extensions they do not understand.

-

-   Servers MUST NOT send this extension. TLS servers MUST support

-   receiving this extension.

-

-

-7.4.2. Server Certificate

-

-   When this message will be sent:

-

-      The server MUST send a certificate whenever the agreed-upon key

-      exchange method uses certificates for authentication (this

-      includes all key exchange methods defined in this document except

-      DH_anon).  This message will always immediately follow the server

-      hello message.

-

-   Meaning of this message:

-

-      This message conveys the server's certificate chain to the client.

-      The certificate MUST be appropriate for the negotiated cipher

-      suite's key exchange algorithm, and any negotiated extensions.

-

-   Structure of this message:

-

-      opaque ASN.1Cert<1..2^24-1>;

-

-      struct {

-          ASN.1Cert certificate_list<0..2^24-1>;

-      } Certificate;

-

-   certificate_list

-      This is a sequence (chain) of certificates. The sender's

-      certificate MUST come first in the list. Each following

-      certificate MUST directly certify the one preceding it. Because

-      certificate validation requires that root keys be distributed

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 45]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      independently, the self-signed certificate that specifies the root

-      certificate authority MAY optionally be omitted from the chain,

-      under the assumption that the remote end must already possess it

-      in order to validate it in any case.

-

-   The same message type and structure will be used for the client's

-   response to a certificate request message. Note that a client MAY

-   send no certificates if it does not have an appropriate certificate

-   to send in response to the server's authentication request.

-

-   Note: PKCS #7 [PKCS7] is not used as the format for the certificate

-   vector because PKCS #6 [PKCS6] extended certificates are not used.

-   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task

-   of parsing the list more difficult.

-

-   The following rules apply to the certificates sent by the server:

-

-   -  The certificate type MUST be X.509v3, unless explicitly negotiated

-      otherwise (e.g., [TLSPGP]).

-

-   -  The end entity certificate's public key (and associated

-      restrictions) MUST be compatible with the selected key exchange

-      algorithm.

-

-      Key Exchange Alg.  Certificate Key Type

-

-      RSA                RSA public key; the certificate MUST

-      RSA_PSK            allow the key to be used for encryption

-                         (the keyEncipherment bit MUST be set

-                         if the key usage extension is present).

-                         Note: RSA_PSK is defined in [TLSPSK].

-

-      DHE_RSA            RSA public key; the certificate MUST

-      ECDHE_RSA          allow the key to be used for signing

-                         (the digitalSignature bit MUST be set

-                         if the key usage extension is present)

-                         with the signature scheme and hash

-                         algorithm that will be employed in the

-                         server key exchange message.

-

-      DHE_DSS            DSA public key; the certificate MUST

-                         allow the key to be used for signing with

-                         the hash algorithm that will be employed

-                         in the server key exchange message.

-

-      DH_DSS             Diffie-Hellman public key; the

-      DH_RSA             keyAgreement bit MUST be set if the

-                         key usage extension is present.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 46]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      ECDH_ECDSA         ECDH-capable public key; the public key

-      ECDH_RSA           MUST use a curve and point format supported

-                         by the client, as described in [TLSECC].

-

-      ECDHE_ECDSA        ECDSA-capable public key; the certificate

-                         MUST allow the key to be used for signing

-                         with the hash algorithm that will be

-                         employed in the server key exchange

-                         message. The public key MUST use a curve

-                         and point format supported by the client,

-                         as described in  [TLSECC].

-

-   -  The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are

-      used to guide certificate selection.

-

-   If the client provided a "signature_algorithms" extension, then all

-   certificates provided by the server MUST be signed by a

-   hash/signature algorithm pair that appears in that extension.  Note

-   that this implies that a certificate containing a key for one

-   signature algorithm MAY be signed using a different signature

-   algorithm (for instance, an RSA key signed with a DSA key.) This is a

-   departure from TLS 1.1, which required that the algorithms be the

-   same.  Note that this also implies that the DH_DSS, DH_RSA,

-   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the

-   algorithm used to sign the certificate. Fixed DH certificates MAY be

-   signed with any hash/signature algorithm pair appearing in the

-   extension.  The naming is historical.

-

-   If the server has multiple certificates, it chooses one of them based

-   on the above-mentioned criteria (in addition to other criteria, such

-   as transport layer endpoint, local configuration and preferences,

-   etc.). If the server has a single certificate it SHOULD attempt to

-   validate that it meets these criteria.

-

-   Note that there are certificates that use algorithms and/or algorithm

-   combinations that cannot be currently used with TLS.  For example, a

-   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in

-   SubjectPublicKeyInfo) cannot be used because TLS defines no

-   corresponding signature algorithm.

-

-   As cipher suites that specify new key exchange methods are specified

-   for the TLS Protocol, they will imply certificate format and the

-   required encoded keying information.

-

-7.4.3. Server Key Exchange Message

-

-   When this message will be sent:

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 47]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      This message will be sent immediately after the server certificate

-      message (or the server hello message, if this is an anonymous

-      negotiation).

-

-      The server key exchange message is sent by the server only when

-      the server certificate message (if sent) does not contain enough

-      data to allow the client to exchange a premaster secret. This is

-      true for the following key exchange methods:

-

-         DHE_DSS

-         DHE_RSA

-         DH_anon

-

-      It is not legal to send the server key exchange message for the

-      following key exchange methods:

-

-         RSA

-         DH_DSS

-         DH_RSA

-

-   Meaning of this message:

-

-      This message conveys cryptographic information to allow the client

-      to communicate the premaster secret: a Diffie-Hellman public key

-      with which the client can complete a key exchange (with the result

-      being the premaster secret) or a public key for some other

-      algorithm.

-

-   Structure of this message:

-

-      enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa }

-           KeyExchangeAlgorithm;

-

-      struct {

-          opaque dh_p<1..2^16-1>;

-          opaque dh_g<1..2^16-1>;

-          opaque dh_Ys<1..2^16-1>;

-      } ServerDHParams;     /* Ephemeral DH parameters */

-

-      dh_p

-         The prime modulus used for the Diffie-Hellman operation.

-

-      dh_g

-         The generator used for the Diffie-Hellman operation.

-

-      dh_Ys

-         The server's Diffie-Hellman public value (g^X mod p).

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 48]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      struct {

-          select (KeyExchangeAlgorithm) {

-              case dh_anon:

-                  ServerDHParams params;

-              case dhe_dss:

-              case dhe_rsa:

-                  ServerDHParams params;

-                  digitally-signed struct {

-                      opaque client_random[32];

-                      opaque server_random[32];

-                      ServerDHParams params;

-                  } signed_params;

-              case rsa:

-              case dh_dss:

-              case dh_rsa:

-                  struct {} ;

-                 /* message is omitted for rsa, dh_dss, and dh_rsa */

-          };

-      } ServerKeyExchange;

-

-      params

-         The server's key exchange parameters.

-

-      signed_params

-         For non-anonymous key exchanges, a signature over the

-         server's key exchange parameters.

-

-   If the client has offered the "signature_algorithms" extension, the

-   signature algorithm and hash algorithm MUST be a pair listed in that

-   extension. Note that there is a possibility for inconsistencies here.

-   For instance, the client might offer DHE_DSS key exchange but omit

-   any DSS pairs from its "signature_algorithms" extension.  In order to

-   negotiate correctly, the server MUST check any candidate cipher

-   suites against the "signature_algorithms" extension before selecting

-   them. This is somewhat inelegant but is a compromise designed to

-   minimize changes to the original cipher suite design.

-

-   In addition, the hash and signature algorithms MUST be compatible

-   with the key in the server's end-entity certificate.  RSA keys MAY be

-   used with any permitted hash algorithm, subject to restrictions in

-   the certificate, if any.

-

-   Because DSA signatures do not contain any secure indication of hash

-   algorithm, there is a risk of hash substitution if multiple hashes

-   may be used with any key. Currently, DSS [DSS] may only be used with

-   SHA-1. Future revisions of DSS [DSS-3] are expected to allow other

-   digest algorithms, as well as guidance as to which digest algorithms

-   should be used with each key size. In addition, future revisions of

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 49]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   [PKIX] may specify mechanisms for certificates to indicate which

-   digest algorithms are to be used with DSA.

-

-   As additional cipher suites are defined for TLS that include new key

-   exchange algorithms, the server key exchange message will be sent if

-   and only if the certificate type associated with the key exchange

-   algorithm does not provide enough information for the client to

-   exchange a premaster secret.

-

-7.4.4. Certificate Request

-

-   When this message will be sent:

-

-       A non-anonymous server can optionally request a certificate from

-       the client, if appropriate for the selected cipher suite. This

-       message, if sent, will immediately follow the Server Key Exchange

-       message (if it is sent; otherwise, the Server Certificate

-       message).

-

-   Structure of this message:

-

-      enum {

-          rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),

-          rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),

-          fortezza_dms_RESERVED(20), (255)

-      } ClientCertificateType;

-

-      opaque DistinguishedName<1..2^16-1>;

-

-      struct {

-          ClientCertificateType certificate_types<1..2^8-1>;

-          SignatureAndHashAlgorithm

-            supported_signature_algorithms<2^16-1>;

-          DistinguishedName certificate_authorities<0..2^16-1>;

-      } CertificateRequest;

-

-   certificate_types

-      A list of the types of certificate types which the client may

-      offer.

-

-         rsa_sign        a certificate containing an RSA key

-         dss_sign        a certificate containing a DSS key

-         rsa_fixed_dh    a certificate containing a static DH key.

-         dss_fixed_dh    a certificate containing a static DH key

-

-   supported_signature_algorithms

-      A list of the hash/signature algorithm pairs that the server is

-      able to verify, listed in descending order of preference.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 50]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   certificate_authorities

-      A list of the distinguished names [X501] of acceptable

-      certificate_authorities, represented in DER-encoded format. These

-      distinguished names may specify a desired distinguished name for a

-      root CA or for a subordinate CA; thus, this message can be used

-      both to describe known roots and a desired authorization space. If

-      the certificate_authorities list is empty then the client MAY send

-      any certificate of the appropriate ClientCertificateType, unless

-      there is some external arrangement to the contrary.

-

-   The interaction of the certificate_types and

-   supported_signature_algorithms fields is somewhat complicated.

-   certificate_types has been present in TLS since SSLv3, but was

-   somewhat underspecified. Much of its functionality is superseded by

-   supported_signature_algorithms. The following rules apply:

-

-   -  Any certificates provided by the client MUST be signed using a

-      hash/signature algorithm pair found in

-      supported_signature_algorithms.

-

-   -  The end-entity certificate provided by the client MUST contain a

-      key which is compatible with certificate_types. If the key is a

-      signature key, it MUST be usable with some hash/signature

-      algorithm pair in supported_signature_algorithms.

-

-   -  For historical reasons, the names of some client certificate types

-      include the algorithm used to sign the certificate.  For example,

-      in earlier versions of TLS, rsa_fixed_dh meant a certificate

-      signed with RSA and containing a static DH key.  In TLS 1.2, this

-      functionality has been obsoleted by the

-      supported_signature_algorithms, and the certificate type no longer

-      restricts the algorithm used to sign the certificate.  For

-      example, if the server sends dss_fixed_dh certificate type and

-      {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply

-      with a certificate containing a static DH key, signed with RSA-

-      SHA1.

-

-   New ClientCertificateType values are assigned by IANA as described in

-   Section 12.

-

-   Note: Values listed as RESERVED may not be used. They were used in

-   SSLv3.

-

-   Note: It is a fatal handshake_failure alert for an anonymous server

-   to request client authentication.

-

-7.4.5 Server hello done

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 51]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   When this message will be sent:

-

-      The server hello done message is sent by the server to indicate

-      the end of the server hello and associated messages. After sending

-      this message, the server will wait for a client response.

-

-   Meaning of this message:

-

-      This message means that the server is done sending messages to

-      support the key exchange, and the client can proceed with its

-      phase of the key exchange.

-

-      Upon receipt of the server hello done message, the client SHOULD

-      verify that the server provided a valid certificate, if required

-      and check that the server hello parameters are acceptable.

-

-   Structure of this message:

-

-      struct { } ServerHelloDone;

-

-7.4.6. Client Certificate

-

-   When this message will be sent:

-

-      This is the first message the client can send after receiving a

-      server hello done message. This message is only sent if the server

-      requests a certificate. If no suitable certificate is available,

-      the client MUST send a certificate message containing no

-      certificates. That is, the certificate_list structure has a length

-      of zero.  If the client does not send any certificates, the server

-      MAY at its discretion either continue the handshake without client

-      authentication, or respond with a fatal handshake_failure alert.

-      Also, if some aspect of the certificate chain was unacceptable

-      (e.g., it was not signed by a known, trusted CA), the server MAY

-      at its discretion either continue the handshake (considering the

-      client unauthenticated) or send a fatal alert.

-

-      Client certificates are sent using the Certificate structure

-      defined in Section 7.4.2.

-

-   Meaning of this message:

-

-      This message conveys the client's certificate chain to the server;

-      the server will use it when verifying the certificate verify

-      message (when the client authentication is based on signing), or

-      calculate the premaster secret (for non-ephemeral Diffie-Hellman).

-      The certificate MUST be appropriate for the negotiated cipher

-      suite's key exchange algorithm, and any negotiated extensions.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 52]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   In particular:

-

-   -  The certificate type MUST be X.509v3, unless explicitly negotiated

-      otherwise (e.g. [TLSPGP]).

-

-   -  The end-entity certificate's public key (and associated

-      restrictions) has to be compatible with the certificate types

-      listed in CertificateRequest:

-

-      Client Cert. Type   Certificate Key Type

-

-      rsa_sign            RSA public key; the certificate MUST allow

-                          the key to be used for signing with the

-                          signature scheme and hash algorithm that

-                          will be employed in the certificate verify

-                          message.

-

-      dss_sign            DSA public key; the certificate MUST allow

-                          the key to be used for signing with the

-                          hash algorithm that will be employed in

-                          the certificate verify message.

-

-      ecdsa_sign          ECDSA-capable public key; the certificate

-                          MUST allow the key to be used for signing

-                          with the hash algorithm that will be

-                          employed in the certificate verify

-                          message; the public key MUST use a

-                          curve and point format supported by the

-                          server.

-

-      rsa_fixed_dh        Diffie-Hellman public key; MUST use

-      dss_fixed_dh        the same parameters as server's key.

-

-      rsa_fixed_ecdh      ECDH-capable public key; MUST use

-      ecdsa_fixed_ecdh    the same curve as server's key, and

-                          MUST use a point format supported by

-                          the server.

-

-   -  If the certificate_authorities list in the certificate request

-      message was non-empty, one of the certificates in the certificate

-      chain SHOULD be issued by one of the listed CAs.

-

-   -  The certificates MUST be signed using an acceptable hash/

-      signature algorithm pair, as described in Section 7.4.4. Note that

-      this relaxes the constraints on certificate signing algorithms

-      found in prior versions of TLS.

-

-   Note that as with the server certificate, there are certificates that

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 53]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   use algorithms/algorithm combinations that cannot be currently used

-   with TLS.

-

-7.4.7. Client Key Exchange Message

-

-   When this message will be sent:

-

-      This message is always sent by the client. It MUST immediately

-      follow the client certificate message, if it is sent. Otherwise it

-      MUST be the first message sent by the client after it receives the

-      server hello done message.

-

-   Meaning of this message:

-

-      With this message, the premaster secret is set, either though

-      direct transmission of the RSA-encrypted secret, or by the

-      transmission of Diffie-Hellman parameters that will allow each

-      side to agree upon the same premaster secret.

-

-      When the client is using an ephemeral Diffie-Hellman exponent,

-      then this message contains the client's Diffie-Hellman public

-      value. If the client is sending a certificate containing a static

-      DH exponent (i.e., it is doing fixed_dh client authentication)

-      then this message MUST be sent but MUST be empty.

-

-

-   Structure of this message:

-

-      The choice of messages depends on which key exchange method has

-      been selected. See Section 7.4.3 for the KeyExchangeAlgorithm

-      definition.

-

-      struct {

-          select (KeyExchangeAlgorithm) {

-              case rsa:

-                  EncryptedPreMasterSecret;

-              case dhe_dss:

-              case dhe_rsa:

-              case dh_dss:

-              case dh_rsa:

-              case dh_anon:

-                  ClientDiffieHellmanPublic;

-          } exchange_keys;

-      } ClientKeyExchange;

-

-7.4.7.1. RSA Encrypted Premaster Secret Message

-

-   Meaning of this message:

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 54]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      If RSA is being used for key agreement and authentication, the

-      client generates a 48-byte premaster secret, encrypts it using the

-      public key from the server's certificate and sends the result in

-      an encrypted premaster secret message. This structure is a variant

-      of the client key exchange message and is not a message in itself.

-

-   Structure of this message:

-

-      struct {

-          ProtocolVersion client_version;

-          opaque random[46];

-      } PreMasterSecret;

-

-      client_version

-         The latest (newest) version supported by the client. This is

-         used to detect version roll-back attacks.

-

-      random

-         46 securely-generated random bytes.

-

-      struct {

-          public-key-encrypted PreMasterSecret pre_master_secret;

-      } EncryptedPreMasterSecret;

-

-      pre_master_secret

-         This random value is generated by the client and is used to

-         generate the master secret, as specified in Section 8.1.

-

-   Note: The version number in the PreMasterSecret is the version

-   offered by the client in the ClientHello.client_version, not the

-   version negotiated for the connection.  This feature is designed to

-   prevent rollback attacks.  Unfortunately, some old implementations

-   use the negotiated version instead and therefore checking the version

-   number may lead to failure to interoperate with such incorrect client

-   implementations.

-

-   Client implementations MUST always send the correct version number in

-   PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,

-   server implementations MUST check the version number as described in

-   the note below. If the version number is 1.0 or earlier, server

-   implementations SHOULD check the version number, but MAY have a

-   configuration option to disable the check. Note that if the check

-   fails, the PreMasterSecret SHOULD be randomized as described below.

-

-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.

-   [KPR03] can be used to attack a TLS server that reveals whether a

-   particular message, when decrypted, is properly PKCS#1 formatted,

-   contains a valid PreMasterSecret structure, or has the correct

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 55]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   version number.

-

-   The best way to avoid these vulnerabilities is to treat incorrectly

-   formatted messages in a manner indistinguishable from correctly

-   formatted RSA blocks. In other words:

-

-      1. Generate a string R of 46 random bytes

-

-      2. Decrypt the message M

-

-      3. If the PKCS#1 padding is not correct, or the length of

-         message M is not exactly 48 bytes:

-            premaster secret = ClientHello.client_version || R

-         else If ClientHello.client_version <= TLS 1.0, and

-         version number check is explicitly disabled:

-            premaster secret = M

-         else:

-            premaster secret = ClientHello.client_version || M[2..47]

-

-   Note that explicitly constructing the premaster_secret with the

-   ClientHello.client_version produces an invalid master_secret if the

-   client has sent the wrong version in the original premaster_secret.

-

-   In any case, a TLS server MUST NOT generate an alert if processing an

-   RSA-encrypted premaster secret message fails, or the version number

-   is not as expected. Instead, it MUST continue the handshake with a

-   randomly generated premaster secret.  It may be useful to log the

-   real cause of failure for troubleshooting purposes; however, care

-   must be taken to avoid leaking the information to an attacker

-   (through, e.g., timing, log files, or other channels.)

-

-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure

-   against the Bleichenbacher attack. However, for maximal compatibility

-   with earlier versions of TLS, this specification uses the RSAES-

-   PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known

-   to exist provided that the above recommendations are followed.

-

-   Implementation Note: Public-key-encrypted data is represented as an

-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted

-   PreMasterSecret in a ClientKeyExchange is preceded by two length

-   bytes. These bytes are redundant in the case of RSA because the

-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange

-   and its length can therefore be unambiguously determined. The SSLv3

-   specification was not clear about the encoding of public-key-

-   encrypted data, and therefore many SSLv3 implementations do not

-   include the the length bytes, encoding the RSA encrypted data

-   directly in the ClientKeyExchange message.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 56]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   This specification requires correct encoding of the

-   EncryptedPreMasterSecret complete with length bytes. The resulting

-   PDU is incompatible with many SSLv3 implementations. Implementors

-   upgrading from SSLv3 MUST modify their implementations to generate

-   and accept the correct encoding. Implementors who wish to be

-   compatible with both SSLv3 and TLS should make their implementation's

-   behavior dependent on the protocol version.

-

-   Implementation Note: It is now known that remote timing-based attacks

-   on TLS are possible, at least when the client and server are on the

-   same LAN. Accordingly, implementations that use static RSA keys MUST

-   use RSA blinding or some other anti-timing technique, as described in

-   [TIMING].

-

-

-7.4.7.2. Client Diffie-Hellman Public Value

-

-   Meaning of this message:

-

-      This structure conveys the client's Diffie-Hellman public value

-      (Yc) if it was not already included in the client's certificate.

-      The encoding used for Yc is determined by the enumerated

-      PublicValueEncoding. This structure is a variant of the client key

-      exchange message, and not a message in itself.

-

-   Structure of this message:

-

-      enum { implicit, explicit } PublicValueEncoding;

-

-      implicit

-         If the client has sent a certificate which contains a suitable

-         Diffie-Hellman key (for fixed_dh client authentication) then Yc

-         is implicit and does not need to be sent again. In this case,

-         the client key exchange message will be sent, but it MUST be

-         empty.

-

-      explicit

-         Yc needs to be sent.

-

-      struct {

-          select (PublicValueEncoding) {

-              case implicit: struct { };

-              case explicit: opaque dh_Yc<1..2^16-1>;

-          } dh_public;

-      } ClientDiffieHellmanPublic;

-

-      dh_Yc

-         The client's Diffie-Hellman public value (Yc).

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 57]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-7.4.8. Certificate verify

-

-   When this message will be sent:

-

-      This message is used to provide explicit verification of a client

-      certificate. This message is only sent following a client

-      certificate that has signing capability (i.e. all certificates

-      except those containing fixed Diffie-Hellman parameters). When

-      sent, it MUST immediately follow the client key exchange message.

-

-   Structure of this message:

-

-      struct {

-           digitally-signed struct {

-               opaque handshake_messages[handshake_messages_length];

-           }

-      } CertificateVerify;

-

-      Here handshake_messages refers to all handshake messages sent or

-      received starting at client hello up to but not including this

-      message, including the type and length fields of the handshake

-      messages. This is the concatenation of all the Handshake

-      structures as defined in 7.4 exchanged thus far. Note that this

-      requires both sides to either buffer the messages or compute

-      running hashes for all potential hash algorithms up to the time of

-      the CertificateVerify computation. Servers can minimize this

-      computation cost by offering a restricted set of digest algorithms

-      in the CertificateRequest message.

-

-      The hash and signature algorithms used in the signature MUST be

-      one of those present in the supported_signature_algorithms field

-      of the CertificateRequest message. In addition, the hash and

-      signature algorithms MUST be compatible with the key in the

-      client's end-entity certificate.  RSA keys MAY be used with any

-      permitted hash algorith, subject to restrictions in the

-      certificate, if any.

-

-      Because DSA signatures do not contain any secure indication of

-      hash algorithm, there is a risk of hash substitution if multiple

-      hashes may be used with any key. Currently, DSS [DSS] may only be

-      used with SHA-1. Future revisions of DSS [DSS-3] are expected to

-      allow other digest algorithms, as well as guidance as to which

-      digest algorithms should be used with each key size. In addition,

-      future revisions of [PKIX] may specify mechanisms for certificates

-      to indicate which digest algorithms are to be used with DSA.

-

-

-7.4.9. Finished

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 58]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   When this message will be sent:

-

-      A finished message is always sent immediately after a change

-      cipher spec message to verify that the key exchange and

-      authentication processes were successful. It is essential that a

-      change cipher spec message be received between the other handshake

-      messages and the Finished message.

-

-   Meaning of this message:

-

-      The finished message is the first protected with the just-

-      negotiated algorithms, keys, and secrets. Recipients of finished

-      messages MUST verify that the contents are correct.  Once a side

-      has sent its Finished message and received and validated the

-      Finished message from its peer, it may begin to send and receive

-      application data over the connection.

-

-   Structure of this message:

-

-      struct {

-          opaque verify_data[verify_data_length];

-      } Finished;

-

-      verify_data

-         PRF(master_secret, finished_label, Hash(handshake_messages))

-            [0..verify_data_length-1];

-

-      finished_label

-         For Finished messages sent by the client, the string "client

-         finished". For Finished messages sent by the server, the string

-         "server finished".

-

-      Hash denotes a Hash of the handshake messages. For the PRF defined

-      in Section 5, the Hash MUST be the Hash used as the basis for the

-      PRF. Any cipher suite which defines a different PRF MUST also

-      define the Hash to use in the Finished computation.

-

-      In previous versions of TLS, the verify_data was always 12 octets

-      long. In the current version of TLS, it depends on the cipher

-      suite. Any cipher suite which does not explicitly specify

-      verify_data_length has a verify_data_length equal to 12. This

-      includes all existing cipher suites.  Note that this

-      representation has the same encoding as with previous versions.

-      Future cipher suites MAY specify other lengths but such length

-      MUST be at least 12 bytes.

-

-      handshake_messages

-         All of the data from all messages in this handshake (not

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 59]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-         including any HelloRequest messages) up to but not including

-         this message. This is only data visible at the handshake layer

-         and does not include record layer headers.  This is the

-         concatenation of all the Handshake structures as defined in

-         7.4, exchanged thus far.

-

-   It is a fatal error if a finished message is not preceded by a change

-   cipher spec message at the appropriate point in the handshake.

-

-   The value handshake_messages includes all handshake messages starting

-   at client hello up to, but not including, this finished message. This

-   may be different from handshake_messages in Section 7.4.8 because it

-   would include the certificate verify message (if sent). Also, the

-   handshake_messages for the finished message sent by the client will

-   be different from that for the finished message sent by the server,

-   because the one that is sent second will include the prior one.

-

-   Note: Change cipher spec messages, alerts, and any other record types

-   are not handshake messages and are not included in the hash

-   computations. Also, Hello Request messages are omitted from handshake

-   hashes.

-

-8. Cryptographic Computations

-

-   In order to begin connection protection, the TLS Record Protocol

-   requires specification of a suite of algorithms, a master secret, and

-   the client and server random values. The authentication, encryption,

-   and MAC algorithms are determined by the cipher_suite selected by the

-   server and revealed in the server hello message. The compression

-   algorithm is negotiated in the hello messages, and the random values

-   are exchanged in the hello messages. All that remains is to calculate

-   the master secret.

-

-8.1. Computing the Master Secret

-

-   For all key exchange methods, the same algorithm is used to convert

-   the pre_master_secret into the master_secret. The pre_master_secret

-   should be deleted from memory once the master_secret has been

-   computed.

-

-      master_secret = PRF(pre_master_secret, "master secret",

-                          ClientHello.random + ServerHello.random)

-                          [0..47];

-

-   The master secret is always exactly 48 bytes in length. The length of

-   the premaster secret will vary depending on key exchange method.

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 60]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-8.1.1. RSA

-

-   When RSA is used for server authentication and key exchange, a

-   48-byte pre_master_secret is generated by the client, encrypted under

-   the server's public key, and sent to the server. The server uses its

-   private key to decrypt the pre_master_secret. Both parties then

-   convert the pre_master_secret into the master_secret, as specified

-   above.

-

-8.1.2. Diffie-Hellman

-

-   A conventional Diffie-Hellman computation is performed. The

-   negotiated key (Z) is used as the pre_master_secret, and is converted

-   into the master_secret, as specified above.  Leading bytes of Z that

-   contain all zero bits are stripped before it is used as the

-   pre_master_secret.

-

-   Note: Diffie-Hellman parameters are specified by the server and may

-   be either ephemeral or contained within the server's certificate.

-

-9. Mandatory Cipher Suites

-

-   In the absence of an application profile standard specifying

-   otherwise, a TLS compliant application MUST implement the cipher

-   suite TLS_RSA_WITH_AES_128_CBC_SHA.

-

-10. Application Data Protocol

-

-   Application data messages are carried by the Record Layer and are

-   fragmented, compressed, and encrypted based on the current connection

-   state. The messages are treated as transparent data to the record

-   layer.

-

-11. Security Considerations

-

-   Security issues are discussed throughout this memo, especially in

-   Appendices D, E, and F.

-

-12. IANA Considerations

-

-   This document uses several registries that were originally created in

-   [TLS1.1]. IANA is requested to update (has updated) these to

-   reference this document. The registries and their allocation policies

-   (unchanged from [TLS1.1]) are listed below.

-

-   -  TLS ClientCertificateType Identifiers Registry: Future values in

-      the range 0-63 (decimal) inclusive are assigned via Standards

-      Action [RFC2434]. Values in the range 64-223 (decimal) inclusive

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 61]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      are assigned Specification Required [RFC2434]. Values from 224-255

-      (decimal) inclusive are reserved for Private Use [RFC2434].

-

-   -  TLS Cipher Suite Registry: Future values with the first byte in

-      the range 0-191 (decimal) inclusive are assigned via Standards

-      Action [RFC2434].  Values with the first byte in the range 192-254

-      (decimal) are assigned via Specification Required [RFC2434].

-      Values with the first byte 255 (decimal) are reserved for Private

-      Use [RFC2434].

-

-   -  This document defines several new HMAC-SHA256 based cipher suites,

-      whose values (in Appendix A.5) are to be (have been) allocated

-      from the TLS Cipher Suite registry.

-

-   -  TLS ContentType Registry: Future values are allocated via

-      Standards Action [RFC2434].

-

-   -  TLS Alert Registry: Future values are allocated via Standards

-      Action [RFC2434].

-

-   -  TLS HandshakeType Registry: Future values are allocated via

-      Standards Action [RFC2434].

-

-   This document also uses a registry originally created in [RFC4366].

-   IANA is requested to update (has updated) it to reference this

-   document.  The registry and its allocation policy (unchanged from

-   [RFC4366]) is listed below:

-

-   -  TLS ExtensionType Registry: Future values are allocated via IETF

-      Consensus [RFC2434]

-

-   In addition, this document defines two new registries to be

-   maintained by IANA:

-

-   -  TLS SignatureAlgorithm Registry: The registry will be initially

-      populated with the values described in Section 7.4.1.4.1.  Future

-      values in the range 0-63 (decimal) inclusive are assigned via

-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)

-      inclusive are assigned via Specification Required [RFC2434].

-      Values from 224-255 (decimal) inclusive are reserved for Private

-      Use [RFC2434].

-

-   -  TLS HashAlgorithm Registry: The registry will be initially

-      populated with the values described in Section 7.4.1.4.1.  Future

-      values in the range 0-63 (decimal) inclusive are assigned via

-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)

-      inclusive are assigned via Specification Required [RFC2434].

-      Values from 224-255 (decimal) inclusive are reserved for Private

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 62]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      Use [RFC2434].

-

-   This document defines one new TLS extension, signature_algorithms,

-   which is to be (has been) allocated value TBD-BY-IANA in the TLS

-   ExtensionType registry.

-

-   This document also uses the TLS Compression Method Identifiers

-   Registry, defined in [RFC3749].  IANA is requested to allocate value

-   0 for the "null" compression method.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 63]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Appendix A. Protocol Constant Values

-

-   This section describes protocol types and constants.

-

-A.1. Record Layer

-

-   struct {

-       uint8 major;

-       uint8 minor;

-   } ProtocolVersion;

-

-   ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/

-

-   enum {

-       change_cipher_spec(20), alert(21), handshake(22),

-       application_data(23), (255)

-   } ContentType;

-

-   struct {

-       ContentType type;

-       ProtocolVersion version;

-       uint16 length;

-       opaque fragment[TLSPlaintext.length];

-   } TLSPlaintext;

-

-   struct {

-       ContentType type;

-       ProtocolVersion version;

-       uint16 length;

-       opaque fragment[TLSCompressed.length];

-   } TLSCompressed;

-

-   struct {

-       ContentType type;

-       ProtocolVersion version;

-       uint16 length;

-       select (SecurityParameters.cipher_type) {

-           case stream: GenericStreamCipher;

-           case block:  GenericBlockCipher;

-           case aead:   GenericAEADCipher;

-       } fragment;

-   } TLSCiphertext;

-

-   stream-ciphered struct {

-       opaque content[TLSCompressed.length];

-       opaque MAC[SecurityParameters.mac_length];

-   } GenericStreamCipher;

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 64]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   struct {

-       opaque IV[SecurityParameters.record_iv_length];

-       block-ciphered struct {

-           opaque content[TLSCompressed.length];

-           opaque MAC[SecurityParameters.mac_length];

-           uint8 padding[GenericBlockCipher.padding_length];

-           uint8 padding_length;

-       };

-   } GenericBlockCipher;

-

-   aead-ciphered struct {

-       opaque IV[SecurityParameters.record_iv_length];

-       opaque aead_output[AEADEncrypted.length];

-   } GenericAEADCipher;

-

-A.2. Change Cipher Specs Message

-

-   struct {

-       enum { change_cipher_spec(1), (255) } type;

-   } ChangeCipherSpec;

-

-A.3. Alert Messages

-

-   enum { warning(1), fatal(2), (255) } AlertLevel;

-

-   enum {

-       close_notify(0),

-       unexpected_message(10),

-       bad_record_mac(20),

-       decryption_failed_RESERVED(21),

-       record_overflow(22),

-       decompression_failure(30),

-       handshake_failure(40),

-       no_certificate_RESERVED(41),

-       bad_certificate(42),

-       unsupported_certificate(43),

-       certificate_revoked(44),

-       certificate_expired(45),

-       certificate_unknown(46),

-       illegal_parameter(47),

-       unknown_ca(48),

-       access_denied(49),

-       decode_error(50),

-       decrypt_error(51),

-       export_restriction_RESERVED(60),

-       protocol_version(70),

-       insufficient_security(71),

-       internal_error(80),

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 65]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-       user_canceled(90),

-       no_renegotiation(100),

-       unsupported_extension(110),           /* new */

-       (255)

-   } AlertDescription;

-

-   struct {

-       AlertLevel level;

-       AlertDescription description;

-   } Alert;

-

-A.4. Handshake Protocol

-

-   enum {

-       hello_request(0), client_hello(1), server_hello(2),

-       certificate(11), server_key_exchange (12),

-       certificate_request(13), server_hello_done(14),

-       certificate_verify(15), client_key_exchange(16),

-       finished(20)

-       (255)

-   } HandshakeType;

-

-   struct {

-       HandshakeType msg_type;

-       uint24 length;

-       select (HandshakeType) {

-           case hello_request:       HelloRequest;

-           case client_hello:        ClientHello;

-           case server_hello:        ServerHello;

-           case certificate:         Certificate;

-           case server_key_exchange: ServerKeyExchange;

-           case certificate_request: CertificateRequest;

-           case server_hello_done:   ServerHelloDone;

-           case certificate_verify:  CertificateVerify;

-           case client_key_exchange: ClientKeyExchange;

-           case finished:            Finished;

-       } body;

-   } Handshake;

-

-A.4.1. Hello Messages

-

-   struct { } HelloRequest;

-

-   struct {

-       uint32 gmt_unix_time;

-       opaque random_bytes[28];

-   } Random;

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 66]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   opaque SessionID<0..32>;

-

-   uint8 CipherSuite[2];

-

-   enum { null(0), (255) } CompressionMethod;

-

-   struct {

-       ProtocolVersion client_version;

-       Random random;

-       SessionID session_id;

-       CipherSuite cipher_suites<2..2^16-2>;

-       CompressionMethod compression_methods<1..2^8-1>;

-       select (extensions_present) {

-           case false:

-               struct {};

-           case true:

-               Extension extensions<0..2^16-1>;

-       };

-   } ClientHello;

-

-   struct {

-       ProtocolVersion server_version;

-       Random random;

-       SessionID session_id;

-       CipherSuite cipher_suite;

-       CompressionMethod compression_method;

-       select (extensions_present) {

-           case false:

-               struct {};

-           case true:

-               Extension extensions<0..2^16-1>;

-       };

-   } ServerHello;

-

-   struct {

-       ExtensionType extension_type;

-       opaque extension_data<0..2^16-1>;

-   } Extension;

-

-   enum {

-       signature_algorithms(TBD-BY-IANA), (65535)

-   } ExtensionType;

-

-   enum{

-       none(0), md5(1), sha1(2), sha256(3), sha384(4),

-       sha512(5), (255)

-   } HashAlgorithm;

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 67]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;

-

-   struct {

-         HashAlgorithm hash;

-         SignatureAlgorithm signature;

-   } SignatureAndHashAlgorithm;

-

-   SignatureAndHashAlgorithm

-    supported_signature_algorithms<2..2^16-1>;

-

-A.4.2. Server Authentication and Key Exchange Messages

-

-   opaque ASN.1Cert<2^24-1>;

-

-   struct {

-       ASN.1Cert certificate_list<0..2^24-1>;

-   } Certificate;

-

-   enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa}

-        KeyExchangeAlgorithm;

-

-   struct {

-       opaque dh_p<1..2^16-1>;

-       opaque dh_g<1..2^16-1>;

-       opaque dh_Ys<1..2^16-1>;

-   } ServerDHParams;     /* Ephemeral DH parameters */

-

-   struct {

-       select (KeyExchangeAlgorithm) {

-           case dh_anon:

-               ServerDHParams params;

-           case dhe_dss:

-           case dhe_rsa:

-               ServerDHParams params;

-               digitally-signed struct {

-                   opaque client_random[32];

-                   opaque server_random[32];

-                   ServerDHParams params;

-               } signed_params;

-           case rsa:

-           case dh_dss:

-           case dh_rsa:

-               struct {} ;

-              /* message is omitted for rsa, dh_dss, and dh_rsa */

-       };

-   } ServerKeyExchange;

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 68]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   enum {

-       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),

-       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),

-       fortezza_dms_RESERVED(20),

-       (255)

-   } ClientCertificateType;

-

-   opaque DistinguishedName<1..2^16-1>;

-

-   struct {

-       ClientCertificateType certificate_types<1..2^8-1>;

-       DistinguishedName certificate_authorities<0..2^16-1>;

-   } CertificateRequest;

-

-   struct { } ServerHelloDone;

-

-A.4.3. Client Authentication and Key Exchange Messages

-

-   struct {

-       select (KeyExchangeAlgorithm) {

-           case rsa:

-               EncryptedPreMasterSecret;

-           case dhe_dss:

-           case dhe_rsa:

-           case dh_dss:

-           case dh_rsa:

-           case dh_anon:

-               ClientDiffieHellmanPublic;

-       } exchange_keys;

-   } ClientKeyExchange;

-

-   struct {

-       ProtocolVersion client_version;

-       opaque random[46];

-   } PreMasterSecret;

-

-   struct {

-       public-key-encrypted PreMasterSecret pre_master_secret;

-   } EncryptedPreMasterSecret;

-

-   enum { implicit, explicit } PublicValueEncoding;

-

-   struct {

-       select (PublicValueEncoding) {

-           case implicit: struct {};

-           case explicit: opaque DH_Yc<1..2^16-1>;

-       } dh_public;

-   } ClientDiffieHellmanPublic;

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 69]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   struct {

-        digitally-signed struct {

-            opaque handshake_messages[handshake_messages_length];

-        }

-   } CertificateVerify;

-

-A.4.4. Handshake Finalization Message

-

-   struct {

-       opaque verify_data[verify_data_length];

-   } Finished;

-

-A.5. The Cipher Suite

-

-   The following values define the cipher suite codes used in the client

-   hello and server hello messages.

-

-   A cipher suite defines a cipher specification supported in TLS

-   Version 1.2.

-

-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a

-   TLS connection during the first handshake on that channel, but MUST

-   NOT be negotiated, as it provides no more protection than an

-   unsecured connection.

-

-      CipherSuite TLS_NULL_WITH_NULL_NULL               = { 0x00,0x00 };

-

-   The following CipherSuite definitions require that the server provide

-   an RSA certificate that can be used for key exchange. The server may

-   request any signature-capable certificate in the certificate request

-   message.

-

-      CipherSuite TLS_RSA_WITH_NULL_MD5                 = { 0x00,0x01 };

-      CipherSuite TLS_RSA_WITH_NULL_SHA                 = { 0x00,0x02 };

-      CipherSuite TLS_RSA_WITH_NULL_SHA256              = { 0x00,TBD1 };

-      CipherSuite TLS_RSA_WITH_RC4_128_MD5              = { 0x00,0x04 };

-      CipherSuite TLS_RSA_WITH_RC4_128_SHA              = { 0x00,0x05 };

-      CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA         = { 0x00,0x0A };

-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F };

-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x35 };

-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256       = { 0x00,TBD2 };

-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256       = { 0x00,TBD3 };

-

-

-   The following cipher suite definitions are used for server-

-   authenticated (and optionally client-authenticated) Diffie-Hellman.

-   DH denotes cipher suites in which the server's certificate contains

-   the Diffie-Hellman parameters signed by the certificate authority

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 70]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman

-   parameters are signed by a a signature-capable certificate, which has

-   been signed by the CA. The signing algorithm used by the server is

-   specified after the DHE parameter. The server can request any

-   signature-capable certificate from the client for client

-   authentication or it may request a Diffie-Hellman certificate. Any

-   Diffie-Hellman certificate provided by the client must use the

-   parameters (group and generator) described by the server.

-

-

-      CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x0D };

-      CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x10 };

-      CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x13 };

-      CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x16 };

-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 };

-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 };

-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 };

-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 };

-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x36 };

-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x37 };

-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };

-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };

-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00, TBD4};

-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00, TBD5};

-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00, TBD6};

-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00, TBD7};

-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256    = { 0x00, TBD8};

-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256    = { 0x00, TBD9};

-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   = { 0x00, TBDA};

-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   = { 0x00, TBDB};

-

-   The following cipher suites are used for completely anonymous Diffie-

-   Hellman communications in which neither party is authenticated. Note

-   that this mode is vulnerable to man-in-the-middle attacks.  Using

-   this mode therefore is of limited use: These cipher suites MUST NOT

-   be used by TLS 1.2 implementations unless the application layer has

-   specifically requested to allow anonymous key exchange.  (Anonymous

-   key exchange may sometimes be acceptable, for example, to support

-   opportunistic encryption when no set-up for authentication is in

-   place, or when TLS is used as part of more complex security protocols

-   that have other means to ensure authentication.)

-

-      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };

-      CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };

-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };

-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };

-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00, TBDC};

-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00, TBDD};

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 71]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   Note that using non-anonymous key exchange without actually verifying

-   the key exchange is essentially equivalent to anonymous key exchange,

-   and the same precautions apply.  While non-anonymous key exchange

-   will generally involve a higher computational and communicational

-   cost than anonymous key exchange, it may be in the interest of

-   interoperability not to disable non-anonymous key exchange when the

-   application layer is allowing anonymous key exchange.

-

-   New cipher suite values are assigned by IANA as described in Section

-   12.

-

-   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are

-   reserved to avoid collision with Fortezza-based cipher suites in SSL

-   3.

-

-A.6. The Security Parameters

-

-   These security parameters are determined by the TLS Handshake

-   Protocol and provided as parameters to the TLS Record Layer in order

-   to initialize a connection state. SecurityParameters includes:

-

-   enum { null(0), (255) } CompressionMethod;

-

-   enum { server, client } ConnectionEnd;

-

-   enum { tls_prf_sha256 } PRFAlgorithm;

-

-   enum { null, rc4, 3des, aes }

-   BulkCipherAlgorithm;

-

-   enum { stream, block, aead } CipherType;

-

-   enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384,

-     hmac_sha512} MACAlgorithm;

-

-   /* The algorithms specified in CompressionMethod,

-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */

-

-   struct {

-       ConnectionEnd          entity;

-       PRFAlgorithm           prf_algorithm;

-       BulkCipherAlgorithm    bulk_cipher_algorithm;

-       CipherType             cipher_type;

-       uint8                  enc_key_length;

-       uint8                  block_length;

-       uint8                  fixed_iv_length;

-       uint8                  record_iv_length;

-       MACAlgorithm           mac_algorithm;

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 72]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-       uint8                  mac_length;

-       uint8                  mac_key_length;

-       CompressionMethod      compression_algorithm;

-       opaque                 master_secret[48];

-       opaque                 client_random[32];

-       opaque                 server_random[32];

-   } SecurityParameters;

-

-A.7. Changes to RFC 4492

-

-   RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS.  This

-   document changes some of the structures used in that document. This

-   section details the required changes for implementors of both RFC

-   4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing

-   RFC 4492 do not need to read this section.

-

-   This document adds a "signature_algorithm" field to the digitally-

-   signed element in order to identify the signature and digest

-   algorithms used to create a signature. This change applies to digital

-   signatures formed using ECDSA as well, thus allowing ECDSA signatures

-   to be used and digest algorithms other than SHA-1, provided such use

-   is compatible with the certificate and any restrictions imposed by

-   future revisions of [PKIX].

-

-   As described in Sections 7.4.2 and 7.4.6, the restrictions on the

-   signature algorithms used to sign certificates are no longer tied to

-   the cipher suite (when used by the server) or the

-   ClientCertificateType (when used by the client). Thus, the

-   restrictions on the algorithm used to sign certificates specified in

-   Sections 2 and 3 of RFC 4492 are also relaxed. As in this document

-   the restrictions on the keys in the end-entity certificate remain.

-

-Appendix B. Glossary

-

-   Advanced Encryption Standard (AES)

-      AES is a widely used symmetric encryption algorithm.  AES is a

-      block cipher with a 128, 192, or 256 bit keys and a 16 byte block

-      size. [AES] TLS currently only supports the 128 and 256 bit key

-      sizes.

-

-   application protocol

-      An application protocol is a protocol that normally layers

-      directly on top of the transport layer (e.g., TCP/IP). Examples

-      include HTTP, TELNET, FTP, and SMTP.

-

-   asymmetric cipher

-      See public key cryptography.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 73]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   authenticated encryption with additional data (AEAD)

-      A symmetric encryption algorithm that simultaneously provides

-      confidentiality and message integrity.

-

-   authentication

-      Authentication is the ability of one entity to determine the

-      identity of another entity.

-

-   block cipher

-      A block cipher is an algorithm that operates on plaintext in

-      groups of bits, called blocks. 64 bits is a common block size.

-

-   bulk cipher

-      A symmetric encryption algorithm used to encrypt large quantities

-      of data.

-

-   cipher block chaining (CBC)

-      CBC is a mode in which every plaintext block encrypted with a

-      block cipher is first exclusive-ORed with the previous ciphertext

-      block (or, in the case of the first block, with the initialization

-      vector). For decryption, every block is first decrypted, then

-      exclusive-ORed with the previous ciphertext block (or IV).

-

-   certificate

-      As part of the X.509 protocol (a.k.a. ISO Authentication

-      framework), certificates are assigned by a trusted Certificate

-      Authority and provide a strong binding between a party's identity

-      or some other attributes and its public key.

-

-   client

-      The application entity that initiates a TLS connection to a

-      server. This may or may not imply that the client initiated the

-      underlying transport connection. The primary operational

-      difference between the server and client is that the server is

-      generally authenticated, while the client is only optionally

-      authenticated.

-

-   client write key

-      The key used to encrypt data written by the client.

-

-   client write MAC key

-      The secret data used to authenticate data written by the client.

-

-   connection

-      A connection is a transport (in the OSI layering model definition)

-      that provides a suitable type of service. For TLS, such

-      connections are peer-to-peer relationships. The connections are

-      transient. Every connection is associated with one session.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 74]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   Data Encryption Standard

-      DES is a very widely used symmetric encryption algorithm. DES is a

-      block cipher with a 56 bit key and an 8 byte block size. Note that

-      in TLS, for key generation purposes, DES is treated as having an 8

-      byte key length (64 bits), but it still only provides 56 bits of

-      protection. (The low bit of each key byte is presumed to be set to

-      produce odd parity in that key byte.) DES can also be operated in

-      a mode where three independent keys and three encryptions are used

-      for each block of data; this uses 168 bits of key (24 bytes in the

-      TLS key generation method) and provides the equivalent of 112 bits

-      of security. [DES], [3DES]

-

-   Digital Signature Standard (DSS)

-      A standard for digital signing, including the Digital Signing

-      Algorithm, approved by the National Institute of Standards and

-      Technology, defined in NIST FIPS PUB 186, "Digital Signature

-      Standard", published May, 1994 by the U.S. Dept. of Commerce.

-      [DSS]

-

-   digital signatures

-      Digital signatures utilize public key cryptography and one-way

-      hash functions to produce a signature of the data that can be

-      authenticated, and is difficult to forge or repudiate.

-

-   handshake

-      An initial negotiation between client and server that establishes

-      the parameters of their transactions.

-

-   Initialization Vector (IV)

-      When a block cipher is used in CBC mode, the initialization vector

-      is exclusive-ORed with the first plaintext block prior to

-      encryption.

-

-   Message Authentication Code (MAC)

-      A Message Authentication Code is a one-way hash computed from a

-      message and some secret data. It is difficult to forge without

-      knowing the secret data. Its purpose is to detect if the message

-      has been altered.

-

-   master secret

-      Secure secret data used for generating encryption keys, MAC

-      secrets, and IVs.

-

-   MD5

-      MD5 is a secure hashing function that converts an arbitrarily long

-      data stream into a hash of fixed size (16 bytes). [MD5]

-

-   public key cryptography

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 75]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      A class of cryptographic techniques employing two-key ciphers.

-      Messages encrypted with the public key can only be decrypted with

-      the associated private key. Conversely, messages signed with the

-      private key can be verified with the public key.

-

-   one-way hash function

-      A one-way transformation that converts an arbitrary amount of data

-      into a fixed-length hash. It is computationally hard to reverse

-      the transformation or to find collisions. MD5 and SHA are examples

-      of one-way hash functions.

-

-   RC4

-      A stream cipher invented by Ron Rivest. A compatible cipher is

-      described in [SCH].

-

-   RSA

-      A very widely used public-key algorithm that can be used for

-      either encryption or digital signing. [RSA]

-

-   server

-      The server is the application entity that responds to requests for

-      connections from clients. See also under client.

-

-   session

-      A TLS session is an association between a client and a server.

-      Sessions are created by the handshake protocol. Sessions define a

-      set of cryptographic security parameters that can be shared among

-      multiple connections. Sessions are used to avoid the expensive

-      negotiation of new security parameters for each connection.

-

-   session identifier

-      A session identifier is a value generated by a server that

-      identifies a particular session.

-

-   server write key

-      The key used to encrypt data written by the server.

-

-   server write MAC key

-      The secret data used to authenticate data written by the server.

-

-   SHA

-      The Secure Hash Algorithm is defined in FIPS PUB 180-2. It

-      produces a 20-byte output. Note that all references to SHA

-      actually use the modified SHA-1 algorithm. [SHA]

-

-   SHA-256

-      The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It

-      produces a 32-byte output.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 76]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   SSL

-      Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on

-      SSL Version 3.0

-

-   stream cipher

-      An encryption algorithm that converts a key into a

-      cryptographically strong keystream, which is then exclusive-ORed

-      with the plaintext.

-

-   symmetric cipher

-      See bulk cipher.

-

-   Transport Layer Security (TLS)

-      This protocol; also, the Transport Layer Security working group of

-      the Internet Engineering Task Force (IETF). See "Comments" at the

-      end of this document.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 77]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Appendix C. Cipher Suite Definitions

-

-Cipher Suite                            Key        Cipher         Mac

-                                        Exchange

-

-TLS_NULL_WITH_NULL_NULL                 NULL         NULL         NULL

-TLS_RSA_WITH_NULL_MD5                   RSA          NULL         MD5

-TLS_RSA_WITH_NULL_SHA                   RSA          NULL         SHA

-TLS_RSA_WITH_NULL_SHA256                RSA          NULL         SHA256

-TLS_RSA_WITH_RC4_128_MD5                RSA          RC4_128      MD5

-TLS_RSA_WITH_RC4_128_SHA                RSA          RC4_128      SHA

-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA          3DES_EDE_CBC SHA

-TLS_RSA_WITH_AES_128_CBC_SHA            RSA          AES_128_CBC  SHA

-TLS_RSA_WITH_AES_256_CBC_SHA            RSA          AES_256_CBC  SHA

-TLS_RSA_WITH_AES_128_CBC_SHA256         RSA          AES_128_CBC  SHA256

-TLS_RSA_WITH_AES_256_CBC_SHA256         RSA          AES_256_CBC  SHA256

-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS       3DES_EDE_CBC SHA

-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA       3DES_EDE_CBC SHA

-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS      3DES_EDE_CBC SHA

-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA      3DES_EDE_CBC SHA

-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon      RC4_128      MD5

-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon      3DES_EDE_CBC SHA

-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS       AES_128_CBC  SHA

-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA       AES_128_CBC  SHA

-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS      AES_128_CBC  SHA

-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA      AES_128_CBC  SHA

-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon      AES_128_CBC  SHA

-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS       AES_256_CBC  SHA

-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA       AES_256_CBC  SHA

-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS      AES_256_CBC  SHA

-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA      AES_256_CBC  SHA

-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon      AES_256_CBC  SHA

-TLS_DH_DSS_WITH_AES_128_CBC_SHA256      DH_DSS       AES_128_CBC  SHA256

-TLS_DH_RSA_WITH_AES_128_CBC_SHA256      DH_RSA       AES_128_CBC  SHA256

-TLS_DHE_DSS_WITH_AES_128_CBC_SHA256     DHE_DSS      AES_128_CBC  SHA256

-TLS_DHE_RSA_WITH_AES_128_CBC_SHA256     DHE_RSA      AES_128_CBC  SHA256

-TLS_DH_anon_WITH_AES_128_CBC_SHA256     DH_anon      AES_128_CBC  SHA256

-TLS_DH_DSS_WITH_AES_256_CBC_SHA256      DH_DSS       AES_256_CBC  SHA256

-TLS_DH_RSA_WITH_AES_256_CBC_SHA256      DH_RSA       AES_256_CBC  SHA256

-TLS_DHE_DSS_WITH_AES_256_CBC_SHA256     DHE_DSS      AES_256_CBC  SHA256

-TLS_DHE_RSA_WITH_AES_256_CBC_SHA256     DHE_RSA      AES_256_CBC  SHA256

-TLS_DH_anon_WITH_AES_256_CBC_SHA256     DH_anon      AES_256_CBC  SHA256

-

-

-                     Key      Expanded     IV    Block

-Cipher       Type  Material Key Material   Size   Size

-

-NULL         Stream   0          0         0     N/A

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 78]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-RC4_128      Stream  16         16         0     N/A

-3DES_EDE_CBC Block   24         24         8      8

-AES_128_CBC  Block   16         16         16    16

-AES_256_CBC  Block   32         32         16    16

-

-

-MAC       Algorithm    mac_length  mac_key_length

-

-NULL      N/A          0           0

-MD5       HMAC-MD5     16          16

-SHA       HMAC-SHA1    20          20

-SHA256    HMAC-SHA256  32          32

-

-   Type

-      Indicates whether this is a stream cipher or a block cipher

-      running in CBC mode.

-

-   Key Material

-      The number of bytes from the key_block that are used for

-      generating the write keys.

-

-   Expanded Key Material

-      The number of bytes actually fed into the encryption algorithm.

-

-   IV Size

-      The amount of data needed to be generated for the initialization

-      vector. Zero for stream ciphers; equal to the block size for block

-      ciphers (this is equal to SecurityParameters.record_iv_length).

-

-   Block Size

-      The amount of data a block cipher enciphers in one chunk; a block

-      cipher running in CBC mode can only encrypt an even multiple of

-      its block size.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 79]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Appendix D. Implementation Notes

-

-   The TLS protocol cannot prevent many common security mistakes. This

-   section provides several recommendations to assist implementors.

-

-D.1 Random Number Generation and Seeding

-

-   TLS requires a cryptographically secure pseudorandom number generator

-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs

-   based on secure hash operations, most notably SHA-1, are acceptable,

-   but cannot provide more security than the size of the random number

-   generator state.

-

-   To estimate the amount of seed material being produced, add the

-   number of bits of unpredictable information in each seed byte. For

-   example, keystroke timing values taken from a PC compatible's 18.2 Hz

-   timer provide 1 or 2 secure bits each, even though the total size of

-   the counter value is 16 bits or more. Seeding a 128-bit PRNG would

-   thus require approximately 100 such timer values.

-

-   [RANDOM] provides guidance on the generation of random values.

-

-D.2 Certificates and Authentication

-

-   Implementations are responsible for verifying the integrity of

-   certificates and should generally support certificate revocation

-   messages. Certificates should always be verified to ensure proper

-   signing by a trusted Certificate Authority (CA). The selection and

-   addition of trusted CAs should be done very carefully. Users should

-   be able to view information about the certificate and root CA.

-

-D.3 Cipher Suites

-

-   TLS supports a range of key sizes and security levels, including some

-   that provide no or minimal security. A proper implementation will

-   probably not support many cipher suites. For instance, anonymous

-   Diffie-Hellman is strongly discouraged because it cannot prevent man-

-   in-the-middle attacks. Applications should also enforce minimum and

-   maximum key sizes. For example, certificate chains containing 512-bit

-   RSA keys or signatures are not appropriate for high-security

-   applications.

-

-D.4 Implementation Pitfalls

-

-   Implementation experience has shown that certain parts of earlier TLS

-   specifications are not easy to understand, and have been a source of

-   interoperability and security problems. Many of these areas have been

-   clarified in this document, but this appendix contains a short list

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 80]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   of the most important things that require special attention from

-   implementors.

-

-   TLS protocol issues:

-

-   -  Do you correctly handle handshake messages that are fragmented

-      to multiple TLS records (see Section 6.2.1)? Including corner

-      cases like a ClientHello that is split to several small

-      fragments? Do you fragment handshake messages that exceed the

-      maximum fragment size? In particular, the certificate and

-      certificate request handshake messages can be large enough to

-      require fragmentation.

-

-   -  Do you ignore the TLS record layer version number in all TLS

-      records before ServerHello (see Appendix E.1)?

-

-   -  Do you handle TLS extensions in ClientHello correctly,

-      including omitting the extensions field completely?

-

-   -  Do you support renegotiation, both client and server initiated?

-      While renegotiation is an optional feature, supporting

-      it is highly recommended.

-

-   -  When the server has requested a client certificate, but no

-      suitable certificate is available, do you correctly send

-      an empty Certificate message, instead of omitting the whole

-      message (see Section 7.4.6)?

-

-   Cryptographic details:

-

-   -  In RSA-encrypted Premaster Secret,  do you correctly send and

-      verify the version number? When an error is encountered, do

-      you continue the handshake to avoid the Bleichenbacher

-      attack (see Section 7.4.7.1)?

-

-   -  What countermeasures do you use to prevent timing attacks against

-      RSA decryption and signing operations (see Section 7.4.7.1)?

-

-   -  When verifying RSA signatures, do you accept both NULL and

-      missing parameters (see Section 4.7)? Do you verify that the

-      RSA padding doesn't have additional data after the hash value?

-      [FI06]

-

-   -  When using Diffie-Hellman key exchange, do you correctly strip

-      leading zero bytes from the negotiated key (see Section 8.1.2)?

-

-   -  Does your TLS client check that the Diffie-Hellman parameters

-      sent by the server are acceptable (see Section F.1.1.3)?

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 81]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   -  How do you generate unpredictable IVs for CBC mode ciphers

-      (see Section 6.2.3.2)?

-

-   -  Do you accept long CBC mode padding (up to 255 bytes; see

-      Section 6.2.3.2)?

-

-   -  How do you address CBC mode timing attacks (Section 6.2.3.2)?

-

-   -  Do you use a strong and, most importantly, properly seeded

-      random number generator (see Appendix D.1) for generating the

-      premaster secret (for RSA key exchange), Diffie-Hellman private

-      values, the DSA "k" parameter, and other security-critical

-      values?

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 82]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Appendix E. Backward Compatibility

-

-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0

-

-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any

-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate

-   the specific protocol version to use.  The TLS protocol provides a

-   built-in mechanism for version negotiation so as not to bother other

-   protocol components with the complexities of version selection.

-

-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use

-   compatible ClientHello messages; thus, supporting all of them is

-   relatively easy.  Similarly, servers can easily handle clients trying

-   to use future versions of TLS as long as the ClientHello format

-   remains compatible, and the client support the highest protocol

-   version available in the server.

-

-   A TLS 1.2 client who wishes to negotiate with such older servers will

-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in

-   ClientHello.client_version. If the server does not support this

-   version, it will respond with ServerHello containing an older version

-   number. If the client agrees to use this version, the negotiation

-   will proceed as appropriate for the negotiated protocol.

-

-   If the version chosen by the server is not supported by the client

-   (or not acceptable), the client MUST send a "protocol_version" alert

-   message and close the connection.

-

-   If a TLS server receives a ClientHello containing a version number

-   greater than the highest version supported by the server, it MUST

-   reply according to the highest version supported by the server.

-

-   A TLS server can also receive a ClientHello containing version number

-   smaller than the highest supported version. If the server wishes to

-   negotiate with old clients, it will proceed as appropriate for the

-   highest version supported by the server that is not greater than

-   ClientHello.client_version. For example, if the server supports TLS

-   1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will

-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing

-   to use) only versions greater than client_version, it MUST send a

-   "protocol_version" alert message and close the connection.

-

-   Whenever a client already knows the highest protocol known to a

-   server (for example, when resuming a session), it SHOULD initiate the

-   connection in that native protocol.

-

-   Note: some server implementations are known to implement version

-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 83]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   that simply close the connection when the client offers a version

-   newer than TLS 1.0. Also, it is known that some servers will refuse

-   connection if any TLS extensions are included in ClientHello.

-   Interoperability with such buggy servers is a complex topic beyond

-   the scope of this document, and may require multiple connection

-   attempts by the client.

-

-   Earlier versions of the TLS specification were not fully clear on

-   what the record layer version number (TLSPlaintext.version) should

-   contain when sending ClientHello (i.e., before it is known which

-   version of the protocol will be employed). Thus, TLS servers

-   compliant with this specification MUST accept any value {03,XX} as

-   the record layer version number for ClientHello.

-

-   TLS clients that wish to negotiate with older servers MAY send any

-   value {03,XX} as the record layer version number. Typical values

-   would be {03,00}, the lowest version number supported by the client,

-   and the value of ClientHello.client_version. No single value will

-   guarantee interoperability with all old servers, but this is a

-   complex topic beyond the scope of this document.

-

-E.2 Compatibility with SSL 2.0

-

-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send

-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST

-   contain the same version number as would be used for ordinary

-   ClientHello, and MUST encode the supported TLS cipher suites in the

-   CIPHER-SPECS-DATA field as described below.

-

-   Warning: The ability to send version 2.0 CLIENT-HELLO messages will

-   be phased out with all due haste, since the newer ClientHello format

-   provides better mechanisms for moving to newer versions and

-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.

-

-   However, even TLS servers that do not support SSL 2.0 MAY accept

-   version 2.0 CLIENT-HELLO messages. The message is presented below in

-   sufficient detail for TLS server implementors; the true definition is

-   still assumed to be [SSL2].

-

-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same

-   way as a ClientHello with a "null" compression method and no

-   extensions. Note that this message MUST be sent directly on the wire,

-   not wrapped as a TLS record. For the purposes of calculating Finished

-   and CertificateVerify, the msg_length field is not considered to be a

-   part of the handshake message.

-

-      uint8 V2CipherSpec[3];

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 84]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-      struct {

-          uint16 msg_length;

-          uint8 msg_type;

-          Version version;

-          uint16 cipher_spec_length;

-          uint16 session_id_length;

-          uint16 challenge_length;

-          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];

-          opaque session_id[V2ClientHello.session_id_length];

-          opaque challenge[V2ClientHello.challenge_length;

-      } V2ClientHello;

-

-   msg_length

-      The highest bit MUST be 1; the remaining bits contain the length

-      of the following data in bytes.

-

-   msg_type

-      This field, in conjunction with the version field, identifies a

-      version 2 client hello message. The value MUST be one (1).

-

-   version

-      Equal to ClientHello.client_version.

-

-   cipher_spec_length

-      This field is the total length of the field cipher_specs. It

-      cannot be zero and MUST be a multiple of the V2CipherSpec length

-      (3).

-

-   session_id_length

-      This field MUST have a value of zero for a client that claims to

-      support TLS 1.2.

-

-   challenge_length

-      The length in bytes of the client's challenge to the server to

-      authenticate itself. Historically, permissible values are between

-      16 and 32 bytes inclusive. When using the SSLv2 backward

-      compatible handshake the client SHOULD use a 32 byte challenge.

-

-   cipher_specs

-      This is a list of all CipherSpecs the client is willing and able

-      to use. In addition to the 2.0 cipher specs defined in [SSL2],

-      this includes the TLS cipher suites normally sent in

-      ClientHello.cipher_suites, each cipher suite prefixed by a zero

-      byte. For example, TLS cipher suite {0x00,0x0A} would be sent as

-      {0x00,0x00,0x0A}.

-

-   session_id

-      This field MUST be empty.

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 85]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   challenge

-      Corresponds to ClientHello.random. If the challenge length is less

-      than 32, the TLS server will pad the data with leading (note: not

-      trailing) zero bytes to make it 32 bytes long.

-

-   Note: Requests to resume a TLS session MUST use a TLS client hello.

-

-E.3. Avoiding Man-in-the-Middle Version Rollback

-

-   When TLS clients fall back to Version 2.0 compatibility mode, they

-   MUST use special PKCS#1 block formatting. This is done so that TLS

-   servers will reject Version 2.0 sessions with TLS-capable clients.

-

-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set

-   the right-hand (least-significant) 8 random bytes of the PKCS padding

-   (not including the terminal null of the padding) for the RSA

-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY

-   to 0x03 (the other padding bytes are random).

-

-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after

-   decrypting the ENCRYPTED-KEY-DATA field, check that these eight

-   padding bytes are 0x03. If they are not, the server SHOULD generate a

-   random value for SECRET-KEY-DATA, and continue the handshake (which

-   will eventually fail since the keys will not match).  Note that

-   reporting the error situation to the client could make the server

-   vulnerable to attacks described in [BLEI].

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 86]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Appendix F. Security Analysis

-

-   The TLS protocol is designed to establish a secure connection between

-   a client and a server communicating over an insecure channel. This

-   document makes several traditional assumptions, including that

-   attackers have substantial computational resources and cannot obtain

-   secret information from sources outside the protocol. Attackers are

-   assumed to have the ability to capture, modify, delete, replay, and

-   otherwise tamper with messages sent over the communication channel.

-   This appendix outlines how TLS has been designed to resist a variety

-   of attacks.

-

-F.1. Handshake Protocol

-

-   The handshake protocol is responsible for selecting a CipherSpec and

-   generating a Master Secret, which together comprise the primary

-   cryptographic parameters associated with a secure session. The

-   handshake protocol can also optionally authenticate parties who have

-   certificates signed by a trusted certificate authority.

-

-F.1.1. Authentication and Key Exchange

-

-   TLS supports three authentication modes: authentication of both

-   parties, server authentication with an unauthenticated client, and

-   total anonymity. Whenever the server is authenticated, the channel is

-   secure against man-in-the-middle attacks, but completely anonymous

-   sessions are inherently vulnerable to such attacks.  Anonymous

-   servers cannot authenticate clients. If the server is authenticated,

-   its certificate message must provide a valid certificate chain

-   leading to an acceptable certificate authority.  Similarly,

-   authenticated clients must supply an acceptable certificate to the

-   server. Each party is responsible for verifying that the other's

-   certificate is valid and has not expired or been revoked.

-

-   The general goal of the key exchange process is to create a

-   pre_master_secret known to the communicating parties and not to

-   attackers. The pre_master_secret will be used to generate the

-   master_secret (see Section 8.1). The master_secret is required to

-   generate the finished messages, encryption keys, and MAC keys (see

-   Sections 7.4.9 and 6.3). By sending a correct finished message,

-   parties thus prove that they know the correct pre_master_secret.

-

-F.1.1.1. Anonymous Key Exchange

-

-   Completely anonymous sessions can be established using Diffie-Hellman

-   for key exchange. The server's public parameters are contained in the

-   server key exchange message and the client's are sent in the client

-   key exchange message. Eavesdroppers who do not know the private

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 87]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   values should not be able to find the Diffie-Hellman result (i.e. the

-   pre_master_secret).

-

-   Warning: Completely anonymous connections only provide protection

-   against passive eavesdropping. Unless an independent tamper-proof

-   channel is used to verify that the finished messages were not

-   replaced by an attacker, server authentication is required in

-   environments where active man-in-the-middle attacks are a concern.

-

-F.1.1.2. RSA Key Exchange and Authentication

-

-   With RSA, key exchange and server authentication are combined. The

-   public key is contained in the server's certificate.  Note that

-   compromise of the server's static RSA key results in a loss of

-   confidentiality for all sessions protected under that static key. TLS

-   users desiring Perfect Forward Secrecy should use DHE cipher suites.

-   The damage done by exposure of a private key can be limited by

-   changing one's private key (and certificate) frequently.

-

-   After verifying the server's certificate, the client encrypts a

-   pre_master_secret with the server's public key. By successfully

-   decoding the pre_master_secret and producing a correct finished

-   message, the server demonstrates that it knows the private key

-   corresponding to the server certificate.

-

-   When RSA is used for key exchange, clients are authenticated using

-   the certificate verify message (see Section 7.4.8). The client signs

-   a value derived from all preceding handshake messages. These

-   handshake messages include the server certificate, which binds the

-   signature to the server, and ServerHello.random, which binds the

-   signature to the current handshake process.

-

-F.1.1.3. Diffie-Hellman Key Exchange with Authentication

-

-   When Diffie-Hellman key exchange is used, the server can either

-   supply a certificate containing fixed Diffie-Hellman parameters or

-   use the server key exchange message to send a set of temporary

-   Diffie-Hellman parameters signed with a DSS or RSA certificate.

-   Temporary parameters are hashed with the hello.random values before

-   signing to ensure that attackers do not replay old parameters. In

-   either case, the client can verify the certificate or signature to

-   ensure that the parameters belong to the server.

-

-   If the client has a certificate containing fixed Diffie-Hellman

-   parameters, its certificate contains the information required to

-   complete the key exchange. Note that in this case the client and

-   server will generate the same Diffie-Hellman result (i.e.,

-   pre_master_secret) every time they communicate. To prevent the

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 88]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   pre_master_secret from staying in memory any longer than necessary,

-   it should be converted into the master_secret as soon as possible.

-   Client Diffie-Hellman parameters must be compatible with those

-   supplied by the server for the key exchange to work.

-

-   If the client has a standard DSS or RSA certificate or is

-   unauthenticated, it sends a set of temporary parameters to the server

-   in the client key exchange message, then optionally uses a

-   certificate verify message to authenticate itself.

-

-   If the same DH keypair is to be used for multiple handshakes, either

-   because the client or server has a certificate containing a fixed DH

-   keypair or because the server is reusing DH keys, care must be taken

-   to prevent small subgroup attacks. Implementations SHOULD follow the

-   guidelines found in [SUBGROUP].

-

-   Small subgroup attacks are most easily avoided by using one of the

-   DHE cipher suites and generating a fresh DH private key (X) for each

-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be

-   computed very quickly, therefore the performance cost is minimized.

-   Additionally, using a fresh key for each handshake provides Perfect

-   Forward Secrecy. Implementations SHOULD generate a new X for each

-   handshake when using DHE cipher suites.

-

-   Because TLS allows the server to provide arbitrary DH groups, the

-   client should verify that the DH group is of suitable size as defined

-   by local policy. The client SHOULD also verify that the DH public

-   exponent appears to be of adequate size. [KEYSIZ] provides a useful

-   guide to the strength of various group sizes.  The server MAY choose

-   to assist the client by providing a known group, such as those

-   defined in [IKEALG] or [MODP]. These can be verified by simple

-   comparison.

-

-F.1.2. Version Rollback Attacks

-

-   Because TLS includes substantial improvements over SSL Version 2.0,

-   attackers may try to make TLS-capable clients and servers fall back

-   to Version 2.0. This attack can occur if (and only if) two TLS-

-   capable parties use an SSL 2.0 handshake.

-

-   Although the solution using non-random PKCS #1 block type 2 message

-   padding is inelegant, it provides a reasonably secure way for Version

-   3.0 servers to detect the attack. This solution is not secure against

-   attackers who can brute force the key and substitute a new ENCRYPTED-

-   KEY-DATA message containing the same key (but with normal padding)

-   before the application specified wait threshold has expired. Altering

-   the padding of the least significant 8 bytes of the PKCS padding does

-   not impact security for the size of the signed hashes and RSA key

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 89]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   lengths used in the protocol, since this is essentially equivalent to

-   increasing the input block size by 8 bytes.

-

-F.1.3. Detecting Attacks Against the Handshake Protocol

-

-   An attacker might try to influence the handshake exchange to make the

-   parties select different encryption algorithms than they would

-   normally chooses.

-

-   For this attack, an attacker must actively change one or more

-   handshake messages. If this occurs, the client and server will

-   compute different values for the handshake message hashes. As a

-   result, the parties will not accept each others' finished messages.

-   Without the master_secret, the attacker cannot repair the finished

-   messages, so the attack will be discovered.

-

-F.1.4. Resuming Sessions

-

-   When a connection is established by resuming a session, new

-   ClientHello.random and ServerHello.random values are hashed with the

-   session's master_secret. Provided that the master_secret has not been

-   compromised and that the secure hash operations used to produce the

-   encryption keys and MAC keys are secure, the connection should be

-   secure and effectively independent from previous connections.

-   Attackers cannot use known encryption keys or MAC secrets to

-   compromise the master_secret without breaking the secure hash

-   operations.

-

-   Sessions cannot be resumed unless both the client and server agree.

-   If either party suspects that the session may have been compromised,

-   or that certificates may have expired or been revoked, it should

-   force a full handshake. An upper limit of 24 hours is suggested for

-   session ID lifetimes, since an attacker who obtains a master_secret

-   may be able to impersonate the compromised party until the

-   corresponding session ID is retired. Applications that may be run in

-   relatively insecure environments should not write session IDs to

-   stable storage.

-

-F.2. Protecting Application Data

-

-   The master_secret is hashed with the ClientHello.random and

-   ServerHello.random to produce unique data encryption keys and MAC

-   secrets for each connection.

-

-   Outgoing data is protected with a MAC before transmission. To prevent

-   message replay or modification attacks, the MAC is computed from the

-   MAC key, the sequence number, the message length, the message

-   contents, and two fixed character strings. The message type field is

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 90]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   necessary to ensure that messages intended for one TLS Record Layer

-   client are not redirected to another. The sequence number ensures

-   that attempts to delete or reorder messages will be detected. Since

-   sequence numbers are 64 bits long, they should never overflow.

-   Messages from one party cannot be inserted into the other's output,

-   since they use independent MAC keys. Similarly, the server-write and

-   client-write keys are independent, so stream cipher keys are used

-   only once.

-

-   If an attacker does break an encryption key, all messages encrypted

-   with it can be read. Similarly, compromise of a MAC key can make

-   message modification attacks possible. Because MACs are also

-   encrypted, message-alteration attacks generally require breaking the

-   encryption algorithm as well as the MAC.

-

-   Note: MAC keys may be larger than encryption keys, so messages can

-   remain tamper resistant even if encryption keys are broken.

-

-F.3. Explicit IVs

-

-   [CBCATT] describes a chosen plaintext attack on TLS that depends on

-   knowing the IV for a record. Previous versions of TLS [TLS1.0] used

-   the CBC residue of the previous record as the IV and therefore

-   enabled this attack. This version uses an explicit IV in order to

-   protect against this attack.

-

-F.4. Security of Composite Cipher Modes

-

-   TLS secures transmitted application data via the use of symmetric

-   encryption and authentication functions defined in the negotiated

-   cipher suite.  The objective is to protect both the integrity and

-   confidentiality of the transmitted data from malicious actions by

-   active attackers in the network.  It turns out that the order in

-   which encryption and authentication functions are applied to the data

-   plays an important role for achieving this goal [ENCAUTH].

-

-   The most robust method, called encrypt-then-authenticate, first

-   applies encryption to the data and then applies a MAC to the

-   ciphertext.  This method ensures that the integrity and

-   confidentiality goals are obtained with ANY pair of encryption and

-   MAC functions, provided that the former is secure against chosen

-   plaintext attacks and that the MAC is secure against chosen-message

-   attacks.  TLS uses another method, called authenticate-then-encrypt,

-   in which first a MAC is computed on the plaintext and then the

-   concatenation of plaintext and MAC is encrypted.  This method has

-   been proven secure for CERTAIN combinations of encryption functions

-   and MAC functions, but it is not guaranteed to be secure in general.

-   In particular, it has been shown that there exist perfectly secure

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 91]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   encryption functions (secure even in the information-theoretic sense)

-   that combined with any secure MAC function, fail to provide the

-   confidentiality goal against an active attack.  Therefore, new cipher

-   suites and operation modes adopted into TLS need to be analyzed under

-   the authenticate-then-encrypt method to verify that they achieve the

-   stated integrity and confidentiality goals.

-

-   Currently, the security of the authenticate-then-encrypt method has

-   been proven for some important cases.  One is the case of stream

-   ciphers in which a computationally unpredictable pad of the length of

-   the message, plus the length of the MAC tag, is produced using a

-   pseudo-random generator and this pad is xor-ed with the concatenation

-   of plaintext and MAC tag.  The other is the case of CBC mode using a

-   secure block cipher.  In this case, security can be shown if one

-   applies one CBC encryption pass to the concatenation of plaintext and

-   MAC and uses a new, independent, and unpredictable IV for each new

-   pair of plaintext and MAC.  In versions of TLS prior to 1.1, CBC mode

-   was used properly EXCEPT that it used a predictable IV in the form of

-   the last block of the previous ciphertext.  This made TLS open to

-   chosen plaintext attacks.  This version of the protocol is immune to

-   those attacks.  For exact details in the encryption modes proven

-   secure, see [ENCAUTH].

-

-F.5 Denial of Service

-

-   TLS is susceptible to a number of denial of service (DoS) attacks.

-   In particular, an attacker who initiates a large number of TCP

-   connections can cause a server to consume large amounts of CPU doing

-   RSA decryption. However, because TLS is generally used over TCP, it

-   is difficult for the attacker to hide his point of origin if proper

-   TCP SYN randomization is used [SEQNUM] by the TCP stack.

-

-   Because TLS runs over TCP, it is also susceptible to a number of

-   denial of service attacks on individual connections. In particular,

-   attackers can forge RSTs, thereby terminating connections, or forge

-   partial TLS records, thereby causing the connection to stall.  These

-   attacks cannot in general be defended against by a TCP-using

-   protocol.  Implementors or users who are concerned with this class of

-   attack should use IPsec AH [AH] or ESP [ESP].

-

-F.6 Final Notes

-

-   For TLS to be able to provide a secure connection, both the client

-   and server systems, keys, and applications must be secure. In

-   addition, the implementation must be free of security errors.

-

-   The system is only as strong as the weakest key exchange and

-   authentication algorithm supported, and only trustworthy

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 92]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   cryptographic functions should be used. Short public keys and

-   anonymous servers should be used with great caution. Implementations

-   and users must be careful when deciding which certificates and

-   certificate authorities are acceptable; a dishonest certificate

-   authority can do tremendous damage.

-

-Changes in This Version

-   [RFC Editor: Please delete this]

-

-   - Added a new pitfall about fragmenting messages when necessary

-     [Issue #71]

-

-   - Added Updates: RFC 4492 [Issue #83]

-

-   - Long CBC padding pitfall [Issue #73]

-

-   - Fixed ProtocolVersion structure [Issue #79]

-

-   - Cleaned up extensions text [Issue #78]

-

-   - Clarified alerts some [Issue #85]

-

-   - Added AES to the table in Appendix C [Issue #72]

-

-   - Tightened up when signature_algorithms is used

-     (it is now a MUST if you support other than SHA-1)

-     and the interpretation when it is absent is also a MUST

-     [Issue #67]

-

-   - Cleaned up "cipher suite" so it's always two words outside

-     of when it refers to the syntactic type [Issue #68]

-

-   - Misc editorial.

-

-   - Added support for SHA256 cipher suites

-

-   - Clarified warning alert behavior and client certificate omission

-   behavior [Issue #84]

-

-   - Removed IDEA and DES entirely for documentation in a separate doc

-   [Issue #64]

-

-   - Changed the presentation language to allow fall-through to simplify

-   some of the PDUs.

-

-   - Cleaned up KeyExchangeAlgorithm ClientKeyExchange to use values

-   that match Appendix C.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 93]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   - Changed digitally-signed to include SignatureAndHashAlgorithm

-   (another simplification)

-

-   - Considerations for RFC 4492

-

-Normative References

-

-   [AES]    National Institute of Standards and Technology,

-            "Specification for the Advanced Encryption Standard (AES)"

-            FIPS 197.  November 26, 2001.

-

-   [3DES]   National Institute of Standards and Technology,

-            "Recommendation for the Triple Data Encryption Algorithm

-            (TDEA) Block Cipher", NIST Special Publication 800-67, May

-            2004.

-

-   [DES]    National Institute of Standards and Technology, "Data

-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.

-

-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard," National

-            Institute of Standards and Technology, U.S. Department of

-            Commerce, 2000.

-

-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-

-            Hashing for Message Authentication", RFC 2104, February

-            1997.

-

-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,

-            April 1992.

-

-   [PKCS1]  J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards

-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC

-            3447, February 2003.

-

-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509

-            Public Key Infrastructure Certificate and Certificate

-            Revocation List (CRL) Profile", RFC 3280, April 2002.

-

-

-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,

-            and Source Code in C, 2nd ed.", Published by John Wiley &

-            Sons, Inc. 1996.

-

-   [SHA]    NIST FIPS PUB 180-2, "Secure Hash Standard," National

-            Institute of Standards and Technology, U.S. Department of

-            Commerce., August 2001.

-

-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 94]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-            Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an

-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,

-            October 1998.

-

-Informative References

-

-   [AEAD]   Mcgrew, D., "Authenticated Encryption", July 2007, draft-

-            mcgrew-auth-enc-05.txt.

-

-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC

-            4302, December 2005.

-

-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against

-            Protocols Based on RSA Encryption Standard PKCS #1" in

-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:

-            1-12, 1998.

-

-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:

-            Problems and Countermeasures",

-            http://www.openssl.org/~bodo/tls-cbc.txt.

-

-   [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,

-            "Password Interception in a SSL/TLS Channel", Advances in

-            Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.

-

-   [CCM]    "NIST Special Publication 800-38C: The CCM Mode for

-            Authentication and Confidentiality",

-            http://csrc.nist.gov/publications/nistpubs/800-38C/

-            SP800-38C.pdf

-

-   [DSS-3]  NIST FIPS PUB 186-3 Draft, "Digital Signature Standard,"

-            National Institute of Standards and Technology, U.S.

-            Department of Commerce, 2006.

-

-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication

-            for Protecting Communications (Or: How Secure is SSL?)",

-            Crypto 2001.

-

-   [ESP]    Kent, S., and Atkinson, R., "IP Encapsulating Security

-            Payload (ESP)", RFC 4303, December 2005.

-

-   [FI06]   Hal Finney, "Bleichenbacher's RSA signature forgery based on

-            implementation error", ietf-openpgp@imc.org mailing list, 27

-            August 2006, http://www.imc.org/ietf-openpgp/mail-

-            archive/msg14307.html.

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 95]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   [GCM]    "NIST Special Publication 800-38D DRAFT (June, 2007):

-            Recommendation for Block Cipher Modes of Operation:

-            Galois/Counter Mode (GCM) and GMAC"

-

-   [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the

-            Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December

-            2005.

-

-   [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For

-            Public Keys Used For Exchanging Symmetric Keys" RFC 3766,

-            April 2004.

-

-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based

-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,

-            March 2003.

-

-   [MODP]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)

-            Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC

-            3526, May 2003.

-

-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax

-            Standard," version 1.5, November 1993.

-

-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax

-            Standard," version 1.5, November 1993.

-

-   [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness

-            Requirements for Security", BCP 106, RFC 4086, June 2005.

-

-   [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol

-            Compression Methods", RFC 3749, May 2004.

-

-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,

-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC

-            4366, April 2006.

-

-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for

-            Obtaining Digital Signatures and Public-Key Cryptosystems,"

-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.

-            120-126.

-

-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",

-            RFC 1948, May 1996.

-

-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications

-            Corp., Feb 9, 1995.

-

-   [SSL3]   A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 96]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-            Protocol", Netscape Communications Corp., Nov 18, 1996.

-

-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"

-            Attacks on the Diffie-Hellman Key Agreement Method for

-            S/MIME", RFC 2785, March 2000.

-

-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,

-            September 1981.

-

-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are

-            practical", USENIX Security Symposium 2003.

-

-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites

-            for Transport Layer Security (TLS)", RFC 3268, June 2002.

-

-   [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and

-            Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher

-            Suites for Transport Layer Security (TLS)", RFC 4492, May

-            2006.

-

-   [TLSEXT] Eastlake, D.E.,  "Transport Layer Security (TLS) Extensions:

-            Extension Definitions", January 2008, draft-ietf-tls-

-            rfc4366-bis-01.txt.

-

-   [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS

-            authentication", RFC 5081, November 2007.

-

-   [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for

-            Transport Layer Security (TLS)", RFC 4279, December 2005.

-

-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",

-            RFC 2246, January 1999.

-

-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version

-            1.1", RFC 4346, April, 2006.

-

-   [X501]   ITU-T Recommendation X.501: Information Technology - Open

-            Systems Interconnection - The Directory: Models, 1993.

-

-   [XDR]    Eisler, M., "External Data Representation Standard", RFC

-            4506, May 2006.

-

-

-Credits

-

-   Working Group Chairs

-

-   Eric Rescorla

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 97]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   EMail: ekr@networkresonance.com

-

-   Pasi Eronen

-   pasi.eronen@nokia.com

-

-

-   Editors

-

-   Tim Dierks                    Eric Rescorla

-   Independent                   Network Resonance, Inc.

-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com

-

-

-   Other contributors

-

-   Christopher Allen (co-editor of TLS 1.0)

-   Alacrity Ventures

-   ChristopherA@AlacrityManagement.com

-

-   Martin Abadi

-   University of California, Santa Cruz

-   abadi@cs.ucsc.edu

-

-   Steven M. Bellovin

-   Columbia University

-   smb@cs.columbia.edu

-

-   Simon Blake-Wilson

-   BCI

-   EMail: sblakewilson@bcisse.com

-

-   Ran Canetti

-   IBM

-   canetti@watson.ibm.com

-

-   Pete Chown

-   Skygate Technology Ltd

-   pc@skygate.co.uk

-

-   Taher Elgamal

-   taher@securify.com

-   Securify

-

-   Pasi Eronen

-   pasi.eronen@nokia.com

-   Nokia

-

-   Anil Gangolli

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 98]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-   anil@busybuddha.org

-

-   Kipp Hickman

-

-   Alfred Hoenes

-

-   David Hopwood

-   Independent Consultant

-   EMail: david.hopwood@blueyonder.co.uk

-

-   Phil Karlton (co-author of SSLv3)

-

-   Paul Kocher (co-author of SSLv3)

-   Cryptography Research

-   paul@cryptography.com

-

-   Hugo Krawczyk

-   IBM

-   hugo@ee.technion.ac.il

-

-   Jan Mikkelsen

-   Transactionware

-   EMail: janm@transactionware.com

-

-   Magnus Nystrom

-   RSA Security

-   EMail: magnus@rsasecurity.com

-

-   Robert Relyea

-   Netscape Communications

-   relyea@netscape.com

-

-   Jim Roskind

-   Netscape Communications

-   jar@netscape.com

-

-   Michael Sabin

-

-   Dan Simon

-   Microsoft, Inc.

-   dansimon@microsoft.com

-

-   Tom Weinstein

-

-   Tim Wright

-   Vodafone

-   EMail: timothy.wright@vodafone.com

-

-

-

-

-Dierks & Rescorla            Standards Track                   [Page 99]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Comments

-

-   The discussion list for the IETF TLS working group is located at the

-   e-mail address <tls@ietf.org>. Information on the group and

-   information on how to subscribe to the list is at

-   <https://www1.ietf.org/mailman/listinfo/tls>

-

-   Archives of the list can be found at:

-   <http://www.ietf.org/mail-archive/web/tls/current/index.html>

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Dierks & Rescorla            Standards Track                  [Page 100]

-

-draft-ietf-tls-rfc4346-bis-09.txt  TLS                    February, 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-Acknowledgment

-

-   Funding for the RFC Editor function is provided by the IETF

-   Administrative Support Activity (IASA).

-

-

-

-

-

-Dierks & Rescorla            Standards Track                  [Page 101]

-

-

-

-

diff --git a/doc/protocol/draft-ietf-tls-rfc4346-bis-10.txt b/doc/protocol/draft-ietf-tls-rfc4346-bis-10.txt
deleted file mode 100644
index 8911c2549b..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4346-bis-10.txt
+++ /dev/null
@@ -1,5660 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                Tim Dierks
-Obsoletes (if approved): RFC 3268, 4346, 4366                Independent
-Updates (if approved): RFC 4492                            Eric Rescorla
-Intended status:  Proposed Standard              Network Resonance, Inc.
-<draft-ietf-tls-rfc4346-bis-10.txt>  March 2008 (Expires September 2008)
-
-
-              The Transport Layer Security (TLS) Protocol
-                              Version 1.2
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2008).
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications security
-   over the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 1]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-Table of Contents
-
-   1.        Introduction                                             4
-   1.1.      Requirements Terminology                                 5
-   1.2.      Major Differences from TLS 1.1                           5
-   2.        Goals                                                    6
-   3.        Goals of This Document                                   7
-   4.        Presentation Language                                    7
-   4.1.      Basic Block Size                                         7
-   4.2.      Miscellaneous                                            7
-   4.3.      Vectors                                                  8
-   4.4.      Numbers                                                  9
-   4.5.      Enumerateds                                              9
-   4.6.      Constructed Types                                        10
-   4.6.1.    Variants                                                 10
-   4.7.      Cryptographic Attributes                                 11
-   4.8.      Constants                                                13
-   5.        HMAC and the Pseudorandom Function                       14
-   6.        The TLS Record Protocol                                  15
-   6.1.      Connection States                                        16
-   6.2.      Record layer                                             18
-   6.2.1.    Fragmentation                                            19
-   6.2.2.    Record Compression and Decompression                     20
-   6.2.3.    Record Payload Protection                                21
-   6.2.3.1.  Null or Standard Stream Cipher                           21
-   6.2.3.2.  CBC Block Cipher                                         22
-   6.2.3.3.  AEAD ciphers                                             24
-   6.3.      Key Calculation                                          25
-   7.        The TLS Handshaking Protocols                            26
-   7.1.      Change Cipher Spec Protocol                              27
-   7.2.      Alert Protocol                                           27
-   7.2.1.    Closure Alerts                                           28
-   7.2.2.    Error Alerts                                             29
-   7.3.      Handshake Protocol Overview                              33
-   7.4.      Handshake Protocol                                       37
-   7.4.1.    Hello Messages                                           38
-   7.4.1.1.  Hello Request                                            38
-   7.4.1.2.  Client Hello                                             39
-   7.4.1.3.  Server Hello                                             42
-   7.4.1.4   Hello Extensions                                         43
-   7.4.1.4.1 Signature Algorithms                                     45
-   7.4.2.    Server Certificate                                       46
-   7.4.3.    Server Key Exchange Message                              49
-   7.4.4.    Certificate Request                                      51
-   7.4.5     Server Hello Done                                        53
-   7.4.6.    Client Certificate                                       53
-   7.4.7.    Client Key Exchange Message                              55
-   7.4.7.1.  RSA Encrypted Premaster Secret Message                   56
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 2]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   7.4.7.2.  Client Diffie-Hellman Public Value                       58
-   7.4.8.    Certificate verify                                       59
-   7.4.9.    Finished                                                 60
-   8.        Cryptographic Computations                               62
-   8.1.      Computing the Master Secret                              62
-   8.1.1.    RSA                                                      62
-   8.1.2.    Diffie-Hellman                                           62
-   9.        Mandatory Cipher Suites                                  63
-   10.       Application Data Protocol                                63
-   11.       Security Considerations                                  63
-   12.       IANA Considerations                                      63
-   A.        Protocol Data Structures and Constant Values             65
-   A.1.      Record Layer                                             65
-   A.2.      Change Cipher Specs Message                              66
-   A.3.      Alert Messages                                           66
-   A.4.      Handshake Protocol                                       67
-   A.4.1.    Hello Messages                                           67
-   A.4.2.    Server Authentication and Key Exchange Messages          69
-   A.4.3.    Client Authentication and Key Exchange Messages          70
-   A.4.4.    Handshake Finalization Message                           71
-   A.5.      The Cipher Suite                                         71
-   A.6.      The Security Parameters                                  73
-   A.7.      Changes to RFC 4492                                      74
-   B.        Glossary                                                 74
-   C.        Cipher Suite Definitions                                 79
-   D.        Implementation Notes                                     81
-   D.1       Random Number Generation and Seeding                     81
-   D.2       Certificates and Authentication                          81
-   D.3       Cipher Suites                                            81
-   D.4       Implementation Pitfalls                                  81
-   E.        Backward Compatibility                                   84
-   E.1       Compatibility with TLS 1.0/1.1 and SSL 3.0               84
-   E.2       Compatibility with SSL 2.0                               85
-   E.3.      Avoiding Man-in-the-Middle Version Rollback              87
-   F.        Security Analysis                                        88
-   F.1.      Handshake Protocol                                       88
-   F.1.1.    Authentication and Key Exchange                          88
-   F.1.1.1.  Anonymous Key Exchange                                   88
-   F.1.1.2.  RSA Key Exchange and Authentication                      89
-   F.1.1.3.  Diffie-Hellman Key Exchange with Authentication          89
-   F.1.2.    Version Rollback Attacks                                 90
-   F.1.3.    Detecting Attacks Against the Handshake Protocol         91
-   F.1.4.    Resuming Sessions                                        91
-   F.2.      Protecting Application Data                              91
-   F.3.      Explicit IVs                                             92
-   F.4.      Security of Composite Cipher Modes                       92
-   F.5       Denial of Service                                        93
-   F.6       Final Notes                                              93
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 3]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-   -  The connection is private. Symmetric cryptography is used for
-      data encryption (e.g., AES [AES], RC4 [SCH] etc.). The keys for
-      this symmetric encryption are generated uniquely for each
-      connection and are based on a secret negotiated by another
-      protocol (such as the TLS Handshake Protocol). The Record Protocol
-      can also be used without encryption.
-
-   -  The connection is reliable. Message transport includes a message
-      integrity check using a keyed MAC. Secure hash functions (e.g.,
-      SHA-1, etc.) are used for MAC computations. The Record Protocol
-      can operate without a MAC, but is generally only used in this mode
-      while another protocol is using the Record Protocol as a transport
-      for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-   -  The peer's identity can be authenticated using asymmetric, or
-      public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This
-      authentication can be made optional, but is generally required for
-      at least one of the peers.
-
-   -  The negotiation of a shared secret is secure: the negotiated
-      secret is unavailable to eavesdroppers, and for any authenticated
-      connection the secret cannot be obtained, even by an attacker who
-      can place himself in the middle of the connection.
-
-   -  The negotiation is reliable: no attacker can modify the
-      negotiation communication without being detected by the parties to
-      the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS Protocol
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 4]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-   of protocols that run on top of TLS.
-
-1.1. Requirements Terminology
-
-   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 [REQ].
-
-1.2. Major Differences from TLS 1.1
-
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms. The major changes are:
-
-   -  The MD5/SHA-1 combination in the pseudorandom function (PRF) has
-      been replaced with cipher suite specified PRFs. All cipher suites
-      in this document use P_SHA256.
-
-   -  The MD5/SHA-1 combination in the digitally-signed element has been
-      replaced with a single hash. Signed elements now include a field
-      that explicitly specifies the hash algorithm used.
-
-   -  Substantial cleanup to the client's and server's ability to
-      specify which hash and signature algorithms they will accept. Note
-      that this also relaxes some of the constraints on signature and
-      hash algorithms from previous versions of TLS.
-
-   -  Addition of support for authenticated encryption with additional
-      data modes.
-
-   -  TLS Extensions definition and AES Cipher Suites were merged in
-      from external [TLSEXT] and [TLSAES].
-
-   -  Tighter checking of EncryptedPreMasterSecret version numbers.
-
-   -  Tightened up a number of requirements.
-
-   -  Verify_data length now depends on the cipher suite (default is
-      still 12).
-
-   -  Cleaned up description of Bleichenbacher/Klima attack defenses.
-
-   -  Alerts MUST now be sent in many cases.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 5]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   -  After a certificate_request, if no certificates are available,
-      clients now MUST send an empty certificate list.
-
-   -  TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
-      cipher suite.
-
-   -  Added HMAC-SHA256 cipher suites
-
-   -  Removed IDEA and DES cipher suites. They are now deprecated and
-      will be documented in a separate document.
-
-   -  Support for the SSLv2 backward-compatible hello is now a MAY, not
-      a SHOULD, with sending it a SHOULD NOT.  Support will probably
-      become a SHOULD NOT in the future.
-
-   - Added limited "fall-through" to the presentation language to allow
-      multiple case arms to have the same encoding.
-
-   -  Added an Implementation Pitfalls sections
-
-   -  The usual clarifications and editorial work.
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-   1. Cryptographic security: TLS should be used to establish a secure
-      connection between two parties.
-
-   2. Interoperability: Independent programmers should be able to
-      develop applications utilizing TLS that can successfully exchange
-      cryptographic parameters without knowledge of one another's code.
-
-   3. Extensibility: TLS seeks to provide a framework into which new
-      public key and bulk encryption methods can be incorporated as
-      necessary. This will also accomplish two sub-goals: preventing the
-      need to create a new protocol (and risking the introduction of
-      possible new weaknesses) and avoiding the need to implement an
-      entire new security library.
-
-   4. Relative efficiency: Cryptographic operations tend to be highly
-      CPU intensive, particularly public key operations. For this
-      reason, the TLS protocol has incorporated an optional session
-      caching scheme to reduce the number of connections that need to be
-      established from scratch. Additionally, care has been taken to
-      reduce network activity.
-
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 6]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions). This
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups. For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e., 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-      value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-              ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 7]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-      T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-      opaque Datum[3];      /* three uninterpreted bytes */
-      Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream. The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length. A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-      T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two-byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 8]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   17-byte vector of uint16 would be illegal).
-
-      opaque mandatory<300..400>;
-            /* length field is 2 bytes, cannot be empty */
-      uint16 longer<0..800>;
-            /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-      uint8 uint16[2];
-      uint8 uint24[3];
-      uint8 uint32[4];
-      uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors. In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-      enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-      enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-
-
-
-Dierks & Rescorla            Standards Track                    [Page 9]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-      enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-      Color color = Color.blue;     /* overspecified, legal */
-      Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-      enum { low, medium, high } Amount;
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ...
-          Tn fn;
-      } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. Case arms have limited fall-through: if two case arms
-   follow in immediate succession with no fields in between, then they
-   both contain the same fields.  Thus, in the example below, "orange"
-   and "banana" both contain V2. Note that this is a new piece of syntax
-   in TLS 1.2.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 10]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   The body of the variant structure may be given a label for reference.
-   The mechanism by which the variant is selected at runtime is not
-   prescribed by the presentation language.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ....
-          Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               case e3: case e4: Te3;
-               ....
-               case en: Ten;
-           } [[fv]];
-      } [[Tv]];
-
-   For example:
-
-      enum { apple, orange, banana } VariantTag;
-
-      struct {
-          uint16 number;
-          opaque string<0..10>; /* variable length */
-      } V1;
-
-      struct {
-          uint32 number;
-          opaque string[10];    /* fixed length */
-      } V2;
-
-      struct {
-          select (VariantTag) { /* value of selector is implicit */
-              case apple:
-                V1;   /* VariantBody, tag = apple */
-              case orange:
-              case banana:
-                V2;   /* VariantBody, tag = orange or banana */
-          } variant_body;       /* optional label on variant */
-      } VariantRecord;
-
-
-4.7. Cryptographic Attributes
-
-   The five cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption and public key encryption are
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 11]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively. A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   A digitally-signed element is encoded as a struct DigitallySigned:
-
-       struct {
-          SignatureAndHashAlgorithm algorithm;
-          opaque signature<0..2^16-1>;
-       } DigitallySigned;
-
-   The algorithm field specifies the algorithm used (see Section
-   7.4.1.4.1 for the definition of this field.)  Note that the
-   introduction of the algorithm field is a change from previous
-   versions.  The signature is a digital signature using those
-   algorithms over the contents of the element. The contents themselves
-   do not appear on the wire but are simply calculated.  The length of
-   the signature is specified by the signing algorithm and key.
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
-   discussed in [PKCS1], the DigestInfo MUST be DER [X680] [X690]
-   encoded and for hash algorithms without parameters (which include
-   SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field MUST be
-   NULL but implementations MUST accept both without parameters and with
-   NULL parameters. Note that earlier versions of TLS used a different
-   RSA signature scheme which did not include a DigestInfo encoding.
-
-   In DSA, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSA signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-      Dss-Sig-Value ::= SEQUENCE {
-          r INTEGER,
-          s INTEGER
-      }
-
-   Note: In current terminology, DSA refers to the Digital Signature
-   Algorithm and DSS refers to the NIST standard. In the original
-   SSL and TLS specs, "DSS" was used universally. This document
-   uses "DSA" to refer to the algorithm, "DSS" to refer to the
-   standard, and uses "DSS" in the code point definitions for
-   historical continuity.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 12]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected. The input may be of any length and aead-ciphered
-   output is generally larger than the input in order to accomodate the
-   integrity check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the encryption
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1].
-
-   In the following example
-
-      stream-ciphered struct {
-          uint8 field1;
-          uint8 field2;
-          digitally-signed opaque {
-         uint8 field3<0..255>;
-         uint8 field4;
-          };
-      } UserType;
-
-
-   The contents of the inner struct (field3 and field4) are used as
-   input for the signature/hash algorithm, and then the entire structure
-   is encrypted with a stream cipher. The length of this structure, in
-   bytes, would be equal to two bytes for field1 and field2, plus two
-   bytes for the signature and hash algorithm, plus two bytes for the
-   length of the signature, plus the length of the output of the signing
-   algorithm. This is known because the algorithm and key used for the
-   signing are known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 13]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-      struct {
-          uint8 f1;
-          uint8 f2;
-      } Example1;
-
-      Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-
-5. HMAC and the Pseudorandom Function
-
-   The TLS record layer uses a keyed Message Authentication Code (MAC)
-   to protect message integrity. The cipher suites defined in this
-   document use a construction known as HMAC, described in [HMAC], which
-   is based on a hash function. Other cipher suites MAY define their own
-   MAC constructions, if needed.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In this section, we define one PRF, based on HMAC. This PRF with the
-   SHA-256 hash function is used for all cipher suites defined in this
-   document and in TLS documents published prior to this document when
-   TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
-   PRF and in general SHOULD use the TLS PRF with SHA-256 or a stronger
-   standard hash function.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-      P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                             HMAC_hash(secret, A(2) + seed) +
-                             HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-
-      A(0) = seed
-      A(i) = HMAC_hash(secret, A(i-1))
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 14]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA256 is being used to
-   create 80 bytes of data, it will have to be iterated three times
-   (through A(3)), creating 96 bytes of output data; the last 16 bytes
-   of the final iteration will then be discarded, leaving 80 bytes of
-   output data.
-
-   TLS's PRF is created by applying P_hash to the secret as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-      73 6C 69 74 68 79 20 74 6F 76 65 73
-
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-   higher-level clients.
-
-   Four protocols that use the record protocol are described in this
-   document: the handshake protocol, the alert protocol, the change
-   cipher spec protocol, and the application data protocol. In order to
-   allow extension of the TLS protocol, additional record content types
-   can be supported by the record protocol. New record content type
-   values are assigned by IANA in the TLS Content Type Registry as
-   described in Section 12.
-
-   Implementations MUST NOT send record types not defined in this
-   document unless negotiated by some extension.  If a TLS
-   implementation receives an unexpected record type, it MUST send an
-   unexpected_message alert.
-
-   Any protocol designed for use over TLS must be carefully designed to
-   deal with all possible attacks against it. As a practical matter,
-   this means that the protocol designer must be aware of what security
-   properties TLS does and does not provide and cannot safely rely on
-   the latter.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 15]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   Note in particular that type and length of a record are not protected
-   by encryption. If this information is itself sensitive, application
-   designers may wish to take steps (padding, cover traffic) to minimize
-   information leakage.
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, an encryption
-   algorithm, and a MAC algorithm. In addition, the parameters for these
-   algorithms are known: the MAC key and the bulk encryption keys for
-   the connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the ChangeCipherSpec can selectively make either of the
-   pending states current, in which case the appropriate current state
-   is disposed of and replaced with the pending state; the pending state
-   is then reinitialized to an empty state. It is illegal to make a
-   state that has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-      Whether this entity is considered the "client" or the "server" in
-      this connection.
-
-   PRF algorithm
-      An algorithm used to generate keys from the master secret (see
-      Sections 5 and 6.3).
-
-   bulk encryption algorithm
-      An algorithm to be used for bulk encryption. This specification
-      includes the key size of this algorithm, whether it is a block,
-      stream, or AEAD cipher, the block size of the cipher (if
-      appropriate), and the lengths of explicit and implicit
-      initialization vectors (or nonces).
-
-   MAC algorithm
-      An algorithm to be used for message authentication. This
-      specification includes the size of the value returned by the MAC
-      algorithm.
-
-   compression algorithm
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 16]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      An algorithm to be used for data compression. This specification
-      must include all information the algorithm requires to do
-      compression.
-
-   master secret
-      A 48-byte secret shared between the two peers in the connection.
-
-   client random
-      A 32-byte value provided by the client.
-
-   server random
-      A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-      enum { server, client } ConnectionEnd;
-
-      enum { tls_prf_sha256 } PRFAlgorithm;
-
-      enum { null, rc4, 3des, aes }
-        BulkCipherAlgorithm;
-
-      enum { stream, block, aead } CipherType;
-
-      enum { null, hmac_md5, hmac_sha1, hmac_sha256,
-           hmac_sha384, hmac_sha512} MACAlgorithm;
-
-      enum { null(0), (255) } CompressionMethod;
-
-      /* The algorithms specified in CompressionMethod, PRFAlgorithm
-         BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-      struct {
-          ConnectionEnd          entity;
-          PRFAlgorithm           prf_algorithm;
-          BulkCipherAlgorithm    bulk_cipher_algorithm;
-          CipherType             cipher_type;
-          uint8                  enc_key_length;
-          uint8                  block_length;
-          uint8                  fixed_iv_length;
-          uint8                  record_iv_length;
-          MACAlgorithm           mac_algorithm;
-          uint8                  mac_length;
-          uint8                  mac_key_length;
-          CompressionMethod      compression_algorithm;
-          opaque                 master_secret[48];
-          opaque                 client_random[32];
-          opaque                 server_random[32];
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 17]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following six items (some of which are not required by all ciphers,
-   and are thus empty):
-
-      client write MAC key
-      server write MAC key
-      client write encryption key
-      server write encryption key
-      client write IV
-      server write IV
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states MUST be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-      The current state of the compression algorithm.
-
-   cipher state
-      The current state of the encryption algorithm. This will consist
-      of the scheduled key for that connection. For stream ciphers, this
-      will also contain whatever state information is necessary to allow
-      the stream to continue to encrypt or decrypt data.
-
-   MAC key
-      The MAC key for this connection, as generated above.
-
-   sequence number
-      Each connection state contains a sequence number, which is
-      maintained separately for read and write states. The sequence
-      number MUST be set to zero whenever a connection state is made the
-      active state. Sequence numbers are of type uint64 and may not
-      exceed 2^64-1. Sequence numbers do not wrap. If a TLS
-      implementation would need to wrap a sequence number, it must
-      renegotiate instead. A sequence number is incremented after each
-      record: specifically, the first record transmitted under a
-      particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 18]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType MAY be coalesced into a
-   single TLSPlaintext record, or a single message MAY be fragmented
-   across several records).
-
-      struct {
-          uint8 major;
-          uint8 minor;
-      } ProtocolVersion;
-
-      enum {
-          change_cipher_spec(20), alert(21), handshake(22),
-          application_data(23), (255)
-      } ContentType;
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          opaque fragment[TLSPlaintext.length];
-      } TLSPlaintext;
-
-   type
-      The higher-level protocol used to process the enclosed fragment.
-
-   version
-      The version of the protocol being employed. This document
-      describes TLS Version 1.2, which uses the version { 3, 3 }. The
-      version value 3.3 is historical, deriving from the use of {3, 1}
-      for TLS 1.0. (See Appendix A.1).  Note that a client that supports
-      multiple versions of TLS may not know what version will be
-      employed before it receives the ServerHello.  See Appendix E for
-      discussion about what record layer version number should be
-      employed for ClientHello.
-
-   length
-      The length (in bytes) of the following TLSPlaintext.fragment.  The
-      length MUST NOT exceed 2^14.
-
-   fragment
-      The application data. This data is transparent and treated as an
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 19]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      independent block to be dealt with by the higher-level protocol
-      specified by the type field.
-
-   Implementations MUST NOT send zero-length fragments of Handshake,
-   Alert, or ChangeCipherSpec content types. Zero-length fragments of
-   Application data MAY be sent as they are potentially useful as a
-   traffic analysis countermeasure.
-
-   Note: Data of different TLS Record layer content types MAY be
-   interleaved.  Application data is generally of lower precedence for
-   transmission than other content types.  However, records MUST be
-   delivered to the network in the same order as they are protected by
-   the record layer.  Recipients MUST receive and process interleaved
-   application layer traffic during handshakes subsequent to the first
-   one on a connection.
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active. [RFC3749] describes compression
-   algorithms for TLS.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-      struct {
-          ContentType type;       /* same as TLSPlaintext.type */
-          ProtocolVersion version;/* same as TLSPlaintext.version */
-          uint16 length;
-          opaque fragment[TLSCompressed.length];
-      } TLSCompressed;
-
-   length
-      The length (in bytes) of the following TLSCompressed.fragment.
-      The length MUST NOT exceed 2^14 + 1024.
-
-   fragment
-      The compressed form of TLSPlaintext.fragment.
-
-   Note: A CompressionMethod.null operation is an identity operation; no
-   fields are altered.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 20]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   Implementation note: Decompression functions are responsible for
-   ensuring that messages cannot cause internal buffer overflows.
-
-6.2.3. Record Payload Protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          select (SecurityParameters.cipher_type) {
-              case stream: GenericStreamCipher;
-              case block:  GenericBlockCipher;
-              case aead:   GenericAEADCipher;
-          } fragment;
-      } TLSCiphertext;
-
-   type
-      The type field is identical to TLSCompressed.type.
-
-   version
-      The version field is identical to TLSCompressed.version.
-
-   length
-      The length (in bytes) of the following TLSCiphertext.fragment.
-      The length MUST NOT exceed 2^14 + 2048.
-
-   fragment
-      The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-      stream-ciphered struct {
-          opaque content[TLSCompressed.length];
-          opaque MAC[SecurityParameters.mac_length];
-      } GenericStreamCipher;
-
-   The MAC is generated as:
-
-      MAC(MAC_write_key, seq_num +
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 21]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-                            TLSCompressed.type +
-                            TLSCompressed.version +
-                            TLSCompressed.length +
-                            TLSCompressed.fragment);
-
-   where "+" denotes concatenation.
-
-   seq_num
-      The sequence number for this record.
-
-   MAC
-      The MAC algorithm specified by SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted,
-   and the MAC size is zero, implying that no MAC is used).  For both
-   null and stream ciphers, TLSCiphertext.length is TLSCompressed.length
-   plus SecurityParameters.mac_length.
-
-6.2.3.2. CBC Block Cipher
-
-   For block ciphers (such as 3DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-      struct {
-          opaque IV[SecurityParameters.record_iv_length];
-          block-ciphered struct {
-              opaque content[TLSCompressed.length];
-              opaque MAC[SecurityParameters.mac_length];
-              uint8 padding[GenericBlockCipher.padding_length];
-              uint8 padding_length;
-          };
-      } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-      The Initialization Vector (IV) SHOULD be chosen at random, and
-      MUST be unpredictable. Note that in versions of TLS prior to 1.1,
-      there was no IV field, and the last ciphertext block of the
-      previous record (the "CBC residue") was used as the IV. This was
-      changed to prevent the attacks described in [CBCATT]. For block
-      ciphers, the IV length is of length
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 22]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      SecurityParameters.record_iv_length which is equal to the
-      SecurityParameters.block_size.
-
-   padding
-      Padding that is added to force the length of the plaintext to be
-      an integral multiple of the block cipher's block length. The
-      padding MAY be any length up to 255 bytes, as long as it results
-      in the TLSCiphertext.length being an integral multiple of the
-      block length. Lengths longer than necessary might be desirable to
-      frustrate attacks on a protocol that are based on analysis of the
-      lengths of exchanged messages. Each uint8 in the padding data
-      vector MUST be filled with the padding length value. The receiver
-      MUST check this padding and MUST use the bad_record_mac alert to
-      indicate padding errors.
-
-   padding_length
-      The padding length MUST be such that the total size of the
-      GenericBlockCipher structure is a multiple of the cipher's block
-      length. Legal values range from zero to 255, inclusive. This
-      length specifies the length of the padding field exclusive of the
-      padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of SecurityParameters.block_length, TLSCompressed.length,
-   SecurityParameters.mac_length, and padding_length.
-
-   Example: If the block length is 8 bytes, the content length
-   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
-   then the length before padding is 82 bytes (this does not include the
-   IV. Thus, the padding length modulo 8 must be equal to 6 in order to
-   make the total length an even multiple of 8 bytes (the block length).
-   The padding length can be 6, 14, 22, and so on, through 254. If the
-   padding length were the minimum necessary, 6, the padding would be 6
-   bytes, each containing the value 6.  Thus, the last 8 octets of the
-   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
-   06 06, where xx is the last octet of the MAC.
-
-   Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
-   critical that the entire plaintext of the record be known before any
-   ciphertext is transmitted. Otherwise, it is possible for the attacker
-   to mount the attack described in [CBCATT].
-
-   Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
-   timing attack on CBC padding based on the time required to compute
-   the MAC. In order to defend against this attack, implementations MUST
-   ensure that record processing time is essentially the same whether or
-   not the padding is correct.  In general, the best way to do this is
-   to compute the MAC even if the padding is incorrect, and only then
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 23]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   reject the packet. For instance, if the pad appears to be incorrect,
-   the implementation might assume a zero-length pad and then compute
-   the MAC. This leaves a small timing channel, since MAC performance
-   depends to some extent on the size of the data fragment, but it is
-   not believed to be large enough to be exploitable, due to the large
-   block size of existing MACs and the small size of the timing signal.
-
-6.2.3.3. AEAD ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-      struct {
-         opaque nonce_explicit[SecurityParameters.record_iv_length];
-         aead-ciphered struct {
-             opaque content[TLSCompressed.length];
-         };
-      } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD]. The key is either the
-   client_write_key or the server_write_key.  No MAC key is used.
-
-   Each AEAD cipher suite MUST specify how the nonce supplied to the
-   AEAD operation is constructed, and what is the length of the
-   GenericAEADCipher.nonce_explicit part. In many cases, it is
-   appropriate to use the partially implicit nonce technique described
-   in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
-   the explicit part. In this case, the implicit part SHOULD be derived
-   from key_block as client_write_iv and server_write_iv (as described
-   in Section 6.3), and the explicit part is included in
-   GenericAEAEDCipher.nonce_explicit.
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   Where "+" denotes concatenation.
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  The length will generally be larger than
-   TLSCompressed.length, but by an amount that varies with the AEAD
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 24]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-      AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext,
-                                   additional_data)
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   nonce, the "additional_data", and the AEADEncrypted value. The output
-   is either the plaintext or an error indicating that the decryption
-   failed. There is no separate integrity check.  I.e.,
-
-      TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
-                                            AEADEncrypted,
-                                            additional_data)
-
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generate keys required
-   by the current connection state (see Appendix A.6) from the security
-   parameters provided by the handshake protocol.
-
-   The master secret is expanded into a sequence of secure bytes, which
-   is then split to a client write MAC key, a server write MAC key, a
-   client write encryption key, and a server write encryption key. Each
-   of these is generated from the byte sequence in that order.  Unused
-   values are empty.  Some AEAD ciphers may additionally require a
-   client write IV and a server write IV (see Section 6.2.3.3).
-
-   When keys and MAC keys are generated, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-      key_block = PRF(SecurityParameters.master_secret,
-                      "key expansion",
-                      SecurityParameters.server_random +
-                      SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-      client_write_MAC_key[SecurityParameters.mac_key_length]
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 25]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      server_write_MAC_key[SecurityParameters.mac_key_length]
-      client_write_key[SecurityParameters.enc_key_length]
-      server_write_key[SecurityParameters.enc_key_length]
-      client_write_IV[SecurityParameters.fixed_iv_length]
-      server_write_IV[SecurityParameters.fixed_iv_length]
-
-   Currently, the client_write_IV and server_write_IV are only generated
-   for implicit nonce techniques as described in Section 3.2.1 of
-   [AEAD].
-
-   Implementation note: The currently defined cipher suite which
-   requires the most material is AES_256_CBC_SHA256. It requires 2 x 32
-   byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key
-   material.
-
-7. The TLS Handshaking Protocols
-
-   TLS has three subprotocols that are used to allow peers to agree upon
-   security parameters for the record layer, to authenticate themselves,
-   to instantiate negotiated security parameters, and to report error
-   conditions to each other.
-
-   The Handshake Protocol is responsible for negotiating a session,
-   which consists of the following items:
-
-   session identifier
-      An arbitrary byte sequence chosen by the server to identify an
-      active or resumable session state.
-
-   peer certificate
-      X509v3 [PKIX] certificate of the peer. This element of the state
-      may be null.
-
-   compression method
-      The algorithm used to compress data prior to encryption.
-
-   cipher spec
-      Specifies the pseudorandom function (PRF) used to generate keying
-      material, the bulk data encryption algorithm (such as null, AES,
-      etc.) and a MAC algorithm (such as HMAC-SHA1). It also defines
-      cryptographic attributes such as the mac_length. (See Appendix A.6
-      for formal definition.)
-
-   master secret
-      48-byte secret shared between the client and server.
-
-   is resumable
-      A flag indicating whether the session can be used to initiate new
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 26]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-      struct {
-          enum { change_cipher_spec(1), (255) } type;
-      } ChangeCipherSpec;
-
-   The ChangeCipherSpec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.) The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent.
-
-   Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec. However, once the ChangeCipherSpec has been sent, the new
-   CipherSpec MUST be used. The first side to send the ChangeCipherSpec
-   does not know that the other side has finished computing the new
-   keying material (e.g., if it has to perform a time consuming public
-   key operation). Thus, a small window of time, during which the
-   recipient must buffer the data, MAY exist. In practice, with modern
-   machines this interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message
-   (warning or fatal) and a description of the alert. Alert messages
-   with a level of fatal result in the immediate termination of the
-   connection. In this case, other connections corresponding to the
-   session may continue, but the session identifier MUST be invalidated,
-   preventing the failed session from being used to establish new
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 27]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   connections. Like other messages, alert messages are encrypted and
-   compressed, as specified by the current connection state.
-
-      enum { warning(1), fatal(2), (255) } AlertLevel;
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed_RESERVED(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          no_certificate_RESERVED(41),
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-          export_restriction_RESERVED(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-          no_renegotiation(100),
-          unsupported_extension(110),
-          (255)
-      } AlertDescription;
-
-      struct {
-          AlertLevel level;
-          AlertDescription description;
-      } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. Note that as of TLS 1.1,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 28]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-       failure to properly close a connection no longer requires that a
-       session not be resumed. This is a change from TLS 1.0 to conform
-       with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection. The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes. It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-   pending data before destroying the transport.
-
-7.2.2. Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection. Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection. Thus, any connection terminated with a fatal alert
-   MUST NOT be resumed.
-
-   Whenever an implementation encounters a condition which is defined as
-   a fatal alert, it MUST send the appropriate alert prior to closing
-   the connection. For all errors where an alert level is not explicitly
-   specified, the sending party MAY determine at its discretion whether
-   to treat this as a fatal error or not. If the implementation chooses
-   to send an alert but intends to close the connection immediately
-   afterwards, it MUST send that alert at the fatal alert level.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 29]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   If an alert with a level of warning is sent and received, generally
-   the connection can continue normally.  If the receiving party decides
-   not to proceed with the connection (e.g., after having received a
-   no_renegotiation alert that it is not willing to accept), it SHOULD
-   send a fatal alert to terminate the connection. Given this, the
-   sending party cannot, in general, know how the receiving party will
-   behave. Therefore, warning alerts are not very useful when the
-   sending party wants to continue the connection, and thus are
-   sometimes omitted. For example, if a peer decides to accept an
-   expired certificate (perhaps after confirming this with the user) and
-   wants to continue the connection, it would not generally send a
-   certificate_expired alert.
-
-   The following error alerts are defined:
-
-   unexpected_message
-      An inappropriate message was received. This alert is always fatal
-      and should never be observed in communication between proper
-      implementations.
-
-   bad_record_mac
-      This alert is returned if a record is received with an incorrect
-      MAC. This alert also MUST be returned if an alert is sent because
-      a TLSCiphertext decrypted in an invalid way: either it wasn't an
-      even multiple of the block length, or its padding values, when
-      checked, weren't correct. This message is always fatal and should
-      never be observed in communication between proper implementations
-      (except when messages were corrupted in the network).
-
-   decryption_failed_RESERVED
-      This alert was used in some earlier versions of TLS, and may have
-      permitted certain attacks against the CBC mode [CBCATT].  It MUST
-      NOT be sent by compliant implementations.
-
-   record_overflow
-      A TLSCiphertext record was received that had a length more than
-      2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-      with more than 2^14+1024 bytes. This message is always fatal and
-      should never be observed in communication between proper
-      implementations (except when messages were corrupted in the
-      network).
-
-   decompression_failure
-      The decompression function received improper input (e.g., data
-      that would expand to excessive length). This message is always
-      fatal and should never be observed in communication between proper
-      implementations.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 30]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   handshake_failure
-      Reception of a handshake_failure alert message indicates that the
-      sender was unable to negotiate an acceptable set of security
-      parameters given the options available. This is a fatal error.
-
-   no_certificate_RESERVED
-      This alert was used in SSLv3 but not any version of TLS.  It MUST
-      NOT be sent by compliant implementations.
-
-   bad_certificate
-      A certificate was corrupt, contained signatures that did not
-      verify correctly, etc.
-
-   unsupported_certificate
-      A certificate was of an unsupported type.
-
-   certificate_revoked
-      A certificate was revoked by its signer.
-
-   certificate_expired
-      A certificate has expired or is not currently valid.
-
-   certificate_unknown
-      Some other (unspecified) issue arose in processing the
-      certificate, rendering it unacceptable.
-
-   illegal_parameter
-      A field in the handshake was out of range or inconsistent with
-      other fields. This message is always fatal.
-
-   unknown_ca
-      A valid certificate chain or partial chain was received, but the
-      certificate was not accepted because the CA certificate could not
-      be located or couldn't be matched with a known, trusted CA.  This
-      message is always fatal.
-
-   access_denied
-      A valid certificate was received, but when access control was
-      applied, the sender decided not to proceed with negotiation.  This
-      message is always fatal.
-
-   decode_error
-      A message could not be decoded because some field was out of the
-      specified range or the length of the message was incorrect. This
-      message is always fatal and should never be observed in
-      communication between proper implementations (except when messages
-      were corrupted in the network).
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 31]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   decrypt_error
-      A handshake cryptographic operation failed, including being unable
-      to correctly verify a signature or validate a finished message.
-      This message is always fatal.
-
-   export_restriction_RESERVED
-      This alert was used in some earlier versions of TLS.  It MUST NOT
-      be sent by compliant implementations.
-
-   protocol_version
-      The protocol version the client has attempted to negotiate is
-      recognized but not supported. (For example, old protocol versions
-      might be avoided for security reasons). This message is always
-      fatal.
-
-   insufficient_security
-      Returned instead of handshake_failure when a negotiation has
-      failed specifically because the server requires ciphers more
-      secure than those supported by the client. This message is always
-      fatal.
-
-   internal_error
-      An internal error unrelated to the peer or the correctness of the
-      protocol (such as a memory allocation failure) makes it impossible
-      to continue. This message is always fatal.
-
-   user_canceled
-      This handshake is being canceled for some reason unrelated to a
-      protocol failure. If the user cancels an operation after the
-      handshake is complete, just closing the connection by sending a
-      close_notify is more appropriate. This alert should be followed by
-      a close_notify. This message is generally a warning.
-
-   no_renegotiation
-      Sent by the client in response to a hello request or by the server
-      in response to a client hello after initial handshaking.  Either
-      of these would normally lead to renegotiation; when that is not
-      appropriate, the recipient should respond with this alert.  At
-      that point, the original requester can decide whether to proceed
-      with the connection. One case where this would be appropriate is
-      where a server has spawned a process to satisfy a request; the
-      process might receive security parameters (key length,
-      authentication, etc.) at startup and it might be difficult to
-      communicate changes to these parameters after that point. This
-      message is always a warning.
-
-   unsupported_extension
-      sent by clients that receive an extended server hello containing
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 32]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      an extension that they did not put in the corresponding client
-      hello. This message is always fatal.
-
-   New Alert values are assigned by IANA as described in Section 12.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-   -  Exchange hello messages to agree on algorithms, exchange random
-      values, and check for session resumption.
-
-   -  Exchange the necessary cryptographic parameters to allow the
-      client and server to agree on a premaster secret.
-
-   -  Exchange certificates and cryptographic information to allow the
-      client and server to authenticate themselves.
-
-   -  Generate a master secret from the premaster secret and exchanged
-      random values.
-
-   -  Provide security parameters to the record layer.
-
-   -  Allow the client and server to verify that their peer has
-      calculated the same security parameters and that the handshake
-      occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man in the middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support. The protocol has been designed to
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection. The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require. The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 33]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   Certificate, the ServerKeyExchange, the client Certificate, and the
-   ClientKeyExchange. New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 46 bytes upwards.
-
-   Following the hello messages, the server will send its certificate in
-   a Certificate message if it is to be authenticated. Additionally, a
-   ServerKeyExchange message may be sent, if it is required (e.g., if
-   the server has no certificate, or if its certificate is for signing
-   only). If the server is authenticated, it may request a certificate
-   from the client, if that is appropriate to the cipher suite selected.
-   Next, the server will send the ServerHelloDone message, indicating
-   that the hello-message phase of the handshake is complete. The server
-   will then wait for a client response. If the server has sent a
-   CertificateRequest message, the client MUST send the Certificate
-   message. The ClientKeyExchange message is now sent, and the content
-   of that message will depend on the public key algorithm selected
-   between the client hello and the server hello. If the client has sent
-   a certificate with signing ability, a digitally-signed
-   CertificateVerify message is sent to explicitly verify possession of
-   the private key in the certificate.
-
-   At this point, a ChangeCipherSpec message is sent by the client, and
-   the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the Finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own ChangeCipherSpec message, transfer the pending to the
-   current Cipher Spec, and send its Finished message under the new
-   Cipher Spec. At this point, the handshake is complete, and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.) Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other than
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 34]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   TLS_NULL_WITH_NULL_NULL is established).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 35]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-   Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-   independent TLS Protocol content type, and is not actually a TLS
-   handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server MUST send ChangeCipherSpec messages and proceed
-   directly to Finished messages. Once the re-establishment is complete,
-   the client and server MAY begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 36]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-          } body;
-      } Handshake;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 37]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message that is not bound by these ordering rules is the HelloRequest
-   message, which can be sent at any time, but which SHOULD be ignored
-   by the client if it arrives in the middle of a handshake.
-
-   New Handshake message types are assigned by IANA as described in
-   Section 12.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello Request
-
-   When this message will be sent:
-
-      The HelloRequest message MAY be sent by the server at any time.
-
-   Meaning of this message:
-
-      HelloRequest is a simple notification that the client should begin
-      the negotiation process anew. In response, the client should a
-      ClientHello message when convenient. This message is not intended
-      to establish which side is the client or server but merely to
-      initiate a new negotiation. Servers SHOULD NOT send a HelloRequest
-      immediately upon the client's initial connection.  It is the
-      client's job to send a ClientHello at that time.
-
-      This message will be ignored by the client if the client is
-      currently negotiating a session. This message MAY be ignored by
-      the client if it does not wish to renegotiate a session, or the
-      client may, if it wishes, respond with a no_renegotiation alert.
-      Since handshake messages are intended to have transmission
-      precedence over application data, it is expected that the
-      negotiation will begin before no more than a few records are
-      received from the client. If the server sends a HelloRequest but
-      does not receive a ClientHello in response, it may close the
-      connection with a fatal alert.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 38]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      After sending a HelloRequest, servers SHOULD NOT repeat the
-      request until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-
-      struct { } HelloRequest;
-
-   This message MUST NOT be included in the message hashes that are
-   maintained throughout the handshake and used in the finished messages
-   and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-
-      When a client first connects to a server it is required to send
-      the ClientHello as its first message. The client can also send a
-      ClientHello in response to a HelloRequest or on its own initiative
-      in order to renegotiate the security parameters in an existing
-      connection.
-
-   Structure of this message:
-
-      The ClientHello message includes a random structure, which is used
-      later in the protocol.
-
-         struct {
-             uint32 gmt_unix_time;
-             opaque random_bytes[28];
-         } Random;
-
-      gmt_unix_time
-         The current time and date in standard UNIX 32-bit format
-         (seconds since the midnight starting Jan 1, 1970, UTC, ignoring
-         leap seconds) according to the sender's internal clock. Clocks
-         are not required to be set correctly by the basic TLS Protocol;
-         higher-level or application protocols may define additional
-         requirements.  Note that, for historical reasons, the data
-         element is named using GMT, the predecessor of the current
-         worldwide time base, UTC.
-
-      random_bytes
-         28 bytes generated by a secure random number generator.
-
-   The ClientHello message includes a variable-length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier MAY be from an earlier connection, this
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 39]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   connection, or from another currently active connection. The second
-   option is useful if the client only wishes to update the random
-   structures and derived values of a connection, and the third option
-   makes it possible to establish several independent secure connections
-   without repeating the full handshake protocol. These independent
-   connections may occur sequentially or simultaneously; a SessionID
-   becomes valid when the handshake negotiating it completes with the
-   exchange of Finished messages and persists until it is removed due to
-   aging or because a fatal error was encountered on a connection
-   associated with the session. The actual contents of the SessionID are
-   defined by the server.
-
-      opaque SessionID<0..32>;
-
-   Warning: Because the SessionID is transmitted without encryption or
-   immediate MAC protection, servers MUST NOT place confidential
-   information in session identifiers or let the contents of fake
-   session identifiers cause any breach of security. (Note that the
-   content of the handshake as a whole, including the SessionID, is
-   protected by the Finished messages exchanged at the end of the
-   handshake.)
-
-   The cipher suite list, passed from the client to the server in the
-   ClientHello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each cipher suite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.  If the list contains cipher
-   suites the server does not recognize, support, or wish to use, the
-   server MUST ignore those cipher suites, and process the remaining
-   ones as usual.
-
-      uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The ClientHello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-      enum { null(0), (255) } CompressionMethod;
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-2>;
-          CompressionMethod compression_methods<1..2^8-1>;
-          select (extensions_present) {
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 40]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ClientHello;
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block. The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello. Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field but is used for compatibility with TLS before
-   extensions were defined.
-
-   client_version
-      The version of the TLS protocol by which the client wishes to
-      communicate during this session. This SHOULD be the latest
-      (highest valued) version supported by the client. For this version
-      of the specification, the version will be 3.3 (See Appendix E for
-      details about backward compatibility).
-
-   random
-      A client-generated random structure.
-
-   session_id
-      The ID of a session the client wishes to use for this connection.
-      This field is empty if no session_id is available, or if the
-      client wishes to generate new security parameters.
-
-   cipher_suites
-      This is a list of the cryptographic options supported by the
-      client, with the client's first preference first. If the
-      session_id field is not empty (implying a session resumption
-      request), this vector MUST include at least the cipher_suite from
-      that session. Values are defined in Appendix A.5.
-
-   compression_methods
-      This is a list of the compression methods supported by the client,
-      sorted by client preference. If the session_id field is not empty
-      (implying a session resumption request), it MUST include the
-      compression_method from that session. This vector MUST contain,
-      and all implementations MUST support, CompressionMethod.null.
-      Thus, a client and server will always be able to agree on a
-      compression method.
-
-   extensions
-      Clients MAY request extended functionality from servers by sending
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 41]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      data in the extensions field.  The actual "Extension" format is
-      defined in Section 7.4.1.4.
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-   client MAY abort the handshake.  A server MUST accept client hello
-   messages both with and without the extensions field, and (as for all
-   other messages) MUST check that the amount of data in the message
-   precisely matches one of these formats; if not, then it MUST send a
-   fatal "decode_error" alert.
-
-   After sending the client hello message, the client waits for a
-   ServerHello message. Any other handshake message returned by the
-   server except for a HelloRequest is treated as a fatal error.
-
-7.4.1.3. Server Hello
-
-   When this message will be sent:
-
-      The server will send this message in response to a ClientHello
-      message when it was able to find an acceptable set of algorithms.
-      If it cannot find such a match, it will respond with a handshake
-      failure alert.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          select (extensions_present) {
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ServerHello;
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-   server_version
-      This field will contain the lower of that suggested by the client
-      in the client hello and the highest supported by the server. For
-      this version of the specification, the version is 3.3.  (See
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 42]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      Appendix E for details about backward compatibility.)
-
-   random
-      This structure is generated by the server and MUST be
-      independently generated from the ClientHello.random.
-
-   session_id
-      This is the identity of the session corresponding to this
-      connection. If the ClientHello.session_id was non-empty, the
-      server will look in its session cache for a match. If a match is
-      found and the server is willing to establish the new connection
-      using the specified session state, the server will respond with
-      the same value as was supplied by the client. This indicates a
-      resumed session and dictates that the parties must proceed
-      directly to the finished messages. Otherwise this field will
-      contain a different value identifying the new session. The server
-      may return an empty session_id to indicate that the session will
-      not be cached and therefore cannot be resumed. If a session is
-      resumed, it must be resumed using the same cipher suite it was
-      originally negotiated with. Note that there is no requirement that
-      the server resume any session even if it had formerly provided a
-      session_id. Clients MUST be prepared to do a full negotiation --
-      including negotiating new cipher suites -- during any handshake.
-
-   cipher_suite
-      The single cipher suite selected by the server from the list in
-      ClientHello.cipher_suites. For resumed sessions, this field is the
-      value from the state of the session being resumed.
-
-   compression_method
-      The single compression algorithm selected by the server from the
-      list in ClientHello.compression_methods. For resumed sessions this
-      field is the value from the resumed session state.
-
-   extensions
-      A list of extensions. Note that only extensions offered by the
-      client can appear in the server's list.
-
-7.4.1.4 Hello Extensions
-
-   The extension format is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-      enum {
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 43]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-          signature_algorithms(TBD-BY-IANA), (65535)
-      } ExtensionType;
-
-   Here:
-
-   -  "extension_type" identifies the particular extension type.
-
-   -  "extension_data" contains information specific to the particular
-      extension type.
-
-   The initial set of extensions is defined in a companion document
-   [TLSEXT]. The list of extension types is maintained by IANA as
-   described in Section 12.
-
-   There are subtle (and not so subtle) interactions that may occur in
-   this protocol between new features and existing features which may
-   result in a significant reduction in overall security. The following
-   considerations should be taken into account when designing new
-   extensions:
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some simply a refusal to support a particular
-      feature.  In general error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should as far as possible be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase. Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS - particularly since
-      the TLS handshake algorithms have specific protection against
-      version rollback attacks based on the version number, and the
-      possibility of version rollback should be a significant
-      consideration in any major design change.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 44]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-7.4.1.4.1 Signature Algorithms
-
-   The client uses the "signature_algorithms" extension to indicate to
-   the server which signature/hash algorithm pairs may be used in
-   digital signatures. The "extension_data" field of this extension
-   contains a "supported_signature_algorithms" value.
-
-      enum {
-          none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
-          sha512(6), (255)
-      } HashAlgorithm;
-
-      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
-        SignatureAlgorithm;
-
-      struct {
-            HashAlgorithm hash;
-            SignatureAlgorithm signature;
-      } SignatureAndHashAlgorithm;
-
-      SignatureAndHashAlgorithm
-        supported_signature_algorithms<2..2^16-2>;
-
-   Each SignatureAndHashAlgorithm value lists a single hash/signature
-   pair which the client is willing to verify. The values are indicated
-   in descending order of preference.
-
-   Note: Because not all signature algorithms and hash algorithms may be
-   accepted by an implementation (e.g., DSA with SHA-1, but not
-   SHA-256), algorithms here are listed in pairs.
-
-   hash
-      This field indicates the hash algorithm which may be used. The
-      values indicate support for unhashed data, MD5 [MD5], SHA-1,
-      SHA-224, SHA-256, SHA-384, and SHA-512 [SHS] respectively. The
-      "none" value is provided for future extensibility, in case of a
-      signature algorithm which does not require hashing before signing.
-
-   signature
-      This field indicates the signature algorithm which may be used.
-      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
-      [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The
-      "anonymous" value is meaningless in this context but used in
-      Section 7.4.3. It MUST NOT appear in this extension.
-
-   The semantics of this extension are somewhat complicated because the
-   cipher suite indicates permissible signature algorithms but not hash
-   algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 45]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   If the client supports only the default hash and signature algorithms
-   (listed in this section), it MAY omit the signature_algorithms
-   extension. If the client does not support the default algorithms, or
-   supports other hash and signature algorithms (and it is willing to
-   use them for verifying messages sent by the server, i.e., server
-   certificates and server key exchange), it MUST send the
-   signature_algorithms extension, listing the algorithms it is willing
-   to accept.
-
-   If the client does not send the signature_algorithms extension, the
-   server MUST assume the following:
-
-   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
-   DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
-   the value {sha1,rsa}.
-
-   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
-   DH_DSS), behave as if the client had sent the value {sha1,dsa}.
-
-   -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
-   ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
-
-   Note: this is a change from TLS 1.1 where there are no explicit rules
-   but as a practical matter one can assume that the peer supports MD5
-   and SHA-1.
-
-   Note: this extension is not meaningful for TLS versions prior to 1.2.
-   Clients MUST NOT offer it if they are offering prior versions.
-   However, even if clients do offer it, the rules specified in [TLSEXT]
-   require servers to ignore extensions they do not understand.
-
-   Servers MUST NOT send this extension. TLS servers MUST support
-   receiving this extension.
-
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-
-      The server MUST send a Certificate message whenever the agreed-
-      upon key exchange method uses certificates for authentication
-      (this includes all key exchange methods defined in this document
-      except DH_anon).  This message will always immediately follow the
-      server hello message.
-
-   Meaning of this message:
-
-      This message conveys the server's certificate chain to the client.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 46]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      The certificate MUST be appropriate for the negotiated cipher
-      suite's key exchange algorithm, and any negotiated extensions.
-
-   Structure of this message:
-
-      opaque ASN.1Cert<1..2^24-1>;
-
-      struct {
-          ASN.1Cert certificate_list<0..2^24-1>;
-      } Certificate;
-
-   certificate_list
-      This is a sequence (chain) of certificates. The sender's
-      certificate MUST come first in the list. Each following
-      certificate MUST directly certify the one preceding it. Because
-      certificate validation requires that root keys be distributed
-      independently, the self-signed certificate that specifies the root
-      certificate authority MAY be omitted from the chain, under the
-      assumption that the remote end must already possess it in order to
-      validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
-   Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-   vector because PKCS #6 [PKCS6] extended certificates are not used.
-   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
-   of parsing the list more difficult.
-
-   The following rules apply to the certificates sent by the server:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g., [TLSPGP]).
-
-   -  The end entity certificate's public key (and associated
-      restrictions) MUST be compatible with the selected key exchange
-      algorithm.
-
-      Key Exchange Alg.  Certificate Key Type
-
-      RSA                RSA public key; the certificate MUST
-      RSA_PSK            allow the key to be used for encryption
-                         (the keyEncipherment bit MUST be set
-                         if the key usage extension is present).
-                         Note: RSA_PSK is defined in [TLSPSK].
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 47]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      DHE_RSA            RSA public key; the certificate MUST
-      ECDHE_RSA          allow the key to be used for signing
-                         (the digitalSignature bit MUST be set
-                         if the key usage extension is present)
-                         with the signature scheme and hash
-                         algorithm that will be employed in the
-                         server key exchange message.
-                   Note: ECDHE_RSA is defined in [TLSECC].
-
-      DHE_DSS            DSA public key; the certificate MUST
-                         allow the key to be used for signing with
-                         the hash algorithm that will be employed
-                         in the server key exchange message.
-
-      DH_DSS             Diffie-Hellman public key; the
-      DH_RSA             keyAgreement bit MUST be set if the
-                         key usage extension is present.
-
-      ECDH_ECDSA         ECDH-capable public key; the public key
-      ECDH_RSA           MUST use a curve and point format supported
-                         by the client, as described in [TLSECC].
-
-      ECDHE_ECDSA        ECDSA-capable public key; the certificate
-                         MUST allow the key to be used for signing
-                         with the hash algorithm that will be
-                         employed in the server key exchange
-                         message. The public key MUST use a curve
-                         and point format supported by the client,
-                         as described in  [TLSECC].
-
-   -  The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are
-      used to guide certificate selection.
-
-   If the client provided a "signature_algorithms" extension, then all
-   certificates provided by the server MUST be signed by a
-   hash/signature algorithm pair that appears in that extension.  Note
-   that this implies that a certificate containing a key for one
-   signature algorithm MAY be signed using a different signature
-   algorithm (for instance, an RSA key signed with a DSA key.) This is a
-   departure from TLS 1.1, which required that the algorithms be the
-   same.  Note that this also implies that the DH_DSS, DH_RSA,
-   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
-   algorithm used to sign the certificate. Fixed DH certificates MAY be
-   signed with any hash/signature algorithm pair appearing in the
-   extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
-   historical.
-
-   If the server has multiple certificates, it chooses one of them based
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 48]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   on the above-mentioned criteria (in addition to other criteria, such
-   as transport layer endpoint, local configuration and preferences,
-   etc.). If the server has a single certificate it SHOULD attempt to
-   validate that it meets these criteria.
-
-   Note that there are certificates that use algorithms and/or algorithm
-   combinations that cannot be currently used with TLS.  For example, a
-   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
-   SubjectPublicKeyInfo) cannot be used because TLS defines no
-   corresponding signature algorithm.
-
-   As cipher suites that specify new key exchange methods are specified
-   for the TLS Protocol, they will the imply certificate format and the
-   required encoded keying information.
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-
-      This message will be sent immediately after the server Certificate
-      message (or the ServerHello message, if this is an anonymous
-      negotiation).
-
-      The ServerKeyExchange message is sent by the server only when the
-      server Certificate message (if sent) does not contain enough data
-      to allow the client to exchange a premaster secret. This is true
-      for the following key exchange methods:
-
-         DHE_DSS
-         DHE_RSA
-         DH_anon
-
-      It is not legal to send the ServerKeyExchange message for the
-      following key exchange methods:
-
-         RSA
-         DH_DSS
-         DH_RSA
-
-         Other key exchange algorithms, such as those defined in
-         [TLSECC], MUST specify whether the ServerKeyExchange message is
-         sent or not; and if the message is sent, its contents.
-
-   Meaning of this message:
-
-      This message conveys cryptographic information to allow the client
-      to communicate the premaster secret: a Diffie-Hellman public key
-      with which the client can complete a key exchange (with the result
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 49]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      being the premaster secret) or a public key for some other
-      algorithm.
-
-   Structure of this message:
-
-      enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
-            /* may be extended, e.g. for ECDH -- see [TLSECC] */
-           } KeyExchangeAlgorithm;
-
-      struct {
-          opaque dh_p<1..2^16-1>;
-          opaque dh_g<1..2^16-1>;
-          opaque dh_Ys<1..2^16-1>;
-      } ServerDHParams;     /* Ephemeral DH parameters */
-
-      dh_p
-         The prime modulus used for the Diffie-Hellman operation.
-
-      dh_g
-         The generator used for the Diffie-Hellman operation.
-
-      dh_Ys
-         The server's Diffie-Hellman public value (g^X mod p).
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case dh_anon:
-                  ServerDHParams params;
-              case dhe_dss:
-              case dhe_rsa:
-                  ServerDHParams params;
-                  digitally-signed struct {
-                      opaque client_random[32];
-                      opaque server_random[32];
-                      ServerDHParams params;
-                  } signed_params;
-              case rsa:
-              case dh_dss:
-              case dh_rsa:
-                  struct {} ;
-                 /* message is omitted for rsa, dh_dss, and dh_rsa */
-              /* may be extended, e.g. for ECDH -- see [TLSECC] */
-          };
-      } ServerKeyExchange;
-
-      params
-         The server's key exchange parameters.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 50]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      signed_params
-         For non-anonymous key exchanges, a signature over the
-         server's key exchange parameters.
-
-   If the client has offered the "signature_algorithms" extension, the
-   signature algorithm and hash algorithm MUST be a pair listed in that
-   extension. Note that there is a possibility for inconsistencies here.
-   For instance, the client might offer DHE_DSS key exchange but omit
-   any DSA pairs from its "signature_algorithms" extension.  In order to
-   negotiate correctly, the server MUST check any candidate cipher
-   suites against the "signature_algorithms" extension before selecting
-   them. This is somewhat inelegant but is a compromise designed to
-   minimize changes to the original cipher suite design.
-
-   In addition, the hash and signature algorithms MUST be compatible
-   with the key in the server's end-entity certificate.  RSA keys MAY be
-   used with any permitted hash algorithm, subject to restrictions in
-   the certificate, if any.
-
-   Because DSA signatures do not contain any secure indication of hash
-   algorithm, there is a risk of hash substitution if multiple hashes
-   may be used with any key. Currently, DSA [DSS] may only be used with
-   SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use
-   of other digest algorithms with DSA, as well as guidance as to which
-   digest algorithms should be used with each key size. In addition,
-   future revisions of [PKIX] may specify mechanisms for certificates to
-   indicate which digest algorithms are to be used with DSA.
-
-   As additional cipher suites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-7.4.4. Certificate Request
-
-   When this message will be sent:
-
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the ServerKeyExchange
-       message (if it is sent; otherwise, the server's Certificate
-       message).
-
-   Structure of this message:
-
-      enum {
-          rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 51]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-          rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-          fortezza_dms_RESERVED(20), (255)
-      } ClientCertificateType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-      struct {
-          ClientCertificateType certificate_types<1..2^8-1>;
-          SignatureAndHashAlgorithm
-            supported_signature_algorithms<2^16-1>;
-          DistinguishedName certificate_authorities<0..2^16-1>;
-      } CertificateRequest;
-
-   certificate_types
-      A list of the types of certificate types which the client may
-      offer.
-
-         rsa_sign        a certificate containing an RSA key
-         dss_sign        a certificate containing a DSA key
-         rsa_fixed_dh    a certificate containing a static DH key.
-         dss_fixed_dh    a certificate containing a static DH key
-
-   supported_signature_algorithms
-      A list of the hash/signature algorithm pairs that the server is
-      able to verify, listed in descending order of preference.
-
-   certificate_authorities
-      A list of the distinguished names [X501] of acceptable
-      certificate_authorities, represented in DER-encoded format. These
-      distinguished names may specify a desired distinguished name for a
-      root CA or for a subordinate CA; thus, this message can be used
-      both to describe known roots and a desired authorization space. If
-      the certificate_authorities list is empty then the client MAY send
-      any certificate of the appropriate ClientCertificateType, unless
-      there is some external arrangement to the contrary.
-
-   The interaction of the certificate_types and
-   supported_signature_algorithms fields is somewhat complicated.
-   certificate_types has been present in TLS since SSLv3, but was
-   somewhat underspecified. Much of its functionality is superseded by
-   supported_signature_algorithms. The following rules apply:
-
-   -  Any certificates provided by the client MUST be signed using a
-      hash/signature algorithm pair found in
-      supported_signature_algorithms.
-
-   -  The end-entity certificate provided by the client MUST contain a
-      key which is compatible with certificate_types. If the key is a
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 52]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      signature key, it MUST be usable with some hash/signature
-      algorithm pair in supported_signature_algorithms.
-
-   -  For historical reasons, the names of some client certificate types
-      include the algorithm used to sign the certificate.  For example,
-      in earlier versions of TLS, rsa_fixed_dh meant a certificate
-      signed with RSA and containing a static DH key.  In TLS 1.2, this
-      functionality has been obsoleted by the
-      supported_signature_algorithms, and the certificate type no longer
-      restricts the algorithm used to sign the certificate.  For
-      example, if the server sends dss_fixed_dh certificate type and
-      {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
-      with a certificate containing a static DH key, signed with RSA-
-      SHA1.
-
-   New ClientCertificateType values are assigned by IANA as described in
-   Section 12.
-
-   Note: Values listed as RESERVED may not be used. They were used in
-   SSLv3.
-
-   Note: It is a fatal handshake_failure alert for an anonymous server
-   to request client authentication.
-
-7.4.5 Server Hello Done
-
-   When this message will be sent:
-
-      The ServerHelloDone message is sent by the server to indicate the
-      end of the ServerHello and associated messages. After sending this
-      message, the server will wait for a client response.
-
-   Meaning of this message:
-
-      This message means that the server is done sending messages to
-      support the key exchange, and the client can proceed with its
-      phase of the key exchange.
-
-      Upon receipt of the ServerHelloDone message, the client SHOULD
-      verify that the server provided a valid certificate, if required,
-      and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-
-      struct { } ServerHelloDone;
-
-7.4.6. Client Certificate
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 53]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   When this message will be sent:
-
-      This is the first message the client can send after receiving a
-      server hello done message. This message is only sent if the server
-      requests a certificate. If no suitable certificate is available,
-      the client MUST send a certificate message containing no
-      certificates. That is, the certificate_list structure has a length
-      of zero.  If the client does not send any certificates, the server
-      MAY at its discretion either continue the handshake without client
-      authentication, or respond with a fatal handshake_failure alert.
-      Also, if some aspect of the certificate chain was unacceptable
-      (e.g., it was not signed by a known, trusted CA), the server MAY
-      at its discretion either continue the handshake (considering the
-      client unauthenticated) or send a fatal alert.
-
-      Client certificates are sent using the Certificate structure
-      defined in Section 7.4.2.
-
-   Meaning of this message:
-
-      This message conveys the client's certificate chain to the server;
-      the server will use it when verifying the CertificateVerify
-      message (when the client authentication is based on signing) or
-      calculating the premaster secret (for non-ephemeral Diffie-
-      Hellman).  The certificate MUST be appropriate for the negotiated
-      cipher suite's key exchange algorithm, and any negotiated
-      extensions.
-
-   In particular:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g. [TLSPGP]).
-
-   -  The end-entity certificate's public key (and associated
-      restrictions) has to be compatible with the certificate types
-      listed in CertificateRequest:
-
-      Client Cert. Type   Certificate Key Type
-
-      rsa_sign            RSA public key; the certificate MUST allow
-                          the key to be used for signing with the
-                          signature scheme and hash algorithm that
-                          will be employed in the certificate verify
-                          message.
-
-      dss_sign            DSA public key; the certificate MUST allow
-                          the key to be used for signing with the
-                          hash algorithm that will be employed in
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 54]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-                          the certificate verify message.
-
-      ecdsa_sign          ECDSA-capable public key; the certificate
-                          MUST allow the key to be used for signing
-                          with the hash algorithm that will be
-                          employed in the certificate verify
-                          message; the public key MUST use a
-                          curve and point format supported by the
-                          server.
-
-      rsa_fixed_dh        Diffie-Hellman public key; MUST use
-      dss_fixed_dh        the same parameters as server's key.
-
-      rsa_fixed_ecdh      ECDH-capable public key; MUST use the
-      ecdsa_fixed_ecdh    same curve as the server's key, and
-                          MUST use a point format supported by
-                          the server.
-
-   -  If the certificate_authorities list in the certificate request
-      message was non-empty, one of the certificates in the certificate
-      chain SHOULD be issued by one of the listed CAs.
-
-   -  The certificates MUST be signed using an acceptable hash/
-      signature algorithm pair, as described in Section 7.4.4. Note that
-      this relaxes the constraints on certificate signing algorithms
-      found in prior versions of TLS.
-
-   Note that as with the server certificate, there are certificates that
-   use algorithms/algorithm combinations that cannot be currently used
-   with TLS.
-
-7.4.7. Client Key Exchange Message
-
-   When this message will be sent:
-
-      This message is always sent by the client. It MUST immediately
-      follow the client certificate message, if it is sent. Otherwise it
-      MUST be the first message sent by the client after it receives the
-      server hello done message.
-
-   Meaning of this message:
-
-      With this message, the premaster secret is set, either through
-      direct transmission of the RSA-encrypted secret, or by the
-      transmission of Diffie-Hellman parameters that will allow each
-      side to agree upon the same premaster secret.
-
-      When the client is using an ephemeral Diffie-Hellman exponent,
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 55]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      then this message contains the client's Diffie-Hellman public
-      value. If the client is sending a certificate containing a static
-      DH exponent (i.e., it is doing fixed_dh client authentication)
-      then this message MUST be sent but MUST be empty.
-
-
-   Structure of this message:
-
-      The choice of messages depends on which key exchange method has
-      been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-      definition.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case rsa:
-                  EncryptedPreMasterSecret;
-              case dhe_dss:
-              case dhe_rsa:
-              case dh_dss:
-              case dh_rsa:
-              case dh_anon:
-                  ClientDiffieHellmanPublic;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-
-      If RSA is being used for key agreement and authentication, the
-      client generates a 48-byte premaster secret, encrypts it using the
-      public key from the server's certificate and sends the result in
-      an encrypted premaster secret message. This structure is a variant
-      of the ClientKeyExchange message and is not a message in itself.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion client_version;
-          opaque random[46];
-      } PreMasterSecret;
-
-      client_version
-         The latest (newest) version supported by the client. This is
-         used to detect version roll-back attacks.
-
-      random
-         46 securely-generated random bytes.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 56]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      struct {
-          public-key-encrypted PreMasterSecret pre_master_secret;
-      } EncryptedPreMasterSecret;
-
-      pre_master_secret
-         This random value is generated by the client and is used to
-         generate the master secret, as specified in Section 8.1.
-
-   Note: The version number in the PreMasterSecret is the version
-   offered by the client in the ClientHello.client_version, not the
-   version negotiated for the connection.  This feature is designed to
-   prevent rollback attacks.  Unfortunately, some old implementations
-   use the negotiated version instead and therefore checking the version
-   number may lead to failure to interoperate with such incorrect client
-   implementations.
-
-   Client implementations MUST always send the correct version number in
-   PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
-   server implementations MUST check the version number as described in
-   the note below. If the version number is TLS 1.0 or earlier, server
-   implementations SHOULD check the version number, but MAY have a
-   configuration option to disable the check. Note that if the check
-   fails, the PreMasterSecret SHOULD be randomized as described below.
-
-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
-   [KPR03] can be used to attack a TLS server that reveals whether a
-   particular message, when decrypted, is properly PKCS#1 formatted,
-   contains a valid PreMasterSecret structure, or has the correct
-   version number.
-
-   The best way to avoid these vulnerabilities is to treat incorrectly
-   formatted messages in a manner indistinguishable from correctly
-   formatted RSA blocks. In other words:
-
-      1. Generate a string R of 46 random bytes
-
-      2. Decrypt the message to recover the plaintext M
-
-      3. If the PKCS#1 padding is not correct, or the length of
-         message M is not exactly 48 bytes:
-            premaster secret = ClientHello.client_version || R
-         else If ClientHello.client_version <= TLS 1.0, and
-         version number check is explicitly disabled:
-            premaster secret = M
-         else:
-            premaster secret = ClientHello.client_version || M[2..47]
-
-   Note that explicitly constructing the premaster_secret with the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 57]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   ClientHello.client_version produces an invalid master_secret if the
-   client has sent the wrong version in the original premaster_secret.
-
-   In any case, a TLS server MUST NOT generate an alert if processing an
-   RSA-encrypted premaster secret message fails, or the version number
-   is not as expected. Instead, it MUST continue the handshake with a
-   randomly generated premaster secret.  It may be useful to log the
-   real cause of failure for troubleshooting purposes; however, care
-   must be taken to avoid leaking the information to an attacker
-   (through, e.g., timing, log files, or other channels.)
-
-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
-   against the Bleichenbacher attack. However, for maximal compatibility
-   with earlier versions of TLS, this specification uses the RSAES-
-   PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known
-   to exist provided that the above recommendations are followed.
-
-   Implementation Note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes. These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined. The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the length bytes, encoding the RSA encrypted data directly in
-   the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes. The resulting
-   PDU is incompatible with many SSLv3 implementations. Implementors
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding. Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-   behavior dependent on the protocol version.
-
-   Implementation Note: It is now known that remote timing-based attacks
-   on TLS are possible, at least when the client and server are on the
-   same LAN. Accordingly, implementations that use static RSA keys MUST
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
-
-7.4.7.2. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-
-      This structure conveys the client's Diffie-Hellman public value
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 58]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      (Yc) if it was not already included in the client's certificate.
-      The encoding used for Yc is determined by the enumerated
-      PublicValueEncoding. This structure is a variant of the client key
-      exchange message, and not a message in itself.
-
-   Structure of this message:
-
-      enum { implicit, explicit } PublicValueEncoding;
-
-      implicit
-         If the client has sent a certificate which contains a suitable
-         Diffie-Hellman key (for fixed_dh client authentication) then Yc
-         is implicit and does not need to be sent again. In this case,
-         the client key exchange message will be sent, but it MUST be
-         empty.
-
-      explicit
-         Yc needs to be sent.
-
-      struct {
-          select (PublicValueEncoding) {
-              case implicit: struct { };
-              case explicit: opaque dh_Yc<1..2^16-1>;
-          } dh_public;
-      } ClientDiffieHellmanPublic;
-
-      dh_Yc
-         The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-
-      This message is used to provide explicit verification of a client
-      certificate. This message is only sent following a client
-      certificate that has signing capability (i.e. all certificates
-      except those containing fixed Diffie-Hellman parameters). When
-      sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-
-      struct {
-           digitally-signed struct {
-               opaque handshake_messages[handshake_messages_length];
-           }
-      } CertificateVerify;
-
-      Here handshake_messages refers to all handshake messages sent or
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 59]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      received starting at client hello up to but not including this
-      message, including the type and length fields of the handshake
-      messages. This is the concatenation of all the Handshake
-      structures as defined in 7.4 exchanged thus far. Note that this
-      requires both sides to either buffer the messages or compute
-      running hashes for all potential hash algorithms up to the time of
-      the CertificateVerify computation. Servers can minimize this
-      computation cost by offering a restricted set of digest algorithms
-      in the CertificateRequest message.
-
-      The hash and signature algorithms used in the signature MUST be
-      one of those present in the supported_signature_algorithms field
-      of the CertificateRequest message. In addition, the hash and
-      signature algorithms MUST be compatible with the key in the
-      client's end-entity certificate.  RSA keys MAY be used with any
-      permitted hash algorithm, subject to restrictions in the
-      certificate, if any.
-
-      Because DSA signatures do not contain any secure indication of
-      hash algorithm, there is a risk of hash substitution if multiple
-      hashes may be used with any key. Currently, DSA [DSS] may only be
-      used with SHA-1. Future revisions of DSS [DSS-3] are expected to
-      allow the use of other digest algorithms with DSA, as well as
-      guidance as to which digest algorithms should be used with each
-      key size. In addition, future revisions of [PKIX] may specify
-      mechanisms for certificates to indicate which digest algorithms
-      are to be used with DSA.
-
-
-7.4.9. Finished
-
-   When this message will be sent:
-
-      A Finished message is always sent immediately after a change
-      cipher spec message to verify that the key exchange and
-      authentication processes were successful. It is essential that a
-      change cipher spec message be received between the other handshake
-      messages and the Finished message.
-
-   Meaning of this message:
-
-      The finished message is the first one protected with the just
-      negotiated algorithms, keys, and secrets. Recipients of finished
-      messages MUST verify that the contents are correct.  Once a side
-      has sent its Finished message and received and validated the
-      Finished message from its peer, it may begin to send and receive
-      application data over the connection.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 60]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   Structure of this message:
-
-      struct {
-          opaque verify_data[verify_data_length];
-      } Finished;
-
-      verify_data
-         PRF(master_secret, finished_label, Hash(handshake_messages))
-            [0..verify_data_length-1];
-
-      finished_label
-         For Finished messages sent by the client, the string "client
-         finished". For Finished messages sent by the server, the string
-         "server finished".
-
-      Hash denotes a Hash of the handshake messages. For the PRF defined
-      in Section 5, the Hash MUST be the Hash used as the basis for the
-      PRF. Any cipher suite which defines a different PRF MUST also
-      define the Hash to use in the Finished computation.
-
-      In previous versions of TLS, the verify_data was always 12 octets
-      long. In the current version of TLS, it depends on the cipher
-      suite. Any cipher suite which does not explicitly specify
-      verify_data_length has a verify_data_length equal to 12. This
-      includes all existing cipher suites.  Note that this
-      representation has the same encoding as with previous versions.
-      Future cipher suites MAY specify other lengths but such length
-      MUST be at least 12 bytes.
-
-      handshake_messages
-         All of the data from all messages in this handshake (not
-         including any HelloRequest messages) up to but not including
-         this message. This is only data visible at the handshake layer
-         and does not include record layer headers.  This is the
-         concatenation of all the Handshake structures as defined in
-         7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a
-   ChangeCipherSpec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at ClientHello up to, but not including, this Finished message. This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the CertificateVerify message (if sent). Also, the
-   handshake_messages for the Finished message sent by the client will
-   be different from that for the Finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 61]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   Note: ChangeCipherSpec messages, alerts, and any other record types
-   are not handshake messages and are not included in the hash
-   computations. Also, HelloRequest messages are omitted from handshake
-   hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-      master_secret = PRF(pre_master_secret, "master secret",
-                          ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a
-   48-byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
-   Note: Diffie-Hellman parameters are specified by the server and may
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 62]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
-   definition).
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-11. Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-12. IANA Considerations
-
-   This document uses several registries that were originally created in
-   [TLS1.1]. IANA is requested to update (has updated) these to
-   reference this document. The registries and their allocation policies
-   (unchanged from [TLS1.1]) are listed below.
-
-   -  TLS ClientCertificateType Identifiers Registry: Future values in
-      the range 0-63 (decimal) inclusive are assigned via Standards
-      Action [RFC2434]. Values in the range 64-223 (decimal) inclusive
-      are assigned Specification Required [RFC2434]. Values from 224-255
-      (decimal) inclusive are reserved for Private Use [RFC2434].
-
-   -  TLS Cipher Suite Registry: Future values with the first byte in
-      the range 0-191 (decimal) inclusive are assigned via Standards
-      Action [RFC2434].  Values with the first byte in the range 192-254
-      (decimal) are assigned via Specification Required [RFC2434].
-      Values with the first byte 255 (decimal) are reserved for Private
-      Use [RFC2434].
-
-   -  This document defines several new HMAC-SHA256 based cipher suites,
-      whose values (in Appendix A.5) are to be (have been) allocated
-      from the TLS Cipher Suite registry.
-
-   -  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 63]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   -  TLS Alert Registry: Future values are allocated via Standards
-      Action [RFC2434].
-
-   -  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA is requested to update (has updated) it to reference this
-   document.  The registry and its allocation policy (unchanged from
-   [RFC4366]) is listed below:
-
-   -  TLS ExtensionType Registry: Future values are allocated via IETF
-      Consensus [RFC2434]. IANA is requested to update this registry to
-      include the signature_algorithms extension and fill in the
-      appropriate value in Section 7.4.1.4.
-
-   In addition, this document defines two new registries to be
-   maintained by IANA:
-
-   -  TLS SignatureAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-   -  TLS HashAlgorithm Registry: The registry will be initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-      This document also uses the TLS Compression Method Identifiers
-      Registry, defined in [RFC3749].  IANA is requested to allocate
-      value  0 for the "null" compression method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 64]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-Appendix A. Protocol Data Structures and Constant Values
-
-      This section describes protocol types and constants.
-
-A.1. Record Layer
-
-   struct {
-       uint8 major;
-       uint8 minor;
-   } ProtocolVersion;
-
-   ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-   enum {
-       change_cipher_spec(20), alert(21), handshake(22),
-       application_data(23), (255)
-   } ContentType;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSPlaintext.length];
-   } TLSPlaintext;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSCompressed.length];
-   } TLSCompressed;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       select (SecurityParameters.cipher_type) {
-           case stream: GenericStreamCipher;
-           case block:  GenericBlockCipher;
-           case aead:   GenericAEADCipher;
-       } fragment;
-   } TLSCiphertext;
-
-   stream-ciphered struct {
-       opaque content[TLSCompressed.length];
-       opaque MAC[SecurityParameters.mac_length];
-   } GenericStreamCipher;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 65]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       block-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       };
-   } GenericBlockCipher;
-
-   struct {
-      opaque nonce_explicit[SecurityParameters.record_iv_length];
-      aead-ciphered struct {
-          opaque content[TLSCompressed.length];
-      };
-   } GenericAEADCipher;
-A.2. Change Cipher Specs Message
-
-   struct {
-       enum { change_cipher_spec(1), (255) } type;
-   } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-   enum { warning(1), fatal(2), (255) } AlertLevel;
-
-   enum {
-       close_notify(0),
-       unexpected_message(10),
-       bad_record_mac(20),
-       decryption_failed_RESERVED(21),
-       record_overflow(22),
-       decompression_failure(30),
-       handshake_failure(40),
-       no_certificate_RESERVED(41),
-       bad_certificate(42),
-       unsupported_certificate(43),
-       certificate_revoked(44),
-       certificate_expired(45),
-       certificate_unknown(46),
-       illegal_parameter(47),
-       unknown_ca(48),
-       access_denied(49),
-       decode_error(50),
-       decrypt_error(51),
-       export_restriction_RESERVED(60),
-       protocol_version(70),
-       insufficient_security(71),
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 66]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-       internal_error(80),
-       user_canceled(90),
-       no_renegotiation(100),
-       unsupported_extension(110),           /* new */
-       (255)
-   } AlertDescription;
-
-   struct {
-       AlertLevel level;
-       AlertDescription description;
-   } Alert;
-
-A.4. Handshake Protocol
-
-   enum {
-       hello_request(0), client_hello(1), server_hello(2),
-       certificate(11), server_key_exchange (12),
-       certificate_request(13), server_hello_done(14),
-       certificate_verify(15), client_key_exchange(16),
-       finished(20)
-       (255)
-   } HandshakeType;
-
-   struct {
-       HandshakeType msg_type;
-       uint24 length;
-       select (HandshakeType) {
-           case hello_request:       HelloRequest;
-           case client_hello:        ClientHello;
-           case server_hello:        ServerHello;
-           case certificate:         Certificate;
-           case server_key_exchange: ServerKeyExchange;
-           case certificate_request: CertificateRequest;
-           case server_hello_done:   ServerHelloDone;
-           case certificate_verify:  CertificateVerify;
-           case client_key_exchange: ClientKeyExchange;
-           case finished:            Finished;
-       } body;
-   } Handshake;
-
-A.4.1. Hello Messages
-
-   struct { } HelloRequest;
-
-   struct {
-       uint32 gmt_unix_time;
-       opaque random_bytes[28];
-   } Random;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 67]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   opaque SessionID<0..32>;
-
-   uint8 CipherSuite[2];
-
-   enum { null(0), (255) } CompressionMethod;
-
-   struct {
-       ProtocolVersion client_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suites<2..2^16-2>;
-       CompressionMethod compression_methods<1..2^8-1>;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ClientHello;
-
-   struct {
-       ProtocolVersion server_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suite;
-       CompressionMethod compression_method;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ServerHello;
-
-   struct {
-       ExtensionType extension_type;
-       opaque extension_data<0..2^16-1>;
-   } Extension;
-
-   enum {
-       signature_algorithms(TBD-BY-IANA), (65535)
-   } ExtensionType;
-
-   enum{
-       none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
-       sha512(6), (255)
-   } HashAlgorithm;
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 68]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   enum {
-      anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
-   } SignatureAlgorithm;
-
-   struct {
-         HashAlgorithm hash;
-         SignatureAlgorithm signature;
-   } SignatureAndHashAlgorithm;
-
-   SignatureAndHashAlgorithm
-    supported_signature_algorithms<2..2^16-1>;
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-   opaque ASN.1Cert<2^24-1>;
-
-   struct {
-       ASN.1Cert certificate_list<0..2^24-1>;
-   } Certificate;
-
-   enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
-          /* may be extended, e.g. for ECDH -- see [TLSECC] */
-        } KeyExchangeAlgorithm;
-
-   struct {
-       opaque dh_p<1..2^16-1>;
-       opaque dh_g<1..2^16-1>;
-       opaque dh_Ys<1..2^16-1>;
-   } ServerDHParams;     /* Ephemeral DH parameters */
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case dh_anon:
-               ServerDHParams params;
-           case dhe_dss:
-           case dhe_rsa:
-               ServerDHParams params;
-               digitally-signed struct {
-                   opaque client_random[32];
-                   opaque server_random[32];
-                   ServerDHParams params;
-               } signed_params;
-           case rsa:
-           case dh_dss:
-           case dh_rsa:
-               struct {} ;
-              /* message is omitted for rsa, dh_dss, and dh_rsa */
-           /* may be extended, e.g. for ECDH -- see [TLSECC] */
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 69]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   } ServerKeyExchange;
-
-
-   enum {
-       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-       fortezza_dms_RESERVED(20),
-       (255)
-   } ClientCertificateType;
-
-   opaque DistinguishedName<1..2^16-1>;
-
-   struct {
-       ClientCertificateType certificate_types<1..2^8-1>;
-       DistinguishedName certificate_authorities<0..2^16-1>;
-   } CertificateRequest;
-
-   struct { } ServerHelloDone;
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa:
-               EncryptedPreMasterSecret;
-           case dhe_dss:
-           case dhe_rsa:
-           case dh_dss:
-           case dh_rsa:
-           case dh_anon:
-               ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   } PreMasterSecret;
-
-   struct {
-       public-key-encrypted PreMasterSecret pre_master_secret;
-   } EncryptedPreMasterSecret;
-
-   enum { implicit, explicit } PublicValueEncoding;
-
-   struct {
-       select (PublicValueEncoding) {
-           case implicit: struct {};
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 70]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-           case explicit: opaque DH_Yc<1..2^16-1>;
-       } dh_public;
-   } ClientDiffieHellmanPublic;
-
-   struct {
-        digitally-signed struct {
-            opaque handshake_messages[handshake_messages_length];
-        }
-   } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-   struct {
-       opaque verify_data[verify_data_length];
-   } Finished;
-
-A.5. The Cipher Suite
-
-   The following values define the cipher suite codes used in the client
-   hello and server hello messages.
-
-   A cipher suite defines a cipher specification supported in TLS
-   Version 1.2.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   NOT be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-      CipherSuite TLS_NULL_WITH_NULL_NULL               = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request any signature-capable certificate in the certificate request
-   message.
-
-      CipherSuite TLS_RSA_WITH_NULL_MD5                 = { 0x00,0x01 };
-      CipherSuite TLS_RSA_WITH_NULL_SHA                 = { 0x00,0x02 };
-      CipherSuite TLS_RSA_WITH_NULL_SHA256              = { 0x00,TBD1 };
-      CipherSuite TLS_RSA_WITH_RC4_128_MD5              = { 0x00,0x04 };
-      CipherSuite TLS_RSA_WITH_RC4_128_SHA              = { 0x00,0x05 };
-      CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA         = { 0x00,0x0A };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x35 };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256       = { 0x00,TBD2 };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256       = { 0x00,TBD3 };
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 71]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   The following cipher suite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a signature-capable certificate, which has
-   been signed by the CA. The signing algorithm used by the server is
-   specified after the DHE component of the CipherSuite name. The server
-   can request any signature-capable certificate from the client for
-   client authentication or it may request a Diffie-Hellman certificate.
-   Any Diffie-Hellman certificate provided by the client must use the
-   parameters (group and generator) described by the server.
-
-
-      CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x0D };
-      CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x10 };
-      CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x13 };
-      CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x16 };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00,TBD4 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00,TBD5 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00,TBD6 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00,TBD7 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256    = { 0x00,TBD8 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256    = { 0x00,TBD9 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   = { 0x00,TBDA };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   = { 0x00,TBDB };
-
-   The following cipher suites are used for completely anonymous Diffie-
-   Hellman communications in which neither party is authenticated. Note
-   that this mode is vulnerable to man-in-the-middle attacks.  Using
-   this mode therefore is of limited use: These cipher suites MUST NOT
-   be used by TLS 1.2 implementations unless the application layer has
-   specifically requested to allow anonymous key exchange.  (Anonymous
-   key exchange may sometimes be acceptable, for example, to support
-   opportunistic encryption when no set-up for authentication is in
-   place, or when TLS is used as part of more complex security protocols
-   that have other means to ensure authentication.)
-
-      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
-      CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 72]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,TBDC};
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00,TBDD};
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-   New cipher suite values are assigned by IANA as described in Section
-   12.
-
-   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in SSL
-   3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-   enum { null(0), (255) } CompressionMethod;
-
-   enum { server, client } ConnectionEnd;
-
-   enum { tls_prf_sha256 } PRFAlgorithm;
-
-   enum { null, rc4, 3des, aes }
-   BulkCipherAlgorithm;
-
-   enum { stream, block, aead } CipherType;
-
-   enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
-     hmac_sha512} MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod, PRFAlgorithm
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-   struct {
-       ConnectionEnd          entity;
-       PRFAlgorithm           prf_algorithm;
-       BulkCipherAlgorithm    bulk_cipher_algorithm;
-       CipherType             cipher_type;
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 73]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-       uint8                  enc_key_length;
-       uint8                  block_length;
-       uint8                  fixed_iv_length;
-       uint8                  record_iv_length;
-       MACAlgorithm           mac_algorithm;
-       uint8                  mac_length;
-       uint8                  mac_key_length;
-       CompressionMethod      compression_algorithm;
-       opaque                 master_secret[48];
-       opaque                 client_random[32];
-       opaque                 server_random[32];
-   } SecurityParameters;
-
-A.7. Changes to RFC 4492
-
-   RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS.  This
-   document changes some of the structures used in that document. This
-   section details the required changes for implementors of both RFC
-   4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing
-   RFC 4492 do not need to read this section.
-
-   This document adds a "signature_algorithm" field to the digitally-
-   signed element in order to identify the signature and digest
-   algorithms used to create a signature. This change applies to digital
-   signatures formed using ECDSA as well, thus allowing ECDSA signatures
-   to be used with digest algorithms other than SHA-1, provided such use
-   is compatible with the certificate and any restrictions imposed by
-   future revisions of [PKIX].
-
-   As described in Sections 7.4.2 and 7.4.6, the restrictions on the
-   signature algorithms used to sign certificates are no longer tied to
-   the cipher suite (when used by the server) or the
-   ClientCertificateType (when used by the client). Thus, the
-   restrictions on the algorithm used to sign certificates specified in
-   Sections 2 and 3 of RFC 4492 are also relaxed. As in this document
-   the restrictions on the keys in the end-entity certificate remain.
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-      AES [AES] is a widely used symmetric encryption algorithm.  AES is
-      a block cipher with a 128, 192, or 256 bit keys and a 16 byte
-      block size. TLS currently only supports the 128 and 256 bit key
-      sizes.
-
-   application protocol
-      An application protocol is a protocol that normally layers
-      directly on top of the transport layer (e.g., TCP/IP). Examples
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 74]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-      See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-      A symmetric encryption algorithm that simultaneously provides
-      confidentiality and message integrity.
-
-   authentication
-      Authentication is the ability of one entity to determine the
-      identity of another entity.
-
-   block cipher
-      A block cipher is an algorithm that operates on plaintext in
-      groups of bits, called blocks. 64 bits was, and 128 bits, is a
-      common block size.
-
-   bulk cipher
-      A symmetric encryption algorithm used to encrypt large quantities
-      of data.
-
-   cipher block chaining (CBC)
-      CBC is a mode in which every plaintext block encrypted with a
-      block cipher is first exclusive-ORed with the previous ciphertext
-      block (or, in the case of the first block, with the initialization
-      vector). For decryption, every block is first decrypted, then
-      exclusive-ORed with the previous ciphertext block (or IV).
-
-   certificate
-      As part of the X.509 protocol (a.k.a. ISO Authentication
-      framework), certificates are assigned by a trusted Certificate
-      Authority and provide a strong binding between a party's identity
-      or some other attributes and its public key.
-
-   client
-      The application entity that initiates a TLS connection to a
-      server. This may or may not imply that the client initiated the
-      underlying transport connection. The primary operational
-      difference between the server and client is that the server is
-      generally authenticated, while the client is only optionally
-      authenticated.
-
-   client write key
-      The key used to encrypt data written by the client.
-
-   client write MAC key
-      The secret data used to authenticate data written by the client.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 75]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   connection
-      A connection is a transport (in the OSI layering model definition)
-      that provides a suitable type of service. For TLS, such
-      connections are peer-to-peer relationships. The connections are
-      transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-      DES [DES] still is a very widely used symmetric encryption
-      algorithm although it is considered as rather weak now. DES is a
-      block cipher with a 56-bit key and an 8-byte block size. Note that
-      in TLS, for key generation purposes, DES is treated as having an
-      8-byte key length (64 bits), but it still only provides 56 bits of
-      protection. (The low bit of each key byte is presumed to be set to
-      produce odd parity in that key byte.) DES can also be operated in
-      a mode [3DES] where three independent keys and three encryptions
-      are used for each block of data; this uses 168 bits of key (24
-      bytes in the TLS key generation method) and provides the
-      equivalent of 112 bits of security.
-
-   Digital Signature Standard (DSS)
-      A standard for digital signing, including the Digital Signing
-      Algorithm, approved by the National Institute of Standards and
-      Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
-      Standard", published January 2000 by the U.S. Dept. of Commerce
-      [DSS].  A significant update [DSS-3] has been drafted and
-      published in March 2006.
-
-
-   digital signatures
-      Digital signatures utilize public key cryptography and one-way
-      hash functions to produce a signature of the data that can be
-      authenticated, and is difficult to forge or repudiate.
-
-   handshake
-      An initial negotiation between client and server that establishes
-      the parameters of their transactions.
-
-   Initialization Vector (IV)
-      When a block cipher is used in CBC mode, the initialization vector
-      is exclusive-ORed with the first plaintext block prior to
-      encryption.
-
-   Message Authentication Code (MAC)
-      A Message Authentication Code is a one-way hash computed from a
-      message and some secret data. It is difficult to forge without
-      knowing the secret data. Its purpose is to detect if the message
-      has been altered.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 76]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   master secret
-      Secure secret data used for generating encryption keys, MAC
-      secrets, and IVs.
-
-   MD5
-      MD5 [MD5] is a hashing function that converts an arbitrarily long
-      data stream into a hash of fixed size (16 bytes).  Due to
-      significant progresses in cryptanalysis, at the time of
-      publication of this document, MD5 no longer can be considered a
-      'secure' hashing function.
-
-   public key cryptography
-      A class of cryptographic techniques employing two-key ciphers.
-      Messages encrypted with the public key can only be decrypted with
-      the associated private key. Conversely, messages signed with the
-      private key can be verified with the public key.
-
-   one-way hash function
-      A one-way transformation that converts an arbitrary amount of data
-      into a fixed-length hash. It is computationally hard to reverse
-      the transformation or to find collisions. MD5 and SHA are examples
-      of one-way hash functions.
-
-   RC4
-      A stream cipher invented by Ron Rivest. A compatible cipher is
-      described in [SCH].
-
-   RSA
-      A very widely used public-key algorithm that can be used for
-      either encryption or digital signing. [RSA]
-
-   server
-      The server is the application entity that responds to requests for
-      connections from clients. See also under client.
-
-   session
-      A TLS session is an association between a client and a server.
-      Sessions are created by the handshake protocol. Sessions define a
-      set of cryptographic security parameters that can be shared among
-      multiple connections. Sessions are used to avoid the expensive
-      negotiation of new security parameters for each connection.
-
-   session identifier
-      A session identifier is a value generated by a server that
-      identifies a particular session.
-
-   server write key
-      The key used to encrypt data written by the server.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 77]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   server write MAC key
-      The secret data used to authenticate data written by the server.
-
-   SHA
-      The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It
-      produces a 20-byte output. Note that all references to SHA
-      (without a numerical suffix) actually use the modified SHA-1
-      algorithm.
-
-   SHA-256
-      The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It
-      produces a 32-byte output.
-
-   SSL
-      Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-      SSL Version 3.0
-
-   stream cipher
-      An encryption algorithm that converts a key into a
-      cryptographically strong keystream, which is then exclusive-ORed
-      with the plaintext.
-
-   symmetric cipher
-      See bulk cipher.
-
-   Transport Layer Security (TLS)
-      This protocol; also, the Transport Layer Security working group of
-      the Internet Engineering Task Force (IETF). See "Comments" at the
-      end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 78]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-Appendix C. Cipher Suite Definitions
-
-Cipher Suite                            Key        Cipher         Mac
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL         NULL         NULL
-TLS_RSA_WITH_NULL_MD5                   RSA          NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA          NULL         SHA
-TLS_RSA_WITH_NULL_SHA256                RSA          NULL         SHA256
-TLS_RSA_WITH_RC4_128_MD5                RSA          RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA          RC4_128      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA          3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA          AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_CBC_SHA            RSA          AES_256_CBC  SHA
-TLS_RSA_WITH_AES_128_CBC_SHA256         RSA          AES_128_CBC  SHA256
-TLS_RSA_WITH_AES_256_CBC_SHA256         RSA          AES_256_CBC  SHA256
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS       3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA       3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS      3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA      3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon      RC4_128      MD5
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon      3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS       AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA       AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS      AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA      AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon      AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS       AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA       AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS      AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA      AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon      AES_256_CBC  SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA256      DH_DSS       AES_128_CBC  SHA256
-TLS_DH_RSA_WITH_AES_128_CBC_SHA256      DH_RSA       AES_128_CBC  SHA256
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA256     DHE_DSS      AES_128_CBC  SHA256
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA256     DHE_RSA      AES_128_CBC  SHA256
-TLS_DH_anon_WITH_AES_128_CBC_SHA256     DH_anon      AES_128_CBC  SHA256
-TLS_DH_DSS_WITH_AES_256_CBC_SHA256      DH_DSS       AES_256_CBC  SHA256
-TLS_DH_RSA_WITH_AES_256_CBC_SHA256      DH_RSA       AES_256_CBC  SHA256
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA256     DHE_DSS      AES_256_CBC  SHA256
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA256     DHE_RSA      AES_256_CBC  SHA256
-TLS_DH_anon_WITH_AES_256_CBC_SHA256     DH_anon      AES_256_CBC  SHA256
-
-
-                        Key      IV   Block
-Cipher        Type    Material  Size  Size
-------------  ------  --------  ----  -----
-NULL          Stream      0       0    N/A
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 79]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-RC4_128       Stream     16       0    N/A
-3DES_EDE_CBC  Block      24       8      8
-AES_128_CBC   Block      16      16     16
-AES_256_CBC   Block      32      16     16
-
-
-MAC       Algorithm    mac_length  mac_key_length
---------  -----------  ----------  --------------
-NULL      N/A              0             0
-MD5       HMAC-MD5        16            16
-SHA       HMAC-SHA1       20            20
-SHA256    HMAC-SHA256     32            32
-
-   Type
-      Indicates whether this is a stream cipher or a block cipher
-      running in CBC mode.
-
-   Key Material
-      The number of bytes from the key_block that are used for
-      generating the write keys.
-
-   Expanded Key Material
-      The number of bytes actually fed into the encryption algorithm.
-
-   IV Size
-      The amount of data needed to be generated for the initialization
-      vector. Zero for stream ciphers; equal to the block size for block
-      ciphers (this is equal to SecurityParameters.record_iv_length).
-
-   Block Size
-      The amount of data a block cipher enciphers in one chunk; a block
-      cipher running in CBC mode can only encrypt an even multiple of
-      its block size.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 80]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1 Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably SHA-1, are acceptable,
-   but cannot provide more security than the size of the random number
-   generator state.
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.3 Cipher Suites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-D.4 Implementation Pitfalls
-
-   Implementation experience has shown that certain parts of earlier TLS
-   specifications are not easy to understand, and have been a source of
-   interoperability and security problems. Many of these areas have been
-   clarified in this document, but this appendix contains a short list
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 81]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   of the most important things that require special attention from
-   implementors.
-
-   TLS protocol issues:
-
-   -  Do you correctly handle handshake messages that are fragmented
-      to multiple TLS records (see Section 6.2.1)? Including corner
-      cases like a ClientHello that is split to several small
-      fragments? Do you fragment handshake messages that exceed the
-      maximum fragment size? In particular, the certificate and
-      certificate request handshake messages can be large enough to
-      require fragmentation.
-
-   -  Do you ignore the TLS record layer version number in all TLS
-      records before ServerHello (see Appendix E.1)?
-
-   -  Do you handle TLS extensions in ClientHello correctly,
-      including omitting the extensions field completely?
-
-   -  Do you support renegotiation, both client and server initiated?
-      While renegotiation is an optional feature, supporting
-      it is highly recommended.
-
-   -  When the server has requested a client certificate, but no
-      suitable certificate is available, do you correctly send
-      an empty Certificate message, instead of omitting the whole
-      message (see Section 7.4.6)?
-
-   Cryptographic details:
-
-   -  In RSA-encrypted Premaster Secret,  do you correctly send and
-      verify the version number? When an error is encountered, do
-      you continue the handshake to avoid the Bleichenbacher
-      attack (see Section 7.4.7.1)?
-
-   -  What countermeasures do you use to prevent timing attacks against
-      RSA decryption and signing operations (see Section 7.4.7.1)?
-
-   -  When verifying RSA signatures, do you accept both NULL and
-      missing parameters (see Section 4.7)? Do you verify that the
-      RSA padding doesn't have additional data after the hash value?
-      [FI06]
-
-   -  When using Diffie-Hellman key exchange, do you correctly strip
-      leading zero bytes from the negotiated key (see Section 8.1.2)?
-
-   -  Does your TLS client check that the Diffie-Hellman parameters
-      sent by the server are acceptable (see Section F.1.1.3)?
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 82]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   -  How do you generate unpredictable IVs for CBC mode ciphers
-      (see Section 6.2.3.2)?
-
-   -  Do you accept long CBC mode padding (up to 255 bytes; see
-      Section 6.2.3.2)?
-
-   -  How do you address CBC mode timing attacks (Section 6.2.3.2)?
-
-   -  Do you use a strong and, most importantly, properly seeded
-      random number generator (see Appendix D.1) for generating the
-      premaster secret (for RSA key exchange), Diffie-Hellman private
-      values, the DSA "k" parameter, and other security-critical
-      values?
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 83]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-Appendix E. Backward Compatibility
-
-E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client supports the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version. If the server does not support this
-   version, it will respond with ServerHello containing an older version
-   number. If the client agrees to use this version, the negotiation
-   will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing a version
-   number smaller than the highest supported version. If the server
-   wishes to negotiate with old clients, it will proceed as appropriate
-   for the highest version supported by the server that is not greater
-   than ClientHello.client_version. For example, if the server supports
-   TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello. If server supports (or is willing
-   to use) only versions greater than client_version, it MUST send a
-   "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol version known to
-   a server (for example, when resuming a session), it SHOULD initiate
-   the connection in that native protocol.
-
-   Note: some server implementations are known to implement version
-   negotiation incorrectly. For example, there are buggy TLS 1.0 servers
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 84]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   that simply close the connection when the client offers a version
-   newer than TLS 1.0. Also, it is known that some servers will refuse
-   the connection if any TLS extensions are included in ClientHello.
-   Interoperability with such buggy servers is a complex topic beyond
-   the scope of this document, and may require multiple connection
-   attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed). Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number. Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version. No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2 Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
-   contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS cipher suites in the
-   CIPHER-SPECS-DATA field as described below.
-
-   Warning: The ability to send version 2.0 CLIENT-HELLO messages will
-   be phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-   However, even TLS servers that do not support SSL 2.0 MAY accept
-   version 2.0 CLIENT-HELLO messages. The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions. Note that this message MUST be sent directly on the wire,
-   not wrapped as a TLS record. For the purposes of calculating Finished
-   and CertificateVerify, the msg_length field is not considered to be a
-   part of the handshake message.
-
-      uint8 V2CipherSpec[3];
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 85]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-      struct {
-          uint16 msg_length;
-          uint8 msg_type;
-          Version version;
-          uint16 cipher_spec_length;
-          uint16 session_id_length;
-          uint16 challenge_length;
-          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-          opaque session_id[V2ClientHello.session_id_length];
-          opaque challenge[V2ClientHello.challenge_length;
-      } V2ClientHello;
-
-   msg_length
-      The highest bit MUST be 1; the remaining bits contain the length
-      of the following data in bytes.
-
-   msg_type
-      This field, in conjunction with the version field, identifies a
-      version 2 client hello message. The value MUST be one (1).
-
-   version
-      Equal to ClientHello.client_version.
-
-   cipher_spec_length
-      This field is the total length of the field cipher_specs. It
-      cannot be zero and MUST be a multiple of the V2CipherSpec length
-      (3).
-
-   session_id_length
-      This field MUST have a value of zero for a client that claims to
-      support TLS 1.2.
-
-   challenge_length
-      The length in bytes of the client's challenge to the server to
-      authenticate itself. Historically, permissible values are between
-      16 and 32 bytes inclusive. When using the SSLv2 backward
-      compatible handshake the client SHOULD use a 32 byte challenge.
-
-   cipher_specs
-      This is a list of all CipherSpecs the client is willing and able
-      to use. In addition to the 2.0 cipher specs defined in [SSL2],
-      this includes the TLS cipher suites normally sent in
-      ClientHello.cipher_suites, each cipher suite prefixed by a zero
-      byte. For example, TLS cipher suite {0x00,0x0A} would be sent as
-      {0x00,0x00,0x0A}.
-
-   session_id
-      This field MUST be empty.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 86]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   challenge
-      Corresponds to ClientHello.random. If the challenge length is less
-      than 32, the TLS server will pad the data with leading (note: not
-      trailing) zero bytes to make it 32 bytes long.
-
-   Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.3. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   MUST use special PKCS#1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
-   the right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).
-
-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
-   decrypting the ENCRYPTED-KEY-DATA field, check that these eight
-   padding bytes are 0x03. If they are not, the server SHOULD generate a
-   random value for SECRET-KEY-DATA, and continue the handshake (which
-   will eventually fail since the keys will not match).  Note that
-   reporting the error situation to the client could make the server
-   vulnerable to attacks described in [BLEI].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 87]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the finished messages, encryption keys, and MAC keys (see
-   Sections 7.4.9 and 6.3). By sending a correct finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using Diffie-Hellman
-   for key exchange. The server's public parameters are contained in the
-   server key exchange message and the client's are sent in the client
-   key exchange message. Eavesdroppers who do not know the private
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 88]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   values should not be able to find the Diffie-Hellman result (i.e. the
-   pre_master_secret).
-
-   Warning: Completely anonymous connections only provide protection
-   against passive eavesdropping. Unless an independent tamper-proof
-   channel is used to verify that the finished messages were not
-   replaced by an attacker, server authentication is required in
-   environments where active man-in-the-middle attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key. TLS
-   users desiring Perfect Forward Secrecy should use DHE cipher suites.
-   The damage done by exposure of a private key can be limited by
-   changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from all preceding handshake messages. These
-   handshake messages include the server certificate, which binds the
-   signature to the server, and ServerHello.random, which binds the
-   signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSA or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 89]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSA or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks. Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE cipher suites and generating a fresh DH private key (X) for each
-   handshake. If a suitable base (such as 2) is chosen, g^X mod p can be
-   computed very quickly, therefore the performance cost is minimized.
-   Additionally, using a fresh key for each handshake provides Perfect
-   Forward Secrecy. Implementations SHOULD generate a new X for each
-   handshake when using DHE cipher suites.
-
-   Because TLS allows the server to provide arbitrary DH groups, the
-   client should verify that the DH group is of suitable size as defined
-   by local policy. The client SHOULD also verify that the DH public
-   exponent appears to be of adequate size. [KEYSIZ] provides a useful
-   guide to the strength of various group sizes.  The server MAY choose
-   to assist the client by providing a known group, such as those
-   defined in [IKEALG] or [MODP]. These can be verified by simple
-   comparison.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new ENCRYPTED-
-   KEY-DATA message containing the same key (but with normal padding)
-   before the application specified wait threshold has expired. Altering
-   the padding of the least significant 8 bytes of the PKCS padding does
-   not impact security for the size of the signed hashes and RSA key
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 90]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   lengths used in the protocol, since this is essentially equivalent to
-   increasing the input block size by 8 bytes.
-
-F.1.3. Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC keys are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations.
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC key, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 91]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64 bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC keys. Similarly, the server-write and
-   client-write keys are independent, so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
-   Note: MAC keys may be larger than encryption keys, so messages can
-   remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-   [CBCATT] describes a chosen plaintext attack on TLS that depends on
-   knowing the IV for a record. Previous versions of TLS [TLS1.0] used
-   the CBC residue of the previous record as the IV and therefore
-   enabled this attack. This version uses an explicit IV in order to
-   protect against this attack.
-
-F.4. Security of Composite Cipher Modes
-
-   TLS secures transmitted application data via the use of symmetric
-   encryption and authentication functions defined in the negotiated
-   cipher suite.  The objective is to protect both the integrity and
-   confidentiality of the transmitted data from malicious actions by
-   active attackers in the network.  It turns out that the order in
-   which encryption and authentication functions are applied to the data
-   plays an important role for achieving this goal [ENCAUTH].
-
-   The most robust method, called encrypt-then-authenticate, first
-   applies encryption to the data and then applies a MAC to the
-   ciphertext.  This method ensures that the integrity and
-   confidentiality goals are obtained with ANY pair of encryption and
-   MAC functions, provided that the former is secure against chosen
-   plaintext attacks and that the MAC is secure against chosen-message
-   attacks.  TLS uses another method, called authenticate-then-encrypt,
-   in which first a MAC is computed on the plaintext and then the
-   concatenation of plaintext and MAC is encrypted.  This method has
-   been proven secure for CERTAIN combinations of encryption functions
-   and MAC functions, but it is not guaranteed to be secure in general.
-   In particular, it has been shown that there exist perfectly secure
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 92]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   encryption functions (secure even in the information-theoretic sense)
-   that combined with any secure MAC function, fail to provide the
-   confidentiality goal against an active attack.  Therefore, new cipher
-   suites and operation modes adopted into TLS need to be analyzed under
-   the authenticate-then-encrypt method to verify that they achieve the
-   stated integrity and confidentiality goals.
-
-   Currently, the security of the authenticate-then-encrypt method has
-   been proven for some important cases.  One is the case of stream
-   ciphers in which a computationally unpredictable pad of the length of
-   the message, plus the length of the MAC tag, is produced using a
-   pseudo-random generator and this pad is xor-ed with the concatenation
-   of plaintext and MAC tag.  The other is the case of CBC mode using a
-   secure block cipher.  In this case, security can be shown if one
-   applies one CBC encryption pass to the concatenation of plaintext and
-   MAC and uses a new, independent, and unpredictable IV for each new
-   pair of plaintext and MAC.  In versions of TLS prior to 1.1, CBC mode
-   was used properly EXCEPT that it used a predictable IV in the form of
-   the last block of the previous ciphertext.  This made TLS open to
-   chosen plaintext attacks.  This version of the protocol is immune to
-   those attacks.  For exact details in the encryption modes proven
-   secure, see [ENCAUTH].
-
-F.5 Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption. However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections. In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH] or ESP [ESP].
-
-F.6 Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 93]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   cryptographic functions should be used. Short public keys and
-   anonymous servers should be used with great caution. Implementations
-   and users must be careful when deciding which certificates and
-   certificate authorities are acceptable; a dishonest certificate
-   authority can do tremendous damage.
-
-Changes in This Version
-   [RFC Editor: Please delete this]
-
-   Clarified traffic analysis considerations
-
-   Added support for SHA-224 for signatures (though not for HMAC).
-
-   Consistent use of camelback style for references to messages (e.g.,
-   ServerHelloDone) in the text.
-
-   Changed "DSS" to "DSA" where we are referring to the algorithm.
-
-   Extensive editorial revisions from Alfred Hoenes.
-
-Normative References
-
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [3DES]   National Institute of Standards and Technology,
-            "Recommendation for the Triple Data Encryption Algorithm
-            (TDEA) Block Cipher", NIST Special Publication 800-67, May
-            2004.
-
-   [DSS]    NIST FIPS PUB 186-2, "Digital Signature Standard", National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, 2000.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-            Hashing for Message Authentication", RFC 2104, February
-            1997.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1]  J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-            (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
-            3447, February 2003.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
-            Public Key Infrastructure Certificate and Certificate
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 94]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-            Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-
-   [SCH]    B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, 2nd ed.", Published by John Wiley &
-            Sons, Inc. 1996.
-
-   [SHS]    NIST FIPS PUB 180-2, "Secure Hash Standard", National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, August 2002.
-
-   [REQ]    Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-            IANA Considerations Section in RFCs", BCP 25, RFC 2434,
-            October 1998.
-
-   [X680]    ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
-            Information technology - Abstract Syntax Notation One
-            (ASN.1): Specification of basic notation.
-
-   [X690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
-            Information technology - ASN.1 encoding Rules: Specification
-            of Basic Encoding Rules (BER), Canonical Encoding Rules
-            (CER) and Distinguished Encoding Rules (DER).
-
-Informative References
-
-   [AEAD]   Mcgrew, D., "An Interface and Algorithms for Authenticated
-            Encryption", RFC 5116, January 2008.
-
-   [AH]     Kent, S., and Atkinson, R., "IP Authentication Header", RFC
-            4302, December 2005.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1-12, 1998.
-
-   [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-            Problems and Countermeasures",
-            http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
-            "Password Interception in a SSL/TLS Channel", Advances in
-            Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 95]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   [CCM]    "NIST Special Publication 800-38C: The CCM Mode for
-            Authentication and Confidentiality",
-            http://csrc.nist.gov/publications/nistpubs/800-38C/
-            SP800-38C.pdf
-
-   [DES]    National Institute of Standards and Technology, "Data
-            Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-   [DSS-3]  NIST FIPS PUB 186-3 Draft, "Digital Signature Standard",
-            National Institute of Standards and Technology, U.S.
-            Department of Commerce, 2006.
-
-   [ECSDSA] American National Standards Institute, "Public Key
-            Cryptography for the Financial Services Industry: The
-            Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS
-            X9.62-2005, November 2005.
-
-   [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
-            for Protecting Communications (Or: How Secure is SSL?)",
-            Crypto 2001.
-
-   [ESP]    Kent, S., and Atkinson, R., "IP Encapsulating Security
-            Payload (ESP)", RFC 4303, December 2005.
-
-   [FI06]   Hal Finney, "Bleichenbacher's RSA signature forgery based on
-            implementation error", ietf-openpgp@imc.org mailing list, 27
-            August 2006, http://www.imc.org/ietf-openpgp/mail-
-            archive/msg14307.html.
-
-   [GCM]    "NIST Special Publication 800-38D DRAFT (June, 2007):
-            Recommendation for Block Cipher Modes of Operation:
-            Galois/Counter Mode (GCM) and GMAC"
-
-   [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the
-            Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December
-            2005.
-
-   [KEYSIZ] Orman, H., and Hoffman, P., "Determining Strengths For
-            Public Keys Used For Exchanging Symmetric Keys" RFC 3766,
-            April 2004.
-
-   [KPR03]  Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-            Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-            March 2003.
-
-   [MODP]   Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-            Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
-            3526, May 2003.
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 96]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard", version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard", version 1.5, November 1993.
-
-   [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
-            Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
-            Compression Methods", RFC 3749, May 2004.
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-            Wright, T., "Transport Layer Security (TLS) Extensions", RFC
-            4366, April 2006.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems",
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
-            120-126.
-
-   [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
-            RFC 1948, May 1996.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
-            Protocol", Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-            Attacks on the Diffie-Hellman Key Agreement Method for
-            S/MIME", RFC 2785, March 2000.
-
-   [TCP]    Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
-            September 1981.
-
-   [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
-            practical", USENIX Security Symposium 2003.
-
-   [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-            for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
-            Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
-            Suites for Transport Layer Security (TLS)", RFC 4492, May
-            2006.
-
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 97]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   [TLSEXT] Eastlake, D.E.,  "Transport Layer Security (TLS) Extensions:
-            Extension Definitions", January 2008, draft-ietf-tls-
-            rfc4366-bis-01.txt.
-
-   [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP keys for TLS
-            authentication", RFC 5081, November 2007.
-
-   [TLSPSK] Eronen, P., Tschofenig, H., "Pre-Shared Key Ciphersuites for
-            Transport Layer Security (TLS)", RFC 4279, December 2005.
-
-   [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
-            RFC 2246, January 1999.
-
-   [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version
-            1.1", RFC 4346, April, 2006.
-
-   [X501]   ITU-T Recommendation X.501: Information Technology - Open
-            Systems Interconnection - The Directory: Models, 1993.
-
-   [XDR]    Eisler, M., "External Data Representation Standard", STD 67,
-            RFC 4506, May 2006.
-
-Credits
-
-   Working Group Chairs
-
-   Eric Rescorla
-   EMail: ekr@networkresonance.com
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-
-
-   Editors
-
-   Tim Dierks                    Eric Rescorla
-   Independent                   Network Resonance, Inc.
-   EMail: tim@dierks.org         EMail: ekr@networkresonance.com
-
-
-   Other contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 98]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-   Nokia
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Alfred Hoenes
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   IBM
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-
-
-
-Dierks & Rescorla            Standards Track                   [Page 99]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-   <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla            Standards Track                  [Page 100]
-
-draft-ietf-tls-rfc4346-bis-10.txt  TLS                       March, 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Dierks & Rescorla            Standards Track                  [Page 101]
-
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4366-bis-00.txt b/doc/protocol/draft-ietf-tls-rfc4366-bis-00.txt
deleted file mode 100644
index 95ca602f22..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4366-bis-00.txt
+++ /dev/null
@@ -1,1276 +0,0 @@
-
-TLS Working Group                                    Donald Eastlake 3rd
-INTERNET-DRAFT                                     Motorola Laboratories
-Obsoletes: RFC 4366
-Updates: RFC 2246, RFC 4346
-Intended status: Proposed Standard
-Expires: Decmeber 2007                                         June 2007
-
-
-    Transport Layer Security (TLS) Extensions: Extension Definitions
-    --------- ----- -------- ----- ----------- --------- -----------
-                  <draft-ietf-tls-rfc4366-bis-00.txt>
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited.  Comments should be sent
-   to the TLS working group mailing list <tls@ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document provides documentation for existing specific TLS
-   extensions. It is a companion document for the TLS 1.2 specification,
-   draft-ietf-tls-rfc4346-bis-03.txt.
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                             [Page 1]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-Acknowledgements
-
-   This draft is based on material from RFC 4366 for which the authors
-   were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.
-   Wright.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Acknowledgements...........................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      1.1 Specific Extensions Covered............................3
-      1.2 Conventions Used in This Document......................4
-
-      3. Server Name Indication..................................5
-      4. Maximum Fragment Length Negotiation.....................6
-      5. Client Certificate URLs.................................7
-      6. Trusted CA Indication..................................10
-      7. Truncated HMAC.........................................11
-      8. Certificate Status Request.............................12
-
-      9. IANA Considerations....................................15
-      10. Security Considerations...............................15
-      10.1 Security Considerations for server_name..............15
-      10.2 Security Considerations for max_fragment_length......15
-      10.3 Security Considerations for client_certificate_url...16
-      10.4 Security Considerations for trusted_ca_keys..........17
-      10.5 Security Considerations for truncated_hmac...........17
-      10.6 Security Considerations for status_request...........18
-      11. Internationalization Considerations...................18
-
-      12. Normative References..................................19
-      13. Informative References................................19
-
-      Copyright, Disclaimer, and Additional IPR Provisions......21
-
-      Author's Address..........................................22
-      Expiration and File Name..................................22
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                             [Page 2]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-1. Introduction
-
-   The TLS (Transport Layer Security) Protocol Version 1.2 is specified
-   in [RFCTLS]. That specification includes the framework for extensions
-   to TLS, considerations in designing such extensions (see Section
-   7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of
-   new extension code points; however, it does not specify any
-   particular extensions other than CertHashTypes (see Section
-   7.4.1.4.1of [RFCTLS]).
-
-   This document provides the specifications for existing TLS
-   extensions. It is, for the most part, the mere adaptation and editing
-   of material from [RFC4366], which covered all aspects of TLS
-   extensions for TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346].
-
-
-
-1.1 Specific Extensions Covered
-
-   The extensions described here focus on extending the functionality
-   provided by the TLS protocol message formats. Other issues, such as
-   the addition of new cipher suites, are deferred.
-
-   Specifically, the extensions described in this document:
-
-   -  Allow TLS clients to provide to the TLS server the name of the
-      server they are contacting. This functionality is desirable in
-      order to facilitate secure connections to servers that host
-      multiple 'virtual' servers at a single underlying network address.
-
-   -  Allow TLS clients and servers to negotiate the maximum fragment
-      length to be sent. This functionality is desirable as a result of
-      memory constraints among some clients, and bandwidth constraints
-      among some access networks.
-
-   -  Allow TLS clients and servers to negotiate the use of client
-      certificate URLs. This functionality is desirable in order to
-      conserve memory on constrained clients.
-
-   -  Allow TLS clients to indicate to TLS servers which CA root keys
-      they possess. This functionality is desirable in order to prevent
-      multiple handshake failures involving TLS clients that are only
-      able to store a small number of CA root keys due to memory
-      limitations.
-
-   -  Allow TLS clients and servers to negotiate the use of truncated
-      MACs. This functionality is desirable in order to conserve
-      bandwidth in constrained access networks.
-
-   -  Allow TLS clients and servers to negotiate that the server sends
-
-
-Donald Eastlake 3rd                                             [Page 3]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-      the client certificate status information (e.g., an Online
-      Certificate Status Protocol (OCSP) [RFC2560] response) during a
-      TLS handshake. This functionality is desirable in order to avoid
-      sending a Certificate Revocation List (CRL) over a constrained
-      access network and therefore save bandwidth.
-
-   The extensions described in this document may be used by TLS clients
-   and servers. The extensions are designed to be backwards compatible,
-   meaning that TLS clients that support the extensions can talk to TLS
-   servers that do not support the extensions, and vice versa. The
-   document therefore updates TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346].
-
-
-
-1.2 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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                             [Page 4]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-3. Server Name Indication
-
-   TLS does not provide a mechanism for a client to tell a server the
-   name of the server it is contacting. It may be desirable for clients
-   to provide this information to facilitate secure connections to
-   servers that host multiple 'virtual' servers at a single underlying
-   network address.
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello. The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-      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;
-
-   Currently, the only server names supported are DNS hostnames;
-   however, this does not imply any dependency of TLS on DNS, and other
-   name types may be added in the future (by an RFC that updates this
-   document). TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client. The hostname is represented as a byte
-   string using UTF-8 encoding [RFC3629], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in Section 3.1
-   of [RFC3490] notwithstanding). If the server needs to match the
-   HostName against names that contain non-US-ASCII characters, it MUST
-   perform the conversion operation described in Section 4 of [RFC3490],
-   treating the HostName as a "query string" (i.e., the AllowUnassigned
-   flag MUST be set). Note that IDNA allows labels to be separated by
-   any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
-   therefore, servers MUST accept any of these characters as a label
-
-
-Donald Eastlake 3rd                                             [Page 5]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   separator. If the server only needs to match the HostName against
-   names containing exclusively ASCII characters, it MUST compare ASCII
-   names case-insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".
-
-   It is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension MAY use the information contained in the extension to guide
-   its selection of an appropriate certificate to return to the client,
-   and/or other aspects of security policy. In this event, the server
-   SHALL include an extension of type "server_name" in the (extended)
-   server hello. The "extension_data" field of this extension SHALL be
-   empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol and then upgrades to TLS, and if a server_name extension is
-   sent, then the extension SHOULD contain the same name that was
-   negotiated in the application protocol. If the server_name is
-   established in the TLS session handshake, the client SHOULD NOT
-   attempt to request a different server name at the application layer.
-
-
-
-4. Maximum Fragment Length Negotiation
-
-   Without this extension, TLS specifies a fixed maximum plaintext
-   fragment length of 2^14 bytes. It may be desirable for constrained
-   clients to negotiate a smaller maximum fragment length due to memory
-   limitations or bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello. The "extension_data" field of this extension SHALL
-   contain:
-
-      enum{
-          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-      } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length. The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-
-
-Donald Eastlake 3rd                                             [Page 6]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello. The
-   "extension_data" field of this extension SHALL contain a
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert. Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent. Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the
-   output of the record layer may be larger. For example, if the
-   negotiated length is 2^9=512, then for currently defined cipher
-   suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and
-   when null compression is used, the record layer output can be at most
-   793 bytes: 5 bytes of headers, 512 bytes of application data, 256
-   bytes of padding, and 20 bytes of MAC. This means that in this event
-   a TLS record layer peer receiving a TLS record layer message larger
-   than 793 bytes may discard the message and send a "record_overflow"
-   alert, without decrypting the message.
-
-
-
-5. Client Certificate URLs
-
-   Without this extension, TLS specifies that when client authentication
-   is performed, client certificates are sent by clients to servers
-   during the TLS handshake. It may be desirable for constrained clients
-   to send certificate URLs in place of certificates, so that they do
-   not need to store their certificates and can therefore save memory.
-
-   In order to negotiate sending certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-
-
-Donald Eastlake 3rd                                             [Page 7]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   (extended) client hello. The "extension_data" field of this extension
-   SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension MAY indicate that they are willing
-   to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello. The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message:
-
-      enum {
-          individual_certs(0), pkipath(1), (255)
-      } CertChainType;
-
-      enum {
-          false(0), true(1)
-      } Boolean;
-
-      struct {
-          CertChainType type;
-          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-      } CertificateURL;
-
-      struct {
-          opaque url<1..2^16-1>;
-          Boolean hash_present;
-          select (hash_present) {
-              case false: struct {};
-              case true: SHA1Hash;
-          } hash;
-      } URLAndOptionalHash;
-
-      opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-   When X.509 certificates are used, there are two possibilities:
-
-   -  If CertificateURL.type is "individual_certs", each URL refers to a
-   single DER-encoded X.509v3 certificate, with the URL for the client's
-   certificate first.
-
-
-
-Donald Eastlake 3rd                                             [Page 8]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   -  If CertificateURL.type is "pkipath", the list contains a single
-   URL referring to a DER-encoded certificate chain, using the type
-   PkiPath described in Section 8 of [RFCTLS].
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion either
-   is not present or is the SHA-1 hash of the certificate or certificate
-   chain (in the case of X.509 certificates, the DER-encoded certificate
-   or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [RFCTLS], Section 7.4.2), but opposite to the order in
-   which certificates are encoded in PkiPath. In either case, the self-
-   signed root certificate MAY be omitted from the chain, under the
-   assumption that the server must already possess it in order to
-   validate it.
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs and then process the
-   certificate chain as usual. A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-   for certificate URLs, and MAY support other schemes. Use of other
-   schemes than "http", "https", or "ftp" may create unexpected
-   problems.
-
-   If the protocol used is HTTP, then the HTTP server can be configured
-   to use the Cache-Control and Expires directives described in
-   [RFC2616] to specify whether and for how long certificates or
-   certificate chains should be cached.
-
-   The TLS server is not required to follow HTTP redirects when
-   retrieving the certificates or certificate chain. The URLs used in
-   this extension SHOULD therefore be chosen not to depend on such
-   redirects.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME-formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [RFC2585],
-   and when a chain of X.509v3 certificates is returned, the Content-
-   Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]).
-
-
-
-Donald Eastlake 3rd                                             [Page 9]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash. If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs. The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-
-
-6. Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello. The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-      struct {
-          TrustedAuthority trusted_authorities_list<0..2^16-1>;
-      } TrustedAuthorities;
-
-      struct {
-          IdentifierType identifier_type;
-          select (identifier_type) {
-              case pre_agreed: struct {};
-              case key_sha1_hash: SHA1Hash;
-              case x509_name: DistinguishedName;
-              case cert_sha1_hash: SHA1Hash;
-          } identifier;
-      } TrustedAuthority;
-
-      enum {
-          pre_agreed(0), key_sha1_hash(1), x509_name(2),
-          cert_sha1_hash(3), (255)
-      } IdentifierType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-
-Donald Eastlake 3rd                                            [Page 10]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses. Each CA root key is identified via either:
-
-   -  "pre_agreed": no CA root key identity supplied.
-
-   -  "key_sha1_hash": contains the SHA-1 hash of the CA root key. For
-      Digital Signature Algorithm (DSA) and Elliptic Curve Digital
-      Signature Algorithm (ECDSA) keys, this is the hash of the
-      "subjectPublicKey" value. For RSA keys, the hash is of the big-
-      endian byte string representation of the modulus without any
-      initial 0-valued bytes. (This copies the key hash formats deployed
-      in other environments.)
-
-   -  "x509_name": contains the DER-encoded X.509 DistinguishedName of
-      the CA.
-
-   -  "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
-      Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer (for example, if
-   a particular CA has multiple key pairs). However, here we assume this
-   is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension MAY use the information contained in the extension to guide
-   their selection of an appropriate certificate chain to return to the
-   client. In this event, the server SHALL include an extension of type
-   "trusted_ca_keys" in the (extended) server hello. The
-   "extension_data" field of this extension SHALL be empty.
-
-
-
-7. Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [RFC2104] to authenticate record layer
-   communications. In TLS, the entire output of the hash function is
-   used as the MAC tag. However, it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-
-
-Donald Eastlake 3rd                                            [Page 11]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   include an extension of type "truncated_hmac" in the extended client
-   hello. The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension MAY agree to use a truncated HMAC by including an extension
-   of type "truncated_hmac", with empty "extension_data", in the
-   extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect. It is strongly recommended that any new cipher
-   suites using other MACs consider the MAC size an integral part of the
-   cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters. Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [RFC2104]. That is, CipherSpec.hash_size is 10 bytes,
-   and only the first 10 bytes of the HMAC output are transmitted and
-   checked. Note that this extension does not affect the calculation of
-   the pseudo-random function (PRF) as part of handshaking or key
-   derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-
-
-8. Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [RFC2560] to check the validity of server certificates,
-   in order to avoid transmission of CRLs and therefore save bandwidth
-   on constrained networks. This extension allows for such information
-   to be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello. The "extension_data"
-   field of this extension SHALL contain "CertificateStatusRequest"
-   where:
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPStatusRequest;
-          } request;
-
-
-Donald Eastlake 3rd                                            [Page 12]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-      } CertificateStatusRequest;
-
-      enum { ocsp(1), (255) } CertificateStatusType;
-
-      struct {
-          ResponderID responder_id_list<0..2^16-1>;
-          Extensions  request_extensions;
-      } OCSPStatusRequest;
-
-      opaque ResponderID<1..2^16-1>;
-      opaque Extensions<0..2^16-1>;
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts. A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server, e.g., by prior arrangement. "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [RFC2560]. "Extensions" is imported from [RFC3280].  A
-   zero-length "request_extensions" value means that there are no
-   extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not
-   valid for the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-   Servers that receive a client hello containing the "status_request"
-   extension MAY return a suitable certificate status response to the
-   client along with their certificate. If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages). If a server returns a
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPResponse;
-          } response;
-
-
-Donald Eastlake 3rd                                            [Page 13]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-      } CertificateStatus;
-
-      opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [RFC2560]). Note that
-   only one OCSP response may be sent.
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response and receiving an OCSP response in
-   a "CertificateStatus" message MUST check the OCSP response and abort
-   the handshake if the response is not satisfactory.
-
-          certificate_unobtainable(111),        /* new */
-          unrecognized_name(112),               /* new */
-          bad_certificate_status_response(113), /* new */
-          bad_certificate_hash_value(114),      /* new */
-          (255)
-      } AlertDescription;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 14]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-9. IANA Considerations
-
-   IANA Considerations for TLS Extensions and the creation of a Registry
-   therefore are all covered in Section 12 of [RFCTLS]..
-
-
-
-10. Security Considerations
-
-   General Security Considerations for TLS Extensions are covered in
-   [RFCTLS]. Security Considerations for particular extensions specified
-   in this document are given below.
-
-   In general, implementers should continue to monitor the state of the
-   art and address any weaknesses identified.
-
-   Additional security considerations are described in the TLS 1.0 RFC
-   [RFC2246] and the TLS 1.1 RFC [RFC4346].
-
-
-
-10.1 Security Considerations for server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs. Apart from this, server_name does not appear to
-   introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur,
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS (in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed). It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-
-
-10.2 Security Considerations for max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages. However, that does not introduce any security
-   complications that are not already present in TLS, since TLS requires
-   implementations to be able to handle fragmented handshake messages.
-
-   Note that as described in Section 4, once a non-null cipher suite has
-
-
-Donald Eastlake 3rd                                            [Page 15]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   been activated, the effective maximum fragment length depends on the
-   cipher suite and compression method, as well as on the negotiated
-   max_fragment_length. This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-
-
-10.3 Security Considerations for client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes. The purpose of including
-   hashes and checking them against the retrieved certificate chain is
-   to ensure that the same property holds when this extension is used,
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances; for example, clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client. Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here. The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server's acting as a client in another URL protocol.
-   The server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some (possibly weird-looking) URL.
-
-   In general, this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw. It also introduces the possibility of denial of service attacks
-   in which an attacker makes many connections to the server, each of
-   which results in the server's attempting a connection to the target
-   of the attack.
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet. This could exacerbate the potential security and denial of
-
-
-Donald Eastlake 3rd                                            [Page 16]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   service problems described above, as well as allow the existence of
-   internal hosts to be confirmed when they would otherwise be hidden.
-
-   The detailed security concerns involved will depend on the URL
-   schemes supported by the server. In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server. In the case of HTTPS, loops and deadlocks may be created, and
-   this should be addressed. In the case of FTP, attacks arise that are
-   similar to FTP bounce attacks.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than be enabled by default.
-   It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled. Unusual protocols that offer limited security or whose
-   security is not well-understood SHOULD be avoided.
-
-   As discussed in [RFC3986], URLs that specify ports other than the
-   default may cause problems, as may very long URLs (which are more
-   likely to be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly. If a request using HTTP (or another caching protocol) goes
-   through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-
-
-10.4 Security Considerations for trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information. As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously. As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-
-
-10.5 Security Considerations for truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs. However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-   Note that the output length of a MAC need not be as long as the
-
-
-Donald Eastlake 3rd                                            [Page 17]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after all handshake
-   messages that affect extension parameters have been authenticated by
-   the hashes in the Finished messages, it is not possible for an active
-   attacker to force negotiation of the truncated HMAC extension where
-   it would not otherwise be used (to the extent that the handshake
-   authentication is secure). Therefore, in the event that any security
-   problem were found with truncated HMAC in the future, if either the
-   client or the server for a given session were updated to take the
-   problem into account, it would be able to veto use of this extension.
-
-
-
-10.6 Security Considerations for status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension. In this case, a client
-   that requires OCSP validation of certificates SHOULD either contact
-   the OCSP server directly or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see Section 4.4.1 of [RFC2560] for further details.
-
-
-
-11. Internationalization Considerations
-
-   None of the extensions defined here directly use strings subject to
-   localization. Domain Name System (DNS) hostnames are encoded using
-   UTF-8. If future extensions use text strings, then
-   internationalization should be considered in their design.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 18]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-12. Normative References
-
-   [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-   Hashing for Message Authentication", RFC 2104, February 1997.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-   RFC 2246, January 1999.
-
-   [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
-   Adams, "X.509 Internet Public Key Infrastructure Online Certificate
-   Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
-   Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May
-   1999.
-
-   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
-   L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
-   HTTP/1.1", RFC 2616, June 1999.
-
-   [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-   X.509 Public Key Infrastructure Certificate and Certificate
-   Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
-   "Internationalizing Domain Names in Applications (IDNA)", RFC 3490,
-   March 2003.
-
-   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
-   STD 63, RFC 3629, November 2003.
-
-   [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-   Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January
-   2005.
-
-   [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
-   (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",
-   draft-ietf-tls-rfc4346-bis-03.txt, March 2007.
-
-
-
-13. Informative References
-
-   [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-   Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-
-Donald Eastlake 3rd                                            [Page 19]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-   for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-   and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,
-   April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 20]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 21]
-
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-Author's Address
-
-   Donald Eastlake 3rd
-   Motorola Laboratories
-   111 Locke Drive
-   Marlborough, MA 01752
-
-   Tel:   +1-508-786-7554
-   Email: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in December 2007.
-
-   Its file name is draft-ietf-tls-rfc4366-bis-00.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 22]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4366-bis-01.txt b/doc/protocol/draft-ietf-tls-rfc4366-bis-01.txt
deleted file mode 100644
index 367d6667f3..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4366-bis-01.txt
+++ /dev/null
@@ -1,1254 +0,0 @@
-TLS Working Group                                    Donald Eastlake 3rd
-INTERNET-DRAFT                                     Motorola Laboratories
-Obsoletes: RFC 4366
-Updates: RFC 2246, RFC 4346
-Intended status: Proposed Standard
-Expires: July 2008                                      January 14, 2009
-
-
-    Transport Layer Security (TLS) Extensions: Extension Definitions
-
-                  <draft-ietf-tls-rfc4366-bis-01.txt>
-
-
-Status of This Document
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited.  Comments should be sent
-   to the TLS working group mailing list <tls@ietf.org>.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document provides documentation for existing specific TLS
-   extensions. It is a companion document for the TLS 1.2 specification,
-   draft-ietf-tls-rfc4346-bis-07.txt.
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                             [Page 1]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-Acknowledgements
-
-   This draft is based on material from RFC 4366 for which the authors
-   were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.
-   Wright.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Acknowledgements...........................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      1.1 Specific Extensions Covered............................3
-      1.2 Conventions Used in This Document......................4
-
-      3. Server Name Indication..................................5
-      4. Maximum Fragment Length Negotiation.....................6
-      5. Client Certificate URLs.................................7
-      6. Trusted CA Indication..................................10
-      7. Truncated HMAC.........................................11
-      8. Certificate Status Request.............................12
-
-      9. IANA Considerations....................................15
-      10. Security Considerations...............................15
-      10.1 Security Considerations for server_name..............15
-      10.2 Security Considerations for max_fragment_length......15
-      10.3 Security Considerations for client_certificate_url...16
-      10.4 Security Considerations for trusted_ca_keys..........17
-      10.5 Security Considerations for truncated_hmac...........17
-      10.6 Security Considerations for status_request...........18
-      11. Internationalization Considerations...................18
-
-      12. Normative References..................................19
-      13. Informative References................................19
-
-      Copyright, Disclaimer, and Additional IPR Provisions......21
-
-      Author's Address..........................................22
-      Expiration and File Name..................................22
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                             [Page 2]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-1. Introduction
-
-   The TLS (Transport Layer Security) Protocol Version 1.2 is specified
-   in [RFCTLS]. That specification includes the framework for extensions
-   to TLS, considerations in designing such extensions (see Section
-   7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of
-   new extension code points; however, it does not specify any
-   particular extensions other than CertHashTypes (see Section
-   7.4.1.4.1of [RFCTLS]).
-
-   This document provides the specifications for existing TLS
-   extensions. It is, for the most part, the mere adaptation and editing
-   of material from [RFC4366], which covered all aspects of TLS
-   extensions for TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346].
-
-
-
-1.1 Specific Extensions Covered
-
-   The extensions described here focus on extending the functionality
-   provided by the TLS protocol message formats. Other issues, such as
-   the addition of new cipher suites, are deferred.
-
-   Specifically, the extensions described in this document:
-
-   -  Allow TLS clients to provide to the TLS server the name of the
-      server they are contacting. This functionality is desirable in
-      order to facilitate secure connections to servers that host
-      multiple 'virtual' servers at a single underlying network address.
-
-   -  Allow TLS clients and servers to negotiate the maximum fragment
-      length to be sent. This functionality is desirable as a result of
-      memory constraints among some clients, and bandwidth constraints
-      among some access networks.
-
-   -  Allow TLS clients and servers to negotiate the use of client
-      certificate URLs. This functionality is desirable in order to
-      conserve memory on constrained clients.
-
-   -  Allow TLS clients to indicate to TLS servers which CA root keys
-      they possess. This functionality is desirable in order to prevent
-      multiple handshake failures involving TLS clients that are only
-      able to store a small number of CA root keys due to memory
-      limitations.
-
-   -  Allow TLS clients and servers to negotiate the use of truncated
-      MACs. This functionality is desirable in order to conserve
-      bandwidth in constrained access networks.
-
-   -  Allow TLS clients and servers to negotiate that the server sends
-
-
-Donald Eastlake 3rd                                             [Page 3]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-      the client certificate status information (e.g., an Online
-      Certificate Status Protocol (OCSP) [RFC2560] response) during a
-      TLS handshake. This functionality is desirable in order to avoid
-      sending a Certificate Revocation List (CRL) over a constrained
-      access network and therefore save bandwidth.
-
-   The extensions described in this document may be used by TLS clients
-   and servers. The extensions are designed to be backwards compatible,
-   meaning that TLS clients that support the extensions can talk to TLS
-   servers that do not support the extensions, and vice versa. The
-   document therefore updates TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346].
-
-
-
-1.2 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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                             [Page 4]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-3. Server Name Indication
-
-   TLS does not provide a mechanism for a client to tell a server the
-   name of the server it is contacting. It may be desirable for clients
-   to provide this information to facilitate secure connections to
-   servers that host multiple 'virtual' servers at a single underlying
-   network address.
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello. The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-      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;
-
-   Currently, the only server names supported are DNS hostnames;
-   however, this does not imply any dependency of TLS on DNS, and other
-   name types may be added in the future (by an RFC that updates this
-   document). TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client. The hostname is represented as a byte
-   string using UTF-8 encoding [RFC3629], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in Section 3.1
-   of [RFC3490] notwithstanding). If the server needs to match the
-   HostName against names that contain non-US-ASCII characters, it MUST
-   perform the conversion operation described in Section 4 of [RFC3490],
-   treating the HostName as a "query string" (i.e., the AllowUnassigned
-   flag MUST be set). Note that IDNA allows labels to be separated by
-   any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
-   therefore, servers MUST accept any of these characters as a label
-
-
-Donald Eastlake 3rd                                             [Page 5]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   separator. If the server only needs to match the HostName against
-   names containing exclusively ASCII characters, it MUST compare ASCII
-   names case-insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".
-
-   It is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension MAY use the information contained in the extension to guide
-   its selection of an appropriate certificate to return to the client,
-   and/or other aspects of security policy. In this event, the server
-   SHALL include an extension of type "server_name" in the (extended)
-   server hello. The "extension_data" field of this extension SHALL be
-   empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol and then upgrades to TLS, and if a server_name extension is
-   sent, then the extension SHOULD contain the same name that was
-   negotiated in the application protocol. If the server_name is
-   established in the TLS session handshake, the client SHOULD NOT
-   attempt to request a different server name at the application layer.
-
-
-
-4. Maximum Fragment Length Negotiation
-
-   Without this extension, TLS specifies a fixed maximum plaintext
-   fragment length of 2^14 bytes. It may be desirable for constrained
-   clients to negotiate a smaller maximum fragment length due to memory
-   limitations or bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello. The "extension_data" field of this extension SHALL
-   contain:
-
-      enum{
-          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-      } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length. The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-
-
-Donald Eastlake 3rd                                             [Page 6]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello. The
-   "extension_data" field of this extension SHALL contain a
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert. Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent. Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the
-   output of the record layer may be larger. For example, if the
-   negotiated length is 2^9=512, then for currently defined cipher
-   suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and
-   when null compression is used, the record layer output can be at most
-   793 bytes: 5 bytes of headers, 512 bytes of application data, 256
-   bytes of padding, and 20 bytes of MAC. This means that in this event
-   a TLS record layer peer receiving a TLS record layer message larger
-   than 793 bytes may discard the message and send a "record_overflow"
-   alert, without decrypting the message.
-
-
-
-5. Client Certificate URLs
-
-   Without this extension, TLS specifies that when client authentication
-   is performed, client certificates are sent by clients to servers
-   during the TLS handshake. It may be desirable for constrained clients
-   to send certificate URLs in place of certificates, so that they do
-   not need to store their certificates and can therefore save memory.
-
-   In order to negotiate sending certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-
-
-Donald Eastlake 3rd                                             [Page 7]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   (extended) client hello. The "extension_data" field of this extension
-   SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension MAY indicate that they are willing
-   to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello. The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message:
-
-      enum {
-          individual_certs(0), pkipath(1), (255)
-      } CertChainType;
-
-      enum {
-          false(0), true(1)
-      } Boolean;
-
-      struct {
-          CertChainType type;
-          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-      } CertificateURL;
-
-      struct {
-          opaque url<1..2^16-1>;
-          Boolean hash_present;
-          select (hash_present) {
-              case false: struct {};
-              case true: SHA1Hash;
-          } hash;
-      } URLAndOptionalHash;
-
-      opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-   When X.509 certificates are used, there are two possibilities:
-
-   -  If CertificateURL.type is "individual_certs", each URL refers to a
-   single DER-encoded X.509v3 certificate, with the URL for the client's
-   certificate first.
-
-
-
-Donald Eastlake 3rd                                             [Page 8]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   -  If CertificateURL.type is "pkipath", the list contains a single
-   URL referring to a DER-encoded certificate chain, using the type
-   PkiPath described in Section 8 of [RFCTLS].
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion either
-   is not present or is the SHA-1 hash of the certificate or certificate
-   chain (in the case of X.509 certificates, the DER-encoded certificate
-   or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [RFCTLS], Section 7.4.2), but opposite to the order in
-   which certificates are encoded in PkiPath. In either case, the self-
-   signed root certificate MAY be omitted from the chain, under the
-   assumption that the server must already possess it in order to
-   validate it.
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs and then process the
-   certificate chain as usual. A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-   for certificate URLs, and MAY support other schemes. Use of other
-   schemes than "http", "https", or "ftp" may create unexpected
-   problems.
-
-   If the protocol used is HTTP, then the HTTP server can be configured
-   to use the Cache-Control and Expires directives described in
-   [RFC2616] to specify whether and for how long certificates or
-   certificate chains should be cached.
-
-   The TLS server is not required to follow HTTP redirects when
-   retrieving the certificates or certificate chain. The URLs used in
-   this extension SHOULD therefore be chosen not to depend on such
-   redirects.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME-formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [RFC2585],
-   and when a chain of X.509v3 certificates is returned, the Content-
-   Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]).
-
-
-
-Donald Eastlake 3rd                                             [Page 9]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash. If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs. The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-
-
-6. Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello. The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-      struct {
-          TrustedAuthority trusted_authorities_list<0..2^16-1>;
-      } TrustedAuthorities;
-
-      struct {
-          IdentifierType identifier_type;
-          select (identifier_type) {
-              case pre_agreed: struct {};
-              case key_sha1_hash: SHA1Hash;
-              case x509_name: DistinguishedName;
-              case cert_sha1_hash: SHA1Hash;
-          } identifier;
-      } TrustedAuthority;
-
-      enum {
-          pre_agreed(0), key_sha1_hash(1), x509_name(2),
-          cert_sha1_hash(3), (255)
-      } IdentifierType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-
-Donald Eastlake 3rd                                            [Page 10]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses. Each CA root key is identified via either:
-
-   -  "pre_agreed": no CA root key identity supplied.
-
-   -  "key_sha1_hash": contains the SHA-1 hash of the CA root key. For
-      Digital Signature Algorithm (DSA) and Elliptic Curve Digital
-      Signature Algorithm (ECDSA) keys, this is the hash of the
-      "subjectPublicKey" value. For RSA keys, the hash is of the big-
-      endian byte string representation of the modulus without any
-      initial 0-valued bytes. (This copies the key hash formats deployed
-      in other environments.)
-
-   -  "x509_name": contains the DER-encoded X.509 DistinguishedName of
-      the CA.
-
-   -  "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
-      Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer (for example, if
-   a particular CA has multiple key pairs). However, here we assume this
-   is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension MAY use the information contained in the extension to guide
-   their selection of an appropriate certificate chain to return to the
-   client. In this event, the server SHALL include an extension of type
-   "trusted_ca_keys" in the (extended) server hello. The
-   "extension_data" field of this extension SHALL be empty.
-
-
-
-7. Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [RFC2104] to authenticate record layer
-   communications. In TLS, the entire output of the hash function is
-   used as the MAC tag. However, it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-
-
-Donald Eastlake 3rd                                            [Page 11]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   include an extension of type "truncated_hmac" in the extended client
-   hello. The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension MAY agree to use a truncated HMAC by including an extension
-   of type "truncated_hmac", with empty "extension_data", in the
-   extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect. It is strongly recommended that any new cipher
-   suites using other MACs consider the MAC size an integral part of the
-   cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters. Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [RFC2104]. That is, CipherSpec.hash_size is 10 bytes,
-   and only the first 10 bytes of the HMAC output are transmitted and
-   checked. Note that this extension does not affect the calculation of
-   the pseudo-random function (PRF) as part of handshaking or key
-   derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-
-
-8. Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [RFC2560] to check the validity of server certificates,
-   in order to avoid transmission of CRLs and therefore save bandwidth
-   on constrained networks. This extension allows for such information
-   to be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello. The "extension_data"
-   field of this extension SHALL contain "CertificateStatusRequest"
-   where:
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPStatusRequest;
-          } request;
-
-
-Donald Eastlake 3rd                                            [Page 12]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-      } CertificateStatusRequest;
-
-      enum { ocsp(1), (255) } CertificateStatusType;
-
-      struct {
-          ResponderID responder_id_list<0..2^16-1>;
-          Extensions  request_extensions;
-      } OCSPStatusRequest;
-
-      opaque ResponderID<1..2^16-1>;
-      opaque Extensions<0..2^16-1>;
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts. A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server, e.g., by prior arrangement. "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [RFC2560]. "Extensions" is imported from [RFC3280].  A
-   zero-length "request_extensions" value means that there are no
-   extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not
-   valid for the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-   Servers that receive a client hello containing the "status_request"
-   extension MAY return a suitable certificate status response to the
-   client along with their certificate. If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages). If a server returns a
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPResponse;
-          } response;
-
-
-Donald Eastlake 3rd                                            [Page 13]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-      } CertificateStatus;
-
-      opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [RFC2560]). Note that
-   only one OCSP response may be sent.
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response and receiving an OCSP response in
-   a "CertificateStatus" message MUST check the OCSP response and abort
-   the handshake if the response is not satisfactory.
-
-          certificate_unobtainable(111),        /* new */
-          unrecognized_name(112),               /* new */
-          bad_certificate_status_response(113), /* new */
-          bad_certificate_hash_value(114),      /* new */
-          (255)
-      } AlertDescription;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 14]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-9. IANA Considerations
-
-   IANA Considerations for TLS Extensions and the creation of a Registry
-   therefore are all covered in Section 12 of [RFCTLS]..
-
-
-
-10. Security Considerations
-
-   General Security Considerations for TLS Extensions are covered in
-   [RFCTLS]. Security Considerations for particular extensions specified
-   in this document are given below.
-
-   In general, implementers should continue to monitor the state of the
-   art and address any weaknesses identified.
-
-   Additional security considerations are described in the TLS 1.0 RFC
-   [RFC2246] and the TLS 1.1 RFC [RFC4346].
-
-
-
-10.1 Security Considerations for server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs. Apart from this, server_name does not appear to
-   introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur,
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS (in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed). It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-
-
-10.2 Security Considerations for max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages. However, that does not introduce any security
-   complications that are not already present in TLS, since TLS requires
-   implementations to be able to handle fragmented handshake messages.
-
-   Note that as described in Section 4, once a non-null cipher suite has
-
-
-Donald Eastlake 3rd                                            [Page 15]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   been activated, the effective maximum fragment length depends on the
-   cipher suite and compression method, as well as on the negotiated
-   max_fragment_length. This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-
-
-10.3 Security Considerations for client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes. The purpose of including
-   hashes and checking them against the retrieved certificate chain is
-   to ensure that the same property holds when this extension is used,
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances; for example, clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client. Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here. The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server's acting as a client in another URL protocol.
-   The server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some (possibly weird-looking) URL.
-
-   In general, this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw. It also introduces the possibility of denial of service attacks
-   in which an attacker makes many connections to the server, each of
-   which results in the server's attempting a connection to the target
-   of the attack.
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet. This could exacerbate the potential security and denial of
-
-
-Donald Eastlake 3rd                                            [Page 16]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   service problems described above, as well as allow the existence of
-   internal hosts to be confirmed when they would otherwise be hidden.
-
-   The detailed security concerns involved will depend on the URL
-   schemes supported by the server. In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server. In the case of HTTPS, loops and deadlocks may be created, and
-   this should be addressed. In the case of FTP, attacks arise that are
-   similar to FTP bounce attacks.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than be enabled by default.
-   It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled. Unusual protocols that offer limited security or whose
-   security is not well-understood SHOULD be avoided.
-
-   As discussed in [RFC3986], URLs that specify ports other than the
-   default may cause problems, as may very long URLs (which are more
-   likely to be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly. If a request using HTTP (or another caching protocol) goes
-   through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-
-
-10.4 Security Considerations for trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information. As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously. As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-
-
-10.5 Security Considerations for truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs. However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-   Note that the output length of a MAC need not be as long as the
-
-
-Donald Eastlake 3rd                                            [Page 17]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after all handshake
-   messages that affect extension parameters have been authenticated by
-   the hashes in the Finished messages, it is not possible for an active
-   attacker to force negotiation of the truncated HMAC extension where
-   it would not otherwise be used (to the extent that the handshake
-   authentication is secure). Therefore, in the event that any security
-   problem were found with truncated HMAC in the future, if either the
-   client or the server for a given session were updated to take the
-   problem into account, it would be able to veto use of this extension.
-
-
-
-10.6 Security Considerations for status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension. In this case, a client
-   that requires OCSP validation of certificates SHOULD either contact
-   the OCSP server directly or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see Section 4.4.1 of [RFC2560] for further details.
-
-
-
-11. Internationalization Considerations
-
-   None of the extensions defined here directly use strings subject to
-   localization. Domain Name System (DNS) hostnames are encoded using
-   UTF-8. If future extensions use text strings, then
-   internationalization should be considered in their design.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 18]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-12. Normative References
-
-   [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-   Hashing for Message Authentication", RFC 2104, February 1997.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
-   Adams, "X.509 Internet Public Key Infrastructure Online Certificate
-   Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
-   Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May
-   1999.
-
-   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
-   L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
-   HTTP/1.1", RFC 2616, June 1999.
-
-   [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-   X.509 Public Key Infrastructure Certificate and Certificate
-   Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
-   "Internationalizing Domain Names in Applications (IDNA)", RFC 3490,
-   March 2003.
-
-   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
-   STD 63, RFC 3629, November 2003.
-
-   [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-   Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January
-   2005.
-
-   [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
-   (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",
-   draft-ietf-tls-rfc4346-bis-*.txt, March 2007.
-
-
-
-13. Informative References
-
-   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-   RFC 2246, January 1999.
-
-   [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-   Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
-
-
-Donald Eastlake 3rd                                            [Page 19]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-   [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
-   for Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-   and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,
-   April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 20]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 21]
-
-INTERNET-DRAFT                                 TLS Extension Definitions
-
-
-Author's Address
-
-   Donald Eastlake 3rd
-   Motorola Laboratories
-   111 Locke Drive
-   Marlborough, MA 01752
-
-   Tel:   +1-508-786-7554
-   Email: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in July 2008.
-
-   Its file name is draft-ietf-tls-rfc4366-bis-01.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd                                            [Page 22]
-
diff --git a/doc/protocol/draft-ietf-tls-rfc4366-bis-02.txt b/doc/protocol/draft-ietf-tls-rfc4366-bis-02.txt
deleted file mode 100644
index 943d4121e6..0000000000
--- a/doc/protocol/draft-ietf-tls-rfc4366-bis-02.txt
+++ /dev/null
@@ -1,1312 +0,0 @@
-

-TLS Working Group                                    Donald Eastlake 3rd

-INTERNET-DRAFT                                     Motorola Laboratories

-Obsoletes: RFC 4366

-Intended status: Proposed Standard

-Expires: August 2008                                   February 20, 2008

-

-

-    Transport Layer Security (TLS) Extensions: Extension Definitions

-

-                  <draft-ietf-tls-rfc4366-bis-02.txt>

-

-

-Status of This Document

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   Distribution of this document is unlimited.  Comments should be sent

-   to the TLS working group mailing list <tls@ietf.org>.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups.  Note that

-   other groups may also distribute working documents as Internet-

-   Drafts.

-

-   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/1id-abstracts.html

-

-   The list of Internet-Draft Shadow Directories can be accessed at

-   http://www.ietf.org/shadow.html

-

-

-Abstract

-

-   This document provides documentation for existing specific TLS

-   extensions. It is a companion document for the TLS 1.2 specification,

-   draft-ietf-tls-rfc4346-bis-07.txt.

-

-

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                             [Page 1]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-Acknowledgements

-

-   This draft is based on material from RFC 4366 for which the authors

-   were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.

-   Wright.

-

-

-

-Table of Contents

-

-      Status of This Document....................................1

-      Abstract...................................................1

-

-      Acknowledgements...........................................2

-      Table of Contents..........................................2

-

-      1. Introduction............................................3

-      1.1 Specific Extensions Covered............................3

-      1.2 Conventions Used in This Document......................4

-

-      2. Extensions to the Handshake Protocol....................5

-

-      3. Server Name Indication..................................6

-      4. Maximum Fragment Length Negotiation.....................7

-      5. Client Certificate URLs.................................8

-      6. Trusted CA Indication..................................11

-      7. Truncated HMAC.........................................12

-      8. Certificate Status Request.............................13

-

-      9. Error Alerts...........................................16

-

-      10. IANA Considerations...................................17

-      11. Security Considerations...............................17

-      11.1 Security Considerations for server_name..............17

-      11.2 Security Considerations for max_fragment_length......17

-      11.3 Security Considerations for client_certificate_url...18

-      11.4 Security Considerations for trusted_ca_keys..........19

-      11.5 Security Considerations for truncated_hmac...........19

-      11.6 Security Considerations for status_request...........20

-

-      12. Normative References..................................21

-      13. Informative References................................21

-

-      Copyright, Disclaimer, and Additional IPR Provisions......22

-

-      Author's Address..........................................23

-      Expiration and File Name..................................23

-

-

-

-

-

-Donald Eastlake 3rd                                             [Page 2]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-1. Introduction

-

-   The TLS (Transport Layer Security) Protocol Version 1.2 is specified

-   in [RFCTLS]. That specification includes the framework for extensions

-   to TLS, considerations in designing such extensions (see Section

-   7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of

-   new extension code points; however, it does not specify any

-   particular extensions other than Signature Algorithms (see Section

-   7.4.1.4.1 of [RFCTLS]).

-

-   This document provides the specifications for existing TLS

-   extensions. It is, for the most part, the adaptation and editing of

-   material from [RFC4366], which covered TLS extensions for TLS 1.0

-   [RFC2246] and TLS 1.1 [RFC4346].

-

-

-

-1.1 Specific Extensions Covered

-

-   The extensions described here focus on extending the functionality

-   provided by the TLS protocol message formats. Other issues, such as

-   the addition of new cipher suites, are deferred.

-

-   Specifically, the extensions described in this document:

-

-   -  Allow TLS clients to provide to the TLS server the name of the

-      server they are contacting. This functionality is desirable in

-      order to facilitate secure connections to servers that host

-      multiple 'virtual' servers at a single underlying network address.

-

-   -  Allow TLS clients and servers to negotiate the maximum fragment

-      length to be sent. This functionality is desirable as a result of

-      memory constraints among some clients, and bandwidth constraints

-      among some access networks.

-

-   -  Allow TLS clients and servers to negotiate the use of client

-      certificate URLs. This functionality is desirable in order to

-      conserve memory on constrained clients.

-

-   -  Allow TLS clients to indicate to TLS servers which CA root keys

-      they possess. This functionality is desirable in order to prevent

-      multiple handshake failures involving TLS clients that are only

-      able to store a small number of CA root keys due to memory

-      limitations.

-

-   -  Allow TLS clients and servers to negotiate the use of truncated

-      MACs. This functionality is desirable in order to conserve

-      bandwidth in constrained access networks.

-

-   -  Allow TLS clients and servers to negotiate that the server sends

-

-

-Donald Eastlake 3rd                                             [Page 3]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-      the client certificate status information (e.g., an Online

-      Certificate Status Protocol (OCSP) [RFC2560] response) during a

-      TLS handshake. This functionality is desirable in order to avoid

-      sending a Certificate Revocation List (CRL) over a constrained

-      access network and therefore save bandwidth.

-

-   The extensions described in this document may be used by TLS clients

-   and servers. The extensions are designed to be backwards compatible,

-   meaning that TLS clients that support the extensions can talk to TLS

-   servers that do not support the extensions, and vice versa.

-

-

-

-1.2 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 [RFC2119].

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                             [Page 4]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-2. Extensions to the Handshake Protocol

-

-   This document specifies the use of two new handshake messages,

-   "CertificateURL" and "CertificateStatus".  These messages are

-   described in Section 5 and Section 8, respectively.  The new

-   handshake message structure therefore becomes:

-

-      enum {

-          hello_request(0), client_hello(1), server_hello(2),

-          certificate(11), server_key_exchange (12),

-          certificate_request(13), server_hello_done(14),

-          certificate_verify(15), client_key_exchange(16),

-          finished(20), certificate_url(21), certificate_status(22),

-          (255)

-      } HandshakeType;

-

-      struct {

-          HandshakeType msg_type;    /* handshake type */

-          uint24 length;             /* bytes in message */

-          select (HandshakeType) {

-              case hello_request:       HelloRequest;

-              case client_hello:        ClientHello;

-              case server_hello:        ServerHello;

-              case certificate:         Certificate;

-              case server_key_exchange: ServerKeyExchange;

-              case certificate_request: CertificateRequest;

-              case server_hello_done:   ServerHelloDone;

-              case certificate_verify:  CertificateVerify;

-              case client_key_exchange: ClientKeyExchange;

-              case finished:            Finished;

-              case certificate_url:     CertificateURL;

-              case certificate_status:  CertificateStatus;

-          } body;

-      } Handshake;

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                             [Page 5]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-3. Server Name Indication

-

-   TLS does not provide a mechanism for a client to tell a server the

-   name of the server it is contacting. It may be desirable for clients

-   to provide this information to facilitate secure connections to

-   servers that host multiple 'virtual' servers at a single underlying

-   network address.

-

-   In order to provide the server name, clients MAY include an extension

-   of type "server_name" in the (extended) client hello. The

-   "extension_data" field of this extension SHALL contain

-   "ServerNameList" where:

-

-      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;

-

-   If the server understood the client hello extension but does not

-   recognize any of the server names, it SHOULD send an

-   unrecognized_name(112) alert (which MAY be fatal).

-

-   Currently, the only server names supported are DNS hostnames;

-   however, this does not imply any dependency of TLS on DNS, and other

-   name types may be added in the future (by an RFC that updates this

-   document). TLS MAY treat provided server names as opaque data and

-   pass the names and types to the application.

-

-   "HostName" contains the fully qualified DNS hostname of the server,

-   as understood by the client. The hostname is represented as a byte

-   string using ASCII encoding without a trailing dot.

-

-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".

-

-   It is RECOMMENDED that clients include an extension of type

-   "server_name" in the client hello whenever they locate a server by a

-   supported name type.

-

-

-

-Donald Eastlake 3rd                                             [Page 6]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   A server that receives a client hello containing the "server_name"

-   extension MAY use the information contained in the extension to guide

-   its selection of an appropriate certificate to return to the client,

-   and/or other aspects of security policy. In this event, the server

-   SHALL include an extension of type "server_name" in the (extended)

-   server hello. The "extension_data" field of this extension SHALL be

-   empty.

-

-   If the server understood the client hello extension but does not

-   recognize the server name, it SHOULD send an "unrecognized_name"

-   alert (which MAY be fatal).

-

-   If an application negotiates a server name using an application

-   protocol and then upgrades to TLS, and if a server_name extension is

-   sent, then the extension SHOULD contain the same name that was

-   negotiated in the application protocol. If the server_name is

-   established in the TLS session handshake, the client SHOULD NOT

-   attempt to request a different server name at the application layer.

-

-

-

-4. Maximum Fragment Length Negotiation

-

-   Without this extension, TLS specifies a fixed maximum plaintext

-   fragment length of 2^14 bytes. It may be desirable for constrained

-   clients to negotiate a smaller maximum fragment length due to memory

-   limitations or bandwidth limitations.

-

-   In order to negotiate smaller maximum fragment lengths, clients MAY

-   include an extension of type "max_fragment_length" in the (extended)

-   client hello. The "extension_data" field of this extension SHALL

-   contain:

-

-      enum{

-          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)

-      } MaxFragmentLength;

-

-   whose value is the desired maximum fragment length. The allowed

-   values for this field are: 2^9, 2^10, 2^11, and 2^12.

-

-   Servers that receive an extended client hello containing a

-   "max_fragment_length" extension MAY accept the requested maximum

-   fragment length by including an extension of type

-   "max_fragment_length" in the (extended) server hello. The

-   "extension_data" field of this extension SHALL contain a

-   "MaxFragmentLength" whose value is the same as the requested maximum

-   fragment length.

-

-   If a server receives a maximum fragment length negotiation request

-   for a value other than the allowed values, it MUST abort the

-

-

-Donald Eastlake 3rd                                             [Page 7]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   handshake with an "illegal_parameter" alert. Similarly, if a client

-   receives a maximum fragment length negotiation response that differs

-   from the length it requested, it MUST also abort the handshake with

-   an "illegal_parameter" alert.

-

-   Once a maximum fragment length other than 2^14 has been successfully

-   negotiated, the client and server MUST immediately begin fragmenting

-   messages (including handshake messages), to ensure that no fragment

-   larger than the negotiated length is sent. Note that TLS already

-   requires clients and servers to support fragmentation of handshake

-   messages.

-

-   The negotiated length applies for the duration of the session

-   including session resumptions.

-

-   The negotiated length limits the input that the record layer may

-   process without fragmentation (that is, the maximum value of

-   TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the

-   output of the record layer may be larger. For example, if the

-   negotiated length is 2^9=512, then for currently defined cipher

-   suites (those defined in [RFCTLS], [RFC2712], and [RFC3268]), and

-   when null compression is used, the record layer output can be at most

-   805 bytes: 5 bytes of headers, 512 bytes of application data, 256

-   bytes of padding, and 32 bytes of MAC. This means that in this event

-   a TLS record layer peer receiving a TLS record layer message larger

-   than 805 bytes may discard the message and send a "record_overflow"

-   alert, without decrypting the message.

-

-

-

-5. Client Certificate URLs

-

-   Without this extension, TLS specifies that when client authentication

-   is performed, client certificates are sent by clients to servers

-   during the TLS handshake. It may be desirable for constrained clients

-   to send certificate URLs in place of certificates, so that they do

-   not need to store their certificates and can therefore save memory.

-

-   In order to negotiate sending certificate URLs to a server, clients

-   MAY include an extension of type "client_certificate_url" in the

-   (extended) client hello. The "extension_data" field of this extension

-   SHALL be empty.

-

-   (Note that it is necessary to negotiate use of client certificate

-   URLs in order to avoid "breaking" existing TLS servers.)

-

-   Servers that receive an extended client hello containing a

-   "client_certificate_url" extension MAY indicate that they are willing

-   to accept certificate URLs by including an extension of type

-   "client_certificate_url" in the (extended) server hello. The

-

-

-Donald Eastlake 3rd                                             [Page 8]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   "extension_data" field of this extension SHALL be empty.

-

-   After negotiation of the use of client certificate URLs has been

-   successfully completed (by exchanging hellos including

-   "client_certificate_url" extensions), clients MAY send a

-   "CertificateURL" message in place of a "Certificate" message as

-   follows (see also Section 2):

-

-      enum {

-          individual_certs(0), pkipath(1), (255)

-      } CertChainType;

-

-      enum {

-          false(0), true(1)

-      } Boolean;

-

-      struct {

-          CertChainType type;

-          URLAndOptionalHash url_and_hash_list<1..2^16-1>;

-      } CertificateURL;

-

-      struct {

-          opaque url<1..2^16-1>;

-          Boolean hash_present;

-          select (hash_present) {

-              case false: struct {};

-              case true: SHA1Hash;

-          } hash;

-      } URLAndOptionalHash;

-

-      opaque SHA1Hash[20];

-

-   Here "url_and_hash_list" contains a sequence of URLs and optional

-   hashes.

-

-   When X.509 certificates are used, there are two possibilities:

-

-   -  If CertificateURL.type is "individual_certs", each URL refers to a

-   single DER-encoded X.509v3 certificate, with the URL for the client's

-   certificate first.

-

-   -  If CertificateURL.type is "pkipath", the list contains a single

-   URL referring to a DER-encoded certificate chain, using the type

-   PkiPath described in Section 8 of [RFCTLS].

-

-   When any other certificate format is used, the specification that

-   describes use of that format in TLS should define the encoding format

-   of certificates or certificate chains, and any constraint on their

-   ordering.

-

-

-

-Donald Eastlake 3rd                                             [Page 9]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   The hash corresponding to each URL at the client's discretion either

-   is not present or is the SHA-1 hash of the certificate or certificate

-   chain (in the case of X.509 certificates, the DER-encoded certificate

-   or the DER-encoded PkiPath).

-

-   Note that when a list of URLs for X.509 certificates is used, the

-   ordering of URLs is the same as that used in the TLS Certificate

-   message (see [RFCTLS], Section 7.4.2), but opposite to the order in

-   which certificates are encoded in PkiPath. In either case, the self-

-   signed root certificate MAY be omitted from the chain, under the

-   assumption that the server must already possess it in order to

-   validate it.

-

-   Servers receiving "CertificateURL" SHALL attempt to retrieve the

-   client's certificate chain from the URLs and then process the

-   certificate chain as usual. A cached copy of the content of any URL

-   in the chain MAY be used, provided that a SHA-1 hash is present for

-   that URL and it matches the hash of the cached copy.

-

-   Servers that support this extension MUST support the http: URL scheme

-   for certificate URLs, and MAY support other schemes. Use of other

-   schemes than "http", "https", or "ftp" may create unexpected

-   problems.

-

-   If the protocol used is HTTP, then the HTTP server can be configured

-   to use the Cache-Control and Expires directives described in

-   [RFC2616] to specify whether and for how long certificates or

-   certificate chains should be cached.

-

-   The TLS server is not required to follow HTTP redirects when

-   retrieving the certificates or certificate chain. The URLs used in

-   this extension SHOULD therefore be chosen not to depend on such

-   redirects.

-

-   If the protocol used to retrieve certificates or certificate chains

-   returns a MIME-formatted response (as HTTP does), then the following

-   MIME Content-Types SHALL be used: when a single X.509v3 certificate

-   is returned, the Content-Type is "application/pkix-cert" [RFC2585],

-   and when a chain of X.509v3 certificates is returned, the Content-

-   Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]).

-

-   If a SHA-1 hash is present for an URL, then the server MUST check

-   that the SHA-1 hash of the contents of the object retrieved from that

-   URL (after decoding any MIME Content-Transfer-Encoding) matches the

-   given hash. If any retrieved object does not have the correct SHA-1

-   hash, the server MUST abort the handshake with a

-   bad_certificate_hash_value(114) alert. This alert is always fatal.

-

-   Clients may choose to send either "Certificate" or "CertificateURL"

-   after successfully negotiating the option to send certificate URLs.

-

-

-Donald Eastlake 3rd                                            [Page 10]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   The option to send a certificate is included to provide flexibility

-   to clients possessing multiple certificates.

-

-   If a server encounters an unreasonable delay in obtaining

-   certificates in a given CertificateURL, it SHOULD time out and signal

-   a certificate_unobtainable(111) error alert. This alert MAY be fatal;

-   for example, if client authentication is required by the server for

-   the handshake to continue.

-

-

-

-6. Trusted CA Indication

-

-   Constrained clients that, due to memory limitations, possess only a

-   small number of CA root keys may wish to indicate to servers which

-   root keys they possess, in order to avoid repeated handshake

-   failures.

-

-   In order to indicate which CA root keys they possess, clients MAY

-   include an extension of type "trusted_ca_keys" in the (extended)

-   client hello. The "extension_data" field of this extension SHALL

-   contain "TrustedAuthorities" where:

-

-      struct {

-          TrustedAuthority trusted_authorities_list<0..2^16-1>;

-      } TrustedAuthorities;

-

-      struct {

-          IdentifierType identifier_type;

-          select (identifier_type) {

-              case pre_agreed: struct {};

-              case key_sha1_hash: SHA1Hash;

-              case x509_name: DistinguishedName;

-              case cert_sha1_hash: SHA1Hash;

-          } identifier;

-      } TrustedAuthority;

-

-      enum {

-          pre_agreed(0), key_sha1_hash(1), x509_name(2),

-          cert_sha1_hash(3), (255)

-      } IdentifierType;

-

-      opaque DistinguishedName<1..2^16-1>;

-

-   Here "TrustedAuthorities" provides a list of CA root key identifiers

-   that the client possesses. Each CA root key is identified via either:

-

-   -  "pre_agreed": no CA root key identity supplied.

-

-   -  "key_sha1_hash": contains the SHA-1 hash of the CA root key. For

-

-

-Donald Eastlake 3rd                                            [Page 11]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-      Digital Signature Algorithm (DSA) and Elliptic Curve Digital

-      Signature Algorithm (ECDSA) keys, this is the hash of the

-      "subjectPublicKey" value. For RSA keys, the hash is of the big-

-      endian byte string representation of the modulus without any

-      initial 0-valued bytes. (This copies the key hash formats deployed

-      in other environments.)

-

-   -  "x509_name": contains the DER-encoded X.509 DistinguishedName of

-      the CA.

-

-   -  "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded

-      Certificate containing the CA root key.

-

-   Note that clients may include none, some, or all of the CA root keys

-   they possess in this extension.

-

-   Note also that it is possible that a key hash or a Distinguished Name

-   alone may not uniquely identify a certificate issuer (for example, if

-   a particular CA has multiple key pairs). However, here we assume this

-   is the case following the use of Distinguished Names to identify

-   certificate issuers in TLS.

-

-   The option to include no CA root keys is included to allow the client

-   to indicate possession of some pre-defined set of CA root keys.

-

-   Servers that receive a client hello containing the "trusted_ca_keys"

-   extension MAY use the information contained in the extension to guide

-   their selection of an appropriate certificate chain to return to the

-   client. In this event, the server SHALL include an extension of type

-   "trusted_ca_keys" in the (extended) server hello. The

-   "extension_data" field of this extension SHALL be empty.

-

-

-

-7. Truncated HMAC

-

-   Currently defined TLS cipher suites use the MAC construction HMAC

-   with either MD5 or SHA-1 [RFC2104] to authenticate record layer

-   communications. In TLS, the entire output of the hash function is

-   used as the MAC tag. However, it may be desirable in constrained

-   environments to save bandwidth by truncating the output of the hash

-   function to 80 bits when forming MAC tags.

-

-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY

-   include an extension of type "truncated_hmac" in the extended client

-   hello. The "extension_data" field of this extension SHALL be empty.

-

-   Servers that receive an extended hello containing a "truncated_hmac"

-   extension MAY agree to use a truncated HMAC by including an extension

-   of type "truncated_hmac", with empty "extension_data", in the

-

-

-Donald Eastlake 3rd                                            [Page 12]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   extended server hello.

-

-   Note that if new cipher suites are added that do not use HMAC, and

-   the session negotiates one of these cipher suites, this extension

-   will have no effect. It is strongly recommended that any new cipher

-   suites using other MACs consider the MAC size an integral part of the

-   cipher suite definition, taking into account both security and

-   bandwidth considerations.

-

-   If HMAC truncation has been successfully negotiated during a TLS

-   handshake, and the negotiated cipher suite uses HMAC, both the client

-   and the server pass this fact to the TLS record layer along with the

-   other negotiated security parameters. Subsequently during the

-   session, clients and servers MUST use truncated HMACs, calculated as

-   specified in [RFC2104]. That is, SecurityParameters.mac_length is 10

-   bytes, and only the first 10 bytes of the HMAC output are transmitted

-   and checked. Note that this extension does not affect the calculation

-   of the pseudo-random function (PRF) as part of handshaking or key

-   derivation.

-

-   The negotiated HMAC truncation size applies for the duration of the

-   session including session resumptions.

-

-

-

-8. Certificate Status Request

-

-   Constrained clients may wish to use a certificate-status protocol

-   such as OCSP [RFC2560] to check the validity of server certificates,

-   in order to avoid transmission of CRLs and therefore save bandwidth

-   on constrained networks. This extension allows for such information

-   to be sent in the TLS handshake, saving roundtrips and resources.

-

-   In order to indicate their desire to receive certificate status

-   information, clients MAY include an extension of type

-   "status_request" in the (extended) client hello. The "extension_data"

-   field of this extension SHALL contain "CertificateStatusRequest"

-   where:

-

-      struct {

-          CertificateStatusType status_type;

-          select (status_type) {

-              case ocsp: OCSPStatusRequest;

-          } request;

-      } CertificateStatusRequest;

-

-      enum { ocsp(1), (255) } CertificateStatusType;

-

-      struct {

-          ResponderID responder_id_list<0..2^16-1>;

-

-

-Donald Eastlake 3rd                                            [Page 13]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-          Extensions  request_extensions;

-      } OCSPStatusRequest;

-

-      opaque ResponderID<1..2^16-1>;

-      opaque Extensions<0..2^16-1>;

-

-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP

-   responders that the client trusts. A zero-length "responder_id_list"

-   sequence has the special meaning that the responders are implicitly

-   known to the server, e.g., by prior arrangement. "Extensions" is a

-   DER encoding of OCSP request extensions.

-

-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as

-   defined in [RFC2560]. "Extensions" is imported from [RFC3280].  A

-   zero-length "request_extensions" value means that there are no

-   extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not

-   valid for the "Extensions" type).

-

-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is

-   unclear about its encoding; for clarification, the nonce MUST be a

-   DER-encoded OCTET STRING, which is encapsulated as another OCTET

-   STRING (note that implementations based on an existing OCSP client

-   will need to be checked for conformance to this requirement).

-

-   Servers that receive a client hello containing the "status_request"

-   extension MAY return a suitable certificate status response to the

-   client along with their certificate. If OCSP is requested, they

-   SHOULD use the information contained in the extension when selecting

-   an OCSP responder and SHOULD include request_extensions in the OCSP

-   request.

-

-   Servers return a certificate response along with their certificate by

-   sending a "CertificateStatus" message immediately after the

-   "Certificate" message (and before any "ServerKeyExchange" or

-   "CertificateRequest" messages). If a server returns a

-   "CertificateStatus" message, then the server MUST have included an

-   extension of type "status_request" with empty "extension_data" in the

-   extended server hello. The "CertificateStatus" message is conveyed

-   using the handshake message type "certificate_status" as follows (see

-   also Section 2):

-

-      struct {

-          CertificateStatusType status_type;

-          select (status_type) {

-              case ocsp: OCSPResponse;

-          } response;

-      } CertificateStatus;

-

-      opaque OCSPResponse<1..2^24-1>;

-

-

-

-Donald Eastlake 3rd                                            [Page 14]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   An "ocsp_response" contains a complete, DER-encoded OCSP response

-   (using the ASN.1 type OCSPResponse defined in [RFC2560]).  Only one

-   OCSP response may be sent.

-

-   Note that a server MAY also choose not to send a "CertificateStatus"

-   message, even if it receives a "status_request" extension in the

-   client hello message.

-

-   Note in addition that servers MUST NOT send the "CertificateStatus"

-   message unless it received a "status_request" extension in the client

-   hello message.

-

-   Clients requesting an OCSP response and receiving an OCSP response in

-   a "CertificateStatus" message MUST check the OCSP response and abort

-   the handshake if the response is not satisfactory with

-   bad_certificate_status_response(113) alert. This alert is always

-   fatal.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                            [Page 15]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-9. Error Alerts

-

-   This section defines new error alerts for use with the TLS extensions

-   defined in this document.

-

-   Four new error alerts are defined.  To avoid "breaking" existing

-   clients and servers, these alerts MUST NOT be sent unless the sending

-   party has received an extended hello message from the party they are

-   communicating with.  These error alerts are conveyed using the

-   following syntax:

-

-      enum {

-          close_notify(0),

-          unexpected_message(10),

-          bad_record_mac(20),

-          decryption_failed(21),

-          record_overflow(22),

-          decompression_failure(30),

-          handshake_failure(40),

-          /* 41 is not defined, for historical reasons */

-          bad_certificate(42),

-          unsupported_certificate(43),

-          certificate_revoked(44),

-          certificate_expired(45),

-          certificate_unknown(46),

-          illegal_parameter(47),

-          unknown_ca(48),

-          access_denied(49),

-          decode_error(50),

-          decrypt_error(51),

-          export_restriction(60),

-          protocol_version(70),

-          insufficient_security(71),

-          internal_error(80),

-          user_canceled(90),

-          no_renegotiation(100),

-          unsupported_extension(110),

-          certificate_unobtainable(111),        /* new */

-          unrecognized_name(112),               /* new */

-          bad_certificate_status_response(113), /* new */

-          bad_certificate_hash_value(114),      /* new */

-          (255)

-      } AlertDescription;

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                            [Page 16]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-10. IANA Considerations

-

-   IANA Considerations for TLS Extensions and the creation of a Registry

-   therefore are all covered in Section 12 of [RFCTLS]..

-

-

-

-11. Security Considerations

-

-   General Security Considerations for TLS Extensions are covered in

-   [RFCTLS]. Security Considerations for particular extensions specified

-   in this document are given below.

-

-   In general, implementers should continue to monitor the state of the

-   art and address any weaknesses identified.

-

-   Additional security considerations are described in the TLS 1.0 RFC

-   [RFC2246] and the TLS 1.1 RFC [RFC4346].

-

-

-

-11.1 Security Considerations for server_name

-

-   If a single server hosts several domains, then clearly it is

-   necessary for the owners of each domain to ensure that this satisfies

-   their security needs. Apart from this, server_name does not appear to

-   introduce significant security issues.

-

-   Implementations MUST ensure that a buffer overflow does not occur,

-   whatever the values of the length fields in server_name.

-

-   Although this document specifies an encoding for internationalized

-   hostnames in the server_name extension, it does not address any

-   security issues associated with the use of internationalized

-   hostnames in TLS (in particular, the consequences of "spoofed" names

-   that are indistinguishable from another name when displayed or

-   printed). It is recommended that server certificates not be issued

-   for internationalized hostnames unless procedures are in place to

-   mitigate the risk of spoofed hostnames.

-

-

-

-11.2 Security Considerations for max_fragment_length

-

-   The maximum fragment length takes effect immediately, including for

-   handshake messages. However, that does not introduce any security

-   complications that are not already present in TLS, since TLS requires

-   implementations to be able to handle fragmented handshake messages.

-

-   Note that as described in Section 4, once a non-null cipher suite has

-

-

-Donald Eastlake 3rd                                            [Page 17]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   been activated, the effective maximum fragment length depends on the

-   cipher suite and compression method, as well as on the negotiated

-   max_fragment_length. This must be taken into account when sizing

-   buffers, and checking for buffer overflow.

-

-

-

-11.3 Security Considerations for client_certificate_url

-

-   There are two major issues with this extension.

-

-   The first major issue is whether or not clients should include

-   certificate hashes when they send certificate URLs.

-

-   When client authentication is used *without* the

-   client_certificate_url extension, the client certificate chain is

-   covered by the Finished message hashes. The purpose of including

-   hashes and checking them against the retrieved certificate chain is

-   to ensure that the same property holds when this extension is used,

-   i.e., that all of the information in the certificate chain retrieved

-   by the server is as the client intended.

-

-   On the other hand, omitting certificate hashes enables functionality

-   that is desirable in some circumstances; for example, clients can be

-   issued daily certificates that are stored at a fixed URL and need not

-   be provided to the client. Clients that choose to omit certificate

-   hashes should be aware of the possibility of an attack in which the

-   attacker obtains a valid certificate on the client's key that is

-   different from the certificate the client intended to provide.

-   Although TLS uses both MD5 and SHA-1 hashes in several other places,

-   this was not believed to be necessary here. The property required of

-   SHA-1 is second pre-image resistance.

-

-   The second major issue is that support for client_certificate_url

-   involves the server's acting as a client in another URL protocol.

-   The server therefore becomes subject to many of the same security

-   concerns that clients of the URL scheme are subject to, with the

-   added concern that the client can attempt to prompt the server to

-   connect to some (possibly weird-looking) URL.

-

-   In general, this issue means that an attacker might use the server to

-   indirectly attack another host that is vulnerable to some security

-   flaw. It also introduces the possibility of denial of service attacks

-   in which an attacker makes many connections to the server, each of

-   which results in the server's attempting a connection to the target

-   of the attack.

-

-   Note that the server may be behind a firewall or otherwise able to

-   access hosts that would not be directly accessible from the public

-   Internet. This could exacerbate the potential security and denial of

-

-

-Donald Eastlake 3rd                                            [Page 18]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   service problems described above, as well as allow the existence of

-   internal hosts to be confirmed when they would otherwise be hidden.

-

-   The detailed security concerns involved will depend on the URL

-   schemes supported by the server. In the case of HTTP, the concerns

-   are similar to those that apply to a publicly accessible HTTP proxy

-   server. In the case of HTTPS, loops and deadlocks may be created, and

-   this should be addressed. In the case of FTP, attacks arise that are

-   similar to FTP bounce attacks.

-

-   As a result of this issue, it is RECOMMENDED that the

-   client_certificate_url extension should have to be specifically

-   enabled by a server administrator, rather than be enabled by default.

-   It is also RECOMMENDED that URI protocols be enabled by the

-   administrator individually, and only a minimal set of protocols be

-   enabled. Unusual protocols that offer limited security or whose

-   security is not well-understood SHOULD be avoided.

-

-   As discussed in [RFC3986], URLs that specify ports other than the

-   default may cause problems, as may very long URLs (which are more

-   likely to be useful in exploiting buffer overflow bugs).

-

-   Also note that HTTP caching proxies are common on the Internet, and

-   some proxies do not check for the latest version of an object

-   correctly. If a request using HTTP (or another caching protocol) goes

-   through a misconfigured or otherwise broken proxy, the proxy may

-   return an out-of-date response.

-

-

-

-11.4 Security Considerations for trusted_ca_keys

-

-   It is possible that which CA root keys a client possesses could be

-   regarded as confidential information. As a result, the CA root key

-   indication extension should be used with care.

-

-   The use of the SHA-1 certificate hash alternative ensures that each

-   certificate is specified unambiguously. As for the previous

-   extension, it was not believed necessary to use both MD5 and SHA-1

-   hashes.

-

-

-

-11.5 Security Considerations for truncated_hmac

-

-   It is possible that truncated MACs are weaker than "un-truncated"

-   MACs. However, no significant weaknesses are currently known or

-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.

-

-   Note that the output length of a MAC need not be as long as the

-

-

-Donald Eastlake 3rd                                            [Page 19]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-   length of a symmetric cipher key, since forging of MAC values cannot

-   be done off-line: in TLS, a single failed MAC guess will cause the

-   immediate termination of the TLS session.

-

-   Since the MAC algorithm only takes effect after all handshake

-   messages that affect extension parameters have been authenticated by

-   the hashes in the Finished messages, it is not possible for an active

-   attacker to force negotiation of the truncated HMAC extension where

-   it would not otherwise be used (to the extent that the handshake

-   authentication is secure). Therefore, in the event that any security

-   problem were found with truncated HMAC in the future, if either the

-   client or the server for a given session were updated to take the

-   problem into account, it would be able to veto use of this extension.

-

-

-

-11.6 Security Considerations for status_request

-

-   If a client requests an OCSP response, it must take into account that

-   an attacker's server using a compromised key could (and probably

-   would) pretend not to support the extension. In this case, a client

-   that requires OCSP validation of certificates SHOULD either contact

-   the OCSP server directly or abort the handshake.

-

-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may

-   improve security against attacks that attempt to replay OCSP

-   responses; see Section 4.4.1 of [RFC2560] for further details.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                            [Page 20]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-12. Normative References

-

-   [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-

-   Hashing for Message Authentication", RFC 2104, February 1997.

-

-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

-   Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.

-   Adams, "X.509 Internet Public Key Infrastructure Online Certificate

-   Status Protocol - OCSP", RFC 2560, June 1999.

-

-   [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key

-   Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May

-   1999.

-

-   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,

-   L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --

-   HTTP/1.1", RFC 2616, June 1999.

-

-   [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet

-   X.509 Public Key Infrastructure Certificate and Certificate

-   Revocation List (CRL) Profile", RFC 3280, April 2002.

-

-   [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform

-   Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January

-   2005.

-

-   [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security

-   (TLS) Protocol Version 1.1", RFC 4346, April 2006.

-

-   [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2",

-   draft-ietf-tls-rfc4346-bis-*.txt, March 2007.

-

-

-

-13. Informative References

-

-   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",

-   RFC 2246, January 1999.

-

-   [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher

-   Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.

-

-   [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites

-   for Transport Layer Security (TLS)", RFC 3268, June 2002.

-

-   [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,

-   and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,

-   April 2006.

-

-

-Donald Eastlake 3rd                                            [Page 21]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-Copyright, Disclaimer, and Additional IPR Provisions

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at ietf-

-   ipr@ietf.org.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                            [Page 22]

-

-INTERNET-DRAFT                                 TLS Extension Definitions

-

-

-Author's Address

-

-   Donald Eastlake 3rd

-   Motorola Laboratories

-   111 Locke Drive

-   Marlborough, MA 01752

-

-   Tel:   +1-508-786-7554

-   Email: Donald.Eastlake@motorola.com

-

-

-

-Expiration and File Name

-

-   This draft expires in August 2008.

-

-   Its file name is draft-ietf-tls-rfc4366-bis-02.txt.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Donald Eastlake 3rd                                            [Page 23]

-

diff --git a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-00.txt b/doc/protocol/draft-ietf-tls-rsa-aes-gcm-00.txt
deleted file mode 100644
index 39660f558f..0000000000
--- a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-00.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-TLS Working Group                                             J. Salowey
-Internet-Draft                                              A. Choudhury
-Intended status: Standards Track                               D. McGrew
-Expires: December 20, 2007                           Cisco Systems, Inc.
-                                                           June 18, 2007
-
-
-                RSA based AES-GCM Cipher Suites for TLS
-                     draft-ietf-tls-rsa-aes-gcm-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 20, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This memo describes the use of the Advanced Encryption Standard (AES)
-   in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
-   authenticated encryption operation.  GCM provides both
-   confidentiality and data origin authentication, can be efficiently
-   implemented in hardware for speeds of 10 gigabits per second and
-   above, and is also well-suited to software implementations.  This
-   memo defines TLS ciphersuites that use AES-GCM with RSA.
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 1]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-
-   3.  RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3
-
-   4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 5
-
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-     6.1.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6
-     6.2.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6
-
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 2]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-1.  Introduction
-
-   This document describes the use of AES [AES]in Galois Counter Mode
-   (GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite
-   for TLS.  This mechanism is not only efficient and secure, hardware
-   implementations can achieve high speeds with low cost and low
-   latency, because the mode can be pipelined.  Applications like
-   CAPWAP, which uses DTLS, can benefit from the high-speed
-   implementations when wireless termination points (WTPs) and
-   controllers (ACs) have to meet requirements to support higher
-   throughputs in the future.  AES-GCM has been specified as a mode that
-   can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security
-   [IEEE8021AE].  It also is part of the NSA suite B ciphersuites for
-   TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B
-   requirements these ciphersuites require ECC base key exchange and TLS
-   1.2.  The ciphersuites defined in this document are based on RSA
-   which allows the use of AES-GCM in environments that have not
-   deployed ECC algorithms and do not need to meet NSA Suite B
-   requirements.  AES-GCM is an authenticated encryption with associated
-   data (AEAD) operation, as used in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
-   The ciphersuites defined in this draft may be used with DTLS defined
-   in [RFC4347] and [I-D.ietf-tls-ecc-new-mac].  This memo uses GCM in a
-   way similar to [I-D.rescorla-tls-suiteb].
-
-
-2.  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 [RFC2119]
-
-
-3.  RSA Based AES-GCM Cipher Suites
-
-   The ciphersuites defined in this document are based on the the AES-
-   GCM authenticated encryption with associated data (AEAD) algorithms
-   AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  Note that this specification uses a 128-bit
-   authentication tag with GCM.  The following ciphersuites are defined:
-
-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
-      CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
-      CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
-
-   The "nonce" SHALL be 12 bytes long and it is "partially implicit"
-   (see section 3.2.1 in [I-D.mcgrew-auth-enc]); that is, part of the
-   nonce is explicitly carried in each packet, and part of the nonce is
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 3]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-   implicit.  The nonce is constructed from a salt and an explicit
-   Counter, sent as part of the packet, as follows:
-
-             Struct{
-                opaque salt[4];
-                opaque explicit_nonce_part[8];
-             } GCMNonce
-
-   The salt is the "implicit" part of the nonce and is not sent in the
-   packet.  It is either the client_write_IV if the client is sending or
-   the server_write_IV if the server is sending.  These IVs SHALL be 4
-   bytes long.
-
-   The explicit_nonce_part is chosen by the sender and included in the
-   packet.  Each value of the explicit_nonce_part MUST be distinct for
-   each distinct invocation of GCM encrypt function using a particular
-   fixed key.  Failure to meet this uniqueness requirement can
-   significantly degrade security.  The explicit_nonce_part is carried
-   in the IV field of the GenericAEADCipher structure.  Therefore, for
-   all the algorithms defined in this section,
-   SecurityParameters.iv_length=8.
-
-   In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence
-   number.  In the case of DTLS the explicit_nonce_part MAY be the 16-
-   bit epoch with the concatenated 48-bit DTLS seq_num.
-
-   If multiple cryptographic processors are in use by the sender, then
-   the sender MUST ensure that each value of the explicit_nonce_part
-   that is used by each processor is distinct.  In this case each
-   encryption processor SHOULD include in the explicit_nonce_part a a
-   fixed value that is distinct for each processor.  The recommended
-   format is
-
-        explicit_nonce_part = FixedDistinct || Variable
-
-   where the FixedDistinct field is distinct for each encryption
-   processor, but is fixed for a given processor, and the Variable field
-   is distinct for each distinct nonce used by a particular encryption
-   processor.  When this method is used, the FixedDistinct fields used
-   by the different processors MUST have the same length.
-
-   In the terms of Figure 2 in [I-D.mcgrew-auth-enc], the Salt is the
-   Fixed-Common part of the nonce (it is fixed, and it is common across
-   all encryption processors), the FixedDistinct field exactly
-   corresponds to the Fixed-Distinct field, and the Variable field
-   corresponds to the Counter field, and the explicit part exactly
-   corresponds to the explicit_nonce_part.
-
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 4]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-   For clarity, we provide an example for TLS in which there are two
-   distinct encryption processors, each of which uses a one-byte
-   FixedDistinct field:
-
-          Salt          = eedc68dc
-          FixedDistinct = 01       (for the first encryption processor)
-          FixedDistinct = 02       (for the second encryption processor)
-
-   The GCMnonces generated by the first encryption processor, and their
-   corresponding explicit_nonce_parts, are:
-
-          GCMNonce                    explicit_nonce_part
-          ------------------------    ----------------------------
-          eedc68dc0100000000000000    0100000000000000
-          eedc68dc0100000000000001    0100000000000001
-          eedc68dc0100000000000002    0100000000000002
-          ...
-
-   The GCMnonces generated by the second encryption processor, and their
-   corresponding explicit_nonce_parts, are
-
-          GCMNonce                    explicit_nonce_part
-          ------------------------    ----------------------------
-          eedc68dc0200000000000000    0200000000000000
-          eedc68dc0200000000000001    0200000000000001
-          eedc68dc0200000000000002    0200000000000002
-          ...
-
-
-   The RSA and RSA-DHE key exchange is performed as defined in
-   [I-D.ietf-tls-rfc4346-bis].
-
-   Recall that an AEAD operation replaces the use of HMAC as a MAC, but
-   not as a PRF for the purposes of key derivation.  Consequently, the
-   hash function for the TLS PRF must be explicitly specified by the
-   ciphersuite.  The PRF algorithms SHALL be as follows:
-
-   For TLS_RSA_WITH_AES_128_GCM_SHA256 and
-   TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256.
-
-   For TLS_RSA_WITH_AES_256_GCM_SHA384 and
-   TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
-
-
-4.  TLS Versions
-
-   These ciphersuites make use of the authenticated encryption with
-   additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 5]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-   MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT
-   offer these cipher suites if they do not offer TLS 1.2 or later.
-   Servers which select an earlier version of TLS MUST NOT select one of
-   these cipher suites.  Because TLS has no way for the client to
-   indicate that it supports TLS 1.2 but not earlier, a non-compliant
-   server might potentially negotiate TLS 1.1 or earlier and select one
-   of the cipher suites in this document.  Clients MUST check the TLS
-   version and generate a fatal "illegal_parameter" alert if they detect
-   an incorrect version.
-
-
-5.  IANA Considerations
-
-   IANA has assigned the following values for the ciphersuites defined
-   in this draft:
-
-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
-      CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
-      CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
-
-
-6.  Security Considerations
-
-6.1.  Perfect Forward Secrecy
-
-   The perfect forward secrecy properties of RSA based TLS ciphersuites
-   are discussed in the security analysis of [RFC4346].  It should be
-   noted that only the ephemeral Diffie-Hellman based ciphersuites are
-   capable of providing perfect forward secrecy.
-
-6.2.  Counter Reuse
-
-   AES-GCM security requires that the counter is never reused.  The IV
-   construction in Section 3 is designed to prevent counter reuse.
-
-
-7.  Acknowledgements
-
-   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac] and
-   [I-D.rescorla-tls-suiteb]
-
-
-8.  References
-
-
-
-
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 6]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-8.1.  Normative References
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, April 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
-              March 2007.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-02 (work in progress),
-              March 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-8.2.  Informative References
-
-   [I-D.ietf-tls-ecc-new-mac]
-              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-              256/384 and AES Galois Counter  Mode",
-              draft-ietf-tls-ecc-new-mac-01 (work in progress),
-              June 2007.
-
-   [I-D.rescorla-tls-suiteb]
-              Salter, M. and E. Rescorla, "Suite B Cipher Suites for
-              TLS", draft-rescorla-tls-suiteb-01 (work in progress),
-              June 2007.
-
-   [IEEE8021AE]
-              Institute of Electrical and Electronics Engineers, "Media
-              Access Control Security", IEEE Standard 802.1AE,
-              August 2006.
-
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 7]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
-              (GCM) in IPsec Encapsulating Security Payload (ESP)",
-              RFC 4106, June 2005.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems, Inc.
-   2901 3rd. Ave
-   Seattle, WA  98121
-   USA
-
-   Email: jsalowey@cisco.com
-
-
-   Abhijit Choudhury
-   Cisco Systems, Inc.
-   3625 Cisco Way
-   San Jose, CA  95134
-   USA
-
-   Email: abhijitc@cisco.com
-
-
-   David McGrew
-   Cisco Systems, Inc.
-   170 W Tasman Drive
-   San Jose, CA  95134
-   USA
-
-   Email: mcgrew@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 8]
-
-Internet-Draft          RSA AES-GCM Ciphersuites               June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Salowey, et al.         Expires December 20, 2007               [Page 9]
-
diff --git a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt b/doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt
deleted file mode 100644
index baddf1ea57..0000000000
--- a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-01.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-TLS Working Group                                             J. Salowey
-Internet-Draft                                              A. Choudhury
-Intended status: Standards Track                               D. McGrew
-Expires: July 16, 2008                               Cisco Systems, Inc.
-                                                        January 13, 2008
-
-
-                RSA based AES-GCM Cipher Suites for TLS
-                     draft-ietf-tls-rsa-aes-gcm-01
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 16, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   This memo describes the use of the Advanced Encryption Standard (AES)
-   in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
-   authenticated encryption operation.  GCM provides both
-   confidentiality and data origin authentication, can be efficiently
-   implemented in hardware for speeds of 10 gigabits per second and
-   above, and is also well-suited to software implementations.  This
-   memo defines TLS ciphersuites that use AES-GCM with RSA.
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 1]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-
-   3.  RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3
-     3.1.  Recommendations for Multiple Cryptographic Processors . . . 4
-
-   4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 5
-
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-     6.1.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6
-     6.2.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6
-
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 2]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-1.  Introduction
-
-   This document describes the use of AES [AES]in Galois Counter Mode
-   (GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite
-   for TLS.  This mechanism is not only efficient and secure, hardware
-   implementations can achieve high speeds with low cost and low
-   latency, because the mode can be pipelined.  Applications like
-   CAPWAP, which uses DTLS, can benefit from the high-speed
-   implementations when wireless termination points (WTPs) and
-   controllers (ACs) have to meet requirements to support higher
-   throughputs in the future.  AES-GCM has been specified as a mode that
-   can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security
-   [IEEE8021AE].  It also is part of the NSA suite B ciphersuites for
-   TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B
-   requirements these ciphersuites require ECC base key exchange and TLS
-   1.2.  The ciphersuites defined in this document are based on RSA
-   which allows the use of AES-GCM in environments that have not
-   deployed ECC algorithms and do not need to meet NSA Suite B
-   requirements.  AES-GCM is an authenticated encryption with associated
-   data (AEAD) cipher, as defined in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
-   The ciphersuites defined in this draft may be used with Datagram TLS
-   defined in [RFC4347].  This memo uses GCM in a way similar to
-   [I-D.ietf-tls-ecc-new-mac].
-
-
-2.  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 [RFC2119]
-
-
-3.  RSA Based AES-GCM Cipher Suites
-
-   The following ciphersuites use the new authenticated encryption modes
-   defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
-
-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
-      CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
-      CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
-
-   These ciphersuites use the AES-GCM authenticated encryption with
-   associated data (AEAD) algorithms AEAD_AES_128_GCM and
-   AEAD_AES_256_GCM described in [I-D.mcgrew-auth-enc].  Note that this
-   specification uses a 128-bit authentication tag with GCM.  The
-   "nonce" SHALL be 12 bytes long and it is "partially implicit" (see
-   section 3.2.1 in [I-D.mcgrew-auth-enc]).  Part of the nonce is
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 3]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-   generated as part of the handshake process and is static for the
-   entire session and part is carried in each packet.
-
-             Struct{
-                opaque salt[4];
-                opaque explicit_nonce_part[8];
-             } GCMNonce
-
-   The salt is the "implicit" part of the nonce and is not sent in the
-   packet.  It is either the client_write_IV if the client is sending or
-   the server_write_IV if the server is sending.  These IVs SHALL be 4
-   bytes long.
-
-   The explicit_nonce_part is chosen by the sender and included in the
-   packet.  Each value of the explicit_nonce_part MUST be distinct for
-   each distinct invocation of GCM encrypt function for any fixed key.
-   Failure to meet this uniqueness requirement can significantly degrade
-   security.  The explicit_nonce_part is carried in the IV field of the
-   GenericAEADCipher structure.  Therefore, for all the algorithms
-   defined in this section, SecurityParameters.iv_length=8.
-
-   In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence
-   number.  In the case of Datagram TLS [RFC4347] the
-   explicit_nonce_part MAY be formed from the concatenation of the 16-
-   bit epoch with the 48-bit DTLS seq_num.
-
-   The RSA and RSA-DHE key exchange is performed as defined in
-   [I-D.ietf-tls-rfc4346-bis].
-
-   The PRF algorithms SHALL be as follows:
-
-   For TLS_RSA_WITH_AES_128_GCM_SHA256 and
-   TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256.
-
-   For TLS_RSA_WITH_AES_256_GCM_SHA384 and
-   TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
-
-3.1.  Recommendations for Multiple Cryptographic Processors
-
-   If multiple cryptographic processors are in use by the sender, then
-   the sender MUST ensure that each value of the explicit_nonce_part
-   that is used by each processor is distinct.  In this case each
-   encryption processor SHOULD include in the explicit_nonce_part a a
-   fixed value that is distinct for each processor.  The recommended
-   format is
-
-        explicit_nonce_part = FixedDistinct || Variable
-
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 4]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-   where the FixedDistinct field is distinct for each encryption
-   processor, but is fixed for a given processor, and the Variable field
-   is distinct for each distinct nonce used by a particular encryption
-   processor.  When this method is used, the FixedDistinct fields used
-   by the different processors MUST have the same length.
-
-   In the terms of Figure 2 in [I-D.mcgrew-auth-enc], the Salt is the
-   Fixed-Common part of the nonce (it is fixed, and it is common across
-   all encryption processors), the FixedDistinct field exactly
-   corresponds to the Fixed-Distinct field, and the Variable field
-   corresponds to the Counter field, and the explicit part exactly
-   corresponds to the explicit_nonce_part.
-
-   For clarity, we provide an example for TLS in which there are two
-   distinct encryption processors, each of which uses a one-byte
-   FixedDistinct field:
-
-          Salt          = eedc68dc
-          FixedDistinct = 01       (for the first encryption processor)
-          FixedDistinct = 02       (for the second encryption processor)
-
-   The GCMnonces generated by the first encryption processor, and their
-   corresponding explicit_nonce_parts, are:
-
-          GCMNonce                    explicit_nonce_part
-          ------------------------    ----------------------------
-          eedc68dc0100000000000000    0100000000000000
-          eedc68dc0100000000000001    0100000000000001
-          eedc68dc0100000000000002    0100000000000002
-          ...
-
-   The GCMnonces generated by the second encryption processor, and their
-   corresponding explicit_nonce_parts, are
-
-          GCMNonce                    explicit_nonce_part
-          ------------------------    ----------------------------
-          eedc68dc0200000000000000    0200000000000000
-          eedc68dc0200000000000001    0200000000000001
-          eedc68dc0200000000000002    0200000000000002
-          ...
-
-
-
-4.  TLS Versions
-
-   These ciphersuites make use of the authenticated encryption with
-   additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They
-   MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 5]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-   offer these cipher suites if they do not offer TLS 1.2 or later.
-   Servers which select an earlier version of TLS MUST NOT select one of
-   these cipher suites.  Because TLS has no way for the client to
-   indicate that it supports TLS 1.2 but not earlier, a non-compliant
-   server might potentially negotiate TLS 1.1 or earlier and select one
-   of the cipher suites in this document.  Clients MUST check the TLS
-   version and generate a fatal "illegal_parameter" alert if they detect
-   an incorrect version.
-
-
-5.  IANA Considerations
-
-   IANA has assigned the following values for the ciphersuites defined
-   in this draft:
-
-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
-      CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
-      CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
-
-
-6.  Security Considerations
-
-   The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to
-   this document as well.  The remainder of this section describes
-   security considerations specific to the cipher suites described in
-   this document.
-
-6.1.  Perfect Forward Secrecy
-
-   The perfect forward secrecy properties of RSA based TLS ciphersuites
-   are discussed in the security analysis of [I-D.ietf-tls-rfc4346-bis].
-   It should be noted that only the ephemeral Diffie-Hellman based
-   ciphersuites (RSA_DHE) are capable of providing perfect forward
-   secrecy.
-
-6.2.  Counter Reuse
-
-   AES-GCM security requires that the counter is never reused.  The IV
-   construction in Section 3 is designed to prevent counter reuse.
-
-
-7.  Acknowledgements
-
-   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac].
-
-
-8.  References
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 6]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-8.1.  Normative References
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, April 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07
-              (work in progress), November 2007.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-05 (work in progress),
-              November 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-8.2.  Informative References
-
-   [I-D.ietf-tls-ecc-new-mac]
-              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-              256/384 and AES Galois Counter  Mode",
-              draft-ietf-tls-ecc-new-mac-02 (work in progress),
-              December 2007.
-
-   [I-D.rescorla-tls-suiteb]
-              Salter, M. and E. Rescorla, "Suite B Cipher Suites for
-              TLS", draft-rescorla-tls-suiteb-01 (work in progress),
-              June 2007.
-
-   [IEEE8021AE]
-              Institute of Electrical and Electronics Engineers, "Media
-              Access Control Security", IEEE Standard 802.1AE,
-              August 2006.
-
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 7]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
-              (GCM) in IPsec Encapsulating Security Payload (ESP)",
-              RFC 4106, June 2005.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems, Inc.
-   2901 3rd. Ave
-   Seattle, WA  98121
-   USA
-
-   Email: jsalowey@cisco.com
-
-
-   Abhijit Choudhury
-   Cisco Systems, Inc.
-   3625 Cisco Way
-   San Jose, CA  95134
-   USA
-
-   Email: abhijitc@cisco.com
-
-
-   David McGrew
-   Cisco Systems, Inc.
-   170 W Tasman Drive
-   San Jose, CA  95134
-   USA
-
-   Email: mcgrew@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 8]
-
-Internet-Draft          RSA AES-GCM Ciphersuites            January 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Salowey, et al.           Expires July 16, 2008                 [Page 9]
-
diff --git a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt b/doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt
deleted file mode 100644
index 671bf846b2..0000000000
--- a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-02.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-

-

-

-TLS Working Group                                             J. Salowey

-Internet-Draft                                              A. Choudhury

-Intended status: Standards Track                               D. McGrew

-Expires: August 10, 2008                             Cisco Systems, Inc.

-                                                        February 7, 2008

-

-

-                     AES-GCM Cipher Suites for TLS

-                     draft-ietf-tls-rsa-aes-gcm-02

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups.  Note that

-   other groups may also distribute working documents as Internet-

-   Drafts.

-

-   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.

-

-   This Internet-Draft will expire on August 10, 2008.

-

-Copyright Notice

-

-   Copyright (C) The IETF Trust (2008).

-

-Abstract

-

-   This memo describes the use of the Advanced Encryption Standard (AES)

-   in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)

-   authenticated encryption operation.  GCM provides both

-   confidentiality and data origin authentication, can be efficiently

-   implemented in hardware for speeds of 10 gigabits per second and

-   above, and is also well-suited to software implementations.  This

-   memo defines TLS ciphersuites that use AES-GCM with RSA, DSS and

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 1]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-   Diffie-Hellman based key exchange mechanisms.

-

-

-Table of Contents

-

-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

-

-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3

-

-   3.  AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 3

-

-   4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 4

-

-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5

-

-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5

-     6.1.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5

-     6.2.  Recommendations for Multiple Encryption Processors  . . . . 5

-

-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7

-

-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7

-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7

-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

-

-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 2]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-1.  Introduction

-

-   This document describes the use of AES [AES]in Galois Counter Mode

-   (GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a

-   ciphersuite for TLS.  AES-GCM is not only efficient and secure, but

-   hardware implementations can achieve high speeds with low cost and

-   low latency, because the mode can be pipelined.  Applications like

-   CAPWAP, which uses DTLS, can benefit from the high-speed

-   implementations when wireless termination points (WTPs) and

-   controllers (ACs) have to meet requirements to support higher

-   throughputs in the future.  AES-GCM has been specified as a mode that

-   can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security

-   [IEEE8021AE].  This document defines ciphersutes based on RSA, DSS

-   and Diffie-Hellman key exchanges; ECC based ciphersuites are defined

-   in a separate document [I-D.ietf-tls-ecc-new-mac].  AES-GCM is an

-   authenticated encryption with associated data (AEAD) cipher, as

-   defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  The ciphersuites

-   defined in this draft may be used with Datagram TLS defined in

-   [RFC4347].  This memo uses GCM in a way similar to

-   [I-D.ietf-tls-ecc-new-mac].

-

-

-2.  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 [RFC2119]

-

-

-3.  AES-GCM Cipher Suites

-

-   The following ciphersuites use the new authenticated encryption modes

-   defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:

-

-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-

-   These ciphersuites use the AES-GCM authenticated encryption with

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 3]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-   associated data (AEAD) algorithms AEAD_AES_128_GCM and

-   AEAD_AES_256_GCM described in [RFC5116].  Note that each of these

-   AEAD algorithms uses a 128-bit authentication tag with GCM.  The

-   "nonce" SHALL be 12 bytes long and it is "partially implicit" (see

-   section 3.2.1 in [RFC5116]).  Part of the nonce is generated as part

-   of the handshake process and is static for the entire session and the

-   other part is carried in each packet.

-

-             Struct{

-                opaque salt[4];

-                opaque explicit_nonce_part[8];

-             } GCMNonce

-

-   The salt is the "implicit" part of the nonce and is not sent in the

-   packet.  It is either the client_write_IV if the client is sending or

-   the server_write_IV if the server is sending.  These IVs SHALL be 4

-   bytes long, therefore, for all the algorithms defined in this

-   section, SecurityParameters.fixed_iv_length=4.

-

-   The explicit_nonce_part is chosen by the sender and included in the

-   packet.  Each value of the explicit_nonce_part MUST be distinct for

-   each distinct invocation of GCM encrypt function for any fixed key.

-   Failure to meet this uniqueness requirement can significantly degrade

-   security.  The explicit_nonce_part is carried in the IV field of the

-   GenericAEADCipher structure.  For all the algorithms defined in this

-   section, SecurityParameters.record_iv_length=8.

-

-   In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence

-   number.  In the case of Datagram TLS [RFC4347] the

-   explicit_nonce_part MAY be formed from the concatenation of the 16-

-   bit epoch with the 48-bit DTLS seq_num.

-

-   The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges

-   are performed as defined in [I-D.ietf-tls-rfc4346-bis].

-

-   The PRF algorithms SHALL be as follows:

-

-   For ciphersuites ending in _SHA256 the hash function is SHA256.

-

-   For ciphersuites ending in _SHA384 the hash function is SHA384.

-

-

-4.  TLS Versions

-

-   These ciphersuites make use of the authenticated encryption with

-   additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They

-   MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT

-   offer these cipher suites if they do not offer TLS 1.2 or later.

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 4]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-   Servers which select an earlier version of TLS MUST NOT select one of

-   these cipher suites.  Because TLS has no way for the client to

-   indicate that it supports TLS 1.2 but not earlier, a non-compliant

-   server might potentially negotiate TLS 1.1 or earlier and select one

-   of the cipher suites in this document.  Clients MUST check the TLS

-   version and generate a fatal "illegal_parameter" alert if they detect

-   an incorrect version.

-

-

-5.  IANA Considerations

-

-   IANA has assigned the following values for the ciphersuites defined

-   in this draft:

-

-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-

-

-6.  Security Considerations

-

-   The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to

-   this document as well.  The remainder of this section describes

-   security considerations specific to the cipher suites described in

-   this document.

-

-6.1.  Counter Reuse

-

-   AES-GCM security requires that the counter is never reused.  The IV

-   construction in Section 3 is designed to prevent counter reuse.

-

-6.2.  Recommendations for Multiple Encryption Processors

-

-   If multiple cryptographic processors are in use by the sender, then

-   the sender MUST ensure that, for a particular key, each value of the

-   explicit_nonce_part used with that key is distinct.  In this case

-   each encryption processor SHOULD include in the explicit_nonce_part a

-   fixed value that is distinct for each processor.  The recommended

-   format is

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 5]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-        explicit_nonce_part = FixedDistinct || Variable

-

-   where the FixedDistinct field is distinct for each encryption

-   processor, but is fixed for a given processor, and the Variable field

-   is distinct for each distinct nonce used by a particular encryption

-   processor.  When this method is used, the FixedDistinct fields used

-   by the different processors MUST have the same length.

-

-   In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common

-   part of the nonce (it is fixed, and it is common across all

-   encryption processors), the FixedDistinct field exactly corresponds

-   to the Fixed-Distinct field, and the Variable field corresponds to

-   the Counter field, and the explicit part exactly corresponds to the

-   explicit_nonce_part.

-

-   For clarity, we provide an example for TLS in which there are two

-   distinct encryption processors, each of which uses a one-byte

-   FixedDistinct field:

-

-          Salt          = eedc68dc

-          FixedDistinct = 01       (for the first encryption processor)

-          FixedDistinct = 02       (for the second encryption processor)

-

-   The GCMnonces generated by the first encryption processor, and their

-   corresponding explicit_nonce_parts, are:

-

-          GCMNonce                    explicit_nonce_part

-          ------------------------    ----------------------------

-          eedc68dc0100000000000000    0100000000000000

-          eedc68dc0100000000000001    0100000000000001

-          eedc68dc0100000000000002    0100000000000002

-          ...

-

-   The GCMnonces generated by the second encryption processor, and their

-   corresponding explicit_nonce_parts, are

-

-          GCMNonce                    explicit_nonce_part

-          ------------------------    ----------------------------

-          eedc68dc0200000000000000    0200000000000000

-          eedc68dc0200000000000001    0200000000000001

-          eedc68dc0200000000000002    0200000000000002

-          ...

-

-

-

-

-

-

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 6]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-7.  Acknowledgements

-

-   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac].  The

-   authors would like to thank Alex Lam and Pasi Eronen for providing

-   useful comments during the review of this draft.

-

-

-8.  References

-

-8.1.  Normative References

-

-   [AES]      National Institute of Standards and Technology,

-              "Specification for the Advanced Encryption Standard

-              (AES)", FIPS 197, November 2001.

-

-   [GCM]      National Institute of Standards and Technology,

-              "Recommendation for Block Cipher Modes of Operation:

-              Galois Counter Mode (GCM) for Confidentiality and

-              Authentication", SP 800-38D, April 2006.

-

-   [I-D.ietf-tls-rfc4346-bis]

-              Dierks, T. and E. Rescorla, "The Transport Layer Security

-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-08

-              (work in progress), January 2008.

-

-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

-              Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer

-              Security", RFC 4347, April 2006.

-

-   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated

-              Encryption", RFC 5116, January 2008.

-

-8.2.  Informative References

-

-   [I-D.ietf-tls-ecc-new-mac]

-              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-

-              256/384 and AES Galois Counter  Mode",

-              draft-ietf-tls-ecc-new-mac-02 (work in progress),

-              December 2007.

-

-   [IEEE8021AE]

-              Institute of Electrical and Electronics Engineers, "Media

-              Access Control Security", IEEE Standard 802.1AE,

-              August 2006.

-

-   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 7]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-              (GCM) in IPsec Encapsulating Security Payload (ESP)",

-              RFC 4106, June 2005.

-

-

-Authors' Addresses

-

-   Joseph Salowey

-   Cisco Systems, Inc.

-   2901 3rd. Ave

-   Seattle, WA  98121

-   USA

-

-   Email: jsalowey@cisco.com

-

-

-   Abhijit Choudhury

-   Cisco Systems, Inc.

-   3625 Cisco Way

-   San Jose, CA  95134

-   USA

-

-   Email: abhijitc@cisco.com

-

-

-   David McGrew

-   Cisco Systems, Inc.

-   170 W Tasman Drive

-   San Jose, CA  95134

-   USA

-

-   Email: mcgrew@cisco.com

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 8]

-

-Internet-Draft            AES-GCM Ciphersuites             February 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-Acknowledgment

-

-   Funding for the RFC Editor function is provided by the IETF

-   Administrative Support Activity (IASA).

-

-

-

-

-

-Salowey, et al.          Expires August 10, 2008                [Page 9]

-

diff --git a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-03.txt b/doc/protocol/draft-ietf-tls-rsa-aes-gcm-03.txt
deleted file mode 100644
index 7b5e57abab..0000000000
--- a/doc/protocol/draft-ietf-tls-rsa-aes-gcm-03.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-

-

-

-TLS Working Group                                             J. Salowey

-Internet-Draft                                              A. Choudhury

-Intended status: Standards Track                               D. McGrew

-Expires: October 16, 2008                            Cisco Systems, Inc.

-                                                          April 14, 2008

-

-

-                     AES-GCM Cipher Suites for TLS

-                     draft-ietf-tls-rsa-aes-gcm-03

-

-Status of this Memo

-

-   By submitting this Internet-Draft, each author represents that any

-   applicable patent or other IPR claims of which he or she is aware

-   have been or will be disclosed, and any of which he or she becomes

-   aware will be disclosed, in accordance with Section 6 of BCP 79.

-

-   Internet-Drafts are working documents of the Internet Engineering

-   Task Force (IETF), its areas, and its working groups.  Note that

-   other groups may also distribute working documents as Internet-

-   Drafts.

-

-   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.

-

-   This Internet-Draft will expire on October 16, 2008.

-

-Copyright Notice

-

-   Copyright (C) The IETF Trust (2008).

-

-Abstract

-

-   This memo describes the use of the Advanced Encryption Standard (AES)

-   in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)

-   authenticated encryption operation.  GCM provides both

-   confidentiality and data origin authentication, can be efficiently

-   implemented in hardware for speeds of 10 gigabits per second and

-   above, and is also well-suited to software implementations.  This

-   memo defines TLS cipher suites that use AES-GCM with RSA, DSS and

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 1]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-   Diffie-Hellman based key exchange mechanisms.

-

-

-Table of Contents

-

-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

-

-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3

-

-   3.  AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 3

-

-   4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 4

-

-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5

-

-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5

-     6.1.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5

-     6.2.  Recommendations for Multiple Encryption Processors  . . . . 5

-

-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6

-

-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7

-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7

-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7

-

-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 2]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-1.  Introduction

-

-   This document describes the use of AES [AES] in Galois Counter Mode

-   (GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a

-   cipher suite for TLS.  AES-GCM is an authenticated encryption with

-   associated data (AEAD) cipher (as defined in TLS 1.2

-   [I-D.ietf-tls-rfc4346-bis]) providing both confidentiality and data

-   origin authentication.  The following sections define cipher suites

-   based on RSA, DSS and Diffie-Hellman key exchanges; ECC based cipher

-   suites are defined in a separate document [I-D.ietf-tls-ecc-new-mac].

-

-   AES-GCM is not only efficient and secure, but hardware

-   implementations can achieve high speeds with low cost and low

-   latency, because the mode can be pipelined.  Applications that

-   require high data throughput can benefit from these high-speed

-   implementations.  AES-GCM has been specified as a mode that can be

-   used with IPsec ESP [RFC4106] and 802.1AE MAC Security [IEEE8021AE].

-

-

-2.  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 [RFC2119].

-

-

-3.  AES-GCM Cipher Suites

-

-   The following cipher suites use the new authenticated encryption

-   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:

-

-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-

-   These cipher suites use the AES-GCM authenticated encryption with

-   associated data (AEAD) algorithms AEAD_AES_128_GCM and

-   AEAD_AES_256_GCM described in [RFC5116].  Note that each of these

-   AEAD algorithms uses a 128-bit authentication tag with GCM.  The

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 3]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-   "nonce" SHALL be 12 bytes long consisting of two parts as follows:

-   (this is an example of a "partially explicit" nonce; see section

-   3.2.1 in [RFC5116]).

-

-             struct{

-                opaque salt[4];

-                opaque nonce_explicit[8];

-             } GCMNonce;

-

-   The salt is the "implicit" part of the nonce and is not sent in the

-   packet.  Instead the salt is generated as part of the handshake

-   process: it is either the client_write_IV (when the client is

-   sending) or the server_write_IV (when the server is sending).  The

-   salt length (SecurityParameters.fixed_iv_length) is 4 octets.

-

-   The nonce_explicit is the "explicit" part of the nonce.  It is chosen

-   by the sender and is carried in each TLS record in the

-   GenericAEADCipher.nonce_explicit field.  The nonce_explicit length

-   (SecurityParameters.record_iv_length) is 8 octets.

-

-   Each value of the nonce_explicit MUST be distinct for each distinct

-   invocation of GCM encrypt function for any fixed key.  Failure to

-   meet this uniqueness requirement can significantly degrade security.

-   The nonce_explicit MAY be the 64-bit sequence number.

-

-   The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges

-   are performed as defined in [I-D.ietf-tls-rfc4346-bis].

-

-   The PRF algorithms SHALL be as follows:

-

-      For cipher suites ending with _SHA256, the PRF is the TLS PRF

-      [I-D.ietf-tls-rfc4346-bis] with SHA-256 as the hash function.

-

-      For cipher suites ending with _SHA384, the PRF is the TLS PRF

-      [I-D.ietf-tls-rfc4346-bis] with SHA-384 as the hash function.

-

-   Implementations MUST send TLS Alert bad_record_mac for all types of

-   failures encountered in processing the AES-GCM algorithm.

-

-

-4.  TLS Versions

-

-   These cipher suites make use of the authenticated encryption with

-   additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They

-   MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT

-   offer these cipher suites if they do not offer TLS 1.2 or later.

-   Servers which select an earlier version of TLS MUST NOT select one of

-   these cipher suites.  Because TLS has no way for the client to

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 4]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-   indicate that it supports TLS 1.2 but not earlier, a non-compliant

-   server might potentially negotiate TLS 1.1 or earlier and select one

-   of the cipher suites in this document.  Clients MUST check the TLS

-   version and generate a fatal "illegal_parameter" alert if they detect

-   an incorrect version.

-

-

-5.  IANA Considerations

-

-   IANA has assigned the following values for the cipher suites defined

-   in this draft:

-

-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}

-      CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}

-

-

-6.  Security Considerations

-

-   The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to

-   this document as well.  The remainder of this section describes

-   security considerations specific to the cipher suites described in

-   this document.

-

-6.1.  Counter Reuse

-

-   AES-GCM security requires that the counter is never reused.  The IV

-   construction in Section 3 is designed to prevent counter reuse.

-

-6.2.  Recommendations for Multiple Encryption Processors

-

-   If multiple cryptographic processors are in use by the sender, then

-   the sender MUST ensure that, for a particular key, each value of the

-   nonce_explicit used with that key is distinct.  In this case each

-   encryption processor SHOULD include in the nonce_explicit a fixed

-   value that is distinct for each processor.  The recommended format is

-

-        nonce_explicit = FixedDistinct || Variable

-

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 5]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-   where the FixedDistinct field is distinct for each encryption

-   processor, but is fixed for a given processor, and the Variable field

-   is distinct for each distinct nonce used by a particular encryption

-   processor.  When this method is used, the FixedDistinct fields used

-   by the different processors MUST have the same length.

-

-   In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common

-   part of the nonce (it is fixed, and it is common across all

-   encryption processors), the FixedDistinct field exactly corresponds

-   to the Fixed-Distinct field, and the Variable field corresponds to

-   the Counter field, and the explicit part exactly corresponds to the

-   nonce_explicit.

-

-   For clarity, we provide an example for TLS in which there are two

-   distinct encryption processors, each of which uses a one-byte

-   FixedDistinct field:

-

-          Salt          = eedc68dc

-          FixedDistinct = 01       (for the first encryption processor)

-          FixedDistinct = 02       (for the second encryption processor)

-

-   The GCMnonces generated by the first encryption processor, and their

-   corresponding nonce_explicit, are:

-

-          GCMNonce                    nonce_explicit

-          ------------------------    ----------------------------

-          eedc68dc0100000000000000    0100000000000000

-          eedc68dc0100000000000001    0100000000000001

-          eedc68dc0100000000000002    0100000000000002

-          ...

-

-   The GCMnonces generated by the second encryption processor, and their

-   corresponding nonce_explicit, are

-

-          GCMNonce                    nonce_explicit

-          ------------------------    ----------------------------

-          eedc68dc0200000000000000    0200000000000000

-          eedc68dc0200000000000001    0200000000000001

-          eedc68dc0200000000000002    0200000000000002

-          ...

-

-

-

-7.  Acknowledgements

-

-   This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac].  The

-   authors would like to thank Alex Lam, Simon Josefsson and Pasi Eronen

-   for providing useful comments during the review of this draft.

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 6]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-8.  References

-

-8.1.  Normative References

-

-   [AES]      National Institute of Standards and Technology, "Advanced

-              Encryption Standard (AES)", FIPS 197, November 2001.

-

-   [GCM]      Dworkin, M., "Recommendation for Block Cipher Modes of

-              Operation: Galois/Counter Mode (GCM) and GMAC", National

-              Institute of Standards and Technology SP 800-38D,

-              November 2007.

-

-   [I-D.ietf-tls-rfc4346-bis]

-              Dierks, T. and E. Rescorla, "The Transport Layer Security

-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10

-              (work in progress), March 2008.

-

-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

-              Requirement Levels", BCP 14, RFC 2119, March 1997.

-

-   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated

-              Encryption", RFC 5116, January 2008.

-

-8.2.  Informative References

-

-   [I-D.ietf-tls-ecc-new-mac]

-              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-

-              256/384 and AES Galois Counter  Mode",

-              draft-ietf-tls-ecc-new-mac-05 (work in progress),

-              April 2008.

-

-   [IEEE8021AE]

-              Institute of Electrical and Electronics Engineers, "Media

-              Access Control Security", IEEE Standard 802.1AE,

-              August 2006.

-

-   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode

-              (GCM) in IPsec Encapsulating Security Payload (ESP)",

-              RFC 4106, June 2005.

-

-

-

-

-

-

-

-

-

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 7]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-Authors' Addresses

-

-   Joseph Salowey

-   Cisco Systems, Inc.

-   2901 3rd. Ave

-   Seattle, WA  98121

-   USA

-

-   Email: jsalowey@cisco.com

-

-

-   Abhijit Choudhury

-   Cisco Systems, Inc.

-   3625 Cisco Way

-   San Jose, CA  95134

-   USA

-

-   Email: abhijitc@cisco.com

-

-

-   David McGrew

-   Cisco Systems, Inc.

-   170 W Tasman Drive

-   San Jose, CA  95134

-   USA

-

-   Email: mcgrew@cisco.com

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 8]

-

-Internet-Draft            AES-GCM Cipher suites               April 2008

-

-

-Full Copyright Statement

-

-   Copyright (C) The IETF Trust (2008).

-

-   This document is subject to the rights, licenses and restrictions

-   contained in BCP 78, and except as set forth therein, the authors

-   retain all their rights.

-

-   This document and the information contained herein are provided on an

-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND

-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS

-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF

-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

-

-

-Intellectual Property

-

-   The IETF takes no position regarding the validity or scope of any

-   Intellectual Property Rights or other rights that might be claimed to

-   pertain to the implementation or use of the technology described in

-   this document or the extent to which any license under such rights

-   might or might not be available; nor does it represent that it has

-   made any independent effort to identify any such rights.  Information

-   on the procedures with respect to rights in RFC documents can be

-   found in BCP 78 and BCP 79.

-

-   Copies of IPR disclosures made to the IETF Secretariat and any

-   assurances of licenses to be made available, or the result of an

-   attempt made to obtain a general license or permission for the use of

-   such proprietary rights by implementers or users of this

-   specification can be obtained from the IETF on-line IPR repository at

-   http://www.ietf.org/ipr.

-

-   The IETF invites any interested party to bring to its attention any

-   copyrights, patents or patent applications, or other proprietary

-   rights that may cover technology that may be required to implement

-   this standard.  Please address the information to the IETF at

-   ietf-ipr@ietf.org.

-

-

-Acknowledgment

-

-   Funding for the RFC Editor function is provided by the IETF

-   Administrative Support Activity (IASA).

-

-

-

-

-

-Salowey, et al.         Expires October 16, 2008                [Page 9]

-

diff --git a/doc/protocol/draft-ietf-tls-sharedkeys-02.txt b/doc/protocol/draft-ietf-tls-sharedkeys-02.txt
deleted file mode 100644
index 91be42d4e1..0000000000
--- a/doc/protocol/draft-ietf-tls-sharedkeys-02.txt
+++ /dev/null
@@ -1,437 +0,0 @@
-
-TLS Working Group                                              P.Gutmann
-Internet-Draft                                    University of Auckland
-Expires: April 2004                                         October 2003
-
-                  Use of Shared Keys in the TLS Protocol
-                       draft-ietf-tls-sharedkeys-02
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task Force
-(IETF), its areas, and its working groups.  Note that other groups may also
-distribute working documents as Internet- Drafts.
-
-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.
-
-1. Abstract
-
-The TLS handshake requires the use of CPU-intensive public-key algorithms with
-a considerable overhead in resource-constrained environments or ones such as
-mainframes where users are charged for CPU time.  This document describes a
-means of employing TLS using symmetric keys or passwords shared in advance
-among communicating parties.  As an additional benefit, this mechanism
-provides cryptographic authentication of both client and server without
-requiring the transmission of passwords or the use of certificates.  No
-modifications or alterations to the TLS protocol are required for this
-process.
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
-"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in
-uppercase, as shown) are to be interpreted as described in [RFC 2119].
-
-2. Problem analysis
-
-TLS is frequently used with devices with little CPU power available, for
-example mobile and embedded devices.  In these situations the initial TLS
-handshake can take as long as half a minute with a 1Kbit RSA key.  In many
-cases a fully general public-key-based handshake is unnecessary, since the
-device is only syncing to a host PC or contacting a fixed base station, which
-would allow a pre-shared symmetric key to be used instead.  An example of this
-kind of use is using 3GPP cellular mechanisms to establish keys used to secure
-a TLS tunnel to a mobile device.
-
-In a slight variation of this case, CPU power is available but is too
-expensive to devote to public-key operations.  This situation is common in
-mainframe environments, where users are charged for CPU time.  As with mobile
-devices, mainframe-to-mainframe or client-to-mainframe communications are
-generally fixed in advance, allowing shared symmetric keys to be employed.
-
-In order to solve these problems, we require a means of eliminating the
-expensive public-key operations in the TLS handshake, while providing an
-equivalent level of security using shared symmetric keys.  The solution is
-fairly straightforward.  Observe that after the initial handshake phase, TLS
-is operating with a quantity of symmetric keying material derived from the
-information exchanged during the initial handshake.  Using shared symmetric
-keys involves explicitly deriving the TLS master secret from the shared key,
-rather than sharing it implicitly via the public-key-based key agreement
-process.  TLS already contains such a mechanism built into the protocol in the
-form of the session cacheing mechanism, which allows a TLS session to be
-resumed without requiring a full public-key-based re-handshake.
-
-The solution to the problem then is obvious: We need to seed the TLS session
-cache with the shared symmetric key.  When the client connects, the session
-cacheing mechanism takes over and the client and server "resume" the phantom
-session created by seeding the cache.  This mechanism requires an absolute
-minimum of code changes to existing TLS implementations (it can be bolted onto
-any existing TLS engine without needing to change the engine itself), and no
-changes to the TLS protocol itself.
-
-2.1 Design considerations
-
-In order to work within the existing TLS protocol design, we require a means
-of identifying a particular session (the session ID in TLS terminology), and
-the keying material required to protect the session.  The { ID, key }
-combination is analogous to the { user name, password } combination
-traditionally used to secure access to computer systems.
-
-In TLS, the session ID is a variable-length value of up to 32 bytes, but is
-typically 32 or less frequently 16 bytes long.  For our use we don't really
-care about its form.  A (somewhat unsound) practice would be to use the user
-name as the session ID.  A more secure alternative would be to employ a value
-derived from the user name in such a way that it can't be directly connected
-to it, for example a MAC of the user name.
-
-Normally the exact format of the session ID is determined explicitly by the
-server and remembered by the client for use during session resumption.
-However, when "resuming" a phantom session in the manner described here, both
-the client and the server must be able to implicitly generate identical
-session ID values in order to identify the phantom session to be resumed.  To
-create a canonical session ID value, we pad the variable-length value out to a
-fixed length by appending zero bytes.
-
-The TLS master secret is a 48-byte value, which is unlikely to correspond to
-the value of the shared symmetric key or password, which would typically be a
-128-bit key or a text password/passphrase.  In order to transform this into
-the type of keying material required by TLS, we need to apply the TLS
-pseudorandom function (PRF) to produce the master secret with which we seed
-the session cache.  The shared secret thus takes the place of the 48-byte
-premaster secret usually used to derive the master secret.  As with the
-variable-length session ID, we need to canonicalise the variable-length
-secret.
-
-The obvious way to do this would be to by zero-pad it to the standard 48-byte
-length usually used for the premaster secret, as for the session ID.
-Unfortunately this straightforward approach doesn't work.  Unlike the SSL PRF,
-which uses the full secret for both the MD5 and SHA-1 halves, the TLS PRF
-isn't a pure black-box design because it splits the secret into two halves
-before using it.  This would result in the second (SHA-1) half in most cases
-end up with only the zero padding bytes as its "secret".  The reasoning behind
-this splitting of the secret was that there might be some interaction between
-the two algorithms that could cause security problems.
-
-As a result, it's necessary to be aware of the PRF's internal structure and
-pre-process the input in a way that negates what the PRF does.  Some of the
-possible options to fix the problem are:
-
-1. Synthesise a new PRF from HMAC to pre-PRF the input to the TLS PRF.  Apart
-   from just being an awful approach, this violates the minimal code-change
-   requirement for TLS implementations that the shared-keys mechanism is
-   supposed to provide.  Instead of simply feeding data in via a standard
-   mechanism, implementors would now need to extend their TLS implementation
-   to introduce new crypto mechanisms.
-
-2. Repeat the input (or some variant thereof) to fill the 48-byte secret
-   value.  This is problematic in that it creates key equivalence classes,
-   for example "ABCD" == "ABCDABCD".
-
-3. Unsplit the input, so that instead of arranaging it as 1 x 48 bytes it's
-   done as 2 x 24 bytes.  This limits the overall key size, and is specific to
-   the PRF being used - a future PRF design may not split the input in this
-   manner, negating the un-splitting step.
-
-The least ugly solution is a variation of 2, prepending a single length byte
-to the secret, then repeating it to fill 48 bytes, to fix the problem of key
-equivalence classes.  This is the approach used here.
-
-Currently the shared-key mechanism always uses the TLS PRF (even if it's used
-with SSL, since this is purely a TLS mechanism).  If in the future a new PRF
-is introduced, it will be necessary to provide some means of switching over to
-the new PRF if both it and the current one are in active use.  Presumably the
-only reason to introduce a new, incompatible PRF would be a successful attack
-on the current one, in which case the point is moot.  However, if for some
-reason it's necessary to keep both PRFs in active use at the same time, then
-some mechanism such as adding the session ID and shared key in the standard
-manner using the TLS PRF and some transformation of the session ID and the
-shared key using the new PRF can be adopted.  Since the details of a possible
-PRF switch are impossible to predict (it may entail a complete protocol
-overhaul for example), this document does not attempt to guess at the details
-beyond providing this implementation hint.
-
-Finally, we need a means of injecting the resulting session ID and master
-secret into the session cache.  This is the only modification required to
-existing TLS implementations.  Once the cache is seeded, all further details
-are handled automatically by the TLS protocol.
-
-It should be noted that this mechanism is best suited for situations where a
-small number of clients/servers are communicating.  While seeding a session
-cache with IDs and keys for 10,000 different users is certainly possible, this
-is rather wasteful of server resources, not to mention the accompanying key
-management nightmare involved in handling such a large number of shared
-symmetric keys.
-
-3. TLS using shared keys
-
-[Note: The following is phrased fairly informally, since it's really an
- application note rather than a standards-track RFC]
-
-Before any exchange takes place, the client and server session caches are
-seeded with a session ID identifying the user/session, and a master secret
-derived from the shared secret key or password/passphrase.  The exact form of
-the data used to create the session ID is application specific (but see the
-comment in the security considerations).  The data used to create the session
-ID is zero-padded to 16 bytes (128 bits) if necessary to meet the requirements
-given in section 2.1.  In C this may be expressed as:
-
-  memset( session_id, 0, 16 );
-  memcpy( session_id, input_data, min( input_data_length, 16 ) );
-
-The master secret used to seed the cache is computed in the standard manner
-using the TLS PRF:
-
-  master_secret = PRF(shared_secret, "shared secret", "")[0..47];
-
-The shared secret or password/passphrase takes the place of the premaster
-secret that is normally used at this point, arranged as follows: First, the
-shared secret/password has a single length byte prepended to it.  The length +
-secret value is then repeated as required to fill the standard 48 bytes.  In C
-this may be expressed as:
-
-  for( premaster_index = 0; premaster_index < 48; )
-    {
-    int i;
-
-    premaster_secret[ premaster_index++ ] = shared_secret_length;
-    for( i = 0; i < shared_secret_length && premaster_index < 48; i++ )
-      premaster_secret[ premaster_index++ ] = shared_secret[ i ];
-    }
-
-This formats the shared secret in a manner that allows it to be used directly
-in place of the standard premaster secret derived from the public-key-based
-key agreement process.
-
-The 'seed' component of the calculation (normally occupied by the client and
-server nonces) is empty in this case, however applications may choose to use
-an application or system-specific value to ensure that the same shared secret
-used with another application or system yields a different master secret.
-When the 'seed' component is non-empty, it should not contain information
-computed from the shared_secret value [SIGMA].  Note that the use of the
-client and server nonces will always produce different keys for each session,
-even if the same master secret is employed.
-
-The final step involves injecting the session ID and master secret into the
-session cache.  This is an implementation-specific issue beyond the scope of
-this document.  All further steps are handled automatically by the TLS
-protocol, which will "resume" the phantom session created by the above steps
-without going through the full public-key-based handshake.
-
-Session cache entries are normally expired after a given amount of time, or
-overwritten on an LRU basis.  In order to prevent shared secret-based entries
-from vanishing after a certain amount of time, these cache entries will need
-to be distinguished from standard cache entries and made more persistent then
-the latter, for example by giving them a longer expiry time when they are
-added or periodically touching them to update their last-access time.  Again,
-this is an implementation issue beyond the scope of this document.
-
-3.1 Use of shared keys with SSLv3
-
-If this key management mechanism is used with an implementation that supports
-SSLv3 alongside TLS (as most do), the TLS PRF must be used for both SSLv3 and
-TLS.  This is required in order to allow the mechanism to function for both
-SSLv3 and TLS, since using different PRFs would require a different session ID
-for each PRF used.
-
-3.2 Test vectors
-
-The following test vectors are derived from the transformation of the password
-"test" into a master_secret value to be added to the session cache:
-
-  Shared secret:
-
-    74 65 73 74   ("test")
-
-  Shared secret expanded to 48-byte premaster secret size:
-
-    04 74 65 73 74 04 74 65
-    73 74 04 74 65 73 74 04
-    ...
-
-  Master secret added to session cache:
-
-    F5 CE 30 92 B8 09 70 D9
-    22 D5 A1 2C EB 7C 43 FA
-    9C 46 A8 83 EA 6E EF 98
-    EB A5 15 12 FD B1 B6 5A
-    5A 47 B8 C4 C5 63 5B 30
-    86 96 F4 FC FB D5 45 78
-
-4. Security considerations
-
-The session ID used to identify sessions is visible to observers.  While using
-a user name as the session ID is the most straightforward option, it may lead
-to problems with traffic analysis, with an attacker being able to track the
-identities of communicating parties.  In addition since the session ID is
-reused over time, traffic analysis may eventually allow an attacker to
-identify parties even if an opaque session ID is used.  [RFC 2246] contains a
-similar warning about the contents of session IDs with TLS in general.  It
-should be noted though that even a worse-case non-opaque session ID results in
-no more exposure than the use of client certificates during a handshake.
-
-As with all schemes involving shared keys, special care should be taken to
-protect the shared values and to limit their exposure over time.  Documents
-covering other shared-key protocols such as Kerberos [RFC 1510] contain
-various security suggestions in this regard.
-
-Use of a fixed shared secret of limited entropy (for example a password)
-allows an attacker to perform an online password-guessing attack by trying to
-resume a session with a master secret derived from each possible password.
-This results in a fatal decrypt_error alert (or some equivalent such as
-handshake_failure or bad_record_mac) which makes the session non-resumable
-(that is, it clears the phantom session from the session cache).
-Implementations should limit the enthusiasm with which they re-seed the
-session cache after such an event; standard precautions against online
-password-guessing attacks apply.
-
-This mechanism is purely a shared-key session establishment mechanism and does
-not provide perfect forward secrecy (PFS) by negotiating additional new keying
-material for each session.  Users requiring PFS can either use a shared-key
-mechanism that also provides PFS such as SRP [SRP], or perform a rehandshake
-using a standard PFS-providing mechanism over the shared key-protected
-channel.  Note though that both of these mechanisms negate the two main
-advantages of the shared-key mechanism, requiring both considerable re-
-engineering of an existing TLS implementation and considerable CPU time to
-perform the PFS cryptographic operations.
-
-Since it does not contain an innate cryptographic mechanism to provide PFS,
-the shared-key mechanism is vulnerable to an offline password-guessing attack
-as follows: An attacker who records all of the handshake messages and knows
-the plaintext for at least one encrypted message can perform the TLS key-
-derivation using a selection of guessed passwords, perform the cryptographic
-operations required to process the TLS handshake exchange, and then apply the
-resulting cryptographic keys to the known-plaintext message.  Such an attack
-consumes considerable time and CPU resources, but is nevertheless possible.
-
-There are three possible defences against this type of attack, the first two
-of which are standard defences against password-guessing attacks:
-
-1. Don't use weak, easily-guess passwords or keys.
-
-2. Perform iterated pre-processing of the password/key before adding it to the
-   session cache.  This has the disadvantage that it negates the shared-key
-   advantage of low CPU consumption during the handshake phase, however the
-   preprocessing can be performed offline on a one-off basis and only the
-   preprocessed key stored by the two communicating parties.  An attacker can,
-   however, also generate a dictionary of pre-processed keys offline, given
-   sufficient CPU and storage space.  The use of a per-server diversifier
-   ('seed' in the PRF process) makes use of a precomputed dictionary
-   impractical, and a secret diversifier makes a general offline attack
-   considerably more difficult through to impossible depending on the
-   circumstances.
-
-3. Use a mechanism that allows for the use of shared keys but also provides
-   PFS, with the advantages and disadvantages described earlier.
-
-Note that the two password-guessing attacks possible against the shared-key
-mechanism, while superficially similar, have quite different requirements on
-the attacker's side.  An online attack merely requires that the attacker know
-the URL of the server that they wish to attack.  An offline attack requires
-that an attacker both know the URL of the server that they wish to attack and
-be able to record complete sessions between the client and the server in order
-to provide the material required for the offline attack.
-
-The TLS specification requires that when a session is resumed, the resumed
-session use the same cipher suite as the original one.  Since with a shared-
-secret session there is no actual session being resumed, it's not possible to
-meet this requirement.  Two approaches are possible to resolve this:
-
-1. When the session cache is seeded on the server, a cipher suite acceptable
-   to the server is specified for the resumed session.  This complies with the
-   requirements, but requires that the server know that the client is capable
-   of supporting this particular suite.  In closed environments (for example
-   syncing to a host PC or a fixed base station, or in a mainframe
-   environment) this is likely to be the case.
-
-2. The requirements are relaxed to allow the client and server to negotiate a
-   cipher suite in the usual manner.  In order to subvert this, an attacker
-   would have to be able to perform a real-time simultaneous break of both
-   HMAC-MD5 and HMAC-SHA1.  In particular the attacker would need to be able
-   to subvert:
-
-     HMAC( secret, PRF( secret, MD5+SHA1 hash ) )
-
-   in the Finished message, which expands to:
-
-     HMAC( secret, HMAC-MD5^HMAC-SHA1( secret, MD5+SHA1 hash ) )
-
-   Because of the unlikeliness of this occurring (an attacker capable of doing
-   this can subvert any TLS session, with or without shared secrets), it
-   appears safe to relax the requirement for resuming with the same cipher
-   suite.
-
-References (Normative)
-
-  [RFC 2119] "Key words for use in RFCs to Indicate Requirement Levels",
-             Scott Bradner, RFC 2119, March 1997.
-
-  [RFC 2246] "The TLS Protocol", RFC 2246, Tim Dierks and Christopher
-             Allen, January 1999.
-
-References (Informative)
-
-  [RFC 1510] "The Kerberos Network Authentication Service (V5)",
-             RFC 1510, John Kohl and B. Clifford Neuman, September
-             1993.
-
-  [SIGMA] "SIGMA: the `SIGn-and-MAc' Approach to Authenticated
-          Diffie-Hellman and its Use in the IKE Protocols", Hugo
-          Krawczyk, Proceedings of of Crypto'03, Springer-Verlag
-          Lecture Notes in Computer Science No.2729, p.399.
-
-  [SRP] "Using SRP for TLS Authentication", David Taylor, IETF draft,
-        November 2002.
-
-Author's Address
-
-Peter Gutmann
-University of Auckland
-Private Bag 92019
-Auckland, New Zealand
-
-Email: pgut001@cs.auckland.ac.nz
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-This document and translations of it may be copied and furnished to others,
-and derivative works that comment on or otherwise explain it or assist in its
-implementation may be prepared, copied, published and distributed, in whole or
-in part, without restriction of any kind, provided that the above copyright
-notice and this paragraph are included on all such copies and derivative
-works.  However, this document itself may not be modified in any way, such as
-by removing the copyright notice or references to the Internet Society or
-other Internet organizations, except as needed for the purpose of developing
-Internet standards in which case the procedures for copyrights defined in the
-Internet Standards process must be followed, or as required to translate it
-into languages other than English.
-
-The limited permissions granted above are perpetual and will not be revoked by
-the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an "AS IS"
-basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
-DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
-WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
-OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
-PURPOSE.
-
-Acknowledgement
-
-Funding for the RFC Editor function is currently provided by the Internet
-Society.
diff --git a/doc/protocol/draft-ietf-tls-srp-00.txt b/doc/protocol/draft-ietf-tls-srp-00.txt
deleted file mode 100644
index 814b9205e7..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-00.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-Network Working Group                                          D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: August 6, 2001                                 February 5, 2001
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-00.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 6, 2001.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the SRP (Secure Remote
-   Password) protocol as an authentication method for the TLS
-   (Transport Layer Security) protocol. 
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires August 6, 2001                 [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-1. Introduction
-
-   At the time of writing, TLS[1] uses public key certificiates with
-   RSA/DSA digital signatures, or Kerberos, for authentication. 
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS (IMAP[3], FTP[4], or
-   TELNET[5], for example). Given these protocols (and others like
-   them) are designed to use the user name and password method of
-   authentication, being able to use user names and passwords to
-   authenticate the TLS connection seems to be a useful feature. 
-
-   SRP[2] is an authentication method that allows the use of user names
-   and passwords in a safe manner. 
-
-   This document describes the use of the SRP authentication method for
-   TLS. 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires August 6, 2001                 [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-2. SRP Authentication in TLS
-
-2.1 Modifications to the TLS Handshake Sequence
-
-   The SRP protocol can not be implemented using the sequence of
-   handshake messages defined in [1] due to the sequence in which the
-   SRP messages must be sent. 
-
-   This document proposes a new sequence of handshake messages for
-   handshakes using the SRP authentication method. 
-
-2.1.1 Message Sequence
-
-   Handshake Message Flow for SRP Authentication
-
-          Client                                 Server
-            |                                      |
-       Client Hello (U) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Server Key Exchange (g, N, s)
-       Client Key Exchange (A) ----------------->  |
-            |  <---------------------------- Server Key Exchange (B)
-            |  <---------------------------- Server Hello Done
-       change cipher spec                          |
-       Finished -------------------------------->  |
-            |                                change cipher spec
-            |  <---------------------------- Finished
-            |                                      |
-
-   The identifiers given after each message name refer to variables
-   defined in [2] that are sent in that message.
-
-   This new handshake sequence has a number of differences from the
-   standard TLS handshake sequence: 
-
-   o  The client hello message has the user name appended to the
-      message. This is allowable as stated in section 7.4.1.2 of [1]. 
-
-   o  The client cannot generate its its public key (A) until after it
-      has received the (g) and (N) paramters from the server, and the
-      client must send its public key before it receives the servers
-      public key (B) (as stated in section 3 of [2]). This means the
-      client must wait for a server key exchange message containing (g)
-      and (N), send a client key exchange message containing (A), and
-      then wait for another server key exchange message containing (B). 
-
-   o  There is no server identification in this version of a TLS
-      handshake. If an attacker gets the SRP password file, they can
-      masquerade as the real system. 
-
-
-Taylor                   Expires August 6, 2001                 [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-2.2 Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication. The details of
-   the on-the-wire changes are given in Section 2.5. 
-
-2.2.1 The Client Hello Message
-
-   The user name is appended to the standard client hello message. The
-   extra data is included in the handshake message hashes. 
-
-2.2.2 The First Server Key Exchange Message
-
-   The server key exchange message in the first round contains the
-   generator (g), the prime (N), and the salt value (s) read from the
-   SRP password file. 
-
-2.2.3 The Client Key Exchange Message
-
-   The client key exchange message carries the clients public key (A),
-   which is calculated using both information known locally, and
-   information received in the first server key exchange message. This
-   message MUST be sent between the first and second server key
-   exchange messages. 
-
-2.2.4 The Second Server Key Exchange Message
-
-   The server key exchange message in the second round contains the
-   servers public key (B). 
-
-2.3 Calculating the Pre-master Secret
-
-   The shared secret resulting from the SRP calculations (S) is used as
-   the pre-master secret. 
-
-   The finished messages perform the same function as the client and
-   server evidence messages specified in [2]. If either the client or
-   the server calculate an incorrect value, the finished messages will
-   not be understood, and the connection will be dropped as specified
-   in [1]. 
-
-2.4 Cipher Suite Definitions
-
-   The following cipher suites are added by this draft. The numbers
-   have been left blank until a suitable range has been selected. 
-
-      CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_SHA       = { ?,? };
-
-      CipherSuite     TLS_SRP_WITH_RC4_128_SHA            = { ?,? };
-
-
-Taylor                   Expires August 6, 2001                 [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-      CipherSuite     TLS_SRP_WITH_IDEA_CBC_SHA           = { ?,? };
-
-      CipherSuite     TLS_SRP_WITH_3DES_EDE_CBC_MD5       = { ?,? };
-
-      CipherSuite     TLS_SRP_WITH_RC4_128_MD5            = { ?,? };
-
-      CipherSuite     TLS_SRP_WITH_IDEA_CBC_MD5           = { ?,? };
-
-2.5 New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication. The representation
-   language used is that used in [1]. 
-
-   opaque Username<1..2^8-1>;
-
-   enum { non_srp, srp } CipherSuiteType;
-
-   struct {
-      ProtocolVersion client_version;
-      Random random;
-      SessionID session_id;
-      CipherSuite cipher_suites<2..2^16-1>;
-
-      /* Need a better way to show the optional user_name field */
-      select (CipherSuiteType) {
-         case non_srp:
-            CompressionMethod compression_methods<1..2^8-1>;
-         case srp:
-            CompressionMethod compression_methods<1..2^8-1>;
-            Username user_name;   /* new entry */
-      };
-   } ClientHello;
-
-   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-   enum { first, second } KeyExchangeRound;
-
-   struct {
-      select (KeyExchangeRound) {
-         case first:
-            opaque srp_s<1..2^8-1>
-            opaque srp_N<1..2^16-1>;
-            opaque srp_g<1..2^16-1>;
-         case second:
-            opaque srp_B<1..2^16-1>;
-      };
-   } ServerSRPParams;     /* SRP parameters */
-
-
-
-Taylor                   Expires August 6, 2001                 [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case diffie_hellman:
-            ServerDHParams params;
-            Signature signed_params;
-         case rsa:
-            ServerRSAParams params;
-            Signature signed_params;
-         case srp:
-            ServerSRPParams params;   /* new entry */
-      };
-   } ServerKeyExchange;
-
-   struct {
-      opaque srp_A<1..2^16-1>;
-   } SRPClientEphemeralPublic;
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case rsa: EncryptedPreMasterSecret;
-         case diffie_hellman: ClientDiffieHellmanPublic;
-         case srp: SRPClientEphemeralPublic;   /* new entry */
-      } exchange_keys;
-   } ClientKeyExchange;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires August 6, 2001                 [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-3. Security Considerations
-
-   There is no server identification in this version of a TLS
-   handshake. If an attacker gets the SRP password file, they can
-   masquerade as the real system. 
-
-   What are the security issues of this new handshake sequence? Are the
-   SRP parameters passed in a safe order? Is it a problem having the
-   username appended to the client hello message? 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires August 6, 2001                 [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-        1999.
-
-   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
-        2945, September 2000.
-
-   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
-        June 1999.
-
-   [4]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
-        V. Wiegand, "Securing FTP with TLS",
-        draft-murray-auth-ftp-ssl-06 (work in progress), September 2000.
-
-   [5]  Boe, M. and J. Altman, "TLS-based Telnet Security",
-        draft-ietf-tn3270e-telnet-tls-05 (work in progress), October
-        2000.
-
-
-Author's Address
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.protekt.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires August 6, 2001                 [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication       February 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph
-   are included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires August 6, 2001                 [Page 9]
-
diff --git a/doc/protocol/draft-ietf-tls-srp-01.txt b/doc/protocol/draft-ietf-tls-srp-01.txt
deleted file mode 100644
index f122ddd944..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-01.txt
+++ /dev/null
@@ -1,728 +0,0 @@
-
-
-Network Working Group                                          D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: December 28, 2001                                 June 29, 2001
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-01
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 28, 2001.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the SRP (Secure Remote
-   Password) protocol as an authentication method for the TLS (Transport
-   Layer Security) protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001               [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
-   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
-   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
-   2.1.2 Session re-use . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
-   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
-   2.3.1 The Client Hello Message . . . . . . . . . . . . . . . . . .  6
-   2.3.2 The Server Hello Message . . . . . . . . . . . . . . . . . .  6
-   2.3.3 The Client Key Exchange Message  . . . . . . . . . . . . . .  6
-   2.3.4 The Server Key Exchange Message  . . . . . . . . . . . . . .  6
-   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
-   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
-   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
-   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
-   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
-   2.6.5 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  9
-   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
-         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
-   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001               [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-1. Introduction
-
-   At the time of writing, TLS [1] uses public key certificiates with
-   RSA/DSA digital signatures, or Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS (IMAP [3], FTP [4], or
-   TELNET [5], for example).  Given these protocols (and others like
-   them) are designed to use the user name and password method of
-   authentication, being able to use user names and passwords to
-   authenticate the TLS connection seems to be a useful feature.
-
-   SRP [2] is an authentication method that allows the use of user names
-   and passwords over unencrypted channels without revealing the
-   password to an eavesdropper.  SRP also supplies a shared secret at
-   the end of the authetication sequence that can be used to generate
-   encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001               [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-2. SRP Authentication in TLS
-
-2.1 Modifications to the TLS Handshake Sequence
-
-   The SRP protocol can not be implemented using the sequence of
-   handshake messages defined in [1] due to the sequence in which the
-   SRP messages must be sent.
-
-   This document proposes a new sequence of handshake messages for
-   handshakes using the SRP authentication method.
-
-2.1.1 Message Sequence
-
-   Handshake Message Flow for SRP Authentication
-
-          Client                                 Server
-            |                                      |
-       Client Hello (U, mds)-------------------->  |
-            |  <---------------------------- Server Hello (md, g, N, s)
-       Client Key Exchange (A) ----------------->  |
-            |  <---------------------------- Server Key Exchange (B)
-            |  <---------------------------- Server Hello Done
-       change cipher spec                          |
-       Finished -------------------------------->  |
-            |                                change cipher spec
-            |  <---------------------------- Finished
-            |                                      |
-
-   The identifiers given after each message name refer to the SRP
-   variables included in that message.  The variables are defined in
-   [2], except for (mds) and (md) which are defined in this document.
-
-   Extended client and server hello messages, as defined in [6], are
-   used to to send the initial client and server values.
-
-   The client key exchange message is sent during the sequence of server
-   messages.  This modification is required because the client must send
-   its public key (A) before it receives the servers public key (B), as
-   stated in Section 3 of [2].
-
-2.1.2 Session re-use
-
-   The short handshake mechanism for re-using sessions for new
-   connections, and renegotiating keys for existing connections will
-   still work with the SRP authentication mechanism and handshake.
-
-   When a client attemps to re-use a session that uses SRP
-   authentication, it MUST still include the SRP extension carrying the
-
-
-
-Taylor                  Expires December 28, 2001               [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-   user name (U) in the client hello message, in case the server cannot
-   or will not allow re-use of the session, meaning a full handshake
-   sequence is required.
-
-   If a client requests an existing session and the server agrees to use
-   it (meaning the short handshake will be used), the server MAY omit
-   the SRP extension from the server hello message, as the information
-   it contains is not used in the short handshake.
-
-2.2 SRP Verifier Message Digest Selection
-
-   SRP uses a message digest algorithm when creating password verifiers,
-   and when performing calculations during authentication.  At the time
-   of writing, SHA-1 is the only algorithm that has been defined for use
-   with SRP.  However, there is no reason other message digest
-   algorithms cannot be used, and the handshake messages and extensions
-   defined by this draft include a message digest algorithm selection
-   mechanism.
-
-   The passwordMessageDigest enumerated, the srp_mds vector, and srp_md
-   value are used to determine which message digest alorithm is to be
-   used by the client when it is performing the SRP calculation.  The
-   server determines which message digest algorithm to use based on the
-   list of message digest algorithms requested by the client, and the
-   list of available SRP verifiers known by the server.
-
-   The client sends a list of message digest algorithms it can use for
-   the SRP calculation using the srp_mds vector.  The server MUST select
-   a message digest algorithm that is in the list supplied by the
-   client, and the server MUST have access to an SRP verifier calculated
-   with the selected message digest algorithm.
-
-   If the server has access to multiple SRP verifiers for the given user
-   (each calculated using a different message disgest algorithm), the
-   server may select whichever matching message digest algorithm it
-   chooses, so long as the selected message digest algorithm appears in
-   the list sent by the client.
-
-   If the server does not have an SRP verifier calculated with any of
-   the message digest algorithms suggested by the client, the server
-   must send a handshake failure alert.
-
-2.3 Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitons
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.6.
-
-
-
-Taylor                  Expires December 28, 2001               [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-2.3.1 The Client Hello Message
-
-   The user name is appended to the standard client hello message using
-   the client hello extension mechanism defined in [6].
-
-   The list of message digests the client can use is also included.
-   This list represents all the message digests the client can use for
-   the SRP calculations.
-
-2.3.2 The Server Hello Message
-
-   The message digest selected by the server (md), the generator (g),
-   the prime (N), and the salt value (s) read from the SRP password file
-   are appended to the server hello message using the client hello
-   extension mechanism defined in [6].
-
-2.3.3 The Client Key Exchange Message
-
-   The client key exchange message carries the client's public key (A),
-   which is calculated using both information known locally, and
-   information received in the server hello message.  This message MUST
-   be sent before the server key exchange message.
-
-2.3.4 The Server Key Exchange Message
-
-   The server key exchange message contains the servers public key (B).
-   The server key exchange message MUST be sent after the client key
-   exchange message.
-
-2.4 Calculating the Pre-master Secret
-
-   The shared secret resulting from the SRP calculations (S) (defined in
-   [2]) is used as the pre-master secret.
-
-   The finished messages perform the same function as the client and
-   server evidence messages specified in [2].  If either the client or
-   the server calculate an incorrect value, the finished messages will
-   not be understood, and the connection will be dropped as specified in
-   [1].
-
-2.5 Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The numbers
-   have been selected based on other RFCs and Internet Drafts that were
-   current at the time of writing, so may need to be changed in future.
-
-      CipherSuite   TLS_SRP_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x5B };
-
-
-
-
-Taylor                  Expires December 28, 2001               [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-      CipherSuite   TLS_SRP_WITH_RC4_128_SHA          = { 0x00,0x5C };
-
-      CipherSuite   TLS_SRP_WITH_IDEA_CBC_SHA         = { 0x00,0x5D };
-
-      CipherSuite   TLS_SRP_WITH_3DES_EDE_CBC_MD5     = { 0x00,0x5E };
-
-      CipherSuite   TLS_SRP_WITH_RC4_128_MD5          = { 0x00,0x5F };
-
-      CipherSuite   TLS_SRP_WITH_IDEA_CBC_MD5         = { 0x00,0x60 };
-
-
-2.6 New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [1].
-
-   When encoding the numbers g, N, A, and B as opaque types, if the most
-   significant bit is set, an extra byte of value 0x00 (all bits
-   cleared) MUST be added as the most significant byte.  This is done as
-   a safeguard against implementations that do not assume these numbers
-   are positive.
-
-2.6.1 ExtensionType
-
-   A new value, "srp(6)", has been added to the enumerated
-   ExtensionType, defined in [6].  This value is used as the extension
-   number for the extensions in both the client hello message and the
-   server hello message.  This value was chosen based on the version of
-   defined in [6] that was current at the time of writing, so may be
-   changed in future.
-
-2.6.2 Client Hello
-
-   The user name (U) and a list of message digests (srp_mds) are encoded
-   in an SRPExtension structure, and sent in an extended client hello
-   message, using an extension of type "srp".
-
-   The list of message digests represents the list of message digests
-   the client can use for the SRP calculations.
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001               [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-   enum { client, server } ClientOrServerExtension;
-
-   enum  { sha-1(0), (255) } PasswordMessageDigest;
-
-   struct {
-      select(ClientOrServerExtension) {
-         case client:
-            opaque srp_U<1..2^8-1>;
-            PasswordMessageDigest srp_mds<1..2^8-1>;
-         case server:
-            PasswordMessageDigest srp_md;
-            opaque srp_s<1..2^8-1>
-            opaque srp_N<1..2^16-1>;
-            opaque srp_g<1..2^16-1>;
-      }
-   } SRPExtension;
-
-
-2.6.3 Server Hello
-
-   The message digest selected by the server (md), the generator (g),
-   the prime (N), and the salt value (s) are encoded in an SRPExtension
-   structure, which is sent in an extended server hello message, using
-   an extension of type "srp".
-
-   The SRPParams structure is defined above.
-
-2.6.4 Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   ephemeral public key (A) is sent in the client key exchange message,
-   encoded in an ClientSRPPublic structure.
-
-   An extra value, srp, has been added to the enumerated
-   KeyExchangeAlgorithm, originally defined in TLS [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001               [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case rsa: EncryptedPreMasterSecret;
-         case diffie_hellman: ClientDiffieHellmanPublic;
-         case srp: ClientSRPPublic;   /* new entry */
-      } exchange_keys;
-   } ClientKeyExchange;
-
-   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-   struct {
-      opaque srp_A<1..2^16-1>;
-   } ClientSRPPublic;
-
-
-2.6.5 Server Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   ephemeral public key (B) is sent in the server key exchange message,
-   encoded in an ServerSRPPublic structure.
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case diffie_hellman:
-            ServerDHParams params;
-            Signature signed_params;
-         case rsa:
-            ServerRSAParams params;
-            Signature signed_params;
-         case srp:
-            ServerSRPPublic;   /* new entry */
-      };
-   } ServerKeyExchange;
-
-   struct {
-      opaque srp_B<1..2^16-1>;
-   } ServerSRPPublic;     /* SRP parameters */
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001               [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-3. Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real host.  Filesystem based X.509 certificate
-   installations are vulnerable to a similar attack unless the servers
-   certificate is issued from a PKI that maintains revocation lists, and
-   the client TLS code can both contact the PKI and make use of the
-   revocation list.
-
-   Not all clients and servers will be able to interoperate once the
-   number of message digest algorithms used for creating password
-   verifiers is increased.  For example, a client may only support SHA-
-   1, whereas the verifiers on the server were created with a different
-   message digest algoritm.
-
-   Because the initial handshake messages are unprotected, an attacker
-   can modify the list of message digests in the client hello message.
-   For example, an attacker could rewrite the message to remove all but
-   the weakest message digest.  There is no way to know this has
-   happened until the finished messages are compared.
-
-   An attacker can also modify the server hello message to use a
-   different message digest than that selected by the server.  If this
-   happens, the handshake will fail after the change cipher spec
-   messages are sent, as the client and server will have calculated
-   different pre-master secret vales.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001              [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-        1999.
-
-   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
-        2945, September 2000.
-
-   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
-        1999.
-
-   [4]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
-        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
-        06 (work in progress), September 2000.
-
-   [5]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
-        tn3270e-telnet-tls-05 (work in progress), October 2000.
-
-   [6]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
-        Wright, "TLS Extensions", draft-ietf-tls-extensions-00 (work in
-        progress), June 2001.
-
-
-Author's Address
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001              [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-Appendix A. Acknowledgements
-
-   The following people have contributed ideas and time to this draft:
-   Raif Naffah, Tom  Wu, Nikos Mavroyanopoulos
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001              [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                  Expires December 28, 2001              [Page 13]
-
diff --git a/doc/protocol/draft-ietf-tls-srp-02.txt b/doc/protocol/draft-ietf-tls-srp-02.txt
deleted file mode 100644
index 1a438dc7c3..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-02.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-Transport Layer Security Working                               D. Taylor
-Group                                             Forge Research Pty Ltd
-Internet-Draft                                           August 21, 2002
-Expires: February 19, 2003
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-02
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on February 19, 2003.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the SRP [2] (Secure Remote
-   Password) protocol as an authentication method for the TLS
-   [1](Transport Layer Security) protocol.
-
-
-
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003                [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
-   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
-   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
-   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
-   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
-   2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.2 Server hello . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.3 Server certificate . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  6
-   2.3.5 Server key exchange  . . . . . . . . . . . . . . . . . . . .  6
-   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
-   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
-   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
-   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
-   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
-   2.6.5 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
-   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
-         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
-   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003                [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-1. Introduction
-
-   At the time of writing, TLS uses public key certificiates with RSA/
-   DSA digital signatures, or Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS (IMAP [3], FTP [5], or
-   TELNET [6], for example).  Given these protocols (and others like
-   them) are designed to use the user name and password method of
-   authentication, being able to safely use user names and passwords to
-   authenticate the TLS connection provides a much easier route to
-   additional security than implementing a public key infrastructure in
-   certain situations.
-
-   SRP is an authentication method that allows the use of user names and
-   passwords over unencrypted channels without revealing the password to
-   an eavesdropper.  SRP also supplies a shared secret at the end of the
-   authetication sequence that can be used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003                [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-2. SRP Authentication in TLS
-
-2.1 Modifications to the TLS Handshake Sequence
-
-   The SRP protocol can not be implemented using the sequence of
-   handshake messages defined in [1] due to the sequence in which the
-   SRP messages must be sent.
-
-   This document presents a new sequence of handshake messages for
-   handshakes using the SRP authentication method.
-
-2.1.1 Message Sequence
-
-   Handshake Message Flow for SRP Authentication
-
-          Client                                 Server
-            |                                      |
-       Client Hello (U) ------------------------>  |
-            |  <---------------------------- Server Hello (g, N, s)
-            |  <---------------------------- Certificate*
-       Client Key Exchange (A) ----------------->  |
-            |  <---------------------------- Server Key Exchange (B)
-            |  <---------------------------- Server Hello Done
-       change cipher spec                          |
-       Finished -------------------------------->  |
-            |                                change cipher spec
-            |  <---------------------------- Finished
-            |                                      |
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-   The identifiers given after each message name refer to the SRP
-   variables included in that message.  The variables U, g, N, s, A, and
-   B are defined in [2].
-
-   Extended client and server hello messages, as defined in [7], are
-   used to to send the initial client and server values.
-
-   The client key exchange message is sent during the sequence of server
-   messages.  This modification is required because the client must send
-   its public key (A) before it receives the servers public key (B), as
-   stated in Section 3 of [2].
-
-2.1.2 Session Re-use
-
-   The short handshake mechanism for re-using sessions for new
-   connections, and renegotiating keys for existing connections will
-
-
-
-Taylor                 Expires February 19, 2003                [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-   still work with the SRP authentication mechanism and handshake.
-
-   When a client attemps to re-use a session that uses SRP
-   authentication, it MUST still include the SRP extension carrying the
-   user name (U) in the client hello message, in case the server cannot
-   or will not allow re-use of the session, meaning a full handshake
-   sequence is required.
-
-   If a client requests an existing session and the server agrees to use
-   it (meaning the short handshake will be used), the server MAY omit
-   the SRP extension from the server hello message, as the information
-   it contains is not used in the short handshake.
-
-2.2 SRP Verifier Message Digest Selection
-
-   The cipher suites defined in this document use the SHA-1 message
-   digest with the SRP algorithm, as specified in [2].  Implementations
-   conforming to this document MUST use the SHA-1 message digest.
-
-   Future documents may define other cipher suites that use different
-   message digests, or other similar functions, with the SRP algorithm.
-
-2.3 Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.6.
-
-2.3.1 Client hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [7].
-
-2.3.2 Server hello
-
-   The the generator (g), the prime (N), and the salt value (s) read
-   from the SRP password file are appended to the server hello message
-   using the hello message extension mechanism defined in [7].
-
-2.3.3 Server certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.5 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-
-
-
-Taylor                 Expires February 19, 2003                [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-   Because the server's certificate is only used for generating a
-   digital signature in SRP cipher suites, the certificate sent MUST
-   contain a public key that can be used for generating digital
-   signatures.
-
-2.3.4 Client key exchange
-
-   The client key exchange message carries the client's public key (A),
-   which is calculated using both information known locally, and
-   information received in the server hello message.  This message MUST
-   be sent before the server key exchange message.
-
-2.3.5 Server key exchange
-
-   The server key exchange message contains the server's public key (B).
-   The server key exchange message MUST be sent after the client key
-   exchange message.
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-2.4 Calculating the Pre-master Secret
-
-   The shared secret resulting from the SRP calculations (S) (defined in
-   [2]) is used as the pre-master secret.
-
-   The finished messages perform the same function as the client and
-   server evidence messages specified in [2].  If either the client or
-   the server calculate an incorrect value, the finished messages will
-   not be understood, and the connection will be dropped as specified in
-   [1].
-
-2.5 Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [4].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-
-
-
-Taylor                 Expires February 19, 2003                [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that do not include a digitial signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP database.
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.6 New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [1].
-
-   When encoding the numbers g, N, A, and B as opaque types, if the most
-   significant bit is set, an extra byte of value 0x00 (all bits
-   cleared) MUST be added as the most significant byte.  This is done as
-   a safeguard against implementations that do not assume these numbers
-   are positive.
-
-2.6.1 ExtensionType
-
-   A new value, "srp(6)", has been added to the enumerated
-   ExtensionType, defined in [7].  This value is used as the extension
-   number for the extensions in both the client hello message and the
-   server hello message.
-
-2.6.2 Client Hello
-
-   The user name (U) is encoded in an SRPExtension structure, and sent
-   in an extended client hello message, using an extension of type
-   "srp".
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003                [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-   enum { client, server } ClientOrServerExtension;
-
-   struct {
-      select(ClientOrServerExtension) {
-         case client:
-            opaque srp_U<1..2^8-1>;
-         case server:
-            opaque srp_s<1..2^8-1>
-            opaque srp_N<1..2^16-1>;
-            opaque srp_g<1..2^16-1>;
-      }
-   } SRPExtension;
-
-
-2.6.3 Server Hello
-
-   The generator (g), the prime (N), and the salt value (s) are encoded
-   in an SRPExtension structure, which is sent in an extended server
-   hello message, using an extension of type "srp".
-
-2.6.4 Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   ephemeral public key (A) is sent in the client key exchange message,
-   encoded in an ClientSRPPublic structure.
-
-   An extra value, srp, has been added to the enumerated
-   KeyExchangeAlgorithm, originally defined in TLS [1].
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case rsa: EncryptedPreMasterSecret;
-         case diffie_hellman: ClientDiffieHellmanPublic;
-         case srp: ClientSRPPublic;   /* new entry */
-      } exchange_keys;
-   } ClientKeyExchange;
-
-   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-   struct {
-      opaque srp_A<1..2^16-1>;
-   } ClientSRPPublic;
-
-
-2.6.5 Server Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   ephemeral public key (B) is sent in the server key exchange message,
-
-
-
-Taylor                 Expires February 19, 2003                [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-   encoded in an ServerSRPPublic structure.
-
-   The following table gives the SignatureAlgorithm value to be used for
-   each ciphersuite.
-
-      Ciphersuite                            SignatureAlgorithm
-
-      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
-
-      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
-
-      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
-
-      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
-
-      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
-
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case diffie_hellman:
-            ServerDHParams params;
-            Signature signed_params;
-         case rsa:
-            ServerRSAParams params;
-            Signature signed_params;
-         case srp:   /* new entry */
-            ServerSRPPublic params;
-            Signature signed_params;
-      };
-   } ServerKeyExchange;
-
-   struct {
-      opaque srp_B<1..2^16-1>;
-   } ServerSRPPublic;     /* SRP parameters */
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003                [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-3. Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real host.  Filesystem based X.509 certificate
-   installations are vulnerable to a similar attack unless the server's
-   certificate is issued from a PKI that maintains revocation lists, and
-   the client TLS code can both contact the PKI and make use of the
-   revocation list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003               [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-        1999.
-
-   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
-        2945, September 2000.
-
-   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
-        1999.
-
-   [4]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-        Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [5]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
-        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
-        09 (work in progress), April 2002.
-
-   [6]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
-        tn3270e-telnet-tls-06 (work in progress), April 2002.
-
-   [7]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
-        Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
-        progress), July 2002.
-
-
-Author's Address
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003               [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-Appendix A. Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003               [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                 Expires February 19, 2003               [Page 13]
-
-
diff --git a/doc/protocol/draft-ietf-tls-srp-03.txt b/doc/protocol/draft-ietf-tls-srp-03.txt
deleted file mode 100644
index 65ee1660e1..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-03.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-Transport Layer Security Working                               D. Taylor
-Group                                             Forge Research Pty Ltd
-Internet-Draft                                         September 4, 2002
-Expires: March 5, 2003
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-03
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on March 5, 2003.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the SRP [2] (Secure Remote
-   Password) protocol as an authentication method for the TLS
-   [1](Transport Layer Security) protocol.
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
-   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
-   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
-   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
-   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
-   2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.2 Server hello . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.3 Server certificate . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  6
-   2.3.5 Server key exchange  . . . . . . . . . . . . . . . . . . . .  6
-   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
-   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
-   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
-   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
-   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
-   2.6.5 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
-   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
-         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
-   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-1. Introduction
-
-   At the time of writing, TLS uses public key certificiates with RSA/
-   DSA digital signatures, or Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS (IMAP [3], FTP [5], or
-   TELNET [6], for example).  Given these protocols (and others like
-   them) are designed to use the user name and password method of
-   authentication, being able to safely use user names and passwords to
-   authenticate the TLS connection provides a much easier route to
-   additional security than implementing a public key infrastructure in
-   certain situations.
-
-   SRP is an authentication method that allows the use of user names and
-   passwords over unencrypted channels without revealing the password to
-   an eavesdropper.  SRP also supplies a shared secret at the end of the
-   authetication sequence that can be used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-   Changes in this version:
-
-      Changed the order of the s, N, and g parameters for the Server
-      Hello message in the handshake sequence diagram to conform to the
-      SRPExtension structure.
-
-      Removed the requirement to add leading zeros to encoded numbers
-      whose most significant bit is set.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-2. SRP Authentication in TLS
-
-2.1 Modifications to the TLS Handshake Sequence
-
-   The SRP protocol can not be implemented using the sequence of
-   handshake messages defined in [1] due to the sequence in which the
-   SRP messages must be sent.
-
-   This document presents a new sequence of handshake messages for
-   handshakes using the SRP authentication method.
-
-2.1.1 Message Sequence
-
-   Handshake Message Flow for SRP Authentication
-
-          Client                                 Server
-            |                                      |
-       Client Hello (U) ------------------------>  |
-            |  <---------------------------- Server Hello (s, N, g)
-            |  <---------------------------- Certificate*
-       Client Key Exchange (A) ----------------->  |
-            |  <---------------------------- Server Key Exchange (B)
-            |  <---------------------------- Server Hello Done
-       change cipher spec                          |
-       Finished -------------------------------->  |
-            |                                change cipher spec
-            |  <---------------------------- Finished
-            |                                      |
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-   The identifiers given after each message name refer to the SRP
-   variables included in that message.  The variables U, g, N, s, A, and
-   B are defined in [2].
-
-   Extended client and server hello messages, as defined in [7], are
-   used to to send the initial client and server values.
-
-   The client key exchange message is sent during the sequence of server
-   messages.  This modification is required because the client must send
-   its public key (A) before it receives the servers public key (B), as
-   stated in Section 3 of [2].
-
-2.1.2 Session Re-use
-
-   The short handshake mechanism for re-using sessions for new
-   connections, and renegotiating keys for existing connections will
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-   still work with the SRP authentication mechanism and handshake.
-
-   When a client attemps to re-use a session that uses SRP
-   authentication, it MUST still include the SRP extension carrying the
-   user name (U) in the client hello message, in case the server cannot
-   or will not allow re-use of the session, meaning a full handshake
-   sequence is required.
-
-   If a client requests an existing session and the server agrees to use
-   it (meaning the short handshake will be used), the server MAY omit
-   the SRP extension from the server hello message, as the information
-   it contains is not used in the short handshake.
-
-2.2 SRP Verifier Message Digest Selection
-
-   The cipher suites defined in this document use the SHA-1 message
-   digest with the SRP algorithm, as specified in [2].  Implementations
-   conforming to this document MUST use the SHA-1 message digest.
-
-   Future documents may define other cipher suites that use different
-   message digests, or other similar functions, with the SRP algorithm.
-
-2.3 Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.6.
-
-2.3.1 Client hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [7].
-
-2.3.2 Server hello
-
-   The the generator (g), the prime (N), and the salt value (s) read
-   from the SRP password file are appended to the server hello message
-   using the hello message extension mechanism defined in [7].
-
-2.3.3 Server certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.5 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-   Because the server's certificate is only used for generating a
-   digital signature in SRP cipher suites, the certificate sent MUST
-   contain a public key that can be used for generating digital
-   signatures.
-
-2.3.4 Client key exchange
-
-   The client key exchange message carries the client's public key (A),
-   which is calculated using both information known locally, and
-   information received in the server hello message.  This message MUST
-   be sent before the server key exchange message.
-
-2.3.5 Server key exchange
-
-   The server key exchange message contains the server's public key (B).
-   The server key exchange message MUST be sent after the client key
-   exchange message.
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-2.4 Calculating the Pre-master Secret
-
-   The shared secret resulting from the SRP calculations (S) (defined in
-   [2]) is used as the pre-master secret.
-
-   The finished messages perform the same function as the client and
-   server evidence messages specified in [2].  If either the client or
-   the server calculate an incorrect value, the finished messages will
-   not be understood, and the connection will be dropped as specified in
-   [1].
-
-2.5 Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [4].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that do not include a digitial signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP database.
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.6 New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [1].
-
-2.6.1 ExtensionType
-
-   A new value, "srp(6)", has been added to the enumerated
-   ExtensionType, defined in [7].  This value is used as the extension
-   number for the extensions in both the client hello message and the
-   server hello message.
-
-2.6.2 Client Hello
-
-   The user name (U) is encoded in an SRPExtension structure, and sent
-   in an extended client hello message, using an extension of type
-   "srp".
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-   enum { client, server } ClientOrServerExtension;
-
-   struct {
-      select(ClientOrServerExtension) {
-         case client:
-            opaque srp_U<1..2^8-1>;
-         case server:
-            opaque srp_s<1..2^8-1>
-            opaque srp_N<1..2^16-1>;
-            opaque srp_g<1..2^16-1>;
-      }
-   } SRPExtension;
-
-
-2.6.3 Server Hello
-
-   The generator (g), the prime (N), and the salt value (s) are encoded
-   in an SRPExtension structure, which is sent in an extended server
-   hello message, using an extension of type "srp".
-
-2.6.4 Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   ephemeral public key (A) is sent in the client key exchange message,
-   encoded in an ClientSRPPublic structure.
-
-   An extra value, srp, has been added to the enumerated
-   KeyExchangeAlgorithm, originally defined in TLS [1].
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case rsa: EncryptedPreMasterSecret;
-         case diffie_hellman: ClientDiffieHellmanPublic;
-         case srp: ClientSRPPublic;   /* new entry */
-      } exchange_keys;
-   } ClientKeyExchange;
-
-   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-   struct {
-      opaque srp_A<1..2^16-1>;
-   } ClientSRPPublic;
-
-
-2.6.5 Server Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   ephemeral public key (B) is sent in the server key exchange message,
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-   encoded in an ServerSRPPublic structure.
-
-   The following table gives the SignatureAlgorithm value to be used for
-   each ciphersuite.
-
-      Ciphersuite                            SignatureAlgorithm
-
-      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
-
-      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
-
-      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
-
-      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
-
-      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
-
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case diffie_hellman:
-            ServerDHParams params;
-            Signature signed_params;
-         case rsa:
-            ServerRSAParams params;
-            Signature signed_params;
-         case srp:   /* new entry */
-            ServerSRPPublic params;
-            Signature signed_params;
-      };
-   } ServerKeyExchange;
-
-   struct {
-      opaque srp_B<1..2^16-1>;
-   } ServerSRPPublic;     /* SRP parameters */
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                  [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-3. Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real host.  Filesystem based X.509 certificate
-   installations are vulnerable to a similar attack unless the server's
-   certificate is issued from a PKI that maintains revocation lists, and
-   the client TLS code can both contact the PKI and make use of the
-   revocation list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                 [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-        1999.
-
-   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
-        2945, September 2000.
-
-   [3]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
-        1999.
-
-   [4]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-        Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [5]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
-        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
-        09 (work in progress), April 2002.
-
-   [6]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
-        tn3270e-telnet-tls-06 (work in progress), April 2002.
-
-   [7]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
-        Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
-        progress), July 2002.
-
-
-Author's Address
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                 [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-Appendix A. Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                 [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication      September 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                   Expires March 5, 2003                 [Page 13]
-
-
diff --git a/doc/protocol/draft-ietf-tls-srp-04.txt b/doc/protocol/draft-ietf-tls-srp-04.txt
deleted file mode 100644
index 093f9ec87f..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-04.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-Transport Layer Security Working                               D. Taylor
-Group                                             Forge Research Pty Ltd
-Internet-Draft                                         November 29, 2002
-Expires: May 30, 2003
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-04
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on May 30, 2003.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the SRP [2] (Secure Remote
-   Password) protocol as an authentication method for the TLS
-   [1](Transport Layer Security) protocol.
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
-   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
-   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
-   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   SRP Verifier Message Digest Selection  . . . . . . . . . . .  5
-   2.3   Changes to the Handshake Message Contents  . . . . . . . . .  5
-   2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.2 Server certificate . . . . . . . . . . . . . . . . . . . . .  5
-   2.3.3 Server key exchange  . . . . . . . . . . . . . . . . . . . .  5
-   2.3.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  6
-   2.4   Calculating the Pre-master Secret  . . . . . . . . . . . . .  6
-   2.5   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  6
-   2.6   New Message Structures . . . . . . . . . . . . . . . . . . .  7
-   2.6.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  7
-   2.6.3 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  7
-   2.6.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  9
-   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 10
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 11
-         Author's Address . . . . . . . . . . . . . . . . . . . . . . 11
-   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-1. Introduction
-
-   At the time of writing, TLS uses public key certificiates with RSA/
-   DSA digital signatures, or Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS (IMAP [4], FTP [6], or
-   TELNET [7], for example).  Given these protocols (and others like
-   them) are designed to use the user name and password method of
-   authentication, being able to safely use user names and passwords to
-   authenticate the TLS connection provides a much easier route to
-   additional security than implementing a public key infrastructure in
-   certain situations.
-
-   SRP is an authentication method that allows the use of user names and
-   passwords over unencrypted channels without revealing the password to
-   an eavesdropper.  SRP also supplies a shared secret at the end of the
-   authetication sequence that can be used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-2. SRP Authentication in TLS
-
-2.1 Modifications to the TLS Handshake Sequence
-
-   The advent of SRP-6 [3] allows the SRP protocol to be implemented
-   using the standard sequence of handshake messages defined in [1].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-2.1.1 Message Sequence
-
-   Handshake Message Flow for SRP Authentication
-
-          Client                                 Server
-            |                                      |
-       Client Hello (I) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Certificate*
-            |  <---------------------------- Server Key Exchange (N, g, s, B)
-            |  <---------------------------- Server Hello Done
-       Client Key Exchange (A) ----------------->  |
-       [Change cipher spec]                        |
-       Finished -------------------------------->  |
-            |                        [Change cipher spec]
-            |  <---------------------------- Finished
-            |                                      |
-       Application Data  <--------------> Application Data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-   The identifiers given after each message name refer to the SRP
-   variables included in that message.  The variables I, N, g, s, A, and
-   B are defined in [3].
-
-   An extended client hello message, as defined in [8], is used to send
-   the client identifier (the user name).
-
-   Servers MAY add an SRP extension to the server hello message.  For
-   the cipher suites defined in this document no information is carried
-   in the SRP extension in the server hello message.  The option to add
-   an SRP extension to the server hello message is given in case it is
-   required in future.
-
-2.1.2 Session Re-use
-
-   The short handshake mechanism for re-using sessions for new
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-   connections, and renegotiating keys for existing connections will
-   still work with the SRP authentication mechanism and handshake.
-
-   When a client attemps to re-use a session that uses SRP
-   authentication, it MUST include the SRP extension carrying the user
-   name (I) in the client hello message, in case the server cannot or
-   will not allow re-use of the session, meaning a full handshake
-   sequence is required.
-
-   If the server does agree to re-use an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.2 SRP Verifier Message Digest Selection
-
-   Implementations conforming to this document MUST use the SHA-1
-   message digest with the SRP algorithm.
-
-2.3 Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.6.
-
-2.3.1 Client hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [8].
-
-2.3.2 Server certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.5 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-   Because the server's certificate is only used for generating a
-   digital signature in SRP cipher suites, the certificate sent MUST
-   contain a public key that can be used for generating digital
-   signatures.
-
-2.3.3 Server key exchange
-
-   The server key exchange message contains the prime (N), the generator
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-   (g), and the salt value (s) read from the SRP password file based on
-   the value of (I) received in the client hello extension.  The server
-   key exchange message also contains the server's public key (B).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-2.3.4 Client key exchange
-
-   The client key exchange message carries the client's public key (A).
-
-2.4 Calculating the Pre-master Secret
-
-   The shared secret resulting from the SRP calculations (S) (defined in
-   [2]) is used as the pre-master secret.
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [2].  If either the
-   client or the server calculate an incorrect value, the finished
-   messages will not be understood, and the connection will be dropped
-   as specified in [1].
-
-2.5 Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [5].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that do not include a digitial signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP database.
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.6 New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [1].
-
-2.6.1 ExtensionType
-
-   A new value, "srp(6)", has been added to the enumerated
-   ExtensionType, defined in [8].  This value MUST be used as the
-   extension number for the SRP extension.
-
-2.6.2 Client Hello
-
-   The user name (I) is encoded in an SRPExtension structure, and sent
-   in an extended client hello message, using an extension of type
-   "srp".
-
-
-   enum { client, server } ClientOrServerExtension;
-
-   struct {
-      select(ClientOrServerExtension) {
-         case client:
-            opaque srp_I<1..2^8-1>;
-         case server:
-            /* empty struct */
-      }
-   } SRPExtension;
-
-
-2.6.3 Server Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-   message must be signed.  The following table gives the
-   SignatureAlgorithm value to be used for each ciphersuite.
-
-      Ciphersuite                            SignatureAlgorithm
-
-      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
-
-      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
-
-      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
-
-      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
-
-      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
-
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case diffie_hellman:
-            ServerDHParams params;
-            Signature signed_params;
-         case rsa:
-            ServerRSAParams params;
-            Signature signed_params;
-         case srp:   /* new entry */
-            ServerSRPParams params;
-            Signature signed_params;
-      };
-   } ServerKeyExchange;
-
-   struct {
-      opaque srp_N<1..2^16-1>;
-      opaque srp_g<1..2^16-1>;
-      opaque srp_s<1..2^8-1>
-      opaque srp_B<1..2^16-1>;
-   } ServerSRPParams;     /* SRP parameters */
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-2.6.4 Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   ephemeral public key (A) is sent in the client key exchange message,
-   encoded in an ClientSRPPublic structure.
-
-   An extra value, srp, has been added to the enumerated
-   KeyExchangeAlgorithm, originally defined in TLS [1].
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case rsa: EncryptedPreMasterSecret;
-         case diffie_hellman: ClientDiffieHellmanPublic;
-         case srp: ClientSRPPublic;   /* new entry */
-      } exchange_keys;
-   } ClientKeyExchange;
-
-   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-   struct {
-      opaque srp_A<1..2^16-1>;
-   } ClientSRPPublic;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                  [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-3. Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real host.  Filesystem based X.509 certificate
-   installations are vulnerable to a similar attack unless the server's
-   certificate is issued from a PKI that maintains revocation lists, and
-   the client TLS code can both contact the PKI and make use of the
-   revocation list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                 [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-References
-
-   [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-        1999.
-
-   [2]  Wu, T., "The SRP Authentication and Key Exchange System", RFC
-        2945, September 2000.
-
-   [3]  Wu, T., "SRP-6: Improvements and Refinements to the Secure
-        Remote Password Protocol", October 2002.
-
-   [4]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June
-        1999.
-
-   [5]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-        Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [6]  Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
-        V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl-
-        09 (work in progress), April 2002.
-
-   [7]  Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf-
-        tn3270e-telnet-tls-06 (work in progress), April 2002.
-
-   [8]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
-        Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in
-        progress), July 2002.
-
-
-Author's Address
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                 [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-Appendix A. Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-   Thanks to Tom Wu for adapting the SRP protocol so it fits the
-   standard TLS handshake message sequence.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                 [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication       November 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor                    Expires May 30, 2003                 [Page 13]
-
-
diff --git a/doc/protocol/draft-ietf-tls-srp-05.txt b/doc/protocol/draft-ietf-tls-srp-05.txt
deleted file mode 100644
index a90491d6d9..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-05.txt
+++ /dev/null
@@ -1,1122 +0,0 @@
-
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: December 16, 2003                                         T. Wu
-                                                           Arcot Systems
-                                                      N. Mavroyanopoulos
-                                                               T. Perrin
-                                                           June 17, 2003
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-05
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 16, 2003.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the SRP [2] (Secure Remote
-   Password) protocol as an authentication method for the TLS
-   [1](Transport Layer Security) protocol.
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
-   2.1   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
-   2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  4
-   2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   Text Preparation . . . . . . . . . . . . . . . . . . . . . .  5
-   2.3   SRP Verifier Creation  . . . . . . . . . . . . . . . . . . .  5
-   2.4   Changes to the Handshake Message Contents  . . . . . . . . .  5
-   2.4.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.4.2 Server certificate . . . . . . . . . . . . . . . . . . . . .  6
-   2.4.3 Server key exchange  . . . . . . . . . . . . . . . . . . . .  6
-   2.4.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  7
-   2.5   Calculating the Pre-master Secret  . . . . . . . . . . . . .  7
-   2.6   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  7
-   2.7   New Message Structures . . . . . . . . . . . . . . . . . . .  8
-   2.7.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . .  8
-   2.7.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . .  8
-   2.7.3 Server Key Exchange  . . . . . . . . . . . . . . . . . . . .  8
-   2.7.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . .  9
-   2.8   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . . 10
-   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 11
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 12
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
-   A.    SRP Group Parameters . . . . . . . . . . . . . . . . . . . . 14
-   B.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
-         Intellectual Property and Copyright Statements . . . . . . . 19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-1. Introduction
-
-   At the time of writing TLS uses public key certificates, or Kerberos,
-   for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS (IMAP [4], FTP [8], or
-   TELNET [9], for example). Given that these protocols (and others like
-   them) are designed to use the user name and password method of
-   authentication, being able to safely use user names and passwords to
-   authenticate the TLS connection provides a much easier route to
-   additional security than implementing a public key infrastructure in
-   certain situations.
-
-   SRP is an authentication method that allows the use of user names and
-   passwords over unencrypted channels without revealing the password to
-   an eavesdropper. SRP also supplies a shared secret at the end of the
-   authentication sequence that can be used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-2. SRP Authentication in TLS
-
-2.1 Modifications to the TLS Handshake Sequence
-
-   The advent of SRP-6 [3] allows the SRP protocol to be implemented
-   using the standard sequence of handshake messages defined in [1].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-2.1.1 Message Sequence
-
-   Handshake Message Flow for SRP Authentication
-
-          Client                                 Server
-            |                                      |
-       Client Hello (I) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Certificate*
-            |  <---------------------------- Server Key Exchange (N, g, s, B)
-            |  <---------------------------- Server Hello Done
-       Client Key Exchange (A) ----------------->  |
-       [Change cipher spec]                        |
-       Finished -------------------------------->  |
-            |                        [Change cipher spec]
-            |  <---------------------------- Finished
-            |                                      |
-       Application Data  <--------------> Application Data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-                                Figure 1
-
-   The identifiers given after each message name refer to the SRP
-   variables included in that message. The variables I, N, g, s, A, and
-   B are defined in [3].
-
-   An extended client hello message, as defined in [10], is used to send
-   the client identifier (the user name).
-
-2.1.2 Session Re-use
-
-   The short handshake mechanism for re-using sessions for new
-   connections, and renegotiating keys for existing connections will
-   still work with the SRP authentication mechanism and handshake.
-
-   When a client attemps to re-use a session that uses SRP
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-   authentication, it MUST include the SRP extension carrying the user
-   name (I) in the client hello message, in case the server cannot or
-   will not allow re-use of the session, meaning a full handshake
-   sequence is required.
-
-   If the server does agree to re-use an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.2 Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the "SASLprep" [7] profile of "stringprep" [6].
-
-2.3 SRP Verifier Creation
-
-   The verifier is created by applying the SRP-SHA1 mechanism as
-   described in RFC 2945 [2] to the user name and password.
-
-2.4 Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication. The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.7.
-
-2.4.1 Client hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [10].
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server will return a
-   missing_srp_username alert (see Section 2.8) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.
-   Through this idiom, the client can advertise that it supports SRP,
-   but not have to prompt the user for his user name and password, nor
-   expose the user name in the clear, unless necessary.
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an unknown_srp_username alert
-   (see Section 2.8).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-   client's finished message as if the password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (g, N) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use hmac-sha1(seed_key, "salt" || user_name) to
-   generate the salts.  For B, the server can return a random value
-   between 2 and N-2 inclusive.  However, the server should take care to
-   simulate computation delays.  One way to do this is to generate a
-   fake verifier using the "seed key" approach, and then proceed with
-   the protocol as usual.
-
-2.4.2 Server certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature. See Section 2.6 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-   Because the server's certificate is only used for generating a
-   digital signature in SRP cipher suites, the certificate sent MUST
-   contain a public key that can be used for verifying digital
-   signatures.
-
-2.4.3 Server key exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the value of (I) received in the client hello extension. The server
-   key exchange message also contains the server's public value (B).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (g, N) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime), and g
-   as a generator % N.  The SRP group parameters in Appendix A are
-   proven to have these properties, so the client SHOULD accept any
-   parameters from this Appendix which have large enough moduli to meet
-   his security requirements.  The client MAY accept other group
-   parameters from the server, either by prior arrangement, or by
-   checking the parameters himself.
-
-   To check that N is a safe prime, the client should use some method
-   such as performing 64 iterations of the Miller-Rabin test with random
-   bases (selected from 2 to N-2) on both N and q (by performing 64
-   iterations, the probability of a false positive is no more than
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-   2^-128).  To check that g is a generator % N, the client can check
-   that g^q equals -1 % N.  Performing these checks may be
-   time-consuming: after checking new parameters, the client may want to
-   add them to a known-good list.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an illegal_parameter alert.
-
-   The client MUST abort the handshake with an illegal_parameter alert
-   if B % N is equal to zero.
-
-2.4.4 Client key exchange
-
-   The client key exchange message carries the client's public value
-   (A).
-
-   The server MUST abort the handshake with an illegal_parameter alert
-   if A % N is equal to zero, 1, or -1.
-
-2.5 Calculating the Pre-master Secret
-
-   The shared secret resulting from the SRP calculations (S) (defined in
-   [2]) is used as the pre-master secret.
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [2]. If either the
-   client or the server calculate an incorrect value, the finished
-   messages will not be understood, and the connection will be dropped
-   as specified in [1].
-
-2.6 Cipher Suite Definitions
-
-   The following cipher suites are added by this draft. The usage of AES
-   ciphersuites is as defined in [5].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.7 New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication. The representation
-   language used is the same as that used in [1].
-
-2.7.1 ExtensionType
-
-   A new value, "srp(6)", has been added to the enumerated
-   ExtensionType, defined in [10].  This value MUST be used as the
-   extension number for the SRP extension.
-
-2.7.2 Client Hello
-
-   The "extension_data" field of the srp extension SHALL contain: opaque
-   srp_I<1..2^8-1> where srp_I is the user name.
-
-2.7.3 Server Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed. The following table gives the
-   SignatureAlgorithm value to be used for each ciphersuite.
-
-      Ciphersuite                            SignatureAlgorithm
-
-      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
-
-      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
-
-      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
-
-      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
-
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case diffie_hellman:
-            ServerDHParams params;
-            Signature signed_params;
-         case rsa:
-            ServerRSAParams params;
-            Signature signed_params;
-         case srp:   /* new entry */
-            ServerSRPParams params;
-            Signature signed_params;
-      };
-   } ServerKeyExchange;
-
-   struct {
-      opaque srp_N<1..2^16-1>;
-      opaque srp_g<1..2^16-1>;
-      opaque srp_s<1..2^8-1>
-      opaque srp_B<1..2^16-1>;
-   } ServerSRPParams;     /* SRP parameters */
-
-
-2.7.4 Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in an ClientSRPPublic structure.
-
-   An extra value, srp, has been added to the enumerated
-   KeyExchangeAlgorithm, originally defined in TLS [1].
-
-
-
-
-Taylor, et al.         Expires December 16, 2003                [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-   struct {
-      select (KeyExchangeAlgorithm) {
-         case rsa: EncryptedPreMasterSecret;
-         case diffie_hellman: ClientDiffieHellmanPublic;
-         case srp: ClientSRPPublic;   /* new entry */
-      } exchange_keys;
-   } ClientKeyExchange;
-
-   enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-   struct {
-      opaque srp_A<1..2^16-1>;
-   } ClientSRPPublic;
-
-
-2.8 Error Alerts
-
-   Two new error alerts are defined:
-
-   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
-      that receives an unknown user name.  This message is always fatal.
-
-   o  "missing_srp_username" (121) - this alert MUST be sent by a server
-      which would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      may be fatal or a warning.  If it is a warning, the server MUST
-      restart its handshake protocol without closing the TLS session,
-      and the client MAY either treat the warning as fatal and close the
-      session, or send the server a new hello message on the same
-      session.  By sending a new hello on the same session, the client
-      can use the idiom described in 2.3.1 without terminating a current
-      TLS session which might be protecting the handshake (and thus the
-      user name).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-3. Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords. Filesystem based X.509
-   certificate installations are vulnerable to a similar attack unless
-   the server's certificate is issued from a PKI that maintains
-   revocation lists, and the client TLS code can both contact the PKI
-   and make use of the revocation list.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   session, then renegotiate an SRP-authenticated session with the
-   handshake protected by the first session.
-
-   The checks described in Section 2.4.3 and Section 2.4.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private exponentials (a and b in [2]) SHOULD be at least 256 bit
-   random numbers, to give approximately 128 bits of security against
-   certain methods of calculating discrete logarithms [12].  Increasing
-   the length of these exponentials may increase security, but it also
-   increases the computation cost."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-References
-
-   [1]   Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-         1999.
-
-   [2]   Wu, T., "The SRP Authentication and Key Exchange System", RFC
-         2945, September 2000.
-
-   [3]   Wu, T., "SRP-6: Improvements and Refinements to the Secure
-         Remote Password Protocol", October 2002.
-
-   [4]   Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
-         June 1999.
-
-   [5]   Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
-         Transport Layer Security (TLS)", RFC 3268, June 2002.
-
-   [6]   Hoffman, P. and M. Blanchet, "Preparation of Internationalized
-         Strings ("stringprep")", RFC 3454, December 2002.
-
-   [7]   Zeilenga, K., "SASLprep: Stringprep profile for user names and
-         passwords", draft-ietf-tn3270e-telnet-tls-06 (work in
-         progress), February 2003.
-
-   [8]   Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and
-         V. Wiegand, "Securing FTP with TLS",
-         draft-murray-auth-ftp-ssl-09 (work in progress), April 2002.
-
-   [9]   Boe, M. and J. Altman, "TLS-based Telnet Security",
-         draft-ietf-sasl-saslprep-00 (work in progress), April 2002.
-
-   [10]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and
-         T. Wright, "TLS Extensions", draft-ietf-tls-extensions-06 (work
-         in progress), February 2003.
-
-   [11]  Kivinen, T. and M. Kojo, "More Modular Exponentiation (MODP)
-         Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC
-         3526, May 2003.
-
-   [12]  van Oorschot, P. and M. Wiener, "On Diffie-Hellman Key
-         Agreement with Short Exponents", 1996.
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-Authors' Addresses
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-   Tom Wu
-   Arcot Systems
-
-   EMail: tom@arcot.com
-   URI:   http://www.arcot.com/
-
-
-   Nikos Mavroyanopoulos
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-
-   EMail: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-Appendix A. SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [11], but generators have been calculated that are primitive roots of
-   N, unlike the generators in [11].
-
-   The 1024, 1536, and 2048-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-       The generator is: 2.
-
-   2.  1536-bit Group
-
-       The hexadecimal value is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-       The generator is: 2.
-
-   3.  2048-bit Group
-
-       The hexadecimal value is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-       The generator is: 2.
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-Appendix B. Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2003
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires December 16, 2003               [Page 20]
-
-
diff --git a/doc/protocol/draft-ietf-tls-srp-06.txt b/doc/protocol/draft-ietf-tls-srp-06.txt
deleted file mode 100644
index 38af5c08f5..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-06.txt
+++ /dev/null
@@ -1,1231 +0,0 @@
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: July 27, 2004                                             T. Wu
-                                                           Arcot Systems
-                                                      N. Mavroyanopoulos
-                                                               T. Perrin
-                                                        January 27, 2004
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-06
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 27, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the SRP (Secure Remote
-   Password) protocol ([SRP], [SRP-6]) as an authentication method for
-   the TLS (Transport Layer Security) protocol [TLS].
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SRP Authentication in TLS  . . . . . . . . . . . . . . . . .  4
-   2.1   Notations and Terminology  . . . . . . . . . . . . . . . . .  4
-   2.2   Modifications to the TLS Handshake Sequence  . . . . . . . .  4
-   2.2.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . .  5
-   2.2.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.3   Text Preparation . . . . . . . . . . . . . . . . . . . . . .  5
-   2.4   SRP Verifier Creation  . . . . . . . . . . . . . . . . . . .  6
-   2.5   Changes to the Handshake Message Contents  . . . . . . . . .  6
-   2.5.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . .  6
-   2.5.2 Server certificate . . . . . . . . . . . . . . . . . . . . .  7
-   2.5.3 Server key exchange  . . . . . . . . . . . . . . . . . . . .  7
-   2.5.4 Client key exchange  . . . . . . . . . . . . . . . . . . . .  8
-   2.6   Calculating the Pre-master Secret  . . . . . . . . . . . . .  8
-   2.7   Cipher Suite Definitions . . . . . . . . . . . . . . . . . .  9
-   2.8   New Message Structures . . . . . . . . . . . . . . . . . . . 10
-   2.8.1 ExtensionType  . . . . . . . . . . . . . . . . . . . . . . . 10
-   2.8.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . . 10
-   2.8.3 Server Key Exchange  . . . . . . . . . . . . . . . . . . . . 10
-   2.8.4 Client Key Exchange  . . . . . . . . . . . . . . . . . . . . 11
-   2.9   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . . 12
-   3.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
-         Normative References . . . . . . . . . . . . . . . . . . . . 14
-         Informative References . . . . . . . . . . . . . . . . . . . 15
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
-   A.    SRP Group Parameters . . . . . . . . . . . . . . . . . . . . 16
-   B.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
-         Intellectual Property and Copyright Statements . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-1. Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, or
-   Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS ([IMAP] or [FTP], for
-   example). Given that these protocols (and others like them) are
-   designed to use the user name and password method of authentication,
-   being able to safely use user names and passwords to authenticate the
-   TLS connection provides a much easier route to additional security
-   than implementing a public key infrastructure in certain situations.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper. SRP also supplies a shared
-   secret at the end of the authentication sequence that can be used to
-   generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-2. SRP Authentication in TLS
-
-2.1 Notations and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This particular version is a slight improvement over
-   "SRP-3", which was described in [SRP] and [RFC2945].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-
-      s: salt
-
-      B, b: server's public and private values
-
-      A, a: client's public and private values
-
-      I: user name (aka "identity")
-
-      p: password
-
-      v: verifier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.  Conversion between integers and byte-strings assumes the
-   most-significant bytes are stored first, as per [TLS] and [RFC2945].
-
-2.2 Modifications to the TLS Handshake Sequence
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-2.2.1 Message Sequence
-
-   Handshake Message Flow for SRP Authentication
-
-          Client                                 Server
-            |                                      |
-       Client Hello (I) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Certificate*
-            |  <---------------------------- Server Key Exchange (N, g, s, B)
-            |  <---------------------------- Server Hello Done
-       Client Key Exchange (A) ----------------->  |
-       [Change cipher spec]                        |
-       Finished -------------------------------->  |
-            |                        [Change cipher spec]
-            |  <---------------------------- Finished
-            |                                      |
-       Application Data  <--------------> Application Data
-
-   * Indicates an optional message which is not always sent.
-
-                                Figure 1
-
-   An extended client hello message, as defined in [TLSEXT], is used to
-   send the client identifier (the user name).
-
-2.2.2 Session Re-use
-
-   The short handshake mechanism for re-using sessions for new
-   connections, and renegotiating keys for existing connections will
-   still work with the SRP authentication mechanism and handshake.
-
-   When a client attemps to re-use a session that uses SRP
-   authentication, it MUST include the SRP extension carrying the user
-   name (I) in the client hello message, in case the server cannot or
-   will not allow re-use of the session, meaning a full handshake
-   sequence is required.
-
-   If the server does agree to re-use an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.3 Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the [SASLPrep] profile of [StringPrep].
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-2.4 SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [RFC2945]. We
-   give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (p), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | p))
-        v = g^x % N
-
-2.5 Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication. The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1 Client hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [TLSEXT].
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server MAY return a
-   missing_srp_username alert (see Section 2.9) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.
-   Through this idiom, the client can advertise that it supports SRP,
-   but not have to prompt the user for his user name and password, nor
-   expose the user name in the clear, unless necessary.
-
-   After sending the missing_srp_username alert, the server MUST leave
-   the TLS connection open, yet reset its handshake protocol state so it
-   is prepared to receive a second client hello message.  Upon receiving
-   the missing_srp_username alert, the client MUST either send a second
-   client hello message, or send a fatal user_cancelled alert.
-
-   If the client sends a second hello message, the second hello message
-   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
-   the server MUST choose one of the SRP ciphersuites.  Both client
-   hello messages MUST be treated as handshake messages and included in
-   the hash calculations for the TLS Finished message.  The premaster
-   and master secret calculations will use the random value from the
-   second client hello message, not the first.
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an unknown_srp_username alert
-   (see Section 2.9).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-   client's finished message with a bad_record_mac alert, as if the
-   password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-2.5.2 Server certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature. See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-   Because the server's certificate is only used for generating a
-   digital signature in SRP cipher suites, the certificate sent MUST
-   contain a public key that can be used for verifying digital
-   signatures.
-
-2.5.3 Server key exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = 3*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length.
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-   and g MUST be a generator of this group.  The SRP group parameters in
-   Appendix A are proven to have these properties, so the client SHOULD
-   accept any parameters from this Appendix which have large enough N
-   values to meet his security requirements.  The client MAY accept
-   other group parameters from the server, either by prior arrangement,
-   or by checking the parameters himself.
-
-   To check that N is a safe prime, the client should use some method
-   such as performing 64 iterations of the Miller-Rabin test with random
-   bases (selected from 2 to N-2) on both N and q (by performing 64
-   iterations, the probability of a false positive is no more than
-   2^-128).  To check that g is a generator of the group, the client can
-   check that 1 < g < N-1, and g^q % N equals N-1. Performing these
-   checks may be time-consuming; after checking new parameters, the
-   client may want to add them to a known-good list.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an insufficient_security alert.
-
-   The client MUST abort the handshake with an illegal_parameter alert
-   if B % N = 0.
-
-2.5.4 Client key exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an illegal_parameter alert
-   if A % N = 0, 1, or N-1.
-
-2.6 Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, p = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(A | B)
-        x = SHA1(s | SHA1(I | ":" | p))
-        <premaster secret> = (B - (3 * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-        N, g, s, v = <read from password file>
-        b = random()
-        B = 3*v + g^b % N
-        A = <read from client>
-        u = SHA1(A | B)
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [RFC2945]. If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a bad_record_mac alert.
-
-   If a client application receives a bad_record_mac alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7 Cipher Suite Definitions
-
-   The following cipher suites are added by this draft. The usage of AES
-   ciphersuites is as defined in [RFC3268].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-
-
-Taylor, et al.           Expires July 27, 2004                  [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8 New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication. The representation
-   language used is the same as that used in [TLS].
-
-2.8.1 ExtensionType
-
-   A new value, "srp(6)", has been added to the enumerated
-   ExtensionType, defined in [TLSEXT].  This value MUST be used as the
-   extension number for the SRP extension.
-
-2.8.2 Client Hello
-
-   The "extension_data" field of the srp extension SHALL contain:
-
-   opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per .
-
-2.8.3 Server Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed. The following table gives the
-   SignatureAlgorithm value to be used for each ciphersuite.
-
-      Ciphersuite                            SignatureAlgorithm
-
-      TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA         anonymous
-
-      TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA     rsa
-
-      TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA     dsa
-
-      TLS_SRP_SHA_WITH_AES_128_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA      dsa
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-      TLS_SRP_SHA_WITH_AES_256_CBC_SHA          anonymous
-
-      TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA      rsa
-
-      TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA      dsa
-
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.4 Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in an ClientSRPPublic structure.
-
-   An extra value, srp, has been added to the enumerated
-   KeyExchangeAlgorithm, originally defined in [TLS].
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9 Error Alerts
-
-   Two new error alerts are defined:
-
-   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
-      that receives an unknown user name.  This message is always fatal.
-
-   o  "missing_srp_username" (121) - this alert MAY be sent by a server
-      which would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always a warning. Upon receiving this alert, the client MAY
-      send a new hello message on the same connection, this time
-      including the SRP extension.  See Section 2.5.1 for more details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-3. Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords. Filesystem based X.509
-   certificate installations are vulnerable to a similar attack unless
-   the server's certificate is issued from a PKI that maintains
-   revocation lists, and the client TLS code can both contact the PKI
-   and make use of the revocation list.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   session, then renegotiate an SRP-authenticated session with the
-   handshake protected by the first session.
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.
-
-   If the client receives a missing_srp_username alert, the client
-   should be aware that unless the handshake protocol is run to
-   completion, this alert may have been inserted by an attacker.  If the
-   handshake protocol is not run to completion, the client should not
-   make any decisions, nor form any assumptions, based on receiving this
-   alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-Normative References
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-              January 1999.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002, <http://
-              srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
-              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [StringPrep]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPrep]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", draft-ietf-sasl-saslprep-04 (work in
-              progress), October 2003.
-
-   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
-              September 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-              Keyed-Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC3268]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-Informative References
-
-   [IMAP]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
-           June 1999.
-
-   [FTP]   Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E.
-           and V. Wiegand, "Securing FTP with TLS",
-           draft-murray-auth-ftp-ssl-12 (work in progress), August 2003.
-
-   [SRP]   Wu, T., "The Secure Remote Password Protocol", Proceedings of
-           the 1998 Internet Society Network and Distributed System
-           Security Symposium pp. 97-111, March 1998.
-
-
-Authors' Addresses
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-   Tom Wu
-   Arcot Systems
-
-   EMail: tom@arcot.com
-   URI:   http://www.arcot.com/
-
-
-   Nikos Mavroyanopoulos
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-
-   EMail: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-Appendix A. SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-       The generator is: 2.
-
-   2.  1536-bit Group
-
-       The hexadecimal value is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-       The generator is: 2.
-
-   3.  2048-bit Group
-
-       The hexadecimal value is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-       The generator is: 2.
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-Appendix B. Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights. Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11. Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard. Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works. However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 21]
-
-Internet-Draft      Using SRP for TLS Authentication        January 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.           Expires July 27, 2004                 [Page 22]
diff --git a/doc/protocol/draft-ietf-tls-srp-07.txt b/doc/protocol/draft-ietf-tls-srp-07.txt
deleted file mode 100644
index b6f3255194..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-07.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: December 6, 2004                                          T. Wu
-                                                           Arcot Systems
-                                                      N. Mavroyanopoulos
-                                                               T. Perrin
-                                                            June 7, 2004
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-07
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 6, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol ([SRP], [SRP-6]) as an authentication method for the
-   Transport Layer Security protocol [TLS].
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1   Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2   Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3   Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4   SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5   Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2   Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3   Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4   Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6   Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7   Cipher Suite Definitions . . . . . . . . . . . . . . . . .  8
-     2.8   New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  9
-       2.8.2   Server Key Exchange  . . . . . . . . . . . . . . . . .  9
-       2.8.3   Client Key Exchange  . . . . . . . . . . . . . . . . . 10
-     2.9   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   4.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
-   4.2   Informative References . . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-   A.  SRP Group Parameters . . . . . . . . . . . . . . . . . . . . . 15
-   B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
-       Intellectual Property and Copyright Statements . . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, or
-   Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS ([IMAP] or [FTP], for
-   example).  Given that these protocols are designed to use the user
-   name and password method of authentication, being able to safely use
-   user names and passwords provides an easier route to additional
-   security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-2.  SRP Authentication in TLS
-
-2.1  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [RFC2945].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-      s: salt
-      B, b: server's public and private values
-      A, a: client's public and private values
-      I: user name (aka "identity")
-      P: password
-      v: verifier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.  Conversion between integers and byte-strings assumes the
-   most-significant bytes are stored first, as per [TLS] and [RFC2945].
-
-2.2  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-          Client                                 Server
-            |                                      |
-       Client Hello (I) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Certificate*
-            |  <---------------------------- Server Key Exchange (N, g, s, B)
-            |  <---------------------------- Server Hello Done
-       Client Key Exchange (A) ----------------->  |
-       [Change cipher spec]                        |
-       Finished -------------------------------->  |
-            |                        [Change cipher spec]
-            |  <---------------------------- Finished
-            |                                      |
-       Application Data  <--------------> Application Data
-
-   * Indicates an optional message which is not always sent.
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-                                Figure 1
-
-
-2.3  Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the [SASLPrep] profile of [StringPrep].
-
-2.4  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [RFC2945].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [TLSEXT] (see
-   Section 2.8.1).
-
-2.5.1.1  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the user name extension in
-   the client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-2.5.1.2  Missing SRP Username
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server MAY return a
-   missing_srp_username alert (see Section 2.9) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.  This
-   allows the client to advertise that it supports SRP, but not have to
-   prompt the user for his user name and password, nor expose the user
-   name in the clear, unless necessary.
-
-   After sending the missing_srp_username alert, the server MUST leave
-   the TLS connection open, yet reset its handshake protocol state so it
-   is prepared to receive a second client hello message.  Upon receiving
-   the missing_srp_username alert, the client MUST either send a second
-   client hello message, or send a fatal user_cancelled alert.
-
-   If the client sends a second hello message, the second hello message
-   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
-   the server MUST choose one of the SRP ciphersuites.  Both client
-   hello messages MUST be treated as handshake messages and included in
-   the hash calculations for the TLS Finished message.  The premaster
-   and master secret calculations will use the random value from the
-   second client hello message, not the first.
-
-2.5.1.3  Unknown SRP Username
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an unknown_srp_username alert
-   (see Section 2.9).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-   client's finished message with a bad_record_mac alert, as if the
-   password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-2.5.2  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | g).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  The SRP group parameters in
-   Appendix A are proven to have these properties, so the client SHOULD
-   accept any parameters from this Appendix which have large enough N
-   values to meet his security requirements.  The client MAY accept
-   other group parameters from the server, either by prior arrangement,
-   or by checking the parameters himself.
-
-   To check that N is a safe prime, the client should use some method
-   such as performing 64 iterations of the Miller-Rabin test with random
-   bases (selected from 2 to N-2) on both N and q (by performing 64
-   iterations, the probability of a false positive is no more than
-   2^-128).  To check that g is a generator of the group, the client can
-   check that 1 < g < N-1, and g^q % N equals N-1.  Performing these
-   checks may be time-consuming; after checking new parameters, the
-   client may want to add them to a known-good list.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an untrusted_srp_parameters alert (see Section
-   2.9).
-
-   The client MUST abort the handshake with an illegal_parameter alert
-   if B % N = 0.
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-2.5.4  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an illegal_parameter alert
-   if A % N = 0.
-
-2.6  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(A | B)
-        k = SHA1(N | g)
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | g)
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(A | B)
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [RFC2945].  If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a bad_record_mac alert.
-
-   If a client application receives a bad_record_mac alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [RFC3268].
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-2.8.1  Client Hello
-
-   A new value, "srp(6)", has been added to the enumerated ExtensionType
-   defined in [TLSEXT].  This value MUST be used as the extension number
-   for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per Section 2.4.
-
-2.8.2  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-
-
-
-Taylor, et al.          Expires December 6, 2004                [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.3  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-2.9  Error Alerts
-
-   Three new error alerts are defined:
-
-   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-   o  "missing_srp_username" (121) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always a warning.  Upon receiving this alert, the client MAY
-      send a new hello message on the same connection, this time
-      including the SRP extension.  See Section 2.5.1.2 for details.
-   o  "untrusted_srp_parameters" (122) - this alert MUST be sent by a
-      client that receives unknown or untrusted (N, g) values.  This
-      alert is always fatal.  See Section 2.5.3 for details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-3.  Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user account, or
-   locking the user account once a threshold of failed attempts is
-   reached.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.
-
-   If the client receives a missing_srp_username alert, the client
-   should be aware that unless the handshake protocol is run to
-   completion, this alert may have been inserted by an attacker.  If the
-   handshake protocol is not run to completion, the client should not
-   make any decisions, nor form any assumptions, based on receiving this
-   alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-4.  References
-
-4.1  Normative References
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-              January 1999.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002,
-              <http://srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
-              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [StringPrep]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPrep]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", draft-ietf-sasl-saslprep-09 (work in
-              progress), April 2004.
-
-   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
-              September 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-              Keyed-Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC3268]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-4.2  Informative References
-
-   [IMAP]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
-           June 1999.
-
-   [FTP]   Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E.
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-           and V. Wiegand, "Securing FTP with TLS",
-           draft-murray-auth-ftp-ssl-13 (work in progress), March 2004.
-
-   [SRP]   Wu, T., "The Secure Remote Password Protocol", Proceedings of
-           the 1998 Internet Society Network and Distributed System
-           Security Symposium pp. 97-111, March 1998.
-
-
-Authors' Addresses
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-   Tom Wu
-   Arcot Systems
-
-   EMail: tom@arcot.com
-   URI:   http://www.arcot.com/
-
-
-   Nikos Mavroyanopoulos
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-
-   EMail: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value is:
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-       The generator is: 2.
-   2.  1536-bit Group
-
-       The hexadecimal value is:
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-       The generator is: 2.
-   3.  2048-bit Group
-
-       The hexadecimal value is:
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-       The generator is: 2.
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 15]
-
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-       The generator is: 5.
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-       The generator is: 5.
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-       The generator is: 5.
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-Appendix B.  Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 6, 2004               [Page 21]
-
-
-

-

diff --git a/doc/protocol/draft-ietf-tls-srp-08.txt b/doc/protocol/draft-ietf-tls-srp-08.txt
deleted file mode 100644
index 8201411b2e..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-08.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: February 17, 2005                                         T. Wu
-                                                     Stanford University
-                                                      N. Mavroyanopoulos
-                                                               T. Perrin
-                                                         August 19, 2004
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-08
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on February 17, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol ([SRP], [SRP-6]) as an authentication method for the
-   Transport Layer Security protocol [TLS].
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1   Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2   Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3   Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4   SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5   Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2   Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3   Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4   Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6   Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7   Cipher Suite Definitions . . . . . . . . . . . . . . . . .  9
-     2.8   New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  9
-       2.8.2   Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3   Client Key Exchange  . . . . . . . . . . . . . . . . . 10
-     2.9   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-   4.1   Normative References . . . . . . . . . . . . . . . . . . . . 13
-   4.2   Informative References . . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-   A.  SRP Group Parameters . . . . . . . . . . . . . . . . . . . . . 15
-   B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
-       Intellectual Property and Copyright Statements . . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, or
-   Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS ([IMAP] or [FTP], for
-   example).  Given that these protocols are designed to use the user
-   name and password method of authentication, being able to safely use
-   user names and passwords provides an easier route to additional
-   security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-2.  SRP Authentication in TLS
-
-2.1  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [RFC2945].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-      s: salt
-      B, b: server's public and private values
-      A, a: client's public and private values
-      I: user name (aka "identity")
-      P: password
-      v: verifier
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the
-   most-significant bytes are stored first, as per [TLS] and [RFC2945].
-   In the following text, if a conversion from integer to byte-string is
-   implicit, the most-significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-          Client                                 Server
-            |                                      |
-       Client Hello (I) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Certificate*
-            |  <---------------------------- Server Key Exchange (N, g, s, B)
-            |  <---------------------------- Server Hello Done
-       Client Key Exchange (A) ----------------->  |
-       [Change cipher spec]                        |
-       Finished -------------------------------->  |
-            |                        [Change cipher spec]
-            |  <---------------------------- Finished
-            |                                      |
-       Application Data  <--------------> Application Data
-
-   * Indicates an optional message which is not always sent.
-
-                                Figure 1
-
-
-2.3  Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the [SASLPrep] profile of [StringPrep].
-
-2.4  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [RFC2945].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [TLSEXT] (see
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-   Section 2.8.1).
-
-2.5.1.1  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the user name extension in
-   the client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.5.1.2  Missing SRP Username
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server MAY return a
-   missing_srp_username alert (see Section 2.9) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.  This
-   allows the client to advertise that it supports SRP, but not have to
-   prompt the user for his user name and password, nor expose the user
-   name in the clear, unless necessary.
-
-   After sending the missing_srp_username alert, the server MUST leave
-   the TLS connection open, yet reset its handshake protocol state so it
-   is prepared to receive a second client hello message.  Upon receiving
-   the missing_srp_username alert, the client MUST either send a second
-   client hello message, or send a fatal user_cancelled alert.
-
-   If the client sends a second hello message, the second hello message
-   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
-   the server MUST choose one of the SRP ciphersuites.  Both client
-   hello messages MUST be treated as handshake messages and included in
-   the hash calculations for the TLS Finished message.  The premaster
-   and master secret calculations will use the random value from the
-   second client hello message, not the first.
-
-2.5.1.3  Unknown SRP Username
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an unknown_srp_username alert
-   (see Section 2.9).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-   client's finished message with a bad_record_mac alert, as if the
-   password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-2.5.2  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  The SRP group parameters in
-   Appendix A are proven to have these properties, so the client SHOULD
-   accept any parameters from this Appendix which have large enough N
-   values to meet his security requirements.  The client MAY accept
-   other group parameters from the server, either by prior arrangement,
-   or by checking the parameters himself.
-
-   To check that N is a safe prime, the client should use some method
-   such as performing 64 iterations of the Miller-Rabin test with random
-   bases (selected from 2 to N-2) on both N and q (by performing 64
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-   iterations, the probability of a false positive is no more than
-   2^-128).  To check that g is a generator of the group, the client can
-   check that 1 < g < N-1, and g^q % N equals N-1.  Performing these
-   checks may be time-consuming; after checking new parameters, the
-   client may want to add them to a known-good list.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an untrusted_srp_parameters alert (see Section
-   2.9).
-
-   The client MUST abort the handshake with an illegal_parameter alert
-   if B % N = 0.
-
-2.5.4  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an illegal_parameter alert
-   if A % N = 0.
-
-2.6  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [RFC2945].  If
-   either the client or the server calculate an incorrect premaster
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a bad_record_mac alert.
-
-   If a client application receives a bad_record_mac alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [RFC3268].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-2.8.1  Client Hello
-
-   A new value, "srp(6)", has been added to the enumerated ExtensionType
-   defined in [TLSEXT].  This value MUST be used as the extension number
-   for the SRP extension.
-
-
-
-
-Taylor, et al.         Expires February 17, 2005                [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per Section 2.4.
-
-2.8.2  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.3  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9  Error Alerts
-
-   Three new error alerts are defined:
-
-   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-   o  "missing_srp_username" (121) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always a warning.  Upon receiving this alert, the client MAY
-      send a new hello message on the same connection, this time
-      including the SRP extension.  See Section 2.5.1.2 for details.
-   o  "untrusted_srp_parameters" (122) - this alert MUST be sent by a
-      client that receives unknown or untrusted (N, g) values.  This
-      alert is always fatal.  See Section 2.5.3 for details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-3.  Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user account, or
-   locking the user account once a threshold of failed attempts is
-   reached.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.
-
-   If the client receives a missing_srp_username alert, the client
-   should be aware that unless the handshake protocol is run to
-   completion, this alert may have been inserted by an attacker.  If the
-   handshake protocol is not run to completion, the client should not
-   make any decisions, nor form any assumptions, based on receiving this
-   alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-4.  References
-
-4.1  Normative References
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-              January 1999.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002,
-              <http://srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
-              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [StringPrep]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPrep]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", draft-ietf-sasl-saslprep-10 (work in
-              progress), July 2004.
-
-   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
-              September 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-              Keyed-Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC3268]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-4.2  Informative References
-
-   [IMAP]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
-           June 1999.
-
-   [FTP]   Ford-Hutchinson, P., "Securing FTP with TLS",
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-           draft-murray-auth-ftp-ssl-15 (work in progress), August 2004.
-
-   [SRP]   Wu, T., "The Secure Remote Password Protocol", Proceedings of
-           the 1998 Internet Society Network and Distributed System
-           Security Symposium pp. 97-111, March 1998.
-
-
-Authors' Addresses
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-   Tom Wu
-   Stanford University
-
-   EMail: tjw@cs.stanford.edu
-
-
-   Nikos Mavroyanopoulos
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-
-   EMail: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-       The generator is: 2.
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-       The generator is: 2.
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-       The generator is: 2.
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-Appendix B.  Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assignees.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication         August 2004
-
-
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires February 17, 2005               [Page 21]
-
-
-

-

diff --git a/doc/protocol/draft-ietf-tls-srp-09.txt b/doc/protocol/draft-ietf-tls-srp-09.txt
deleted file mode 100644
index 28057bd888..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-09.txt
+++ /dev/null
@@ -1,1056 +0,0 @@
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: September 15, 2005                                        T. Wu
-                                                     Stanford University
-                                                    N. Mavrogiannopoulos
-                                                               T. Perrin
-                                                          March 17, 2005
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-09
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on September 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol ([SRP], [SRP-6]) as an authentication method for the
-   Transport Layer Security protocol [TLS].
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 1]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1   Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2   Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3   Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4   SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5   Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2   Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3   Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4   Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6   Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7   Cipher Suite Definitions . . . . . . . . . . . . . . . . .  9
-     2.8   New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1   Client Hello . . . . . . . . . . . . . . . . . . . . .  9
-       2.8.2   Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3   Client Key Exchange  . . . . . . . . . . . . . . . . . 10
-     2.9   Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   4.1   Normative References . . . . . . . . . . . . . . . . . . . . 14
-   4.2   Informative References . . . . . . . . . . . . . . . . . . . 14
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
-   A.  SRP Group Parameters . . . . . . . . . . . . . . . . . . . . . 16
-   B.  SRP Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 20
-   C.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
-       Intellectual Property and Copyright Statements . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 2]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, or
-   Kerberos, for authentication.
-
-   These authentication methods do not seem well suited to the
-   applications now being adapted to use TLS ([IMAP] or [FTP], for
-   example).  Given that these protocols are designed to use the user
-   name and password method of authentication, being able to safely use
-   user names and passwords provides an easier route to additional
-   security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 3]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-2.  SRP Authentication in TLS
-
-2.1  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [RFC2945].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-      s: salt
-      B, b: server's public and private values
-      A, a: client's public and private values
-      I: user name (aka "identity")
-      P: password
-      v: verifier
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the
-   most-significant bytes are stored first, as per [TLS] and [RFC2945].
-   In the following text, if a conversion from integer to byte-string is
-   implicit, the most-significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 4]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-          Client                                 Server
-            |                                      |
-       Client Hello (I) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Certificate*
-            |  <---------------------------- Server Key Exchange (N, g, s, B)
-            |  <---------------------------- Server Hello Done
-       Client Key Exchange (A) ----------------->  |
-       [Change cipher spec]                        |
-       Finished -------------------------------->  |
-            |                        [Change cipher spec]
-            |  <---------------------------- Finished
-            |                                      |
-       Application Data  <--------------> Application Data
-
-   * Indicates an optional message which is not always sent.
-
-                                Figure 1
-
-2.3  Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the [SASLPrep] profile of [StringPrep].
-
-2.4  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [RFC2945].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [TLSEXT] (see
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 5]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-   Section 2.8.1).
-
-2.5.1.1  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the user name extension in
-   the client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.5.1.2  Missing SRP Username
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server MAY return a
-   missing_srp_username alert (see Section 2.9) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.  This
-   allows the client to advertise that it supports SRP, but not have to
-   prompt the user for his user name and password, nor expose the user
-   name in the clear, unless necessary.
-
-   After sending the missing_srp_username alert, the server MUST leave
-   the TLS connection open, yet reset its handshake protocol state so it
-   is prepared to receive a second client hello message.  Upon receiving
-   the missing_srp_username alert, the client MUST either send a second
-   client hello message, or send a fatal user_cancelled alert.
-
-   If the client sends a second hello message, the second hello message
-   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
-   the server MUST choose one of the SRP ciphersuites.  Both client
-   hello messages MUST be treated as handshake messages and included in
-   the hash calculations for the TLS Finished message.  The premaster
-   and master secret calculations will use the random value from the
-   second client hello message, not the first.
-
-2.5.1.3  Unknown SRP Username
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an unknown_srp_username alert
-   (see Section 2.9).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 6]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-   client's finished message with a bad_record_mac alert, as if the
-   password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-2.5.2  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  The SRP group parameters in
-   Appendix A are proven to have these properties, so the client SHOULD
-   accept any parameters from this Appendix which have large enough N
-   values to meet his security requirements.  The client MAY accept
-   other group parameters from the server, either by prior arrangement,
-   or by checking the parameters himself.  See Section 3 for additional
-   security considerations relevant to the acceptance of the group
-   parameters (N, g).
-
-   Group parameters that are not accepted via one of the above methods
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 7]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-   MUST be rejected with an untrusted_srp_parameters alert (see Section
-   2.9).
-
-   The client MUST abort the handshake with an illegal_parameter alert
-   if B % N = 0.
-
-2.5.4  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an illegal_parameter alert
-   if A % N = 0.
-
-2.6  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [RFC2945].  If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a bad_record_mac alert.
-
-   If a client application receives a bad_record_mac alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 8]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-2.7  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [RFC3268].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x50 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA      = { 0x00,0x53 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA  = { 0x00,0x54 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA  = { 0x00,0x55 };
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA      = { 0x00,0x56 };
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA  = { 0x00,0x57 };
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA  = { 0x00,0x58 };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-2.8.1  Client Hello
-
-   A new value, "srp(6)", has been added to the enumerated ExtensionType
-   defined in [TLSEXT].  This value MUST be used as the extension number
-   for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per Section 2.4.
-
-
-
-Taylor, et al.         Expires September 15, 2005               [Page 9]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-2.8.2  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.3  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 10]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9  Error Alerts
-
-   Three new error alerts are defined:
-
-   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-   o  "missing_srp_username" (121) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always a warning.  Upon receiving this alert, the client MAY
-      send a new hello message on the same connection, this time
-      including the SRP extension.  See Section 2.5.1.2 for details.
-   o  "untrusted_srp_parameters" (122) - this alert MUST be sent by a
-      client that receives unknown or untrusted (N, g) values.  This
-      alert is always fatal.  See Section 2.5.3 for details.
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 11]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-3.  Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user account, or
-   locking the user account once a threshold of failed attempts is
-   reached.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-   The received parameters N and g in the Server Key Exchange message
-   are crucial for the security of the user's password.  In particular,
-   an attacker may attempt to substitute values for which he can more
-   easily compute discrete logarithms [TrapDoor].  Algorithmic advances
-   and/or increases in computing power may necessitate increases in the
-   size of N.  As a consequence, clients should ensure that the received
-   parameter N, in addition to passing the checks mentioned in 2.5.3, is
-   also large enough to make discrete logarithms computationally
-   infeasible.  In addition, if a client accepts untrusted values N and
-   g from the Server Key Exchange message, it should ensure that it is
-   not of any special form that would make discrete logarithms easier to
-   compute.  Because of the difficulty of performing this check in the
-   general case, implementors may opt to accept only those parameters
-   that come from a trusted source, such as those listed in Appendix A
-   and parameters locally configured through prior arrangement.
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.
-
-   If the client receives a missing_srp_username alert, the client
-   should be aware that unless the handshake protocol is run to
-   completion, this alert may have been inserted by an attacker.  If the
-   handshake protocol is not run to completion, the client should not
-   make any decisions, nor form any assumptions, based on receiving this
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 12]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-   alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 13]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-4.  References
-
-4.1  Normative References
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-              January 1999.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002,
-              <http://srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
-              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [StringPrep]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPrep]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", draft-ietf-sasl-saslprep-10 (work in
-              progress), July 2004.
-
-   [RFC2945]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
-              September 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-              Keyed-Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC3268]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-4.2  Informative References
-
-   [IMAP]     Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
-              2595, June 1999.
-
-   [FTP]      Ford-Hutchinson, P., "Securing FTP with TLS",
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 14]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-              draft-murray-auth-ftp-ssl-16 (work in progress), February
-              2005.
-
-   [SRP]      Wu, T., "The Secure Remote Password Protocol", Proceedings
-              of the 1998 Internet Society Network and Distributed
-              System Security Symposium pp. 97-111, March 1998.
-
-   [TrapDoor]
-              Gordon, D., "Designing and Detecting Trapdoors for
-              Discrete Log Cryptosystems", Springer-Verlag Advances in
-              Cryptology - Crypto '92, pp. 66-75, 1993.
-
-Authors' Addresses
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   EMail: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-   Tom Wu
-   Stanford University
-
-   EMail: tjw@cs.stanford.edu
-
-   Nikos Mavrogiannopoulos
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-   Trevor Perrin
-
-   EMail: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 15]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-       The generator is: 2.
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-       The generator is: 2.
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 16]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-       The generator is: 2.
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 17]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 18]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 19]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-Appendix B.  SRP Test Vectors
-
-   The following test vectors demonstrate calculation of the verifier
-   and premaster secret.
-
-      I = "alice"
-      P = "password123"
-      s = BEB25379 D1A8581E B5A72767 3A2441EE
-      N, g = <1024-bit parameters from Appendix A>
-      k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
-      x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
-      v =
-         7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
-         9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
-         C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
-         EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
-         E955A5E2 9E7AB245 DB2BE315 E2099AFB
-
-      a =
-         60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
-         DA2D4393
-      b =
-         E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
-         05284D20
-      A =
-         61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
-         4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
-         8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
-         BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
-         B349EF5D 76988A36 72FAC47B 0769447B
-      B =
-         BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
-         BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
-         6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
-         37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
-         EB4012B7 D7665238 A8E3FB00 4B117B58
-      u =
-         CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
-      <premaster secret> =
-         B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
-         233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
-         41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
-         3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
-         C346D7E4 74B29EDE 8A469FFE CA686E5A
-
-
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 20]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-Appendix C.  Acknowledgements
-
-   Thanks to all on the IETF tls mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 21]
-Internet-Draft      Using SRP for TLS Authentication          March 2005
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-Taylor, et al.         Expires September 15, 2005              [Page 22]
diff --git a/doc/protocol/draft-ietf-tls-srp-10.txt b/doc/protocol/draft-ietf-tls-srp-10.txt
deleted file mode 100644
index d7e303cbcc..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-10.txt
+++ /dev/null
@@ -1,1402 +0,0 @@
-
-
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: April 9, 2006                                             T. Wu
-                                                     Stanford University
-                                                    N. Mavrogiannopoulos
-                                                               T. Perrin
-                                                         October 6, 2005
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-10
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on April 9, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol ([SRP], [SRP-6]) as an authentication method for the
-   Transport Layer Security protocol [TLS].
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1.  Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2.  Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3.  Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5.  Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2.  Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3.  Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4.  Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6.  Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7.  Cipher Suite Definitions . . . . . . . . . . . . . . . . .  9
-     2.8.  New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . 10
-       2.8.2.  Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3.  Client Key Exchange  . . . . . . . . . . . . . . . . . 11
-     2.9.  Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     4.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
-     4.2.  Informative References . . . . . . . . . . . . . . . . . . 14
-   Appendix A.  SRP Group Parameters  . . . . . . . . . . . . . . . . 16
-   Appendix B.  SRP Test Vectors  . . . . . . . . . . . . . . . . . . 21
-   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 23
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
-   Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, pre-
-   shared keys, or Kerberos for authentication.
-
-   These authentication methods do not seem well suited to certain
-   applications now being adapted to use TLS ([IMAP] for example).
-   Given that many protocols are designed to use the user name and
-   password method of authentication, being able to safely use user
-   names and passwords provides an easier route to additional security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-2.  SRP Authentication in TLS
-
-2.1.  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [SRP-RFC].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-
-      s: salt
-
-      B, b: server's public and private values
-
-      A, a: client's public and private values
-
-      I: user name (aka "identity")
-
-      P: password
-
-      v: verifier
-
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the most-
-   significant bytes are stored first, as per [TLS] and [SRP-RFC].  In
-   the following text, if a conversion from integer to byte-string is
-   implicit, the most-significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2.  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-          Client                                 Server
-            |                                      |
-       Client Hello (I) ------------------------>  |
-            |  <---------------------------- Server Hello
-            |  <---------------------------- Certificate*
-            |  <---------------------------- Server Key Exchange (N, g, s, B)
-            |  <---------------------------- Server Hello Done
-       Client Key Exchange (A) ----------------->  |
-       [Change cipher spec]                        |
-       Finished -------------------------------->  |
-            |                        [Change cipher spec]
-            |  <---------------------------- Finished
-            |                                      |
-       Application Data  <--------------> Application Data
-
-   * Indicates an optional message which is not always sent.
-
-   Figure 1
-
-2.3.  Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the [SASLPREP] profile of [STRINGPREP].
-
-2.4.  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [SRP-RFC].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1.  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [TLSEXT] (see
-   Section 2.8.1).
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-2.5.1.1.  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the user name extension in
-   the client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.5.1.2.  Missing SRP Username
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server MAY return a
-   missing_srp_username alert (see Section 2.9) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.  This
-   allows the client to advertise that it supports SRP, but not have to
-   prompt the user for his user name and password, nor expose the user
-   name in the clear, unless necessary.
-
-   After sending the missing_srp_username alert, the server MUST leave
-   the TLS connection open, yet reset its handshake protocol state so it
-   is prepared to receive a second client hello message.  Upon receiving
-   the missing_srp_username alert, the client MUST either send a second
-   client hello message, or send a fatal user_cancelled alert.
-
-   If the client sends a second hello message, the second hello message
-   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
-   the server MUST choose one of the SRP ciphersuites.  Both client
-   hello messages MUST be treated as handshake messages and included in
-   the hash calculations for the TLS Finished message.  The premaster
-   and master secret calculations will use the random value from the
-   second client hello message, not the first.
-
-2.5.1.3.  Unknown SRP Username
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an unknown_srp_username alert
-   (see Section 2.9).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-   client's finished message with a bad_record_mac alert, as if the
-   password was incorrect.
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-2.5.2.  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3.  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  In addition, the group
-   parameters MUST NOT be specially chosen to allow efficient
-   computation of discrete logarithms.
-
-   The SRP group parameters in Appendix A satisfy the above
-   requirements, so the client SHOULD accept any parameters from this
-   Appendix which have large enough N values to meet her security
-   requirements.
-
-   The client MAY accept other group parameters from the server, if the
-   client has reason to believe these parameters satisfy the above
-   requirements, and the parameters have large enough N values.  For
-   example, if the parameters transmitted by the server match parameters
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-   on a "known-good" list, the client may choose to accept them.  See
-   Section 3 for additional security considerations relevant to the
-   acceptance of the group parameters.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an untrusted_srp_parameters alert (see
-   Section 2.9).
-
-   The client MUST abort the handshake with an illegal_parameter alert
-   if B % N = 0.
-
-2.5.4.  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an illegal_parameter alert
-   if A % N = 0.
-
-2.6.  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [SRP-RFC].  If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a bad_record_mac alert.
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-   If a client application receives a bad_record_mac alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7.  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [AESCIPH].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x50 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0x53 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x54 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x55 };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0x56 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x57 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x58 };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8.  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                 [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-2.8.1.  Client Hello
-
-   A new value, "srp(6)", has been added to the enumerated ExtensionType
-   defined in [TLSEXT].  This value MUST be used as the extension number
-   for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per Section 2.4.
-
-2.8.2.  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-2.8.3.  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9.  Error Alerts
-
-   Three new error alerts are defined:
-
-   o  "unknown_srp_username" (120) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-
-   o  "missing_srp_username" (121) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always a warning.  Upon receiving this alert, the client MAY
-      send a new hello message on the same connection, this time
-      including the SRP extension.  See Section 2.5.1.2 for details.
-
-   o  "untrusted_srp_parameters" (122) - this alert MUST be sent by a
-      client that receives unknown or untrusted (N, g) values.  This
-      alert is always fatal.  See Section 2.5.3 for details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-3.  Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user account, or
-   locking the user account once a threshold of failed attempts is
-   reached.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-   An attacker who could calculate discrete logarithms in the
-   multiplicative group % N could compromise user passwords, and could
-   also compromise the the confidentiality and integrity of TLS
-   sessions.  Clients MUST ensure that the received parameter N is large
-   enough to make calculating discrete logarithms computationally
-   infeasible.
-
-   An attacker may try to send a prime value N which is large enough to
-   be secure, but which has a special form for which the attacker can
-   more easily compute discrete logarithms (e.g., using the algorithm
-   discussed in [TRAPDOOR]).  If the client executes the protocol using
-   such a prime, the client's password could be compromised.  Because of
-   the difficulty of checking for such special primes in real-time,
-   clients SHOULD only accept group parameters that come from a trusted
-   source, such as those listed in Appendix A, or parameters configured
-   locally by a trusted administrator.
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.
-
-   If the client receives a missing_srp_username alert, the client
-   should be aware that unless the handshake protocol is run to
-   completion, this alert may have been inserted by an attacker.  If the
-   handshake protocol is not run to completion, the client should not
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-   make any decisions, nor form any assumptions, based on receiving this
-   alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-4.  References
-
-4.1.  Normative References
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-              January 1999.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002,
-              <http://srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [STRINGPREP]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPREP]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", RFC 4013, February 2005.
-
-   [SRP-RFC]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
-              September 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [AESCIPH]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)",
-              RFC 3268, June 2002.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-4.2.  Informative References
-
-   [IMAP]     Newman, C., "Using TLS with IMAP, POP3 and ACAP",
-              RFC 2595, June 1999.
-
-   [SRP]      Wu, T., "The Secure Remote Password Protocol", Proceedings
-              of the 1998 Internet Society Network and Distributed
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-              System Security Symposium pp. 97-111, March 1998.
-
-   [TRAPDOOR]
-              Gordon, D., "Designing and Detecting Trapdoors for
-              Discrete Log Cryptosystems", Springer-Verlag Advances in
-              Cryptology - Crypto '92, pp. 66-75, 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-
-       The generator is: 2.
-
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-
-       The generator is: 2.
-
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-
-       The generator is: 2.
-
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-Appendix B.  SRP Test Vectors
-
-   The following test vectors demonstrate calculation of the verifier
-   and premaster secret.
-
-      I = "alice"
-
-      P = "password123"
-
-      s = BEB25379 D1A8581E B5A72767 3A2441EE
-
-      N, g = <1024-bit parameters from Appendix A>
-
-      k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
-
-      x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
-
-      v =
-
-         7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
-         9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
-         C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
-         EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
-         E955A5E2 9E7AB245 DB2BE315 E2099AFB
-
-      a =
-
-         60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
-         DA2D4393
-
-      b =
-
-         E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
-         05284D20
-
-      A =
-
-         61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
-         4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
-         8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
-         BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
-         B349EF5D 76988A36 72FAC47B 0769447B
-
-      B =
-
-         BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
-         BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
-         6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 21]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-         37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
-         EB4012B7 D7665238 A8E3FB00 4B117B58
-
-      u =
-
-         CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
-
-      <premaster secret> =
-
-         B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
-         233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
-         41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
-         3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
-         C346D7E4 74B29EDE 8A469FFE CA686E5A
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 22]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-Appendix C.  Acknowledgements
-
-   Thanks to all on the IETF TLS mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 23]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-Authors' Addresses
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   Email: DavidTaylor@forge.com.au
-   URI:   http://www.forge.com.au/
-
-
-   Tom Wu
-   Stanford University
-
-   Email: tjw@cs.stanford.edu
-
-
-   Nikos Mavrogiannopoulos
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-
-   Email: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 24]
-
-Internet-Draft      Using SRP for TLS Authentication        October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Taylor, et al.            Expires April 9, 2006                [Page 25]
-
-
diff --git a/doc/protocol/draft-ietf-tls-srp-11.txt b/doc/protocol/draft-ietf-tls-srp-11.txt
deleted file mode 100644
index a178d50d3d..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-11.txt
+++ /dev/null
@@ -1,1400 +0,0 @@
-
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                    Forge Research Pty Ltd
-Expires: November 19, 2006                                         T. Wu
-                                                     Stanford University
-                                                    N. Mavrogiannopoulos
-                                                               T. Perrin
-                                                             Independent
-                                                            May 18, 2006
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-11
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on November 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol ([SRP], [SRP-6]) as an authentication method for the
-   Transport Layer Security protocol [TLS].
-
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1.  Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2.  Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3.  Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5.  Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2.  Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3.  Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4.  Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6.  Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7.  Cipher Suite Definitions . . . . . . . . . . . . . . . . .  9
-     2.8.  New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . 10
-       2.8.2.  Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3.  Client Key Exchange  . . . . . . . . . . . . . . . . . 11
-     2.9.  Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-   4.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     4.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
-     4.2.  Informative References . . . . . . . . . . . . . . . . . . 14
-   Appendix A.  SRP Group Parameters  . . . . . . . . . . . . . . . . 16
-   Appendix B.  SRP Test Vectors  . . . . . . . . . . . . . . . . . . 21
-   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 23
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
-   Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, pre-
-   shared keys, or Kerberos for authentication.
-
-   These authentication methods do not seem well suited to certain
-   applications now being adapted to use TLS ([IMAP] for example).
-   Given that many protocols are designed to use the user name and
-   password method of authentication, being able to safely use user
-   names and passwords provides an easier route to additional security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-2.  SRP Authentication in TLS
-
-2.1.  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [SRP-RFC].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-
-      s: salt
-
-      B, b: server's public and private values
-
-      A, a: client's public and private values
-
-      I: user name (aka "identity")
-
-      P: password
-
-      v: verifier
-
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the most-
-   significant bytes are stored first, as per [TLS] and [SRP-RFC].  In
-   the following text, if a conversion from integer to byte-string is
-   implicit, the most-significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2.  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-   Client                                            Server
-
-   Client Hello (I)        -------->
-                                               Server Hello
-                                               Certificate*
-                                        Server Key Exchange (N, g, s, B)
-                           <--------      Server Hello Done
-   Client Key Exchange (A) -------->
-   [Change cipher spec]
-   Finished                -------->
-                                       [Change cipher spec]
-                           <--------               Finished
-
-   Application Data        <------->       Application Data
-
-   * Indicates an optional message which is not always sent.
-
-   Figure 1
-
-2.3.  Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the [SASLPREP] profile of [STRINGPREP].
-
-2.4.  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [SRP-RFC].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1.  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [TLSEXT] (see
-   Section 2.8.1).
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-2.5.1.1.  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the user name extension in
-   the client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.5.1.2.  Missing SRP Username
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server MAY return a
-   "missing_srp_username" alert (see Section 2.9) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.  This
-   allows the client to advertise that it supports SRP, but not have to
-   prompt the user for his user name and password, nor expose the user
-   name in the clear, unless necessary.
-
-   After sending the "missing_srp_username" alert, the server MUST leave
-   the TLS connection open, yet reset its handshake protocol state so it
-   is prepared to receive a second client hello message.  Upon receiving
-   the "missing_srp_username" alert, the client MUST either send a
-   second client hello message, or send a fatal user_cancelled alert.
-
-   If the client sends a second hello message, the second hello message
-   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
-   the server MUST choose one of the SRP ciphersuites.  Both client
-   hello messages MUST be treated as handshake messages and included in
-   the hash calculations for the TLS Finished message.  The premaster
-   and master secret calculations will use the random value from the
-   second client hello message, not the first.
-
-2.5.1.3.  Unknown SRP Username
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an "unknown_srp_username" alert
-   (see Section 2.9).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-   client's finished message with a "bad_record_mac" alert, as if the
-   password was incorrect.
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-2.5.2.  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3.  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  In addition, the group
-   parameters MUST NOT be specially chosen to allow efficient
-   computation of discrete logarithms.
-
-   The SRP group parameters in Appendix A satisfy the above
-   requirements, so the client SHOULD accept any parameters from this
-   Appendix which have large enough N values to meet her security
-   requirements.
-
-   The client MAY accept other group parameters from the server, if the
-   client has reason to believe these parameters satisfy the above
-   requirements, and the parameters have large enough N values.  For
-   example, if the parameters transmitted by the server match parameters
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-   on a "known-good" list, the client may choose to accept them.  See
-   Section 3 for additional security considerations relevant to the
-   acceptance of the group parameters.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an "untrusted_srp_parameters" alert (see
-   Section 2.9).
-
-   The client MUST abort the handshake with an "illegal_parameter" alert
-   if B % N = 0.
-
-2.5.4.  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an "illegal_parameter" alert
-   if A % N = 0.
-
-2.6.  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [SRP-RFC].  If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a "bad_record_mac" alert.
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-   If a client application receives a "bad_record_mac" alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7.  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [AESCIPH].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x?? };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x?? };
-
-   [[ EDITOR: The actual cipher suite numbers will be assigned by IANA.
-   The numbers between 0x50 to 0x58 were suggested. ]]
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8.  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-
-
-
-Taylor, et al.          Expires November 19, 2006               [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-   language used is the same as that used in [TLS].
-
-2.8.1.  Client Hello
-
-   A new extensions "srp" with value ??, [[ EDITOR: This will be
-   assigned by IANA (the value 6 was suggested) ]], has been added to
-   the enumerated ExtensionType defined in [TLSEXT].  This value MUST be
-   used as the extension number for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per Section 2.4.
-
-2.8.2.  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.3.  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9.  Error Alerts
-
-   Three new error alerts are defined:
-
-   o  "unknown_srp_username" (???) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-
-   o  "missing_srp_username" (???) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always a warning.  Upon receiving this alert, the client MAY
-      send a new hello message on the same connection, this time
-      including the SRP extension.  See Section 2.5.1.2 for details.
-
-   o  "untrusted_srp_parameters" (???) - this alert MUST be sent by a
-      client that receives unknown or untrusted (N, g) values.  This
-      alert is always fatal.  See Section 2.5.3 for details.
-
-   [[ EDITOR: Error alert numbers are to be assigned by IANA.  The
-   values 120 to 122 are suggested. ]]
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-3.  Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user account, or
-   locking the user account once a threshold of failed attempts is
-   reached.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-   An attacker who could calculate discrete logarithms in the
-   multiplicative group % N could compromise user passwords, and could
-   also compromise the the confidentiality and integrity of TLS
-   sessions.  Clients MUST ensure that the received parameter N is large
-   enough to make calculating discrete logarithms computationally
-   infeasible.
-
-   An attacker may try to send a prime value N which is large enough to
-   be secure, but which has a special form for which the attacker can
-   more easily compute discrete logarithms (e.g., using the algorithm
-   discussed in [TRAPDOOR]).  If the client executes the protocol using
-   such a prime, the client's password could be compromised.  Because of
-   the difficulty of checking for such special primes in real-time,
-   clients SHOULD only accept group parameters that come from a trusted
-   source, such as those listed in Appendix A, or parameters configured
-   locally by a trusted administrator.
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.
-
-   If the client receives a missing_srp_username alert, the client
-   should be aware that unless the handshake protocol is run to
-   completion, this alert may have been inserted by an attacker.  If the
-   handshake protocol is not run to completion, the client should not
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-   make any decisions, nor form any assumptions, based on receiving this
-   alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-4.  References
-
-4.1.  Normative References
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-              January 1999.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002,
-              <http://srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [STRINGPREP]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPREP]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", RFC 4013, February 2005.
-
-   [SRP-RFC]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
-              September 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [AESCIPH]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)",
-              RFC 3268, June 2002.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-4.2.  Informative References
-
-   [IMAP]     Newman, C., "Using TLS with IMAP, POP3 and ACAP",
-              RFC 2595, June 1999.
-
-   [SRP]      Wu, T., "The Secure Remote Password Protocol", Proceedings
-              of the 1998 Internet Society Network and Distributed
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-              System Security Symposium pp. 97-111, March 1998.
-
-   [TRAPDOOR]
-              Gordon, D., "Designing and Detecting Trapdoors for
-              Discrete Log Cryptosystems", Springer-Verlag Advances in
-              Cryptology - Crypto '92, pp. 66-75, 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-
-       The generator is: 2.
-
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-
-       The generator is: 2.
-
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-
-       The generator is: 2.
-
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-Appendix B.  SRP Test Vectors
-
-   The following test vectors demonstrate calculation of the verifier
-   and premaster secret.
-
-      I = "alice"
-
-      P = "password123"
-
-      s = BEB25379 D1A8581E B5A72767 3A2441EE
-
-      N, g = <1024-bit parameters from Appendix A>
-
-      k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
-
-      x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
-
-      v =
-
-         7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
-         9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
-         C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
-         EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
-         E955A5E2 9E7AB245 DB2BE315 E2099AFB
-
-      a =
-
-         60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
-         DA2D4393
-
-      b =
-
-         E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
-         05284D20
-
-      A =
-
-         61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
-         4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
-         8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
-         BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
-         B349EF5D 76988A36 72FAC47B 0769447B
-
-      B =
-
-         BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
-         BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
-         6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 21]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-         37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
-         EB4012B7 D7665238 A8E3FB00 4B117B58
-
-      u =
-
-         CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
-
-      <premaster secret> =
-
-         B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
-         233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
-         41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
-         3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
-         C346D7E4 74B29EDE 8A469FFE CA686E5A
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 22]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-Appendix C.  Acknowledgements
-
-   Thanks to all on the IETF TLS mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 23]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-Authors' Addresses
-
-   David Taylor
-   Forge Research Pty Ltd
-
-   Email: dtaylor@swiftdsl.com.au
-
-
-   Tom Wu
-   Stanford University
-
-   Email: tjw@cs.stanford.edu
-
-
-   Nikos Mavrogiannopoulos
-   Independent
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-   Independent
-
-   Email: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 24]
-
-Internet-Draft      Using SRP for TLS Authentication            May 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Taylor, et al.          Expires November 19, 2006              [Page 25]
-
diff --git a/doc/protocol/draft-ietf-tls-srp-12.txt b/doc/protocol/draft-ietf-tls-srp-12.txt
deleted file mode 100644
index 57d471b16d..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-12.txt
+++ /dev/null
@@ -1,1512 +0,0 @@
-
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                               Independent
-Expires: December 28, 2006                                         T. Wu
-                                                     Stanford University
-                                                    N. Mavrogiannopoulos
-                                                               T. Perrin
-                                                             Independent
-                                                           June 26, 2006
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-12
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 28, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol as an authentication method for the Transport Layer Security
-   protocol.
-
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1.  Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2.  Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3.  Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5.  Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2.  Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3.  Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4.  Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6.  Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7.  Cipher Suite Definitions . . . . . . . . . . . . . . . . .  9
-     2.8.  New Message Structures . . . . . . . . . . . . . . . . . . 10
-       2.8.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . 10
-       2.8.2.  Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3.  Client Key Exchange  . . . . . . . . . . . . . . . . . 11
-     2.9.  Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
-     5.2.  Informative References . . . . . . . . . . . . . . . . . . 16
-   Appendix A.  SRP Group Parameters  . . . . . . . . . . . . . . . . 18
-   Appendix B.  SRP Test Vectors  . . . . . . . . . . . . . . . . . . 23
-   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 25
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
-   Intellectual Property and Copyright Statements . . . . . . . . . . 27
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, pre-
-   shared keys, or Kerberos for authentication.
-
-   These authentication methods do not seem well suited to certain
-   applications now being adapted to use TLS ([IMAP] for example).
-   Given that many protocols are designed to use the user name and
-   password method of authentication, being able to safely use user
-   names and passwords provides an easier route to additional security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-2.  SRP Authentication in TLS
-
-2.1.  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [SRP-RFC].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-
-      s: salt
-
-      B, b: server's public and private values
-
-      A, a: client's public and private values
-
-      I: user name (aka "identity")
-
-      P: password
-
-      v: verifier
-
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the most-
-   significant bytes are stored first, as per [TLS] and [SRP-RFC].  In
-   the following text, if a conversion from integer to byte-string is
-   implicit, the most-significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2.  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-   Client                                            Server
-
-   Client Hello (I)        -------->
-                                               Server Hello
-                                               Certificate*
-                                        Server Key Exchange (N, g, s, B)
-                           <--------      Server Hello Done
-   Client Key Exchange (A) -------->
-   [Change cipher spec]
-   Finished                -------->
-                                       [Change cipher spec]
-                           <--------               Finished
-
-   Application Data        <------->       Application Data
-
-   * Indicates an optional message which is not always sent.
-
-   Figure 1
-
-2.3.  Text Preparation
-
-   The user name and password strings shall be UTF-8 encoded Unicode,
-   prepared using the [SASLPREP] profile of [STRINGPREP].
-
-2.4.  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [SRP-RFC].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1.  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the hello message extension mechanism defined in [TLSEXT] (see
-   Section 2.8.1).
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-2.5.1.1.  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the user name extension in
-   the client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.5.1.2.  Missing SRP Username
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server MAY return a
-   "missing_srp_username" alert (see Section 2.9) immediately after
-   processing the client hello message.  This alert signals the client
-   to resend the hello message, this time with the SRP extension.  This
-   allows the client to advertise that it supports SRP, but not have to
-   prompt the user for his user name and password, nor expose the user
-   name in the clear, unless necessary.
-
-   After sending the "missing_srp_username" alert, the server MUST leave
-   the TLS connection open, yet reset its handshake protocol state so it
-   is prepared to receive a second client hello message.  Upon receiving
-   the "missing_srp_username" alert, the client MUST either send a
-   second client hello message, or send a fatal user_cancelled alert.
-
-   If the client sends a second hello message, the second hello message
-   MUST offer SRP ciphersuites, and MUST contain the SRP extension, and
-   the server MUST choose one of the SRP ciphersuites.  Both client
-   hello messages MUST be treated as handshake messages and included in
-   the hash calculations for the TLS Finished message.  The premaster
-   and master secret calculations will use the random value from the
-   second client hello message, not the first.
-
-2.5.1.3.  Unknown SRP Username
-
-   If the server doesn't have a verifier for the given user name, the
-   server MAY abort the handshake with an "unknown_srp_username" alert
-   (see Section 2.9).  Alternatively, if the server wishes to hide the
-   fact that this user name doesn't have a verifier, the server MAY
-   simulate the protocol as if a verifier existed, but then reject the
-   client's finished message with a "bad_record_mac" alert, as if the
-   password was incorrect.
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-2.5.2.  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3.  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  In addition, the group
-   parameters MUST NOT be specially chosen to allow efficient
-   computation of discrete logarithms.
-
-   The SRP group parameters in Appendix A satisfy the above
-   requirements, so the client SHOULD accept any parameters from this
-   Appendix which have large enough N values to meet her security
-   requirements.
-
-   The client MAY accept other group parameters from the server, if the
-   client has reason to believe these parameters satisfy the above
-   requirements, and the parameters have large enough N values.  For
-   example, if the parameters transmitted by the server match parameters
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-   on a "known-good" list, the client may choose to accept them.  See
-   Section 3 for additional security considerations relevant to the
-   acceptance of the group parameters.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an "untrusted_srp_parameters" alert (see
-   Section 2.9).
-
-   The client MUST abort the handshake with an "illegal_parameter" alert
-   if B % N = 0.
-
-2.5.4.  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an "illegal_parameter" alert
-   if A % N = 0.
-
-2.6.  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [SRP-RFC].  If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a "bad_record_mac" alert.
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-   If a client application receives a "bad_record_mac" alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7.  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [AESCIPH].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD5 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD6
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD7
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD8 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD9
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0xTBD10
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD11 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD12
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0xTBD13
-      };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006               [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-2.8.  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-2.8.1.  Client Hello
-
-   A new extension "srp" with value TBD1, has been added to the
-   enumerated ExtensionType defined in [TLSEXT].  This value MUST be
-   used as the extension number for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per Section 2.4.
-
-2.8.2.  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.3.  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9.  Error Alerts
-
-   Three new error alerts are defined:
-
-   o  "unknown_srp_username" (TBD2) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-   o  "missing_srp_username" (TBD3) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always a warning.  Upon receiving this alert, the client MAY
-      send a new hello message on the same connection, this time
-      including the SRP extension.  See Section 2.5.1.2 for details.
-
-   o  "untrusted_srp_parameters" (TBD4) - this alert MUST be sent by a
-      client that receives unknown or untrusted (N, g) values.  This
-      alert is always fatal.  See Section 2.5.3 for details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-3.  Security Considerations
-
-   If an attacker is able to steal the SRP verifier file, the attacker
-   can masquerade as the real server, and can also use dictionary
-   attacks to recover client passwords.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user account, or
-   locking the user account once a threshold of failed attempts is
-   reached.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous, or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-   An attacker who could calculate discrete logarithms in the
-   multiplicative group % N could compromise user passwords, and could
-   also compromise the the confidentiality and integrity of TLS
-   sessions.  Clients MUST ensure that the received parameter N is large
-   enough to make calculating discrete logarithms computationally
-   infeasible.
-
-   An attacker may try to send a prime value N which is large enough to
-   be secure, but which has a special form for which the attacker can
-   more easily compute discrete logarithms (e.g., using the algorithm
-   discussed in [TRAPDOOR]).  If the client executes the protocol using
-   such a prime, the client's password could be compromised.  Because of
-   the difficulty of checking for such special primes in real-time,
-   clients SHOULD only accept group parameters that come from a trusted
-   source, such as those listed in Appendix A, or parameters configured
-   locally by a trusted administrator.
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are crucial for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.
-
-   If the client receives a missing_srp_username alert, the client
-   should be aware that unless the handshake protocol is run to
-   completion, this alert may have been inserted by an attacker.  If the
-   handshake protocol is not run to completion, the client should not
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-   make any decisions, nor form any assumptions, based on receiving this
-   alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-4.  IANA Considerations
-
-   This document defines a new TLS extension "srp", assigned the value
-   TBD1 (the value 6 is suggested) from the TLS ExtensionType registry
-   defined in [TLSEXT].
-
-   The error alerts that are defined in this document are assigned to
-   the TLS Alert registry defined in [TLS].  The alerts together with
-   their assigned number (the values 120-122 are suggested) are shown
-   below.
-
-   o  "unknown_srp_username" (TBD2)
-
-   o  "missing_srp_username" (TBD3)
-
-   o  "untrusted_srp_parameters" (TBD4)
-
-   IANA assigned the cipher suites' numbers to the Cipher Suite
-   Registry, defined in [TLS].  The assigned values are listed below
-   (the numbers between 0x50 to 0x58 are suggested).
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD5 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD6
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0xTBD7
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD8 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0xTBD9
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0xTBD10
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD11 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0xTBD12
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0xTBD13
-      };
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-5.  References
-
-5.1.  Normative References
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol version
-              1.1", RFC 4346, April 2006.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002,
-              <http://srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "TLS Extensions", RFC 3546, June 2003.
-
-   [STRINGPREP]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPREP]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", RFC 4013, February 2005.
-
-   [SRP-RFC]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Announcing the Secure Hash Standard", FIPS 180-1,
-              September 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [AESCIPH]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)",
-              RFC 3268, June 2002.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-5.2.  Informative References
-
-   [IMAP]     Newman, C., "Using TLS with IMAP, POP3 and ACAP",
-              RFC 2595, June 1999.
-
-   [SRP]      Wu, T., "The Secure Remote Password Protocol", Proceedings
-              of the 1998 Internet Society Network and Distributed
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-              System Security Symposium pp. 97-111, March 1998.
-
-   [TRAPDOOR]
-              Gordon, D., "Designing and Detecting Trapdoors for
-              Discrete Log Cryptosystems", Springer-Verlag Advances in
-              Cryptology - Crypto '92, pp. 66-75, 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-
-       The generator is: 2.
-
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-
-       The generator is: 2.
-
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-
-       The generator is: 2.
-
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 21]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 22]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-Appendix B.  SRP Test Vectors
-
-   The following test vectors demonstrate calculation of the verifier
-   and premaster secret.
-
-      I = "alice"
-
-      P = "password123"
-
-      s = BEB25379 D1A8581E B5A72767 3A2441EE
-
-      N, g = <1024-bit parameters from Appendix A>
-
-      k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
-
-      x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
-
-      v =
-
-         7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
-         9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
-         C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
-         EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
-         E955A5E2 9E7AB245 DB2BE315 E2099AFB
-
-      a =
-
-         60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
-         DA2D4393
-
-      b =
-
-         E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
-         05284D20
-
-      A =
-
-         61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
-         4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
-         8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
-         BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
-         B349EF5D 76988A36 72FAC47B 0769447B
-
-      B =
-
-         BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
-         BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
-         6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 23]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-         37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
-         EB4012B7 D7665238 A8E3FB00 4B117B58
-
-      u =
-
-         CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
-
-      <premaster secret> =
-
-         B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
-         233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
-         41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
-         3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
-         C346D7E4 74B29EDE 8A469FFE CA686E5A
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 24]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-Appendix C.  Acknowledgements
-
-   Thanks to all on the IETF TLS mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 25]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-Authors' Addresses
-
-   David Taylor
-   Independent
-
-   Email: dtaylor@gnutls.org
-
-
-   Tom Wu
-   Stanford University
-
-   Email: tjw@cs.stanford.edu
-
-
-   Nikos Mavrogiannopoulos
-   Independent
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-   Independent
-
-   Email: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 26]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Taylor, et al.          Expires December 28, 2006              [Page 27]
-
diff --git a/doc/protocol/draft-ietf-tls-srp-13.txt b/doc/protocol/draft-ietf-tls-srp-13.txt
deleted file mode 100644
index 800b7192ca..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-13.txt
+++ /dev/null
@@ -1,1457 +0,0 @@
-
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                               Independent
-Expires: June 17, 2007                                             T. Wu
-                                                     Stanford University
-                                                    N. Mavrogiannopoulos
-                                                               T. Perrin
-                                                             Independent
-                                                       December 14, 2006
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-13
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 17, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2006).
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol as an authentication method for the Transport Layer Security
-   protocol.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1.  Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2.  Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3.  Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5.  Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2.  Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3.  Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4.  Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6.  Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7.  Cipher Suite Definitions . . . . . . . . . . . . . . . . .  8
-     2.8.  New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  9
-       2.8.2.  Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3.  Client Key Exchange  . . . . . . . . . . . . . . . . . 10
-     2.9.  Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-     3.1.  General Considerations for Implementors  . . . . . . . . . 12
-     3.2.  Accepting Group Parameters . . . . . . . . . . . . . . . . 12
-     3.3.  Protocol Characteristics . . . . . . . . . . . . . . . . . 12
-     3.4.  Hash Function Considerations . . . . . . . . . . . . . . . 13
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     5.2.  Informative References . . . . . . . . . . . . . . . . . . 16
-   Appendix A.  SRP Group Parameters  . . . . . . . . . . . . . . . . 17
-   Appendix B.  SRP Test Vectors  . . . . . . . . . . . . . . . . . . 22
-   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 24
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
-   Intellectual Property and Copyright Statements . . . . . . . . . . 26
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, pre-
-   shared keys, or Kerberos for authentication.
-
-   These authentication methods do not seem well suited to certain
-   applications now being adapted to use TLS ([IMAP] for example).
-   Given that many protocols are designed to use the user name and
-   password method of authentication, being able to safely use user
-   names and passwords provides an easier route to additional security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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 [REQ].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-2.  SRP Authentication in TLS
-
-2.1.  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [SRP-RFC].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-
-      s: salt
-
-      B, b: server's public and private values
-
-      A, a: client's public and private values
-
-      I: user name (aka "identity")
-
-      P: password
-
-      v: verifier
-
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the most-
-   significant bytes are stored first, as per [TLS] and [SRP-RFC].  In
-   the following text, if a conversion from integer to byte-string is
-   implicit, the most-significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2.  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-   Client                                            Server
-
-   Client Hello (I)        -------->
-                                               Server Hello
-                                               Certificate*
-                                        Server Key Exchange (N, g, s, B)
-                           <--------      Server Hello Done
-   Client Key Exchange (A) -------->
-   [Change cipher spec]
-   Finished                -------->
-                                       [Change cipher spec]
-                           <--------               Finished
-
-   Application Data        <------->       Application Data
-
-   * Indicates an optional message which is not always sent.
-
-                                 Figure 1
-
-2.3.  Text Preparation
-
-   The user name and password strings SHALL be UTF-8 encoded Unicode,
-   prepared using the [SASLPREP] profile of [STRINGPREP].
-
-2.4.  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [SRP-RFC].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1.  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the extension mechanism defined in [TLSEXT] (see Section 2.8.1).
-   This user name extension is henceforth called the "SRP extension".
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-   The following subsections give details of its use.
-
-2.5.1.1.  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the SRP extension in the
-   client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.5.1.2.  Missing SRP Extension
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server SHOULD return a fatal
-   "unknown_psk_identity" alert (see Section 2.9) immediately after
-   processing the client hello message.
-
-   A client receiving this alert MAY choose to reconnect and resend the
-   hello message, this time with the SRP extension.  This allows the
-   client to advertise that it supports SRP, but not have to prompt the
-   user for his user name and password, nor expose the user name in the
-   clear, unless necessary.
-
-2.5.1.3.  Unknown SRP Username
-
-   If the server doesn't have a verifier for the user name in the SRP
-   extension, the server MAY abort the handshake with an
-   "unknown_psk_identity" alert (see Section 2.9).  Alternatively, if
-   the server wishes to hide the fact that this user name doesn't have a
-   verifier, the server MAY simulate the protocol as if a verifier
-   existed, but then reject the client's finished message with a
-   "bad_record_mac" alert, as if the password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-2.5.2.  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3.  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  In addition, the group
-   parameters MUST NOT be specially chosen to allow efficient
-   computation of discrete logarithms.
-
-   The SRP group parameters in Appendix A satisfy the above
-   requirements, so the client SHOULD accept any parameters from this
-   Appendix which have large enough N values to meet her security
-   requirements.
-
-   The client MAY accept other group parameters from the server, if the
-   client has reason to believe these parameters satisfy the above
-   requirements, and the parameters have large enough N values.  For
-   example, if the parameters transmitted by the server match parameters
-   on a "known-good" list, the client may choose to accept them.  See
-   Section 3 for additional security considerations relevant to the
-   acceptance of the group parameters.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an "insufficient_security" alert (see
-   Section 2.9).
-
-   The client MUST abort the handshake with an "illegal_parameter" alert
-   if B % N = 0.
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-2.5.4.  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an "illegal_parameter" alert
-   if A % N = 0.
-
-2.6.  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [SRP-RFC].  If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a "bad_record_mac" alert.
-
-   If a client application receives a "bad_record_mac" alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7.  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [AESCIPH].
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD2 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD3
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD4
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD5 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD6
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD7
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD8 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD9
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD10
-      };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8.  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-2.8.1.  Client Hello
-
-   A new extension "srp" with value TBD1, has been added to the
-   enumerated ExtensionType defined in [TLSEXT].  This value MUST be
-
-
-
-Taylor, et al.            Expires June 17, 2007                 [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-   used as the extension number for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>
-
-   where srp_I is the user name, encoded per Section 2.3.
-
-2.8.2.  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.3.  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9.  Error Alerts
-
-   This document introduces four new uses of alerts:
-
-   o  "unknown_psk_identity" (115) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always fatal.  See Section 2.5.1.2 for details.
-
-   o  "unknown_psk_identity" (115) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-
-   o  "insufficient_security" (71) - this alert MUST be sent by a client
-      that receives unknown or untrusted (N, g) values.  This alert is
-      always fatal.  See Section 2.5.3 for details.
-
-   o  "illegal_parameter" (47) - this alert MUST be sent by a client or
-      server that receives a key exchange message with A % N = 0 or B %
-      N = 0.  This alert is always fatal.  See Section 2.5.3 and
-      Section 2.5.4 and for details.
-
-   The "insufficient_security" and "illegal_parameter" alerts are
-   defined in [TLS].  The "unknown_psk_identity" alert is defined in
-   [PSK].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-3.  Security Considerations
-
-3.1.  General Considerations for Implementors
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are CRUCIAL for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.  See [TLS] section D.1 for advice on
-   choosing cryptographically secure random numbers.
-
-3.2.  Accepting Group Parameters
-
-   An attacker who could calculate discrete logarithms % N could
-   compromise user passwords, and could also compromise the the
-   confidentiality and integrity of TLS sessions.  Clients MUST ensure
-   that the received parameter N is large enough to make calculating
-   discrete logarithms computationally infeasible.
-
-   An attacker may try to send a prime value N which is large enough to
-   be secure, but which has a special form for which the attacker can
-   more easily compute discrete logarithms (e.g., using the algorithm
-   discussed in [TRAPDOOR]).  If the client executes the protocol using
-   such a prime, the client's password could be compromised.  Because of
-   the difficulty of checking for such primes in real-time, clients
-   SHOULD only accept group parameters that come from a trusted source,
-   such as those listed in Appendix A, or parameters configured locally
-   by a trusted administrator.
-
-3.3.  Protocol Characteristics
-
-   If an attacker learns a user's SRP verifier (e.g., by gaining access
-   to a server's password file), the attacker can masquerade as the real
-   server to that user, and can also attempt a dictionary attack to
-   recover that user's password.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user name.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-   If the client receives an "unknown_psk_identity" alert in response to
-   a client hello, this alert may have been inserted by an attacker.
-   The client should be careful about making any decisions, or forming
-   any conclusions, based on receiving this alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-3.4.  Hash Function Considerations
-
-   This protocol uses SHA-1 to derive several values:
-
-   o  u prevents an attacker who learns a user's verifier from being
-      able to authenticate as that user (see [SRP-6]).
-
-   o  k prevents an attacker who can select group parameters from being
-      able to launch a 2-for-1 guessing attack (see [SRP-6]).
-
-   o  x contains the user's password mixed with a salt.
-
-   Cryptanalytic attacks against SHA-1 which only affect its collision-
-   resistance do not compromise these uses.  If attacks against SHA-1
-   are discovered which do compromise these uses, new ciphersuites
-   should be specified to use a different hash algorithm.
-
-   In this situation, clients could send a Client Hello message
-   containing new and/or old SRP ciphersuites along with a single SRP
-   extension.  The server could then select the appropriate ciphersuite
-   based on the type of verifier it has stored for this user.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-4.  IANA Considerations
-
-   This document defines a new TLS extension "srp" (value TBD1), whose
-   value is to be assigned from the TLS ExtensionType Registry defined
-   in [TLSEXT].
-
-   This document defines nine new ciphersuites, whose values are to be
-   assigned from the TLS Cipher Suite registry defined in [TLS].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD2 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD3
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD4
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD5 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD6
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD7
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD8 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD9
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD10
-      };
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-5.  References
-
-5.1.  Normative References
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol version
-              1.1", RFC 4346, April 2006.
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", October 2002,
-              <http://srp.stanford.edu/srp6.ps>.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [STRINGPREP]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPREP]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", RFC 4013, February 2005.
-
-   [SRP-RFC]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Secure Hash Standard (SHS)", FIPS 180-2, August 2002.
-
-   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [AESCIPH]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)",
-              RFC 3268, June 2002.
-
-   [PSK]      Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-5.2.  Informative References
-
-   [IMAP]     Newman, C., "Using TLS with IMAP, POP3 and ACAP",
-              RFC 2595, June 1999.
-
-   [SRP]      Wu, T., "The Secure Remote Password Protocol", Proceedings
-              of the 1998 Internet Society Network and Distributed
-              System Security Symposium pp. 97-111, March 1998.
-
-   [TRAPDOOR]
-              Gordon, D., "Designing and Detecting Trapdoors for
-              Discrete Log Cryptosystems", Springer-Verlag Advances in
-              Cryptology - Crypto '92, pp. 66-75, 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-
-       The generator is: 2.
-
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-
-       The generator is: 2.
-
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-
-       The generator is: 2.
-
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 21]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-Appendix B.  SRP Test Vectors
-
-   The following test vectors demonstrate calculation of the verifier
-   and premaster secret.
-
-      I = "alice"
-
-      P = "password123"
-
-      s = BEB25379 D1A8581E B5A72767 3A2441EE
-
-      N, g = <1024-bit parameters from Appendix A>
-
-      k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
-
-      x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
-
-      v =
-
-         7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
-         9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
-         C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
-         EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
-         E955A5E2 9E7AB245 DB2BE315 E2099AFB
-
-      a =
-
-         60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
-         DA2D4393
-
-      b =
-
-         E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
-         05284D20
-
-      A =
-
-         61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
-         4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
-         8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
-         BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
-         B349EF5D 76988A36 72FAC47B 0769447B
-
-      B =
-
-         BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
-         BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
-         6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 22]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-         37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
-         EB4012B7 D7665238 A8E3FB00 4B117B58
-
-      u =
-
-         CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
-
-      <premaster secret> =
-
-         B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
-         233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
-         41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
-         3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
-         C346D7E4 74B29EDE 8A469FFE CA686E5A
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 23]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-Appendix C.  Acknowledgements
-
-   Thanks to all on the IETF TLS mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 24]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-Authors' Addresses
-
-   David Taylor
-   Independent
-
-   Email: dtaylor@gnutls.org
-
-
-   Tom Wu
-   Stanford University
-
-   Email: tjw@cs.stanford.edu
-
-
-   Nikos Mavrogiannopoulos
-   Independent
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-   Independent
-
-   Email: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 25]
-
-Internet-Draft      Using SRP for TLS Authentication       December 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Taylor, et al.            Expires June 17, 2007                [Page 26]
-
-
diff --git a/doc/protocol/draft-ietf-tls-srp-14.txt b/doc/protocol/draft-ietf-tls-srp-14.txt
deleted file mode 100644
index 5ebc432932..0000000000
--- a/doc/protocol/draft-ietf-tls-srp-14.txt
+++ /dev/null
@@ -1,1457 +0,0 @@
-
-
-
-TLS Working Group                                              D. Taylor
-Internet-Draft                                               Independent
-Expires: December 15, 2007                                         T. Wu
-                                                     Stanford University
-                                                    N. Mavrogiannopoulos
-                                                               T. Perrin
-                                                             Independent
-                                                           June 13, 2007
-
-
-                    Using SRP for TLS Authentication
-                         draft-ietf-tls-srp-14
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 15, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 1]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol as an authentication method for the Transport Layer Security
-   protocol.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  4
-     2.1.  Notation and Terminology . . . . . . . . . . . . . . . . .  4
-     2.2.  Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3.  Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5.  Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  5
-       2.5.2.  Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3.  Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4.  Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6.  Calculating the Pre-master Secret  . . . . . . . . . . . .  8
-     2.7.  Cipher Suite Definitions . . . . . . . . . . . . . . . . .  8
-     2.8.  New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  9
-       2.8.2.  Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3.  Client Key Exchange  . . . . . . . . . . . . . . . . . 10
-     2.9.  Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-     3.1.  General Considerations for Implementors  . . . . . . . . . 12
-     3.2.  Accepting Group Parameters . . . . . . . . . . . . . . . . 12
-     3.3.  Protocol Characteristics . . . . . . . . . . . . . . . . . 12
-     3.4.  Hash Function Considerations . . . . . . . . . . . . . . . 13
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     5.2.  Informative References . . . . . . . . . . . . . . . . . . 15
-   Appendix A.  SRP Group Parameters  . . . . . . . . . . . . . . . . 17
-   Appendix B.  SRP Test Vectors  . . . . . . . . . . . . . . . . . . 22
-   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 24
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
-   Intellectual Property and Copyright Statements . . . . . . . . . . 26
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 2]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, pre-
-   shared keys, or Kerberos for authentication.
-
-   These authentication methods do not seem well suited to certain
-   applications now being adapted to use TLS ([IMAP] for example).
-   Given that many protocols are designed to use the user name and
-   password method of authentication, being able to safely use user
-   names and passwords provides an easier route to additional security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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 [REQ].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 3]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-2.  SRP Authentication in TLS
-
-2.1.  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [SRP-RFC].
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-
-      s: salt
-
-      B, b: server's public and private values
-
-      A, a: client's public and private values
-
-      I: user name (aka "identity")
-
-      P: password
-
-      v: verifier
-
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the most-
-   significant bytes are stored first, as per [TLS] and [SRP-RFC].  In
-   the following text, if a conversion from integer to byte-string is
-   implicit, the most-significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2.  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 4]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-   Client                                            Server
-
-   Client Hello (I)        -------->
-                                               Server Hello
-                                               Certificate*
-                                        Server Key Exchange (N, g, s, B)
-                           <--------      Server Hello Done
-   Client Key Exchange (A) -------->
-   [Change cipher spec]
-   Finished                -------->
-                                       [Change cipher spec]
-                           <--------               Finished
-
-   Application Data        <------->       Application Data
-
-   * Indicates an optional message which is not always sent.
-
-                                 Figure 1
-
-2.3.  Text Preparation
-
-   The user name and password strings SHALL be UTF-8 encoded Unicode,
-   prepared using the [SASLPREP] profile of [STRINGPREP].
-
-2.4.  SRP Verifier Creation
-
-   The verifier is calculated as described in section 3 of [SRP-RFC].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-2.5.1.  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the extension mechanism defined in [TLSEXT] (see Section 2.8.1).
-   This user name extension is henceforth called the "SRP extension".
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 5]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-   The following subsections give details of its use.
-
-2.5.1.1.  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the SRP extension in the
-   client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure attackers cannot replace the authenticated identity
-   without supplying the proper authentication information.
-
-2.5.1.2.  Missing SRP Extension
-
-   The client may offer SRP ciphersuites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP
-   ciphersuite in this case, the server SHOULD return a fatal
-   "unknown_psk_identity" alert (see Section 2.9) immediately after
-   processing the client hello message.
-
-   A client receiving this alert MAY choose to reconnect and resend the
-   hello message, this time with the SRP extension.  This allows the
-   client to advertise that it supports SRP, but not have to prompt the
-   user for his user name and password, nor expose the user name in the
-   clear, unless necessary.
-
-2.5.1.3.  Unknown SRP Username
-
-   If the server doesn't have a verifier for the user name in the SRP
-   extension, the server MAY abort the handshake with an
-   "unknown_psk_identity" alert (see Section 2.9).  Alternatively, if
-   the server wishes to hide the fact that this user name doesn't have a
-   verifier, the server MAY simulate the protocol as if a verifier
-   existed, but then reject the client's finished message with a
-   "bad_record_mac" alert, as if the password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 6]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-2.5.2.  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which ciphersuites defined in this document require a server
-   certificate to be sent.
-
-2.5.3.  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number which SHOULD be at least 256 bits in
-   length, and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  In addition, the group
-   parameters MUST NOT be specially chosen to allow efficient
-   computation of discrete logarithms.
-
-   The SRP group parameters in Appendix A satisfy the above
-   requirements, so the client SHOULD accept any parameters from this
-   Appendix which have large enough N values to meet her security
-   requirements.
-
-   The client MAY accept other group parameters from the server, if the
-   client has reason to believe these parameters satisfy the above
-   requirements, and the parameters have large enough N values.  For
-   example, if the parameters transmitted by the server match parameters
-   on a "known-good" list, the client may choose to accept them.  See
-   Section 3 for additional security considerations relevant to the
-   acceptance of the group parameters.
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an "insufficient_security" alert (see
-   Section 2.9).
-
-   The client MUST abort the handshake with an "illegal_parameter" alert
-   if B % N = 0.
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 7]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-2.5.4.  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number which SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an "illegal_parameter" alert
-   if A % N = 0.
-
-2.6.  Calculating the Pre-master Secret
-
-   The pre-master secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The pre-master secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [SRP-RFC].  If
-   either the client or the server calculate an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a "bad_record_mac" alert.
-
-   If a client application receives a "bad_record_mac" alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-2.7.  Cipher Suite Definitions
-
-   The following cipher suites are added by this draft.  The usage of
-   AES ciphersuites is as defined in [AESCIPH].
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 8]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD2 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD3
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD4
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD5 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD6
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD7
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD8 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD9
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD10
-      };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume the server is authenticated by its possesion of the
-   SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   ciphersuites, and MAY implement the remaining ciphersuites.
-
-2.8.  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-2.8.1.  Client Hello
-
-   A new extension "srp" with value TBD1, has been added to the
-   enumerated ExtensionType defined in [TLSEXT].  This value MUST be
-
-
-
-Taylor, et al.          Expires December 15, 2007               [Page 9]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-   used as the extension number for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>;
-
-   where srp_I is the user name, encoded per Section 2.3.
-
-2.8.2.  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>;
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-2.8.3.  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 10]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9.  Error Alerts
-
-   This document introduces four new uses of alerts:
-
-   o  "unknown_psk_identity" (115) - this alert MAY be sent by a server
-      that would like to select an offered SRP ciphersuite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always fatal.  See Section 2.5.1.2 for details.
-
-   o  "unknown_psk_identity" (115) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-
-   o  "insufficient_security" (71) - this alert MUST be sent by a client
-      that receives unknown or untrusted (N, g) values.  This alert is
-      always fatal.  See Section 2.5.3 for details.
-
-   o  "illegal_parameter" (47) - this alert MUST be sent by a client or
-      server that receives a key exchange message with A % N = 0 or B %
-      N = 0.  This alert is always fatal.  See Section 2.5.3 and
-      Section 2.5.4 and for details.
-
-   The "insufficient_security" and "illegal_parameter" alerts are
-   defined in [TLS].  The "unknown_psk_identity" alert is defined in
-   [PSK].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 11]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-3.  Security Considerations
-
-3.1.  General Considerations for Implementors
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are CRUCIAL for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256 bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.  See [TLS] section D.1 for advice on
-   choosing cryptographically secure random numbers.
-
-3.2.  Accepting Group Parameters
-
-   An attacker who could calculate discrete logarithms % N could
-   compromise user passwords, and could also compromise the the
-   confidentiality and integrity of TLS sessions.  Clients MUST ensure
-   that the received parameter N is large enough to make calculating
-   discrete logarithms computationally infeasible.
-
-   An attacker may try to send a prime value N which is large enough to
-   be secure, but which has a special form for which the attacker can
-   more easily compute discrete logarithms (e.g., using the algorithm
-   discussed in [TRAPDOOR]).  If the client executes the protocol using
-   such a prime, the client's password could be compromised.  Because of
-   the difficulty of checking for such primes in real-time, clients
-   SHOULD only accept group parameters that come from a trusted source,
-   such as those listed in Appendix A, or parameters configured locally
-   by a trusted administrator.
-
-3.3.  Protocol Characteristics
-
-   If an attacker learns a user's SRP verifier (e.g., by gaining access
-   to a server's password file), the attacker can masquerade as the real
-   server to that user, and can also attempt a dictionary attack to
-   recover that user's password.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address, or against a particular user name.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 12]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-   If the client receives an "unknown_psk_identity" alert in response to
-   a client hello, this alert may have been inserted by an attacker.
-   The client should be careful about making any decisions, or forming
-   any conclusions, based on receiving this alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-3.4.  Hash Function Considerations
-
-   This protocol uses SHA-1 to derive several values:
-
-   o  u prevents an attacker who learns a user's verifier from being
-      able to authenticate as that user (see [SRP-6]).
-
-   o  k prevents an attacker who can select group parameters from being
-      able to launch a 2-for-1 guessing attack (see [SRP-6]).
-
-   o  x contains the user's password mixed with a salt.
-
-   Cryptanalytic attacks against SHA-1 which only affect its collision-
-   resistance do not compromise these uses.  If attacks against SHA-1
-   are discovered which do compromise these uses, new ciphersuites
-   should be specified to use a different hash algorithm.
-
-   In this situation, clients could send a Client Hello message
-   containing new and/or old SRP ciphersuites along with a single SRP
-   extension.  The server could then select the appropriate ciphersuite
-   based on the type of verifier it has stored for this user.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 13]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-4.  IANA Considerations
-
-   This document defines a new TLS extension "srp" (value TBD1), whose
-   value is to be assigned from the TLS ExtensionType Registry defined
-   in [TLSEXT].
-
-   This document defines nine new ciphersuites, whose values are to be
-   assigned from the TLS Cipher Suite registry defined in [TLS].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD2 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD3
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0xTBD4
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD5 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD6
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0xTBD7
-      };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD8 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD9
-      };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0xTBD10
-      };
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 14]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-5.  References
-
-5.1.  Normative References
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol version
-              1.1", RFC 4346, April 2006.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [STRINGPREP]
-              Hoffman, P. and M. Blanchet, "Preparation of
-              Internationalized Strings ("stringprep")", RFC 3454,
-              December 2002.
-
-   [SASLPREP]
-              Zeilenga, K., "SASLprep: Stringprep profile for user names
-              and passwords", RFC 4013, February 2005.
-
-   [SRP-RFC]  Wu, T., "The SRP Authentication and Key Exchange System",
-              RFC 2945, September 2000.
-
-   [SHA1]     "Secure Hash Standard (SHS)", FIPS 180-2, August 2002.
-
-   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [AESCIPH]  Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)",
-              RFC 3268, June 2002.
-
-   [PSK]      Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponentiation
-              (MODP) Diffie-Hellman groups for Internet Key Exchange
-              (IKE)", RFC 3526, May 2003.
-
-5.2.  Informative References
-
-   [IMAP]     Newman, C., "Using TLS with IMAP, POP3 and ACAP",
-              RFC 2595, June 1999.
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 15]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-   [SRP-6]    Wu, T., "SRP-6: Improvements and Refinements to the Secure
-              Remote Password Protocol", Submission to IEEE P1363.2
-              working group, October 2002,
-              <http://grouper.ieee.org/groups/1363/>.
-
-   [SRP]      Wu, T., "The Secure Remote Password Protocol", Proceedings
-              of the 1998 Internet Society Network and Distributed
-              System Security Symposium pp. 97-111, March 1998.
-
-   [TRAPDOOR]
-              Gordon, D., "Designing and Detecting Trapdoors for
-              Discrete Log Cryptosystems", Springer-Verlag Advances in
-              Cryptology - Crypto '92, pp. 66-75, 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 16]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024, 1536, and 2048-bit groups are taken from software developed
-   by Tom Wu and Eugene Jhong for the Stanford SRP distribution, and
-   subsequently proven to be prime.  The larger primes are taken from
-   [MODP], but generators have been calculated that are primitive roots
-   of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-
-       The generator is: 2.
-
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-
-       The generator is: 2.
-
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 17]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-
-       The generator is: 2.
-
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 18]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 19]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-
-       The generator is: 5.
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 20]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 21]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-Appendix B.  SRP Test Vectors
-
-   The following test vectors demonstrate calculation of the verifier
-   and premaster secret.
-
-      I = "alice"
-
-      P = "password123"
-
-      s = BEB25379 D1A8581E B5A72767 3A2441EE
-
-      N, g = <1024-bit parameters from Appendix A>
-
-      k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
-
-      x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
-
-      v =
-
-         7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
-         9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
-         C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
-         EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
-         E955A5E2 9E7AB245 DB2BE315 E2099AFB
-
-      a =
-
-         60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
-         DA2D4393
-
-      b =
-
-         E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
-         05284D20
-
-      A =
-
-         61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
-         4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
-         8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
-         BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
-         B349EF5D 76988A36 72FAC47B 0769447B
-
-      B =
-
-         BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
-         BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
-         6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 22]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-         37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
-         EB4012B7 D7665238 A8E3FB00 4B117B58
-
-      u =
-
-         CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
-
-      <premaster secret> =
-
-         B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
-         233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
-         41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
-         3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
-         C346D7E4 74B29EDE 8A469FFE CA686E5A
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 23]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-Appendix C.  Acknowledgements
-
-   Thanks to all on the IETF TLS mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 24]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-Authors' Addresses
-
-   David Taylor
-   Independent
-
-   Email: dtaylor@gnutls.org
-
-
-   Tom Wu
-   Stanford University
-
-   Email: tjw@cs.stanford.edu
-
-
-   Nikos Mavrogiannopoulos
-   Independent
-
-   Email: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-   Independent
-
-   Email: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 25]
-
-Internet-Draft      Using SRP for TLS Authentication           June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Taylor, et al.          Expires December 15, 2007              [Page 26]
-
-
diff --git a/doc/protocol/draft-ietf-tls-ssl-mods-00.txt b/doc/protocol/draft-ietf-tls-ssl-mods-00.txt
deleted file mode 100644
index 1a068269ee..0000000000
--- a/doc/protocol/draft-ietf-tls-ssl-mods-00.txt
+++ /dev/null
@@ -1,224 +0,0 @@
-Transport Layer Security Working Group                      Tim Dierks
-INTERNET-DRAFT                                   Consensus Development
-Expires May 31, 1997                                 November 26, 1996
-
-
-            Modifications to the SSL protocol for TLS
-                 <draft-ietf-tls-ssl-mods-00.txt>
-
-
-
-Status of this memo
-
-This document is an Internet-Draft. Internet-Drafts are working
-documents of the Internet Engineering Task Force (IETF), its areas, and
-its working groups. Note that other groups may also distribute working
-documents as Internet- Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or made obsolete 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.
-
-To learn the current status of any Internet-Draft, please check the
-1id-abstracts.txt listing contained in the Internet Drafts Shadow
-Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
-ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
-
-
-Abstract
-
-This document recommends for several modifications be made to the SSL
-3.0 protocol as it is standardized by the IETF under the name of TLS.
-These changes primarily standardize various technical details of the
-protocol and make some other minor modifications.
-
-1. MAC algorithm
-
-SSL 3.0 uses a version of the HMAC algorithm which is not the most
-recent or the recommended standard. The SSL MAC is defined as:
-
-    hash(MAC_secret + pad_2 +
-         hash(MAC_secret + pad_1 + data));
-
-Where data is the concatenation of several record header fields and the
-record data. pad_1 and pad_2 are repetitions of the value 0x36 and 0x5C,
-respectively. These bytes are repeated a number of times dependent on
-which hash algorithm is being used: 48 times for MD5 and 40 times for
-SHA.
-
-I recommend moving to HMAC as described in
-<draft-ietf-ipsec-hmac-md5-01.txt> by incorporating this algorithm into
-the TLS standard (or by referring to it, should it become an RFC
-standard). This formulation uses a 64 byte pad which is combined with
-the MAC secret using XOR rather than concatenation.
-
-Dierks, T.                     Expires May, 1997               [Page 1]
-INTERNET-DRAFT                   SSL-TLS mods             November 1996
-
-This would replace the MAC formulations used in the certificate verify
-and finished messages (where the MAC_secret is the master secret) and
-the MAC formulation used in the record layer (where the MAC_secret is
-generated specifically for each connection direction.)
-
-2. MAC contents
-
-Currently, the SSL record layer applies the MAC to every element in the
-record except for the protocol version encoded into every packet. It is
-inappropriate to transmit values which might affect the functionality of
-the connection without applying the MAC to these values. If the version
-number does not control the function of the channel, it should be
-eliminated; if it does affect the communication, it should be MACed.
-Thus, I recommend that the data which is MAC`d be amended to:
-
-    seq_num + SSLCompressed.type + SSLCompressed.version +
-        SSLCompressed.length + SSLCompressed.fragment
-
-3. Block padding
-
-Padding is required when working with block ciphers to expand source
-data to an even multiple of the block length. SSL specifies padding, but
-does not specify a particular value. In order to ensure that
-implementors do not accidentally transmit unintended data in
-uninitialized padding fields, I recommend that the TLS add a requirement
-that the padding be initialized to a particular value. I propose that
-the padding field must be zeroed and that implementations should check
-for appropriate padding on incoming records.
-
-4. Message order standardization
-
-In the original SSL 3.0 specification, an error made the statement of
-when the certificate request message should be transmitted unclear, and
-different implementations send it in two places: either before or after
-the server key exchange message. I propose that for the TLS
-specification, the certificate request message be clearly specified to
-follow the server key exchange message.
-
-5. Certificate chain contents
-
-In the original SSL 3.0 specification, the text required that a complete
-X.509 certificate chain be sent up to and including the self-signed root
-cert. It is claimed that this was not the intent of the drafters, and in
-fact, many implementations do not comply with this portion of the
-standard. Thus, I propose that the TLS specification clearly state that
-a partial certificate chain is acceptable if it can be reasonably hoped
-that the peer will hold all needed certificates to complete the chain.
-
-
-
-
-
-
-Dierks, T.                     Expires May, 1997               [Page 2]
-INTERNET-DRAFT                   SSL-TLS mods             November 1996
-
-6. The no_certificate alert
-
-The no_certificate alert, which is to be sent by a client which does not
-have a suitable certificate to provide a server, presents a subtle
-problem to the SSL implementer. Because the message order of the SSL
-protocol is for the most part well defined and enforced, what messages
-have arrived is very important to the state machine which manages the
-handshake protocol. Because this alert can replace a handshake message,
-the alert protocol must communicate to the handshake protocol that this
-alert has arrived. This is the only place where such a piece of
-promiscuity is required, thus I recommend that in place of sending a
-no_certificate alert, TLS clients who do not have a suitable certificate
-for a server submit instead an Certificate message which contains no
-certificates.
-
-7. Additional alerts
-
-SSL doesn`t have a great deal of variety in its error alerts. I propose
-that the following alerts be added to the specification:
-
-    internal_error [fatal]: an internal error unrelated to the peer or
-the correctness of the protocol makes it impossible to continue (such as
-a memory allocation failure).
-    user_canceled [fatal]: the user aborted this handshake or connection
-for some reason.
-    decrypt_error [fatal]: a public or private key operation failed due
-to using the wrong key
-    decode_error [fatal]: a message could not be decoded because some
-field was out of the specified range or the length of the message was
-incorrect.
-    export_restriction [fatal]: an attempt to circumvent export
-restrictions was detected; for example, attemption to transfer a 1024
-bit ephemeral RSA key for the RSA_EXPORT handshake method.
-    protocol_version [fatal]: the protocol version the peer has
-attempted to negotiate is recognized, but not supported. (For example,
-old protocol versions might be avoided for security reasons).
-    record_overflow [fatal]: an SSLCiphertext record was received which
-had a length more than 2^14+2048 bytes, or a record decrypted to a
-SSLCompressed record with more than 2^14+1024 bytes.
-    decryption_failed [fatal]: a SSLCiphertext decrypted in an invalid
-way: either it wasn`t an even multiple of the block length or its
-padding values, when checked, weren`t correct.
-    access_denied [fatal]: a valid certificate was received, but it did
-not pass the access control mechanism.
-    unknown_ca [fatal]: a valid certificate chain or partial chain was
-received, but the certificate was not accepted because the CA
-certificate could not be located or couldn`t be matched with a known,
-trusted CA.
-    insufficient_security [fatal]: returned instead of handshake_failure
-when a negotiation has failed specifically because one of the parties
-requires ciphers more secure than those supported by their peer.
-    no_renegotiation [warning]: generated in response to a hello request
-
-Dierks, T.                     Expires May, 1997               [Page 3]
-INTERNET-DRAFT                   SSL-TLS mods             November 1996
-
-or a client hello sent on an already negotiated channel. This informs
-the requestor that no response will be generated, as this entity does
-not want to renegotiate security parameters (as you might wish to do if
-there` no way to communicate security parameters up the stack to the
-client after initial negotiation.
-
-8. Seperation of Record and Handshake layers
-
-The SSL Record Protocol and Handshake Protocol can be viewed as two
-independant layered protocols: the Record Protocol provides encrypted,
-reliable transport, and the Handshake Protocol provides algorithm and
-key negotiation and peer authentication. I propose that they be formally
-seperated into two documents, or at least two distinct sections of the
-TLS document. This should make their interoperation clearer, aiding
-security analysis and perhaps allowing utilization of the Record
-Protocol with some other handshake protocol or vice-versa.
-
-9. Additional Record Protocol clients
-
-The SSL Record Protocol supports transmitting many different kinds of
-records over a single connection. This is already used for
-distinguishing different kinds of protocol messages from each other and
-from application data. I propose that TLS clearly specify that layered
-protocols are allowed to use the Record Protocol to transport new record
-types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks, T.                     Expires May, 1997               [Page 4]
diff --git a/doc/protocol/draft-ietf-tls-suiteb-00.txt b/doc/protocol/draft-ietf-tls-suiteb-00.txt
deleted file mode 100644
index 1933175549..0000000000
--- a/doc/protocol/draft-ietf-tls-suiteb-00.txt
+++ /dev/null
@@ -1,447 +0,0 @@
-
-Network Working Group                                          M. Salter
-Internet-Draft                                  National Security Agency
-Intended status:  Informational                              E. Rescorla
-Expires:  October 25, 2007                             Network Resonance
-                                                          April 23, 2007
-
-
-                     Suite B Cipher Suites for TLS
-                      draft-ietf-tls-suiteb-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 25, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   The United States Government has published guidelines for "NSA Suite
-   B Cryptography" dated July, 2005, which defines cryptographic
-   algorithm polcy for national security applications.  This document
-   defines a profile of TLS which is conformant with Suite B.
-
-
-
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 1]
-
-Internet-Draft               Suite B for TLS                  April 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Suite B Requirements  . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Suite B Compliance Requirements . . . . . . . . . . . . . . . . 4
-     4.1.  Security Levels . . . . . . . . . . . . . . . . . . . . . . 4
-     4.2.  Acceptable Curves . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 2]
-
-Internet-Draft               Suite B for TLS                  April 2007
-
-
-1.  Introduction
-
-   In July, 2005 the National Security Agency posted "Fact Sheet, NSA
-   Suite B Cryptography" which stated:
-
-       To complement the existing policy for the use of the Advanced
-       Encryption Standard (AES) to protect national security systems
-       and information as specified in The National Policy on the use of
-       the Advanced Encryption Standard (AES) to Protect National
-       Security Systems and National Security Information (CNSSP-15),
-       the National Security Agency (NSA) announced Suite B Cryptography
-       at the 2005 RSA Conference.  In addition to the AES, Suite B
-       includes cryptographic algorithms for hashing, digital
-       signatures, and key exchange.
-
-       Suite B only specifies the cryptographic algorithms to be
-       used. Many other factors need to be addressed in determining
-       whether a particular device implementing a particular set of
-       cryptographic algorithms should be used to satisfy a particular
-       requirement.
-
-   Among those factors are "requirements for interoperability both
-   domestically and internationally".
-
-   This document is a profile of of TLS 1.2 [I-D.ietf-tls-rfc4346-bis]
-   and of the cipher suites defined in [I-D.ietf-tls-ecc-new-mac], but
-   does not itself define any new cipher suites.  This profile requires
-   TLS 1.2.
-
-
-2.  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 [RFC2119].
-
-
-3.  Suite B Requirements
-
-   The "Suite B Fact Sheet" requires that key establishment and
-   authentication algorithms be based on Elliptic Curve Cryptography,
-   that the encryption algorithm be AES [AES], and that the function
-   used for key derivation and data integrity be SHA [SHS].  It defines
-   two security levels, of 128 and 192 bits.
-
-   In particular it states:
-
-
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 3]
-
-Internet-Draft               Suite B for TLS                  April 2007
-
-
-      SUITE B includes:
-
-       Encryption:          Advanced Encryption Standard (AES)  -
-                            FIPS 197 (with keys sizes of 128 and 256
-                            bits)
-
-       Digital Signature:   Elliptic Curve Digital Signature Algorithm -
-                            FIPS 186-2 (using the curves with 256 and
-                            384-bit prime moduli)
-
-       Key Exchange:        Elliptic Curve Diffie-Hellman or Elliptic
-                            Curve MQV Draft NIST Special Publication
-                            800-56 (using the curves with 256 and
-                            384-bit prime moduli)
-
-       Hashing:             Secure Hash Algorithm - FIPS 180-2
-                            (using SHA-256 and SHA-384)
-
-      All implementations of Suite B must, at a minimum, include AES
-      with 128-bit keys, the 256-bit prime modulus elliptic curve and
-      SHA-256 as a common mode for widespread interoperability.
-
-   The 128-bit security level corresponds to an elliptic curve size of
-   256 bits, AES-128, and SHA-256.  The 192-bit security level
-   corresponds to an elliptic curve size of 384 bits, AES-256, and SHA-
-   384.
-
-
-4.  Suite B Compliance Requirements
-
-   To be considered "Suite B compatible" at least one of the Galois
-   Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac]
-   MUST be negotiated.  In compliance with the guidance in the Suite B
-   Fact Sheet every TLS implementation of Suite B SHOULD implement
-   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
-
-4.1.  Security Levels
-
-   As described in Section 1, Suite B specifies two security levels, 128
-   and 192 bit.  The following table lists the security levels for each
-   cipher suite:
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 4]
-
-Internet-Draft               Suite B for TLS                  April 2007
-
-
-       +-----------------------------------------+----------------+
-       | Cipher Suite                            | Security Level |
-       +-----------------------------------------+----------------+
-       | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128            |
-       | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256  | 128            |
-       | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192            |
-       | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384  | 192            |
-       +-----------------------------------------+----------------+
-
-4.2.  Acceptable Curves
-
-   RFC 4492 defines a variety of elliptic curves.  For cipher suites
-   defined in this specification, only secp256r1 (23) or secp384r1 (24)
-   may be used.  (These are the same curves that appear in FIPS 186-2 as
-   P-256 and P-384, respectively.)  For cipher suites at the 128-bit
-   security level, secp256r1 MUST be used.  For cipher suites at the
-   192-bit security level, secp384r1 MUST be used.  RFC 4492 requires
-   that uncompressed (0) form be supported. ansiX962_compressed_prime(1)
-   point formats MAY be supported.
-
-   Clients desiring to negotiate only a Suite B-compliant connection
-   MUST generate a "Supported Elliptic Curves Extension" containing only
-   the allowed curves.  These curves MUST match the cipher suite
-   security levels being offered.  Clients which are willing to do both
-   Suite B-compliant and non-Suite B-compliant connections MAY omit the
-   extension or send the extension but offer other curves as well as the
-   appropriate Suite B ones.
-
-   Servers desiring to negotiate a Suite B-compliant connection SHOULD
-   check for the presence of the extension, but MUST NOT negotiate
-   inappropriate curves even if they are offered by the client.  This
-   allows a Client which is willing to do either Suite B-compliant or
-   non-Suite B-compliant modes to interoperate with a server which will
-   only do Suite B-compliant modes.  If the client does not advertise an
-   acceptable curve, the server MUST generate a fatal
-   "handshake_failure" alert and terminate the connection.  Clients MUST
-   check the chosen curve to make sure it is acceptable.
-
-
-5.  Security Considerations
-
-   Most of the security considerations for this document are described
-   in TLS 1.2 [I-D.ietf-tls-rfc4346-bis], RFC 4492 [RFC4492], and
-   [I-D.ietf-tls-ecc-new-mac].  Readers should consult those documents.
-
-   In order to meet the goal of a consistent security level for the
-   entire cipher suite, in Suite B mode TLS implementations MUST ONLY
-   use the curves defined in Section 4.2.  Otherwise, it is possible to
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 5]
-
-Internet-Draft               Suite B for TLS                  April 2007
-
-
-   have a set of symmetric algorithms with much weaker or stronger
-   security properties than the asymmetric (ECC) algorithms.
-
-
-6.  IANA Considerations
-
-   This document defines no actions for IANA.
-
-
-7.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
-              March 2007.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [I-D.ietf-tls-ecc-new-mac]
-              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-              256/384 and AES Galois Counter Mode", April 2007.
-
-8.2.  Informative References
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 6]
-
-Internet-Draft               Suite B for TLS                  April 2007
-
-
-Authors' Addresses
-
-   Margaret Salter
-   National Security Agency
-   9800 Savage Rd.
-   Fort Meade  20755-6709
-   USA
-
-   Email:  msalter@restarea.ncsc.mil
-
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 7]
-
-Internet-Draft               Suite B for TLS                  April 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Salter & Rescorla       Expires October 25, 2007                [Page 8]
-
-
diff --git a/doc/protocol/draft-keromytis-tls-authz-keynote-00.txt b/doc/protocol/draft-keromytis-tls-authz-keynote-00.txt
deleted file mode 100644
index 14479ad944..0000000000
--- a/doc/protocol/draft-keromytis-tls-authz-keynote-00.txt
+++ /dev/null
@@ -1,210 +0,0 @@
-Internet-Draft                                           A. D. Keromytis
-March 2008                                           Columbia University
-Expires: October 2008
-Creation Date: 2008-03-28
-Intended Status: Proposed
-
-
-        Transport Layer Security (TLS) Authorization Using KeyNote
-                 <draft-keromytis-tls-authz-keynote-00.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 IETF Trust (2008).
-
-Abstract
-
-   This document specifies the use of the KeyNote trust-management
-   system as an authorization extension in the Transport Layer
-   Security (TLS) Handshake Protocol, according to [AUTHZ].
-   Extensions carried in the client and server hello messages
-   confirm that both parties support the desired authorization
-   data types. Then, if supported by both the client and the
-   server, KeyNote credentials are exchanged during the
-   supplemental data handshake message.
-
-
-1. Introduction
-
-   This document describes the identifiers necessary to exchange
-   KeyNote [KEYNOTE] credential assertions inside a TLS [TLS1.0]
-   [TLS1.1] exchange.  Such credential assertions can authorize
-   the client and/or the server to perform certain actions. In
-   most usage scenarios, the KeyNote credential assertions will
-   be signed by a cryptographic public key [RFC2792].  By using the
-   X.509 key and signature encoding [X509KEY], it is possible to 
-   add KeyNote-based authorization and policy compliance support to
-   the existing, unmodified X.509 authentication exchange in TLS.
-
-   A list of KeyNote credentials (e.g., forming a delegation chain)
-   may be sent as part of the same payload.
-
-   In most scenarios, at least one of these credentials will be
-   issued to the public key of the transmitter of the credentials,
-   i.e., said public key will appear in the ``Licensees'' field of
-   at least one KeyNote credential assertion.  The same public key
-   will generally be used by the transmitter of the same credentials
-   to authenticate as part of the TLS exchange.  The
-   authentication material (e.g., cryptographic public key) that was
-   used by the transmitter to authenticate in the TLS exchange will
-   be provided to the KeyNote evaluation engine as an ``Action
-   Authorizer''.
-
-
-2. KeyNote Credential Assertion Lists
-
-  The KeyNote Assertion List type definition in the TLS Authorization
-  Data Formats registry is:
-
-      keynote_assertion_list(TBA)
-
-   When the keynote_assertion_list value is present, the authorization
-   data is a list of KeyNote credential assertions that conforms to
-   the profile in RFC 2704 [KEYNOTE].
-
-   A KeyNote assertion list is transmitted inside an AuthorizationData
-   structure as an opaque sequence of 1 - 2^16-1 bytes:
-
-      opaque KeyNoteAssertionList<1..2^16-1>;
-
-   When KeyNoteAssertion List is used, the field contains an ASCII-
-   encoded list of signed KeyNote assertions, as described in RFC 2704
-   [KEYNOTE].  The assertions are separated by two '\n' (newline)
-   characters.  A KeyNote assertion is a structure similar to a public
-   key certificate; the main difference is that instead of a binding
-   between a name and a public key, KeyNote assertions bind public keys
-   to authorization rules that are evaluated by the peer when the sender
-   later issues specific requests.
-
-   When making an authorization decision based on a list of KeyNote
-   assertions, proper linkage between the KeyNote assertions and the
-   public key certificate that is transferred in the TLS Certificate
-   message is needed.  Receivers of a KeyNote assertion list should
-   initialize the ACTION_AUTHORIZER variable to be the sender's public
-   key, which was used to authenticate the TLS exchange.  If a
-   different authentication mechanism is used, it is the responsibility
-   of the credential issuer to issue the appropriate credentials.
-
-
-3. IANA Considerations
-
-   This document requires a new entry in the IANA-maintained TLS 
-   Authorization Data Formats registry, keynote_assertion_list(TBD).
-   This registry is defined in [AUTHZ].
-
-
-4. Security Considerations
-
-   There are no security considerations beyond those discussed in
-   [KEYNOTE], [RFC2792], and [AUTHZ].
-
-
-5. Normative References
-
-   [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
-                an IANA Considerations Section in RFCs", RFC 3434,
-                October 1998.
-
-   [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version
-                1.0", RFC 2246, January 1999.
-
-   [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer
-                Security (TLS) Protocol, Version 1.1", RFC 4346,
-                February 2006.
-
-
-6. Informative References
-
-   [KEYNOTE]    Blaze, M., Feigenbaum, J., Ioannidis, J., and
-                A. Keromytis, "The KeyNote Trust-Management System,
-                Version 2", RFC 2704, September 1999.
-
-   [RFC2792]    Blaze, M., Ioannidis, J., and A. Keromytis, "DSA and RSA
-                Key and Signature Encoding for the KeyNote Trust
-                Management System", RFC 2792, March 2000.
-
-   [AUTHZ]      Brown, M., and R. Housley, "Transport Layer Security
-                (TLS) Authorization Extensions", June 2006
-                <draft-housley-tls-authz-extns-07.txt>
-
-   [X509KEY]    A. D. Keromytis, "X.509 Key and Signature Encoding for
-                the KeyNote Trust Management System", March 2008
-                <draft-keromytis-keynote-x509-00.txt>
-
-
-Author's Address
-
-   Angelos D. Keromytis
-   Department of Computer Science
-   Columbia University
-   Mail Code 0401
-   1214 Amsterdam Avenue
-   New York, New York 1007
-   USA
-   angelos <at> cs <dot> columbia <dot> edu
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
diff --git a/doc/protocol/draft-lee-tls-seed-01.txt b/doc/protocol/draft-lee-tls-seed-01.txt
deleted file mode 100644
index 6bdb176d82..0000000000
--- a/doc/protocol/draft-lee-tls-seed-01.txt
+++ /dev/null
@@ -1,360 +0,0 @@
-
-
-
-
-
-TLS Working Group                               Hyangjin Lee(KISA)
-INTERNET-DRAFT                                    Jaeho Yoon(KISA)
-Document: draft-lee-tls-seed-01.txt                Jaeil Lee(KISA)
-Expiration Date: July 2005                           January 2005
-
-
-    Addition of SEED Ciphersuites to Transport Layer Security (TLS)
-
-                      <draft-lee-tls-seed-01.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, I certify that any applicable
-   patent or other IPR claims of which I am aware have been disclosed,
-   or will be disclosed, and any of which I become aware will be
-   disclosed, in accordance with RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-Abstract
-
-   This document proposes the addition of new cipher suites to the
-   Transport Layer Security (TLS) protocol to support the SEED
-   encryption algorithm as a bulk cipher algorithm.
-
-1. Introduction
-
-   This document proposes the addition of new cipher suites to the TLS
-   protocol [TLS] to support the SEED encryption algorithm as a bulk
-   cipher algorithm.
-
-
-
-
-
-
-Lee, et. al.               Expires - July 2005          	[Page 1]
-
-
-
-
-
-INTERNET-DRAFT          SEED Ciphersuites to TLS            January 2005
-
-
-1.1. SEED
-
-   SEED is a symmetric encryption algorithm that had been developed by
-   KISA(Korea Information Security Agency) and a group of experts since
-   1998. The input/output block size of SEED is 128-bit and the key
-   length is also 128-bit. SEED has the 16-round Feistel structure.  A
-   128-bit input is divided into two 64-bit blocks and the right 64-bit
-   block is an input to the round function with a 64-bit subkey
-   generated from the key scheduling.
-
-   SEED is easily implemented in various software and hardware because
-   it is designed to increase the efficiency of memory storage and the
-   simplicity in generating keys without degrading the security of the
-   algorithm. In particular, it can be effectively adopted to a
-   computing environment with a restricted resources such as a mobile
-   devices, smart cards and so on.
-
-   SEED is a national industrial association standard [TTASSEED] and is
-   widely used in South Korea for electronic commerce and financial
-   services operated on wired & wireless PKI.
-
-   The algorithm specification and object identifiers are described in
-   [SEED-ID]. The SEED homepage,
-   http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of
-   information about SEED, including detailed specification, evaluation
-   report, test vectors, and so on.
-
-1.2.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
-   as shown) are to be interpreted as described in [RFC2119].
-
-2. Proposed Cipher Suites
-
-   The new ciphersuites proposed here have the following definitions:
-
-      CipherSuite TLS_RSA_WITH_SEED_CBC_SHA      = { 0x00, 0x96};
-      CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA   = { 0x00, 0x97};
-      CipherSuite TLS_DH_RSA_WITH_SEED_CBC_SHA   = { 0x00, 0x98};
-      CipherSuite TLS_DHE_DSS_WITH_SEED_CBC_SHA  = { 0x00, 0x99};
-      CipherSuite TLS_DHE_RSA_WITH_SEED_CBC_SHA  = { 0x00, 0x9A};
-      CipherSuite TLS_DH_anon_WITH_SEED_CBC_SHA  = { 0x00, 0x9B};
-
-3. CipherSuite Definitions
-
-
-
-
-
-
-Lee, et. al.               Expires - July 2005          	[Page 2]
-
-
-
-
-
-INTERNET-DRAFT          SEED Ciphersuites to TLS            January 2005
-
-
-3.1. Cipher
-
-   All the ciphersuites described here use SEED in cipher block
-   chaining(CBC) mode as a bulk cipher algorithm.  SEED is a 128-bit
-   block cipher with 128-bit key size.
-
-3.2. Hash
-
-   All the ciphersuites described here use SHA-1 [SHA-1] in an HMAC
-   construction as described in section 5 of [TLS].
-
-3.3. Key exchange
-
-   The ciphersuites defined here differ in the type of certificate and
-   key exchange method.  They use the following options:
-
-      CipherSuite                         Key Exchange Algorithm
-
-      TLS_RSA_WITH_SEED_CBC_SHA                    RSA
-      TLS_DH_DSS_WITH_SEED_CBC_SHA                 DH_DSS
-      TLS_DH_RSA_WITH_SEED_CBC_SHA                 DH_RSA
-      TLS_DHE_DSS_WITH_SEED_CBC_SHA                DHE_DSS
-      TLS_DHE_RSA_WITH_SEED_CBC_SHA                DHE_RSA
-      TLS_DH_anon_WITH_SEED_CBC_SHA                DH_anon
-
-   For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA
-   and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS].
-
-4.  IANA considerations
-
-   IANA does not currently have a registry for TLS-related numbers, so
-   there are no IANA actions associated with this document.
-
-5. Security Considerations
-
-   It is not believed that the new ciphersuites are ever less secure
-   than the corresponding older ones. No security problem has been found
-   on SEED. SEED is robust against known attacks including Differential
-   cryptanalysis, Linear cryptanalysis and related key attacks, etc.
-   SEED has gone through wide public scrutinizing procedures.
-   Especially, it has been evaluated and also considered
-   cryptographically secure by trustworthy organizations such as ISO/IEC
-   JTC 1/SC 27 and Japan CRYPTREC (Cryptography Research and Evaluation
-   Committees) [ISOSEED][CRYPTREC]. SEED has been submitted to other
-   several standardization bodies such as ISO(ISO/IEC 18033-3), IETF
-   S/MIME Mail Security [SEED-SMIME] and it is under consideration.  For
-   further security considerations, the reader is encouraged to read
-   [SEED-EVAL].
-
-
-
-Lee, et. al.               Expires - July 2005          	[Page 3]
-
-
-
-
-
-INTERNET-DRAFT          SEED Ciphersuites to TLS            January 2005
-
-
-   For other security considerations, please refer to the security of
-   the corresponding older ciphersuites described in [TLS] and [AES-
-   TLS].
-
-6. References
-
-6.1 Normative Reference
-
-   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [SEED]      KISA, "SEED Algorithm Specification",
-               http://www.kisa.or.kr/seed/seed_eng.html"
-
-   [TLS]       T. Dierks, and C. Allen, "The TLS Protocol Version 1.0",
-            RFC 2246, January 1999.
-
-6.2 Informative Reference
-
-   [AES-TLS]   P. Chown, "Advanced Encryption Standard (AES)
-               Ciphersuites for Transport Layer Security (TLS)",
-               RFC 3268, June 2002.
-
-   [CRYPTREC]  Information-technology Promotion Agency (IPA), Japan,
-               CRYPTREC. "SEED Evaluation Report", February, 2002
-               http://www.kisa.or.kr/seed/seed_eng.html
-
-   [ISOSEED]   ISO/IEC JTC 1/SC 27, "National Body contributions on
-               NP 18033 "Encryption Algorithms" in Response to SC 27
-               N2563 (ATT.3 Korea Contribution)", ISO/IEC JTC 1/SC 27
-               N2656r1 (n2656_3.zip), October, 2000
-
-   [SEED-EVAL] KISA, "Self Evaluation Report",
-               http://www.kisa.or.kr/seed/seed_eng.html"
-
-   [SEED-ID]   Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,
-               "The SEED Encryption Algorithm", draft-park-seed-01.txt,
-               April, 2004.
-
-   [SEED-SMIME] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee,
-               "Use of the SEED Encryption Algorithm in CMS",
-               draft-ietf-smime-cms-01.txt, April, 2004.
-
-   [SHA-1]     FIPS PUB 180-1, "Secure Hash Standard", National Institute
-               of Standards and Technology, U.S. Department of Commerce,
-               April 17, 1995.
-
-   [TTASSEED]  Telecommunications Technology Association (TTA),
-
-
-
-Lee, et. al.               Expires - July 2005          	[Page 4]
-
-
-
-
-
-INTERNET-DRAFT          SEED Ciphersuites to TLS            January 2005
-
-
-               South Korea, "128-bit Symmetric Block Cipher (SEED)",
-               TTAS.KO-12.0004, September, 1998 (In Korean)
-               http://www.tta.or.kr/English/new/main/index.htm
-
-7. Authorsí¯ Addresses
-
-     Hyangjin Lee
-     Korea Information Security Agency
-     Phone: +82-2-405-5446
-     FAX  : +82-2-405-5499
-     Email: jiinii@kisa.or.kr
-
-     Jaeho Yoon
-     Korea Information Security Agency
-     Phone: +82-2-405-5434
-     FAX  : +82-2-405-5499
-     Email: jhyoon@kisa.or.kr
-
-     Jaeil Lee
-     Korea Information Security Agency
-     Phone: +82-2-405-5300
-     FAX  : +82-2-405-5499
-     Email: jilee@kisa.or.kr
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed
-   to pertain to the implementation or use of the technology described
-   in this document or the extent to which any license under such
-   rights might or might not be available; nor does it represent that
-   it has made any independent effort to identify any such rights.
-   Information on the IETFí¯s procedures with respect to rights in IETF
-   Documents can be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use
-   of such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository
-   at http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-Lee, et. al.               Expires - July 2005          	[Page 5]
-
-
-
-
-
-INTERNET-DRAFT          SEED Ciphersuites to TLS            January 2005
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lee, et. al.               Expires - July 2005          	[Page 6]
-
-
-
diff --git a/doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt b/doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt
deleted file mode 100644
index 8a4d32e67d..0000000000
--- a/doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-Network Working Group                               N. Mavrogiannopoulos
-Internet-Draft                                               Independent
-Updates: rfc5081                                            January 2008
-(if approved)
-Intended status: Informational
-Expires: July 4, 2008
-
-
-  Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
-                 draft-mavrogiannopoulos-rfc5081bis-00
-
-Status of This Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 4, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   This memo proposes extensions to the Transport Layer Security (TLS)
-   protocol to support the OpenPGP key format.  The extensions discussed
-   here include a certificate type negotiation mechanism, and the
-   required modifications to the TLS Handshake Protocol.
-
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 1]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   3.  Changes to the Handshake Message Contents . . . . . . . . . . . 3
-     3.1.  Client Hello  . . . . . . . . . . . . . . . . . . . . . . . 3
-     3.2.  Server Hello  . . . . . . . . . . . . . . . . . . . . . . . 4
-     3.3.  Server Certificate  . . . . . . . . . . . . . . . . . . . . 4
-     3.4.  Certificate Request . . . . . . . . . . . . . . . . . . . . 6
-     3.5.  Client Certificate  . . . . . . . . . . . . . . . . . . . . 6
-     3.6.  Other Handshake Messages  . . . . . . . . . . . . . . . . . 6
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 2]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-1.  Introduction
-
-   The IETF has two sets of standards for public key certificates, one
-   set for use of X.509 certificates [PKIX] and one for OpenPGP
-   certificates [OpenPGP].  At the time of writing, TLS [TLS] standards
-   are defined to use only X.509 certificates.  This document specifies
-   a way to negotiate use of OpenPGP certificates for a TLS session, and
-   specifies how to transport OpenPGP certificates via TLS.  The
-   proposed extensions are backward compatible with the current TLS
-   specification, so that existing client and server implementations
-   that make use of X.509 certificates are not affected.
-
-2.  Terminology
-
-   The term "OpenPGP key" is used in this document as in the OpenPGP
-   specification [OpenPGP].  We use the term "OpenPGP certificate" to
-   refer to OpenPGP keys that are enabled for authentication.
-
-   This document uses the same notation and terminology used in the TLS
-   Protocol specification [TLS].
-
-   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 [RFC2119].
-
-3.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP certificates are to be used for authentication.
-
-3.1.  Client Hello
-
-   In order to indicate the support of multiple certificate types,
-   clients MUST include an extension of type "cert_type" (see Section 5)
-   to the extended client hello message.  The hello extension mechanism
-   is described in [TLSEXT].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension MUST be
-   omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension contains a
-   CertificateTypeExtension structure.
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 3]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-   No new cipher suites are required to use OpenPGP certificates.  All
-   existing cipher suites that support a compatible, with the key, key
-   exchange method can be used in combination with OpenPGP certificates.
-
-3.2.  Server Hello
-
-   If the server receives a client hello that contains the "cert_type"
-   extension and chooses a cipher suite that requires a certificate,
-   then two outcomes are possible.  The server MUST either select a
-   certificate type from the certificate_types field in the extended
-   client hello or terminate the connection with a fatal alert of type
-   "unsupported_certificate".
-
-   The certificate type selected by the server is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message using an extension of type "cert_type".  Servers
-   that only support X.509 certificates MAY omit including the
-   "cert_type" extension in the extended server hello.
-
-   It is perfectly legal for a server to ignore this message.  In that
-   case the normal TLS handshake should be used.  Other certificate
-   types than the default MUST NOT be used.
-
-3.3.  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated, then it is required to
-   present an OpenPGP certificate in the certificate message.  The
-   certificate must contain a public key that matches the selected key
-   exchange algorithm, as shown below.
-
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 4]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-      Key Exchange Algorithm  OpenPGP Certificate Type
-
-      RSA                     RSA public key that can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key that can be used for
-                              authentication.
-
-      DHE_RSA                 RSA public key that can be used for
-                              authentication.
-
-   An OpenPGP certificate appearing in the certificate message is sent
-   using the binary OpenPGP format.  The certificate MUST contain all
-   the elements required by Section 11.1 of [OpenPGP].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire certificate.  The process of fingerprint
-   generation is described in Section 12.2 of [OpenPGP].  The peer shall
-   respond with a "certificate_unobtainable" fatal alert if the
-   certificate with the given fingerprint cannot be found.  The
-   "certificate_unobtainable" fatal alert is defined in Section 4 of
-   [TLSEXT].
-
-
-      enum {
-           cert_fingerprint (0), cert (1), subkey_cert (2), (255)
-      } OpenPGPCertDescriptorType;
-
-      opaque OpenPGPCertFingerprint<16..20>;
-
-      opaque OpenPGPCert<0..2^24-1>;
-
-      struct {
-          opaque OpenPGPKeyID<1..8>;
-          opaque OpenPGPCert<0..2^24-1>;
-      } OpenPGPSubKeyCert;
-
-      struct {
-           OpenPGPCertDescriptorType descriptorType;
-           select (descriptorType) {
-                case cert_fingerprint: OpenPGPCertFingerprint;
-                case cert: OpenPGPCert;
-                case subkey_cert: OpenPGPSubKeyCert;
-           }
-      } Certificate;
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 5]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-3.4.  Certificate Request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However, if this message is sent, and the negotiated
-   certificate type is OpenPGP, the "certificate_authorities" list MUST
-   be empty.
-
-3.5.  Client Certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message, and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP certificates have been selected and no certificate
-   is available from the client, then a certificate structure that
-   contains an empty OpenPGPCert vector MUST be sent.  The server SHOULD
-   respond with a "handshake_failure" fatal alert if client
-   authentication is required.
-
-3.6.  Other Handshake Messages
-
-   All the other handshake messages are identical to the TLS
-   specification.
-
-4.  Security Considerations
-
-   All security considerations discussed in [TLS], [TLSEXT], and
-   [OpenPGP] apply to this document.  Considerations about the use of
-   the web of trust or identity and certificate verification procedure
-   are outside the scope of this document.  These are considered issues
-   to be handled by the application layer protocols.
-
-   The protocol for certificate type negotiation is identical in
-   operation to ciphersuite negotiation of the [TLS] specification with
-   the addition of default values when the extension is omitted.  Since
-   those omissions have a unique meaning and the same protection is
-   applied to the values as with ciphersuites, it is believed that the
-   security properties of this negotiation are the same as with
-   ciphersuite negotiation.
-
-   When using OpenPGP fingerprints instead of the full certificates, the
-   discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs"
-   applies, especially when external servers are used to retrieve keys.
-   However, a major difference is that although the
-   "client_certificate_url" extension allows identifying certificates
-   without including the certificate hashes, this is not possible in the
-   protocol proposed here.  In this protocol, the certificates, when not
-   sent, are always identified by their fingerprint, which serves as a
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 6]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-   cryptographic hash of the certificate (see Section 12.2 of
-   [OpenPGP]).
-
-   The information that is available to participating parties and
-   eavesdroppers (when confidentiality is not available through a
-   previous handshake) is the number and the types of certificates they
-   hold, plus the contents of certificates.
-
-5.  IANA Considerations
-
-   This document defines a new TLS extension, "cert_type", assigned a
-   value of 9 from the TLS ExtensionType registry defined in [TLSEXT].
-   This value is used as the extension number for the extensions in both
-   the client hello message and the server hello message.  The new
-   extension type is used for certificate type negotiation.
-
-   The "cert_type" extension contains an 8-bit CertificateType field,
-   for which a new registry, named "TLS Certificate Types", is
-   established in this document, to be maintained by IANA.  The registry
-   is segmented in the following way:
-
-   1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
-
-   2.  Values from 2 through 223 decimal inclusive are assigned via IETF
-       Consensus [RFC2434].
-
-   3.  Values from 224 decimal through 255 decimal inclusive are
-       reserved for Private Use [RFC2434].
-
-6.  Acknowledgements
-
-   This document was based on earlier work made by Will Price and
-   Michael Elkins.
-
-   The author wishes to thank Werner Koch, David Taylor, Timo Schulz,
-   Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie
-   Orman for their suggestions on improving this document.
-
-7.  References
-
-7.1.  Normative References
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", RFC 4346, April 2006.
-
-   [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R.
-              Thayer, "OpenPGP Message Format", RFC 4880, October 2007.
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 7]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", RFC 2434,
-              October 1998.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-7.2.  Informative References
-
-   [PKIX]     Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-Author's Address
-
-   Nikos Mavrogiannopoulos
-   Independent
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 8]
-
-Internet-Draft             Using OpenPGP Keys               January 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Mavrogiannopoulos         Expires July 4, 2008                  [Page 9]
-
diff --git a/doc/protocol/draft-modadugu-tls-ctr-00.txt b/doc/protocol/draft-modadugu-tls-ctr-00.txt
deleted file mode 100644
index 3660aaf764..0000000000
--- a/doc/protocol/draft-modadugu-tls-ctr-00.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-Network Working Group                                        N. Modadugu
-Internet-Draft                                       Stanford University
-Expires: April 19, 2006                                      E. Rescorla
-                                                       Network Resonance
-                                                        October 16, 2005
-
-
-            AES Counter Mode Cipher Suites for TLS and DTLS
-                       draft-modadugu-tls-ctr-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on April 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes the use of the Advanced Encryption Standard
-   (AES) Counter Mode for use as a Transport Layer Security (TLS) and
-   Datagram Transport Layer Security (DTLS) confidentiality mechanism.
-
-
-
-
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 1]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-     1.1.  Conventions Used In This Document . . . . . . . . . . . . . 3
-   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   3.  Encrypting Records with AES Counter Mode  . . . . . . . . . . . 4
-     3.1.  TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
-       3.1.1.  AES Counter Mode  . . . . . . . . . . . . . . . . . . . 4
-     3.2.  DTLS  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     3.3.  Padding . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     3.4.  Session Resumption  . . . . . . . . . . . . . . . . . . . . 6
-   4.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . . . 6
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
-     5.1.  Maximum Key Lifetime  . . . . . . . . . . . . . . . . . . . 7
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 2]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-1.  Introduction
-
-   Transport Layer Security [3] provides channel-oriented security for
-   application layer protocols.  In TLS, cryptographic algorithms are
-   specified in "Cipher Suites, which consist of a group of algorithms
-   to be used together."
-
-   Cipher suites supported by TLS are divided into stream and block
-   ciphers.  Counter mode ciphers behave like stream ciphers, but are
-   constructed based on a block cipher primitive (that is, counter mode
-   operation of a block cipher results in a stream cipher.)  This
-   specification is limited to discussion of the operation of AES in
-   counter mode (AES-CTR.)
-
-   Counter mode ciphers (CTR) offer a number of attractive features over
-   other block cipher modes and stream ciphers such as RC4:
-
-   Low Bandwidth: AES-CTR provides a saving of 17-32 bytes per record
-      compared to AES-CBC as used in TLS 1.1 and DTLS. 16 bytes are
-      saved from not having to transmit an explicit IV, and another 1-16
-      bytes are saved from the absence of the padding block.
-
-   Random Access: AES-CTR is capable of random access within the key
-      stream.  For DTLS, this implies that records can be processed out
-      of order without dependency on packet arrival order, and also
-      without keystream buffering.
-
-   Parallelizable: As a consequence of AES-CTR supporting random access
-      within the key stream, the cipher can be easily parallelized.
-
-   Multiple mode support: AES-CTR support in TLS/DTLS allows for
-      implementator to support both a stream (CTR) and block (CBC)
-      cipher through the implemention of a single symmetric algorithm.
-
-1.1.  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 [1].
-
-
-2.  Terminology
-
-   This document reuses some terminology introduced in [2] and [3].  The
-   term 'counter block' has the same meaning as used in RFC3686,
-   however, the term 'IV', in this document, holds the meaning defined
-   in [3].
-
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 3]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-3.  Encrypting Records with AES Counter Mode
-
-   The use of AES-CTR in TLS/DTLS turns out to be fairly
-   straightforward, with the additional benefit that the method of
-   operation in TLS/DTLS mimics, to a large extent, that in IPsec.  The
-   primary constraint on the use of counter mode ciphers is that for a
-   given key, a counter block value MUST never be used more than once
-   (see Section 7. of [2] for a detailed explanation.)  In TLS/DTLS
-   ensuring that counter block values never repeat during a given
-   session is straightforward as explained in the following sections.
-
-   SSL/TLS records encrypted with AES CTR mode use a
-   CipherSpec.cipher_type of GenericStreamCipher (Section 6.2.3 of [3].)
-
-3.1.  TLS
-
-   The cipher stream generated by AES-CTR is much like the cipher stream
-   generated by stream ciphers like RC4.  For reasons described in
-   Section 7. of [2], a counter block value MUST never be used more than
-   once with a given key.  This is achieved by having part of the per-
-   record IV determined by the record sequence number.  Although the
-   client and server use the same sequence number space, they use
-   different keys and IVs.
-
-3.1.1.  AES Counter Mode
-
-   AES counter mode requires the encryptor and decryptor to share a per-
-   record unique counter block.  A given counter block MUST never be
-   used more than once with the same key.  For a more in-depth
-   discussion of AES-CTR operation, refer to Section 2.1 of [2].  The
-   following description of AES-CTR mode has been adapted from [2].
-
-   To encrypt a payload with AES-CTR, the encryptor partitions the
-   plaintext, PT, into 128-bit blocks.  The final block MAY be less than
-   128 bits.
-
-   PT = PT[1] PT[2] ...  PT[n]
-
-   Each PT block is XORed with a block of the key stream to generate the
-   ciphertext, CT.  The AES encryption of each counter block results in
-   128 bits of key stream.
-
-   To construct the counter block, the most significant 48 bits of the
-   counter block are set to the 48 low order bits of the client_write_IV
-   (for the half-duplex stream originated by the client) or the 48 low
-   order bits of the server_write_IV (for the half-duplex stream
-   originated by the server.)  The following 64 bits of the counter
-   block are set to record sequence number, and the remaining 16 bits
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 4]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-   function as the block counter.  The least significant bit of the
-   counter block is initially set to one.  This counter value is
-   incremented by one to generate subsequent counter blocks, each
-   resulting in another 128 bits of key stream.
-
-          struct {
-             case client:
-                 uint48 client_write_IV;  // low order 48-bits
-             case server:
-                 uint48 server_write_IV;  // low order 48-bits
-             uint64 seq_num;
-             uint16 blk_ctr;
-          } CtrBlk;
-
-   The seq_num and blk_ctr fields of the counter block are initialized
-   for each record processed, while the IV is initialized immediately
-   after a key calculation is made (key calculations are made whenver a
-   TLS/DTLS handshake, either full or abbreviated, is executed.) seq_num
-   is set to the sequence number of the record, and blk_ctr is
-   initialized to 1.
-
-   Note that the block counter does not overflow since the maximum TLS/
-   DTLS record size is 14 KB and 16 bits of blk_ctr allow the generation
-   of 1MB of keying material per record.
-
-   The encryption of n plaintext blocks can be summarized as:
-
-         FOR i := 1 to n-1 DO
-           CT[i] := PT[i] XOR AES(CtrBlk)
-           CtrBlk := CtrBlk + 1
-         END
-         CT[n] := PT[n] XOR TRUNC(AES(CtrBlk))
-
-   The AES() function performs AES encryption with the fresh key.
-
-   The TRUNC() function truncates the output of the AES encrypt
-   operation to the same length as the final plaintext block, returning
-   the most significant bits.
-
-   Decryption is similar.  The decryption of n ciphertext blocks can be
-   summarized as:
-
-         FOR i := 1 to n-1 DO
-           PT[i] := CT[i] XOR AES(CtrBlk)
-           CtrBlk := CtrBlk + 1
-         END
-         PT[n] := CT[n] XOR TRUNC(AES(CtrBlk))
-
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 5]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-   For TLS, no part of the counter block need be transmitted, since the
-   client_write_IV and server_write_IV are derived during the key
-   calculation phase, and the record sequence number is implicit.
-
-3.2.  DTLS
-
-   The operation of AES-CTR in DTLS is the same as in TLS, with the only
-   difference being the inclusion of the epoch in the counter block.
-   The counter block is constructed as follows for DTLS:
-
-       struct {
-          case client:
-              uint48 client_write_IV;  // low order 48-bits
-          case server:
-              uint48 server_write_IV;  // low order 48-bits
-          uint16 epoch;
-          uint48 seq_num;
-          uint16 blk_ctr;
-       } CtrBlk;
-
-   The epoch and record sequence number used for generating the counter
-   block are extracted from the received record.
-
-3.3.  Padding
-
-   Stream ciphers in TLS and DTLS do not require plaintext padding.
-
-3.4.  Session Resumption
-
-   TLS supports session resumption via caching of session ID's and
-   connection parameters on both client and server.  While resumed
-   sessions use the same master secret that was originally negotiated, a
-   resumed session uses new keys that are derived, in part, using fresh
-   client_random and server_random parameters.  As a result resumed
-   sessions do not use the same encryption keys or IVs as the original
-   session.
-
-
-4.  Design Rationale
-
-   An alternate design for the construction of the counter block would
-   be the use of an explicit 'record tag' (as a substitute for the
-   implicit record sequence number) that could potentially be generated
-   via an LFSR.  Such a design, however, suffers two major drawbacks
-   when used in the TLS or DTLS protocol, without offering any
-   significant benefit: (1) in both TLS and DTLS inclusion of such a tag
-   would incur a bandwidth cost, (2) all TLS and DTLS associations have
-   per-record sequence numbers which can be used to ensure counter
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 6]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-   uniqueness.
-
-
-5.  Security Considerations
-
-   See Section 7. of [2].
-
-5.1.  Maximum Key Lifetime
-
-   TLS/DTLS sessions employing AES-CTR MUST be renegotiated before
-   sequence numbers repeat.  In the case of TLS, this implies a maximum
-   of 2^64 records per session, while for DTLS the maximum is 2^48 (with
-   the remaining bits reserved for epoch.)
-
-
-6.  IANA Considerations
-
-   IANA has assigned the following values for AES-CTR mode ciphers:
-
-   CipherSuite TLS_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_DSS_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_RSA_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_anon_WITH_AES_128_CTR_SHA = { 0xXX, 0xXX };
-
-   CipherSuite TLS_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_DSS_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DHE_RSA_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-   CipherSuite TLS_DH_anon_WITH_AES_256_CTR_SHA = { 0xXX, 0xXX };
-
-7.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Housley, R., "Using Advanced Encryption Standard (AES) Counter
-        Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686,
-        January 2004.
-
-   [3]  Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
-        draft-ietf-tls-rfc2246-bis-13 (work in progress), June 2005.
-
-
-
-
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 7]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-Authors' Addresses
-
-   Nagendra Modadugu
-   Stanford University
-   353 Serra Mall
-   Stanford, CA  94305
-   USA
-
-   Email: nagendra@cs.stanford.edu
-
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore Rd., #212
-   Palo Alto, CA  94303
-   USA
-
-   Email: ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 8]
-
-Internet-Draft              TLS/DTLS AES-CTR                October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Modadugu & Rescorla      Expires April 19, 2006                 [Page 9]
-
-
diff --git a/doc/protocol/draft-nir-tee-pm-00.txt b/doc/protocol/draft-nir-tee-pm-00.txt
deleted file mode 100644
index 0219d3b7dd..0000000000
--- a/doc/protocol/draft-nir-tee-pm-00.txt
+++ /dev/null
@@ -1,1008 +0,0 @@
-
-
-
-TLS Working Group                                                 Y. Nir
-Internet-Draft                                                Y. Sheffer
-Intended status: Standards Track                             Check Point
-Expires: August 25, 2007                                   H. Tschofenig
-                                                                 Siemens
-                                                       February 21, 2007
-
-
-             Protocol Model for TLS with EAP Authentication
-                        draft-nir-tee-pm-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 25, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 1]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-Abstract
-
-   This document describes an extension to the TLS protocol to allow TLS
-   clients to authenticate with legacy credentials using the Extensible
-   Authentication Protocol (EAP).
-
-   This work follows the example of IKEv2, where EAP has been added to
-   the IKEv2 protocol to allow clients to use different credentials such
-   as passwords, token cards, and shared secrets.
-
-   When TLS is used with EAP, additional records are sent after the
-   ChangeCipherSpec protocol message, effectively creating an extended
-   handshake before the application layer data can be sent.  Each EapMsg
-   handshake record contains exactly one EAP message.  Using EAP for
-   client authentication allows TLS to be used with various AAA back-end
-   servers such as RADIUS or Diameter.
-
-   TLS with EAP may be used for securing a data connection such as HTTP
-   or POP3, where the ability of EAP to work with backend servers can
-   remove that burden from the application layer.
-
-   This document is a protocol model, rather than a full protocol
-   specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 2]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  5
-   2.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  6
-   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
-     3.1.  The tee_supported Extension  . . . . . . . . . . . . . . .  8
-     3.2.  The InterimAuth Handshake Message  . . . . . . . . . . . .  8
-     3.3.  The EapMsg Handshake Message . . . . . . . . . . . . . . .  8
-     3.4.  Calculating the Finished message . . . . . . . . . . . . .  8
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     4.1.  InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
-     4.2.  Identity Protection  . . . . . . . . . . . . . . . . . . . 10
-   5.  Performance Considerations . . . . . . . . . . . . . . . . . . 12
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
-   Intellectual Property and Copyright Statements . . . . . . . . . . 18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 3]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-1.  Introduction
-
-   This document describes a new extension to [TLS].  This extension
-   allows a TLS client to authenticate using [EAP] instead of using a
-   certificate, or alternatively performing the authentication at the
-   application level.  The extension follows [TLS-EXT].  For the
-   remainder of this document we will refer to this extension as TEE
-   (TLS with EAP Extension).  The document is a protocol model as
-   described in [RFC4101].
-
-   TEE extends the TLS handshake beyond the regular setup, to allow the
-   EAP protocol to run between the TLS server (called an "authenticator"
-   in EAP) and the TLS client (called a "supplicant").  This allows the
-   TLS architecture to handle client authentication before exposing the
-   server application software to an unauthenticated client.  In doing
-   this, we follow the approach taken for IKEv2 in [IKEv2].  However,
-   similar to regular TLS, we protect the user identity by only sending
-   the client identity after the server has authenticated.  In this our
-   solution defers from that of IKEv2.
-
-   Currently used applications use TLS to authenticate the server only.
-   After that, the application takes over, and presents a login screen
-   where the user is expected to present their credentials.
-
-   This creates several problems.  It allows a client to access the
-   application before authentication, thus creating a potential for
-   anonymous attacks on non-hardened applications.  Additionally, web
-   pages are not particularly well suited for long shared secrets and
-   for certain devices such as USB tokens.
-
-   TEE allows full mutual authentication to occur for all these
-   applications within the TLS exchange.  The application receives
-   control only when the user is identified and authenticated.  The
-   authentication can be built into the server infrastructure by
-   connecting to an AAA server.  The client side can be integrated into
-   client software such as web browsers and mail clients.  An EAP
-   infrastructure is already built-in to some operating systems
-   providing a user interface for each authentication method within EAP.
-
-   We intend TEE to be used for various protocols that use TLS such as
-   HTTPS, in cases where certificate based authentication is not
-   practical.  This includes web-based mail services, online banking,
-   premium content websites and mail clients.
-
-   Another class of applications that may see benefit from TEE are TLS
-   based VPN clients used as part of so-called "SSL VPN" products.  No
-   such client protocols have so far been standardized.
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 4]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-1.1.  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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 5]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-2.  Operating Environment
-
-   TEE will work between a client application and a server application,
-   taking care of all encryption and authentication.
-
-
-        Client                         Server
-    +-------------------------+     +------------------------+
-    |  |GUI| | Client | |TLS+-+-----+-+TLS|   |Server      | |
-    |  +-^-+ |Software| +-^-+ |     +-+-^-+   |Application | |
-    |    |   +--------+   |   |     |   |     |Software    | |
-    |    |                |   |     |   |     +------------+ |
-    |  +-v----------------v-+ |     |   |                    |
-    |  |   EAP              | |     +---|--------------------+
-    |  |  Infrastructure    | |         |
-    |  +--------------------+ |         |    +--------+
-    +-------------------------+         |    | AAA    |
-                                        |    | Server |
-                                        +-----        |
-                                             +--------+
-
-   The above diagram shows the typical deployment.  The client has
-   software that either includes a UI for some EAP methods, or else is
-   able to invoke some operating system EAP infrastructure that takes
-   care of the user interaction.  The server is configured with the
-   address and protocol of the AAA server.  Typically the AAA server
-   communicates using the RADIUS protocol with EAP ([RADIUS] and
-   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
-
-   As stated in the introduction, we expect TEE to be used in both
-   browsers and applications.  Further uses may be authentication and
-   key generation for other protocols, and tunneling clients, which so
-   far have not been standardized.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 6]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-3.  Protocol Overview
-
-   The TEE extension defines the following:
-   o  A new extension type called tee_supported, used to indicate that
-      the client supports this extension.
-   o  A new message type for the handshake protocol, called InterimAuth,
-      which is used to sign previous messages.
-   o  A new message type for the handshake protocol, called EapMsg,
-      which is used to carry a single EAP message.
-
-   The diagram below outlines the protocol structure.  For illustration
-   purposes only, we use the [I-D.dpotter-pppext-eap-mschap] EAP method
-   .
-
-         Client                                               Server
-         ------                                               ------
-
-         ClientHello(*)             -------->
-                                                      ServerHello(*)
-                                                       (Certificate)
-                                                   ServerKeyExchange
-                                            EapMsg(Identity-Request)
-                                     <--------       ServerHelloDone
-         ClientKeyExchange
-         (CertificateVerify)
-         ChangeCipherSpec
-         InterimAuth
-         EapMsg(Identity-Reply)     -------->
-                                                    ChangeCipherSpec
-                                                         InterimAuth
-                                          EapMsg(MS-CHAP-v2-Request)
-                                    <--------
-         EapMsg(MS-CHAP-v2-Reply)   -------->
-                                                     EapMsg(Success)
-                                    <--------               Finished
-         Finished                   -------->
-
-       (*) The ClientHello and ServerHello include the tee_supported
-           extension to indicate support for TEE
-
-
-   The client indicates in the first message its support for TEE.  The
-   server sends an EAP identity request in the reply.  The client sends
-   the identity reply after the handshake completion.  The EAP request-
-   response sequence continues until the client is either authenticated
-   or rejected.
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 7]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-3.1.  The tee_supported Extension
-
-   The tee_supported extension is a ClientHello and ServerHello
-   extension as defined in section 2.3 of [TLS-EXT].  The extension_type
-   field is TBA by IANA.  The extension_data is zero-length.
-
-3.2.  The InterimAuth Handshake Message
-
-   The InterimAuth message is identical in syntax to the Finished
-   message described in section 7.4.9 of [TLS].  It is calculated in
-   exactly the same way.
-
-   The semantics, however, are somewhat different.  The "Finished"
-   message indicates that application data may now be sent.  The
-   "InterimAuth" message does not indicate this.  Instead, further
-   handshake messages are needed.
-
-   Depending on the EAP method used, the Finished message may be
-   calculated differently.  See Section 3.4 for details.
-
-   The HandshakeType value for the InterimAuth handshake message is TBA
-   by IANA.
-
-3.3.  The EapMsg Handshake Message
-
-   The EapMsg handshake message carries exactly one EAP message as
-   defined in [EAP].
-
-   The HandshakeType value for the EapMsg handshake message is TBA by
-   IANA.
-
-   The EapMsg message is used to tunnel EAP messages between the
-   authentication server, which may be the co-located with the TLS
-   server, or may be a separate AAA server, and the supplicant, which is
-   co-located with the TLS client.  TLS on either side receives the EAP
-   data from the EAP infrastructure, and treats it as opaque.  TLS does
-   not make any changes to the EAP payload or make any decisions based
-   on the contents of an EapMsg handshake message.
-
-3.4.  Calculating the Finished message
-
-   If the EAP method is key-generating, the Finished message is
-   calculated as follows:
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 8]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-         struct {
-             opaque verify_data[12];
-         } Finished;
-
-         verify_data
-             PRF(MSK, finished_label, MD5(handshake_messages) +
-             SHA-1(handshake_messages)) [0..11];
-
-   The finished_label is defined exactly as in section 7.4.9 of [TLS].
-
-   The handshake_messages, similar to regular TLS is all of the data
-   from all messages in this handshake, including any EapMsg and
-   InterimAuth messages, up to but not including this Finished message.
-   This is the concatenation of all the Handshake structures, as defined
-   in section 7.4 of [TLS] and here, exchanged thus far.
-
-   The MSK is typically received from the AAA server over the RADIUS or
-   Diameter protocol.
-
-   If the EAP method is not key-generating, then the Finished message is
-   calculated exactly as described in [TLS].  Such methods however, are
-   NOT RECOMMENDED.  See Section 4.1 for details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007                [Page 9]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-4.  Security Considerations
-
-4.1.  InterimAuth vs. Finished
-
-   In regular TLS, the Finished message provides two functions: it signs
-   all previous messages, and it signals that application data can now
-   be used.  In TEE, we sign the previous messages twice.
-
-   Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate
-   keys in addition to authenticating clients.  Such methods are said to
-   be resistant to MITM attacks as discussed in [MITM].  Such methods
-   are called key-generating methods.
-
-   To realize the benefit of such methods, we need to verify the key
-   that was generated within the EAP method.  This is referred to as the
-   MSK in EAP.  In TEE, the InterimAuth message signs all previous
-   messages with the master_secret, just like the Finished message in
-   regular TLS.  The Finished message signs all previous messages using
-   the MSK if such exists.  If not, then the messages are signed with
-   the master_secret as in regular TLS.
-
-   The need for signing twice arises from the fact that we need to use
-   both the master_secret and the MSK.  It was possible to use just one
-   Finished record and blend the MSK into the master_secret.  However,
-   this would needlessly complicate the protocol and make security
-   analysis more difficult.  Instead, we have decided to follow the
-   example of IKEv2, where two AUTH payloads are exchanged.
-
-   It should be noted that using non-key-generating methods may expose
-   the client to a MITM attack if the same MITM method is used in some
-   other situation, in which the EAP is done outside of a protected
-   tunnel with an authenticated server.  Unless it can be determined
-   that the EAP method is never used in such a situation, non-key-
-   generating methods SHOULD NOT be used.
-
-4.2.  Identity Protection
-
-   Unlike [TLS-PSK], TEE provides identity protection for the client.
-   The client's identity is hidden from a passive eavesdropper using TLS
-   encryption, and it is not sent to the server until after the server's
-   identity has been authenticated by verifying the certificate.
-
-   Active attacks are thwarted by the server authentication using a
-   certificate or by using a suitable EAP method.
-
-   We could save one round-trip by having the client send its identity
-   within the Client Hello message.  This is similar to TLS-PSK.
-   However, we believe that identity protection is a worthy enough goal,
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 10]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-   so as to justify the extra round-trip.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 11]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-5.  Performance Considerations
-
-   Regular TLS adds two round-trips to a TCP connection.  However,
-   because of the stream nature of TCP, the client does not really need
-   to wait for the server's Finished message, and can begin sending
-   application data immediately after its own Finished message.  In
-   practice, many clients do so, and TLS only adds one round-trip of
-   delay.
-
-   TEE adds as many round-trips as the EAP method requires.  For
-   example, EAP-MD5 requires 1 round-trip, while EAP-SIM requires 2
-   round-trips.  Additionally, the client MUST wait for the EAP-Success
-   message before sending its own Finished message, so we need at least
-   3 round-trips for the entire handshake.  The best a client can do is
-   two round-trips plus however many round-trips the EAP method
-   requires.
-
-   It should be noted, though, that these extra round-trips save
-   processing time at the application level.  Two extra round-trips take
-   a lot less time than presenting a log-in web page and processing the
-   user's input.
-
-   It should also be noted, that TEE reverses the order of the Finished
-   messages.  In regular TLS the client sends the Finished message
-   first.  In TEE it is the server that sends the Finished message
-   first.  This should not affect performance, and it is clear that the
-   client may send application data immediately after the Finished
-   message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 12]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-6.  IANA Considerations
-
-   IANA is asked to assign an extension type value from the
-   "ExtensionType Values" registry for the tee_supported extension.
-
-   IANA is asked to assign two handshake message types from the "TLS
-   HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 13]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-7.  Acknowledgments
-
-   The TLS Innel Application Extension work ([TLS/IA]) has inspired the
-   authors to create this simplified work.  TLS/IA provides a somewhat
-   different approach to integrating non-certificate credentials into
-   the TLS protocol, in addition to several other features available
-   from the RADIUS namespace.
-
-   The authors would also like to thanks the various contributors to
-   [IKEv2] whose work inspired this one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 14]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-8.  References
-
-8.1.  Normative References
-
-   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
-              Levkowetz, "Extensible Authentication Protocol (EAP)",
-              RFC 3748, June 2004.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [TLS-EXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-8.2.  Informative References
-
-   [Dia-EAP]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
-              Authentication Protocol (EAP) Application", RFC 4072,
-              August 2005.
-
-   [Diameter]
-              Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
-              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
-
-   [I-D.dpotter-pppext-eap-mschap]
-              Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2
-              Authentication Protocol",
-              draft-dpotter-pppext-eap-mschap-01 (work in progress),
-              January 2002.
-
-   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              RFC 4306, December 2005.
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
-              in Tunneled Authentication Protocols", October 2002.
-
-   [RAD-EAP]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
-              Dial In User Service) Support For Extensible
-              Authentication Protocol (EAP)", RFC 3579, September 2003.
-
-   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
-              "Remote Authentication Dial In User Service (RADIUS)",
-              RFC 2865, June 2000.
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 15]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-   [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
-              June 2005.
-
-   [TLS-PSK]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [TLS/IA]   Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
-              T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
-              draft-funk-tls-inner-application-extension-03 (work in
-              progress), June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 16]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-Authors' Addresses
-
-   Yoav Nir
-   Check Point Software Technologies Ltd.
-   3A Jabotinsky St.
-   Ramat Gan  52520
-   Israel
-
-   Email: ynir@checkpoint.com
-
-
-   Yaron Sheffer
-   Check Point Software Technologies Ltd.
-   3A Jabotinsky St.
-   Ramat Gan  52520
-   Israel
-
-   Email: yaronf at checkpoint dot com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bavaria  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-   URI:   http://www.tschofenig.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 17]
-
-Internet-Draft                   TEE PM                    February 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Nir, et al.              Expires August 25, 2007               [Page 18]
-
diff --git a/doc/protocol/draft-nir-tls-eap-00.txt b/doc/protocol/draft-nir-tls-eap-00.txt
deleted file mode 100644
index d740f04917..0000000000
--- a/doc/protocol/draft-nir-tls-eap-00.txt
+++ /dev/null
@@ -1,1120 +0,0 @@
-
-
-
-TLS Working Group                                                 Y. Nir
-Internet-Draft                                                Y. Sheffer
-Intended status: Standards Track                             Check Point
-Expires: December 9, 2007                                  H. Tschofenig
-                                                                     NSN
-                                                              P. Gutmann
-                                                  University of Auckland
-                                                            June 7, 2007
-
-
-                      TLS using EAP Authentication
-                        draft-nir-tls-eap-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 9, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 1]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-Abstract
-
-   This document describes an extension to the TLS protocol to allow TLS
-   clients to authenticate with legacy credentials using the Extensible
-   Authentication Protocol (EAP).
-
-   This work follows the example of IKEv2, where EAP has been added to
-   the IKEv2 protocol to allow clients to use different credentials such
-   as passwords, token cards, and shared secrets.
-
-   When TLS is used with EAP, additional records are sent after the
-   ChangeCipherSpec protocol message and before the Finished message,
-   effectively creating an extended handshake before the application
-   layer data can be sent.  Each EapMsg handshake record contains
-   exactly one EAP message.  Using EAP for client authentication allows
-   TLS to be used with various AAA back-end servers such as RADIUS or
-   Diameter.
-
-   TLS with EAP may be used for securing a data connection such as HTTP
-   or POP3.  We believe it has three main benefits:
-   o  The ability of EAP to work with backend servers can remove that
-      burden from the application layer.
-   o  Moving the user authentication into the TLS handshake protects the
-      presumably less secure application layer from attacks by
-      unauthenticated parties.
-   o  Using mutual authentication methods within EAP can help thwart
-      certain classes of phishing attacks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 2]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  EAP Applicability  . . . . . . . . . . . . . . . . . . . .  5
-     1.2.  Conventions Used in This Document  . . . . . . . . . . . .  5
-   2.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  6
-   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
-     3.1.  The tee_supported Extension  . . . . . . . . . . . . . . .  8
-     3.2.  The InterimAuth Handshake Message  . . . . . . . . . . . .  8
-     3.3.  The EapMsg Handshake Message . . . . . . . . . . . . . . .  8
-     3.4.  Calculating the Finished message . . . . . . . . . . . . .  9
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     4.1.  InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
-     4.2.  Identity Protection  . . . . . . . . . . . . . . . . . . . 10
-     4.3.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 11
-   5.  Performance Considerations . . . . . . . . . . . . . . . . . . 12
-   6.  Operational Considerations . . . . . . . . . . . . . . . . . . 13
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
-   9.  Changes from Previous Versions . . . . . . . . . . . . . . . . 16
-     9.1.  Changes from the protocol model draft  . . . . . . . . . . 16
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
-   Intellectual Property and Copyright Statements . . . . . . . . . . 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 3]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-1.  Introduction
-
-   This document describes a new extension to [TLS].  This extension
-   allows a TLS client to authenticate using [EAP] instead of performing
-   the authentication at the application level.  The extension follows
-   [TLS-EXT].  For the remainder of this document we will refer to this
-   extension as TEE (TLS with EAP Extension).
-
-   TEE extends the TLS handshake beyond the regular setup, to allow the
-   EAP protocol to run between the TLS server (called an "authenticator"
-   in EAP) and the TLS client (called a "supplicant").  This allows the
-   TLS architecture to handle client authentication before exposing the
-   server application software to an unauthenticated client.  In doing
-   this, we follow the approach taken for IKEv2 in [RFC4306].  However,
-   similar to regular TLS, we protect the user identity by only sending
-   the client identity after the server has authenticated.  In this our
-   solution differs from that of IKEv2.
-
-   Currently used applications that rely on non-certificate user
-   credentials use TLS to authenticate the server only.  After that, the
-   application takes over, and presents a login screen where the user is
-   expected to present their credentials.
-
-   This creates several problems.  It allows a client to access the
-   application before authentication, thus creating a potential for
-   anonymous attacks on non-hardened applications.  Additionally, web
-   pages are not particularly well suited for long shared secrets and
-   for interfacing with certain devices such as USB tokens.
-
-   TEE allows full mutual authentication to occur for all these
-   applications within the TLS exchange.  The application receives
-   control only when the user is identified and authenticated.  The
-   authentication can be built into the server infrastructure by
-   connecting to an AAA server.  The client side can be integrated into
-   client software such as web browsers and mail clients.  An EAP
-   infrastructure is already built into some operating systems providing
-   a user interface for each authentication method within EAP.
-
-   We intend TEE to be used for various protocols that use TLS such as
-   HTTPS, in cases where certificate based client authentication is not
-   practical.  This includes web-based mail services, online banking,
-   premium content websites and mail clients.
-
-   Another class of applications that may see benefit from TEE are TLS
-   based VPN clients used as part of so-called "SSL VPN" products.  No
-   such client protocols have so far been standardized.
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 4]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-1.1.  EAP Applicability
-
-   Section 1.3 of [EAP] states that EAP is only applicable for network
-   access authentication, rather than for "bulk data transfer".  It then
-   goes on to explain why the transport properties of EAP indeed make it
-   unsuitable for bulk data transfer, e.g. for large file transport.
-   Our proposed use of EAP falls squarely within the applicability as
-   defined, since we make no further use of EAP beyond access
-   authentication.
-
-1.2.  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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 5]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-2.  Operating Environment
-
-   TEE will work between a client application and a server application,
-   performing either client authentication or mutual authentication
-   within the TLS exchange.
-
-
-        Client                         Server
-    +-------------------------+     +------------------------+
-    |  |GUI| | Client | |TLS+-+-----+-+TLS|   |Server      | |
-    |  +-^-+ |Software| +-^-+ |     +-+-^-+   |Application | |
-    |    |   +--------+   |   |     |   |     |Software    | |
-    |    |                |   |     |   |     +------------+ |
-    |  +-v----------------v-+ |     |   |                    |
-    |  |   EAP              | |     +---|--------------------+
-    |  |  Infrastructure    | |         |
-    |  +--------------------+ |         |    +--------+
-    +-------------------------+         |    | AAA    |
-                                        |    | Server |
-                                        +-----        |
-                                             +--------+
-
-   The above diagram shows the typical deployment.  The client has
-   software that either includes a UI for some EAP methods, or else is
-   able to invoke some operating system EAP infrastructure that takes
-   care of the user interaction.  The server is configured with the
-   address and protocol of the AAA server.  Typically the AAA server
-   communicates using the RADIUS protocol with EAP ([RADIUS] and
-   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
-
-   As stated in the introduction, we expect TEE to be used in both
-   browsers and applications.  Further uses may be authentication and
-   key generation for other protocols, and tunneling clients, which so
-   far have not been standardized.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 6]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-3.  Protocol Overview
-
-   The TEE extension defines the following:
-   o  A new extension type called tee_supported, used to indicate that
-      the client supports this extension.
-   o  A new message type for the handshake protocol, called InterimAuth,
-      which is used to sign previous messages.
-   o  A new message type for the handshake protocol, called EapMsg,
-      which is used to carry a single EAP message.
-
-   The diagram below outlines the protocol structure.  For illustration
-   purposes only, we use the MSCHAPv2 EAP method
-   [I-D.dpotter-pppext-eap-mschap].
-
-         Client                                               Server
-         ------                                               ------
-
-         ClientHello(*)             -------->
-                                                      ServerHello(*)
-                                                       (Certificate)
-                                                   ServerKeyExchange
-                                            EapMsg(Identity-Request)
-                                     <--------       ServerHelloDone
-         ClientKeyExchange
-         (CertificateVerify)
-         ChangeCipherSpec
-         InterimAuth
-         EapMsg(Identity-Reply)     -------->
-                                                    ChangeCipherSpec
-                                                         InterimAuth
-                                          EapMsg(MS-CHAP-v2-Request)
-                                    <--------
-         EapMsg(MS-CHAP-v2-Reply)   -------->
-                                                     EapMsg(Success)
-                                    <--------               Finished
-         Finished                   -------->
-
-       (*) The ClientHello and ServerHello include the tee_supported
-           extension to indicate support for TEE
-
-
-   The client indicates in the first message its support for TEE.  The
-   server sends an EAP identity request in the reply.  The client sends
-   the identity reply after the handshake completion.  The EAP request-
-   response sequence continues until the client is either authenticated
-   or rejected.
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 7]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-3.1.  The tee_supported Extension
-
-   The tee_supported extension is a ClientHello and ServerHello
-   extension as defined in section 2.3 of [TLS-EXT].  The extension_type
-   field is TBA by IANA.  The extension_data is zero-length.
-
-3.2.  The InterimAuth Handshake Message
-
-   The InterimAuth message is identical in syntax to the Finished
-   message described in section 7.4.9 of [TLS].  It is calculated in
-   exactly the same way.
-
-   The semantics, however, are somewhat different.  The "Finished"
-   message indicates that application data may now be sent.  The
-   "InterimAuth" message does not indicate this.  Instead, further
-   handshake messages are needed.
-
-   The HandshakeType value for the InterimAuth handshake message is TBA
-   by IANA.
-
-3.3.  The EapMsg Handshake Message
-
-   The EapMsg handshake message carries exactly one EAP message as
-   defined in [EAP].
-
-   The HandshakeType value for the EapMsg handshake message is TBA by
-   IANA.
-
-   The EapMsg message is used to tunnel EAP messages between the
-   authentication server, which may be co-located with the TLS server,
-   or else may be a separate AAA server, and the supplicant, which is
-   co-located with the TLS client.  TLS on either side receives the EAP
-   data from the EAP infrastructure, and treats it as opaque.  TLS does
-   not make any changes to the EAP payload or make any decisions based
-   on the contents of an EapMsg handshake message.
-
-   Note that it is expected that the authentication server notifies the
-   TLS server about authentication success or failure, and so TLS need
-   not inspect the eap_payload within the EapMsg to detect success or
-   failure.
-
-         struct {
-             opaque eap_payload[4..65535];
-         } EapMsg;
-
-         eap_payload is defined in section 4 of RFC 3748. It includes
-         the Code, Identifier, Length and Data fields of the EAP
-         packet.
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 8]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-3.4.  Calculating the Finished message
-
-   If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the
-   Finished message is calculated as follows:
-
-         struct {
-             opaque verify_data[12];
-         } Finished;
-
-         verify_data
-             PRF(MSK, finished_label, MD5(handshake_messages) +
-             SHA-1(handshake_messages)) [0..11];
-
-   The finished_label and the PRF are as defined in section 7.4.9 of
-   [TLS].
-
-   The handshake_messages field, similar to regular TLS, comprises all
-   of the data from all messages in this handshake, including any EapMsg
-   and InterimAuth messages, up to but not including this Finished
-   message.  This is the concatenation of all the Handshake structures
-   exchanged thus far, as defined in section 7.4 of [TLS].
-
-   The Master Session Key (MSK) is derived by the AAA server and by the
-   client if the EAP method is key-generating.  On the server-side, it
-   is typically received from the AAA server over the RADIUS or Diameter
-   protocol.  On the client-side, it is passed to TLS by some other
-   method.
-
-   If the EAP method is not key-generating, then the Finished message is
-   calculated exactly as described in [TLS].  For a discussion on the
-   use of such methods, see Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007                [Page 9]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-4.  Security Considerations
-
-4.1.  InterimAuth vs. Finished
-
-   In regular TLS, the Finished message provides two functions: it signs
-   all preceding messages, and it signals that application data can now
-   be sent.  In TEE, some of the messages are signed twice.
-
-   Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate
-   keys in addition to authenticating clients.  Such methods are said to
-   be resistant to man-in-the-middle (MITM) attacks as discussed in
-   [MITM].  Such methods are called key-generating methods.
-
-   To realize the benefit of such methods, we need to verify the key
-   that was generated within the EAP method.  This is referred to as the
-   MSK in EAP.  In TEE, the InterimAuth message signs all previous
-   messages with the master_secret, just like the Finished message in
-   regular TLS.  The Finished message signs all previous messages using
-   the MSK if such exists.  If not, then the messages are signed with
-   the master_secret as in regular TLS.
-
-   The need for signing twice arises from the fact that we need to use
-   both the master_secret and the MSK.  It was possible to use just one
-   Finished record and blend the MSK into the master_secret.  However,
-   this would needlessly complicate the protocol and make security
-   analysis more difficult.  Instead, we have decided to follow the
-   example of IKEv2, where two AUTH payloads are exchanged.
-
-   It should be noted that using non-key-generating methods may expose
-   the client to a MITM attack if the same method and credentials are
-   used in some other situation, in which the EAP is done outside of a
-   protected tunnel with an authenticated server.  Unless it can be
-   determined that the EAP method is never used in such a situation,
-   non-key-generating methods SHOULD NOT be used.
-
-4.2.  Identity Protection
-
-   Unlike [TLS-PSK], TEE provides identity protection for the client.
-   The client's identity is hidden from a passive eavesdropper using TLS
-   encryption.  Active attacks are discussed in Section 4.3.
-
-   We could save one round-trip by having the client send its identity
-   within the Client Hello message.  This is similar to TLS-PSK.
-   However, we believe that identity protection is a worthy enough goal,
-   so as to justify the extra round-trip.
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 10]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-4.3.  Mutual Authentication
-
-   In order to achieve our security goals, we need to have both the
-   server and the client authenticate.  Client authentication is
-   obviously done using the EAP method.  The server authentication can
-   be done in either of two ways:
-   1.  The client can verify the server certificate.  This may work well
-       depending on the scenario, but implies that the client or its
-       user can recognize the right DN or alternate name, and
-       distinguish it from plausible alternatives.  The introduction to
-       [I.D.Webauth-phishing] shows that at least in HTTPS, this is not
-       always the case.
-   2.  The client can use a mutually authenticated (MA) EAP method such
-       as MS-CHAPv2.  In this case, server certificate verification does
-       not matter, and the TLS handshake may as well be anonymous.  Note
-       that in this case, the client identity is sent to the server
-       before server authentication.
-
-   To summarize:
-   o  Clients MUST NOT propose anonymous ciphersuites, unless they
-      support MA EAP methods.
-   o  Servers MUST NOT accept anonymous ciphersuites, unless they
-      support MA EAP methods.  If they support both MA and non-MA
-      methods, they SHOULD prefer to use the MA methods.
-   o  Clients MUST NOT accept non-MA methods if the ciphersuite is
-      anonymous.
-   o  Clients MUST NOT accpet non-MA mehtods if they are not able to
-      verify the server credentials.  Note that this document does not
-      define what verification involves.  If the server DN is known and
-      stored on the client, verifying certificate signature and checking
-      revocation may be enough.  For web browsers, the case is not as
-      clear cut, and MA methods SHOULD be used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 11]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-5.  Performance Considerations
-
-   Regular TLS adds two round-trips to a TCP connection.  However,
-   because of the stream nature of TCP, the client does not really need
-   to wait for the server's Finished message, and can begin sending
-   application data immediately after its own Finished message.  In
-   practice, many clients do so, and TLS only adds one round-trip of
-   delay.
-
-   TEE adds as many round-trips as the EAP method requires.  For
-   example, EAP-MD5 requires 1 round-trip, while EAP-SIM requires 2
-   round-trips.  Additionally, the client MUST wait for the EAP-Success
-   message before sending its own Finished message, so we need at least
-   3 round-trips for the entire handshake.  The best a client can do is
-   two round-trips plus however many round-trips the EAP method
-   requires.
-
-   It should be noted, though, that these extra round-trips save
-   processing time at the application level.  Two extra round-trips take
-   a lot less time than presenting a log-in web page and processing the
-   user's input.
-
-   It should also be noted, that TEE reverses the order of the Finished
-   messages.  In regular TLS the client sends the Finished message
-   first.  In TEE it is the server that sends the Finished message
-   first.  This should not affect performance, and it is clear that the
-   client may send application data immediately after the Finished
-   message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 12]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-6.  Operational Considerations
-
-   Section 4.3 defines a dependency between the TLS state and the EAP
-   state in that it mandates that certain EAP methods should not be used
-   with certain TLS ciphersuites.  To avoid such dependencies, there are
-   two approaches that implementations can take.  They can either not
-   use any anonymous ciphersuites, or else they can use only MA EAP
-   methods.
-
-   Where certificate validation is problematic, such as in browser-based
-   HTTPS, we recommend the latter approach.
-
-   In cases where the use of EAP within TLS is not known before opening
-   the connection, it is necessary to consider the implications of
-   requiring the user to type in credentials after the connection has
-   already started.  TCP sessions may time out, because of security
-   considerations, and this may lead to session setup failure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 13]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-7.  IANA Considerations
-
-   IANA is asked to assign an extension type value from the
-   "ExtensionType Values" registry for the tee_supported extension.
-
-   IANA is asked to assign two handshake message types from the "TLS
-   HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 14]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-8.  Acknowledgments
-
-   The TLS Inner Application Extension work ([TLS/IA]) has inspired the
-   authors to create this simplified work.  TLS/IA provides a somewhat
-   different approach to integrating non-certificate credentials into
-   the TLS protocol, in addition to several other features available
-   from the RADIUS namespace.
-
-   The authors would also like to thank the various contributors to
-   [RFC4306] whose work inspired this one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 15]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-9.  Changes from Previous Versions
-
-9.1.  Changes from the protocol model draft
-
-   o  Added diagram for EapMsg
-   o  Added discussion of EAP applicability
-   o  Added discussion of mutually-authenticated EAP methods vs other
-      methods in the security considerations.
-   o  Added operational considerations.
-   o  Other minor nits.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 16]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-10.  References
-
-10.1.  Normative References
-
-   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
-              Levkowetz, "Extensible Authentication Protocol (EAP)",
-              RFC 3748, June 2004.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [TLS-EXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-10.2.  Informative References
-
-   [Dia-EAP]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
-              Authentication Protocol (EAP) Application", RFC 4072,
-              August 2005.
-
-   [Diameter]
-              Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
-              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
-
-   [I-D.dpotter-pppext-eap-mschap]
-              Potter, D. and J. Zamick, "PPP EAP MS-CHAP-V2
-              Authentication Protocol",
-              draft-dpotter-pppext-eap-mschap-01 (work in progress),
-              January 2002.
-
-   [I-D.ietf-eap-keying]
-              Aboba, B., "Extensible Authentication Protocol (EAP) Key
-              Management Framework", draft-ietf-eap-keying-18 (work in
-              progress), February 2007.
-
-   [I.D.Webauth-phishing]
-              Hartman, S., "Requirements for Web Authentication
-              Resistant to Phishing", draft-hartman-webauth-phishing-03
-              (work in progress), March 2007.
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
-              in Tunneled Authentication Protocols", October 2002.
-
-   [RAD-EAP]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 17]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-              Dial In User Service) Support For Extensible
-              Authentication Protocol (EAP)", RFC 3579, September 2003.
-
-   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
-              "Remote Authentication Dial In User Service (RADIUS)",
-              RFC 2865, June 2000.
-
-   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              RFC 4306, December 2005.
-
-   [TLS-PSK]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [TLS/IA]   Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
-              T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
-              draft-funk-tls-inner-application-extension-03 (work in
-              progress), June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 18]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-Authors' Addresses
-
-   Yoav Nir
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: ynir@checkpoint.com
-
-
-   Yaron Sheffer
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: yaronf at checkpoint dot com
-
-
-   Hannes Tschofenig
-   Nokia Siemens Networks
-   Otto-Hahn-Ring 6
-   Munich, Bavaria  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-   URI:   http://www.tschofenig.com
-
-
-   Peter Gutmann
-   University of Auckland
-   Department of Computer Science
-   New Zealand
-
-   Email: pgut001@cs.auckland.ac.nz
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 19]
-
-Internet-Draft                 EAP-in-TLS                      June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Nir, et al.             Expires December 9, 2007               [Page 20]
-
diff --git a/doc/protocol/draft-nir-tls-eap-01.txt b/doc/protocol/draft-nir-tls-eap-01.txt
deleted file mode 100644
index 041fba2933..0000000000
--- a/doc/protocol/draft-nir-tls-eap-01.txt
+++ /dev/null
@@ -1,1176 +0,0 @@
-
-
-
-TLS Working Group                                                 Y. Nir
-Internet-Draft                                                Y. Sheffer
-Intended status: Standards Track                             Check Point
-Expires: January 5, 2008                                   H. Tschofenig
-                                                                     NSN
-                                                              P. Gutmann
-                                                  University of Auckland
-                                                            July 4, 2007
-
-
-                      TLS using EAP Authentication
-                        draft-nir-tls-eap-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on January 5, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 1]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-Abstract
-
-   This document describes an extension to the TLS protocol to allow TLS
-   clients to authenticate with legacy credentials using the Extensible
-   Authentication Protocol (EAP).
-
-   This work follows the example of IKEv2, where EAP has been added to
-   the IKEv2 protocol to allow clients to use different credentials such
-   as passwords, token cards, and shared secrets.
-
-   When TLS is used with EAP, additional records are sent after the
-   ChangeCipherSpec protocol message and before the Finished message,
-   effectively creating an extended handshake before the application
-   layer data can be sent.  Each EapMsg handshake record contains
-   exactly one EAP message.  Using EAP for client authentication allows
-   TLS to be used with various AAA back-end servers such as RADIUS or
-   Diameter.
-
-   TLS with EAP may be used for securing a data connection such as HTTP
-   or POP3.  We believe it has three main benefits:
-   o  The ability of EAP to work with backend servers can remove that
-      burden from the application layer.
-   o  Moving the user authentication into the TLS handshake protects the
-      presumably less secure application layer from attacks by
-      unauthenticated parties.
-   o  Using mutual authentication methods within EAP can help thwart
-      certain classes of phishing attacks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 2]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  EAP Applicability  . . . . . . . . . . . . . . . . . . . .  5
-     1.2.  Conventions Used in This Document  . . . . . . . . . . . .  5
-   2.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  6
-   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
-     3.1.  The tee_supported Extension  . . . . . . . . . . . . . . .  8
-     3.2.  The InterimAuth Handshake Message  . . . . . . . . . . . .  8
-     3.3.  The EapMsg Handshake Message . . . . . . . . . . . . . . .  8
-     3.4.  Calculating the Finished message . . . . . . . . . . . . .  9
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     4.1.  InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
-     4.2.  Identity Protection  . . . . . . . . . . . . . . . . . . . 10
-     4.3.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 11
-   5.  Performance Considerations . . . . . . . . . . . . . . . . . . 12
-   6.  Operational Considerations . . . . . . . . . . . . . . . . . . 13
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
-   9.  Changes from Previous Versions . . . . . . . . . . . . . . . . 16
-     9.1.  Changes in version -01 . . . . . . . . . . . . . . . . . . 16
-     9.2.  Changes from the protocol model draft  . . . . . . . . . . 16
-   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 17
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 18
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
-   Intellectual Property and Copyright Statements . . . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 3]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-1.  Introduction
-
-   This document describes a new extension to [TLS].  This extension
-   allows a TLS client to authenticate using [EAP] instead of performing
-   the authentication at the application level.  The extension follows
-   [TLS-EXT].  For the remainder of this document we will refer to this
-   extension as TEE (TLS with EAP Extension).
-
-   TEE extends the TLS handshake beyond the regular setup, to allow the
-   EAP protocol to run between the TLS server (called an "authenticator"
-   in EAP) and the TLS client (called a "supplicant").  This allows the
-   TLS architecture to handle client authentication before exposing the
-   server application software to an unauthenticated client.  In doing
-   this, we follow the approach taken for IKEv2 in [RFC4306].  However,
-   similar to regular TLS, we protect the user identity by only sending
-   the client identity after the server has authenticated.  In this our
-   solution differs from that of IKEv2.
-
-   Currently used applications that rely on non-certificate user
-   credentials use TLS to authenticate the server only.  After that, the
-   application takes over, and presents a login screen where the user is
-   expected to present their credentials.
-
-   This creates several problems.  It allows a client to access the
-   application before authentication, thus creating a potential for
-   anonymous attacks on non-hardened applications.  Additionally, web
-   pages are not particularly well suited for long shared secrets and
-   for interfacing with certain devices such as USB tokens.
-
-   TEE allows full mutual authentication to occur for all these
-   applications within the TLS exchange.  The application receives
-   control only when the user is identified and authenticated.  The
-   authentication can be built into the server infrastructure by
-   connecting to an AAA server.  The client side can be integrated into
-   client software such as web browsers and mail clients.  An EAP
-   infrastructure is already built into some operating systems providing
-   a user interface for each authentication method within EAP.
-
-   We intend TEE to be used for various protocols that use TLS such as
-   HTTPS, in cases where certificate based client authentication is not
-   practical.  This includes web-based mail services, online banking,
-   premium content websites and mail clients.
-
-   Another class of applications that may see benefit from TEE are TLS
-   based VPN clients used as part of so-called "SSL VPN" products.  No
-   such client protocols have so far been standardized.
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 4]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-1.1.  EAP Applicability
-
-   Section 1.3 of [EAP] states that EAP is only applicable for network
-   access authentication, rather than for "bulk data transfer".  It then
-   goes on to explain why the transport properties of EAP indeed make it
-   unsuitable for bulk data transfer, e.g. for large file transport.
-   Our proposed use of EAP falls squarely within the applicability as
-   defined, since we make no further use of EAP beyond access
-   authentication.
-
-1.2.  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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 5]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-2.  Operating Environment
-
-   TEE will work between a client application and a server application,
-   performing either client authentication or mutual authentication
-   within the TLS exchange.
-
-
-        Client                         Server
-    +-------------------------+     +------------------------+
-    |  |GUI| | Client | |TLS+-+-----+-+TLS|   |Server      | |
-    |  +-^-+ |Software| +-^-+ |     +-+-^-+   |Application | |
-    |    |   +--------+   |   |     |   |     |Software    | |
-    |    |                |   |     |   |     +------------+ |
-    |  +-v----------------v-+ |     |   |                    |
-    |  |   EAP              | |     +---|--------------------+
-    |  |  Infrastructure    | |         |
-    |  +--------------------+ |         |    +--------+
-    +-------------------------+         |    | AAA    |
-                                        |    | Server |
-                                        +-----        |
-                                             +--------+
-
-   The above diagram shows the typical deployment.  The client has
-   software that either includes a UI for some EAP methods, or else is
-   able to invoke some operating system EAP infrastructure that takes
-   care of the user interaction.  The server is configured with the
-   address and protocol of the AAA server.  Typically the AAA server
-   communicates using the RADIUS protocol with EAP ([RADIUS] and
-   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
-
-   As stated in the introduction, we expect TEE to be used in both
-   browsers and applications.  Further uses may be authentication and
-   key generation for other protocols, and tunneling clients, which so
-   far have not been standardized.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 6]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-3.  Protocol Overview
-
-   The TEE extension defines the following:
-   o  A new extension type called tee_supported, used to indicate that
-      the communicating application (either client or server) supports
-      this extension.
-   o  A new message type for the handshake protocol, called InterimAuth,
-      which is used to sign previous messages.
-   o  A new message type for the handshake protocol, called EapMsg,
-      which is used to carry a single EAP message.
-
-   The diagram below outlines the protocol structure.  For illustration
-   purposes only, we use the GPSK EAP method [EAP-GPSK].
-
-         Client                                               Server
-         ------                                               ------
-
-         ClientHello(*)             -------->
-                                                      ServerHello(*)
-                                                       (Certificate)
-                                                   ServerKeyExchange
-                                            EapMsg(Identity-Request)
-                                     <--------       ServerHelloDone
-         ClientKeyExchange
-         (CertificateVerify)
-         ChangeCipherSpec
-         InterimAuth
-         EapMsg(Identity-Reply)     -------->
-                                                    ChangeCipherSpec
-                                                         InterimAuth
-                                                EapMsg(GPSK-Request)
-                                    <--------
-         EapMsg(GPSK-Reply)         -------->
-                                                EapMsg(GPSK-Request)
-                                    <--------
-         EapMsg(GPSK-Reply)         -------->
-                                                     EapMsg(Success)
-                                    <--------               Finished
-         Finished                   -------->
-
-       (*) The ClientHello and ServerHello include the tee_supported
-           extension to indicate support for TEE
-
-
-   The client indicates in the first message its support for TEE.  The
-   server sends an EAP identity request in the reply.  The client sends
-   the identity reply after the handshake completion.  The EAP request-
-   response sequence continues until the client is either authenticated
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 7]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-   or rejected.
-
-3.1.  The tee_supported Extension
-
-   The tee_supported extension is a ClientHello and ServerHello
-   extension as defined in section 2.3 of [TLS-EXT].  The extension_type
-   field is TBA by IANA.  The extension_data is zero-length.
-
-3.2.  The InterimAuth Handshake Message
-
-   The InterimAuth message is identical in syntax to the Finished
-   message described in section 7.4.9 of [TLS].  It is calculated in
-   exactly the same way.
-
-   The semantics, however, are somewhat different.  The "Finished"
-   message indicates that application data may now be sent.  The
-   "InterimAuth" message does not indicate this.  Instead, further
-   handshake messages are needed.
-
-   The HandshakeType value for the InterimAuth handshake message is TBA
-   by IANA.
-
-3.3.  The EapMsg Handshake Message
-
-   The EapMsg handshake message carries exactly one EAP message as
-   defined in [EAP].
-
-   The HandshakeType value for the EapMsg handshake message is TBA by
-   IANA.
-
-   The EapMsg message is used to tunnel EAP messages between the
-   authentication server, which may be co-located with the TLS server,
-   or else may be a separate AAA server, and the supplicant, which is
-   co-located with the TLS client.  TLS on either side receives the EAP
-   data from the EAP infrastructure, and treats it as opaque.  TLS does
-   not make any changes to the EAP payload or make any decisions based
-   on the contents of an EapMsg handshake message.
-
-   Note that it is expected that the authentication server notifies the
-   TLS server about authentication success or failure, and so TLS need
-   not inspect the eap_payload within the EapMsg to detect success or
-   failure.
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 8]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-         struct {
-             opaque eap_payload[4..65535];
-         } EapMsg;
-
-         eap_payload is defined in section 4 of RFC 3748. It includes
-         the Code, Identifier, Length and Data fields of the EAP
-         packet.
-
-3.4.  Calculating the Finished message
-
-   If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the
-   Finished message is calculated as follows:
-
-         struct {
-             opaque verify_data[12];
-         } Finished;
-
-         verify_data
-             PRF(MSK, finished_label, MD5(handshake_messages) +
-             SHA-1(handshake_messages)) [0..11];
-
-   The finished_label and the PRF are as defined in section 7.4.9 of
-   [TLS].
-
-   The handshake_messages field, unlike regular TLS, does not sign all
-   the data in the handshake.  Instead it signs all the data that has
-   not been signed by the previous InterimAuth message.  The
-   handshake_messages field includes all of the octets beginning with
-   and including the InterimAuth message, up to but not including this
-   Finished message.  This is the concatenation of all the Handshake
-   structures exchanged thus far, and not yet signed, as defined in
-   section 7.4 of [TLS]and in this document.
-
-   The Master Session Key (MSK) is derived by the AAA server and by the
-   client if the EAP method is key-generating.  On the server-side, it
-   is typically received from the AAA server over the RADIUS or Diameter
-   protocol.  On the client-side, it is passed to TLS by some other
-   method.
-
-   If the EAP method is not key-generating, then the master_secret is
-   used to sign the messages instead of the MSK.  For a discussion on
-   the use of such methods, see Section 4.1.
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008                [Page 9]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-4.  Security Considerations
-
-4.1.  InterimAuth vs. Finished
-
-   In regular TLS, the Finished message provides two functions: it signs
-   all preceding messages, and it signals that application data can now
-   be sent.  In TEE, it only signs those messages that have not yet been
-   signed.
-
-   Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate
-   keys in addition to authenticating clients.  Such methods are said to
-   be resistant to man-in-the-middle (MITM) attacks as discussed in
-   [MITM].  Such methods are called key-generating methods.
-
-   To realize the benefit of such methods, we need to verify the key
-   that was generated within the EAP method.  This is referred to as the
-   MSK in EAP.  In TEE, the InterimAuth message signs all previous
-   messages with the master_secret, just like the Finished message in
-   regular TLS.  The Finished message signs the rest of the messages
-   using the MSK if such exists.  If not, then the messages are signed
-   with the master_secret as in regular TLS.
-
-   The need for signing twice arises from the fact that we need to use
-   both the master_secret and the MSK.  It was possible to use just one
-   Finished record and blend the MSK into the master_secret.  However,
-   this would needlessly complicate the protocol and make security
-   analysis more difficult.  Instead, we have decided to follow the
-   example of IKEv2, where two AUTH payloads are exchanged.
-
-   It should be noted that using non-key-generating methods may expose
-   the client to a MITM attack if the same method and credentials are
-   used in some other situation, in which the EAP is done outside of a
-   protected tunnel with an authenticated server.  Unless it can be
-   determined that the EAP method is never used in such a situation,
-   non-key-generating methods SHOULD NOT be used.  This issue is
-   discussed extensively in [Compound-Authentication].
-
-4.2.  Identity Protection
-
-   Unlike [TLS-PSK], TEE provides identity protection for the client.
-   The client's identity is hidden from a passive eavesdropper using TLS
-   encryption.  Active attacks are discussed in Section 4.3.
-
-   We could save one round-trip by having the client send its identity
-   within the Client Hello message.  This is similar to TLS-PSK.
-   However, we believe that identity protection is a worthy enough goal,
-   so as to justify the extra round-trip.
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 10]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-4.3.  Mutual Authentication
-
-   In order to achieve our security goals, we need to have both the
-   server and the client authenticate.  Client authentication is
-   obviously done using the EAP method.  The server authentication can
-   be done in either of two ways:
-   1.  The client can verify the server certificate.  This may work well
-       depending on the scenario, but implies that the client or its
-       user can recognize the right DN or alternate name, and
-       distinguish it from plausible alternatives.  The introduction to
-       [I.D.Webauth-phishing] shows that at least in HTTPS, this is not
-       always the case.
-   2.  The client can use a mutually authenticated (MA) EAP method such
-       as GPSK.  In this case, server certificate verification does not
-       matter, and the TLS handshake may as well be anonymous.  Note
-       that in this case, the client identity is sent to the server
-       before server authentication.
-
-   To summarize:
-   o  Clients MUST NOT propose anonymous ciphersuites, unless they
-      support MA EAP methods.
-   o  Clients MUST NOT accept non-MA methods if the ciphersuite is
-      anonymous.
-   o  Clients MUST NOT accept non-MA methods if they are not able to
-      verify the server credentials.  Note that this document does not
-      define what verification involves.  If the server DN is known and
-      stored on the client, verifying certificate signature and checking
-      revocation may be enough.  For web browsers, the case is not as
-      clear cut, and MA methods SHOULD be used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 11]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-5.  Performance Considerations
-
-   Regular TLS adds two round-trips to a TCP connection.  However,
-   because of the stream nature of TCP, the client does not really need
-   to wait for the server's Finished message, and can begin sending
-   application data immediately after its own Finished message.  In
-   practice, many clients do so, and TLS only adds one round-trip of
-   delay.
-
-   TEE adds as many round-trips as the EAP method requires.  For
-   example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2
-   round-trips.  Additionally, the client MUST wait for the EAP-Success
-   message before sending its own Finished message, so we need at least
-   3 round-trips for the entire handshake.  The best a client can do is
-   two round-trips plus however many round-trips the EAP method
-   requires.
-
-   It should be noted, though, that these extra round-trips save
-   processing time at the application level.  Two extra round-trips take
-   a lot less time than presenting a log-in web page and processing the
-   user's input.
-
-   It should also be noted, that TEE reverses the order of the Finished
-   messages.  In regular TLS the client sends the Finished message
-   first.  In TEE it is the server that sends the Finished message
-   first.  This should not affect performance, and it is clear that the
-   client may send application data immediately after the Finished
-   message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 12]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-6.  Operational Considerations
-
-   Section 4.3 defines a dependency between the TLS state and the EAP
-   state in that it mandates that certain EAP methods should not be used
-   with certain TLS ciphersuites.  To avoid such dependencies, there are
-   two approaches that implementations can take.  They can either not
-   use any anonymous ciphersuites, or else they can use only MA EAP
-   methods.
-
-   Where certificate validation is problematic, such as in browser-based
-   HTTPS, we recommend the latter approach.
-
-   In cases where the use of EAP within TLS is not known before opening
-   the connection, it is necessary to consider the implications of
-   requiring the user to type in credentials after the connection has
-   already started.  TCP sessions may time out, because of security
-   considerations, and this may lead to session setup failure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 13]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-7.  IANA Considerations
-
-   IANA is asked to assign an extension type value from the
-   "ExtensionType Values" registry for the tee_supported extension.
-
-   IANA is asked to assign two handshake message types from the "TLS
-   HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 14]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-8.  Acknowledgments
-
-   The authors would like to thank Josh Howlett for his comments.
-
-   The TLS Inner Application Extension work ([TLS/IA]) has inspired the
-   authors to create this simplified work.  TLS/IA provides a somewhat
-   different approach to integrating non-certificate credentials into
-   the TLS protocol, in addition to several other features available
-   from the RADIUS namespace.
-
-   The authors would also like to thank the various contributors to
-   [RFC4306] whose work inspired this one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 15]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-9.  Changes from Previous Versions
-
-9.1.  Changes in version -01
-
-   o  Changed the construction of the Finished message
-   o  Replaced MS-CHAPv2 with GPSK in examples.
-   o  Added open issues section.
-   o  Added reference to [Compound-Authentication]
-   o  Fixed reference to MITM attack
-
-9.2.  Changes from the protocol model draft
-
-   o  Added diagram for EapMsg
-   o  Added discussion of EAP applicability
-   o  Added discussion of mutually-authenticated EAP methods vs other
-      methods in the security considerations.
-   o  Added operational considerations.
-   o  Other minor nits.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 16]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-10.  Open Issues
-
-   Some have suggested that since the protocol is identical to regular
-   TLS up to the InterimAuth message, we should call that the Finished
-   message, and call the last message in the extended handshake
-   something like "EapFinished".  This has the advantage that the
-   construction of Finished is already well defined and will not change.
-   However, the Finished message has a specific meaning as indicated by
-   its name.  It means that the handshake is over and that application
-   data can now be sent.  This is not true of what is in this draft
-   called InterimAuth.  We'd like the opinions of reviewrs about this
-   issue.
-
-   The MSK from the EAP exchange is only used to sign the Finished
-   message.  It is not used again in the data encryption.  In this we
-   followed the example of IKEv2.  The reason is that TLS already has
-   perfectly good ways of exchanging keys, and we do not need this
-   capability from EAP methods.  Also, using the MSK in keys would
-   require an additional ChangeCipherSpec and would complicate the
-   protocol.  We'd like the opinions of reviewrs about this issue.
-
-   Another response we got was that we should have a MUST requirement
-   that only mutually authenticated and key-generating methods be used
-   in TEE.  This would simplify the security considerations section.
-   While we agree that this is a good idea, most EAP methods in common
-   use are not compliant.  Additionally, such requirements assume that
-   EAP packets are visible to a passive attacker.  As EAP is used in
-   protected tunnels such as in L2TP, in IKEv2 and here, this assumption
-   may not be required.  If we consider the server authenticated by its
-   certificate, it may be acceptable to use a non-MA method.
-
-   It has been suggested that identity protection is not important
-   enough to add a roundtrip, and so we should have the client send the
-   username in the ClientHello.  We are not sure about how others feel
-   about this, and would like to solicit the reviewers opinion.  Note
-   that if this is done, the client sends the user name before ever
-   receiving any indication that the server actually supports TEE.  This
-   might be acceptable in an email client, where the server is
-   preconfigured, but it may be unacceptable in other uses, such as web
-   browsers.
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 17]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-11.  References
-
-11.1.  Normative References
-
-   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
-              Levkowetz, "Extensible Authentication Protocol (EAP)",
-              RFC 3748, June 2004.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [TLS-EXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-11.2.  Informative References
-
-   [Compound-Authentication]
-              Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
-              "The Compound Authentication Binding Problem",
-              draft-puthenkulam-eap-binding-04 (work in progress),
-              October 2003.
-
-   [Dia-EAP]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
-              Authentication Protocol (EAP) Application", RFC 4072,
-              August 2005.
-
-   [Diameter]
-              Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
-              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
-
-   [EAP-GPSK]
-              Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
-              Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in
-              progress), April 2007.
-
-   [I-D.ietf-eap-keying]
-              Aboba, B., "Extensible Authentication Protocol (EAP) Key
-              Management Framework", draft-ietf-eap-keying-18 (work in
-              progress), February 2007.
-
-   [I.D.Webauth-phishing]
-              Hartman, S., "Requirements for Web Authentication
-              Resistant to Phishing", draft-hartman-webauth-phishing-03
-              (work in progress), March 2007.
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 18]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
-              in Tunneled Authentication Protocols", IACR ePrint
-              Archive , October 2002.
-
-   [RAD-EAP]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
-              Dial In User Service) Support For Extensible
-              Authentication Protocol (EAP)", RFC 3579, September 2003.
-
-   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
-              "Remote Authentication Dial In User Service (RADIUS)",
-              RFC 2865, June 2000.
-
-   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              RFC 4306, December 2005.
-
-   [TLS-PSK]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [TLS/IA]   Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
-              T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
-              draft-funk-tls-inner-application-extension-03 (work in
-              progress), June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 19]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-Authors' Addresses
-
-   Yoav Nir
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: ynir@checkpoint.com
-
-
-   Yaron Sheffer
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: yaronf at checkpoint dot com
-
-
-   Hannes Tschofenig
-   Nokia Siemens Networks
-   Otto-Hahn-Ring 6
-   Munich, Bavaria  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-   URI:   http://www.tschofenig.com
-
-
-   Peter Gutmann
-   University of Auckland
-   Department of Computer Science
-   New Zealand
-
-   Email: pgut001@cs.auckland.ac.nz
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 20]
-
-Internet-Draft                 EAP-in-TLS                      July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Nir, et al.              Expires January 5, 2008               [Page 21]
-
diff --git a/doc/protocol/draft-nir-tls-eap-02.txt b/doc/protocol/draft-nir-tls-eap-02.txt
deleted file mode 100644
index fa56748dc1..0000000000
--- a/doc/protocol/draft-nir-tls-eap-02.txt
+++ /dev/null
@@ -1,1176 +0,0 @@
-
-
-
-TLS Working Group                                                 Y. Nir
-Internet-Draft                                                Y. Sheffer
-Intended status: Standards Track                             Check Point
-Expires: April 16, 2008                                    H. Tschofenig
-                                                                     NSN
-                                                              P. Gutmann
-                                                  University of Auckland
-                                                        October 14, 2007
-
-
-                      TLS using EAP Authentication
-                        draft-nir-tls-eap-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on April 16, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 1]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-Abstract
-
-   This document describes an extension to the TLS protocol to allow TLS
-   clients to authenticate with legacy credentials using the Extensible
-   Authentication Protocol (EAP).
-
-   This work follows the example of IKEv2, where EAP has been added to
-   the IKEv2 protocol to allow clients to use different credentials such
-   as passwords, token cards, and shared secrets.
-
-   When TLS is used with EAP, additional records are sent after the
-   ChangeCipherSpec protocol message and before the Finished message,
-   effectively creating an extended handshake before the application
-   layer data can be sent.  Each EapMsg handshake record contains
-   exactly one EAP message.  Using EAP for client authentication allows
-   TLS to be used with various AAA back-end servers, such as RADIUS or
-   Diameter.
-
-   TLS with EAP may be used for securing a data connection such as HTTP
-   or POP3.  We believe it has three main benefits:
-   o  The ability of EAP to work with backend servers can remove that
-      burden from the application layer.
-   o  Moving the user authentication into the TLS handshake protects the
-      presumably less secure application layer from attacks by
-      unauthenticated parties.
-   o  Using mutual authentication methods within EAP can help thwart
-      certain classes of phishing attacks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 2]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  EAP Applicability  . . . . . . . . . . . . . . . . . . . .  5
-     1.2.  Comparison with Design Alternatives  . . . . . . . . . . .  5
-     1.3.  Conventions Used in This Document  . . . . . . . . . . . .  5
-   2.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  6
-   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
-     3.1.  The tee_supported Extension  . . . . . . . . . . . . . . .  8
-     3.2.  The InterimAuth Handshake Message  . . . . . . . . . . . .  8
-     3.3.  The EapMsg Handshake Message . . . . . . . . . . . . . . .  8
-     3.4.  Calculating the Finished message . . . . . . . . . . . . .  9
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     4.1.  InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
-     4.2.  Identity Protection  . . . . . . . . . . . . . . . . . . . 10
-     4.3.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 11
-   5.  Performance Considerations . . . . . . . . . . . . . . . . . . 12
-   6.  Operational Considerations . . . . . . . . . . . . . . . . . . 13
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
-   9.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 16
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
-   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 19
-     A.1.  Changes from Previous Versions . . . . . . . . . . . . . . 19
-       A.1.1.  Changes in version -02 . . . . . . . . . . . . . . . . 19
-       A.1.2.  Changes in version -01 . . . . . . . . . . . . . . . . 19
-       A.1.3.  Changes from the protocol model draft  . . . . . . . . 19
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
-   Intellectual Property and Copyright Statements . . . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 3]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-1.  Introduction
-
-   This document describes a new extension to [TLS] that allows a TLS
-   client to authenticate using [EAP] instead of performing the
-   authentication at the application layer.  The extension follows
-   [TLS-EXT].  For the remainder of this document we will refer to this
-   extension as TEE (TLS with EAP Extension).
-
-   TEE extends the TLS handshake beyond the regular setup, to allow the
-   EAP protocol to run between the TLS server (called an "authenticator"
-   in EAP) and the TLS client (called a "supplicant").  This allows the
-   TLS architecture to handle client authentication before exposing the
-   server application software to an unauthenticated client.  In doing
-   this, we follow the approach taken for IKEv2 in [RFC4306].  However,
-   similar to regular TLS, we protect the user identity by only sending
-   the client identity after the server has authenticated.  In this our
-   solution differs from that of IKEv2.
-
-   Today, most applications that rely on symmetric credentials use TLS
-   to authenticate the server only.  After that, the application takes
-   over, and presents a login screen where the user is expected to
-   present their credentials.
-
-   This creates several problems.  It allows a client to access the
-   application before authentication, thus creating a potential for
-   anonymous attacks on non-hardened applications.  Additionally, web
-   pages are not particularly well suited for long shared secrets and
-   for interfacing with certain devices such as USB tokens.
-
-   TEE allows full mutual authentication to occur for all these
-   applications within the TLS exchange.  The application receives
-   control only when the user is identified and authenticated.  The
-   authentication can be built into the server infrastructure by
-   connecting to a AAA server.  The client side can be integrated into
-   client software such as web browsers and mail clients.  An EAP
-   infrastructure is already built into major operating systems
-   providing a user interface for each authentication method within EAP.
-
-   We intend TEE to be used for various protocols that use TLS such as
-   HTTPS, in cases where certificate based client authentication is not
-   practical.  This includes web-based mail services, online banking,
-   premium content websites and mail clients.
-
-   Another class of applications that may see benefit from TEE are TLS
-   based VPN clients used as part of so-called "SSL VPN" products.  No
-   such client protocols so far has been standardized.
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 4]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-1.1.  EAP Applicability
-
-   Section 1.3 of [EAP] states that EAP is only applicable for network
-   access authentication, rather than for "bulk data transfer".  It then
-   goes on to explain why the transport properties of EAP indeed make it
-   unsuitable for bulk data transfer, e.g., for large file transport.
-   Our proposed use of EAP falls squarely within the applicability as
-   defined, since we make no further use of EAP beyond access
-   authentication.
-
-1.2.  Comparison with Design Alternatives
-
-   It has been suggested to implement EAP authentication as part of the
-   protected application, rather than as part of the TLS handshake.  A
-   BCP document could be used to describe a secure way of doing this.
-   The drawbacks we see in such an approach are listed below:
-   o  EAP does not have a pre-defined transport method.  Application
-      designers would need to specify an EAP transport for each
-      application.  Making this a part of TLS has the benefit of a
-      single specification for all protected applications.
-   o  The integration of EAP and TLS is security-sensitive and should be
-      standardized and interoperable.  We do not believe that it should
-      be left to application designers to do this in a secure manner.
-      Specifically on the server-side, integration with AAA servers adds
-      complexity and is more naturally part of the underlying
-      infrastrcture.
-   o  Our current proposal provides channel binding between TLS and EAP,
-      to counter the MITM attacks described in [MITM].  A draft for
-      allowing applications the access to keying material produced by
-      TLS is available with [I-D.rescorla-tls-extractor].  This type of
-      interworking between the TLS stack and the application layer is
-      necessary when EAP is run outside the TLS handshake and then the
-      two exchanges need to be linked together.  Since the key extractor
-      functionality is not yet available in TLS stacks it is difficult
-      for application designers to bind the user authentication to the
-      protected channel provided by TLS.
-
-1.3.  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 [RFC2119].
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 5]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-2.  Operating Environment
-
-   TEE will work between a client application and a server application,
-   performing either client authentication or mutual authentication
-   within the TLS exchange.
-
-
-        Client                         Server
-    +-------------------------+     +------------------------+
-    |  |GUI| | Client | |TLS+-+-----+-+TLS|   |Server      | |
-    |  +-^-+ |Software| +-^-+ |     +-+-^-+   |Application | |
-    |    |   +--------+   |   |     |   |     |Software    | |
-    |    |                |   |     |   |     +------------+ |
-    |  +-v----------------v-+ |     |   |                    |
-    |  |   EAP              | |     +---|--------------------+
-    |  |  Infrastructure    | |         |
-    |  +--------------------+ |         |    +--------+
-    +-------------------------+         |    | AAA    |
-                                        |    | Server |
-                                        +-----        |
-                                             +--------+
-
-   The above diagram shows the typical deployment.  The client has
-   software that either includes a UI for some EAP methods, or else is
-   able to invoke some operating system EAP infrastructure that takes
-   care of the user interaction.  The server is configured with the
-   address and protocol of the AAA server.  Typically the AAA server
-   communicates using the RADIUS protocol with EAP ([RADIUS] and
-   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
-
-   As stated in the introduction, we expect TEE to be used in both
-   browsers and applications.  Further uses may be authentication and
-   key generation for other protocols, and tunneling clients, which so
-   far have not been standardized.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 6]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-3.  Protocol Overview
-
-   The TEE extension defines the following:
-   o  A new extension type called tee_supported, used to indicate that
-      the communicating application (either client or server) supports
-      this extension.
-   o  A new message type for the handshake protocol, called InterimAuth,
-      which is used to sign previous messages.
-   o  A new message type for the handshake protocol, called EapMsg,
-      which is used to carry a single EAP message.
-
-   The diagram below outlines the protocol structure.  For illustration
-   purposes only, we use the GPSK EAP method [EAP-GPSK].
-
-         Client                                               Server
-         ------                                               ------
-
-         ClientHello(*)             -------->
-                                                      ServerHello(*)
-                                                       (Certificate)
-                                                   ServerKeyExchange
-                                            EapMsg(Identity-Request)
-                                     <--------       ServerHelloDone
-         ClientKeyExchange
-         (CertificateVerify)
-         ChangeCipherSpec
-         InterimAuth
-         EapMsg(Identity-Reply)     -------->
-                                                    ChangeCipherSpec
-                                                         InterimAuth
-                                                EapMsg(GPSK-Request)
-                                    <--------
-         EapMsg(GPSK-Reply)         -------->
-                                                EapMsg(GPSK-Request)
-                                    <--------
-         EapMsg(GPSK-Reply)         -------->
-                                                     EapMsg(Success)
-                                    <--------               Finished
-         Finished                   -------->
-
-       (*) The ClientHello and ServerHello include the tee_supported
-           extension to indicate support for TEE
-
-
-   The client indicates in the first message its support for TEE.  The
-   server sends an EAP identity request in the reply.  The client sends
-   the identity reply after the handshake completion.  The EAP request-
-   response sequence continues until the client is either authenticated
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 7]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-   or rejected.
-
-3.1.  The tee_supported Extension
-
-   The tee_supported extension is a ClientHello and ServerHello
-   extension as defined in Section 2.3 of [TLS-EXT].  The extension_type
-   field is TBA by IANA.  The extension_data is zero-length.
-
-3.2.  The InterimAuth Handshake Message
-
-   The InterimAuth message is identical in syntax to the Finished
-   message described in Section 7.4.9 of [TLS].  It is calculated in
-   exactly the same way.
-
-   The semantics, however, are somewhat different.  The "Finished"
-   message indicates that application data may now be sent.  The
-   "InterimAuth" message does not indicate this.  Instead, further
-   handshake messages are needed.
-
-   The HandshakeType value for the InterimAuth handshake message is TBA
-   by IANA.
-
-3.3.  The EapMsg Handshake Message
-
-   The EapMsg handshake message carries exactly one EAP message as
-   defined in [EAP].
-
-   The HandshakeType value for the EapMsg handshake message is TBA by
-   IANA.
-
-   The EapMsg message is used to tunnel EAP messages between the
-   authentication server, which may be co-located with the TLS server,
-   or else may be a separate AAA server, and the supplicant, which is
-   co-located with the TLS client.  TLS on either side receives the EAP
-   data from the EAP infrastructure, and treats it as opaque.  TLS does
-   not make any changes to the EAP payload or make any decisions based
-   on the contents of an EapMsg handshake message.
-
-   Note that it is expected that the EAP server notifies the TLS server
-   about authentication success or failure, and TLS does not inspect the
-   eap_payload within the EapMsg to detect success or failure.
-
-         struct {
-             opaque eap_payload[4..65535];
-         } EapMsg;
-
-         eap_payload is defined in section 4 of RFC 3748. It includes
-         the Code, Identifier, Length and Data fields of the EAP
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 8]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-         packet.
-
-3.4.  Calculating the Finished message
-
-   If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the
-   Finished message is calculated as follows:
-
-         struct {
-             opaque verify_data[12];
-         } Finished;
-
-         verify_data
-             PRF(MSK, finished_label, MD5(handshake_messages) +
-             SHA-1(handshake_messages)) [0..11];
-
-   The finished_label and the PRF are as defined in Section 7.4.9 of
-   [TLS].
-
-   The handshake_messages field, unlike regular TLS, does not sign all
-   the data in the handshake.  Instead it signs all the data that has
-   not been signed by the previous InterimAuth message.  The
-   handshake_messages field includes all of the octets beginning with
-   and including the InterimAuth message, up to but not including this
-   Finished message.  This is the concatenation of all the Handshake
-   structures exchanged thus far, and not yet signed, as defined in
-   Section 7.4 of [TLS]and in this document.
-
-   The Master Session Key (MSK) is derived by the AAA server and by the
-   client if the EAP method is key-generating.  On the server-side, it
-   is typically received from the AAA server over the RADIUS or Diameter
-   protocol.  On the client-side, it is passed to TLS by some other
-   method.
-
-   If the EAP method is not key-generating, then the master_secret is
-   used to sign the messages instead of the MSK.  For a discussion on
-   the use of such methods, see Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                 [Page 9]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-4.  Security Considerations
-
-4.1.  InterimAuth vs. Finished
-
-   In regular TLS, the Finished message provides two functions: it signs
-   all preceding messages, and it signals that application data can now
-   be sent.  In TEE, it only signs those messages that have not yet been
-   signed.
-
-   Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate
-   keys in addition to authenticating clients.  Such methods are said to
-   be resistant to man-in-the-middle (MITM) attacks as discussed in
-   [MITM].  Such methods are called key-generating methods.
-
-   To realize the benefit of such methods, we need to verify the key
-   that was generated within the EAP method.  This is referred to as the
-   MSK in EAP.  In TEE, the InterimAuth message signs all previous
-   messages with the master_secret, just like the Finished message in
-   regular TLS.  The Finished message signs the rest of the messages
-   using the MSK if such exists.  If not, then the messages are signed
-   with the master_secret as in regular TLS.
-
-   The need for signing twice arises from the fact that we need to use
-   both the master_secret and the MSK.  It was possible to use just one
-   Finished record and blend the MSK into the master_secret.  However,
-   this would needlessly complicate the protocol and make security
-   analysis more difficult.  Instead, we have decided to follow the
-   example of IKEv2, where two AUTH payloads are exchanged.
-
-   It should be noted that using non-key-generating methods may expose
-   the client to a MITM attack if the same method and credentials are
-   used in some other situation, in which the EAP is done outside of a
-   protected tunnel with an authenticated server.  Unless it can be
-   determined that the EAP method is never used in such a situation,
-   non-key-generating methods SHOULD NOT be used.  This issue is
-   discussed extensively in [Compound-Authentication].
-
-4.2.  Identity Protection
-
-   Unlike [TLS-PSK], TEE provides active user identity confidentiality
-   for the client.  The client's identity is hidden from an active and a
-   passive eavesdropper using the server-side authenticated TLS channel
-   (followed by encryption of the EAP-based handshake messages).  Active
-   attacks are discussed in Section 4.3.
-
-   We could save one round-trip by having the client send its identity
-   within the Client Hello message.  This is similar to TLS-PSK.
-   However, we believe that identity protection is a worthy enough goal,
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 10]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-   so as to justify the extra round-trip.
-
-4.3.  Mutual Authentication
-
-   In order to achieve our security goals, we need to have both the
-   server and the client authenticate.  Client authentication is
-   obviously done using the EAP method.  The server authentication can
-   be done in either of two ways:
-   1.  The client can verify the server certificate.  This may work well
-       depending on the scenario, but implies that the client or its
-       user can recognize the right DN or alternate name, and
-       distinguish it from plausible alternatives.  The introduction to
-       [I.D.Webauth-phishing] shows that at least in HTTPS, this is not
-       always the case.
-   2.  The client can use a mutually authenticated (MA) EAP method such
-       as GPSK.  In this case, server certificate verification does not
-       matter, and the TLS handshake may as well be anonymous.  Note
-       that in this case, the client identity is sent to the server
-       before server authentication.
-
-   To summarize:
-   o  Clients MUST NOT propose anonymous ciphersuites, unless they
-      support MA EAP methods.
-   o  Clients MUST NOT accept non-MA methods if the ciphersuite is
-      anonymous.
-   o  Clients MUST NOT accept non-MA methods if they are not able to
-      verify the server credentials.  Note that this document does not
-      define what verification involves.  If the server DN is known and
-      stored on the client, verifying certificate signature and checking
-      revocation may be enough.  For web browsers, the case is not as
-      clear cut, and MA methods SHOULD be used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 11]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-5.  Performance Considerations
-
-   Regular TLS adds two round-trips to a TCP connection.  However,
-   because of the stream nature of TCP, the client does not really need
-   to wait for the server's Finished message, and can begin sending
-   application data immediately after its own Finished message.  In
-   practice, many clients do so, and TLS only adds one round-trip of
-   delay.
-
-   TEE adds as many round-trips as the EAP method requires.  For
-   example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2
-   round-trips.  Additionally, the client MUST wait for the EAP-Success
-   message before sending its own Finished message, so we need at least
-   3 round-trips for the entire handshake.  The best a client can do is
-   two round-trips plus however many round-trips the EAP method
-   requires.
-
-   It should be noted, though, that these extra round-trips save
-   processing time at the application level.  Two extra round-trips take
-   a lot less time than presenting a log-in web page and processing the
-   user's input.
-
-   It should also be noted, that TEE reverses the order of the Finished
-   messages.  In regular TLS the client sends the Finished message
-   first.  In TEE it is the server that sends the Finished message
-   first.  This should not affect performance, and it is clear that the
-   client may send application data immediately after the Finished
-   message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 12]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-6.  Operational Considerations
-
-   Section 4.3 defines a dependency between the TLS state and the EAP
-   state in that it mandates that certain EAP methods should not be used
-   with certain TLS ciphersuites.  To avoid such dependencies, there are
-   two approaches that implementations can take.  They can either not
-   use any anonymous ciphersuites, or else they can use only MA EAP
-   methods.
-
-   Where certificate validation is problematic, such as in browser-based
-   HTTPS, we recommend the latter approach.
-
-   In cases where the use of EAP within TLS is not known before opening
-   the connection, it is necessary to consider the implications of
-   requiring the user to type in credentials after the connection has
-   already started.  TCP sessions may time out, because of security
-   considerations, and this may lead to session setup failure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 13]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-7.  IANA Considerations
-
-   IANA is asked to assign an extension type value from the
-   "ExtensionType Values" registry for the tee_supported extension.
-
-   IANA is asked to assign two handshake message types from the "TLS
-   HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 14]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-8.  Acknowledgments
-
-   The authors would like to thank Josh Howlett for his comments.
-
-   The TLS Inner Application Extension work ([TLS/IA]) has inspired the
-   authors to create this simplified work.  TLS/IA provides a somewhat
-   different approach to integrating non-certificate credentials into
-   the TLS protocol, in addition to several other features available
-   from the RADIUS namespace.
-
-   The authors would also like to thank the various contributors to
-   [RFC4306] whose work inspired this one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 15]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-9.  Open Issues
-
-   Some have suggested that since the protocol is identical to regular
-   TLS up to the InterimAuth message, we should call that the Finished
-   message, and call the last message in the extended handshake
-   something like "EapFinished".  This has the advantage that the
-   construction of Finished is already well defined and will not change.
-   However, the Finished message has a specific meaning as indicated by
-   its name.  It means that the handshake is over and that application
-   data can now be sent.  This is not true of what is in this draft
-   called InterimAuth.  We would like the opinions of reviewers about
-   this issue.
-
-   The MSK from the EAP exchange is only used to sign the Finished
-   message.  It is not used again in the data encryption.  In this we
-   followed the example of IKEv2.  The reason is that TLS already has
-   perfectly good ways of exchanging keys, and we do not need this
-   capability from EAP methods.  Also, using the MSK in keys would
-   require an additional ChangeCipherSpec and would complicate the
-   protocol.  We would like the opinions of reviewers about this issue.
-
-   Another response we got was that we should have a MUST requirement
-   that only mutually authenticated and key generating methods be used
-   in TEE.  This would simplify the security considerations section.
-   While we agree that this is a good idea, most EAP methods in common
-   use are not compliant.  Additionally, such requirements assume that
-   EAP packets are visible to a passive attacker.  As EAP is used in
-   protected tunnels such as in L2TP, in IKEv2 and here, this assumption
-   may not be required.  If we consider the server authenticated by its
-   certificate, it may be acceptable to use a non-MA method.
-
-   It has been suggested that identity protection is not important
-   enough to add a roundtrip, and so we should have the client send the
-   username in the ClientHello.  We are not sure about how others feel
-   about this, and would like to solicit the reviewers opinion.  Note
-   that if this is done, the client sends the user name before ever
-   receiving any indication that the server actually supports TEE.  This
-   might be acceptable in an email client, where the server is
-   preconfigured, but it may be unacceptable in other uses, such as web
-   browsers.
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 16]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-10.  References
-
-10.1.  Normative References
-
-   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
-              Levkowetz, "Extensible Authentication Protocol (EAP)",
-              RFC 3748, June 2004.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [TLS-EXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-10.2.  Informative References
-
-   [Compound-Authentication]
-              Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
-              "The Compound Authentication Binding Problem",
-              draft-puthenkulam-eap-binding-04 (work in progress),
-              October 2003.
-
-   [Dia-EAP]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
-              Authentication Protocol (EAP) Application", RFC 4072,
-              August 2005.
-
-   [Diameter]
-              Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
-              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
-
-   [EAP-GPSK]
-              Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
-              Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in
-              progress), April 2007.
-
-   [I-D.ietf-eap-keying]
-              Aboba, B., "Extensible Authentication Protocol (EAP) Key
-              Management Framework", draft-ietf-eap-keying-18 (work in
-              progress), February 2007.
-
-   [I-D.rescorla-tls-extractor]
-              Rescorla, E., "Keying Material Extractors for Transport
-              Layer Security (TLS)", draft-rescorla-tls-extractor-00
-              (work in progress), January 2007.
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 17]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-   [I.D.Webauth-phishing]
-              Hartman, S., "Requirements for Web Authentication
-              Resistant to Phishing", draft-hartman-webauth-phishing-03
-              (work in progress), March 2007.
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
-              in Tunneled Authentication Protocols", IACR ePrint
-              Archive , October 2002.
-
-   [RAD-EAP]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
-              Dial In User Service) Support For Extensible
-              Authentication Protocol (EAP)", RFC 3579, September 2003.
-
-   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
-              "Remote Authentication Dial In User Service (RADIUS)",
-              RFC 2865, June 2000.
-
-   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              RFC 4306, December 2005.
-
-   [TLS-PSK]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [TLS/IA]   Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
-              T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
-              draft-funk-tls-inner-application-extension-03 (work in
-              progress), June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 18]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-Appendix A.  Change History
-
-A.1.  Changes from Previous Versions
-
-A.1.1.  Changes in version -02
-
-   o  Added discussion of alternative designs.
-
-A.1.2.  Changes in version -01
-
-   o  Changed the construction of the Finished message
-   o  Replaced MS-CHAPv2 with GPSK in examples.
-   o  Added open issues section.
-   o  Added reference to [Compound-Authentication]
-   o  Fixed reference to MITM attack
-
-A.1.3.  Changes from the protocol model draft
-
-   o  Added diagram for EapMsg
-   o  Added discussion of EAP applicability
-   o  Added discussion of mutually-authenticated EAP methods vs other
-      methods in the security considerations.
-   o  Added operational considerations.
-   o  Other minor nits.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 19]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-Authors' Addresses
-
-   Yoav Nir
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: ynir@checkpoint.com
-
-
-   Yaron Sheffer
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: yaronf@checkpoint.com
-
-
-   Hannes Tschofenig
-   Nokia Siemens Networks
-   Otto-Hahn-Ring 6
-   Munich, Bavaria  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-   URI:   http://www.tschofenig.com
-
-
-   Peter Gutmann
-   University of Auckland
-   Department of Computer Science
-   New Zealand
-
-   Email: pgut001@cs.auckland.ac.nz
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 20]
-
-Internet-Draft                 EAP-in-TLS                   October 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Nir, et al.              Expires April 16, 2008                [Page 21]
-
diff --git a/doc/protocol/draft-nir-tls-eap-03.txt b/doc/protocol/draft-nir-tls-eap-03.txt
deleted file mode 100644
index 5415134610..0000000000
--- a/doc/protocol/draft-nir-tls-eap-03.txt
+++ /dev/null
@@ -1,1176 +0,0 @@
-
-
-
-TLS Working Group                                                 Y. Nir
-Internet-Draft                                                Y. Sheffer
-Intended status: Standards Track                             Check Point
-Expires: October 6, 2008                                   H. Tschofenig
-                                                                     NSN
-                                                              P. Gutmann
-                                                  University of Auckland
-                                                           April 4, 2008
-
-
-                      TLS using EAP Authentication
-                        draft-nir-tls-eap-03.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 6, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 1]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-Abstract
-
-   This document describes an extension to the TLS protocol to allow TLS
-   clients to authenticate with legacy credentials using the Extensible
-   Authentication Protocol (EAP).
-
-   This work follows the example of IKEv2, where EAP has been added to
-   the IKEv2 protocol to allow clients to use different credentials such
-   as passwords, token cards, and shared secrets.
-
-   When TLS is used with EAP, additional records are sent after the
-   ChangeCipherSpec protocol message and before the Finished message,
-   effectively creating an extended handshake before the application
-   layer data can be sent.  Each EapMsg handshake record contains
-   exactly one EAP message.  Using EAP for client authentication allows
-   TLS to be used with various AAA back-end servers such as RADIUS or
-   Diameter.
-
-   TLS with EAP may be used for securing a data connection such as HTTP
-   or POP3.  We believe it has three main benefits:
-   o  The ability of EAP to work with backend servers can remove that
-      burden from the application layer.
-   o  Moving the user authentication into the TLS handshake protects the
-      presumably less secure application layer from attacks by
-      unauthenticated parties.
-   o  Using mutual authentication methods within EAP can help thwart
-      certain classes of phishing attacks.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 2]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  EAP Applicability  . . . . . . . . . . . . . . . . . . . .  5
-     1.2.  Comparison with Design Alternatives  . . . . . . . . . . .  5
-     1.3.  Conventions Used in This Document  . . . . . . . . . . . .  5
-   2.  Operating Environment  . . . . . . . . . . . . . . . . . . . .  6
-   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  7
-     3.1.  The tee_supported Extension  . . . . . . . . . . . . . . .  8
-     3.2.  The InterimAuth Handshake Message  . . . . . . . . . . . .  8
-     3.3.  The EapMsg Handshake Message . . . . . . . . . . . . . . .  8
-     3.4.  Calculating the Finished message . . . . . . . . . . . . .  9
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     4.1.  InterimAuth vs. Finished . . . . . . . . . . . . . . . . . 10
-     4.2.  Identity Protection  . . . . . . . . . . . . . . . . . . . 10
-     4.3.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 11
-   5.  Performance Considerations . . . . . . . . . . . . . . . . . . 12
-   6.  Operational Considerations . . . . . . . . . . . . . . . . . . 13
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
-   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
-   9.  Changes from Previous Versions . . . . . . . . . . . . . . . . 16
-     9.1.  Changes in version -02 . . . . . . . . . . . . . . . . . . 16
-     9.2.  Changes in version -01 . . . . . . . . . . . . . . . . . . 16
-     9.3.  Changes from the protocol model draft  . . . . . . . . . . 16
-   10. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 17
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 18
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
-   Intellectual Property and Copyright Statements . . . . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 3]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-1.  Introduction
-
-   This document describes a new extension to [TLS].  This extension
-   allows a TLS client to authenticate using [EAP] instead of performing
-   the authentication at the application level.  The extension follows
-   [TLS-EXT].  For the remainder of this document we will refer to this
-   extension as TEE (TLS with EAP Extension).
-
-   TEE extends the TLS handshake beyond the regular setup, to allow the
-   EAP protocol to run between the TLS server (called an "authenticator"
-   in EAP) and the TLS client (called a "supplicant").  This allows the
-   TLS architecture to handle client authentication before exposing the
-   server application software to an unauthenticated client.  In doing
-   this, we follow the approach taken for IKEv2 in [RFC4306].  However,
-   similar to regular TLS, we protect the user identity by only sending
-   the client identity after the server has authenticated.  In this our
-   solution differs from that of IKEv2.
-
-   Currently used applications that rely on non-certificate user
-   credentials use TLS to authenticate the server only.  After that, the
-   application takes over, and presents a login screen where the user is
-   expected to present their credentials.
-
-   This creates several problems.  It allows a client to access the
-   application before authentication, thus creating a potential for
-   anonymous attacks on non-hardened applications.  Additionally, web
-   pages are not particularly well suited for long shared secrets and
-   for interfacing with certain devices such as USB tokens.
-
-   TEE allows full mutual authentication to occur for all these
-   applications within the TLS exchange.  The application receives
-   control only when the user is identified and authenticated.  The
-   authentication can be built into the server infrastructure by
-   connecting to an AAA server.  The client side can be integrated into
-   client software such as web browsers and mail clients.  An EAP
-   infrastructure is already built into some operating systems providing
-   a user interface for each authentication method within EAP.
-
-   We intend TEE to be used for various protocols that use TLS such as
-   HTTPS, in cases where certificate based client authentication is not
-   practical.  This includes web-based mail services, online banking,
-   premium content websites and mail clients.
-
-   Another class of applications that may see benefit from TEE are TLS
-   based VPN clients used as part of so-called "SSL VPN" products.  No
-   such client protocols have so far been standardized.
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 4]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-1.1.  EAP Applicability
-
-   Section 1.3 of [EAP] states that EAP is only applicable for network
-   access authentication, rather than for "bulk data transfer".  It then
-   goes on to explain why the transport properties of EAP indeed make it
-   unsuitable for bulk data transfer, e.g. for large file transport.
-   Our proposed use of EAP falls squarely within the applicability as
-   defined, since we make no further use of EAP beyond access
-   authentication.
-
-1.2.  Comparison with Design Alternatives
-
-   It has been suggested to implement EAP authentication as part of the
-   protected application, rather than as part of the TLS handshake.  A
-   BCP document could be used to describe a secure way of doing this.
-   The drawbacks we see in such an approach are listed below:
-   o  EAP does not have a pre-defined transport method.  Application
-      designers would need to specify an EAP transport for each
-      application.  Making this a part of TLS has the benefit of a
-      single specification for all protected applications.
-   o  The integration of EAP and TLS is security-sensitive and should be
-      standardized and interoperable.  We do not believe that it should
-      be left to application designers to do this in a secure manner.
-      Specifically on the server-side, integration with AAA servers adds
-      complexity and is more naturally part of the underlying
-      infrastrcture.
-   o  Our current proposal provides channel binding between TLS and EAP,
-      to counter the MITM attacks described in [MITM].  TLS does not
-      provide any standard way of extracting cryptographic material from
-      the TLS state, and in most implementations, the TLS state is not
-      exposed to the protected application.  Because of this, it is
-      difficult for application designers to bind the user
-      authentication to the protected channel provided by TLS.
-
-1.3.  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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 5]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-2.  Operating Environment
-
-   TEE will work between a client application and a server application,
-   performing either client authentication or mutual authentication
-   within the TLS exchange.
-
-
-        Client                         Server
-    +-------------------------+     +------------------------+
-    |  |GUI| | Client | |TLS+-+-----+-+TLS|   |Server      | |
-    |  +-^-+ |Software| +-^-+ |     +-+-^-+   |Application | |
-    |    |   +--------+   |   |     |   |     |Software    | |
-    |    |                |   |     |   |     +------------+ |
-    |  +-v----------------v-+ |     |   |                    |
-    |  |   EAP              | |     +---|--------------------+
-    |  |  Infrastructure    | |         |
-    |  +--------------------+ |         |    +--------+
-    +-------------------------+         |    | AAA    |
-                                        |    | Server |
-                                        +-----        |
-                                             +--------+
-
-   The above diagram shows the typical deployment.  The client has
-   software that either includes a UI for some EAP methods, or else is
-   able to invoke some operating system EAP infrastructure that takes
-   care of the user interaction.  The server is configured with the
-   address and protocol of the AAA server.  Typically the AAA server
-   communicates using the RADIUS protocol with EAP ([RADIUS] and
-   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
-
-   As stated in the introduction, we expect TEE to be used in both
-   browsers and applications.  Further uses may be authentication and
-   key generation for other protocols, and tunneling clients, which so
-   far have not been standardized.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 6]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-3.  Protocol Overview
-
-   The TEE extension defines the following:
-   o  A new extension type called tee_supported, used to indicate that
-      the communicating application (either client or server) supports
-      this extension.
-   o  A new message type for the handshake protocol, called InterimAuth,
-      which is used to sign previous messages.
-   o  A new message type for the handshake protocol, called EapMsg,
-      which is used to carry a single EAP message.
-
-   The diagram below outlines the protocol structure.  For illustration
-   purposes only, we use the GPSK EAP method [EAP-GPSK].
-
-         Client                                               Server
-         ------                                               ------
-
-         ClientHello(*)             -------->
-                                                      ServerHello(*)
-                                                       (Certificate)
-                                                   ServerKeyExchange
-                                            EapMsg(Identity-Request)
-                                     <--------       ServerHelloDone
-         ClientKeyExchange
-         (CertificateVerify)
-         ChangeCipherSpec
-         InterimAuth
-         EapMsg(Identity-Reply)     -------->
-                                                    ChangeCipherSpec
-                                                         InterimAuth
-                                                EapMsg(GPSK-Request)
-                                    <--------
-         EapMsg(GPSK-Reply)         -------->
-                                                EapMsg(GPSK-Request)
-                                    <--------
-         EapMsg(GPSK-Reply)         -------->
-                                                     EapMsg(Success)
-                                    <--------               Finished
-         Finished                   -------->
-
-       (*) The ClientHello and ServerHello include the tee_supported
-           extension to indicate support for TEE
-
-
-   The client indicates in the first message its support for TEE.  The
-   server sends an EAP identity request in the reply.  The client sends
-   the identity reply after the handshake completion.  The EAP request-
-   response sequence continues until the client is either authenticated
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 7]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-   or rejected.
-
-3.1.  The tee_supported Extension
-
-   The tee_supported extension is a ClientHello and ServerHello
-   extension as defined in section 2.3 of [TLS-EXT].  The extension_type
-   field is TBA by IANA.  The extension_data is zero-length.
-
-3.2.  The InterimAuth Handshake Message
-
-   The InterimAuth message is identical in syntax to the Finished
-   message described in section 7.4.9 of [TLS].  It is calculated in
-   exactly the same way.
-
-   The semantics, however, are somewhat different.  The "Finished"
-   message indicates that application data may now be sent.  The
-   "InterimAuth" message does not indicate this.  Instead, further
-   handshake messages are needed.
-
-   The HandshakeType value for the InterimAuth handshake message is TBA
-   by IANA.
-
-3.3.  The EapMsg Handshake Message
-
-   The EapMsg handshake message carries exactly one EAP message as
-   defined in [EAP].
-
-   The HandshakeType value for the EapMsg handshake message is TBA by
-   IANA.
-
-   The EapMsg message is used to tunnel EAP messages between the
-   authentication server, which may be co-located with the TLS server,
-   or else may be a separate AAA server, and the supplicant, which is
-   co-located with the TLS client.  TLS on either side receives the EAP
-   data from the EAP infrastructure, and treats it as opaque.  TLS does
-   not make any changes to the EAP payload or make any decisions based
-   on the contents of an EapMsg handshake message.
-
-   Note that it is expected that the authentication server notifies the
-   TLS server about authentication success or failure, and so TLS need
-   not inspect the eap_payload within the EapMsg to detect success or
-   failure.
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 8]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-         struct {
-             opaque eap_payload[4..65535];
-         } EapMsg;
-
-         eap_payload is defined in section 4 of RFC 3748. It includes
-         the Code, Identifier, Length and Data fields of the EAP
-         packet.
-
-3.4.  Calculating the Finished message
-
-   If the EAP method is key-generating (see [I-D.ietf-eap-keying]), the
-   Finished message is calculated as follows:
-
-         struct {
-             opaque verify_data[12];
-         } Finished;
-
-         verify_data
-             PRF(MSK, finished_label, MD5(handshake_messages) +
-             SHA-1(handshake_messages)) [0..11];
-
-   The finished_label and the PRF are as defined in section 7.4.9 of
-   [TLS].
-
-   The handshake_messages field, unlike regular TLS, does not sign all
-   the data in the handshake.  Instead it signs all the data that has
-   not been signed by the previous InterimAuth message.  The
-   handshake_messages field includes all of the octets beginning with
-   and including the InterimAuth message, up to but not including this
-   Finished message.  This is the concatenation of all the Handshake
-   structures exchanged thus far, and not yet signed, as defined in
-   section 7.4 of [TLS]and in this document.
-
-   The Master Session Key (MSK) is derived by the AAA server and by the
-   client if the EAP method is key-generating.  On the server-side, it
-   is typically received from the AAA server over the RADIUS or Diameter
-   protocol.  On the client-side, it is passed to TLS by some other
-   method.
-
-   If the EAP method is not key-generating, then the master_secret is
-   used to sign the messages instead of the MSK.  For a discussion on
-   the use of such methods, see Section 4.1.
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008                [Page 9]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-4.  Security Considerations
-
-4.1.  InterimAuth vs. Finished
-
-   In regular TLS, the Finished message provides two functions: it signs
-   all preceding messages, and it signals that application data can now
-   be sent.  In TEE, it only signs those messages that have not yet been
-   signed.
-
-   Some EAP methods, such as EAP-TLS, EAP-IKEv2 and EAP-SIM generate
-   keys in addition to authenticating clients.  Such methods are said to
-   be resistant to man-in-the-middle (MITM) attacks as discussed in
-   [MITM].  Such methods are called key-generating methods.
-
-   To realize the benefit of such methods, we need to verify the key
-   that was generated within the EAP method.  This is referred to as the
-   MSK in EAP.  In TEE, the InterimAuth message signs all previous
-   messages with the master_secret, just like the Finished message in
-   regular TLS.  The Finished message signs the rest of the messages
-   using the MSK if such exists.  If not, then the messages are signed
-   with the master_secret as in regular TLS.
-
-   The need for signing twice arises from the fact that we need to use
-   both the master_secret and the MSK.  It was possible to use just one
-   Finished record and blend the MSK into the master_secret.  However,
-   this would needlessly complicate the protocol and make security
-   analysis more difficult.  Instead, we have decided to follow the
-   example of IKEv2, where two AUTH payloads are exchanged.
-
-   It should be noted that using non-key-generating methods may expose
-   the client to a MITM attack if the same method and credentials are
-   used in some other situation, in which the EAP is done outside of a
-   protected tunnel with an authenticated server.  Unless it can be
-   determined that the EAP method is never used in such a situation,
-   non-key-generating methods SHOULD NOT be used.  This issue is
-   discussed extensively in [Compound-Authentication].
-
-4.2.  Identity Protection
-
-   Unlike [TLS-PSK], TEE provides identity protection for the client.
-   The client's identity is hidden from a passive eavesdropper using TLS
-   encryption.  Active attacks are discussed in Section 4.3.
-
-   We could save one round-trip by having the client send its identity
-   within the Client Hello message.  This is similar to TLS-PSK.
-   However, we believe that identity protection is a worthy enough goal,
-   so as to justify the extra round-trip.
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 10]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-4.3.  Mutual Authentication
-
-   In order to achieve our security goals, we need to have both the
-   server and the client authenticate.  Client authentication is
-   obviously done using the EAP method.  The server authentication can
-   be done in either of two ways:
-   1.  The client can verify the server certificate.  This may work well
-       depending on the scenario, but implies that the client or its
-       user can recognize the right DN or alternate name, and
-       distinguish it from plausible alternatives.  The introduction to
-       [I.D.Webauth-phishing] shows that at least in HTTPS, this is not
-       always the case.
-   2.  The client can use a mutually authenticated (MA) EAP method such
-       as GPSK.  In this case, server certificate verification does not
-       matter, and the TLS handshake may as well be anonymous.  Note
-       that in this case, the client identity is sent to the server
-       before server authentication.
-
-   To summarize:
-   o  Clients MUST NOT propose anonymous ciphersuites, unless they
-      support MA EAP methods.
-   o  Clients MUST NOT accept non-MA methods if the ciphersuite is
-      anonymous.
-   o  Clients MUST NOT accept non-MA methods if they are not able to
-      verify the server credentials.  Note that this document does not
-      define what verification involves.  If the server DN is known and
-      stored on the client, verifying certificate signature and checking
-      revocation may be enough.  For web browsers, the case is not as
-      clear cut, and MA methods SHOULD be used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 11]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-5.  Performance Considerations
-
-   Regular TLS adds two round-trips to a TCP connection.  However,
-   because of the stream nature of TCP, the client does not really need
-   to wait for the server's Finished message, and can begin sending
-   application data immediately after its own Finished message.  In
-   practice, many clients do so, and TLS only adds one round-trip of
-   delay.
-
-   TEE adds as many round-trips as the EAP method requires.  For
-   example, EAP-MD5 requires 1 round-trip, while EAP-GPSK requires 2
-   round-trips.  Additionally, the client MUST wait for the EAP-Success
-   message before sending its own Finished message, so we need at least
-   3 round-trips for the entire handshake.  The best a client can do is
-   two round-trips plus however many round-trips the EAP method
-   requires.
-
-   It should be noted, though, that these extra round-trips save
-   processing time at the application level.  Two extra round-trips take
-   a lot less time than presenting a log-in web page and processing the
-   user's input.
-
-   It should also be noted, that TEE reverses the order of the Finished
-   messages.  In regular TLS the client sends the Finished message
-   first.  In TEE it is the server that sends the Finished message
-   first.  This should not affect performance, and it is clear that the
-   client may send application data immediately after the Finished
-   message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 12]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-6.  Operational Considerations
-
-   Section 4.3 defines a dependency between the TLS state and the EAP
-   state in that it mandates that certain EAP methods should not be used
-   with certain TLS ciphersuites.  To avoid such dependencies, there are
-   two approaches that implementations can take.  They can either not
-   use any anonymous ciphersuites, or else they can use only MA EAP
-   methods.
-
-   Where certificate validation is problematic, such as in browser-based
-   HTTPS, we recommend the latter approach.
-
-   In cases where the use of EAP within TLS is not known before opening
-   the connection, it is necessary to consider the implications of
-   requiring the user to type in credentials after the connection has
-   already started.  TCP sessions may time out, because of security
-   considerations, and this may lead to session setup failure.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 13]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-7.  IANA Considerations
-
-   IANA is asked to assign an extension type value from the
-   "ExtensionType Values" registry for the tee_supported extension.
-
-   IANA is asked to assign two handshake message types from the "TLS
-   HandshakeType Registry", one for "EapMsg" and one for "InterimAuth".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 14]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-8.  Acknowledgments
-
-   The authors would like to thank Josh Howlett for his comments.
-
-   The TLS Inner Application Extension work ([TLS/IA]) has inspired the
-   authors to create this simplified work.  TLS/IA provides a somewhat
-   different approach to integrating non-certificate credentials into
-   the TLS protocol, in addition to several other features available
-   from the RADIUS namespace.
-
-   The authors would also like to thank the various contributors to
-   [RFC4306] whose work inspired this one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 15]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-9.  Changes from Previous Versions
-
-9.1.  Changes in version -02
-
-   o  Added discussion of alternative designs.
-
-9.2.  Changes in version -01
-
-   o  Changed the construction of the Finished message
-   o  Replaced MS-CHAPv2 with GPSK in examples.
-   o  Added open issues section.
-   o  Added reference to [Compound-Authentication]
-   o  Fixed reference to MITM attack
-
-9.3.  Changes from the protocol model draft
-
-   o  Added diagram for EapMsg
-   o  Added discussion of EAP applicability
-   o  Added discussion of mutually-authenticated EAP methods vs other
-      methods in the security considerations.
-   o  Added operational considerations.
-   o  Other minor nits.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 16]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-10.  Open Issues
-
-   Some have suggested that since the protocol is identical to regular
-   TLS up to the InterimAuth message, we should call that the Finished
-   message, and call the last message in the extended handshake
-   something like "EapFinished".  This has the advantage that the
-   construction of Finished is already well defined and will not change.
-   However, the Finished message has a specific meaning as indicated by
-   its name.  It means that the handshake is over and that application
-   data can now be sent.  This is not true of what is in this draft
-   called InterimAuth.  We'd like the opinions of reviewrs about this
-   issue.
-
-   The MSK from the EAP exchange is only used to sign the Finished
-   message.  It is not used again in the data encryption.  In this we
-   followed the example of IKEv2.  The reason is that TLS already has
-   perfectly good ways of exchanging keys, and we do not need this
-   capability from EAP methods.  Also, using the MSK in keys would
-   require an additional ChangeCipherSpec and would complicate the
-   protocol.  We'd like the opinions of reviewrs about this issue.
-
-   Another response we got was that we should have a MUST requirement
-   that only mutually authenticated and key-generating methods be used
-   in TEE.  This would simplify the security considerations section.
-   While we agree that this is a good idea, most EAP methods in common
-   use are not compliant.  Additionally, such requirements assume that
-   EAP packets are visible to a passive attacker.  As EAP is used in
-   protected tunnels such as in L2TP, in IKEv2 and here, this assumption
-   may not be required.  If we consider the server authenticated by its
-   certificate, it may be acceptable to use a non-MA method.
-
-   It has been suggested that identity protection is not important
-   enough to add a roundtrip, and so we should have the client send the
-   username in the ClientHello.  We are not sure about how others feel
-   about this, and would like to solicit the reviewers opinion.  Note
-   that if this is done, the client sends the user name before ever
-   receiving any indication that the server actually supports TEE.  This
-   might be acceptable in an email client, where the server is
-   preconfigured, but it may be unacceptable in other uses, such as web
-   browsers.
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 17]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-11.  References
-
-11.1.  Normative References
-
-   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
-              Levkowetz, "Extensible Authentication Protocol (EAP)",
-              RFC 3748, June 2004.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]      Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [TLS-EXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-11.2.  Informative References
-
-   [Compound-Authentication]
-              Puthenkulam, J., Lortz, V., Palekar, A., and D. Simon,
-              "The Compound Authentication Binding Problem",
-              draft-puthenkulam-eap-binding-04 (work in progress),
-              October 2003.
-
-   [Dia-EAP]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
-              Authentication Protocol (EAP) Application", RFC 4072,
-              August 2005.
-
-   [Diameter]
-              Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
-              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
-
-   [EAP-GPSK]
-              Clancy, T. and H. Tschofenig, "EAP Generalized Pre-Shared
-              Key (EAP-GPSK)", draft-ietf-emu-eap-gpsk-05 (work in
-              progress), April 2007.
-
-   [I-D.ietf-eap-keying]
-              Aboba, B., "Extensible Authentication Protocol (EAP) Key
-              Management Framework", draft-ietf-eap-keying-18 (work in
-              progress), February 2007.
-
-   [I.D.Webauth-phishing]
-              Hartman, S., "Requirements for Web Authentication
-              Resistant to Phishing", draft-hartman-webauth-phishing-03
-              (work in progress), March 2007.
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 18]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-   [MITM]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
-              in Tunneled Authentication Protocols", IACR ePrint
-              Archive , October 2002.
-
-   [RAD-EAP]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
-              Dial In User Service) Support For Extensible
-              Authentication Protocol (EAP)", RFC 3579, September 2003.
-
-   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
-              "Remote Authentication Dial In User Service (RADIUS)",
-              RFC 2865, June 2000.
-
-   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              RFC 4306, December 2005.
-
-   [TLS-PSK]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [TLS/IA]   Funk, P., Blake-Wilson, S., Smith, H., Tschofenig, N., and
-              T. Hardjono, "TLS Inner Application Extension (TLS/IA)",
-              draft-funk-tls-inner-application-extension-03 (work in
-              progress), June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 19]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-Authors' Addresses
-
-   Yoav Nir
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: ynir@checkpoint.com
-
-
-   Yaron Sheffer
-   Check Point Software Technologies Ltd.
-   5 Hasolelim st.
-   Tel Aviv  67897
-   Israel
-
-   Email: yaronf at checkpoint dot com
-
-
-   Hannes Tschofenig
-   Nokia Siemens Networks
-   Otto-Hahn-Ring 6
-   Munich, Bavaria  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-   URI:   http://www.tschofenig.com
-
-
-   Peter Gutmann
-   University of Auckland
-   Department of Computer Science
-   New Zealand
-
-   Email: pgut001@cs.auckland.ac.nz
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 20]
-
-Internet-Draft                 EAP-in-TLS                     April 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Nir, et al.              Expires October 6, 2008               [Page 21]
-
diff --git a/doc/protocol/draft-otto-tls-sigma-ciphersuite-00.txt b/doc/protocol/draft-otto-tls-sigma-ciphersuite-00.txt
deleted file mode 100644
index 0bf5ab2ef0..0000000000
--- a/doc/protocol/draft-otto-tls-sigma-ciphersuite-00.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-TLS Working Group                                                T. Otto
-Internet-Draft                                            April 27, 2007
-Intended status: Standards Track
-Expires: October 29, 2007
-
-
-                  A Privacy-enhancing TLS ciphersuite
-                draft-otto-tls-sigma-ciphersuite-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 29, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007                [Page 1]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-Abstract
-
-   This document describes a TLS ciphersuite which is based on the SIGMA
-   protocol.  By its careful adoption in the TLS handshake protocol, the
-   proposed ciphersuite is able to inherit features of the SIGMA
-   protocol.  The ciphersuite provides active identity protection,
-   forward secrecy, deniability and adjustable security strength.  A
-   similar ciphersuite offering these features has not yet been proposed
-   so far.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  TLS and its handshake protocol . . . . . . . . . . . . . .  4
-     1.2.  The SIGMA protocol . . . . . . . . . . . . . . . . . . . .  5
-     1.3.  Requirements notation  . . . . . . . . . . . . . . . . . .  6
-     1.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
-   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
-   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
-     6.2.  Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007                [Page 2]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-1.  Introduction
-
-   This document specifies such a new ciphersuite, which encapsulates
-   the SIGMA protocol [SIGMA] into the TLS handshake messages and
-   therefore inherits its valueable features.  Further information about
-   SIGMA can be found on the author's website, which is
-   http://www.ee.technion.ac.il/~hugo/sigma.html
-
-   In the remainder of this document, we use the term TLS-SIGMA for our
-   proposal.
-
-   TLS-SIGMA offers
-
-   Forward Secrecy:
-
-      This is achieved by the authenticated Diffie-Hellman key exchange
-      which is the cryptographic core of the SIGMA protocol.
-
-   Adjustability:
-
-      The cryptographic strength is determined by the choice of the
-      Diffie-Hellman group.  We call this feature adjustable security
-      strength.
-
-   Active Identity Protection:
-
-      The Identity of the Client is protected against active attacks.
-      This is achieved because the server autenticates prior to the
-      client.  Only if the client could identity the server properly, he
-      sends his identity.
-
-   Deniability:
-
-      In contrast to many other ciphersuites, the conversation between
-      client and server is deniable, in the sense, that by carrying out
-      the TLS-SIGMA handshake, there exists no proof for the server
-      having talked to the client, at least none which can withstand at
-      a court, and vice versa.
-
-
-   One might argue that there already exist numerous TLS ciphersuites
-   with a DH key exchange, for example TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
-   and ask where the particular advantages of this ciphersuite are.
-
-   The crucial point is that with RSA as key exchange mechanism and the
-   mutual authentication case, the client computes in CertificateVerify
-   a signature over all handshake messages (see Section 7.4.8 of
-   [RFC2246]), that is
-
-
-
-Otto                    Expires October 29, 2007                [Page 3]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-   CertificateVerify = SIG(Client; g^x, g^y, CertServer, CertClient)
-
-   and thus provides an undeniable proof that the conversation has taken
-   place.
-
-1.1.  TLS and its handshake protocol
-
-   TLS has its origin in the SSL protocol developed by Netscape
-   Communications in early 1990s.  In the meantime, it became the major
-   protocol to establish a cryptographially protected context between
-   two communicating parties.
-
-   One of the most valuable features of TLS is its flexibility in that
-   initially, both sides agree on a set of cryptographic algorithms, a
-   so-called ciphersuite.  Such a ciphersuite comprises an algorithm for
-   authentiation and key exchange, a stream or block cipher for bulk
-   encryption and finally, an algorithm for hashing.
-
-   While SSL realized this flexibility by a complicated negotiation, TLS
-   has facilitated the procedure, in that the client sends the server
-   all his supported ciphersuites, whereafter the server selects one of
-   them according to his policy or aborts the protocol, if none suitable
-   is among them.
-
-   TLS is designed having addition of further ciphersuites in mind.
-
-   The TLS handshake protocol's main intention is to
-
-   o  negotiate certain session parameters,
-
-   o  authenticate the server to the client, and optionally, the client
-      to the server and
-
-   o  establish a shared cryptographic secret.
-
-   If the handshake has finished successfully, a cryptographically
-   protected channel is established between the two parties, which can
-   be used to exchange securely further data.  The message flow of the
-   TLS handshake protocol is shown the following figure.
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007                [Page 4]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-         Client                                               Server
-         ------                                               ------
-
-   (1)   ClientHello                -------->
-                                                         ServerHello
-   (2)                                                 (Certificate)
-                                                   ServerKeyExchange
-                                                (CertificateRequest)
-                                    <--------        ServerHelloDone
-   (3)   (Certificate)
-         ClientKeyExchange
-         (CertificateVerify)
-         ChangeCipherSpec
-         Finished                   -------->
-   (4)                                              ChangeCipherSpec
-                                    <--------               Finished
-
-
-
-                          Figure 1: TLS handshake
-
-1.2.  The SIGMA protocol
-
-   SIGMA is a family of cryptographic key-exchange protocols that
-   provide perfect forward secrecy via a Diffie-Hellman exchange
-   authenticated with digital signatures.  It has been proposed already
-   in 1995.  It has gained many popularity by building the cryptographic
-   basis for the signature-based modes of IKE and IKEv2.
-
-   The protocol has very valuable features which motivated us to
-   incorporate it into TLS.
-
-   The SIGMA specification offers two subprotocols, SIGMA-I and SIGMA-R,
-   where I and R stand for Intiator and Responder.  SIGMA-I is a three-
-   message protocol and provides active identity protection for the
-   initiator, while SIGMA-R consists of four messages and provides
-   active identity protection for the responder.  Obviously, only the
-   SIGMA-I seems to be suitable to be built-in in TLS, so that we
-   restricts on it in the following.
-
-   Figure Figure 2 depicts the message flow of SIGMA-I.
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007                [Page 5]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-    A                                                          B
-    |                         g^x                              |
-    |--------------------------------------------------------->|
-    |                                                          |
-    |     g^y, ENC (Ke; B, SIG(B; g^x,g^y), MAC(Km; B) )       |
-    |<---------------------------------------------------------|
-    |                                                          |
-    |          ENC (Ke; A, SIG(A; g^y,g^x), MAC(Km; A) )       |
-    |--------------------------------------------------------->|
-
-                             Figure 2: SIGMA-I
-
-   The SIGMA specification allows to replace the peer's exponential by a
-   nonce, but we omit this modification.  The protocol derives Ke, Km
-   and a session key Ks from the Diffie-Hellman shared key, but they
-   have to be computationally independent.  On page 20 of [SIGMA] the
-   refinement to add some sense of direction to the MAC, i.e. we replace
-   MAC(Km;A) MAC(Km; "0",A) and MAC(Km;B) by MAC(Km; "1",B).
-
-   Finally, we replace (according to the rationale on page 21 of
-   [SIGMA]) the pair (SIG(B; g^x,g^y), MAC(Km; B)) by SIG(B; MAC(Km;
-   g^x,g^y,B))) and vice versa for the pair (SIG(A; g^y,g^x), MAC(Km;
-   A)).
-
-   The terminology does not deviate too much from existing work.  The
-   semantic is as follows.  ENC(K;X) stands for encryption of X with key
-   K. g^x and g^y are Diffie-Hellman keys.  SIG(A;X) stands for A's
-   signature on the content X. MAC (K;X) stands for computing a MAC over
-   X keyed by K.
-
-   Ke and Km are derived from the Diffie-Hellman shared secret g^(xy)
-   through a PRF, while they must be cryptographically independent.
-
-1.3.  Requirements notation
-
-   In this document, several words are used to signify the requirements
-   of the specification.  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
-   [RFC2119].
-
-1.4.  Terminology
-
-   This document frequently uses the following terms:
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007                [Page 6]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-   client:
-
-       One side of the connection.
-
-   server:
-
-       The other side of the connection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007                [Page 7]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-2.  Protocol Overview
-
-   This section describes how SIGMA-I is built in the TLS handshake
-   protocol.  Specifying a new ciphersuite means to re-define the
-   semantic or content of existing handshake messages or to add
-   extensions to the initial Hello exchange.
-
-   SIGMA-I fits perfectly in the message flow, if the client takes the
-   role of the initiator, and the server of the responder.
-
-   First, the client sends in an extension of the TLS ClientHello his
-   Diffie-Hellman public key g^x to the server, together with the DH
-   group he desires.  Possible choices are the prime groups defined in
-   IKEv2 [RFC4306] or in [RFC3546].  Table Figure 3 summarizes the
-   choices.
-
-   +--------------------+------+-------------+
-   | DH group specifier | bits | defined in  |
-   +--------------------+------+-------------+
-   | 0x0001             |  768 | RFC 4306    |
-   +--------------------+------+-------------+
-   | 0x0002             | 1024 | RFC 4306    |
-   +--------------------+------+-------------+
-   | 0x0003             | 1536 | RFC 3546    |
-   +--------------------+------+-------------+
-   | 0x0004             | 2048 | RFC 3546    |
-   +--------------------+------+-------------+
-   | 0x0005             | 3072 | RFC 3546    |
-   +--------------------+------+-------------+
-   | 0x0006             | 4096 | RFC 3546    |
-   +--------------------+------+-------------+
-
-                            Figure 3: DH groups
-
-   The server then verifies whether the selected / proposed DH group is
-   accceptable.  If no, the TLS handshake fails and the server sends a
-   corresponding message to the client.  Otherwise, the server selects a
-   private key y, computes g^y and sends this parameter in an extension
-   of the ServerHello back.  The Certificate message contains the
-   server's certificate (which corresponds to the identity B in the
-   SIGMA-I message flow), ServerkeyExchange contains the encrypted
-   signature and hash according to message 2 in Figure X.
-
-   Both sides are now able to compute the premaster secret.  The server
-   computes SK = (g^x)^y, the client computes SK = (g^y)^x.  The master
-   secret and keyblock are derived as specified in TLS v1.0.
-
-   The client sends now in the Certificate message his certificate
-
-
-
-Otto                    Expires October 29, 2007                [Page 8]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-   (which corresponds to the identity A in the SIGMA-I message flow),
-   and in ClientKeyExchange the encrypted signature and MAC, according
-   to message 3 in Figure Figure 2.  The CertificateVerify message is
-   not sent.  For RSA ciphersuites, this message would contain a
-   signature over all previously exchanged handshake messages.  Applying
-   this signature would destroy SIGMA's properties.
-
-   According to the rationale above, we show the message flow for TLS-
-   SIGMA :
-
-
-         Client (A)                                           Server (B)
-         ------                                               ------
-
-   (1)   ClientHello (g^x)          -------->
-                                                      ServerHello (g^y)
-   (2)                                                  Certificate (B)
-
-                                                      ServerKeyExchange
-                                    ENC(Ke; SIG(B; MAC(Km; g^x,g^y,B)))
-
-                                    <--------           ServerHelloDone
-   (3)
-         ClientKeyExchange
-         ENC(Ke; SIG( A; MAC(Km; g^y,g^x,A)))
-
-         ChangeCipherSpec
-         Finished                   -------->
-   (4)                                                 ChangeCipherSpec
-                                    <--------                  Finished
-
-
-
-                      Figure 4: TLS-SIGMA ciphersuite
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007                [Page 9]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-3.  IANA Considerations
-
-   -TBD-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007               [Page 10]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-4.  Security Considerations
-
-   -TBD-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007               [Page 11]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-5.  Acknowledgments
-
-   Add your name here.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007               [Page 12]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-6.  References
-
-6.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
-              Levkowetz, "Extensible Authentication Protocol (EAP)",
-              RFC 3748, June 2004.
-
-6.2.  Informative References
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC2407]  Piper, D., "The Internet IP Security Domain of
-              Interpretation for ISAKMP", RFC 2407, November 1998.
-
-   [RFC2408]  Maughan, D., Schneider, M., and M. Schertler, "Internet
-              Security Association and Key Management Protocol
-              (ISAKMP)", RFC 2408, November 1998.
-
-   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
-              (IKE)", RFC 2409, November 1998.
-
-   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 3546, June 2003.
-
-   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              RFC 4306, December 2005.
-
-   [SIGMA]    Hugo Krawczyk, "SIGMA: the 'SIGn-and-MAc' Approach to
-              Authenticated Diffie-Hellman and its Use in the IKE
-              Protocols", Springer LNCS Advances in Cryptography -
-              CRYPTO 2003 Proceedings, LNCS 2729, 2003.
-
-   [TLSPSK-Perf]
-              Mario Di Raimondo, Rosario Gennaro, Hugo Krawczyk,
-              "Deniable Authentication and Key Exchange.", CCS 06
-              (Conference on Computer and Communications Security) URL:
-              , October 2006.
-
-
-
-
-Otto                    Expires October 29, 2007               [Page 13]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-Author's Address
-
-   Thomas Otto
-   Germany
-
-   Email: t.otto@tu-bs.de
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Otto                    Expires October 29, 2007               [Page 14]
-
-Internet-Draft     A Privacy-enhancing TLS ciphersuite        April 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Otto                    Expires October 29, 2007               [Page 15]
-
diff --git a/doc/protocol/draft-rescorla-dtls-02.txt b/doc/protocol/draft-rescorla-dtls-02.txt
deleted file mode 100644
index 9a2636910a..0000000000
--- a/doc/protocol/draft-rescorla-dtls-02.txt
+++ /dev/null
@@ -1,994 +0,0 @@
-
-
-                                                             E. Rescorla
-                                                              RTFM, Inc.
-                                                             N. Modadugu
-INTERNET-DRAFT                                       Stanford University
-<draft-rescorla-dtls-02.txt>           December 2003 (Expires June 2004)
-
-                   Datagram Transport Layer Security
-
-Status of this Memo
-
-By submitting this Internet-Draft, I certify that any applicable
-patent or other IPR claims of which I am aware have been disclosed,
-and any of which I become aware will be disclosed, in accordance with
-RFC 3668.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-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 a "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999-2004). All Rights Reserved.
-
-
-
-Rescorla, Modadugu                                               [Page 1] 
-
-Contents
-
-
-
-Abstract
-
-   This document specifies Version 1.0 of the Datagram Transport Layer
-   Security (DTLS) protocol. The DTLS protocol provides communications
-   privacy for datagram protocols. The protocol allows client/server
-   applications to communicate in a way that is designed to prevent
-   eavesdropping, tampering, or message forgery. The DTLS protocol is
-   based on the TLS protocol and provides equivalent security
-   guarantees. Datagram semantics of the underlying transport are
-   preserved by the DTLS protocol.
-
-1. Introduction
-
-   TLS [TLS] is the most widely deployed protocol for securing network
-   traffic. It is widely used for protecting Web traffic and for e-mail
-   protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of
-   TLS is that it provides a transparent channel. Thus, it is easy to
-   secure an application protocol by inserting TLS between the
-   application layer and the network layer. However, TLS must run over a
-   reliable transport channel--typically TCP [TCP]. It therefore cannot
-   be used to secure unreliable datagram traffic.
-
-   However, over the past few years an increasing number of application
-   layer protocols have been designed which UDP transport. In particular
-   such protocols as the Session Initiation Protocol (SIP) [SIP], and
-   electronic gaming protocols are increasingly popular. (Note that SIP
-   can run over both TCP and UDP, but that there are situations in which
-   UDP is preferable). Currently, designers these applications are faced
-   with a number of unsatisfactory choices. First, they can use IPsec
-   [RFC2401]. However, for a number of reasons detailed in [WHYIPSEC],
-   this is only suitable for some applications. Second, they can design
-   a custom application layer security protocol. SIP, for instance, uses
-   a variant of S/MIME to secure its traffic. Unfortunately, application
-   layer security protocols typically require a large amount of effort
-   to design--by contrast to the relatively small amount of effort
-   required to run the protocol over TLS.
-
-   In many cases, the most desirable way to secure client/server
-   applications would be to use TLS, however the requirement for
-   datagram semantics automatically prohibits use of TLS. Thus, a
-   datagram-compatible variant of TLS would be very desirable. This memo
-   describes such a protocol: Datagram Transport Layer Security (DTLS).
-
-
-Rescorla, Modadugu                                               [Page 2] 
-
-   DTLS is deliberately designed to be as similar to to TLS as possible,
-   both to minimize new security invention and to maximize the amount of
-   code and infrastructure reuse.
-
-2. Usage Model
-
-   The DTLS protocol is designed to secure data between communicating
-   applications. It is designed to run in application space, without
-   requiring any kernel modifications. While the design of the DTLS
-   protocol does not preclude its use in securing arbitrary datagram
-   traffic, it is primarily expected to secure communication based on
-   datagram sockets.
-
-   Datagram transport does not guarantee reliable or in-order delivery
-   of data. The DTLS protocol preserves this property for payload data.
-   Applications such as media streaming, Internet telephony and online
-   gaming use datagram transport for communication due to the delay-
-   sensitive nature of transported data. The behavior of such
-   applications is unchanged when the DTLS protocol is used to secure
-   communication, since the DTLS protocol does not compensate for lost
-   or re-ordered data traffic.
-
-3. Overview of DTLS
-
-   The basic design philosophy of DTLS is to construct "TLS over
-   datagram". The reason that TLS cannot be used directly in datagram
-   environments is simply that packets may be lost or reordered. TLS has
-   no internal facilities to handle this kind of unreliability and
-   therefore TLS implementations break when rehosted on datagram
-   transport. The purpose of DTLS is to make only the minimal changes to
-   TLS required to fix this problem. To the greatest extent possible,
-   DTLS is identical to TLS. Whenever we need to invent new mechanisms,
-   we attempt to do so in such a way that it preserves the style of TLS.
-
-   Unreliability creates problems for TLS at two levels:
-
-      1. TLS's traffic encryption layer does not allow independent
-      decryption of individual records. If record N is not received,
-      then record N+1 cannot be decrypted.
-
-      2. The TLS handshake layer assumes that handshake messages are
-      delivered reliably and breaks if those messages are lost.
-
-   The rest of this section describes the approach that DTLS uses to
-   solve these problems.
-
-
-
-Rescorla, Modadugu                                               [Page 3] 
-
-3.1. Loss-insensitive messaging
-
-   In TLS's traffic encryption layer (called the TLS Record Layer),
-   records are not independent. There are two kinds of inter-record
-   dependency:
-
-      1. Cryptographic context (CBC state, stream cipher key stream) is
-      chained between records.
-
-      2. Anti-replay and message reordering protection are provided by a
-      MAC which includes a sequence number, but the sequence numbers are
-      implicit in the records.
-
-   The fix for both of these problems is straightforward and well-known
-   from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1
-   [TLS11] is already adding explicit CBC state to TLS records. DTLS
-   borrows that mechanism and adds explicit sequence numbers.
-
-3.2. Providing Reliability for Handshake
-
-   The TLS handshake is a lockstep cryptographic handshake. Messages
-   must be transmitted and received in a defined order and any other
-   order is an error. Clearly, this is incompatible with reordering and
-   message loss. In addition, TLS handshake messages are potentially
-   larger than any given datagram, thus creating the problem of
-   fragmentation. DTLS must provide fixes for both these problems.
-
-3.2.1. Packet Loss
-
-   DTLS uses a simple retransmission timer to handle packet loss. The
-   following figure demonstrates the basic concept using the first phase
-   of the DTLS handshake:
-
-      Client                                   Server
-      ------                                   ------
-      ClientHello           ------>
-
-                              X<-- HelloVerifyRequest
-                                               (lost)
-
-      [Timer Expires]
-
-      ClientHello           ------>
-      (retransmit)
-
-   Once the client has transmitted the ClientHello message, it expects
-   to see a HelloVerifyRequest from the server. However, if the server's
-   message is lost the client knows that either the ClientHello or the
-
-
-Rescorla, Modadugu                                               [Page 4] 
-
-   HelloVerifyRequest has been lost and retransmits. When the server
-   receives the retransmission, it knows to retransmit. The server also
-   maintains a retransmission timer and retransmits when that timer
-   expires.
-
-3.2.2. Reordering
-
-   In DTLS, each handshake message is assigned a specific sequence
-   number within that handshake. When a peer receives a handshake
-   message, it can quickly determine whether that message is the next
-   message it expects. If it is, then it processes it. If not, it queues
-   it up for future handling once all previous messages have been
-   received.
-
-3.3. Message Size
-
-   TLS and DTLS handshake messages can be quite large (in theory up to
-   2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams
-   are often limited to <1500 bytes. In order to compensate for this
-   limitation, each DTLS handshake message may be fragmented over
-   several DTLS records. Each DTLS handshake message contains both a
-   fragment offset and a fragment length. Thus, a recipient in
-   possession of all bytes of a handshake message can reassemble the
-   original unfragmented message.
-   DTLS optionally supports record replay detection. The technique used
-   is the same as in IPsec AH/ESP, by maintaining a bitmap window of
-   received records. Records that are too old to fit in the window and
-   records that have been previously received are silently discarded.
-   The replay detection feature is optional, since packet duplication is
-   not always malicious, but can also occur due to routing errors.
-   Applications may conceivably detect duplicate packets and accordingly
-   modify their data transmission strategy.
-
-4. Differences from TLS
-
-   As mentioned in Section , DTLS is intentionally very similar to TLS.
-   Therefore, instead of presenting DTLS as a new protocol, we instead
-   present it as a series of deltas from TLS 1.1 [TLS11]. Where we do
-   not explicitly call out differences, DTLS is the same as TLS.
-
-4.1. Record Layer
-
-   The DTLS record layer is extremely similar to that of TLS 1.1. The
-   only change is the inclusion of an explicit sequence number in the
-   record. This sequence number allows the recipient to correctly verify
-   the TLS MAC. The DTLS record format is shown below:
-
-
-
-Rescorla, Modadugu                                               [Page 5] 
-
-       struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 epoch;
-        uint48 sequence_number;
-        uint16 length;
-        opaque fragment[DTLSPlaintext.length];
-       } DTLSPlaintext;
-
-      type
-       Equivalent to the type field in a TLS 1.1 record.
-
-      version
-       The version of the protocol being employed. This document
-       describes DTLS Version 1.0, which uses the version { 254, 255
-       }. The version value of 254.255 is the 1's complement of DTLS
-       Version 1.0. This maximal spacing between TLS and DTLS version
-       numbers ensures that records from the two protocols can be
-       easily distinguished.
-
-      epoch
-       A counter value that is incremented on every cipher state
-       change.
-
-      sequence_number
-       The sequence number for this record.
-
-      length
-       Identical to the length field in a TLS 1.1 record. As in TLS
-       1.1, the length should not exceed 2^14.
-
-      fragment
-       Identical to the fragment field of a TLS 1.1 record.
-
-   DTLS uses an explicit rather than implicit sequence number, carried
-   in the sequence_number field of the record. As with TLS, the sequence
-   number is set to zero after each ChangeCipherSpec message is sent.
-
-   If several handshakes are performed in close succession, there might
-   be multiple records on the wire with the same sequence number but
-   from different cipher states. The epoch field allows recipients to
-   distinguish such packets. The epoch number is initially zero and is
-   incremented each time the ChangeCipherSpec messages is sent. In order
-   to ensure that any given sequence/epoch pair is unique,
-   implementations MUST NOT allow the same epoch value to be reused
-   within two times the maximum segment lifetime. In practice, TLS
-   implementations rehandshake rarely and we therefore do not expect
-   this to be a problem.
-
-
-Rescorla, Modadugu                                               [Page 6] 
-
-4.1.1. Transport Layer Mapping
-
-   Each DTLS record MUST fit within a single datagram. In order to avoid
-   IP fragmentation [MOGUL], DTLS implementations SHOULD determine the
-   MTU and send records smaller than the MTU. DTLS implementations
-   SHOULD provide a way for applications to determine the value of the
-   MTU (optimally the maximum application datagram size, which is the
-   PMTU minus the DTLS per-record overhead). If the application attempts
-   to send a record larger than the MTU, the DTLS implementation MUST
-   either generate an error or fragment the packet.
-
-4.1.1.1. PMTU Discovery
-
-   The PMTU SHOULD be initialized from the interface MTU that will be
-   used to send packets.
-
-   To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment
-   (DF) bit. As specified in [RFC 1191], when a router receives a packet
-   with DF set that is larger than the next link's MTU, it sends an ICMP
-   Destination Unreachable message to the source of the datagram with
-   the Code indicating "fragmentation needed and DF set" (also known as
-   a "Datagram Too Big" message). When a DTLS implementation receives a
-   Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU
-   value given in the ICMP message. If the MTU given in the message is
-   zero, the sender chooses a value for PMTU using the algorithm
-   described in Section 7 of [RFC 1191]. If the MTU given in the message
-   is greater than the current PMTU, the Datagram Too Big message is
-   ignored, as described in [RFC 1191].
-
-   A DTLS implementation may allow the application to occasionally
-   request that PMTU discovery be performed again. This will reset the
-   PMTU to the outgoing interface's MTU. Such requests SHOULD be rate
-   limited, to one per two seconds, for example.
-
-   Because some firewalls and routers screen out ICMP messages, it is
-   difficult to distinguish packet loss from a large PMTU estimate. In
-   order to allow connections under these circumstances, DTLS
-   implementations MAY choose to back off their PMTU estimate during the
-   retransmit backoff described in Section . For instance, if a large
-   packet is being sent, after 3 retransmits a sender might choose to
-   fragment the packet.
-
-4.1.2. Record payload protection
-
-4.1.2.1. MAC
-
-   The DTLS MAC is the same as that of TLS 1.1. However, rather than
-   using TLS's implicit sequence number, the sequence number used to
-
-
-Rescorla, Modadugu                                               [Page 7] 
-
-   compute the MAC is the 64-bit value formed by concatenating the epoch
-   and the sequence number in the order they appear on the wire. Note
-   that the DTLS epoch + sequence number is the same length as the TLS
-   sequence number.
-
-4.1.2.2. Null or standard stream cipher
-
-   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
-
-   The only stream cipher described in TLS 1.1 is RC4, which cannot be
-   randomly accessed. RC4 MUST NOT be used with DTLS.
-
-4.1.2.3. Block Cipher
-
-   DTLS block cipher encryption and decryption are performed exactly as
-   with TLS 1.1.
-
-4.1.2.4. Anti-Replay
-
-   DTLS records contain a sequence number to provide replay protection.
-   Sequence number verification SHOULD be performed using the following
-   sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402]
-
-   The receiver packet counter for this session MUST be initialized to
-   zero when the session is established. For each received record, the
-   receiver MUST verify that the record contains a Sequence Number that
-   does not duplicate the Sequence Number of any other record received
-   during the life of this session. This SHOULD be the first check
-   applied to a packet after it has been matched to a session, to speed
-   rejection of duplicate records.
-
-   Duplicates are rejected through the use of a sliding receive window.
-   (How the window is implemented is a local matter, but the following
-   text describes the functionality that the implementation must
-   exhibit.) A MINIMUM window size of 32 MUST be supported; but a window
-   size of 64 is preferred and SHOULD be employed as the default.
-   Another window size (larger than the MINIMUM) MAY be chosen by the
-   receiver. (The receiver does NOT notify the sender of the window
-   size.)
-
-   The "right" edge of the window represents the highest, validated
-   Sequence Number value received on this session. Records that contain
-   Sequence Numbers lower than the "left" edge of the window are
-   rejected. Packets falling within the window are checked against a
-   list of received packets within the window. An efficient means for
-   performing this check, based on the use of a bit mask, is described
-   in [RFC 2401].
-
-
-Rescorla, Modadugu                                               [Page 8] 
-
-   If the received record falls within the window and is new, or if the
-   packet is to the right of the window, then the receiver proceeds to
-   MAC verification. If the MAC validation fails, the receiver MUST
-   discard the received record as invalid. The receive window is updated
-   only if the MAC verification succeeds.
-
-4.2. The DTLS Handshake Protocol
-
-   DTLS uses all of the same handshake messages and flows as TLS, with
-   three principal changes:
-
-      1. A stateless cookie exchange to prevent denial of service
-      attacks.
-
-      2. Modifications to the handshake header to handle message loss,
-      reordering and fragmentation.
-
-      3. Retransmission timers to handle message loss.
-
-   With these exceptions, the DTLS message formats, flows, and logic are
-   the same as those of TLS 1.1.
-
-4.2.1. Denial of Service Countermeasures
-
-   Datagram security protocols are extremely susceptible to a variety of
-   denial of service (DoS) attacks. Two attacks are of particular
-   concern:
-
-      1. An attacker can consume excessive resources on the server by
-      transmitting a series of handshake initiation requests, causing
-      the server to allocate state and potentially perform expensive
-      cryptographic operations.
-
-      2. An attacker can use the server as an amplifier by sending
-      connection initiation messages with a forged source of the victim.
-      The server then sends its next message (in DTLS, a Certificate
-      message, which can be quite large) to the victim machine, thus
-      flooding it.
-
-   In order to prevent both of these attacks, DTLS borrows the stateless
-   cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When
-   the client sends its ClientHello message to the server, the server
-   MAY respond with a HelloVerifyRequest message. This message contains
-   a stateless cookie generated using the technique of [PHOTURIS]. The
-   client MUST retransmit the ClientHello with the cookie added. The
-   server then verifies the cookie and proceeds with the handshake only
-   if it is valid.
-
-
-Rescorla, Modadugu                                               [Page 9] 
-
-   The exchange is shown below:
-
-         Client                                   Server
-         ------                                   ------
-         ClientHello           ------>
-
-                               <----- HelloVerifyRequest
-                                      (contains cookie)
-
-         ClientHello           ------>
-         (with cookie)
-
-         [Rest of handshake]
-
-   DTLS therefore modifies the ClientHello message to add the cookie
-   value.
-
-      struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        Cookie cookie<0..32>;                 // New field
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-      } ClientHello;
-
-   If the client does not have a cookie for a given server, it should
-   use a zero-length cookie.
-
-   The definition of HelloVerifyRequest is as follows:
-
-      struct {
-        Cookie cookie<0..32>;
-      } HelloVerifyRequest;
-
-   The HelloVerifyRequest message type is hello_verify_request(3).
-
-   When responding to a HelloVerifyRequest the client MUST use the same
-   parameter values (version, random, session_id, cipher_suites,
-   compression_method) as in the original ClientHello. The server SHOULD
-   use those values to generate its cookie and verify that they are
-   correct upon cookie receipt.
-
-   Although DTLS servers are not required to do a cookie exchange, they
-   SHOULD do so whenever a new handshake is performed in order to avoid
-   being used as amplifiers. If the server is being operated in an
-   environment where amplification is not a problem, the server MAY
-   choose not to perform a cookie exchange. In addition, the server MAY
-
-
-Rescorla, Modadugu                                              [Page 10] 
-
-   choose not do to a cookie exchange when a session is resumed. Clients
-   MUST be prepared to do a cookie exchange with every handshake.
-
-4.2.2. Handshake Message Format
-
-   In order to support message loss, reordering, and fragmentation DTLS
-   modifies the TLS 1.1 handshake header:
-
-      struct {
-        HandshakeType msg_type;
-        uint24 length;
-        uint16 message_seq;                              // New field
-        uint24 fragment_offset;                          // New field
-        uint24 fragment_length;                          // New field
-        select (HandshakeType) {
-      case hello_request: HelloRequest;
-      case client_hello:  ClientHello;
-      case hello_verify_request: HelloVerifyRequest;     // New message type
-      case server_hello:  ServerHello;
-      case certificate:Certificate;
-      case server_key_exchange: ServerKeyExchange;
-      case certificate_request: CertificateRequest;
-      case server_hello_done:ServerHelloDone;
-      case certificate_verify:  CertificateVerify;
-      case client_key_exchange: ClientKeyExchange;
-      case finished:Finished;
-        } body;
-      } Handshake;
-
-   The first message each side transmits in each handshake always has
-   message_seq = 0. Whenever each new message is generated, the
-   message_seq value is incremented by one. When a message is
-   retransmitted, the same message_seq value is used. For example.
-
-      Client                             Server
-      ------                             ------
-      ClientHello (seq=0)  ------>
-
-                              X<-- HelloVerifyRequest (seq=0)
-                                              (lost)
-
-      [Timer Expires]
-
-      ClientHello (seq=0)  ------>
-      (retransmit)
-
-                           <------ HelloVerifyRequest (seq=0)
-
-
-Rescorla, Modadugu                                              [Page 11] 
-
-      ClientHello (seq=1)  ------>
-      (with cookie)
-
-                           <------        ServerHello (seq=1)
-                           <------        Certificate (seq=2)
-                           <------    ServerHelloDone (seq=3)
-
-      [Rest of handshake]
-
-   DTLS implementations maintain (at least notionally) a
-   next_receive_seq counter. This counter is initially set to zero. When
-   a message is received, if its sequence number matches
-   next_receive_seq, next_receive_seq is incremented and the message is
-   processed. If the sequence number is less than next_receive_seq the
-   message MUST be discarded. If the sequence number is greater than
-   next_receive_seq, the implementation SHOULD queue the message but MAY
-   discard it. (This is a simple space/bandwidth tradeoff).
-
-4.2.3. Message Fragmentation and Reassembly
-
-   As noted in Section , each DTLS message MUST fit within a single
-   transport layer datagram. However, handshake messages are potentially
-   bigger than the maximum record size. Therefore DTLS provides a
-   mechanism for fragmenting a handshake message over a number of
-   records.
-
-   When transmitting the handshake message, the sender divides the
-   message into a series of N contiguous data ranges. These range must
-   be no larger than the maximum handshake fragment size and MUST
-   jointly contain the entire handshake message. The ranges SHOULD NOT
-   overlap. The sender then creates N handshake messages, all with the
-   same message_seq value as the original handshake message. Each new
-   message is labelled with the fragment_offset (the number of bytes
-   contained in previous fragments) and the fragment_length (the length
-   of this fragment). The length field in all messages is the same as
-   the length field of the original message. An unfragmented message is
-   a degenerate case with fragment_offset=0 and fragment_length=length.
-
-   When a DTLS implementation receives a handshake message fragment, it
-   MUST buffer it until it has the entire handshake message. DTLS
-   implementations MUST be able to handle overlapping fragment ranges.
-   This allows senders to retransmit handshake messages with smaller
-   fragment sizes during path MTU discovery.
-
-4.2.4. Timeout and Retransmission
-
-   DTLS messages are grouped into a series of message flights, according
-   the diagrams below. Although each flight of messages may consist of a
-
-
-Rescorla, Modadugu                                              [Page 12] 
-
-   number of messages, they should be viewed as monolithic for the
-   purpose of timeout and retransmission.
-
-      Client                                          Server
-      ------                                          ------
-
-      ClientHello             -------->                           Flight 1
-
-                              <-------    HelloVerifyRequest      Flight 2
-
-     ClientHello              -------->                           Flight 3
-
-                                                 ServerHello    \
-                                                Certificate*     \
-                                          ServerKeyExchange*      Flight 4
-                                         CertificateRequest*     /
-                              <--------      ServerHelloDone    /
-
-      Certificate*                                              \
-      ClientKeyExchange                                          \
-      CertificateVerify*                                          Flight 5
-      [ChangeCipherSpec]                                         /
-      Finished                -------->                         /
-
-                                          [ChangeCipherSpec]    \ Flight 6
-                              <--------             Finished    /
-               Figure 1: Message flights for full handshake
-
-      Client                                           Server
-      ------                                           ------
-
-      ClientHello             -------->                          Flight 1
-
-                                                 ServerHello    \
-                                          [ChangeCipherSpec]     Flight 2
-                               <--------             Finished    /
-
-      [ChangeCipherSpec]                                         \Flight 3
-      Finished                 -------->                         /
-   Figure 2: Message flights for session resuming handshake (no cookie exchange)
-
-   DTLS uses a simple timeout and retransmission scheme with the
-   following state machine.
-
-
-
-Rescorla, Modadugu                                              [Page 13] 
-
-                   +--------+
-                   | PREPAR |
-             +---> | -ING   |
-             |     |        |
-             |     +--------+
-             |         |
-             |         |
-             |         | Buffer next flight
-             |         |
-             |        \|/
-             |     +---------+
-             |     |         |
-             |     | SENDING |<--------------------+
-             |     |         |                     |
-             |     +---------+                     |
-     Receive |          |                          |
-        next |          | Send flight              |
-      flight |  +-------+                          |
-             |  |       | Set retransmit timer     |
-             |  |      \|/                         |
-             |  |  +---------+                     |
-             |  |  |         |                     |
-             +--)--| WAITING |---------------------+
-             |  |  |         |     Timer expires   |
-             |  |  +---------+                     |
-             |  |         |                        |
-             |  |         |                        |
-             |  |         +------------------------+
-             |  |                  Read retransmit
-     Receive |  |
-        last |  |
-      flight |  |
-             |  |
-            \|/\|/
-
-            FINISH
-          Figure 3: DTLS timeout and retransmission state machine
-
-   The state machine has three basic states.
-
-   In the PREPARING state the implementation does whatever computations
-   are necessary to prepare the next flight of messages. It then buffers
-   them up for transmission (emptying the buffer first) and enters the
-   SENDING state.
-
-
-
-Rescorla, Modadugu                                              [Page 14] 
-
-   In the SENDING state, the implementation transmits the buffered
-   flight of messages. Once the messages have been sent, the
-   implementation then enters the FINISH state if this is the last
-   flight in the handshake, or, if the implementation expects to receive
-   more messages, sets a retransmit timer and then enters the WAITING
-   state.
-
-   There are three ways to exit the WAITING state:
-
-      1. The retransmit timer expires: the implementation transitions to
-      the SENDING state, where it retransmits the flight, resets the
-      retransmit timer, and returns to the WAITING state.
-
-      2. The implementation reads a retransmitted flight from the peer:
-      the implementation transitions to the SENDING state, where it
-      retransmits the flight, resets the retransmit timer, and returns
-      to the WAITING state. The rationale here is that the receipt of a
-      duplicate message is the likely result of timer expiry on the peer
-      and therefore suggests that part of one's previous flight was
-      lost.
-
-      3. The implementation receives the next flight of messages: if
-      this is the final flight of messages the implementation
-      transitions to FINISHED. If the implementation needs to send a new
-      flight, it transitions to the PREPARING state. Partial reads
-      (whether partial messages or only some of the messages in the
-      flight) do not cause state transitions or timer resets.
-
-   Because DTLS clients send the first message (ClientHello) they start
-   in the PREPARING state. DTLS servers start in the WAITING state, but
-   with empty buffers and no retransmit timer.
-
-4.2.4.1. Timer Values
-
-   Timer value choices are a local matter. We recommend that
-   implementations use an initial timer value of 500 ms and double the
-   value at each retransmission, up to 2MSL. Implementations SHOULD
-   start the timer value at the initial value with each new flight of
-   messages.
-
-4.2.5. ChangeCipherSpec
-
-   As with TLS, the ChangeCipherSpec message is not technically a
-   handshake message but MUST be treated as part of the same flight as
-   the associated Finished message for the purposes of timeout and
-   retransmission.
-
-
-
-Rescorla, Modadugu                                              [Page 15] 
-
-4.2.6. Finished messages
-
-   Finished messages have the same format as in TLS. However, in order
-   to remove sensitivity to fragmentation, the Finished MAC MUST be
-   computed as if each handshake message had been sent as a single
-   fragment. Note that in cases where the cookie exchange is used, the
-   initial ClientHello and HelloVerifyRequest ARE included in the
-   Finished MAC.
-
-
-A.1 Summary of new syntax
-
-   This section includes specifications for the data structures that
-   have changed between TLS 1.1 and DTLS.
-
-4.2. Record Layer
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // NEW
-     uint48 sequence_number;                         // NEW
-     uint16 length;
-     opaque fragment[DTLSPlaintext.length];
-   } DTLSPlaintext;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // NEW
-     uint48 sequence_number;                         // NEW
-     uint16 length;
-     opaque fragment[DTLSCompressed.length];
-   } DTLSCompressed;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // NEW
-     uint48 sequence_number;                         // NEW
-     uint16 length;
-     select (CipherSpec.cipher_type) {
-   case block:  GenericBlockCipher;
-     } fragment;
-   } DTLSCiphertext;
-
-
-
-Rescorla, Modadugu                                              [Page 16] 
-
-4.3. Handshake Protocol
-
-   enum {
-     hello_request(0), client_hello(1), server_hello(2),
-     hello_verify_request(3),                        // NEW
-     certificate(11), server_key_exchange (12),
-     certificate_request(13), server_hello_done(14),
-     certificate_verify(15), client_key_exchange(16),
-     finished(20), (255)
-   } HandshakeType;
-
-   struct {
-     HandshakeType msg_type;
-     uint24 length;
-     uint16 message_seq;                             // NEW
-     uint24 fragment_offset;                         // NEW
-     uint24 fragment_length;                         // NEW
-     select (HandshakeType) {
-   case hello_request: HelloRequest;
-   case client_hello:  ClientHello;
-   case server_hello:  ServerHello;
-   case hello_verify_request: HelloVerifyRequest;    // NEW
-   case certificate:Certificate;
-   case server_key_exchange: ServerKeyExchange;
-   case certificate_request: CertificateRequest;
-   case server_hello_done:ServerHelloDone;
-   case certificate_verify:  CertificateVerify;
-   case client_key_exchange: ClientKeyExchange;
-   case finished:Finished;
-     } body;
-   } Handshake;
-
-   struct {
-     Cookie cookie<H0..32>;
-   } HelloVerifyRequest;
-
-5. Security Considerations
-
-   This document describes a variant of TLS 1.1 and therefore most of
-   the security considerations are the same as TLS 1.1.
-
-   The primary additional security consideration raised by DTLS is that
-   of denial of service. DTLS includes a cookie exchange designed to
-   protect against denial of service. However, implementations which do
-   not use this cookie exchange are still vulnerable to DoS. In
-   particular, DTLS servers which do not use the cookie exchange may be
-   used as attack amplifiers even if they themselves are not
-   experiencing DoS. Therefore DTLS servers SHOULD use the cookie
-
-
-Rescorla, Modadugu                                              [Page 17] 
-
-   exchange unless there is good reason to believe that amplification is
-   not a threat in their environment.
-
-6. IANA Considerations
-
-   This document uses the same identifier space as does TLS [TLS11], so
-   no IANA registries are required beyond those for TLS. Identifiers MAY
-   NOT be assigned for DTLS that conflict with TLS.
-
-References
-
-Normative References
-
-   [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
-              Protocol", RFC 2521, March 1999.
-
-   [RFC1191]  Mogul, J. C., Deering, S.E., "Path MTU Discovery",
-              RFC 1191, November 1990.
-
-   [RFC2401]  Kent, S., Atkinson, R., "Security Architecture for the
-              Internet Protocol", RFC2401, November 1998.
-
-   [TLS]      Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [TLS11]    Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
-              draft-ietf-tls-rfc2246-bis-05.txt, July 2003.
-
-Informative References
-
-   [AH]       Kent, S., and Atkinson, R., "IP Authentication Header",
-              RFC 2402, November 1998.
-
-   [DCCP]     Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
-              Congestion Control Protocol", draft-ietf-dccp-spec-05.txt,
-              October 2003
-
-   [DTLS]     Modadugu, N., Rescorla, E., "The Design and Implementation
-              of Datagram TLS", in Proceedings of ISOC NDSS 2004,
-              February 2004.
-
-   [ESP]      Kent, S., and Atkinson, R., "IP Encapsulating Security
-              Payload (ESP)", RFC 2406, November 1998.
-
-   [IKE]      Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
-              RFC 2409, November 1998.
-
-
-Rescorla, Modadugu                                              [Page 18] 
-
-   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
-              4rev1", RFC 3501, March 2003.
-
-   [POP]      Myers, J., and Rose, M., "Post Office Protocol -
-              Version 3", RFC 1939, May 1996.
-
-   [SIP]      Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A.,
-              Peterson, J., Sparks, R., Handley, M., Schooler, E.,
-              "SIP: Session Initiation Protocol", RFC 3261,
-              June 2002.
-
-   [TCP]      Postel, J., "Transmission Control Protocol",
-              RFC 793, September 1981.
-
-   [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
-              draft-bellovin-useipsec-02.txt, October 2003
-
-Authors' Address
-
-   Eric Rescorla <ekr@rtfm.com>
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto, CA 94303
-
-   Nagendra Modadugu <nagendra@cs.stanford.edu>
-   Computer Science Department
-   353 Serra Mall
-   Stanford University
-   Stanford, CA 94305
-
-
-Acknowledgements
-
-   The authors would like to thank Dan Boneh, Eu-Jin Goh, Constantine
-   Sapuntzakis, and Hovav Shacham for discussions and comments on the
-   design of DTLS. Thanks to the anonymous NDSS reviewers of our
-   original NDSS paper on DTLS [DTLS] for their comments. Also, thanks
-   to Steve Kent for feedback that helped clarify many points. The
-   section on PMTU was cribbed from the DCCP specification [DCCP].
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 19] 
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 20]
diff --git a/doc/protocol/draft-rescorla-dtls-03.txt b/doc/protocol/draft-rescorla-dtls-03.txt
deleted file mode 100644
index 24dfbf1dcf..0000000000
--- a/doc/protocol/draft-rescorla-dtls-03.txt
+++ /dev/null
@@ -1,1176 +0,0 @@
-                                                             E. Rescorla
-                                                              RTFM, Inc.
-                                                             N. Modadugu
-INTERNET-DRAFT                                       Stanford University
-<draft-rescorla-dtls-03.txt>         February 2004 (Expires August 2005)
-
-                   Datagram Transport Layer Security
-
-Status of this Memo
-
-By submitting this Internet-Draft, I certify that any applicable
-patent or other IPR claims of which I am aware have been disclosed,
-and any of which I become aware will be disclosed, in accordance with
-RFC 3668.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-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 a "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999-2004). All Rights Reserved.
-
-
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 1]
-
-
-Abstract
-
-   This document specifies Version 1.0 of the Datagram Transport Layer
-   Security (DTLS) protocol. The DTLS protocol provides communications
-   privacy for datagram protocols. The protocol allows client/server
-   applications to communicate in a way that is designed to prevent
-   eavesdropping, tampering, or message forgery. The DTLS protocol is
-   based on the TLS protocol and provides equivalent security
-   guarantees. Datagram semantics of the underlying transport are
-   preserved by the DTLS protocol.
-
-
-Contents
-
-
-
-
-1. Introduction
-
-   TLS [TLS] is the most widely deployed protocol for securing network
-   traffic. It is widely used for protecting Web traffic and for e-mail
-   protocols such as IMAP [IMAP] and POP [POP]. The primary advantage of
-   TLS is that it provides a transparent connection-oriented channel.
-   Thus, it is easy to secure an application protocol by inserting TLS
-   between the application layer and the transport layer. However, TLS
-   must run over a reliable transport channel--typically TCP [TCP]. It
-   therefore cannot be used to secure unreliable datagram traffic.
-
-   However, over the past few years an increasing number of application
-   layer protocols have been designed which UDP transport. In particular
-   such protocols as the Session Initiation Protocol (SIP) [SIP], and
-   electronic gaming protocols are increasingly popular. (Note that SIP
-   can run over both TCP and UDP, but that there are situations in which
-   UDP is preferable). Currently, designers of these applications are
-   faced with a number of unsatisfactory choices. First, they can use
-   IPsec [RFC2401]. However, for a number of reasons detailed in
-   [WHYIPSEC], this is only suitable for some applications. Second, they
-   can design a custom application layer security protocol. SIP, for
-   instance, uses a subsert of S/MIME to secure its traffic.
-   Unfortunately, while application layer security protocols generally
-   provide superior security properties (e.g., end-to-end security in
-   the case of S/MIME) it typically require a large amount of effort to
-   design--by contrast to the relatively small amount of effort required
-   to run the protocol over TLS.
-
-   In many cases, the most desirable way to secure client/server
-   applications would be to use TLS; however the requirement for
-   datagram semantics automatically prohibits use of TLS. Thus, a
-
-
-
-Rescorla, Modadugu                                               [Page 2]
-
-
-   datagram-compatible variant of TLS would be very desirable. This memo
-   describes such a protocol: Datagram Transport Layer Security (DTLS).
-   DTLS is deliberately designed to be as similar to to TLS as possible,
-   both to minimize new security invention and to maximize the amount of
-   code and infrastructure reuse.
-
-
-1.1. Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Usage Model
-
-   The DTLS protocol is designed to secure data between communicating
-   applications. It is designed to run in application space, without
-   requiring any kernel modifications. While the design of the DTLS
-   protocol does not preclude its use in securing arbitrary datagram
-   traffic, it is primarily expected to secure communication based on
-   datagram sockets.
-
-   Datagram transport does not require or provide reliable or in-order
-   delivery of data. The DTLS protocol preserves this property for
-   payload data. Applications such as media streaming, Internet
-   telephony and online gaming use datagram transport for communication
-   due to the delay-sensitive nature of transported data. The behavior
-   of such applications is unchanged when the DTLS protocol is used to
-   secure communication, since the DTLS protocol does not compensate for
-   lost or re-ordered data traffic.
-
-3. Overview of DTLS
-
-   The basic design philosophy of DTLS is to construct "TLS over
-   datagram". The reason that TLS cannot be used directly in datagram
-   environments is simply that packets may be lost or reordered. TLS has
-   no internal facilities to handle this kind of unreliability and
-   therefore TLS implementations break when rehosted on datagram
-   transport. The purpose of DTLS is to make only the minimal changes to
-   TLS required to fix this problem. To the greatest extent possible,
-   DTLS is identical to TLS. Whenever we need to invent new mechanisms,
-   we attempt to do so in such a way that it preserves the style of TLS.
-
-   Unreliability creates problems for TLS at two levels:
-
-      1. TLS's traffic encryption layer does not allow independent
-      decryption of individual records. If record N is not received,
-      then record N+1 cannot be decrypted.
-
-
-
-Rescorla, Modadugu                                               [Page 3]
-
-
-      2. The TLS handshake layer assumes that handshake messages are
-      delivered reliably and breaks if those messages are lost.
-
-   The rest of this section describes the approach that DTLS uses to
-   solve these problems.
-
-3.1. Loss-insensitive messaging
-
-   In TLS's traffic encryption layer (called the TLS Record Layer),
-   records are not independent. There are two kinds of inter-record
-   dependency:
-
-      1. Cryptographic context (CBC state, stream cipher key stream) is
-      chained between records.
-
-      2. Anti-replay and message reordering protection are provided by a
-      MAC which includes a sequence number, but the sequence numbers are
-      implicit in the records.
-
-   The fix for both of these problems is straightforward and well-known
-   from IPsec ESP [ESP]: add explicit state to the records. TLS 1.1
-   [TLS11] is already adding explicit CBC state to TLS records. DTLS
-   borrows that mechanism and adds explicit sequence numbers.
-
-3.2. Providing Reliability for Handshake
-
-   The TLS handshake is a lockstep cryptographic handshake. Messages
-   must be transmitted and received in a defined order and any other
-   order is an error. Clearly, this is incompatible with reordering and
-   message loss. In addition, TLS handshake messages are potentially
-   larger than any given datagram, thus creating the problem of
-   fragmentation. DTLS must provide fixes for both these problems.
-
-3.2.1. Packet Loss
-
-   DTLS uses a simple retransmission timer to handle packet loss. The
-   following figure demonstrates the basic concept using the first phase
-   of the DTLS handshake:
-
-      Client                                   Server
-      ------                                   ------
-      ClientHello           ------>
-
-                              X<-- HelloVerifyRequest
-                                               (lost)
-
-      [Timer Expires]
-
-
-
-
-Rescorla, Modadugu                                               [Page 4]
-
-
-      ClientHello           ------>
-      (retransmit)
-
-   Once the client has transmitted the ClientHello message, it expects
-   to see a HelloVerifyRequest from the server. However, if the server's
-   message is lost the client knows that either the ClientHello or the
-   HelloVerifyRequest has been lost and retransmits. When the server
-   receives the retransmission, it knows to retransmit. The server also
-   maintains a retransmission timer and retransmits when that timer
-   expires.
-
-3.2.2. Reordering
-
-   In DTLS, each handshake message is assigned a specific sequence
-   number within that handshake. When a peer receives a handshake
-   message, it can quickly determine whether that message is the next
-   message it expects. If it is, then it processes it. If not, it queues
-   it up for future handling once all previous messages have been
-   received.
-
-3.2.3. Message Size
-
-   TLS and DTLS handshake messages can be quite large (in theory up to
-   2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams
-   are often limited to <1500 bytes. In order to compensate for this
-   limitation, each DTLS handshake message may be fragmented over
-   several DTLS records. Each DTLS handshake message contains both a
-   fragment offset and a fragment length. Thus, a recipient in
-   possession of all bytes of a handshake message can reassemble the
-   original unfragmented message.
-
-3.3. Replay Detection
-
-   DTLS optionally supports record replay detection. The technique used
-   is the same as in IPsec AH/ESP, by maintaining a bitmap window of
-   received records. Records that are too old to fit in the window and
-   records that have been previously received are silently discarded.
-   The replay detection feature is optional, since packet duplication is
-   not always malicious, but can also occur due to routing errors.
-   Applications may conceivably detect duplicate packets and accordingly
-   modify their data transmission strategy.
-
-4. Differences from TLS
-
-   As mentioned in Section 3., DTLS is intentionally very similar to
-   TLS. Therefore, instead of presenting DTLS as a new protocol, we
-   instead present it as a series of deltas from TLS 1.1 [TLS11]. Where
-   we do not explicitly call out differences, DTLS is the same as TLS.
-
-
-
-Rescorla, Modadugu                                               [Page 5]
-
-
-4.1. Record Layer
-
-   The DTLS record layer is extremely similar to that of TLS 1.1. The
-   only change is the inclusion of an explicit sequence number in the
-   record. This sequence number allows the recipient to correctly verify
-   the TLS MAC. The DTLS record format is shown below:
-
-       struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 epoch;               // New field
-        uint48 sequence_number;       // New field
-        uint16 length;
-        opaque fragment[DTLSPlaintext.length];
-       } DTLSPlaintext;
-
-      type
-       Equivalent to the type field in a TLS 1.1 record.
-
-      version
-       The version of the protocol being employed. This document
-       describes DTLS Version 1.0, which uses the version { 254, 255
-       }. The version value of 254.255 is the 1's complement of DTLS
-       Version 1.0. This maximal spacing between TLS and DTLS version
-       numbers ensures that records from the two protocols can be
-       easily distinguished.
-
-      epoch
-       A counter value that is incremented on every cipher state
-       change.
-
-      sequence_number
-       The sequence number for this record.
-
-      length
-       Identical to the length field in a TLS 1.1 record. As in TLS
-       1.1, the length should not exceed 2^14.
-
-      fragment
-       Identical to the fragment field of a TLS 1.1 record.
-
-   DTLS uses an explicit rather than implicit sequence number, carried
-   in the sequence_number field of the record. As with TLS, the sequence
-   number is set to zero after each ChangeCipherSpec message is sent.
-
-   If several handshakes are performed in close succession, there might
-   be multiple records on the wire with the same sequence number but
-   from different cipher states. The epoch field allows recipients to
-
-
-
-Rescorla, Modadugu                                               [Page 6]
-
-
-   distinguish such packets. The epoch number is initially zero and is
-   incremented each time the ChangeCipherSpec messages is sent. In order
-   to ensure that any given sequence/epoch pair is unique,
-   implementations MUST NOT allow the same epoch value to be reused
-   within two times the maximum segment lifetime. In practice, TLS
-   implementations rehandshake rarely and we therefore do not expect
-   this to be a problem.
-
-4.1.1. Transport Layer Mapping
-
-   Each DTLS record MUST fit within a single datagram. In order to avoid
-   IP fragmentation [MOGUL], DTLS implementations SHOULD determine the
-   MTU and send records smaller than the MTU. DTLS implementations
-   SHOULD provide a way for applications to determine the value of the
-   MTU (optimally the maximum application datagram size, which is the
-   PMTU minus the DTLS per-record overhead). If the application attempts
-   to send a record larger than the MTU, the DTLS implementation MUST
-   either generate an error or fragment the packet.
-
-   Multiple DTLS records may be placed in a single datagram. They are
-   simply encoded consecutively. The DTLS record framing is sufficient
-   to determine the boundaries. Note, however, that the first byte of
-   the datagram payload must be the beginning of a record. Records may
-   not span datagrams.
-
-4.1.1.1. PMTU Discovery
-
-   The PMTU SHOULD be initialized from the interface MTU that will be
-   used to send packets.
-
-   To perform PMTU discovery, the DTLS sender sets the IP Don't Fragment
-   (DF) bit. As specified in [RFC 1191], when a router receives a packet
-   with DF set that is larger than the next link's MTU, it sends an ICMP
-   Destination Unreachable message to the source of the datagram with
-   the Code indicating "fragmentation needed and DF set" (also known as
-   a "Datagram Too Big" message). When a DTLS implementation receives a
-   Datagram Too Big message, it decreases its PMTU to the Next-Hop MTU
-   value given in the ICMP message. If the MTU given in the message is
-   zero, the sender chooses a value for PMTU using the algorithm
-   described in Section 7 of [RFC 1191]. If the MTU given in the message
-   is greater than the current PMTU, the Datagram Too Big message is
-   ignored, as described in [RFC 1191].
-
-   A DTLS implementation may allow the application to occasionally
-   request that PMTU discovery be performed again. This will reset the
-   PMTU to the outgoing interface's MTU. Such requests SHOULD be rate
-   limited, to one per two seconds, for example.
-
-
-
-
-Rescorla, Modadugu                                               [Page 7]
-
-
-   Because some firewalls and routers screen out ICMP messages, it is
-   difficult to distinguish packet loss from a large PMTU estimate. In
-   order to allow connections under these circumstances, DTLS
-   implementations MAY choose to back off their PMTU estimate during the
-   retransmit backoff described in Section 4.2.4.. For instance, if a
-   large packet is being sent, after 3 retransmits a sender might choose
-   to fragment the packet.
-
-4.1.2. Record payload protection
-
-   Like TLS, DTLS transmits data as a series of protected records. The
-   rest of this section describes the details of that format.
-
-4.1.2.1. MAC
-
-   The DTLS MAC is the same as that of TLS 1.1. However, rather than
-   using TLS's implicit sequence number, the sequence number used to
-   compute the MAC is the 64-bit value formed by concatenating the epoch
-   and the sequence number in the order they appear on the wire. Note
-   that the DTLS epoch + sequence number is the same length as the TLS
-   sequence number.
-
-4.1.2.2. Null or standard stream cipher
-
-   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
-
-   The only stream cipher described in TLS 1.1 is RC4, which cannot be
-   randomly accessed. RC4 MUST NOT be used with DTLS.
-
-4.1.2.3. Block Cipher
-
-   DTLS block cipher encryption and decryption are performed exactly as
-   with TLS 1.1.
-
-4.1.2.4. New Cipher Suites
-
-   Upon registration, new TLS cipher suites MUST indicate whether they
-   are suitable for DTLS usage and what, if any, adaptations must be
-   made.
-
-4.1.2.5. Anti-Replay
-
-   DTLS records contain a sequence number to provide replay protection.
-   Sequence number verification SHOULD be performed using the following
-   sliding, window procedure, borrowed from Section 3.4.3 of [RFC 2402]
-
-   The receiver packet counter for this session MUST be initialized to
-   zero when the session is established. For each received record, the
-
-
-
-Rescorla, Modadugu                                               [Page 8]
-
-
-   receiver MUST verify that the record contains a Sequence Number that
-   does not duplicate the Sequence Number of any other record received
-   during the life of this session. This SHOULD be the first check
-   applied to a packet after it has been matched to a session, to speed
-   rejection of duplicate records.
-
-   Duplicates are rejected through the use of a sliding receive window.
-   (How the window is implemented is a local matter, but the following
-   text describes the functionality that the implementation must
-   exhibit.) A minimum window size of 32 MUST be supported; but a window
-   size of 64 is preferred and SHOULD be employed as the default.
-   Another window size (larger than the minimum) MAY be chosen by the
-   receiver. (The receiver does not notify the sender of the window
-   size.)
-
-   The "right" edge of the window represents the highest, validated
-   Sequence Number value received on this session. Records that contain
-   Sequence Numbers lower than the "left" edge of the window are
-   rejected. Packets falling within the window are checked against a
-   list of received packets within the window. An efficient means for
-   performing this check, based on the use of a bit mask, is described
-   in Appendix C of [RFC 2401].
-
-   If the received record falls within the window and is new, or if the
-   packet is to the right of the window, then the receiver proceeds to
-   MAC verification. If the MAC validation fails, the receiver MUST
-   discard the received record as invalid. The receive window is updated
-   only if the MAC verification succeeds.
-
-4.2. The DTLS Handshake Protocol
-
-   DTLS uses all of the same handshake messages and flows as TLS, with
-   three principal changes:
-
-      1. A stateless cookie exchange has been added to prevent denial of
-      service attacks.
-
-      2. Modifications to the handshake header to handle message loss,
-      reordering and fragmentation.
-
-      3. Retransmission timers to handle message loss.
-
-   With these exceptions, the DTLS message formats, flows, and logic are
-   the same as those of TLS 1.1.
-
-
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 9]
-
-
-4.2.1. Denial of Service Countermeasures
-
-   Datagram security protocols are extremely susceptible to a variety of
-   denial of service (DoS) attacks. Two attacks are of particular
-   concern:
-
-      1. An attacker can consume excessive resources on the server by
-      transmitting a series of handshake initiation requests, causing
-      the server to allocate state and potentially perform expensive
-      cryptographic operations.
-
-      2. An attacker can use the server as an amplifier by sending
-      connection initiation messages with a forged source of the victim.
-      The server then sends its next message (in DTLS, a Certificate
-      message, which can be quite large) to the victim machine, thus
-      flooding it.
-
-   In order to prevent both of these attacks, DTLS borrows the stateless
-   cookie technique used by Photuris [PHOTURIS] and IKEv2 [IKE]. When
-   the client sends its ClientHello message to the server, the server
-   MAY respond with a HelloVerifyRequest message. This message contains
-   a stateless cookie generated using the technique of [PHOTURIS]. The
-   client MUST retransmit the ClientHello with the cookie added. The
-   server then verifies the cookie and proceeds with the handshake only
-   if it is valid.
-
-   The exchange is shown below:
-
-         Client                                   Server
-         ------                                   ------
-         ClientHello           ------>
-
-                               <----- HelloVerifyRequest
-                                      (contains cookie)
-
-         ClientHello           ------>
-         (with cookie)
-
-         [Rest of handshake]
-
-   DTLS therefore modifies the ClientHello message to add the cookie
-   value.
-
-      struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        Cookie cookie<0..32>;                 // New field
-
-
-
-Rescorla, Modadugu                                              [Page 10]
-
-
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-      } ClientHello;
-
-   If the client does not have a cookie for a given server, it should
-   use a zero-length cookie.
-
-   The definition of HelloVerifyRequest is as follows:
-
-      struct {
-        Cookie cookie<0..32>;
-      } HelloVerifyRequest;
-
-   The HelloVerifyRequest message type is hello_verify_request(3).
-
-   When responding to a HelloVerifyRequest the client MUST use the same
-   parameter values (version, random, session_id, cipher_suites,
-   compression_method) as in the original ClientHello. The server SHOULD
-   use those values to generate its cookie and verify that they are
-   correct upon cookie receipt.
-
-   Although DTLS servers are not required to do a cookie exchange, they
-   SHOULD do so whenever a new handshake is performed in order to avoid
-   being used as amplifiers. If the server is being operated in an
-   environment where amplification is not a problem, the server MAY
-   choose not to perform a cookie exchange. In addition, the server MAY
-   choose not do to a cookie exchange when a session is resumed. Clients
-   MUST be prepared to do a cookie exchange with every handshake.
-
-4.2.2. Handshake Message Format
-
-   In order to support message loss, reordering, and fragmentation DTLS
-   modifies the TLS 1.1 handshake header:
-
-      struct {
-        HandshakeType msg_type;
-        uint24 length;
-        uint16 message_seq;                              // New field
-        uint24 fragment_offset;                          // New field
-        uint24 fragment_length;                          // New field
-        select (HandshakeType) {
-      case hello_request: HelloRequest;
-      case client_hello:  ClientHello;
-      case hello_verify_request: HelloVerifyRequest;     // New type
-      case server_hello:  ServerHello;
-      case certificate:Certificate;
-      case server_key_exchange: ServerKeyExchange;
-      case certificate_request: CertificateRequest;
-
-
-
-Rescorla, Modadugu                                              [Page 11]
-
-
-      case server_hello_done:ServerHelloDone;
-      case certificate_verify:  CertificateVerify;
-      case client_key_exchange: ClientKeyExchange;
-      case finished:Finished;
-        } body;
-      } Handshake;
-
-   The first message each side transmits in each handshake always has
-   message_seq = 0. Whenever each new message is generated, the
-   message_seq value is incremented by one. When a message is
-   retransmitted, the same message_seq value is used. For example.
-
-      Client                             Server
-      ------                             ------
-      ClientHello (seq=0)  ------>
-
-                              X<-- HelloVerifyRequest (seq=0)
-                                              (lost)
-
-      [Timer Expires]
-
-      ClientHello (seq=0)  ------>
-      (retransmit)
-
-                           <------ HelloVerifyRequest (seq=0)
-
-      ClientHello (seq=1)  ------>
-      (with cookie)
-
-                           <------        ServerHello (seq=1)
-                           <------        Certificate (seq=2)
-                           <------    ServerHelloDone (seq=3)
-
-      [Rest of handshake]
-
-   DTLS implementations maintain (at least notionally) a
-   next_receive_seq counter. This counter is initially set to zero. When
-   a message is received, if its sequence number matches
-   next_receive_seq, next_receive_seq is incremented and the message is
-   processed. If the sequence number is less than next_receive_seq the
-   message MUST be discarded. If the sequence number is greater than
-   next_receive_seq, the implementation SHOULD queue the message but MAY
-   discard it. (This is a simple space/bandwidth tradeoff).
-
-4.2.3. Message Fragmentation and Reassembly
-
-   As noted in Section 4.1.1., each DTLS message MUST fit within a
-   single transport layer datagram. However, handshake messages are
-
-
-
-Rescorla, Modadugu                                              [Page 12]
-
-
-   potentially bigger than the maximum record size. Therefore DTLS
-   provides a mechanism for fragmenting a handshake message over a
-   number of records.
-
-   When transmitting the handshake message, the sender divides the
-   message into a series of N contiguous data ranges. These range MUST
-   NOT be larger than the maximum handshake fragment size and MUST
-   jointly contain the entire handshake message. The ranges SHOULD NOT
-   overlap. The sender then creates N handshake messages, all with the
-   same message_seq value as the original handshake message. Each new
-   message is labelled with the fragment_offset (the number of bytes
-   contained in previous fragments) and the fragment_length (the length
-   of this fragment). The length field in all messages is the same as
-   the length field of the original message. An unfragmented message is
-   a degenerate case with fragment_offset=0 and fragment_length=length.
-
-   When a DTLS implementation receives a handshake message fragment, it
-   MUST buffer it until it has the entire handshake message. DTLS
-   implementations MUST be able to handle overlapping fragment ranges.
-   This allows senders to retransmit handshake messages with smaller
-   fragment sizes during path MTU discovery.
-
-   Note that as with TLS, multiple handshake messages may be placed in
-   the same DTLS record, provided that there is room and that they are
-   part of the same flight. Thus, there are two acceptable ways to pack
-   two DTLS messages into the same datagram: in the same record or in
-   separate records.
-
-4.2.4. Timeout and Retransmission
-
-   DTLS messages are grouped into a series of message flights, according
-   the diagrams below. Although each flight of messages may consist of a
-   number of messages, they should be viewed as monolithic for the
-   purpose of timeout and retransmission.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 13]
-
-
-      Client                                          Server
-      ------                                          ------
-
-      ClientHello             -------->                           Flight 1
-
-                              <-------    HelloVerifyRequest      Flight 2
-
-     ClientHello              -------->                           Flight 3
-
-                                                 ServerHello    \
-                                                Certificate*     \
-                                          ServerKeyExchange*      Flight 4
-                                         CertificateRequest*     /
-                              <--------      ServerHelloDone    /
-
-      Certificate*                                              \
-      ClientKeyExchange                                          \
-      CertificateVerify*                                          Flight 5
-      [ChangeCipherSpec]                                         /
-      Finished                -------->                         /
-
-                                          [ChangeCipherSpec]    \ Flight 6
-                              <--------             Finished    /
-               Figure 1: Message flights for full handshake
-
-
-      Client                                           Server
-      ------                                           ------
-
-      ClientHello             -------->                          Flight 1
-
-                                                 ServerHello    \
-                                          [ChangeCipherSpec]     Flight 2
-                               <--------             Finished    /
-
-      [ChangeCipherSpec]                                         \Flight 3
-      Finished                 -------->                         /
-   Figure 2: Message flights for session resuming handshake (no cookie exchange)
-
-
-   DTLS uses a simple timeout and retransmission scheme with the
-   following state machine. Because DTLS clients send the first message
-   (ClientHello) they start in the PREPARING state. DTLS servers start
-   in the WAITING state, but with empty buffers and no retransmit timer.
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 14]
-
-
-                   +-----------+
-                   | PREPARING |
-             +---> |           |
-             |     |           |
-             |     +-----------+
-             |           |
-             |           |
-             |           | Buffer next flight
-             |           |
-             |          \|/
-             |     +-----------+
-             |     |           |
-             |     |  SENDING  |<------------------+
-             |     |           |                   |
-             |     +-----------+                   |
-     Receive |           |                         |
-        next |           | Send flight             |
-      flight |  +--------+                         |
-             |  |        | Set retransmit timer    |
-             |  |       \|/                        |
-             |  |  +-----------+                   |
-             |  |  |           |                   |
-             +--)--|  WAITING  |-------------------+
-             |  |  |           |   Timer expires   |
-             |  |  +-----------+                   |
-             |  |         |                        |
-             |  |         |                        |
-             |  |         +------------------------+
-             |  |                Read retransmit
-     Receive |  |
-        last |  |
-      flight |  |
-             |  |
-            \|/\|/
-
-         +-----------+
-         |           |
-         | FINISHED  |
-         |           |
-         +-----------+
-
-          Figure 3: DTLS timeout and retransmission state machine
-
-
-   The state machine has three basic states.
-
-   In the PREPARING state the implementation does whatever computations
-   are necessary to prepare the next flight of messages. It then buffers
-
-
-
-Rescorla, Modadugu                                              [Page 15]
-
-
-   them up for transmission (emptying the buffer first) and enters the
-   SENDING state.
-
-   In the SENDING state, the implementation transmits the buffered
-   flight of messages. Once the messages have been sent, the
-   implementation then enters the FINISHED state if this is the last
-   flight in the handshake, or, if the implementation expects to receive
-   more messages, sets a retransmit timer and then enters the WAITING
-   state.
-
-   There are three ways to exit the WAITING state:
-
-      1. The retransmit timer expires: the implementation transitions to
-      the SENDING state, where it retransmits the flight, resets the
-      retransmit timer, and returns to the WAITING state.
-
-      2. The implementation reads a retransmitted flight from the peer:
-      the implementation transitions to the SENDING state, where it
-      retransmits the flight, resets the retransmit timer, and returns
-      to the WAITING state. The rationale here is that the receipt of a
-      duplicate message is the likely result of timer expiry on the peer
-      and therefore suggests that part of one's previous flight was
-      lost.
-
-      3. The implementation receives the next flight of messages: if
-      this is the final flight of messages the implementation
-      transitions to FINISHED. If the implementation needs to send a new
-      flight, it transitions to the PREPARING state. Partial reads
-      (whether partial messages or only some of the messages in the
-      flight) do not cause state transitions or timer resets.
-
-
-4.2.4.1. Timer Values
-
-   Timer value choices are a local matter. We RECOMMEND that
-   implementations use an initial timer value of 500 ms and double the
-   value at each retransmission, up to twice the TCP Maximum Segment
-   Lifetime. [TCP] Implementations SHOULD start the timer value at the
-   initial value with each new flight of messages.
-
-4.2.5. ChangeCipherSpec
-
-   As with TLS, the ChangeCipherSpec message is not technically a
-   handshake message but MUST be treated as part of the same flight as
-   the associated Finished message for the purposes of timeout and
-   retransmission.
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 16]
-
-
-4.2.6. Finished messages
-
-   Finished messages have the same format as in TLS. However, in order
-   to remove sensitivity to fragmentation, the Finished MAC MUST be
-   computed as if each handshake message had been sent as a single
-   fragment. Note that in cases where the cookie exchange is used, the
-   initial ClientHello and HelloVerifyRequest MUST BE included in the
-   Finished MAC.
-
-
-
-A.1Summary of new syntax
-
-   This section includes specifications for the data structures that
-   have changed between TLS 1.1 and DTLS.
-
-4.2. Record Layer
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     opaque fragment[DTLSPlaintext.length];
-   } DTLSPlaintext;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     opaque fragment[DTLSCompressed.length];
-   } DTLSCompressed;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     select (CipherSpec.cipher_type) {
-   case block:  GenericBlockCipher;
-     } fragment;
-   } DTLSCiphertext;
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 17]
-
-
-4.3. Handshake Protocol
-
-   enum {
-     hello_request(0), client_hello(1), server_hello(2),
-     hello_verify_request(3),                        // New field
-     certificate(11), server_key_exchange (12),
-     certificate_request(13), server_hello_done(14),
-     certificate_verify(15), client_key_exchange(16),
-     finished(20), (255)
-   } HandshakeType;
-
-   struct {
-     HandshakeType msg_type;
-     uint24 length;
-     uint16 message_seq;                             // New field
-     uint24 fragment_offset;                         // New field
-     uint24 fragment_length;                         // New field
-     select (HandshakeType) {
-   case hello_request: HelloRequest;
-   case client_hello:  ClientHello;
-   case server_hello:  ServerHello;
-   case hello_verify_request: HelloVerifyRequest;    // New field
-   case certificate:Certificate;
-   case server_key_exchange: ServerKeyExchange;
-   case certificate_request: CertificateRequest;
-   case server_hello_done:ServerHelloDone;
-   case certificate_verify:  CertificateVerify;
-   case client_key_exchange: ClientKeyExchange;
-   case finished:Finished;
-     } body;
-   } Handshake;
-
-   struct {
-     Cookie cookie<H0..32>;
-   } HelloVerifyRequest;
-
-5. Security Considerations
-
-   This document describes a variant of TLS 1.1 and therefore most of
-   the security considerations are the same as those of TLS 1.1 [TLS11],
-   described in Appendices D, E, and F.
-
-   The primary additional security consideration raised by DTLS is that
-   of denial of service. DTLS includes a cookie exchange designed to
-   protect against denial of service. However, implementations which do
-   not use this cookie exchange are still vulnerable to DoS. In
-   particular, DTLS servers which do not use the cookie exchange may be
-   used as attack amplifiers even if they themselves are not
-
-
-
-Rescorla, Modadugu                                              [Page 18]
-
-
-   experiencing DoS. Therefore DTLS servers SHOULD use the cookie
-   exchange unless there is good reason to believe that amplification is
-   not a threat in their environment.
-
-6. IANA Considerations
-
-   This document uses the same identifier space as TLS [TLS11], so no
-   IANA registries are required beyond those for TLS. Identifiers MAY
-   NOT be assigned for DTLS that conflict with TLS. When new identifiers
-   are assigned for TLS, authors MUST specify whether they are suitable
-   for DTLS.
-
-References
-
-Normative References
-
-   [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
-              Protocol", RFC 2521, March 1999.
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [REQ]
-
-   [RFC1191]  Mogul, J. C., Deering, S.E., "Path MTU Discovery",
-              RFC 1191, November 1990.
-
-   [RFC2401]  Kent, S., Atkinson, R., "Security Architecture for the
-              Internet Protocol", RFC2401, November 1998.
-
-   [TCP]      Postel, J., "Transmission Control Protocol",
-              RFC 793, September 1981.
-
-   [TLS]      Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [TLS11]    Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
-              draft-ietf-tls-rfc2246-bis-05.txt, July 2003.
-
-
-Informative References
-
-   [AH]       Kent, S., and Atkinson, R., "IP Authentication Header",
-              RFC 2402, November 1998.
-
-   [DCCP]     Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
-              Congestion Control Protocol", draft-ietf-dccp-spec-05.txt,
-              October 2003
-
-
-
-Rescorla, Modadugu                                              [Page 19]
-
-
-   [DTLS]     Modadugu, N., Rescorla, E., "The Design and Implementation
-              of Datagram TLS", in Proceedings of ISOC NDSS 2004,
-              February 2004.
-
-   [ESP]      Kent, S., and Atkinson, R., "IP Encapsulating Security
-              Payload (ESP)", RFC 2406, November 1998.
-
-
-   [IKE]      Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
-              RFC 2409, November 1998.
-
-   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
-              4rev1", RFC 3501, March 2003.
-
-   [POP]      Myers, J., and Rose, M., "Post Office Protocol -
-              Version 3", RFC 1939, May 1996.
-
-
-   [SIP]      Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A.,
-              Peterson, J., Sparks, R., Handley, M., Schooler, E.,
-              "SIP: Session Initiation Protocol", RFC 3261,
-              June 2002.
-
-   [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
-              draft-bellovin-useipsec-02.txt, October 2003
-
-Authors' Address
-
-   Eric Rescorla <ekr@rtfm.com>
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto, CA 94303
-
-   Nagendra Modadugu <nagendra@cs.stanford.edu>
-   Computer Science Department
-   353 Serra Mall
-   Stanford University
-   Stanford, CA 94305
-
-
-
-Acknowledgements
-
-   The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley,
-   Constantine Sapuntzakis, and Hovav Shacham for discussions and
-   comments on the design of DTLS. Thanks to the anonymous NDSS
-   reviewers of our original NDSS paper on DTLS [DTLS] for their
-   comments. Also, thanks to Steve Kent for feedback that helped clarify
-
-
-
-Rescorla, Modadugu                                              [Page 20]
-
-
-   many points. The section on PMTU was cribbed from the DCCP
-   specification [DCCP].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 21]
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 22]
-
diff --git a/doc/protocol/draft-rescorla-dtls-04.txt b/doc/protocol/draft-rescorla-dtls-04.txt
deleted file mode 100644
index 5d7ee14b6f..0000000000
--- a/doc/protocol/draft-rescorla-dtls-04.txt
+++ /dev/null
@@ -1,1338 +0,0 @@
-                                                           E. Rescorla
-                                                              RTFM, Inc.
-                                                             N. Modadugu
-INTERNET-DRAFT                                       Stanford University
-<draft-rescorla-dtls-04.txt>           April 2004 (Expires October 2005)
-
-                   Datagram Transport Layer Security
-
-Status of this Memo
-
-By submitting this Internet-Draft, each author represents that any
-applicable patent or other IPR claims of which he or she is aware
-have been or will be disclosed, and any of which he or she becomes
-aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-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/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999-2004). All Rights Reserved.
-
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 1]
-
-
-Abstract
-
-   This document specifies Version 1.0 of the Datagram Transport
-   Layer Security (DTLS) protocol. The DTLS protocol provides
-   communications privacy for datagram protocols. The protocol
-   allows client/server applications to communicate in a way that
-   is designed to prevent eavesdropping, tampering, or message
-   forgery. The DTLS protocol is based on the TLS protocol and
-   provides equivalent security guarantees. Datagram semantics of
-   the underlying transport are preserved by the DTLS protocol.
-
-
-Contents
-
-   1           Introduction                                          3
-     1.1         Requirements Terminology                            3
-   2           Usage Model                                           4
-   3           Overview of DTLS                                      4
-     3.1         Loss-insensitive messaging                          4
-     3.2         Providing Reliability for Handshake                 5
-       3.2.1       Packet Loss                                       5
-       3.2.2       Reordering                                        6
-       3.2.3       Message Size                                      6
-     3.3         Replay Detection                                    6
-   4           Differences from TLS                                  6
-     4.1         Record Layer                                        7
-       4.1.1       Transport Layer Mapping                           8
-         4.1.1.1     PMTU Discovery                                  8
-       4.1.2       Record payload protection                         9
-         4.1.2.1     MAC                                             9
-         4.1.2.2     Null or standard stream cipher                  9
-         4.1.2.3     Block Cipher                                   10
-         4.1.2.4     New Cipher Suites                              10
-         4.1.2.5     Anti-Replay                                    10
-     4.2         The DTLS Handshake Protocol                        11
-       4.2.1       Denial of Service Countermeasures                11
-       4.2.2       Handshake Message Format                         13
-       4.2.3       Message Fragmentation and Reassembly             15
-       4.2.4       Timeout and Retransmission                       16
-         4.2.4.1     Timer Values                                   19
-       4.2.5       ChangeCipherSpec                                 20
-       4.2.6       Finished messages                                20
-       4.2.7       Alert Messages                                   20
-     4.2         Record Layer                                       20
-     4.3         Handshake Protocol                                 21
-   5           Security Considerations                              22
-   6           IANA Considerations                                  22
-
-
-
-
-Rescorla, Modadugu                                               [Page 2]
-
-
-1. Introduction
-
-   TLS [TLS] is the most widely deployed protocol for securing
-   network traffic. It is widely used for protecting Web traffic
-   and for e-mail protocols such as IMAP [IMAP] and POP [POP].
-   The primary advantage of TLS is that it provides a transparent
-   connection-oriented channel. Thus, it is easy to secure an
-   application protocol by inserting TLS between the application
-   layer and the transport layer. However, TLS must run over a
-   reliable transport channel--typically TCP [TCP]. It therefore
-   cannot be used to secure unreliable datagram traffic.
-
-   However, over the past few years an increasing number of
-   application layer protocols have been designed which UDP
-   transport. In particular such protocols as the Session
-   Initiation Protocol (SIP) [SIP], and electronic gaming
-   protocols are increasingly popular. (Note that SIP can run
-   over both TCP and UDP, but that there are situations in which
-   UDP is preferable). Currently, designers of these applications
-   are faced with a number of unsatisfactory choices. First, they
-   can use IPsec [RFC2401]. However, for a number of reasons
-   detailed in [WHYIPSEC], this is only suitable for some
-   applications. Second, they can design a custom application
-   layer security protocol. SIP, for instance, uses a subsert of
-   S/MIME to secure its traffic. Unfortunately, while application
-   layer security protocols generally provide superior security
-   properties (e.g., end-to-end security in the case of S/MIME)
-   it typically require a large amount of effort to design--by
-   contrast to the relatively small amount of effort required to
-   run the protocol over TLS.
-
-   In many cases, the most desirable way to secure client/server
-   applications would be to use TLS; however the requirement for
-   datagram semantics automatically prohibits use of TLS. Thus, a
-   datagram-compatible variant of TLS would be very desirable.
-   This memo describes such a protocol: Datagram Transport Layer
-   Security (DTLS). DTLS is deliberately designed to be as
-   similar to to TLS as possible, both to minimize new security
-   invention and to maximize the amount of code and
-   infrastructure reuse.
-
-
-1.1. Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
-   NOT" and "MAY" that appear in this document are to be
-   interpreted as described in RFC 2119 [REQ].
-
-
-
-
-Rescorla, Modadugu                                               [Page 3]
-
-
-2. Usage Model
-
-   The DTLS protocol is designed to secure data between
-   communicating applications. It is designed to run in
-   application space, without requiring any kernel modifications.
-
-   Datagram transport does not require or provide reliable or in-
-   order delivery of data. The DTLS protocol preserves this
-   property for payload data. Applications such as media
-   streaming, Internet telephony and online gaming use datagram
-   transport for communication due to the delay-sensitive nature
-   of transported data. The behavior of such applications is
-   unchanged when the DTLS protocol is used to secure
-   communication, since the DTLS protocol does not compensate for
-   lost or re-ordered data traffic.
-
-3. Overview of DTLS
-
-   The basic design philosophy of DTLS is to construct "TLS over
-   datagram". The reason that TLS cannot be used directly in
-   datagram environments is simply that packets may be lost or
-   reordered. TLS has no internal facilities to handle this kind
-   of unreliability and therefore TLS implementations break when
-   rehosted on datagram transport. The purpose of DTLS is to make
-   only the minimal changes to TLS required to fix this problem.
-   To the greatest extent possible, DTLS is identical to TLS.
-   Whenever we need to invent new mechanisms, we attempt to do so
-   in such a way that it preserves the style of TLS.
-
-   Unreliability creates problems for TLS at two levels:
-
-      1. TLS's traffic encryption layer does not allow
-      independent decryption of individual records. If record N
-      is not received, then record N+1 cannot be decrypted.
-
-      2. The TLS handshake layer assumes that handshake messages
-      are delivered reliably and breaks if those messages are
-      lost.
-
-   The rest of this section describes the approach that DTLS uses
-   to solve these problems.
-
-3.1. Loss-insensitive messaging
-
-   In TLS's traffic encryption layer (called the TLS Record
-   Layer), records are not independent. There are two kinds of
-   inter-record dependency:
-
-
-
-
-Rescorla, Modadugu                                               [Page 4]
-
-
-      1. Cryptographic context (CBC state, stream cipher key
-      stream) is chained between records.
-
-      2. Anti-replay and message reordering protection are
-      provided by a MAC which includes a sequence number, but the
-      sequence numbers are implicit in the records.
-
-   The fix for both of these problems is straightforward and
-   well-known from IPsec ESP [ESP]: add explicit state to the
-   records. TLS 1.1 [TLS11] is already adding explicit CBC state
-   to TLS records. DTLS borrows that mechanism and adds explicit
-   sequence numbers.
-
-3.2. Providing Reliability for Handshake
-
-   The TLS handshake is a lockstep cryptographic handshake.
-   Messages must be transmitted and received in a defined order
-   and any other order is an error. Clearly, this is incompatible
-   with reordering and message loss. In addition, TLS handshake
-   messages are potentially larger than any given datagram, thus
-   creating the problem of fragmentation. DTLS must provide fixes
-   for both these problems.
-
-3.2.1. Packet Loss
-
-   DTLS uses a simple retransmission timer to handle packet loss.
-   The following figure demonstrates the basic concept using the
-   first phase of the DTLS handshake:
-
-      Client                                   Server
-      ------                                   ------
-      ClientHello           ------>
-
-                              X<-- HelloVerifyRequest
-                                               (lost)
-
-      [Timer Expires]
-
-      ClientHello           ------>
-      (retransmit)
-
-   Once the client has transmitted the ClientHello message, it
-   expects to see a HelloVerifyRequest from the server. However,
-   if the server's message is lost the client knows that either
-   the ClientHello or the HelloVerifyRequest has been lost and
-   retransmits. When the server receives the retransmission, it
-   knows to retransmit. The server also maintains a
-   retransmission timer and retransmits when that timer expires.
-
-
-
-Rescorla, Modadugu                                               [Page 5]
-
-
-   Note: timeout and retransmission do not apply to the
-   HelloVerifyRequest, because this requires creating state on
-   the server.
-
-3.2.2. Reordering
-
-   In DTLS, each handshake message is assigned a specific
-   sequence number within that handshake. When a peer receives a
-   handshake message, it can quickly determine whether that
-   message is the next message it expects. If it is, then it
-   processes it. If not, it queues it up for future handling once
-   all previous messages have been received.
-
-3.2.3. Message Size
-
-   TLS and DTLS handshake messages can be quite large (in theory
-   up to 2^24-1 bytes, in practice many kilobytes). By contrast,
-   UDP datagrams are often limited to <1500 bytes if
-   fragmentation is not desired. In order to compensate for this
-   limitation, each DTLS handshake message may be fragmented over
-   several DTLS records. Each DTLS handshake message contains
-   both a fragment offset and a fragment length. Thus, a
-   recipient in possession of all bytes of a handshake message
-   can reassemble the original unfragmented message.
-
-3.3. Replay Detection
-
-   DTLS optionally supports record replay detection. The
-   technique used is the same as in IPsec AH/ESP, by maintaining
-   a bitmap window of received records. Records that are too old
-   to fit in the window and records that have been previously
-   received are silently discarded. The replay detection feature
-   is optional, since packet duplication is not always malicious,
-   but can also occur due to routing errors. Applications may
-   conceivably detect duplicate packets and accordingly modify
-   their data transmission strategy.
-
-4. Differences from TLS
-
-   As mentioned in Section 3., DTLS is intentionally very similar
-   to TLS. Therefore, instead of presenting DTLS as a new
-   protocol, we instead present it as a series of deltas from TLS
-   1.1 [TLS11]. Where we do not explicitly call out differences,
-   DTLS is the same as TLS.
-
-
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 6]
-
-
-4.1. Record Layer
-
-   The DTLS record layer is extremely similar to that of TLS 1.1.
-   The only change is the inclusion of an explicit sequence
-   number in the record. This sequence number allows the
-   recipient to correctly verify the TLS MAC. The DTLS record
-   format is shown below:
-
-       struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 epoch;               // New field
-        uint48 sequence_number;       // New field
-        uint16 length;
-        opaque fragment[DTLSPlaintext.length];
-       } DTLSPlaintext;
-
-      type
-       Equivalent to the type field in a TLS 1.1 record.
-
-      version
-       The version of the protocol being employed. This document
-       describes DTLS Version 1.0, which uses the version { 254, 255
-       }. The version value of 254.255 is the 1's complement of DTLS
-       Version 1.0. This maximal spacing between TLS and DTLS version
-       numbers ensures that records from the two protocols can be
-       easily distinguished.
-
-      epoch
-       A counter value that is incremented on every cipher state
-       change.
-
-      sequence_number
-       The sequence number for this record.
-
-      length
-       Identical to the length field in a TLS 1.1 record. As in TLS
-       1.1, the length should not exceed 2^14.
-
-      fragment
-       Identical to the fragment field of a TLS 1.1 record.
-
-   DTLS uses an explicit rather than implicit sequence number,
-   carried in the sequence_number field of the record. As with
-   TLS, the sequence number is set to zero after each
-   ChangeCipherSpec message is sent.
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 7]
-
-
-   If several handshakes are performed in close succession, there
-   might be multiple records on the wire with the same sequence
-   number but from different cipher states. The epoch field
-   allows recipients to distinguish such packets. The epoch
-   number is initially zero and is incremented each time the
-   ChangeCipherSpec messages is sent. In order to ensure that any
-   given sequence/epoch pair is unique, implementations MUST NOT
-   allow the same epoch value to be reused within two times the
-   TCP maximum segment lifetime. In practice, TLS implementations
-   rehandshake rarely and we therefore do not expect this to be a
-   problem.
-
-4.1.1. Transport Layer Mapping
-
-   Each DTLS record MUST fit within a single datagram. In order
-   to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD
-   determine the MTU and send records smaller than the MTU. DTLS
-   implementations SHOULD provide a way for applications to
-   determine the value of the PMTU (or alternately the maximum
-   application datagram size, which is the PMTU minus the DTLS
-   per-record overhead). If the application attempts to send a
-   record larger than the MTU the DTLS implementation SHOULD
-   generate an error, thus avoiding sending a packet which will
-   be fragmented.
-
-   Note that unlike IPsec, DTLS records do not contain any
-   association identifiers. Applications must arrange to
-   multiplex between associations. With UDP, this is presumably
-   done with host/port number.
-
-   Multiple DTLS records may be placed in a single datagram. hey
-   are simply encoded consecutively. The DTLS record framing is
-   sufficient to determine the boundaries. Note, however, that
-   the first byte of the datagram payload must be the beginning
-   of a record. Records may not span datagrams.
-
-4.1.1.1. PMTU Discovery
-
-   In general, DTLS's philosophy is to avoid dealing with PMTU
-   issues. The general strategy is to start with a conservative
-   MTU and then update it if events require it, but not actively
-   probe for MTU values. PMTU discovery is left to the
-   application.
-
-   The PMTU SHOULD be initialized from the interface MTU that
-   will be used to send packets. If the DTLS implementation
-   receives an RFC 1191 [RFC1191] ICMP Destination Unreachable
-   message with the "fragmentation needed and DF set" Code
-
-
-
-Rescorla, Modadugu                                               [Page 8]
-
-
-   (otherwise known as Datagram Too Big) it should decrease its
-   PMTU estimate to that given in the ICMP message. A DTLS
-   implementation SHOULD allow the application to occasionally
-   reset its PMTU estimate. The DTLS implementation SHOULD also
-   allow applications to control the status of the DF bit. These
-   controls allow the application to perform PMTU discovery.
-
-   One special case is the DTLS handshake system. Handshake
-   messages should be set with DF set. Because some firewalls and
-   routers screen out ICMP messages, it is difficult for the
-   handshake layer to distinguish packet loss from an overlarge
-   PMTU estimate. In order to allow connections under these
-   circumstances, DTLS implementations SHOULD back off handshake
-   packet size during the retransmit backoff described in Section
-   4.2.4.. For instance, if a large packet is being sent, after 3
-   retransmits the handshake layer might choose to fragment the
-   handshake message on retransmission. In general, choice of a
-   conservative initial MTU will avoid this problem.
-
-4.1.2. Record payload protection
-
-   Like TLS, DTLS transmits data as a series of protected
-   records. The rest of this section describes the details of
-   that format.
-
-4.1.2.1. MAC
-
-   The DTLS MAC is the same as that of TLS 1.1. However, rather
-   than using TLS's implicit sequence number, the sequence number
-   used to compute the MAC is the 64-bit value formed by
-   concatenating the epoch and the sequence number in the order
-   they appear on the wire. Note that the DTLS epoch + sequence
-   number is the same length as the TLS sequence number.
-
-   Note that one important difference between DTLS and TLS MAC
-   handling is that in TLS MAC errors must result in connection
-   termination. In DTLS, the receiving implementation MAY simply
-   discard the offending record and continue with the connection.
-   This change is possible because DTLS records are not dependent
-   on each other the way that TLS records are.
-
-
-4.1.2.2. Null or standard stream cipher
-
-   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL
-   cipher.
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 9]
-
-
-   The only stream cipher described in TLS 1.1 is RC4, which
-   cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
-
-4.1.2.3. Block Cipher
-
-   DTLS block cipher encryption and decryption are performed
-   exactly as with TLS 1.1.
-
-4.1.2.4. New Cipher Suites
-
-   Upon registration, new TLS cipher suites MUST indicate whether
-   they are suitable for DTLS usage and what, if any, adaptations
-   must be made.
-
-4.1.2.5. Anti-Replay
-
-   DTLS records contain a sequence number to provide replay
-   protection. Sequence number verification SHOULD be performed
-   using the following sliding, window procedure, borrowed from
-   Section 3.4.3 of [RFC 2402]
-
-   The receiver packet counter for this session MUST be
-   initialized to zero when the session is established. For each
-   received record, the receiver MUST verify that the record
-   contains a Sequence Number that does not duplicate the
-   Sequence Number of any other record received during the life
-   of this session. This SHOULD be the first check applied to a
-   packet after it has been matched to a session, to speed
-   rejection of duplicate records.
-
-   Duplicates are rejected through the use of a sliding receive
-   window. (How the window is implemented is a local matter, but
-   the following text describes the functionality that the
-   implementation must exhibit.) A minimum window size of 32 MUST
-   be supported; but a window size of 64 is preferred and SHOULD
-   be employed as the default. Another window size (larger than
-   the minimum) MAY be chosen by the receiver. (The receiver does
-   not notify the sender of the window size.)
-
-   The "right" edge of the window represents the highest,
-   validated Sequence Number value received on this session.
-   Records that contain Sequence Numbers lower than the "left"
-   edge of the window are rejected. Packets falling within the
-   window are checked against a list of received packets within
-   the window. An efficient means for performing this check,
-   based on the use of a bit mask, is described in Appendix C of
-   [RFC 2401].
-
-
-
-
-Rescorla, Modadugu                                              [Page 10]
-
-
-   If the received record falls within the window and is new, or
-   if the packet is to the right of the window, then the receiver
-   proceeds to MAC verification. If the MAC validation fails, the
-   receiver MUST discard the received record as invalid. The
-   receive window is updated only if the MAC verification
-   succeeds.
-
-4.2. The DTLS Handshake Protocol
-
-   DTLS uses all of the same handshake messages and flows as TLS,
-   with three principal changes:
-
-      1. A stateless cookie exchange has been added to prevent
-      denial of service attacks.
-
-      2. Modifications to the handshake header to handle message
-      loss, reordering and fragmentation.
-
-      3. Retransmission timers to handle message loss.
-
-   With these exceptions, the DTLS message formats, flows, and
-   logic are the same as those of TLS 1.1.
-
-4.2.1. Denial of Service Countermeasures
-
-   Datagram security protocols are extremely susceptible to a
-   variety of denial of service (DoS) attacks. Two attacks are of
-   particular concern:
-
-      1. An attacker can consume excessive resources on the
-      server by transmitting a series of handshake initiation
-      requests, causing the server to allocate state and
-      potentially perform expensive cryptographic operations.
-
-      2. An attacker can use the server as an amplifier by
-      sending connection initiation messages with a forged source
-      of the victim. The server then sends its next message (in
-      DTLS, a Certificate message, which can be quite large) to
-      the victim machine, thus flooding it.
-
-   In order to counter both of these attacks, DTLS borrows the
-   stateless cookie technique used by Photuris [PHOTURIS] and IKE
-   [IKE]. When the client sends its ClientHello message to the
-   server, the server MAY respond with a HelloVerifyRequest
-   message. This message contains a stateless cookie generated
-   using the technique of [PHOTURIS]. The client MUST retransmit
-   the ClientHello with the cookie added. The server then
-   verifies the cookie and proceeds with the handshake only if it
-
-
-
-Rescorla, Modadugu                                              [Page 11]
-
-
-   is valid. This mechanism forces the attacker/client to be able
-   to receive the cookie, which makes DoS attacks with spoofed IP
-   addresses difficult. This mechanism does not provide any
-   defense against DoS attacks mounted from valid IP addresses.
-
-   The exchange is shown below:
-
-         Client                                   Server
-         ------                                   ------
-         ClientHello           ------>
-
-                               <----- HelloVerifyRequest
-                                      (contains cookie)
-
-         ClientHello           ------>
-         (with cookie)
-
-         [Rest of handshake]
-
-   DTLS therefore modifies the ClientHello message to add the
-   cookie value.
-
-      struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        opaque cookie<0..32>;                 // New field
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-      } ClientHello;
-
-   When sending the first ClientHello, the client does not have a
-   cookie yet; in this case, the Cookie field is left empty (zero
-   length).
-
-   The definition of HelloVerifyRequest is as follows:
-
-      struct {
-        Cookie cookie<0..32>;
-      } HelloVerifyRequest;
-
-   The HelloVerifyRequest message type is
-   hello_verify_request(3).
-
-   When responding to a HelloVerifyRequest the client MUST use
-   the same parameter values (version, random, session_id,
-   cipher_suites, compression_method) as in the original
-   ClientHello. The server SHOULD use those values to generate
-
-
-
-Rescorla, Modadugu                                              [Page 12]
-
-
-   its cookie and verify that they are correct upon cookie
-   receipt. The DTLS server SHOULD generate cookies in such a way
-   that they can be verified without retaining any per-client
-   state on the server. One technique is to have a randomly
-   generated secret and generate cookies as:
-   Cookie = HMAC(Secret, Client-IP, Client-Parameters)
-
-   When the second ClientHello is received, the server can verify
-   that the Cookie is valid and that the client can receive
-   packets at the given IP address.
-     One potential attack on this scheme is for the attacker to
-   collect a number of cookies from different addresses and then
-   reuse them to attack the server. The server can defend against
-   this attack by changing the Secret value frequently, thus
-   invalidating those cookies. If the server wishes legitimate
-   clients to be able to handshake through the transition (e.g.,
-   they received a cookie with Secret 1 and then sent the second
-   ClientHello after the server has changed to Secret 2), the
-   server can have a limited window during which it accepts both
-   secrets. [IKEv2] suggests adding a version number to cookies
-   to detect this case. An alternative approach is simply to try
-   verifying with both secrets.
-
-   Although DTLS servers are not required to do a cookie
-   exchange, they SHOULD do so whenever a new handshake is
-   performed in order to avoid being used as amplifiers. If the
-   server is being operated in an environment where amplification
-   is not a problem, the server MAY choose not to perform a
-   cookie exchange. In addition, the server MAY choose not do to
-   a cookie exchange when a session is resumed. Clients MUST be
-   prepared to do a cookie exchange with every handshake.
-
-   If HelloVerifyRequest is used, the initial ClientHello and
-   HelloVerifyRequest are not included in the calculation of the
-   verify_data for the Finished message.
-
-4.2.2. Handshake Message Format
-
-   In order to support message loss, reordering, and
-   fragmentation DTLS modifies the TLS 1.1 handshake header:
-
-      struct {
-        HandshakeType msg_type;
-        uint24 length;
-        uint16 message_seq;                              // New field
-        uint24 fragment_offset;                          // New field
-        uint24 fragment_length;                          // New field
-        select (HandshakeType) {
-
-
-
-Rescorla, Modadugu                                              [Page 13]
-
-
-      case hello_request: HelloRequest;
-      case client_hello:  ClientHello;
-      case hello_verify_request: HelloVerifyRequest;     // New type
-      case server_hello:  ServerHello;
-      case certificate:Certificate;
-      case server_key_exchange: ServerKeyExchange;
-      case certificate_request: CertificateRequest;
-      case server_hello_done:ServerHelloDone;
-      case certificate_verify:  CertificateVerify;
-      case client_key_exchange: ClientKeyExchange;
-      case finished:Finished;
-        } body;
-      } Handshake;
-
-   The first message each side transmits in each handshake always
-   has message_seq = 0. Whenever each new message is generated,
-   the message_seq value is incremented by one. When a message is
-   retransmitted, the same message_seq value is used. For
-   example.
-
-      Client                             Server
-      ------                             ------
-      ClientHello (seq=0)  ------>
-
-                              X<-- HelloVerifyRequest (seq=0)
-                                              (lost)
-
-      [Timer Expires]
-
-      ClientHello (seq=0)  ------>
-      (retransmit)
-
-                           <------ HelloVerifyRequest (seq=0)
-
-      ClientHello (seq=1)  ------>
-      (with cookie)
-
-                           <------        ServerHello (seq=1)
-                           <------        Certificate (seq=2)
-                           <------    ServerHelloDone (seq=3)
-
-      [Rest of handshake]
-
-   Note, however, that from the perspective of the DTLS record
-   layer, the retransmission is a new record. This record will
-   have a new DTLSPlaintext.sequence_number value.
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 14]
-
-
-   DTLS implementations maintain (at least notionally) a
-   next_receive_seq counter. This counter is initially set to
-   zero. When a message is received, if its sequence number
-   matches next_receive_seq, next_receive_seq is incremented and
-   the message is processed. If the sequence number is less than
-   next_receive_seq the message MUST be discarded. If the
-   sequence number is greater than next_receive_seq, the
-   implementation SHOULD queue the message but MAY discard it.
-   (This is a simple space/bandwidth tradeoff).
-
-4.2.3. Message Fragmentation and Reassembly
-
-   As noted in Section 4.1.1., each DTLS message MUST fit within
-   a single transport layer datagram. However, handshake messages
-   are potentially bigger than the maximum record size. Therefore
-   DTLS provides a mechanism for fragmenting a handshake message
-   over a number of records.
-
-   When transmitting the handshake message, the sender divides
-   the message into a series of N contiguous data ranges. These
-   range MUST NOT be larger than the maximum handshake fragment
-   size and MUST jointly contain the entire handshake message.
-   The ranges SHOULD NOT overlap. The sender then creates N
-   handshake messages, all with the same message_seq value as the
-   original handshake message. Each new message is labelled with
-   the fragment_offset (the number of bytes contained in previous
-   fragments) and the fragment_length (the length of this
-   fragment). The length field in all messages is the same as the
-   length field of the original message. An unfragmented message
-   is a degenerate case with fragment_offset=0 and
-   fragment_length=length.
-
-   When a DTLS implementation receives a handshake message
-   fragment, it MUST buffer it until it has the entire handshake
-   message. DTLS implementations MUST be able to handle
-   overlapping fragment ranges. This allows senders to retransmit
-   handshake messages with smaller fragment sizes during path MTU
-   discovery.
-
-   Note that as with TLS, multiple handshake messages may be
-   placed in the same DTLS record, provided that there is room
-   and that they are part of the same flight. Thus, there are two
-   acceptable ways to pack two DTLS messages into the same
-   datagram: in the same record or in separate records.
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 15]
-
-
-4.2.4. Timeout and Retransmission
-
-   DTLS messages are grouped into a series of message flights,
-   according the diagrams below. Although each flight of messages
-   may consist of a number of messages, they should be viewed as
-   monolithic for the purpose of timeout and retransmission.
-
-      Client                                          Server
-      ------                                          ------
-
-      ClientHello             -------->                           Flight 1
-
-                              <-------    HelloVerifyRequest      Flight 2
-
-     ClientHello              -------->                           Flight 3
-
-                                                 ServerHello    \
-                                                Certificate*     \
-                                          ServerKeyExchange*      Flight 4
-                                         CertificateRequest*     /
-                              <--------      ServerHelloDone    /
-
-      Certificate*                                              \
-      ClientKeyExchange                                          \
-      CertificateVerify*                                          Flight 5
-      [ChangeCipherSpec]                                         /
-      Finished                -------->                         /
-
-                                          [ChangeCipherSpec]    \ Flight 6
-                              <--------             Finished    /
-            Figure 1: Message flights for full handshake
-
-
-      Client                                           Server
-      ------                                           ------
-
-      ClientHello             -------->                          Flight 1
-
-                                                 ServerHello    \
-                                          [ChangeCipherSpec]     Flight 2
-                               <--------             Finished    /
-
-      [ChangeCipherSpec]                                         \Flight 3
-      Finished                 -------->                         /
-   Figure 2: Message flights for session resuming handshake (no
-                          cookie exchange)
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 16]
-
-
-   DTLS uses a simple timeout and retransmission scheme with the
-   following state machine. Because DTLS clients send the first
-   message (ClientHello) they start in the PREPARING state. DTLS
-   servers start in the WAITING state, but with empty buffers and
-   no retransmit timer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 17]
-
-
-                   +-----------+
-                   | PREPARING |
-             +---> |           |
-             |     |           |
-             |     +-----------+
-             |           |
-             |           |
-             |           | Buffer next flight
-             |           |
-             |          \|/
-             |     +-----------+
-             |     |           |
-             |     |  SENDING  |<------------------+
-             |     |           |                   |
-             |     +-----------+                   |
-     Receive |           |                         |
-        next |           | Send flight             |
-      flight |  +--------+                         |
-             |  |        | Set retransmit timer    |
-             |  |       \|/                        |
-             |  |  +-----------+                   |
-             |  |  |           |                   |
-             +--)--|  WAITING  |-------------------+
-             |  |  |           |   Timer expires   |
-             |  |  +-----------+                   |
-             |  |         |                        |
-             |  |         |                        |
-             |  |         +------------------------+
-             |  |                Read retransmit
-     Receive |  |
-        last |  |
-      flight |  |
-             |  |
-            \|/\|/
-
-         +-----------+
-         |           |
-         | FINISHED  |
-         |           |
-         +-----------+
-
-      Figure 3: DTLS timeout and retransmission state machine
-
-
-   The state machine has three basic states.
-
-   In the PREPARING state the implementation does whatever
-   computations are necessary to prepare the next flight of
-
-
-
-Rescorla, Modadugu                                              [Page 18]
-
-
-   messages. It then buffers them up for transmission (emptying
-   the buffer first) and enters the SENDING state.
-
-   In the SENDING state, the implementation transmits the
-   buffered flight of messages. Once the messages have been sent,
-   the implementation then enters the FINISHED state if this is
-   the last flight in the handshake, or, if the implementation
-   expects to receive more messages, sets a retransmit timer and
-   then enters the WAITING state.
-
-   There are three ways to exit the WAITING state:
-
-      1. The retransmit timer expires: the implementation
-      transitions to the SENDING state, where it retransmits the
-      flight, resets the retransmit timer, and returns to the
-      WAITING state.
-
-      2. The implementation reads a retransmitted flight from the
-      peer: the implementation transitions to the SENDING state,
-      where it retransmits the flight, resets the retransmit
-      timer, and returns to the WAITING state. The rationale here
-      is that the receipt of a duplicate message is the likely
-      result of timer expiry on the peer and therefore suggests
-      that part of one's previous flight was lost.
-
-      3. The implementation receives the next flight of messages:
-      if this is the final flight of messages the implementation
-      transitions to FINISHED. If the implementation needs to
-      send a new flight, it transitions to the PREPARING state.
-      Partial reads (whether partial messages or only some of the
-      messages in the flight) do not cause state transitions or
-      timer resets.
-
-   Because DTLS clients send the first message (ClientHello) they
-   start in the PREPARING state. DTLS servers start in the
-   WAITING state, but with empty buffers and no retransmit timer.
-
-4.2.4.1. Timer Values
-
-   Timer value choices are a local matter. Implementations SHOULD
-   use an initial timer value of 500 ms and double the value at
-   each retransmission, up to twice the TCP maximum segment
-   lifetime [TCP] (if the recommendations in [TCP] are followed,
-   this will be 240 seconds). Implementations SHOULD start the
-   timer value at the initial value with each new flight of
-   messages.
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 19]
-
-
-4.2.5. ChangeCipherSpec
-
-   As with TLS, the ChangeCipherSpec message is not technically a
-   handshake message but MUST be treated as part of the same
-   flight as the associated Finished message for the purposes of
-   timeout and retransmission.
-
-4.2.6. Finished messages
-
-   Finished messages have the same format as in TLS. However, in
-   order to remove sensitivity to fragmentation, the Finished MAC
-   MUST be computed as if each handshake message had been sent as
-   a single fragment. Note that in cases where the cookie
-   exchange is used, the initial ClientHello and
-   HelloVerifyRequest MUST BE included in the Finished MAC.
-
-4.2.7. Alert Messages
-
-   Note that Alert messages are not retransmitted at all, even
-   when they occur in the context of a handshake. However, a DTLS
-   implementation SHOULD generate a new alert message if the
-   offending record is received again (e.g., as a retransmitted
-   handshake message).
-
-
-
-A.1Summary of new syntax
-
-   This section includes specifications for the data structures
-   that have changed between TLS 1.1 and DTLS.
-
-4.2. Record Layer
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     opaque fragment[DTLSPlaintext.length];
-   } DTLSPlaintext;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     opaque fragment[DTLSCompressed.length];
-
-
-
-Rescorla, Modadugu                                              [Page 20]
-
-
-   } DTLSCompressed;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     select (CipherSpec.cipher_type) {
-   case block:  GenericBlockCipher;
-     } fragment;
-   } DTLSCiphertext;
-
-4.3. Handshake Protocol
-
-   enum {
-     hello_request(0), client_hello(1), server_hello(2),
-     hello_verify_request(3),                        // New field
-     certificate(11), server_key_exchange (12),
-     certificate_request(13), server_hello_done(14),
-     certificate_verify(15), client_key_exchange(16),
-     finished(20), (255)
-   } HandshakeType;
-
-   struct {
-     HandshakeType msg_type;
-     uint24 length;
-     uint16 message_seq;                             // New field
-     uint24 fragment_offset;                         // New field
-     uint24 fragment_length;                         // New field
-     select (HandshakeType) {
-   case hello_request: HelloRequest;
-   case client_hello:  ClientHello;
-   case server_hello:  ServerHello;
-   case hello_verify_request: HelloVerifyRequest;    // New field
-   case certificate:Certificate;
-   case server_key_exchange: ServerKeyExchange;
-   case certificate_request: CertificateRequest;
-   case server_hello_done:ServerHelloDone;
-   case certificate_verify:  CertificateVerify;
-   case client_key_exchange: ClientKeyExchange;
-   case finished:Finished;
-     } body;
-   } Handshake;
-
-   struct {
-     ProtocolVersion client_version;
-     Random random;
-
-
-
-Rescorla, Modadugu                                              [Page 21]
-
-
-     SessionID session_id;
-     opaque cookie<0..32>;                 // New field
-     CipherSuite cipher_suites<2..2^16-1>;
-     CompressionMethod compression_methods<1..2^8-1>;
-   } ClientHello;
-
-   struct {
-     Cookie cookie<0..32>;
-   } HelloVerifyRequest;
-
-5. Security Considerations
-
-   This document describes a variant of TLS 1.1 and therefore
-   most of the security considerations are the same as those of
-   TLS 1.1 [TLS11], described in Appendices D, E, and F.
-
-   The primary additional security consideration raised by DTLS
-   is that of denial of service. DTLS includes a cookie exchange
-   designed to protect against denial of service. However,
-   implementations which do not use this cookie exchange are
-   still vulnerable to DoS. In particular, DTLS servers which do
-   not use the cookie exchange may be used as attack amplifiers
-   even if they themselves are not experiencing DoS. Therefore
-   DTLS servers SHOULD use the cookie exchange unless there is
-   good reason to believe that amplification is not a threat in
-   their environment.
-
-6. IANA Considerations
-
-   This document uses the same identifier space as TLS [TLS11],
-   so no new IANA registries are required. When new identifiers
-   are assigned for TLS, authors MUST specify whether they are
-   suitable for DTLS.
-
-   This document defines a new handshake message,
-   hello_verify_request, whose value is to be allocated from the
-   TLS HandshakeType registry defined in [TLS11]. The value "3"
-   is suggested.
-
-References
-
-Normative References
-
-   [RFC1191]  Mogul, J. C., Deering, S.E., "Path MTU Discovery",
-              RFC 1191, November 1990.
-
-   [RFC2401]  Kent, S., Atkinson, R., "Security Architecture for the
-              Internet Protocol", RFC2401, November 1998.
-
-
-
-Rescorla, Modadugu                                              [Page 22]
-
-
-   [TCP]      Postel, J., "Transmission Control Protocol",
-              RFC 793, September 1981.
-
-   [TLS11]    Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
-              draft-ietf-tls-rfc2246-bis-05.txt, July 2003.
-
-
-Informative References
-
-   [AH]       Kent, S., and Atkinson, R., "IP Authentication Header",
-              RFC 2402, November 1998.
-
-   [DCCP]     Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
-              Congestion Control Protocol", draft-ietf-dccp-spec-11.txt,
-              10 March 2005
-
-   [DNS]      Mockapetris, P.V., "Domain names - implementation and
-              specification", RFC 1035, November 1987.
-
-   [DTLS]     Modadugu, N., Rescorla, E., "The Design and Implementation
-              of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
-
-   [ESP]      Kent, S., and Atkinson, R., "IP Encapsulating Security
-              Payload (ESP)", RFC 2406, November 1998.
-
-
-   [IKE]      Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
-              RFC 2409, November 1998.
-
-   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              draft-ietf-ipsec-ikev2-17.txt, September 2004.
-
-   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
-              4rev1", RFC 3501, March 2003.
-
-   [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
-              Protocol", RFC 2521, March 1999.
-
-
-   [POP]      Myers, J., and Rose, M., "Post Office Protocol -
-              Version 3", RFC 1939, May 1996.
-
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [SIP]      Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A.,
-
-
-
-Rescorla, Modadugu                                              [Page 23]
-
-
-              Peterson, J., Sparks, R., Handley, M., Schooler, E.,
-              "SIP: Session Initiation Protocol", RFC 3261,
-              June 2002.
-
-   [TLS]      Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
-              draft-bellovin-useipsec-02.txt, October 2003
-
-Authors' Address
-
-   Eric Rescorla <ekr@rtfm.com>
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto, CA 94303
-
-   Nagendra Modadugu <nagendra@cs.stanford.edu>
-   Computer Science Department
-   353 Serra Mall
-   Stanford University
-   Stanford, CA 94305
-
-
-
-Acknowledgements
-
-   The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ
-   Housley, Constantine Sapuntzakis, and Hovav Shacham for
-   discussions and comments on the design of DTLS. Thanks to the
-   anonymous NDSS reviewers of our original NDSS paper on DTLS
-   [DTLS] for their comments. Also, thanks to Steve Kent for
-   feedback that helped clarify many points. The section on PMTU
-   was cribbed from the DCCP specification [DCCP]. Pasi Eronen
-   provided a detailed review of this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 24]
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 25]
-
diff --git a/doc/protocol/draft-rescorla-dtls-05.txt b/doc/protocol/draft-rescorla-dtls-05.txt
deleted file mode 100644
index ba75c2ad99..0000000000
--- a/doc/protocol/draft-rescorla-dtls-05.txt
+++ /dev/null
@@ -1,1393 +0,0 @@
-
-                                                             E. Rescorla
-                                                              RTFM, Inc.
-                                                             N. Modadugu
-INTERNET-DRAFT                                       Stanford University
-<draft-rescorla-dtls-05.txt>           June 2004 (Expires December 2005)
-
-                   Datagram Transport Layer Security
-
-Status of this Memo
-
-By submitting this Internet-Draft, each author represents that any
-applicable patent or other IPR claims of which he or she is aware
-have been or will be disclosed, and any of which he or she becomes
-aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-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/1id-abstracts.html
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 1]
-
-
-Abstract
-
-   This document specifies Version 1.0 of the Datagram Transport
-   Layer Security (DTLS) protocol. The DTLS protocol provides
-   communications privacy for datagram protocols. The protocol
-   allows client/server applications to communicate in a way that
-   is designed to prevent eavesdropping, tampering, or message
-   forgery. The DTLS protocol is based on the TLS protocol and
-   provides equivalent security guarantees. Datagram semantics of
-   the underlying transport are preserved by the DTLS protocol.
-
-
-Contents
-
-   1           Introduction                                          3
-     1.1         Requirements Terminology                            3
-   2           Usage Model                                           4
-   3           Overview of DTLS                                      4
-     3.1         Loss-insensitive messaging                          4
-     3.2         Providing Reliability for Handshake                 5
-       3.2.1       Packet Loss                                       5
-       3.2.2       Reordering                                        6
-       3.2.3       Message Size                                      6
-     3.3         Replay Detection                                    6
-   4           Differences from TLS                                  6
-     4.1         Record Layer                                        7
-       4.1.1       Transport Layer Mapping                           8
-         4.1.1.1     PMTU Discovery                                  9
-       4.1.2       Record payload protection                         9
-         4.1.2.1     MAC                                            10
-         4.1.2.2     Null or standard stream cipher                 10
-         4.1.2.3     Block Cipher                                   10
-         4.1.2.4     New Cipher Suites                              10
-         4.1.2.5     Anti-Replay                                    10
-     4.2         The DTLS Handshake Protocol                        11
-       4.2.1       Denial of Service Countermeasures                12
-       4.2.2       Handshake Message Format                         14
-       4.2.3       Message Fragmentation and Reassembly             16
-       4.2.4       Timeout and Retransmission                       16
-         4.2.4.1     Timer Values                                   19
-       4.2.5       ChangeCipherSpec                                 20
-       4.2.6       Finished messages                                20
-       4.2.7       Alert Messages                                   20
-     4.2         Record Layer                                       21
-     4.3         Handshake Protocol                                 21
-   5           Security Considerations                              22
-   6           IANA Considerations                                  23
-
-
-
-
-Rescorla, Modadugu                                               [Page 2]
-
-
-1. Introduction
-
-   TLS [TLS] is the most widely deployed protocol for securing
-   network traffic. It is widely used for protecting Web traffic
-   and for e-mail protocols such as IMAP [IMAP] and POP [POP].
-   The primary advantage of TLS is that it provides a transparent
-   connection-oriented channel. Thus, it is easy to secure an
-   application protocol by inserting TLS between the application
-   layer and the transport layer. However, TLS must run over a
-   reliable transport channel--typically TCP [TCP]. It therefore
-   cannot be used to secure unreliable datagram traffic.
-
-   However, over the past few years an increasing number of
-   application layer protocols have been designed which use UDP
-   transport. In particular such protocols as the Session
-   Initiation Protocol (SIP) [SIP], and electronic gaming
-   protocols are increasingly popular. (Note that SIP can run
-   over both TCP and UDP, but that there are situations in which
-   UDP is preferable). Currently, designers of these applications
-   are faced with a number of unsatisfactory choices. First, they
-   can use IPsec [RFC2401]. However, for a number of reasons
-   detailed in [WHYIPSEC], this is only suitable for some
-   applications. Second, they can design a custom application
-   layer security protocol. SIP, for instance, uses a subset of
-   S/MIME to secure its traffic. Unfortunately, while application
-   layer security protocols generally provide superior security
-   properties (e.g., end-to-end security in the case of S/MIME)
-   it typically requires a large amount of effort to design--by
-   contrast to the relatively small amount of effort required to
-   run the protocol over TLS.
-
-   In many cases, the most desirable way to secure client/server
-   applications would be to use TLS; however the requirement for
-   datagram semantics automatically prohibits use of TLS. Thus, a
-   datagram-compatible variant of TLS would be very desirable.
-   This memo describes such a protocol: Datagram Transport Layer
-   Security (DTLS). DTLS is deliberately designed to be as
-   similar to to TLS as possible, both to minimize new security
-   invention and to maximize the amount of code and
-   infrastructure reuse.
-
-
-1.1. Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
-   NOT" and "MAY" that appear in this document are to be
-   interpreted as described in RFC 2119 [REQ].
-
-
-
-
-Rescorla, Modadugu                                               [Page 3]
-
-
-2. Usage Model
-
-   The DTLS protocol is designed to secure data between
-   communicating applications. It is designed to run in
-   application space, without requiring any kernel modifications.
-
-   Datagram transport does not require or provide reliable or in-
-   order delivery of data. The DTLS protocol preserves this
-   property for payload data. Applications such as media
-   streaming, Internet telephony and online gaming use datagram
-   transport for communication due to the delay-sensitive nature
-   of transported data. The behavior of such applications is
-   unchanged when the DTLS protocol is used to secure
-   communication, since the DTLS protocol does not compensate for
-   lost or re-ordered data traffic.
-
-3. Overview of DTLS
-
-   The basic design philosophy of DTLS is to construct "TLS over
-   datagram". The reason that TLS cannot be used directly in
-   datagram environments is simply that packets may be lost or
-   reordered. TLS has no internal facilities to handle this kind
-   of unreliability and therefore TLS implementations break when
-   rehosted on datagram transport. The purpose of DTLS is to make
-   only the minimal changes to TLS required to fix this problem.
-   To the greatest extent possible, DTLS is identical to TLS.
-   Whenever we need to invent new mechanisms, we attempt to do so
-   in such a way that it preserves the style of TLS.
-
-   Unreliability creates problems for TLS at two levels:
-
-      1. TLS's traffic encryption layer does not allow
-      independent decryption of individual records. If record N
-      is not received, then record N+1 cannot be decrypted.
-
-      2. The TLS handshake layer assumes that handshake messages
-      are delivered reliably and breaks if those messages are
-      lost.
-
-   The rest of this section describes the approach that DTLS uses
-   to solve these problems.
-
-3.1. Loss-insensitive messaging
-
-   In TLS's traffic encryption layer (called the TLS Record
-   Layer), records are not independent. There are two kinds of
-   inter-record dependency:
-
-
-
-
-Rescorla, Modadugu                                               [Page 4]
-
-
-      1. Cryptographic context (CBC state, stream cipher key
-      stream) is chained between records.
-
-      2. Anti-replay and message reordering protection are
-      provided by a MAC which includes a sequence number, but the
-      sequence numbers are implicit in the records.
-
-   The fix for both of these problems is straightforward and
-   well-known from IPsec ESP [ESP]: add explicit state to the
-   records. TLS 1.1 [TLS11] is already adding explicit CBC state
-   to TLS records. DTLS borrows that mechanism and adds explicit
-   sequence numbers.
-
-3.2. Providing Reliability for Handshake
-
-   The TLS handshake is a lockstep cryptographic handshake.
-   Messages must be transmitted and received in a defined order
-   and any other order is an error. Clearly, this is incompatible
-   with reordering and message loss. In addition, TLS handshake
-   messages are potentially larger than any given datagram, thus
-   creating the problem of fragmentation. DTLS must provide fixes
-   for both these problems.
-
-3.2.1. Packet Loss
-
-   DTLS uses a simple retransmission timer to handle packet loss.
-   The following figure demonstrates the basic concept using the
-   first phase of the DTLS handshake:
-
-      Client                                   Server
-      ------                                   ------
-      ClientHello           ------>
-
-                              X<-- HelloVerifyRequest
-                                               (lost)
-
-      [Timer Expires]
-
-      ClientHello           ------>
-      (retransmit)
-
-   Once the client has transmitted the ClientHello message, it
-   expects to see a HelloVerifyRequest from the server. However,
-   if the server's message is lost the client knows that either
-   the ClientHello or the HelloVerifyRequest has been lost and
-   retransmits. When the server receives the retransmission, it
-   knows to retransmit. The server also maintains a
-   retransmission timer and retransmits when that timer expires.
-
-
-
-Rescorla, Modadugu                                               [Page 5]
-
-
-   Note: timeout and retransmission do not apply to the
-   HelloVerifyRequest, because this requires creating state on
-   the server.
-
-3.2.2. Reordering
-
-   In DTLS, each handshake message is assigned a specific
-   sequence number within that handshake. When a peer receives a
-   handshake message, it can quickly determine whether that
-   message is the next message it expects. If it is, then it
-   processes it. If not, it queues it up for future handling once
-   all previous messages have been received.
-
-3.2.3. Message Size
-
-   TLS and DTLS handshake messages can be quite large (in theory
-   up to 2^24-1 bytes, in practice many kilobytes). By contrast,
-   UDP datagrams are often limited to <1500 bytes if
-   fragmentation is not desired. In order to compensate for this
-   limitation, each DTLS handshake message may be fragmented over
-   several DTLS records. Each DTLS handshake message contains
-   both a fragment offset and a fragment length. Thus, a
-   recipient in possession of all bytes of a handshake message
-   can reassemble the original unfragmented message.
-
-3.3. Replay Detection
-
-   DTLS optionally supports record replay detection. The
-   technique used is the same as in IPsec AH/ESP, by maintaining
-   a bitmap window of received records. Records that are too old
-   to fit in the window and records that have been previously
-   received are silently discarded. The replay detection feature
-   is optional, since packet duplication is not always malicious,
-   but can also occur due to routing errors. Applications may
-   conceivably detect duplicate packets and accordingly modify
-   their data transmission strategy.
-
-4. Differences from TLS
-
-   As mentioned in Section 3., DTLS is intentionally very similar
-   to TLS. Therefore, instead of presenting DTLS as a new
-   protocol, we instead present it as a series of deltas from TLS
-   1.1 [TLS11]. Where we do not explicitly call out differences,
-   DTLS is the same as in [TLS11].
-
-
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 6]
-
-
-4.1. Record Layer
-
-   The DTLS record layer is extremely similar to that of TLS 1.1.
-   The only change is the inclusion of an explicit sequence
-   number in the record. This sequence number allows the
-   recipient to correctly verify the TLS MAC. The DTLS record
-   format is shown below:
-
-       struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 epoch;               // New field
-        uint48 sequence_number;       // New field
-        uint16 length;
-        opaque fragment[DTLSPlaintext.length];
-       } DTLSPlaintext;
-
-      type
-       Equivalent to the type field in a TLS 1.1 record.
-
-      version
-       The version of the protocol being employed. This document
-       describes DTLS Version 1.0, which uses the version { 254, 255
-       }. The version value of 254.255 is the 1's complement of DTLS
-       Version 1.0. This maximal spacing between TLS and DTLS version
-       numbers ensures that records from the two protocols can be
-       easily distinguished.
-
-      epoch
-       A counter value that is incremented on every cipher state
-       change.
-
-      sequence_number
-       The sequence number for this record.
-
-      length
-       Identical to the length field in a TLS 1.1 record. As in TLS
-       1.1, the length should not exceed 2^14.
-
-      fragment
-       Identical to the fragment field of a TLS 1.1 record.
-
-   DTLS uses an explicit rather than implicit sequence number,
-   carried in the sequence_number field of the record. As with
-   TLS, the sequence number is set to zero after each
-   ChangeCipherSpec message is sent.
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 7]
-
-
-   If several handshakes are performed in close succession, there
-   might be multiple records on the wire with the same sequence
-   number but from different cipher states. The epoch field
-   allows recipients to distinguish such packets. The epoch
-   number is initially zero and is incremented each time the
-   ChangeCipherSpec messages is sent. In order to ensure that any
-   given sequence/epoch pair is unique, implementations MUST NOT
-   allow the same epoch value to be reused within two times the
-   TCP maximum segment lifetime. In practice, TLS implementations
-   rehandshake rarely and we therefore do not expect this to be a
-   problem.
-
-4.1.1. Transport Layer Mapping
-
-   Each DTLS record MUST fit within a single datagram. In order
-   to avoid IP fragmentation [MOGUL], DTLS implementations SHOULD
-   determine the MTU and send records smaller than the MTU. DTLS
-   implementations SHOULD provide a way for applications to
-   determine the value of the PMTU (or alternately the maximum
-   application datagram size, which is the PMTU minus the DTLS
-   per-record overhead). If the application attempts to send a
-   record larger than the MTU the DTLS implementation SHOULD
-   generate an error, thus avoiding sending a packet which will
-   be fragmented.
-
-   Note that unlike IPsec, DTLS records do not contain any
-   association identifiers. Applications must arrange to
-   multiplex between associations. With UDP, this is presumably
-   done with host/port number.
-
-   Multiple DTLS records may be placed in a single datagram. They
-   are simply encoded consecutively. The DTLS record framing is
-   sufficient to determine the boundaries. Note, however, that
-   the first byte of the datagram payload must be the beginning
-   of a record. Records may not span datagrams.
-
-   Some transports, such as DCCP [DCCP] provide their own
-   sequence numbers. When carried over those transports, both the
-   DTLS and the transport sequence numbers will be present.
-   Although this introduces a small amount of inefficiency, the
-   transport layer and DTLS sequence numbers serve different
-   purposes and therefore for conceptual simplicity it is
-   superior to use both sequence numbers. In the future,
-   extensions to DTLS may be specified that allow the use of only
-   one set of sequence numbers for deployment in constrained
-   environments.
-     Some transports, such as DCCP, provide congestion control
-   for traffic carried over them. If the congestion window is
-
-
-
-Rescorla, Modadugu                                               [Page 8]
-
-
-   sufficiently narrow, DTLS handshake retransmissions may be
-   held rather than transmitted immediately, potentially leading
-   to timeouts and spurious retransmission. When DTLS is used
-   over such transports, care should be taken not to overrun the
-   likely congestion window. In the future, a DTLS-DCCP mapping
-   may be specificied to provide optimal behavior for this
-   interaction.
-
-4.1.1.1. PMTU Discovery
-
-   In general, DTLS's philosophy is to avoid dealing with PMTU
-   issues. The general strategy is to start with a conservative
-   MTU and then update it if events during the handshake or
-   actual application data transport phase require it.
-
-   The PMTU SHOULD be initialized from the interface MTU that
-   will be used to send packets. If the DTLS implementation
-   receives an RFC 1191 [RFC1191] ICMP Destination Unreachable
-   message with the "fragmentation needed and DF set" Code
-   (otherwise known as Datagram Too Big) it should decrease its
-   PMTU estimate to that given in the ICMP message. A DTLS
-   implementation SHOULD allow the application to occasionally
-   reset its PMTU estimate. The DTLS implementation SHOULD also
-   allow applications to control the status of the DF bit. These
-   controls allow the application to perform PMTU discovery. RFC
-   1981 [RFC1981] procedures SHOULD be followed for IPv6.
-
-   One special case is the DTLS handshake system. Handshake
-   messages should be set with DF set. Because some firewalls and
-   routers screen out ICMP messages, it is difficult for the
-   handshake layer to distinguish packet loss from an overlarge
-   PMTU estimate. In order to allow connections under these
-   circumstances, DTLS implementations SHOULD back off handshake
-   packet size during the retransmit backoff described in Section
-   4.2.4.. For instance, if a large packet is being sent, after 3
-   retransmits the handshake layer might choose to fragment the
-   handshake message on retransmission. In general, choice of a
-   conservative initial MTU will avoid this problem.
-
-4.1.2. Record payload protection
-
-   Like TLS, DTLS transmits data as a series of protected
-   records. The rest of this section describes the details of
-   that format.
-
-
-
-
-
-
-
-Rescorla, Modadugu                                               [Page 9]
-
-
-4.1.2.1. MAC
-
-   The DTLS MAC is the same as that of TLS 1.1. However, rather
-   than using TLS's implicit sequence number, the sequence number
-   used to compute the MAC is the 64-bit value formed by
-   concatenating the epoch and the sequence number in the order
-   they appear on the wire. Note that the DTLS epoch + sequence
-   number is the same length as the TLS sequence number.
-
-   Note that one important difference between DTLS and TLS MAC
-   handling is that in TLS MAC errors must result in connection
-   termination. In DTLS, the receiving implementation MAY simply
-   discard the offending record and continue with the connection.
-   This change is possible because DTLS records are not dependent
-   on each other the way that TLS records are.
-     In general, DTLS implementations SHOULD silently discard
-   data with bad MACs. If a DTLS implementation chooses to
-   generate an alert when it receives a message with an invalid
-   MAC, it MUST generate bad_record_mac alert with level fatal
-   and terminate its connection state.
-
-4.1.2.2. Null or standard stream cipher
-
-   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL
-   cipher.
-
-   The only stream cipher described in TLS 1.1 is RC4, which
-   cannot be randomly accessed. RC4 MUST NOT be used with DTLS.
-
-4.1.2.3. Block Cipher
-
-   DTLS block cipher encryption and decryption are performed
-   exactly as with TLS 1.1.
-
-4.1.2.4. New Cipher Suites
-
-   Upon registration, new TLS cipher suites MUST indicate whether
-   they are suitable for DTLS usage and what, if any, adaptations
-   must be made.
-
-4.1.2.5. Anti-Replay
-
-   DTLS records contain a sequence number to provide replay
-   protection. Sequence number verification SHOULD be performed
-   using the following sliding window procedure, borrowed from
-   Section 3.4.3 of [RFC 2402].
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 10]
-
-
-   The receiver packet counter for this session MUST be
-   initialized to zero when the session is established. For each
-   received record, the receiver MUST verify that the record
-   contains a Sequence Number that does not duplicate the
-   Sequence Number of any other record received during the life
-   of this session. This SHOULD be the first check applied to a
-   packet after it has been matched to a session, to speed
-   rejection of duplicate records.
-
-   Duplicates are rejected through the use of a sliding receive
-   window. (How the window is implemented is a local matter, but
-   the following text describes the functionality that the
-   implementation must exhibit.) A minimum window size of 32 MUST
-   be supported; but a window size of 64 is preferred and SHOULD
-   be employed as the default. Another window size (larger than
-   the minimum) MAY be chosen by the receiver. (The receiver does
-   not notify the sender of the window size.)
-
-   The "right" edge of the window represents the highest,
-   validated Sequence Number value received on this session.
-   Records that contain Sequence Numbers lower than the "left"
-   edge of the window are rejected. Packets falling within the
-   window are checked against a list of received packets within
-   the window. An efficient means for performing this check,
-   based on the use of a bit mask, is described in Appendix C of
-   [RFC 2401].
-
-   If the received record falls within the window and is new, or
-   if the packet is to the right of the window, then the receiver
-   proceeds to MAC verification. If the MAC validation fails, the
-   receiver MUST discard the received record as invalid. The
-   receive window is updated only if the MAC verification
-   succeeds.
-
-4.2. The DTLS Handshake Protocol
-
-   DTLS uses all of the same handshake messages and flows as TLS,
-   with three principal changes:
-
-      1. A stateless cookie exchange has been added to prevent
-      denial of service attacks.
-
-      2. Modifications to the handshake header to handle message
-      loss, reordering and fragmentation.
-
-      3. Retransmission timers to handle message loss.
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 11]
-
-
-   With these exceptions, the DTLS message formats, flows, and
-   logic are the same as those of TLS 1.1.
-
-4.2.1. Denial of Service Countermeasures
-
-   Datagram security protocols are extremely susceptible to a
-   variety of denial of service (DoS) attacks. Two attacks are of
-   particular concern:
-
-      1. An attacker can consume excessive resources on the
-      server by transmitting a series of handshake initiation
-      requests, causing the server to allocate state and
-      potentially perform expensive cryptographic operations.
-
-      2. An attacker can use the server as an amplifier by
-      sending connection initiation messages with a forged source
-      of the victim. The server then sends its next message (in
-      DTLS, a Certificate message, which can be quite large) to
-      the victim machine, thus flooding it.
-
-   In order to counter both of these attacks, DTLS borrows the
-   stateless cookie technique used by Photuris [PHOTURIS] and IKE
-   [IKE]. When the client sends its ClientHello message to the
-   server, the server MAY respond with a HelloVerifyRequest
-   message. This message contains a stateless cookie generated
-   using the technique of [PHOTURIS]. The client MUST retransmit
-   the ClientHello with the cookie added. The server then
-   verifies the cookie and proceeds with the handshake only if it
-   is valid. This mechanism forces the attacker/client to be able
-   to receive the cookie, which makes DoS attacks with spoofed IP
-   addresses difficult. This mechanism does not provide any
-   defense against DoS attacks mounted from valid IP addresses.
-
-   The exchange is shown below:
-
-         Client                                   Server
-         ------                                   ------
-         ClientHello           ------>
-
-                               <----- HelloVerifyRequest
-                                      (contains cookie)
-
-         ClientHello           ------>
-         (with cookie)
-
-         [Rest of handshake]
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 12]
-
-
-   DTLS therefore modifies the ClientHello message to add the
-   cookie value.
-
-      struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        opaque cookie<0..32>;                 // New field
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-      } ClientHello;
-
-   When sending the first ClientHello, the client does not have a
-   cookie yet; in this case, the Cookie field is left empty (zero
-   length).
-
-   The definition of HelloVerifyRequest is as follows:
-
-      struct {
-        ProtocolVersion server_version;
-        opaque cookie<0..32>;
-      } HelloVerifyRequest;
-
-   The HelloVerifyRequest message type is
-   hello_verify_request(3).
-
-   The server_version field is defined as in TLS.
-
-   When responding to a HelloVerifyRequest the client MUST use
-   the same parameter values (version, random, session_id,
-   cipher_suites, compression_method) as in the original
-   ClientHello. The server SHOULD use those values to generate
-   its cookie and verify that they are correct upon cookie
-   receipt. The server MUST use the same version number in the
-   HelloVerifyRequest that it would use when sending a
-   ServerHello. Upon receipt of the ServerHello, the client MUST
-   verify that the server version values match.
-
-   The DTLS server SHOULD generate cookies in such a way that
-   they can be verified without retaining any per-client state on
-   the server. One technique is to have a randomly generated
-   secret and generate cookies as:
-   Cookie = HMAC(Secret, Client-IP, Client-Parameters)
-
-   When the second ClientHello is received, the server can verify
-   that the Cookie is valid and that the client can receive
-   packets at the given IP address.
-     One potential attack on this scheme is for the attacker to
-
-
-
-Rescorla, Modadugu                                              [Page 13]
-
-
-   collect a number of cookies from different addresses and then
-   reuse them to attack the server. The server can defend against
-   this attack by changing the Secret value frequently, thus
-   invalidating those cookies. If the server wishes legitimate
-   clients to be able to handshake through the transition (e.g.,
-   they received a cookie with Secret 1 and then sent the second
-   ClientHello after the server has changed to Secret 2), the
-   server can have a limited window during which it accepts both
-   secrets. [IKEv2] suggests adding a version number to cookies
-   to detect this case. An alternative approach is simply to try
-   verifying with both secrets.
-
-   DTLS servers SHOULD perform a cookie exchange whenever a new
-   handshake is being performed. If the server is being operated
-   in an environment where amplification is not a problem, the
-   server MAY be configured to not to perform a cookie exchange.
-   The default SHOULD be that the exchange is performed, however.
-   In addition, the server MAY choose not do to a cookie exchange
-   when a session is resumed. Clients MUST be prepared to do a
-   cookie exchange with every handshake.
-
-   If HelloVerifyRequest is used, the initial ClientHello and
-   HelloVerifyRequest are not included in the calculation of the
-   verify_data for the Finished message.
-
-4.2.2. Handshake Message Format
-
-   In order to support message loss, reordering, and
-   fragmentation DTLS modifies the TLS 1.1 handshake header:
-
-      struct {
-        HandshakeType msg_type;
-        uint24 length;
-        uint16 message_seq;                              // New field
-        uint24 fragment_offset;                          // New field
-        uint24 fragment_length;                          // New field
-        select (HandshakeType) {
-      case hello_request: HelloRequest;
-      case client_hello:  ClientHello;
-      case hello_verify_request: HelloVerifyRequest;     // New type
-      case server_hello:  ServerHello;
-      case certificate:Certificate;
-      case server_key_exchange: ServerKeyExchange;
-      case certificate_request: CertificateRequest;
-      case server_hello_done:ServerHelloDone;
-      case certificate_verify:  CertificateVerify;
-      case client_key_exchange: ClientKeyExchange;
-      case finished:Finished;
-
-
-
-Rescorla, Modadugu                                              [Page 14]
-
-
-        } body;
-      } Handshake;
-
-   The first message each side transmits in each handshake always
-   has message_seq = 0. Whenever each new message is generated,
-   the message_seq value is incremented by one. When a message is
-   retransmitted, the same message_seq value is used. For
-   example.
-
-      Client                             Server
-      ------                             ------
-      ClientHello (seq=0)  ------>
-
-                              X<-- HelloVerifyRequest (seq=0)
-                                              (lost)
-
-      [Timer Expires]
-
-      ClientHello (seq=0)  ------>
-      (retransmit)
-
-                           <------ HelloVerifyRequest (seq=0)
-
-      ClientHello (seq=1)  ------>
-      (with cookie)
-
-                           <------        ServerHello (seq=1)
-                           <------        Certificate (seq=2)
-                           <------    ServerHelloDone (seq=3)
-
-      [Rest of handshake]
-
-   Note, however, that from the perspective of the DTLS record
-   layer, the retransmission is a new record. This record will
-   have a new DTLSPlaintext.sequence_number value.
-
-   DTLS implementations maintain (at least notionally) a
-   next_receive_seq counter. This counter is initially set to
-   zero. When a message is received, if its sequence number
-   matches next_receive_seq, next_receive_seq is incremented and
-   the message is processed. If the sequence number is less than
-   next_receive_seq the message MUST be discarded. If the
-   sequence number is greater than next_receive_seq, the
-   implementation SHOULD queue the message but MAY discard it.
-   (This is a simple space/bandwidth tradeoff).
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 15]
-
-
-4.2.3. Message Fragmentation and Reassembly
-
-   As noted in Section 4.1.1., each DTLS message MUST fit within
-   a single transport layer datagram. However, handshake messages
-   are potentially bigger than the maximum record size. Therefore
-   DTLS provides a mechanism for fragmenting a handshake message
-   over a number of records.
-
-   When transmitting the handshake message, the sender divides
-   the message into a series of N contiguous data ranges. These
-   range MUST NOT be larger than the maximum handshake fragment
-   size and MUST jointly contain the entire handshake message.
-   The ranges SHOULD NOT overlap. The sender then creates N
-   handshake messages, all with the same message_seq value as the
-   original handshake message. Each new message is labelled with
-   the fragment_offset (the number of bytes contained in previous
-   fragments) and the fragment_length (the length of this
-   fragment). The length field in all messages is the same as the
-   length field of the original message. An unfragmented message
-   is a degenerate case with fragment_offset=0 and
-   fragment_length=length.
-
-   When a DTLS implementation receives a handshake message
-   fragment, it MUST buffer it until it has the entire handshake
-   message. DTLS implementations MUST be able to handle
-   overlapping fragment ranges. This allows senders to retransmit
-   handshake messages with smaller fragment sizes during path MTU
-   discovery.
-
-   Note that as with TLS, multiple handshake messages may be
-   placed in the same DTLS record, provided that there is room
-   and that they are part of the same flight. Thus, there are two
-   acceptable ways to pack two DTLS messages into the same
-   datagram: in the same record or in separate records.
-
-4.2.4. Timeout and Retransmission
-
-   DTLS messages are grouped into a series of message flights,
-   according the diagrams below. Although each flight of messages
-   may consist of a number of messages, they should be viewed as
-   monolithic for the purpose of timeout and retransmission.
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 16]
-
-
-      Client                                          Server
-      ------                                          ------
-
-      ClientHello             -------->                           Flight 1
-
-                              <-------    HelloVerifyRequest      Flight 2
-
-     ClientHello              -------->                           Flight 3
-
-                                                 ServerHello    \
-                                                Certificate*     \
-                                          ServerKeyExchange*      Flight 4
-                                         CertificateRequest*     /
-                              <--------      ServerHelloDone    /
-
-      Certificate*                                              \
-      ClientKeyExchange                                          \
-      CertificateVerify*                                          Flight 5
-      [ChangeCipherSpec]                                         /
-      Finished                -------->                         /
-
-                                          [ChangeCipherSpec]    \ Flight 6
-                              <--------             Finished    /
-            Figure 1: Message flights for full handshake
-
-
-      Client                                           Server
-      ------                                           ------
-
-      ClientHello             -------->                          Flight 1
-
-                                                 ServerHello    \
-                                          [ChangeCipherSpec]     Flight 2
-                               <--------             Finished    /
-
-      [ChangeCipherSpec]                                         \Flight 3
-      Finished                 -------->                         /
-   Figure 2: Message flights for session resuming handshake (no
-                          cookie exchange)
-
-
-   DTLS uses a simple timeout and retransmission scheme with the
-   following state machine. Because DTLS clients send the first
-   message (ClientHello) they start in the PREPARING state. DTLS
-   servers start in the WAITING state, but with empty buffers and
-   no retransmit timer.
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 17]
-
-
-                +-----------+
-                | PREPARING |
-          +---> |           | <--------------------+
-          |     |           |                      |
-          |     +-----------+                      |
-          |           |                            |
-          |           |                            |
-          |           | Buffer next flight         |
-          |           |                            |
-          |          \|/                           |
-          |     +-----------+                      |
-          |     |           |                      |
-          |     |  SENDING  |<------------------+  |
-          |     |           |                   |  | Send
-          |     +-----------+                   |  | HelloRequest
-  Receive |           |                         |  |
-     next |           | Send flight             |  | or
-   flight |  +--------+                         |  |
-          |  |        | Set retransmit timer    |  | Receive
-          |  |       \|/                        |  | HelloRequest
-          |  |  +-----------+                   |  | Send
-          |  |  |           |                   |  | ClientHello
-          +--)--|  WAITING  |-------------------+  |
-          |  |  |           |   Timer expires   |  |
-          |  |  +-----------+                   |  |
-          |  |         |                        |  |
-          |  |         |                        |  |
-          |  |         +------------------------+  |
-          |  |                Read retransmit      |
-  Receive |  |                                     |
-     last |  |                                     |
-   flight |  |                                     |
-          |  |                                     |
-         \|/\|/                                    |
-                                                   |
-      +-----------+                                |
-      |           |                                |
-      | FINISHED  | -------------------------------+
-      |           |
-      +-----------+
-
-     Figure 3: DTLS timeout and retransmission state machine
-
-
-   The state machine has three basic states.
-
-   In the PREPARING state the implementation does whatever
-   computations are necessary to prepare the next flight of
-
-
-
-Rescorla, Modadugu                                              [Page 18]
-
-
-   messages. It then buffers them up for transmission (emptying
-   the buffer first) and enters the SENDING state.
-
-   In the SENDING state, the implementation transmits the
-   buffered flight of messages. Once the messages have been sent,
-   the implementation then enters the FINISHED state if this is
-   the last flight in the handshake, or, if the implementation
-   expects to receive more messages, sets a retransmit timer and
-   then enters the WAITING state.
-
-   There are three ways to exit the WAITING state:
-
-      1. The retransmit timer expires: the implementation
-      transitions to the SENDING state, where it retransmits the
-      flight, resets the retransmit timer, and returns to the
-      WAITING state.
-
-      2. The implementation reads a retransmitted flight from the
-      peer: the implementation transitions to the SENDING state,
-      where it retransmits the flight, resets the retransmit
-      timer, and returns to the WAITING state. The rationale here
-      is that the receipt of a duplicate message is the likely
-      result of timer expiry on the peer and therefore suggests
-      that part of one's previous flight was lost.
-
-      3. The implementation receives the next flight of messages:
-      if this is the final flight of messages the implementation
-      transitions to FINISHED. If the implementation needs to
-      send a new flight, it transitions to the PREPARING state.
-      Partial reads (whether partial messages or only some of the
-      messages in the flight) do not cause state transitions or
-      timer resets.
-
-   Because DTLS clients send the first message (ClientHello) they
-   start in the PREPARING state. DTLS servers start in the
-   WAITING state, but with empty buffers and no retransmit timer.
-
-   When the server desires a rehandshake, it transitions from the
-   FINISHED state to the PREPARING state to transmit the
-   HelloRequest. When the client receives a HelloRequest it
-   transitions from FINISHED to PREPARING to transmit the
-   ClientHello.
-
-4.2.4.1. Timer Values
-
-   Though timer value choices are the choice of the
-   implementation, mishandling of the timer can lead to serious
-   congestion problems, for example if many instances of a DTLS
-
-
-
-Rescorla, Modadugu                                              [Page 19]
-
-
-   time out early and retransmit too quickly on a congested link.
-   Implementations SHOULD use an initial timer value of 1 second
-   (the minimum defined in RFC 2988 [RFC2988]) and double the
-   value at each retransmission, up to no less than the the RFC
-   2988 maximum of 60 seconds. Note that we recommend a 1 second
-   timer rather than the 3 second RFC 2988 default in order to
-   improve latency for time-sensitive applications. Because DTLS
-   only uses retransmission for handshake and not dataflow, the
-   effect on congestion should be minimal.
-     Implementations SHOULD retain the current timer value until
-   a transmission without loss occurs, at which time the value
-   may be reset to the initial value. After a long period of
-   idleness, no less than 10 times the current timer value,
-   implementations may reset the timer to the initial value. One
-   situation where this might occur is when a rehandshake is used
-   after substantial data transfer.
-
-4.2.5. ChangeCipherSpec
-
-   As with TLS, the ChangeCipherSpec message is not technically a
-   handshake message but MUST be treated as part of the same
-   flight as the associated Finished message for the purposes of
-   timeout and retransmission.
-
-4.2.6. Finished messages
-
-   Finished messages have the same format as in TLS. However, in
-   order to remove sensitivity to fragmentation, the Finished MAC
-   MUST be computed as if each handshake message had been sent as
-   a single fragment. Note that in cases where the cookie
-   exchange is used, the initial ClientHello and
-   HelloVerifyRequest MUST NOT included in the Finished MAC.
-
-4.2.7. Alert Messages
-
-   Note that Alert messages are not retransmitted at all, even
-   when they occur in the context of a handshake. However, a DTLS
-   implementation SHOULD generate a new alert message if the
-   offending record is received again (e.g., as a retransmitted
-   handshake message). Implementations SHOULD detect when a peer
-   is persistently sending bad messages and terminate the local
-   connection state after such misbehavior is detected.
-
-
-
-A.1Summary of new syntax
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 20]
-
-
-   This section includes specifications for the data structures
-   that have changed between TLS 1.1 and DTLS.
-
-4.2. Record Layer
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     opaque fragment[DTLSPlaintext.length];
-   } DTLSPlaintext;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     opaque fragment[DTLSCompressed.length];
-   } DTLSCompressed;
-
-   struct {
-     ContentType type;
-     ProtocolVersion version;
-     uint16 epoch;                                   // New field
-     uint48 sequence_number;                         // New field
-     uint16 length;
-     select (CipherSpec.cipher_type) {
-   case block:  GenericBlockCipher;
-     } fragment;
-   } DTLSCiphertext;
-
-4.3. Handshake Protocol
-
-   enum {
-     hello_request(0), client_hello(1), server_hello(2),
-     hello_verify_request(3),                        // New field
-     certificate(11), server_key_exchange (12),
-     certificate_request(13), server_hello_done(14),
-     certificate_verify(15), client_key_exchange(16),
-     finished(20), (255)
-   } HandshakeType;
-
-   struct {
-     HandshakeType msg_type;
-     uint24 length;
-     uint16 message_seq;                             // New field
-
-
-
-Rescorla, Modadugu                                              [Page 21]
-
-
-     uint24 fragment_offset;                         // New field
-     uint24 fragment_length;                         // New field
-     select (HandshakeType) {
-   case hello_request: HelloRequest;
-   case client_hello:  ClientHello;
-   case server_hello:  ServerHello;
-   case hello_verify_request: HelloVerifyRequest;    // New field
-   case certificate:Certificate;
-   case server_key_exchange: ServerKeyExchange;
-   case certificate_request: CertificateRequest;
-   case server_hello_done:ServerHelloDone;
-   case certificate_verify:  CertificateVerify;
-   case client_key_exchange: ClientKeyExchange;
-   case finished:Finished;
-     } body;
-   } Handshake;
-
-   struct {
-     ProtocolVersion client_version;
-     Random random;
-     SessionID session_id;
-     opaque cookie<0..32>;                 // New field
-     CipherSuite cipher_suites<2..2^16-1>;
-     CompressionMethod compression_methods<1..2^8-1>;
-   } ClientHello;
-
-   struct {
-     opaque cookie<0..32>;
-   } HelloVerifyRequest;
-
-5. Security Considerations
-
-   This document describes a variant of TLS 1.1 and therefore
-   most of the security considerations are the same as those of
-   TLS 1.1 [TLS11], described in Appendices D, E, and F.
-
-   The primary additional security consideration raised by DTLS
-   is that of denial of service. DTLS includes a cookie exchange
-   designed to protect against denial of service. However,
-   implementations which do not use this cookie exchange are
-   still vulnerable to DoS. In particular, DTLS servers which do
-   not use the cookie exchange may be used as attack amplifiers
-   even if they themselves are not experiencing DoS. Therefore
-   DTLS servers SHOULD use the cookie exchange unless there is
-   good reason to believe that amplification is not a threat in
-   their environment. Clients MUST be prepared to do a cookie
-   exchange with every handshake.
-
-
-
-
-Rescorla, Modadugu                                              [Page 22]
-
-
-6. IANA Considerations
-
-   This document uses the same identifier space as TLS [TLS11],
-   so no new IANA registries are required. When new identifiers
-   are assigned for TLS, authors MUST specify whether they are
-   suitable for DTLS.
-
-   This document defines a new handshake message,
-   hello_verify_request, whose value is to be allocated from the
-   TLS HandshakeType registry defined in [TLS11]. The value "3"
-   is suggested.
-
-References
-
-Normative References
-
-   [RFC1191]  Mogul, J. C., Deering, S.E., "Path MTU Discovery",
-              RFC 1191, November 1990.
-
-   [RFC1981]  J. McCann, S. Deering, J. Mogul, "Path MTU Discovery
-              for IP version 6", RFC1981, August 1996.
-
-   [RFC2401]  Kent, S., Atkinson, R., "Security Architecture for the
-              Internet Protocol", RFC2401, November 1998.
-
-   [RFC2988]  Paxson, V., Allman, M., "Computing TCP's Retransmission
-           Timer", RFC 2988, November 2000.
-
-   [TCP]      Postel, J., "Transmission Control Protocol",
-              RFC 793, September 1981.
-
-   [TLS11]    Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
-              draft-ietf-tls-rfc2246-bis-05.txt, July 2003.
-
-
-Informative References
-
-   [AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES"
-           http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
-
-   [AH]       Kent, S., and Atkinson, R., "IP Authentication Header",
-              RFC 2402, November 1998.
-
-   [DCCP]     Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
-              Congestion Control Protocol", draft-ietf-dccp-spec-11.txt,
-              10 March 2005
-
-   [DNS]      Mockapetris, P.V., "Domain names - implementation and
-
-
-
-Rescorla, Modadugu                                              [Page 23]
-
-
-              specification", RFC 1035, November 1987.
-
-   [DTLS]     Modadugu, N., Rescorla, E., "The Design and Implementation
-              of Datagram TLS", Proceedings of ISOC NDSS 2004, February 2004.
-
-   [ESP]      Kent, S., and Atkinson, R., "IP Encapsulating Security
-              Payload (ESP)", RFC 2406, November 1998.
-
-
-   [IKE]      Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)",
-              RFC 2409, November 1998.
-
-   [IKEv2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
-              draft-ietf-ipsec-ikev2-17.txt, September 2004.
-
-   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
-              4rev1", RFC 3501, March 2003.
-
-   [PHOTURIS] Karn, P., Simpson, W., "Photuris: Session-Key Management
-              Protocol", RFC 2521, March 1999.
-
-
-   [POP]      Myers, J., and Rose, M., "Post Office Protocol -
-              Version 3", RFC 1939, May 1996.
-
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [SCTP]     R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
-              T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson,
-              Stream Control Transmission Protocol", RFC 2960,
-              October 2000.
-
-   [SIP]      Rosenberg, J., Schulzrinne, Camarillo, G., Johnston, A.,
-              Peterson, J., Sparks, R., Handley, M., Schooler, E.,
-              "SIP: Session Initiation Protocol", RFC 3261,
-              June 2002.
-
-   [TLS]      Dierks, T., and Allen, C., "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
-              draft-bellovin-useipsec-02.txt, October 2003
-
-Authors' Address
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 24]
-
-
-   Eric Rescorla <ekr@rtfm.com>
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto, CA 94303
-
-   Nagendra Modadugu <nagendra@cs.stanford.edu>
-   Computer Science Department
-   353 Serra Mall
-   Stanford University
-   Stanford, CA 94305
-
-
-
-Acknowledgements
-
-   The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ
-   Housley, Constantine Sapuntzakis, and Hovav Shacham for
-   discussions and comments on the design of DTLS. Thanks to the
-   anonymous NDSS reviewers of our original NDSS paper on DTLS
-   [DTLS] for their comments. Also, thanks to Steve Kent for
-   feedback that helped clarify many points. The section on PMTU
-   was cribbed from the DCCP specification [DCCP]. Pasi Eronen
-   provided a detailed review of this specification. Helpful
-   comments on the document were also received from Mark Allman,
-   Jari Arkko, Joel Halpern, Ted Hardie and Allison Mankin.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 25]
-
-
-Full Copyright Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard. Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Copyright Notice
-   Copyright (C) The Internet Society (2003). This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla, Modadugu                                              [Page 26]
-
diff --git a/doc/protocol/draft-rescorla-tls-extended-random-00.txt b/doc/protocol/draft-rescorla-tls-extended-random-00.txt
deleted file mode 100644
index 5b33f74178..0000000000
--- a/doc/protocol/draft-rescorla-tls-extended-random-00.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                                RTFM, Inc.
-Intended status:  Informational                                M. Salter
-Expires:  October 31, 2008                      National Security Agency
-                                                          April 29, 2008
-
-
-                     Extended Random Values for TLS
-               draft-rescorla-tls-extended-random-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 31, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   This document describes an extension for using larger client and
-   server Random values with Transport Layer Security (TLS) and Datagram
-   TLS (DTLS).
-
-
-
-
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 1]
-
-Internet-Draft             Extended TLS Random                April 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  The ExtendedRandom Extension  . . . . . . . . . . . . . . . . . 3
-     3.1.  Negotiating the ExtendedRandom Extension  . . . . . . . . . 4
-     3.2.  PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-     4.1.  Threats to TLS  . . . . . . . . . . . . . . . . . . . . . . 5
-     4.2.  Scope of Randomness . . . . . . . . . . . . . . . . . . . . 5
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 2]
-
-Internet-Draft             Extended TLS Random                April 2008
-
-
-1.  Introduction
-
-   TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte
-   "Random" value consisting of a 32-bit time value time and 28 randomly
-   generated bytes:
-
-         struct {
-            uint32 gmt_unix_time;
-            opaque random_bytes[28];
-         } Random;
-
-   The client and server each contribute a Random value which is then
-   mixed with secret keying material to produce the final per-
-   association keying material.
-
-   The United States Department of Defense has requested a TLS mode
-   which allows the use of longer public randomness values for use with
-   high security level cipher suites like those specified in Suite B
-   [I-D.rescorla-tls-suiteb].  The rationale for this as stated by DoD
-   is that the public randomness for each side should be at least twice
-   as long as the security level for cryptographic parity, which makes
-   the 224 bits of randomness provided by the current TLS random values
-   insufficient.
-
-   This document specifies an extension which allows for additional
-   randomness to be exchanged in the Hello messages.
-
-
-2.  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 [RFC2119].
-
-
-3.  The ExtendedRandom Extension
-
-   This document defines a new TLS extension called "extended_random".
-
-   The "extended_random" extension carried in a new TLS extension called
-   "ExtendedRandom".
-
-        struct {
-            opaque extended_random_value<0..2^16-1>;
-        } ExtendedRandom;
-
-   The extended_random_value MUST be a randomly generated byte string.
-   A cryptographically secure PRNG [RFC4086] SHOULD be used.
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 3]
-
-Internet-Draft             Extended TLS Random                April 2008
-
-
-3.1.  Negotiating the ExtendedRandom Extension
-
-   The client requests support for the extended randomness feature by
-   sending an "extended_random" extension in its ClientHello.  The
-   "extension_data" field contains an ExtendedRandom value.
-
-   When a server which does not recognize the "extended_random"
-   extension receives one, it will ignore it as required.  A server
-   which recognizes the extension MAY choose to ignore it, in which case
-   it SHOULD continue with the exchange as if it had not received the
-   extension.
-
-   If the server wishes to use the extended randomness feature, it MUST
-   send its own "extended_random" extension with an
-   extended_random_value equal in length to the client's
-   extended_random_value.  Clients SHOULD check the length of the
-   server's extended_random_value and generate a fatal
-   "illegal_parameter" error if it is present but does does not match
-   the length that was transmitted in the ClientHello.
-
-   Because TLS does not permit servers to request extensions which the
-   client did not offer, the client may not offer the "extended_random"
-   extension even if the server requires it.  In this case, the server
-   should generate a fatal "handshake_failure" alert.
-
-   Because there is no way to mark extensions as critical, the server
-   may ignore the "extended_random" extension even though the client
-   requires it.  If a client requires the extended randomness input
-   feature but the server does not negotiate it, the client SHOULD
-   generate a fatal "handshake_failure" alert.
-
-3.2.  PRF Modifications
-
-   When the extended randomness feature is in use, the extended random
-   values MUST be mixed into the PRF along with the client and server
-   random values during the PMS->MS conversion.  Thus, the PRF becomes:
-
-          master_secret = PRF(pre_master_secret, "master secret",
-                              ClientHello.random +
-                              ClientHello.extended_random_value +
-                              ServerHello.random +
-                              ServerHello.extended_random_value)[0..47];
-
-   Because new extensions may not be introduced in resumed handshakes,
-   mixing in the extended inputs during the MS->keying material
-   conversion would simply involve mixing in the same material twice.
-   Therefore, the extended random inputs are only used when the PMS is
-   converted into the MS.
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 4]
-
-Internet-Draft             Extended TLS Random                April 2008
-
-
-4.  Security Considerations
-
-4.1.  Threats to TLS
-
-   When this extension is in use it increases the amount of data that an
-   attacker can inject into the PRF.  This potentially would allow an
-   attacker who had partially compromised the PRF greater scope for
-   influencing the output.  Hash-based PRFs like the one in TLS are
-   designed to be fairly indifferent to the input size (the input is
-   already greater than the block size of most hash functions), however
-   there is currently no proof that a larger input space would not make
-   attacks easier.
-
-   Another concern is that bad implementations might generate low
-   entropy extented random values.  TLS is designed to function
-   correctly even when fed low-entropy random values because they are
-   primarily used to generate distinct keying material for each
-   connection.
-
-4.2.  Scope of Randomness
-
-   TLS specifies that when a session is resumed the extensions from the
-   original connection are used:
-
-        If, on the other hand, the older session is resumed, then the
-        server MUST ignore the extensions and send a server hello
-        containing none of the extension types.  In this case, the
-        functionality of these extensions negotiated during the original
-        session initiation is applied to the resumed session.
-
-   This motivates why the the extended randomness does not get mixed
-   into the PRF when generating the keying material from the master
-   secret.  Because the same values would be used for every connection
-   in a session, they would not provide any differentiation in the
-   keying material between the connections.
-
-
-5.  IANA Considerations
-
-   This document defines an extension to TLS, in accordance with
-   [I-D.ietf-tls-rfc4366-bis]:
-
-     enum { extended_random (??) } ExtensionType;
-
-   [[ NOTE:  These values need to be assigned by IANA ]]
-
-
-
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 5]
-
-Internet-Draft             Extended TLS Random                April 2008
-
-
-6.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
-              (work in progress), March 2008.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-7.2.  Informative References
-
-   [I-D.ietf-tls-rfc4366-bis]
-              3rd, D., "Transport Layer Security (TLS) Extensions:
-              Extension Definitions", draft-ietf-tls-rfc4366-bis-02
-              (work in progress), February 2008.
-
-   [I-D.rescorla-tls-suiteb]
-              Salter, M. and E. Rescorla, "Suite B Cipher Suites for
-              TLS", draft-rescorla-tls-suiteb-02 (work in progress),
-              April 2008.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-
-Authors' Addresses
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto, CA  94303
-   USA
-
-   Email:  ekr@rtfm.com
-
-
-
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 6]
-
-Internet-Draft             Extended TLS Random                April 2008
-
-
-   Margaret Salter
-   National Security Agency
-   9800 Savage Rd.
-   Fort Meade  20755-6709
-   USA
-
-   Email:  msalter@restarea.ncsc.mil
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 7]
-
-Internet-Draft             Extended TLS Random                April 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla & Salter       Expires October 31, 2008                [Page 8]
-
diff --git a/doc/protocol/draft-rescorla-tls-extractor-00.txt b/doc/protocol/draft-rescorla-tls-extractor-00.txt
deleted file mode 100644
index 52fdb62ab3..0000000000
--- a/doc/protocol/draft-rescorla-tls-extractor-00.txt
+++ /dev/null
@@ -1,337 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Intended status:  Standards Track                       January 14, 2007
-Expires:  July 18, 2007
-
-
-     Keying Material Extractors for Transport Layer Security (TLS)
-                  draft-rescorla-tls-extractor-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 18, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2007).
-
-Abstract
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   to perform key establishment but then use some of the keying material
-   for their own purposes.  This document describes a general mechanism
-   for allowing that.
-
-
-
-
-
-
-
-Rescorla                  Expires July 18, 2007                 [Page 1]
-
-Internet-Draft               TLS Extractors                 January 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
-     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4
-     6.2.  Informational References  . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                  Expires July 18, 2007                 [Page 2]
-
-Internet-Draft               TLS Extractors                 January 2007
-
-
-1.  Introduction
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   [4] or Datagram TLS (DTLS) [5] to perform key establishment but then
-   use some of the keying material for their own purposes.  A typical
-   example is DTLS-SRTP [6], which uses DTLS to perform a key exchange
-   and negotiate the SRTP [3] protection suite and then uses the DTLS
-   master_secret to generate the SRTP keys.
-
-   These applications imply a need to be able to extract Exported Keying
-   Material (EKM) from TLS/DTLS.  This mechanism has the following
-   requirements:
-
-   o  Both client and server need to be able to extract the same EKM
-      value.
-   o  EKM values should be indistinguishable from random by attackers
-      who don't know the master_secret.
-   o  It should be possible to extract multiple EKM values from the same
-      TLS/DTLS association.
-   o  Knowing one EKM value should not reveal any information about the
-      master_secret or about other EKM values.
-
-   The mechanism described in this document is intended to fill these
-   requirements.
-
-
-2.  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 [1].
-
-
-3.  Extractor Definition
-
-   An extractor takes as input two values:
-
-   o  A disambiguating label string
-   o  A length value
-
-   It then computes:
-
-
-          PRF(master_secret, "EXTRACTOR" + label,
-              SecurityParameters.client_random +
-              SecurityParameters.server_random)[length]
-
-   The output is a pseudorandom bit string of length bytes generated
-
-
-
-Rescorla                  Expires July 18, 2007                 [Page 3]
-
-Internet-Draft               TLS Extractors                 January 2007
-
-
-   from the master_secret.
-
-   Label values MUST be registered via Specification Required as
-   described by RFC 2434 [2].
-
-
-4.  Security Considerations
-
-   Because an extractor produces the same value if applied twice with
-   the same label to the same master_secret, it is critical that two EKM
-   values generated with the same label be used for two different
-   purposes--hence the requirement for IANA registration.  However,
-   because extractors depend on the TLS PRF, it is not a threat to the
-   use of an EKM value generated from one label to reveal an EKM value
-   generated from another label.
-
-
-5.  IANA Considerations
-
-   Section Section 3 requires that all extractor labels be registered
-   via 2434 Specification Required.  IANA has created a TLSExtractor
-   registry for this purpose.  Future values MUST be allocated via
-   Specification Required as described in [RFC2434].
-
-
-6.  References
-
-6.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [3]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
-        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
-        RFC 3711, March 2004.
-
-   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
-        Protocol Version 1.1", RFC 4346, April 2006.
-
-   [5]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-        Security", RFC 4347, April 2006.
-
-
-
-
-
-
-
-Rescorla                  Expires July 18, 2007                 [Page 4]
-
-Internet-Draft               TLS Extractors                 January 2007
-
-
-6.2.  Informational References
-
-   [6]  Rescorla, E. and D. McGrew, "Datagram Transport Layer Security
-        (DTLS) Extension to Establish Keys for  Secure Real-time
-        Transport Protocol (SRTP)", draft-mcgrew-tls-srtp-00 (work in
-        progress), June 2006.
-
-
-Author's Address
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto, CA  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                  Expires July 18, 2007                 [Page 5]
-
-Internet-Draft               TLS Extractors                 January 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                  Expires July 18, 2007                 [Page 6]
-
-
diff --git a/doc/protocol/draft-rescorla-tls-extractor-01.txt b/doc/protocol/draft-rescorla-tls-extractor-01.txt
deleted file mode 100644
index 5176f7abc7..0000000000
--- a/doc/protocol/draft-rescorla-tls-extractor-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Intended status:  Standards Track                      November 17, 2007
-Expires:  May 20, 2008
-
-
-     Keying Material Extractors for Transport Layer Security (TLS)
-                  draft-rescorla-tls-extractor-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on May 20, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   to perform key establishment but then use some of the keying material
-   for their own purposes.  This document describes a general mechanism
-   for allowing that.
-
-
-
-
-
-
-
-Rescorla                  Expires May 20, 2008                  [Page 1]
-
-Internet-Draft               TLS Extractors                November 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Signalling Extractors . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Extractor Definition  . . . . . . . . . . . . . . . . . . . . . 3
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     8.2.  Informational References  . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                  Expires May 20, 2008                  [Page 2]
-
-Internet-Draft               TLS Extractors                November 2007
-
-
-1.  Introduction
-
-   A number of protocols wish to leverage Transport Layer Security (TLS)
-   [4] or Datagram TLS (DTLS) [5] to perform key establishment but then
-   use some of the keying material for their own purposes.  A typical
-   example is DTLS-SRTP [6], which uses DTLS to perform a key exchange
-   and negotiate the SRTP [3] protection suite and then uses the DTLS
-   master_secret to generate the SRTP keys.
-
-   These applications imply a need to be able to extract Exported Keying
-   Material (EKM) from TLS/DTLS.  This mechanism has the following
-   requirements:
-
-   o  Both client and server need to be able to extract the same EKM
-      value.
-   o  EKM values should be indistinguishable from random by attackers
-      who don't know the master_secret.
-   o  It should be possible to extract multiple EKM values from the same
-      TLS/DTLS association.
-   o  Knowing one EKM value should not reveal any information about the
-      master_secret or about other EKM values.
-
-   The mechanism described in this document is intended to fill these
-   requirements.
-
-
-2.  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 [1].
-
-
-3.  Signalling Extractors
-
-   Other protocols which wish to use extractors SHOULD have some way for
-   the peers to signal that an extractor will be used.  An example is a
-   TLS extension, as used in DTLS-SRTP.
-
-
-4.  Extractor Definition
-
-   An extractor takes as input two values:
-
-   o  A disambiguating label string
-   o  A length value
-
-   It then computes:
-
-
-
-Rescorla                  Expires May 20, 2008                  [Page 3]
-
-Internet-Draft               TLS Extractors                November 2007
-
-
-          PRF(master_secret, label,
-              SecurityParameters.client_random +
-              SecurityParameters.server_random)[length]
-
-   The output is a pseudorandom bit string of length bytes generated
-   from the master_secret.
-
-   Label values MUST be registered via Specification Required as
-   described by RFC 2434 [2].  Note that extractor labels have the
-   potential to collide with existing PRF labels.  In order to prevent
-   this, labels SHOULD begin with "EXTRACTOR".  This is not a MUST
-   because there are existing uses which have labels which do not begin
-   with this prefix.
-
-
-5.  Security Considerations
-
-   Because an extractor produces the same value if applied twice with
-   the same label to the same master_secret, it is critical that two EKM
-   values generated with the same label be used for two different
-   purposes--hence the requirement for IANA registration.  However,
-   because extractors depend on the TLS PRF, it is not a threat to the
-   use of an EKM value generated from one label to reveal an EKM value
-   generated from another label.
-
-
-6.  IANA Considerations
-
-   IANA is requested to create (has created) a TLS Extractor Label
-   registry for this purpose.  The initial contents of the registry are
-   given below:
-
-      Value                          Reference
-      -----                          ------------
-      client finished                [RFC4346]
-      server finished                [RFC4346]
-      master secret                  [RFC4346]
-      key expansion                  [RFC4346]
-      client EAP encryption          [RFC2716]
-      ttls keying material           [draft-funk-eap-ttls-v0-01]
-
-   Future values are allocated via RFC2434 Specification Required
-   policy.  The label is a string consisting of printable ASCII
-   characters.  IANA MUST also verify that one label is not a prefix of
-   any other label.  For example, labels "key" or "master secretary" are
-   forbidden.
-
-
-
-
-
-Rescorla                  Expires May 20, 2008                  [Page 4]
-
-Internet-Draft               TLS Extractors                November 2007
-
-
-7.  Acknowledgments
-
-   Thanks to Pasi Eronen for valuable comments and the contents of the
-   IANA section.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [3]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
-        Norrman, "The Secure Real-time Transport Protocol (SRTP)",
-        RFC 3711, March 2004.
-
-   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
-        Protocol Version 1.1", RFC 4346, April 2006.
-
-   [5]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-        Security", RFC 4347, April 2006.
-
-8.2.  Informational References
-
-   [6]  McGrew, D. and E. Rescorla, "Datagram Transport Layer Security
-        (DTLS) Extension to Establish Keys for  Secure Real-time
-        Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-00 (work in
-        progress), July 2007.
-
-
-Author's Address
-
-   Eric Rescorla
-   Network Resonance
-   2064 Edgewood Drive
-   Palo Alto, CA  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-Rescorla                  Expires May 20, 2008                  [Page 5]
-
-Internet-Draft               TLS Extractors                November 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Rescorla                  Expires May 20, 2008                  [Page 6]
-
-
diff --git a/doc/protocol/draft-rescorla-tls-opaque-prf-input-00.txt b/doc/protocol/draft-rescorla-tls-opaque-prf-input-00.txt
deleted file mode 100644
index ff9a74f2f8..0000000000
--- a/doc/protocol/draft-rescorla-tls-opaque-prf-input-00.txt
+++ /dev/null
@@ -1,449 +0,0 @@
-
-
-
-Network Working Group                                        E. Rescorla
-Internet-Draft                                         Network Resonance
-Expires:  June 16, 2007                                        M. Salter
-                                                National Security Agency
-                                                       December 13, 2006
-
-
-                       Opaque PRF Inputs for TLS
-               draft-rescorla-tls-opaque-prf-input-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 16, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a mechanism for using opaque PRF inputs with
-   Transport Layer Security (TLS) and Datagram TLS (DTLS).
-
-
-
-
-
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 1]
-
-Internet-Draft            TLS Opaque PRF Inputs            December 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  The OpaquePRFInput Extension  . . . . . . . . . . . . . . . . . 3
-     3.1.  Negotiating the OpaquePRFInput Extension  . . . . . . . . . 4
-     3.2.  PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-     4.1.  Threats to TLS  . . . . . . . . . . . . . . . . . . . . . . 5
-     4.2.  New Security Issues . . . . . . . . . . . . . . . . . . . . 5
-     4.3.  Scope of Randomness . . . . . . . . . . . . . . . . . . . . 5
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 2]
-
-Internet-Draft            TLS Opaque PRF Inputs            December 2006
-
-
-1.  Introduction
-
-   TLS [RFC4346] and DTLS [RFC4347] use a 32-byte "Random" value
-   consisting of a 32-bit time value time and 28 randomly generated
-   bytes:
-
-         struct {
-            uint32 gmt_unix_time;
-            opaque random_bytes[28];
-         } Random;
-
-   The client and server each contribute a Random value which is then
-   mixed with secret keying material to produce the final per-
-   association keying material.
-
-   In a number of United States Government applications, it is desirable
-   to have some material with the following properties:
-
-   1.  It is contributed both by client and server.
-   2.  It is arbitrary-length.
-   3.  It is mixed into the eventual keying material.
-   4.  It is structured and decodable by the receiving party.
-
-   These requirements are incompatible with the current Random
-   mechanism, which supports a short, fixed-length value.  This document
-   describes a mechanism called "Opaque PRF Inputs for TLS" that meets
-   these requirements.
-
-
-2.  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 [RFC2119].
-
-
-3.  The OpaquePRFInput Extension
-
-   The OpaquePRFInput is carried in a new TLS extension called
-   "OpaquePRFInput".
-
-        struct {
-            opaque opaque_prf_input_value<0..2^16-1>;
-        } OpaquePRFInput;
-
-   The opaque_prf_input_value is an opaque byte-string which is
-   generated in an implementation-dependent fashion.  It MAY be
-   generated by and/or made available to the TLS/DTLS-using application.
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 3]
-
-Internet-Draft            TLS Opaque PRF Inputs            December 2006
-
-
-3.1.  Negotiating the OpaquePRFInput Extension
-
-   The client requests support for the opaque PRF input feature by
-   sending an "opaque_prf_input" extension in its ClientHello.  The
-   "extension_data" field contains an OpaquePRFInput value.
-
-   When a server which does not recognize the "opaque_prf_input"
-   extension receives one, it will ignore it as required by [RFC4366].
-   A server which recognizes the extension MAY choose to ignore it, in
-   which case it SHOULD continue with the exchange as if it had not
-   received the extension.
-
-   If the server wishes to use the opaque PRF input feature, it MUST
-   send its own "opaque_prf_input" extension with an
-   opaque_prf_input_value equal in length to the client's
-   opaque_prf_input_value.  Clients SHOULD check the length of the
-   server's opaque_prf_input_value and generate a fatal
-   "illegal_parameter" error if it is present but does does not match
-   the length that was transmitted in the ClientHello.
-
-   Because RFC 4366 does not permit servers to request extensions which
-   the client did not offer, the client may not offer the
-   "opaque_prf_input" extension even if the server requires it.  In this
-   case, the server should generate a fatal "handshake_failure" alert.
-
-   Because there is no way to mark extensions as critical, the server
-   may ignore the "opaque_prf_input" extension even though the client
-   requires it.  If a client requires the opaque PRF input feature but
-   the server does not negotiate it, the client SHOULD generate a fatal
-   "handshake_failure" alert.
-
-3.2.  PRF Modifications
-
-   When the opaque PRF input feature is in use, the opaque PRF input
-   values MUST be mixed into the PRF along with the client and server
-   random values during the PMS->MS conversion.  Thus, the PRF becomes:
-
-          master_secret = PRF(pre_master_secret, "master secret",
-                              ClientHello.random +
-                              ClientHello.opaque_prf_input_value +
-                              ServerHello.random +
-                              ServerHello.opaque_prf_input_value)[0..47];
-
-   Because new extensions may not be introduced in resumed handshakes,
-   mixing in the opaque PRF inputs during the MS->keying material
-   conversion would simply involve mixing in the same material twice.
-   Therefore, the opaque PRF inputs are only used when the PMS is
-   converted into the MS.
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 4]
-
-Internet-Draft            TLS Opaque PRF Inputs            December 2006
-
-
-4.  Security Considerations
-
-4.1.  Threats to TLS
-
-   When this extension is in use it increases the amount of data that an
-   attacker can inject into the PRF.  This potentially would allow an
-   attacker who had partially compromised the PRF greater scope for
-   influencing the output.  Hash-based PRFs like the one in TLS are
-   designed to be fairly indifferent to the input size (the input is
-   already greater than the block size of most hash functions), however
-   there is currently no proof that a larger input space would not make
-   attacks easier.
-
-   Another concern is that bad implementations might generate low
-   entropy opaque PRF input values.  TLS is designed to function
-   correctly even when fed low-entropy random values because they are
-   primarily used to generate distinct keying material for each
-   connection.
-
-4.2.  New Security Issues
-
-   As noted in Section 3 it is anticipated that applications may want to
-   have access to the opaque PRF input values and that they may contain
-   data that is meaningful at a higher layer.  Because the values are
-   covered by the TLS Finished message, they are integrity-protected by
-   TLS.  However, the application must independently provide any
-   confidentiality necessary for those values.
-
-4.3.  Scope of Randomness
-
-   RFC 4366 specifies that when a session is resumed the extensions from
-   the original connection are used:
-
-         If, on the other hand, the older session is resumed, then the
-         server MUST ignore the extensions and send a server hello
-         containing none of the extension types.  In this case, the
-         functionality of these extensions negotiated during the original
-         session initiation is applied to the resumed session.
-
-   This motivates why the the opaque PRF input does not get mixed into
-   the PRF when generating the keying material from the master secret.
-   Because the same opaque PRF inputs would be used for every connection
-   in a session, they would not provide any differentiation in the
-   keying material between the connections.
-
-
-5.  IANA Considerations
-
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 5]
-
-Internet-Draft            TLS Opaque PRF Inputs            December 2006
-
-
-   This document defines an extension to TLS, in accordance with
-   [RFC4366]:
-
-     enum { opaque_prf_input (??) } ExtensionType;
-
-   [[ NOTE:  These values need to be assigned by IANA ]]
-
-
-6.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress),
-              October 2006.
-
-7.2.  Informative References
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 6]
-
-Internet-Draft            TLS Opaque PRF Inputs            December 2006
-
-
-Authors' Addresses
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto, CA  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-   Margaret Salter
-   National Security Agency
-   9800 Savage Rd.
-   Fort Meade  20755-6709
-   USA
-
-   Email:  msalter@restarea.ncsc.mil
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 7]
-
-Internet-Draft            TLS Opaque PRF Inputs            December 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Rescorla & Salter         Expires June 16, 2007                 [Page 8]
-
-
diff --git a/doc/protocol/draft-rescorla-tls-suiteb-00.txt b/doc/protocol/draft-rescorla-tls-suiteb-00.txt
deleted file mode 100644
index f37266c625..0000000000
--- a/doc/protocol/draft-rescorla-tls-suiteb-00.txt
+++ /dev/null
@@ -1,617 +0,0 @@
-
-
-
-Network Working Group                                          M. Salter
-Internet-Draft                                  National Security Agency
-Expires:  June 16, 2007                                      E. Rescorla
-                                                       Network Resonance
-                                                       December 13, 2006
-
-
-                      SuiteB CipherSuites for TLS
-                    draft-rescorla-tls-suiteb-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 16, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   RFC 4492 describes elliptic curve cipher suites for Transport Layer
-   Security (TLS).  However, all those cipher suites use SHA-1 as their
-   MAC algorithm, which makes them unsuitable for some applications.
-   This document describes eight new CipherSuites for TLS/DTLS which
-   specify stronger digest algorithms and therefore are suitable for use
-   in applications which require compliance with the United States
-   Government's guidelines for "NSA Suite B Cryptography" dated July,
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 1]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-   2005.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
-   3.  SuiteB Requirements  . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Cipher Suites  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     4.1.  HMAC-based Cipher Suites . . . . . . . . . . . . . . . . .  4
-     4.2.  Galois Counter Mode-based Cipher Suites  . . . . . . . . .  5
-   5.  Suite B Compliance Requirements  . . . . . . . . . . . . . . .  6
-     5.1.  Security Levels  . . . . . . . . . . . . . . . . . . . . .  6
-     5.2.  Acceptable Curves  . . . . . . . . . . . . . . . . . . . .  6
-   6.  TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-     7.1.  Downgrade Attack . . . . . . . . . . . . . . . . . . . . .  7
-     7.2.  Perfect Forward Secrecy  . . . . . . . . . . . . . . . . .  8
-     7.3.  Counter Reuse with GCM . . . . . . . . . . . . . . . . . .  8
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     10.1. Normative References . . . . . . . . . . . . . . . . . . .  8
-     10.2. Informative References . . . . . . . . . . . . . . . . . .  9
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 2]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-1.  Introduction
-
-   In July, 2005 the National Security Agency posted "Fact Sheet, NSA
-   Suite B Cryptography" which stated:
-
-       To complement the existing policy for the use of the Advanced
-       Encryption Standard (AES) to protect national security systems
-       and information as specified in The National Policy on the use of
-       the Advanced Encryption Standard (AES) to Protect National
-       Security Systems and National Security Information (CNSSP-15),
-       the National Security Agency (NSA) announced Suite B Cryptography
-       at the 2005 RSA Conference.  In addition to the AES, Suite B
-       includes cryptographic algorithms for hashing, digital
-       signatures, and key exchange.
-
-       Suite B only specifies the cryptographic algorithms to be
-       used. Many other factors need to be addressed in determining
-       whether a particular device implementing a particular set of
-       cryptographic algorithms should be used to satisfy a particular
-       requirement.
-
-   Among those factors are "requirements for interoperability both
-   domestically and internationally".
-
-   This document is intended to address those requirements in the
-   particular case of TLS [RFC4346] and Datagram TLS [RFC4347].  Much of
-   what is needed to define the Suite B CipherSuites is specified in RFC
-   4492 "ECC for TLS" [RFC4492].  We use the terminology, notation, and
-   details from that document to the extent possible.  A key ingredient
-   of SuiteB not found in RFC4492--or the definition of TLS itself prior
-   to 1.2--is the use of SHA256 or SHA384 for key derivation.  TLS 1.2
-   [I-D.ietf-tls-rfc4346-bis] allows for the use of these hash in the
-   pseudo-random function (PRF) used to derive the keys.
-
-   Unless specifically stated herein, details of the protocol are
-   identical to those given in [I-D.ietf-tls-rfc4346-bis] and [RFC4492]
-
-
-2.  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 [RFC2119].
-
-
-3.  SuiteB Requirements
-
-   The "Suite B Fact Sheet" requires that key establishment and
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 3]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-   authentication algorithms be based on Elliptic Curve Cryptography,
-   that the encryption algorithm be AES [AES], and that the function
-   used for key derivation and data integrity be SHA [SHS].  It defines
-   two security levels, of 128 and 192 bits.
-
-   In particular it states:
-
-      SUITE B includes:
-
-        Encryption:          Advanced Encryption Standard (AES)  -
-                             FIPS 197 with keys sizes of 128 and 256
-                             bits)
-
-        Digital Signature:   Elliptic Curve Digital Signature Algorithm -
-                             FIPS 186-2 (using the curves with 256 and
-                             384-bit prime moduli)
-
-        Key Exchange:        Elliptic Curve Diffie-Hellman or Elliptic
-                             Curve MQV Draft NIST Special Publication
-                             800-56 (using the curves with 256 and
-                             384-bit prime moduli)
-
-        Hashing:             Secure Hash Algorithm - FIPS 180-2
-                             (using SHA-256 and SHA-384)
-
-      All implementations of Suite B must, at a minimum, include AES
-      with 128-bit keys, the 256-bit prime modulus elliptic curve and
-      SHA-256 as a common mode for widespread interoperability.
-
-   The 128-bit security level corresponds to an elliptic curve size of
-   256 bits, AES-128, and SHA-256.  The 192-bit security level
-   corresponds to an elliptic curve size of 384 bits, AES-256, and SHA-
-   384.  Because both settings require a digest algorithm other than
-   SHA-1, new cipher suites are required and defined in this document.
-
-
-4.  Cipher Suites
-
-   This document defines 8 new cipher suites to be added to TLS.  All
-   use Elliptic Curve Cryptography for key exchange and digital
-   signature, as defined in RFC 4492.
-
-4.1.  HMAC-based Cipher Suites
-
-   The first four cipher suites use AES in CBC mode with an HMAC-based
-   MAC:
-
-
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 4]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256  = {0xXX,XX}
-        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384  = {0xXX,XX}
-        CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX}
-        CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX}
-
-   These four cipher suites are the same as the corresponding cipher
-   suites in RFC 4492 (TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
-   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
-   TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, and
-   TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA) except that SHA-256 is used for
-   the MAC with AES-128 and SHA-384 is used for the MAC with AES-256.
-   As described in TLS 1.2, the digest used for the MAC MUST also be
-   used in the PRF.
-
-4.2.  Galois Counter Mode-based Cipher Suites
-
-   The second four cipher suites use the new authenticated encryption
-   modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
-
-        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  = {0xXX,XX}
-        CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384  = {0xXX,XX}
-        CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX}
-        CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX}
-
-   These cipher suites use the authenticated encryption with additional
-   data algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  The "nonce" input to the AEAD algorithm SHALL
-   be 12 bytes long, and constructed as follows:
-
-             struct {
-                case client:
-                    uint32 client_write_IV;  // low order 32-bits
-                case server:
-                    uint32 server_write_IV;  // low order 32-bits
-                uint64 seq_num;
-             } GCMNonce.
-
-   In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
-   48-bit seq_num.
-
-   This construction allows the internal counter to be 32-bits long,
-   which is the most convenient size for use with GCM.
-
-   Note:  the role played by the client_write_IV and server_write_IV is
-   often called "salt" in counter mode specifications [RFC3686].
-
-   Because GCM does not use HMAC as a MAC function, the hash function
-   for the TLS PRF must be explicitly specified.
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 5]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be SHA-256.
-
-   For TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
-   TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 it SHALL be SHA-384.
-
-
-5.  Suite B Compliance Requirements
-
-   The following requirements apply only to SuiteB compliant
-   implementations.  However, ordinary TLS implementations MAY use these
-   cipher suites even if they do not comply with the requirements in
-   this section.
-
-   To be considered "SuiteB compatible" at least one of the CipherSuites
-   defined in this document MUST be negotiated.  In compliance with the
-   guidance in the Suite B Fact Sheet every TLS implementation of SuiteB
-   SHOULD implement TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
-
-5.1.  Security Levels
-
-   As described in Section 1, Suite B specifies two security levels, 128
-   and 192 bit.  The following table lists the security levels for each
-   cipher suite:
-
-       +-----------------------------------------+----------------+
-       | Cipher Suite                            | Security Level |
-       +-----------------------------------------+----------------+
-       | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | 128            |
-       | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | 192            |
-       | TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256  | 128            |
-       | TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384  | 192            |
-       | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128            |
-       | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192            |
-       | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256  | 128            |
-       | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384  | 192            |
-       +-----------------------------------------+----------------+
-
-5.2.  Acceptable Curves
-
-   RFC 4492 defines a variety of elliptic curves.  For cipher suites
-   defined in this specification, only secp256r1 (23) or secp384r1 (24)
-   may be used.  (These are the same curves that appear in FIPS 186-2
-   and ANSI X9.62 as P256 and P384, respectively).  For cipher suites at
-   the 128-bit security level, secp256r1 MUST be used.  For cipher
-   suites at the 192-bit security level, secp256r MUST be used.  Both
-   uncompressed (0) and ansiX962_compressed_prime(1) point formats
-   SHOULD be supported.
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 6]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-   Clients desiring to negotiate only a SuiteB-compliant connection MUST
-   generate a "Supported Elliptic Curves Extension" containing only the
-   allowed curves.  These curves MUST match the cipher suite security
-   levels being offered.  Clients which are willing to do both SuiteB-
-   compliant and non-SuiteB-compliant connections MAY omit the extension
-   or send the extension but offer other curves as well as the
-   appropriate SuiteB ones.
-
-   Servers desiring to negotiate a SuiteB-compliant connection SHOULD
-   check for the presence of the extension, but MUST NOT negotiate
-   inappropriate curves even if they are offered by the client.  This
-   allows a Client which is willing to do either SuiteB-compliant or
-   non-SuiteB-compliant modes to interoperate with a server which will
-   only do SuiteB-compliant modes.  If the client does not advertise an
-   acceptable curve, the server MUST generate a fatal
-   "handshake_failure" alert and terminate the connection.  Clients
-   SHOULD check the chosen curve to make sure it is acceptable.
-
-
-6.  TLS Versions
-
-   Because these cipher suites depend on features available only in TLS
-   1.2 (PRF flexibility and combined authenticated encryption cipher
-   modes), they MUST NOT be negotiated in older versions of TLS.
-   Clients MUST NOT offer these cipher suites if they do not offer TLS
-   1.2 or later.  Servers which select an earlier version of TLS MUST
-   NOT select one of these cipher suites.  Because TLS has no way for
-   the client to indicate that it supports TLS 1.2 but not earlier, a
-   non-compliant server might potentially negotiate TLS 1.1 or earlier
-   and select one of the cipher suites in this document.  Clients MUST
-   check the TLS version and generate a fatal "illegal_parameter" alert
-   if they detect an incorrect version.
-
-
-7.  Security Considerations
-
-   The security considerations in RFC 4346 and RFC 4492 apply to this
-   document as well.  The remainder of this section describes security
-   considerations specific to the cipher suites described in this
-   document.
-
-7.1.  Downgrade Attack
-
-   TLS negotiation is only as secure as the weakest cipher suite that is
-   supported.  For instance, an implementation which supports both 160-
-   bit and 256-bit elliptic curves can be subject to an active downgrade
-   attack to the 160-bit security level.  An attacker who can attack
-   that can then forge the Finished handshake check and successfully
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 7]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-   mount a man-in-the-middle attack.
-
-   In environments where there is a concern about this form of attack,
-   implementations SHOULD only offer cipher suites which are as strong
-   as their minimum acceptable security level.
-
-7.2.  Perfect Forward Secrecy
-
-   The static ECDH cipher suites specified in this document do not
-   provide perfect forward secrecy (PFS).  Thus, compromise of a single
-   static key leads to potential decryption of all traffic protected
-   using that key.  Implementors of this specification SHOULD provide at
-   least one ECDHE mode of operation.
-
-7.3.  Counter Reuse with GCM
-
-   AES-GCM is only secure if the counter is never reused.  The IV
-   construction algorithm above is designed to ensure that that cannot
-   happen.
-
-
-8.  IANA Considerations
-
-   IANA has assigned the following values for the SuiteB cipher suites:
-
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256   = {0xXX,XX}
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384   = {0xXX,XX}
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256    = {0xXX,XX}
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384    = {0xXX,XX}
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256   = {0xXX,XX}
-      CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384   = {0xXX,XX}
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256    = {0xXX,XX}
-      CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384    = {0xXX,XX}
-
-
-9.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 8]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-              Counter Mode With IPsec Encapsulating Security Payload
-              (ESP)", RFC 3686, January 2004.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-01 (work in progress),
-              October 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress),
-              October 2006.
-
-   [I-D.ietf-tls-ctr]
-              Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
-              Suites for TLS and DTLS", draft-ietf-tls-ctr-01 (work in
-              progress), June 2006.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois;/Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, April 2006.
-
-10.2.  Informative References
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla         Expires June 16, 2007                 [Page 9]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-Authors' Addresses
-
-   Margaret Salter
-   National Security Agency
-   9800 Savage Rd.
-   Fort Meade  20755-6709
-   USA
-
-   Email:  msalter@restarea.ncsc.mil
-
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla         Expires June 16, 2007                [Page 10]
-
-Internet-Draft               SuiteB for TLS                December 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Salter & Rescorla         Expires June 16, 2007                [Page 11]
-
-
diff --git a/doc/protocol/draft-rescorla-tls-suiteb-01.txt b/doc/protocol/draft-rescorla-tls-suiteb-01.txt
deleted file mode 100644
index e6644fbd59..0000000000
--- a/doc/protocol/draft-rescorla-tls-suiteb-01.txt
+++ /dev/null
@@ -1,449 +0,0 @@
-
-
-
-Network Working Group                                          M. Salter
-Internet-Draft                                  National Security Agency
-Intended status:  Informational                              E. Rescorla
-Expires:  December 4, 2007                             Network Resonance
-                                                            June 2, 2007
-
-
-                     Suite B Cipher Suites for TLS
-                    draft-rescorla-tls-suiteb-01.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 4, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   The United States Government has published guidelines for "NSA Suite
-   B Cryptography" dated July, 2005, which defines cryptographic
-   algorithm polcy for national security applications.  This document
-   defines a profile of TLS which is conformant with Suite B.
-
-
-
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 1]
-
-Internet-Draft               Suite B for TLS                   June 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Suite B Requirements  . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Suite B Compliance Requirements . . . . . . . . . . . . . . . . 4
-     4.1.  Security Levels . . . . . . . . . . . . . . . . . . . . . . 4
-     4.2.  Acceptable Curves . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 2]
-
-Internet-Draft               Suite B for TLS                   June 2007
-
-
-1.  Introduction
-
-   In July, 2005 the National Security Agency posted "Fact Sheet, NSA
-   Suite B Cryptography" which stated:
-
-       To complement the existing policy for the use of the Advanced
-       Encryption Standard (AES) to protect national security systems
-       and information as specified in The National Policy on the use of
-       the Advanced Encryption Standard (AES) to Protect National
-       Security Systems and National Security Information (CNSSP-15),
-       the National Security Agency (NSA) announced Suite B Cryptography
-       at the 2005 RSA Conference.  In addition to the AES, Suite B
-       includes cryptographic algorithms for hashing, digital
-       signatures, and key exchange.
-
-       Suite B only specifies the cryptographic algorithms to be
-       used. Many other factors need to be addressed in determining
-       whether a particular device implementing a particular set of
-       cryptographic algorithms should be used to satisfy a particular
-       requirement.
-
-   Among those factors are "requirements for interoperability both
-   domestically and internationally".
-
-   This document is a profile of of TLS 1.2 [I-D.ietf-tls-rfc4346-bis]
-   and of the cipher suites defined in [I-D.ietf-tls-ecc-new-mac], but
-   does not itself define any new cipher suites.  This profile requires
-   TLS 1.2.
-
-
-2.  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 [RFC2119].
-
-
-3.  Suite B Requirements
-
-   The "Suite B Fact Sheet" requires that key establishment and
-   authentication algorithms be based on Elliptic Curve Cryptography,
-   that the encryption algorithm be AES [AES], and that the function
-   used for key derivation and data integrity be SHA [SHS].  It defines
-   two security levels, of 128 and 192 bits.
-
-   In particular it states:
-
-
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 3]
-
-Internet-Draft               Suite B for TLS                   June 2007
-
-
-      SUITE B includes:
-
-       Encryption:          Advanced Encryption Standard (AES)  -
-                            FIPS 197 (with keys sizes of 128 and 256
-                            bits)
-
-       Digital Signature:   Elliptic Curve Digital Signature Algorithm -
-                            FIPS 186-2 (using the curves with 256 and
-                            384-bit prime moduli)
-
-       Key Exchange:        Elliptic Curve Diffie-Hellman or Elliptic
-                            Curve MQV Draft NIST Special Publication
-                            800-56 (using the curves with 256 and
-                            384-bit prime moduli)
-
-       Hashing:             Secure Hash Algorithm - FIPS 180-2
-                            (using SHA-256 and SHA-384)
-
-      All implementations of Suite B must, at a minimum, include AES
-      with 128-bit keys, the 256-bit prime modulus elliptic curve and
-      SHA-256 as a common mode for widespread interoperability.
-
-   The 128-bit security level corresponds to an elliptic curve size of
-   256 bits, AES-128, and SHA-256.  The 192-bit security level
-   corresponds to an elliptic curve size of 384 bits, AES-256, and SHA-
-   384.
-
-
-4.  Suite B Compliance Requirements
-
-   To be considered "Suite B compatible" at least one of the Galois
-   Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac]
-   MUST be negotiated.  In compliance with the guidance in the Suite B
-   Fact Sheet every TLS implementation of Suite B SHOULD implement
-   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
-
-4.1.  Security Levels
-
-   As described in Section 1, Suite B specifies two security levels, 128
-   and 192 bit.  The following table lists the security levels for each
-   cipher suite:
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 4]
-
-Internet-Draft               Suite B for TLS                   June 2007
-
-
-       +-----------------------------------------+----------------+
-       | Cipher Suite                            | Security Level |
-       +-----------------------------------------+----------------+
-       | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128            |
-       | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256  | 128            |
-       | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192            |
-       | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384  | 192            |
-       +-----------------------------------------+----------------+
-
-4.2.  Acceptable Curves
-
-   RFC 4492 defines a variety of elliptic curves.  For cipher suites
-   defined in this specification, only secp256r1 (23) or secp384r1 (24)
-   may be used.  (These are the same curves that appear in FIPS 186-2 as
-   P-256 and P-384, respectively.)  For cipher suites at the 128-bit
-   security level, secp256r1 MUST be used.  For cipher suites at the
-   192-bit security level, secp384r1 MUST be used.  RFC 4492 requires
-   that uncompressed (0) form be supported. ansiX962_compressed_prime(1)
-   point formats MAY be supported.
-
-   Clients desiring to negotiate only a Suite B-compliant connection
-   MUST generate a "Supported Elliptic Curves Extension" containing only
-   the allowed curves.  These curves MUST match the cipher suite
-   security levels being offered.  Clients which are willing to do both
-   Suite B-compliant and non-Suite B-compliant connections MAY omit the
-   extension or send the extension but offer other curves as well as the
-   appropriate Suite B ones.
-
-   Servers desiring to negotiate a Suite B-compliant connection SHOULD
-   check for the presence of the extension, but MUST NOT negotiate
-   inappropriate curves even if they are offered by the client.  This
-   allows a Client which is willing to do either Suite B-compliant or
-   non-Suite B-compliant modes to interoperate with a server which will
-   only do Suite B-compliant modes.  If the client does not advertise an
-   acceptable curve, the server MUST generate a fatal
-   "handshake_failure" alert and terminate the connection.  Clients MUST
-   check the chosen curve to make sure it is acceptable.
-
-
-5.  Security Considerations
-
-   Most of the security considerations for this document are described
-   in TLS 1.2 [I-D.ietf-tls-rfc4346-bis], RFC 4492 [RFC4492], and
-   [I-D.ietf-tls-ecc-new-mac].  Readers should consult those documents.
-
-   In order to meet the goal of a consistent security level for the
-   entire cipher suite, in Suite B mode TLS implementations MUST ONLY
-   use the curves defined in Section 4.2.  Otherwise, it is possible to
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 5]
-
-Internet-Draft               Suite B for TLS                   June 2007
-
-
-   have a set of symmetric algorithms with much weaker or stronger
-   security properties than the asymmetric (ECC) algorithms.
-
-
-6.  IANA Considerations
-
-   This document defines no actions for IANA.
-
-
-7.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-03 (work in progress),
-              March 2007.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [I-D.ietf-tls-ecc-new-mac]
-              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-              256/384 and AES Galois Counter Mode", April 2007.
-
-8.2.  Informative References
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 6]
-
-Internet-Draft               Suite B for TLS                   June 2007
-
-
-Authors' Addresses
-
-   Margaret Salter
-   National Security Agency
-   9800 Savage Rd.
-   Fort Meade  20755-6709
-   USA
-
-   Email:  msalter@restarea.ncsc.mil
-
-
-   Eric Rescorla
-   Network Resonance
-   2483 E. Bayshore #212
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@networkresonance.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 7]
-
-Internet-Draft               Suite B for TLS                   June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Salter & Rescorla       Expires December 4, 2007                [Page 8]
-
-
diff --git a/doc/protocol/draft-rescorla-tls-suiteb-02.txt b/doc/protocol/draft-rescorla-tls-suiteb-02.txt
deleted file mode 100644
index a8ac2cf2b3..0000000000
--- a/doc/protocol/draft-rescorla-tls-suiteb-02.txt
+++ /dev/null
@@ -1,449 +0,0 @@
-
-
-
-Network Working Group                                          M. Salter
-Internet-Draft                                  National Security Agency
-Intended status:  Informational                              E. Rescorla
-Expires:  October 16, 2008                             Network Resonance
-                                                          April 14, 2008
-
-
-                     Suite B Cipher Suites for TLS
-                    draft-rescorla-tls-suiteb-02.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on October 16, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-Abstract
-
-   The United States Government has published guidelines for "NSA Suite
-   B Cryptography" dated July, 2005, which defines cryptographic
-   algorithm polcy for national security applications.  This document
-   defines a profile of TLS which is conformant with Suite B.
-
-
-
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 1]
-
-Internet-Draft               Suite B for TLS                  April 2008
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-   3.  Suite B Requirements  . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Suite B Compliance Requirements . . . . . . . . . . . . . . . . 4
-     4.1.  Security Levels . . . . . . . . . . . . . . . . . . . . . . 4
-     4.2.  Acceptable Curves . . . . . . . . . . . . . . . . . . . . . 5
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 2]
-
-Internet-Draft               Suite B for TLS                  April 2008
-
-
-1.  Introduction
-
-   In July, 2005 the National Security Agency posted "Fact Sheet, NSA
-   Suite B Cryptography" which stated:
-
-       To complement the existing policy for the use of the Advanced
-       Encryption Standard (AES) to protect national security systems
-       and information as specified in The National Policy on the use of
-       the Advanced Encryption Standard (AES) to Protect National
-       Security Systems and National Security Information (CNSSP-15),
-       the National Security Agency (NSA) announced Suite B Cryptography
-       at the 2005 RSA Conference.  In addition to the AES, Suite B
-       includes cryptographic algorithms for hashing, digital
-       signatures, and key exchange.
-
-       Suite B only specifies the cryptographic algorithms to be
-       used. Many other factors need to be addressed in determining
-       whether a particular device implementing a particular set of
-       cryptographic algorithms should be used to satisfy a particular
-       requirement.
-
-   Among those factors are "requirements for interoperability both
-   domestically and internationally".
-
-   This document is a profile of of TLS 1.2 [I-D.ietf-tls-rfc4346-bis]
-   and of the cipher suites defined in [I-D.ietf-tls-ecc-new-mac], but
-   does not itself define any new cipher suites.  This profile requires
-   TLS 1.2.
-
-
-2.  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 [RFC2119].
-
-
-3.  Suite B Requirements
-
-   The "Suite B Fact Sheet" requires that key establishment and
-   authentication algorithms be based on Elliptic Curve Cryptography,
-   that the encryption algorithm be AES [AES], and that the function
-   used for key derivation and data integrity be SHA [SHS].  It defines
-   two security levels, of 128 and 192 bits.
-
-   In particular it states:
-
-
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 3]
-
-Internet-Draft               Suite B for TLS                  April 2008
-
-
-      SUITE B includes:
-
-       Encryption:          Advanced Encryption Standard (AES)  -
-                            FIPS 197 (with keys sizes of 128 and 256
-                            bits)
-
-       Digital Signature:   Elliptic Curve Digital Signature Algorithm -
-                            FIPS 186-2 (using the curves with 256 and
-                            384-bit prime moduli)
-
-       Key Exchange:        Elliptic Curve Diffie-Hellman or Elliptic
-                            Curve MQV Draft NIST Special Publication
-                            800-56 (using the curves with 256 and
-                            384-bit prime moduli)
-
-       Hashing:             Secure Hash Algorithm - FIPS 180-2
-                            (using SHA-256 and SHA-384)
-
-      All implementations of Suite B must, at a minimum, include AES
-      with 128-bit keys, the 256-bit prime modulus elliptic curve and
-      SHA-256 as a common mode for widespread interoperability.
-
-   The 128-bit security level corresponds to an elliptic curve size of
-   256 bits, AES-128, and SHA-256.  The 192-bit security level
-   corresponds to an elliptic curve size of 384 bits, AES-256, and SHA-
-   384.
-
-
-4.  Suite B Compliance Requirements
-
-   To be considered "Suite B compatible" at least one of the Galois
-   Counter Mode (GCM) CipherSuites defined in [I-D.ietf-tls-ecc-new-mac]
-   MUST be negotiated.  In compliance with the guidance in the Suite B
-   Fact Sheet every TLS implementation of Suite B SHOULD implement
-   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.
-
-4.1.  Security Levels
-
-   As described in Section 1, Suite B specifies two security levels, 128
-   and 192 bit.  The following table lists the security levels for each
-   cipher suite:
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 4]
-
-Internet-Draft               Suite B for TLS                  April 2008
-
-
-       +-----------------------------------------+----------------+
-       | Cipher Suite                            | Security Level |
-       +-----------------------------------------+----------------+
-       | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128            |
-       | TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256  | 128            |
-       | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192            |
-       | TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384  | 192            |
-       +-----------------------------------------+----------------+
-
-4.2.  Acceptable Curves
-
-   RFC 4492 defines a variety of elliptic curves.  For cipher suites
-   defined in this specification, only secp256r1 (23) or secp384r1 (24)
-   may be used.  (These are the same curves that appear in FIPS 186-2
-   [DSS] as P-256 and P-384, respectively.)  For cipher suites at the
-   128-bit security level, secp256r1 MUST be used.  For cipher suites at
-   the 192-bit security level, secp384r1 MUST be used.  RFC 4492
-   requires that uncompressed (0) form be supported.
-   ansiX962_compressed_prime(1) point formats MAY be supported.
-
-   Clients desiring to negotiate only a Suite B-compliant connection
-   MUST generate a "Supported Elliptic Curves Extension" containing only
-   the allowed curves.  These curves MUST match the cipher suite
-   security levels being offered.  Clients which are willing to do both
-   Suite B-compliant and non-Suite B-compliant connections MAY omit the
-   extension or send the extension but offer other curves as well as the
-   appropriate Suite B ones.
-
-   Servers desiring to negotiate a Suite B-compliant connection SHOULD
-   check for the presence of the extension, but MUST NOT negotiate
-   inappropriate curves even if they are offered by the client.  This
-   allows a Client which is willing to do either Suite B-compliant or
-   non-Suite B-compliant modes to interoperate with a server which will
-   only do Suite B-compliant modes.  If the client does not advertise an
-   acceptable curve, the server MUST generate a fatal
-   "handshake_failure" alert and terminate the connection.  Clients MUST
-   check the chosen curve to make sure it is acceptable.
-
-
-5.  Security Considerations
-
-   Most of the security considerations for this document are described
-   in TLS 1.2 [I-D.ietf-tls-rfc4346-bis], RFC 4492 [RFC4492],
-   [I-D.ietf-tls-rsa-aes-gcm], and [I-D.ietf-tls-ecc-new-mac].  Readers
-   should consult those documents.
-
-   In order to meet the goal of a consistent security level for the
-   entire cipher suite, in Suite B mode TLS implementations MUST ONLY
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 5]
-
-Internet-Draft               Suite B for TLS                  April 2008
-
-
-   use the curves defined in Section 4.2.  Otherwise, it is possible to
-   have a set of symmetric algorithms with much weaker or stronger
-   security properties than the asymmetric (ECC) algorithms.
-
-
-6.  IANA Considerations
-
-   This document defines no actions for IANA.
-
-
-7.  Acknowledgements
-
-   This work was supported by the US Department of Defense.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
-              (work in progress), March 2008.
-
-   [I-D.ietf-tls-ecc-new-mac]
-              Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
-              256/384 and AES Galois Counter  Mode",
-              draft-ietf-tls-ecc-new-mac-04 (work in progress),
-              February 2008.
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [SHS]      National Institute of Standards and Technology, "Secure
-              Hash Standard", FIPS 180-2, August 2002.
-
-   [DSS]      National Institute of Standards and Technology, "Digital
-              Signature Standard", FIPS 186-2, January 2000.
-
-
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 6]
-
-Internet-Draft               Suite B for TLS                  April 2008
-
-
-8.2.  Informative References
-
-   [I-D.ietf-tls-rsa-aes-gcm]
-              Salowey, J., Choudhury, A., and D. McGrew, "AES-GCM Cipher
-              Suites for TLS", draft-ietf-tls-rsa-aes-gcm-02 (work in
-              progress), February 2008.
-
-
-Authors' Addresses
-
-   Margaret Salter
-   National Security Agency
-   9800 Savage Rd.
-   Fort Meade  20755-6709
-   USA
-
-   Email:  msalter@restarea.ncsc.mil
-
-
-   Eric Rescorla
-   Network Resonance
-   2064 Edgewood Drive
-   Palo Alto  94303
-   USA
-
-   Email:  ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 7]
-
-Internet-Draft               Suite B for TLS                  April 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Salter & Rescorla       Expires October 16, 2008                [Page 8]
-
-
diff --git a/doc/protocol/draft-salowey-tls-rfc4507bis-00.txt b/doc/protocol/draft-salowey-tls-rfc4507bis-00.txt
deleted file mode 100644
index 8623e73bf5..0000000000
--- a/doc/protocol/draft-salowey-tls-rfc4507bis-00.txt
+++ /dev/null
@@ -1,1009 +0,0 @@
-
-
-
-Network Working Group                                         J. Salowey
-Internet-Draft                                                   H. Zhou
-Obsoletes: 4507 (if approved)                              Cisco Systems
-Intended status: Standards Track                               P. Eronen
-Expires: December 13, 2007                                         Nokia
-                                                           H. Tschofenig
-                                                  Nokia Siemens Networks
-                                                           June 11, 2007
-
-
- Transport Layer Security (TLS) Session Resumption without Server-Side
-                                 State
-                  draft-salowey-tls-rfc4507bis-00.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on December 13, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document describes a mechanism that enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 1]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   ticket and forwards it to the client.  The client can subsequently
-   resume a session using the obtained ticket.  This document obsoletes
-   RFC 4507.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.2.  SessionTicket TLS Extension  . . . . . . . . . . . . . . .  7
-     3.3.  NewSessionTicket Handshake Message . . . . . . . . . . . .  7
-     3.4.  Interaction with TLS Session ID  . . . . . . . . . . . . .  9
-   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . .  9
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-     5.1.  Invalidating Sessions  . . . . . . . . . . . . . . . . . . 11
-     5.2.  Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 11
-     5.3.  Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 11
-     5.4.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 12
-     5.5.  Ticket Protection Key Management . . . . . . . . . . . . . 12
-     5.6.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 12
-     5.7.  Alternate Ticket Formats and Distribution Schemes  . . . . 12
-     5.8.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 13
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
-   Appendix A.  Discussion of Changes to RFC4507  . . . . . . . . . . 15
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
-   Intellectual Property and Copyright Statements . . . . . . . . . . 18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 2]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) session without requiring session-specific state at the TLS
-   server.  This mechanism may be used with any TLS ciphersuite.  This
-   document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1
-   defined in [RFC4346].  The mechanism makes use of TLS extensions
-   defined in [RFC4366] and defines a new TLS message type.
-
-   This mechanism is useful in the following situations:
-
-
-      1.  servers that handle a large number of transactions from
-          different users
-      2.  servers that desire to cache sessions for a long time
-      3.  ability to load balance requests across servers
-      4.  embedded servers with little memory
-
-   This document obsoletes RFC 4507 [RFC4507] to correct an error in the
-   encoding that caused the specification to differ from deployed
-   implementations.  At the time of this writing there are no known
-   implementations that follow the encoding specified in RFC 4507.  This
-   update to RFC 4507 aligns the document with this currently deployed
-   implementations.  More details of the change are given in Appendix A.
-
-
-2.  Terminology
-
-   Within this document, the term 'ticket' refers to a cryptographically
-   protected data structure that is created by the server and consumed
-   by the server to rebuild session-specific state.
-
-   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 [RFC2119].
-
-
-3.  Protocol
-
-   This specification describes a mechanism to distribute encrypted
-   session-state information in the form of a ticket.  The ticket is
-   created by a TLS server and sent to a TLS client.  The TLS client
-   presents the ticket to the TLS server to resume a session.
-   Implementations of this specification are expected to support both
-   mechanisms.  Other specifications can take advantage of the session
-   tickets, perhaps specifying alternative means for distribution or
-   selection.  For example, a separate specification may describe an
-   alternate way to distribute a ticket and use the TLS extension in
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 3]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   this document to resume the session.  This behavior is beyond the
-   scope of the document and would need to be described in a separate
-   specification.
-
-3.1.  Overview
-
-   The client indicates that it supports this mechanism by including a
-   SessionTicket TLS extension in the ClientHello message.  The
-   extension will be empty if the client does not already possess a
-   ticket for the server.  The extension is described in Section 3.2.
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   TLS handshake message described in Section 3.3.  This message is sent
-   during the TLS handshake before the ChangeCipherSpec message, after
-   the server has successfully verified the client's Finished message.
-
-
-         Client                                               Server
-
-         ClientHello
-        (empty SessionTicket extension)-------->
-                                                         ServerHello
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                    NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   Figure 1: Message flow for full handshake issuing new session ticket
-
-   The client caches this ticket along with the master secret and other
-   parameters associated with the current session.  When the client
-   wishes to resume the session, it includes the ticket in the
-   SessionTicket extension within the ClientHello message.  The server
-   then decrypts the received ticket, verifies the ticket's validity,
-   retrieves the session state from the contents of the ticket, and uses
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 4]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   this state to resume the session.  The interaction with the TLS
-   Session ID is described in Section 3.4.  If the server successfully
-   verifies the client's ticket, then it may renew the ticket by
-   including a NewSessionTicket handshake message after the ServerHello.
-
-
-         Client                                                Server
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                      (empty SessionTicket extension)
-                                                     NewSessionTicket
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-          Figure 2: Message flow for abbreviated handshake using
-                          new	
-			session ticket
-
-   A recommended ticket format is given in Section 4.
-
-   If the server cannot or does not want to honor the ticket, then it
-   can initiate a full handshake with the client.
-
-   In the case that the server does not wish to issue a new ticket at
-   this time, it just completes the handshake without including a
-   SessionTicket extension or NewSessionTicket handshake message.  This
-   is shown below (this flow is identical to Figure 1 in RFC 2246,
-   except for the session ticket extension in the first message):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 5]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-         Client                                               Server
-
-         ClientHello
-         (SessionTicket extension)    -------->
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-    Figure 3: Message flow for server completing full handshake without
-                        issuing new session ticket
-
-   If the server rejects the ticket, it may still wish to issue a new
-   ticket after performing the full handshake as shown below (this flow
-   is identical to Figure 1, except the SessionTicket extension in the
-   Client Hello is not empty):
-
-
-         Client                                               Server
-
-         ClientHello
-         (SessionTicket extension) -------->
-                                                         ServerHello
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                  <--------          ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                 -------->
-                                                    NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                  <--------                 Finished
-         Application Data         <------->         Application Data
-
-    Figure 4: Message flow for server rejecting ticket, performing full
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 6]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-                 handshake and issuing new session ticket
-
-3.2.  SessionTicket TLS Extension
-
-   The SessionTicket TLS extension is based on [RFC4366].  The format of
-   the ticket is an opaque structure used to carry session-specific
-   state information.  This extension may be sent in the ClientHello and
-   ServerHello.
-
-   If the client possesses a ticket that it wants to use to resume a
-   session, then it includes the ticket in the SessionTicket extension
-   in the ClientHello.  If the client does not have a ticket and is
-   prepared to receive one in the NewSessionTicket handshake message,
-   then it MUST include a zero-length ticket in the SessionTicket
-   extension.  If the client is not prepared to receive a ticket in the
-   NewSessionTicket handshake message then it MUST NOT include a
-   SessionTicket extension unless it is sending a non-empty ticket it
-   received through some other means from the server.
-
-   The server uses an zero-length SessionTicket extension to indicate to
-   the client that it will send a new session ticket using the
-   NewSessionTicket handshake message described in Section 3.3.  The
-   server MUST send this extension in the ServerHello if it wishes to
-   issue a new ticket to the client using the NewSessionTicket handshake
-   message.  The server MUST NOT send this extension if it does not
-   receive one in the ClientHello.
-
-   If the server fails to verify the ticket, then it falls back to
-   performing a full handshake.  If the ticket is accepted by the server
-   but the handshake fails, the client SHOULD delete the ticket.
-
-   The SessionTicket extension has been assigned the number 35.  The
-   extension_data field of SessionTicket extension contains the ticket.
-
-3.3.  NewSessionTicket Handshake Message
-
-   This message is sent by the server during the TLS handshake before
-   the ChangeCipherSpec message.  This message MUST be sent if the
-   server included a SessionTicket extension in the ServerHello.  This
-   message MUST NOT be sent if the server did not include a
-   SessionTicket extension in the ServerHello.  In the case of a full
-   handshake, the server MUST verify the client's Finished message
-   before sending the ticket.  The client MUST NOT treat the ticket as
-   valid until it has verified the server's Finished message.  If the
-   server determines that it does not want to include a ticket after it
-   has included the SessionTicket extension in the ServerHello, then it
-   sends a zero-length ticket in the NewSessionTicket handshake message.
-
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 7]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   If the server successfully verifies the client's ticket, then it MAY
-   renew the ticket by including a NewSessionTicket handshake message
-   after the ServerHello in the abbreviated handshake.  The client
-   should start using the new ticket as soon as possible after it
-   verifies the server's Finished message for new connections.  Note
-   that since the updated ticket is issued before the handshake
-   completes, it is possible that the client may not put the new ticket
-   into use before it initiates new connections.  The server MUST NOT
-   assume that the client actually received the updated ticket until it
-   successfully verifies the client's Finished message.
-
-   The NewSessionTicket handshake message has been assigned the number 4
-   and its definition is given at the end of this section.  The
-   ticket_lifetime_hint field contains a hint from the server about how
-   long the ticket should be stored.  The value indicates the lifetime
-   in seconds as a 32-bit unsigned integer in network byte order.  A
-   value of zero is reserved to indicate that the lifetime of the ticket
-   is unspecified.  A client SHOULD delete the ticket and associated
-   state when the time expires.  It MAY delete the ticket earlier based
-   on local policy.  A server MAY treat a ticket as valid for a shorter
-   or longer period of time than what is stated in the
-   ticket_lifetime_hint.
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case session_ticket:      NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          uint32 ticket_lifetime_hint;
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 8]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-3.4.  Interaction with TLS Session ID
-
-   If a server is planning on issuing a SessionTicket to a client that
-   does not present one, it SHOULD include an empty Session ID in the
-   ServerHello.  If the server includes a non-empty session ID, then it
-   is indicating intent to use stateful session resume.  If the client
-   receives a SessionTicket from the server, then it discards any
-   Session ID that was sent in the ServerHello.
-
-   When presenting a ticket, the client MAY generate and include a
-   Session ID in the TLS ClientHello.  If the server accepts the ticket
-   and the Session ID is not empty, then it MUST respond with the same
-   Session ID present in the ClientHello.  This allows the client to
-   easily differentiate when the server is resuming a session from when
-   it is falling back to a full handshake.  Since the client generates a
-   Session ID, the server MUST NOT rely upon the Session ID having a
-   particular value when validating the ticket.  If a ticket is
-   presented by the client, the server MUST NOT attempt to use the
-   Session ID in the ClientHello for stateful session resume.
-   Alternatively, the client MAY include an empty Session ID in the
-   ClientHello.  In this case, the client ignores the Session ID sent in
-   the ServerHello and determines if the server is resuming a session by
-   the subsequent handshake messages.
-
-
-4.  Recommended Ticket Construction
-
-   This section describes a recommended format and protection for the
-   ticket.  Note that the ticket is opaque to the client, so the
-   structure is not subject to interoperability concerns, and
-   implementations may diverge from this format.  If implementations do
-   diverge from this format, they must take security concerns seriously.
-   Clients MUST NOT examine the ticket under the assumption that it
-   complies with this document.
-
-   The server uses two different keys: one 128-bit key for AES [AES] in
-   CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
-   [SHA1].
-
-   The ticket is structured as follows:
-
-      struct {
-          opaque key_name[16];
-          opaque iv[16];
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } ticket;
-
-
-
-
-Salowey, et al.         Expires December 13, 2007               [Page 9]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   Here, key_name serves to identify a particular set of keys used to
-   protect the ticket.  It enables the server to easily recognize
-   tickets it has issued.  The key_name should be randomly generated to
-   avoid collisions between servers.  One possibility is to generate new
-   random keys and key_name every time the server is started.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_name (16 octets)and IV (16 octets), followed
-   by the length of the encrypted_state field (2 octets) and its
-   contents (variable length).
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ClientIdentity client_identity;
-          uint32 timestamp;
-      } StatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ClientAuthenticationType;
-
-      struct {
-          ClientAuthenticationType client_authentication_type;
-          select (ClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>;   /* from [RFC4279] */
-
-          }
-       } ClientIdentity;
-
-   The structure StatePlaintext stores the TLS session state including
-   the master_secret.  The timestamp within this structure allows the
-   TLS server to expire tickets.  To cover the authentication and key
-   exchange protocols provided by TLS, the ClientIdentity structure
-   contains the authentication type of the client used in the initial
-   exchange (see ClientAuthenticationType).  To offer the TLS server
-   with the same capabilities for authentication and authorization, a
-   certificate list is included in case of public-key-based
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 10]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   authentication.  The TLS server is therefore able to inspect a number
-   of different attributes within these certificates.  A specific
-   implementation might choose to store a subset of this information or
-   additional information.  Other authentication mechanisms, such as
-   Kerberos [RFC2712], would require different client identity data.
-
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be authenticated and encrypted to prevent
-   modification or eavesdropping by an attacker.  Several attacks
-   described below will be possible if this is not carefully done.
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of service as
-   described below.
-
-5.1.  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used, the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure that an attacker cannot invalidate a chosen
-   session.
-
-5.2.  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server;
-   however, since the ticket is encrypted and the attacker does not know
-   the secret key, a stolen ticket does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the ticket's contents.
-
-5.3.  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user, or
-   to gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 11]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   such as a keyed HMAC-SHA1.
-
-5.4.  Denial of Service Attacks
-
-   The key_name field defined in the recommended ticket format helps the
-   server efficiently reject tickets that it did not issue.  However, an
-   adversary could store or generate a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service, the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-5.5.  Ticket Protection Key Management
-
-   A full description of the management of the keys used to protect the
-   ticket is beyond the scope of this document.  A list of RECOMMENDED
-   practices is given below.
-
-   o  The keys should be generated securely following the randomness
-      recommendations in [RFC4086].
-   o  The keys and cryptographic protection algorithms should be at
-      least 128 bits in strength.
-   o  The keys should not be used for any other purpose than generating
-      and verifying tickets.
-   o  The keys should be changed regularly.
-   o  The keys should be changed if the ticket format or cryptographic
-      protection algorithms change.
-
-5.6.  Ticket Lifetime
-
-   The TLS server controls the lifetime of the ticket.  Servers
-   determine the acceptable lifetime based on the operational and
-   security requirements of the environments in which they are deployed.
-   The ticket lifetime may be longer than the 24-hour lifetime
-   recommended in [RFC2246].  TLS clients may be given a hint of the
-   lifetime of the ticket.  Since the lifetime of a ticket may be
-   unspecified, a client has its own local policy that determines when
-   it discards tickets.
-
-5.7.  Alternate Ticket Formats and Distribution Schemes
-
-   If the ticket format or distribution scheme defined in this document
-   is not used, then great care must be taken in analyzing the security
-   of the solution.  In particular, if confidential information, such as
-   a secret key, is transferred to the client, it MUST be done using
-   secure communication so as to prevent attackers from obtaining or
-   modifying the key.  Also, the ticket MUST have its integrity and
-   confidentiality protected with strong cryptographic techniques to
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 12]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   prevent a breach in the security of the system.
-
-5.8.  Identity Privacy, Anonymity, and Unlinkability
-
-   This document mandates that the content of the ticket is
-   confidentiality protected in order to avoid leakage of its content,
-   such as user-relevant information.  As such, it prevents disclosure
-   of potentially sensitive information carried within the ticket.
-
-   The initial handshake exchange, which was used to obtain the ticket,
-   might not provide identity confidentiality of the client based on the
-   properties of TLS.  Another relevant security threat is the ability
-   for an on-path adversary to observe multiple TLS handshakes where the
-   same ticket is used and therefore to conclude that they belong to the
-   same communication endpoints.  Application designers that use the
-   ticket mechanism described in this document should consider that
-   unlinkability [ANON] is not necessarily provided.
-
-   While a full discussion of these topics is beyond the scope of this
-   document, it should be noted that it is possible to issue a ticket
-   using a TLS renegotiation handshake that occurs after a secure tunnel
-   has been established by a previous handshake.  This may help address
-   some privacy and unlinkability issues in some environments.
-
-
-6.  Acknowledgements
-
-   The authors would like to thank the following people for their help
-   with preparing and reviewing this document: Eric Rescorla, Mohamad
-   Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
-   Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of
-   the TLS working group.
-
-   [CSSC] describes a solution that is very similar to the one described
-   in this document and gives a detailed analysis of the security
-   considerations involved.  [RFC2712] describes a mechanism for using
-   Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
-   of tickets to avoid server state.  [RFC4851] makes use of a similar
-   mechanism to avoid maintaining server state for the cryptographic
-   tunnel.  [SC97] also investigates the concept of stateless sessions.
-
-   The authors would also like to thank Jan Nordqvist who found the
-   encoding error in RFC 4507 corrected by this document.
-
-
-7.  IANA Considerations
-
-   IANA has assigned a TLS extension number of 35 to the SessionTicket
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 13]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   TLS extension from the TLS registry of ExtensionType values defined
-   in [RFC4366].
-
-   IANA has assigned a TLS HandshakeType number 4 to the
-   NewSessionTicket handshake type from the TLS registry of
-   HandshakeType values defined in [RFC4346].
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC4507]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
-              "Transport Layer Security (TLS) Session Resumption without
-              Server-Side State", RFC 4507, May 2006.
-
-8.2.  Informative References
-
-   [AES]      National Institute of Standards and Technology, "Advanced
-              Encryption Standard (AES)", Federal Information
-              Processing Standards (FIPS) Publication 197,
-              November 2001.
-
-   [ANON]     Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
-              Unobservability, Pseudonymity, and Identity Management - A
-              Consolidated Proposal for Terminology", http://
-              dud.inf.tu-dresden.de/literatur/
-              Anon_Terminology_v0.26-1.pdf Draft 0.26, December 2005.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", NIST Special Publication 800-38A,
-              December 2001.
-
-   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 14]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-              caching for TLS", Transactions on Information and
-              System Security (TISSEC) , Volume 7, Issue 4,
-              November 2004.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [RFC4851]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
-              Flexible Authentication via Secure Tunneling Extensible
-              Authentication Protocol Method (EAP-FAST)", RFC 4851,
-              May 2007.
-
-   [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-   [SHA1]     National Institute of Standards and Technology, "Secure
-              Hash Standard (SHS)", Federal Information Processing
-              Standards    (FIPS) Publication  180-2, August 2002.
-
-
-Appendix A.  Discussion of Changes to RFC4507
-
-   RFC 4507 [RFC4507] defines a mechanism to resume a TLS session
-   without maintaining server side state by specifying an encrypted
-   ticket that is maintained on the client.  The client presents this
-   ticket to the server in a SessionTicket hello extension.  The
-   encoding in RFC 4507 used the XDR style encoding specified in TLS
-   [RFC4346].
-
-   An error in the encoding caused the specification to differ from
-   deployed implementations.  At the time of this writing there are no
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 15]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-   known implementations that follow the encoding specified in RFC 4507.
-   This update to RFC 4507 aligns the document with this currently
-   deployed implementations.
-
-   Erroneous encoding in RFC 4507 resulted in two length fields; one for
-   the extension contents and one for the ticket itself.  Hence, for a
-   ticket that is 256 bytes long and begins with the hex value FF FF the
-   encoding of the extension would be as follows according to RFC 4507:
-
-
-        00 23          Ticket Extension type 35
-        01 02          Length of extension contents
-        01 00          Length of ticket
-        FF FF .. ..    Actual ticket
-
-   The update proposed in this document reflects what implementations
-   actually encode, namely it removes the redundant length field.  So,
-   for a ticket that is 256 bytes long and begins with the hex value FF
-   FF the encoding of the extension would be as follows according to
-   this update:
-
-
-        00 23          SessionTicket Extension type 35
-        01 00          Length of extension contents (ticket)
-        FF FF .. ..    Actual ticket
-
-   A server implemented according to RFC 4507 receiving a ticket
-   extension from an client conforming to this document would interpret
-   the first two bytes of the ticket as the length of this ticket.  This
-   will result in either an inconsistent length field or in the
-   processing of a ticket missing the first two bytes.  In the first
-   case the server should reject the request based on a malformed length
-   and in the second case the server should reject the ticket based on a
-   malformed ticket, incorrect key version or failed decryption.  A
-   server implementation based on this update receiving an RFC 4507
-   extension would interpret the first length field as the length of the
-   ticket and include the second two length bytes as the first bytes in
-   the ticket resulting in the ticket being rejected based on a
-   malformed ticket, incorrect key version or failed decryption.
-
-   A server implementation can construct tickets such that it can detect
-   an RFC 4507 implementation, if one existed, by including a cookie at
-   the beginning of the tickets that can be differentiated from a valid
-   length.  For example, if an implementation constructed tickets to
-   start with the hex values FF FF then it could determine where the
-   ticket begins and determine the length correctly from the type of
-   length fields present.
-
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 16]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   Email: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   Email: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Nokia Siemens Networks
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 17]
-
-Internet-Draft      Stateless TLS Session Resumption           June 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Salowey, et al.         Expires December 13, 2007              [Page 18]
-
diff --git a/doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt b/doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt
deleted file mode 100644
index 7acd83e1d6..0000000000
--- a/doc/protocol/draft-salowey-tls-rsa-aes-gcm-00.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-TLS Working Group                                             J. Salowey
-Internet-Draft                                              A. Choudhury
-Intended status: Standards Track                               D. McGrew
-Expires: August 29, 2007                             Cisco Systems, Inc.
-                                                       February 25, 2007
-
-
-                RSA based AES-GCM Cipher Suites for TLS
-                    draft-salowey-tls-rsa-aes-gcm-00
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 29, 2007.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This memo describes the use of the Advanced Encryption Standard (AES)
-   in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
-   authenticated encryption operation.  GCM provides both
-   confidentiality and data origin authentication, can be efficiently
-   implemented in hardware for speeds of 10 gigabits per second and
-   above, and is also well-suited to software implementations.  This
-   memo defines TLS ciphersuites that use AES-GCM with RSA.
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 1]
-
-Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
-   2.  Conventions Used In This Document . . . . . . . . . . . . . . . 3
-
-   3.  RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3
-
-   4.  TLS Versions  . . . . . . . . . . . . . . . . . . . . . . . . . 4
-
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-     6.1.  Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 5
-     6.2.  Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5
-
-   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
-
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
-
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 2]
-
-Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
-
-
-1.  Introduction
-
-   This document describes the use of AES [AES]in Galois Counter Mode
-   (GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite
-   for TLS.  This mechanism is not only efficient and secure, hardware
-   implementations can achieve high speeds with low cost and low
-   latency, because the mode can be pipelined.  Applications like
-   CAPWAP, which uses DTLS, can benefit from the high-speed
-   implementations when wireless termination points (WTPs) and
-   controllers (ACs) have to meet requirements to support higher
-   throughputs in the future.  AES-GCM has been specified as a mode that
-   can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security
-   [IEEE8021AE].  It also is part of the NSA suite B ciphersuites for
-   TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B
-   requirements these ciphersuites require ECC base key exchange and TLS
-   1.2.  The ciphersuites defined in this document are based on RSA
-   which allows the use of AES-GCM in environments that have not
-   deployed ECC algorithms and do not need to meet NSA Suite B
-   requirements.  AES-GCM is an authenticated encryption with associated
-   data (AEAD) operation, as used in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
-   The ciphersuites defined in this draft may be used with DTLS defined
-   in [RFC4347] and [I-D.ietf-tls-ctr].  This memo uses GCM in a way
-   similar to [I-D.rescorla-tls-suiteb].
-
-
-2.  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 [RFC2119]
-
-
-3.  RSA Based AES-GCM Cipher Suites
-
-   The ciphersuites defined in this document are based on the the AES-
-   GCM authenticated encryption with associated data (AEAD) algorithms
-   AEAD_AES_128_GCM and AEAD_AES_256_GCM described in
-   [I-D.mcgrew-auth-enc].  Note that this specification uses a 128-bit
-   authentication tag with GCM.  The following ciphersuites are defined:
-
-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
-      CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
-      CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
-
-   These ciphersuites make use of the AEAD capability in TLS 1.2
-   [I-D.ietf-tls-rfc4346-bis].  The "nonce" SHALL be 12 bytes long and
-   constructed from a salt and a counter as follows:
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 3]
-
-Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
-
-
-             Struct{
-                uint32 salt;
-                uint64 counter;
-             } GCMNonce
-
-   The salt is derived form the TLS key block as follows:
-
-            struct {
-               case client:
-                  uint32 client_write_IV;  // low order 32-bits
-               case server:
-                  uint32 server_write_IV;  // low order 32-bits
-            } salt
-
-
-   In the case of TLS the counter is the 64 bit sequence number.  In the
-   case of DTLS the counter is formed from the concatenation of the 16-
-   bit epoch with the 48-bit sequence number.
-
-   The RSA and RSA-DHE key exchange is performed as defined in
-   [I-D.ietf-tls-rfc4346-bis].
-
-   Recall that an AEAD operation replaces the use of HMAC as a MAC, but
-   not as a PRF for the purposes of key derivation.  Consequently, the
-   hash function for the TLS PRF must be explicitly specified by the
-   ciphersuite.  For TLS_RSA_WITH_AES_128_GCM_SHA256 and
-   TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256.  For
-   TLS_RSA_WITH_AES_256_GCM_SHA384 and
-   TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
-
-
-4.  TLS Versions
-
-   These ciphersuites make use of the authenticated encryption with
-   additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis].  They
-   MUST NOT be negotiated in older versions of TLS.  Clients MUST NOT
-   offer these cipher suites if they do not offer TLS 1.2 or later.
-   Servers which select an earlier version of TLS MUST NOT select one of
-   these cipher suites.  Because TLS has no way for the client to
-   indicate that it supports TLS 1.2 but not earlier, a non-compliant
-   server might potentially negotiate TLS 1.1 or earlier and select one
-   of the cipher suites in this document.  Clients MUST check the TLS
-   version and generate a fatal "illegal_parameter" alert if they detect
-   an incorrect version.
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 4]
-
-Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
-
-
-5.  IANA Considerations
-
-   IANA has assigned the following values for the ciphersuites defined
-   in this draft:
-
-      CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
-      CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
-      CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
-      CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
-
-
-6.  Security Considerations
-
-6.1.  Perfect Forward Secrecy
-
-   The perfect forward secrecy properties of RSA based TLS ciphersuites
-   are discussed in the security analysis of [RFC4346].  It should be
-   noted that only the ephemeral Diffie-Hellman based ciphersuites are
-   capable of providing perfect forward secrecy.
-
-6.2.  Counter Reuse
-
-   AES-GCM security requires that the counter is never reused.  The IV
-   construction in Section 3 is designed to prevent counter reuse.
-
-
-7.  Acknowledgements
-
-   This draft borrows heavily from [I-D.ietf-tls-ctr] and
-   [I-D.rescorla-tls-suiteb]
-
-
-8.  References
-
-8.1.  Normative References
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard
-              (AES)", FIPS 197, November 2001.
-
-   [GCM]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois Counter Mode (GCM) for Confidentiality and
-              Authentication", SP 800-38D, April 2006.
-
-   [I-D.ietf-tls-rfc4346-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.2", draft-ietf-tls-rfc4346-bis-02 (work in progress),
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 5]
-
-Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
-
-
-              October 2006.
-
-   [I-D.mcgrew-auth-enc]
-              McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", draft-mcgrew-auth-enc-01 (work in progress),
-              October 2006.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security", RFC 4347, April 2006.
-
-8.2.  Informative References
-
-   [I-D.ietf-tls-ctr]
-              Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
-              Suites for TLS and DTLS", draft-ietf-tls-ctr-01 (work in
-              progress), June 2006.
-
-   [I-D.rescorla-tls-suiteb]
-              Salter, M. and E. Rescorla, "SuiteB CipherSuites for TLS",
-              draft-rescorla-tls-suiteb-00 (work in progress),
-              December 2006.
-
-   [IEEE8021AE]
-              Institute of Electrical and Electronics Engineers, "Media
-              Access Control Security", IEEE Standard 802.1AE,
-              August 2006.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
-              (GCM) in IPsec Encapsulating Security Payload (ESP)",
-              RFC 4106, June 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 6]
-
-Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems, Inc.
-   2901 3rd. Ave
-   Seattle, WA  98121
-   USA
-
-   Email: jsalowey@cisco.com
-
-
-   Abhijit Choudhury
-   Cisco Systems, Inc.
-   170 W Tasman Drive
-   San Jose, CA  95134
-   USA
-
-   Email: abhijitc@cisco.com
-
-
-   David McGrew
-   Cisco Systems, Inc.
-   170 W Tasman Drive
-   San Jose, CA  95134
-   USA
-
-   Email: mcgrew@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 7]
-
-Internet-Draft          RSA AES-GCM Ciphersuites           February 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Salowey, et al.          Expires August 29, 2007                [Page 8]
-
diff --git a/doc/protocol/draft-salowey-tls-ticket-02.txt b/doc/protocol/draft-salowey-tls-ticket-02.txt
deleted file mode 100644
index b45b3d0bea..0000000000
--- a/doc/protocol/draft-salowey-tls-ticket-02.txt
+++ /dev/null
@@ -1,614 +0,0 @@
-
-TLS Working Group                                             J. Salowey
-Internet-Draft                                                   H. Zhou
-Expires: August 23, 2005                                   Cisco Systems
-                                                               P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                       February 19, 2005
-
-
-            TLS Session Resumption without Server-Side State
-                    draft-salowey-tls-ticket-02.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is subject to all provisions
-   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
-   author represents that any applicable patent or other IPR claims of
-   which he or she is aware have been or will be disclosed, and any of
-   which he or she become aware will be disclosed, in accordance with
-   RFC 3668.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as
-   Internet-Drafts.
-
-   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.
-
-   This Internet-Draft will expire on August 23, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a mechanism which enables the TLS server to
-   resume sessions and avoid keeping per-client session state.  The TLS
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 1]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-   server encapsulates the session state into a ticket and forwards it
-   to the client.  The client can subsequently resume a session using
-   the obtained ticket.  This mechanism makes use of new TLS handshake
-   messages and TLS hello extensions.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.2   Format of SessionTicket TLS extension  . . . . . . . . . .  5
-     3.3   Format of NewSessionTicket handshake message . . . . . . .  5
-   4.  Sample ticket construction . . . . . . . . . . . . . . . . . .  6
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  8
-     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  8
-     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  8
-     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
-   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
-   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     8.1   Normative References . . . . . . . . . . . . . . . . . . .  9
-     8.2   Informative References . . . . . . . . . . . . . . . . . .  9
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
-       Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 2]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-1.  Introduction
-
-   This document defines a way to resume a TLS session without requiring
-   session-specific state at the TLS server.  This mechanism may be used
-   with any TLS ciphersuite.  The mechanism makes use of TLS extensions
-   defined in [RFC3546] and defines a new TLS message type.
-
-   This mechanism is useful in the following types of situations
-      (1) servers that handle a large number of transactions from
-      different users
-      (2) servers that desire to cache sessions for a long time
-      (3) ability to load balance requests across servers
-      (4) embedded servers with little memory
-
-2.  Terminology
-
-   Within this document the term 'ticket' refers to a cryptographically
-   protected data structure which is created by the server and consumed
-   by the server to rebuild session specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-3.1  Overview
-
-   The client indicates that it supports this mechanism by including an
-   empty SessionTicket TLS extension in the ClientHello message.
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   TLS handshake message.  This message is sent during the TLS handshake
-   before the ChangeCipherSpec message after the server has verified the
-   client's Finished message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 3]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-         Client                                               Server
-
-         ClientHello                   -------->
-        (empty SessionTicket extension)
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   The client caches this ticket along with the master secret, session
-   ID and other parameters associated with the current session.  When
-   the client wishes to resume the session, it includes a SessionTicket
-   TLS extension in the SessionTicket extension within ClientHello
-   message.  The server then verifies that the ticket has not been
-   tampered with, decrypts the contents, and retrieves the session state
-   from the contents of the ticket and uses this state to resume the
-   session.  Since separate fields in the request are used for the
-   session ID and the ticket standard stateful session resume can
-   co-exist with the ticket based session resume described in this
-   specification.
-
-
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-   Since the ticket is typically interpreted by the same server or group
-   of servers that created it, the exact format of the ticket does not
-   need to be the same for all implementations.  A sample ticket format
-   is given in Section 4.  If the server cannot or does not want to
-   honor the ticket then it can initiate a full handshake with the
-   client.
-
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 4]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-   It is possible that the session ticket and master session key could
-   be delivered through some out of band mechanism.  This behavior is
-   beyond the scope of the document and would need to be described in a
-   separate specification.
-
-3.2  Format of SessionTicket TLS extension
-
-   The format of the ticket is an opaque structure used to carry session
-   specific state information.
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-
-3.3  Format of NewSessionTicket handshake message
-
-   This message is sent during the TLS handshake before the
-   ChangeCipherSpec message after the server has verified the client's
-   Finished message.
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case new_session_ticket:  NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-
-
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 5]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-4.  Sample ticket construction
-
-   This section describes one possibility how the ticket could be
-   constructed, other implementations are possible.
-
-   The server uses two keys, one 128-bit key for AES encryption and one
-   128-bit key for HMAC-SHA1.
-
-   The ticket is structured as follows:
-
-      struct {
-          uint32 key_version;
-          opaque iv[16]
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } ExampleTicket;
-
-   Here key_version identifies a particular set of keys.  One
-   possibility is to generate new random keys every time the server is
-   started, and use the timestamp as the key version.  The same
-   mechanisms known from a number of other protocols can be reused for
-   this purpose.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_version (4 octets) and IV (16 octets),
-   followed by the contents of the encrypted_state field (without the
-   length).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 6]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ClientIdentity client_identity;
-          uint32 timestamp;
-      } ExampleStatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1)
-     } ExampleClientAuthenticationType;
-
-      struct {
-          ExampleClientAuthenticationType client_authentication_type;
-          select (ExampleClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-          }
-       } ExampleClientIdentity;
-
-   The structure ExampleStatePlaintext stores the TLS session state
-   including the SessionID and the master_secret.  The timestamp within
-   this structure allows the TLS server to expire tickets.  To cover the
-   authentication and key exchange protocols provided by TLS the
-   ExampleClientIdentity structure contains the authentication type of
-   the client used in the initial exchange (see
-   ExampleClientAuthenticationType).  To offer the TLS server with the
-   same capabilities for authentication and authorization a certificate
-   list is included in case of public key based authentication.  The TLS
-   server is therefore able to inspect a number of different attributes
-   within these certificates.  A specific implementation might choose to
-   store a subset of this information.  Other authentication mechanism
-   such as Kerberos or pre-shared keys would require different client
-   identity data.
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be sufficiently authenticated and encrypted to
-   prevent modification or eavesdropping by an attacker.  Several
-   attacks described below will be possible if this is not carefully
-   done.
-
-   Implementations should take care to ensure that the processing of
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 7]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-   tickets does not increase the chance of denial of serve as described
-   below.
-
-5.1  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure an attacker cannot invalidate a chosen session.
-
-5.2  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server,
-   however since the ticket is encrypted and the attacker does not know
-   the secret key a stolen key does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the tickets contents.
-
-5.3  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user or
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC.
-
-5.4  Denial of Service Attacks
-
-   An adversary could store or forge a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-6.  Acknowledgments
-
-   The authors would like to thank the following people for their help
-   with this document: Eric Rescorla, Nancy Cam-Winget and David McGrew
-
-   [RFC2712] describes a mechanism for using Kerberos ([RFC1510]) in TLS
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 8]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-   ciphersuites, which helped inspire the use of tickets to avoid server
-   state.  [EAP-FAST] makes use of a similar mechanism to avoid
-   maintaining server state for the cryptographic tunnel.  [AURA97] also
-   investigates the concept of stateless sessions.  [CSSC] describes a
-   solution that is very similar to the one described in this document
-   and gives a detailed analysis of the security considerations
-   involved.
-
-7.  IANA considerations
-
-   Needs a TLS extension number (for including the ticket in client
-   hello), and HandshakeType number (for delivering the ticket to the
-   client).
-
-8.  References
-
-8.1  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", March 1997.
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 3546, June 2003.
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-8.2  Informative References
-
-   [AURA97]   Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-   [CSSC]     Shacham, H., Boneh, D. and E. Rescorla, "Client Side
-              Caching for TLS",
-              URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf,
-              2002.
-
-   [EAP-FAST]
-              Cam-Winget, N., McGrew, D., Salowey, J. and H. Zhou, "EAP
-              Flexible Authentication via Secure Tunneling (EAP-FAST)",
-              Internet-Draft work-in-progress, February 2004.
-
-   [RFC1510]  Kohl, J. and C. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510, September 1993.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-
-
-
-Salowey, et al.          Expires August 23, 2005                [Page 9]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   Email: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   Email: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires August 23, 2005               [Page 10]
-
-Internet-Draft      Stateless TLS Session Resumption       February 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Salowey, et al.          Expires August 23, 2005               [Page 11]
-
diff --git a/doc/protocol/draft-salowey-tls-ticket-03.txt b/doc/protocol/draft-salowey-tls-ticket-03.txt
deleted file mode 100644
index b7d694e3a1..0000000000
--- a/doc/protocol/draft-salowey-tls-ticket-03.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                                         J. Salowey
-Internet-Draft                                                   H. Zhou
-Expires: January 16, 2006                                  Cisco Systems
-                                                               P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                           July 15, 2005
-
-
- Transport Layer Security Session Resumption without Server-Side State
-                    draft-salowey-tls-ticket-03.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on January 16, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a mechanism which enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-   ticket and forwards it to the client.  The client can subsequently
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 1]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-   resume a session using the obtained ticket.  This mechanism makes use
-   of new TLS handshake messages and TLS hello extensions.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.2   Format of SessionTicket TLS extension  . . . . . . . . . .  5
-     3.3   Format of NewSessionTicket handshake message . . . . . . .  5
-   4.  Sample ticket construction . . . . . . . . . . . . . . . . . .  6
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  8
-     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  8
-     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  8
-     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
-     5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . .  9
-   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     8.1   Normative References . . . . . . . . . . . . . . . . . . .  9
-     8.2   Informative References . . . . . . . . . . . . . . . . . .  9
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
-       Intellectual Property and Copyright Statements . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 2]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) [RFC2246]session without requiring session-specific state at
-   the TLS server.  This mechanism may be used with any TLS ciphersuite.
-   The mechanism makes use of TLS extensions defined in [RFC3546] and
-   defines a new TLS message type.
-
-   This mechanism is useful in the following types of situations
-      (1) servers that handle a large number of transactions from
-      different users
-      (2) servers that desire to cache sessions for a long time
-      (3) ability to load balance requests across servers
-      (4) embedded servers with little memory
-
-2.  Terminology
-
-   Within this document the term 'ticket' refers to a cryptographically
-   protected data structure which is created by the server and consumed
-   by the server to rebuild session specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-3.1  Overview
-
-   The client indicates that it supports this mechanism by including an
-   empty SessionTicket TLS extension in the ClientHello message.
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   TLS handshake message.  This message is sent during the TLS handshake
-   before the ChangeCipherSpec message after the server has verified the
-   client's Finished message.
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 3]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-         Client                                               Server
-
-         ClientHello                   -------->
-        (empty SessionTicket extension)
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   The client caches this ticket along with the master secret, session
-   ID and other parameters associated with the current session.  When
-   the client wishes to resume the session, it includes a SessionTicket
-   TLS extension in the SessionTicket extension within ClientHello
-   message.  The server then verifies that the ticket has not been
-   tampered with, decrypts the contents, and retrieves the session state
-   from the contents of the ticket and uses this state to resume the
-   session.  Since separate fields in the request are used for the
-   session ID and the ticket standard stateful session resume can co-
-   exist with the ticket based session resume described in this
-   specification.
-
-
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-   Since the ticket is typically interpreted by the same server or group
-   of servers that created it, the exact format of the ticket does not
-   need to be the same for all implementations.  A sample ticket format
-   is given in Section 4.  If the server cannot or does not want to
-   honor the ticket then it can initiate a full handshake with the
-   client.
-
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 4]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-   It is possible that the session ticket and master session key could
-   be delivered through some out of band mechanism.  This behavior is
-   beyond the scope of the document and would need to be described in a
-   separate specification.
-
-3.2  Format of SessionTicket TLS extension
-
-   The format of the ticket is an opaque structure used to carry session
-   specific state information.
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-
-3.3  Format of NewSessionTicket handshake message
-
-   This message is sent during the TLS handshake before the
-   ChangeCipherSpec message after the server has verified the client's
-   Finished message.
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case new_session_ticket:  NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-
-
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 5]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-4.  Sample ticket construction
-
-   This section describes one possibility how the ticket could be
-   constructed, other implementations are possible.
-
-   The server uses two keys, one 128-bit key for AES encryption and one
-   128-bit key for HMAC-SHA1.
-
-   The ticket is structured as follows:
-
-      struct {
-          uint32 key_version;
-          opaque iv[16]
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } ExampleTicket;
-
-   Here key_version identifies a particular set of keys.  One
-   possibility is to generate new random keys every time the server is
-   started, and use the timestamp as the key version.  The same
-   mechanisms known from a number of other protocols can be reused for
-   this purpose.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_version (4 octets) and IV (16 octets),
-   followed by the contents of the encrypted_state field (without the
-   length).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 6]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ClientIdentity client_identity;
-          uint32 timestamp;
-      } ExampleStatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ExampleClientAuthenticationType;
-
-      struct {
-          ExampleClientAuthenticationType client_authentication_type;
-          select (ExampleClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>;
-
-          }
-       } ExampleClientIdentity;
-
-   The structure ExampleStatePlaintext stores the TLS session state
-   including the SessionID and the master_secret.  The timestamp within
-   this structure allows the TLS server to expire tickets.  To cover the
-   authentication and key exchange protocols provided by TLS the
-   ExampleClientIdentity structure contains the authentication type of
-   the client used in the initial exchange (see
-   ExampleClientAuthenticationType).  To offer the TLS server with the
-   same capabilities for authentication and authorization a certificate
-   list is included in case of public key based authentication.  The TLS
-   server is therefore able to inspect a number of different attributes
-   within these certificates.  A specific implementation might choose to
-   store a subset of this information.  Other authentication mechanism
-   such as Kerberos [RFC2712] or pre-shared keys [I-D.ietf-tls-psk]
-   would require different client identity data.
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be sufficiently authenticated and encrypted to
-   prevent modification or eavesdropping by an attacker.  Several
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 7]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-   attacks described below will be possible if this is not carefully
-   done.
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of serve as described
-   below.
-
-5.1  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure an attacker cannot invalidate a chosen session.
-
-5.2  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server,
-   however since the ticket is encrypted and the attacker does not know
-   the secret key a stolen key does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the tickets contents.
-
-5.3  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user or
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC.
-
-5.4  Denial of Service Attacks
-
-   An adversary could store or forge a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-
-
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 8]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-5.5  Ticket Protection Key Lifetime
-
-   The management of the keys used to protect the ticket is beyond the
-   scope of this document.  It is advisable to limit the lifetime of
-   these keys to ensure they are not overused.
-
-6.  Acknowledgments
-
-   The authors would like to thank the following people for their help
-   with this document: Eric Rescorla, Mohamad Badra, Nancy Cam-Winget
-   and David McGrew
-
-   [RFC2712] describes a mechanism for using Kerberos ([RFC1510]) in TLS
-   ciphersuites, which helped inspire the use of tickets to avoid server
-   state.  [I-D.cam-winget-eap-fast] makes use of a similar mechanism to
-   avoid maintaining server state for the cryptographic tunnel.
-   [AURA97] also investigates the concept of stateless sessions.  [CSSC]
-   describes a solution that is very similar to the one described in
-   this document and gives a detailed analysis of the security
-   considerations involved.
-
-7.  IANA considerations
-
-   Needs a TLS extension number (for including the ticket in client
-   hello), and HandshakeType number (for delivering the ticket to the
-   client).
-
-8.  References
-
-8.1  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 3546, June 2003.
-
-8.2  Informative References
-
-   [AURA97]   Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client Side
-
-
-
-Salowey, et al.         Expires January 16, 2006                [Page 9]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-              Caching for TLS",
-              URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf,
-              2002.
-
-   [I-D.cam-winget-eap-fast]
-              Salowey, J., "EAP Flexible Authentication via Secure
-              Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-02 (work
-              in progress), April 2005.
-
-   [I-D.ietf-tls-psk]
-              Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
-              (work in progress), June 2005.
-
-   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510, September 1993.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   Email: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   Email: hzhou@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires January 16, 2006               [Page 10]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires January 16, 2006               [Page 11]
-
-Internet-Draft      Stateless TLS Session Resumption           July 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Salowey, et al.         Expires January 16, 2006               [Page 12]
-
diff --git a/doc/protocol/draft-salowey-tls-ticket-04.txt b/doc/protocol/draft-salowey-tls-ticket-04.txt
deleted file mode 100644
index 21b9a5c549..0000000000
--- a/doc/protocol/draft-salowey-tls-ticket-04.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                                         J. Salowey
-Internet-Draft                                                   H. Zhou
-Expires: February 2, 2006                                  Cisco Systems
-                                                               P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                             August 2005
-
-
- Transport Layer Security Session Resumption without Server-Side State
-                    draft-salowey-tls-ticket-04.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on February 2, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a mechanism which enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-   ticket and forwards it to the client.  The client can subsequently
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 1]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-   resume a session using the obtained ticket.  This mechanism makes use
-   of new TLS handshake messages and TLS hello extensions.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.2   Format of SessionTicket TLS extension  . . . . . . . . . .  5
-     3.3   Format of NewSessionTicket handshake message . . . . . . .  5
-   4.  Sample ticket construction . . . . . . . . . . . . . . . . . .  6
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  8
-     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  8
-     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  8
-     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  8
-     5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . .  9
-   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     8.1   Normative References . . . . . . . . . . . . . . . . . . .  9
-     8.2   Informative References . . . . . . . . . . . . . . . . . . 10
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
-       Intellectual Property and Copyright Statements . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 2]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) [RFC2246] session without requiring session-specific state at
-   the TLS server.  This mechanism may be used with any TLS ciphersuite.
-   The mechanism makes use of TLS extensions defined in [I-D.ietf-tls-
-   rfc3546bis] and defines a new TLS message type.
-
-   This mechanism is useful in the following types of situations
-      (1) servers that handle a large number of transactions from
-      different users
-      (2) servers that desire to cache sessions for a long time
-      (3) ability to load balance requests across servers
-      (4) embedded servers with little memory
-
-2.  Terminology
-
-   Within this document the term 'ticket' refers to a cryptographically
-   protected data structure which is created by the server and consumed
-   by the server to rebuild session specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-3.1  Overview
-
-   The client indicates that it supports this mechanism by including a
-   SessionTicket TLS extension in the ClientHello message.  The
-   extension will be empty if the client does not already possess a
-   ticket for the server.
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   TLS handshake message.  This message is sent during the TLS handshake
-   before the ChangeCipherSpec message after the server has verified the
-   client's Finished message.
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 3]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-         Client                                               Server
-
-         ClientHello                   -------->
-        (empty SessionTicket extension)
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   The client caches this ticket along with the master secret, session
-   ID and other parameters associated with the current session.  When
-   the client wishes to resume the session, it includes a SessionTicket
-   TLS extension in the SessionTicket extension within ClientHello
-   message.  The server then verifies that the ticket has not been
-   tampered with, decrypts the contents, and retrieves the session state
-   from the contents of the ticket and uses this state to resume the
-   session.  Since separate fields in the request are used for the
-   session ID and the ticket standard stateful session resume can co-
-   exist with the ticket based session resume described in this
-   specification.
-
-
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-   Since the ticket is typically interpreted by the same server or group
-   of servers that created it, the exact format of the ticket does not
-   need to be the same for all implementations.  A sample ticket format
-   is given in Section 4.  If the server cannot or does not want to
-   honor the ticket then it can initiate a full handshake with the
-   client.
-
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 4]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-   It is possible that the session ticket and master session key could
-   be delivered through some out of band mechanism.  This behavior is
-   beyond the scope of the document and would need to be described in a
-   separate specification.
-
-3.2  Format of SessionTicket TLS extension
-
-   The format of the ticket is an opaque structure used to carry session
-   specific state information.
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-   The SessionTicket extension has been assigned the number TBD1.
-
-3.3  Format of NewSessionTicket handshake message
-
-   This message is sent during the TLS handshake before the
-   ChangeCipherSpec message after the server has verified the client's
-   Finished message.
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case new_session_ticket:  NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-   The NewSessionTicket handshake message has been assigned the number
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 5]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-   TBD2.
-
-4.  Sample ticket construction
-
-   This section describes one possibility how the ticket could be
-   constructed, other implementations are possible.
-
-   The server uses two keys, one 128-bit key for AES encryption and one
-   128-bit key for HMAC-SHA1.
-
-   The ticket is structured as follows:
-
-      struct {
-          uint32 key_version;
-          opaque iv[16]
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } ExampleTicket;
-
-   Here key_version identifies a particular set of keys.  One
-   possibility is to generate new random keys every time the server is
-   started, and use the timestamp as the key version.  The same
-   mechanisms known from a number of other protocols can be reused for
-   this purpose.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_version (4 octets) and IV (16 octets),
-   followed by the contents of the encrypted_state field (without the
-   length).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 6]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ExampleClientIdentity client_identity;
-          uint32 timestamp;
-      } ExampleStatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ExampleClientAuthenticationType;
-
-      struct {
-          ExampleClientAuthenticationType client_authentication_type;
-          select (ExampleClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>;
-
-          }
-       } ExampleClientIdentity;
-
-   The structure ExampleStatePlaintext stores the TLS session state
-   including the SessionID and the master_secret.  The timestamp within
-   this structure allows the TLS server to expire tickets.  To cover the
-   authentication and key exchange protocols provided by TLS the
-   ExampleClientIdentity structure contains the authentication type of
-   the client used in the initial exchange (see
-   ExampleClientAuthenticationType).  To offer the TLS server with the
-   same capabilities for authentication and authorization a certificate
-   list is included in case of public key based authentication.  The TLS
-   server is therefore able to inspect a number of different attributes
-   within these certificates.  A specific implementation might choose to
-   store a subset of this information.  Other authentication mechanism
-   such as Kerberos [RFC2712] or pre-shared keys [I-D.ietf-tls-psk]
-   would require different client identity data.
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be sufficiently authenticated and encrypted to
-   prevent modification or eavesdropping by an attacker.  Several
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 7]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-   attacks described below will be possible if this is not carefully
-   done.
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of serve as described
-   below.
-
-5.1  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure an attacker cannot invalidate a chosen session.
-
-5.2  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server,
-   however since the ticket is encrypted and the attacker does not know
-   the secret key a stolen key does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the tickets contents.
-
-5.3  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user or
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC.
-
-5.4  Denial of Service Attacks
-
-   An adversary could store or forge a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-
-
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 8]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-5.5  Ticket Protection Key Lifetime
-
-   The management of the keys used to protect the ticket is beyond the
-   scope of this document.  It is advisable to limit the lifetime of
-   these keys to ensure they are not overused.
-
-6.  Acknowledgments
-
-   The authors would like to thank the following people for their help
-   with this document: Eric Rescorla, Mohamad Badra, Nancy Cam-Winget
-   and David McGrew.
-
-   [RFC2712] describes a mechanism for using Kerberos ([RFC1510]) in TLS
-   ciphersuites, which helped inspire the use of tickets to avoid server
-   state.  [I-D.cam-winget-eap-fast] makes use of a similar mechanism to
-   avoid maintaining server state for the cryptographic tunnel.
-   [AURA97] also investigates the concept of stateless sessions.  [CSSC]
-   describes a solution that is very similar to the one described in
-   this document and gives a detailed analysis of the security
-   considerations involved.
-
-7.  IANA considerations
-
-   IANA has assigned a TLS extension number of TBD1 (the value 35 is
-   suggested) to the SessionTicket TLS extension from the TLS registry
-   of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
-
-   IANA has assigned a TLS HandshakeType number TBD2 to the
-   NewSessionTicket handshake type from the TLS registry of
-   HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis].
-
-8.  References
-
-8.1  Normative References
-
-   [I-D.ietf-tls-rfc2246-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
-              June 2005.
-
-   [I-D.ietf-tls-rfc3546bis]
-              Blake-Wilson, S., "Transport Layer Security (TLS)
-              Extensions", draft-ietf-tls-rfc3546bis-01 (work in
-              progress), May 2005.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-Salowey, et al.         Expires February 2, 2006                [Page 9]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-8.2  Informative References
-
-   [AURA97]   Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client Side
-              Caching for TLS",
-              URI http://crypto.stanford.edu/~dabo/papers/fasttrack.pdf.
-
-   [I-D.cam-winget-eap-fast]
-              Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
-              Flexible Authentication via Secure Tunneling (EAP-FAST)",
-              draft-cam-winget-eap-fast-02 (work in progress),
-              April 2005.
-
-   [I-D.ietf-tls-psk]
-              Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
-              (work in progress), June 2005.
-
-   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510, September 1993.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   Email: jsalowey@cisco.com
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires February 2, 2006               [Page 10]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   Email: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.         Expires February 2, 2006               [Page 11]
-
-Internet-Draft      Stateless TLS Session Resumption         August 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Salowey, et al.         Expires February 2, 2006               [Page 12]
-
diff --git a/doc/protocol/draft-salowey-tls-ticket-05.txt b/doc/protocol/draft-salowey-tls-ticket-05.txt
deleted file mode 100644
index 8e1c2d9d4d..0000000000
--- a/doc/protocol/draft-salowey-tls-ticket-05.txt
+++ /dev/null
@@ -1,728 +0,0 @@
-
-
-
-Network Working Group                                         J. Salowey
-Internet-Draft                                                   H. Zhou
-Expires: April 21, 2006                                    Cisco Systems
-                                                               P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                        October 18, 2005
-
-
- Transport Layer Security Session Resumption without Server-Side State
-                    draft-salowey-tls-ticket-05.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on April 21, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a mechanism which enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-   ticket and forwards it to the client.  The client can subsequently
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 1]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-   resume a session using the obtained ticket.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.2   SessionTicket TLS extension  . . . . . . . . . . . . . . .  5
-     3.3   SessionTicket handshake message  . . . . . . . . . . . . .  5
-     3.4   Interaction with TLS session ID  . . . . . . . . . . . . .  6
-   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . .  7
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . .  9
-     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . .  9
-     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . .  9
-     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . .  9
-     5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . .  9
-     5.6   Alternate Ticket Formats and Distribution Schemes  . . . . 10
-   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     8.1   Normative References . . . . . . . . . . . . . . . . . . . 10
-     8.2   Informative References . . . . . . . . . . . . . . . . . . 11
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
-       Intellectual Property and Copyright Statements . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 2]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) [RFC2246] session without requiring session-specific state at
-   the TLS server.  This mechanism may be used with any TLS ciphersuite.
-   The mechanism makes use of TLS extensions defined in [I-D.ietf-tls-
-   rfc3546bis] and defines a new TLS message type.
-
-   This mechanism is useful in the following types of situations
-      (1) servers that handle a large number of transactions from
-      different users
-      (2) servers that desire to cache sessions for a long time
-      (3) ability to load balance requests across servers
-      (4) embedded servers with little memory
-
-2.  Terminology
-
-   Within this document the term 'ticket' refers to a cryptographically
-   protected data structure which is created by the server and consumed
-   by the server to rebuild session specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-   This specification describes a mechanism to distribute encrypted
-   session state information in a ticket from a TLS server to a TLS
-   client and for a TLS client to present a ticket to a TLS server to
-   resume a session.  Implementations of this specification are expected
-   to support both mechanism.  Other specifications can take advantage
-   of the session tickets, perhaps specifying alternative means for
-   distribution or selection.  For example a separate specification may
-   describe an alternate way to distribute a ticket and use the TLS
-   extension in this document to resume the session.  This behavior is
-   beyond the scope of the document and would need to be described in a
-   separate specification.
-
-3.1  Overview
-
-   The client indicates that it supports this mechanism by including a
-   SessionTicket TLS extension in the ClientHello message.  The
-   extension will be empty if the client does not already possess a
-   ticket for the server.  The extension is described in Section 3.2
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 3]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the SessionTicket TLS
-   handshake message described in Section 3.3.  This message is sent
-   during the TLS handshake before the ChangeCipherSpec message after
-   the server has successfully verified the client's Finished message.
-
-
-         Client                                               Server
-
-         ClientHello                   -------->
-        (empty SessionTicket extension)
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                       SessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   The client caches this ticket along with the master secret and other
-   parameters associated with the current session.  When the client
-   wishes to resume the session, it includes the ticket in the
-   SessionTicket extension within ClientHello message.  The server then
-   verifies that the ticket has not been tampered with, decrypts the
-   contents, retrieves the session state from the contents of the ticket
-   and uses this state to resume the session.  The interaction with the
-   TLS Session ID is described in Section 3.4.  If the server
-   successfully verifies the client's ticket then it may renew the
-   ticket by including a SessionTicket handshake message after the
-   ServerHello.
-
-
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                                        SessionTicket
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 4]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-   A recommended ticket format is given in Section 4.  If the server
-   cannot or does not want to honor the ticket then it can initiate a
-   full handshake with the client.
-
-3.2  SessionTicket TLS extension
-
-   The SessionTicket TLS extension is based on [I-D.ietf-tls-
-   rfc3546bis].  The format of the ticket is an opaque structure used to
-   carry session specific state information.  This extension is sent in
-   the ClientHello.  If the client posses a ticket that it wants to use
-   to resume a session then it includes it in the SessionTicket
-   extension in the ClientHello.  If the client does not have a ticket
-   and it is prepared to receive one in the SessionTicket handshake
-   message then it MUST include a zero length ticket in the
-   SessionTicket extension.  If the client is not prepared to receive a
-   ticket in the SessionTicket handshake message then it MUST NOT
-   include a zero length SessionTicket extension.
-
-   If the server fails to verify the ticket then it falls back to
-   performing a full handshake.  If the ticket is accepted by the server
-   but the handshake fails the client SHOULD delete the ticket.
-
-   The SessionTicket extension has been assigned the number TBD1.  The
-   format of the SessionTicket extension is given below.
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-
-3.3  SessionTicket handshake message
-
-   This message is sent during the TLS handshake before the
-   ChangeCipherSpec message.  This message MUST only be sent if either
-   the client included a SessionTicket extension with a zero length
-   ticket in the ClientHello or if the client included a ticket that was
-   previously issued in a SessionTicket handshake message.  In the case
-   of a full handshake, the server MUST verify the client's Finished
-   message before sending the ticket.  The client MUST NOT treat the
-   ticket as valid until it has verified the server's Finished message.
-
-   If the server successfully verifies the client's ticket then it MAY
-   renew the ticket by including a SessionTicket handshake message after
-   the ServerHello in the abbreviated handshake.  The client should
-   start using the new ticket as soon as possible after it verifies the
-   Server's finished message for new connections.  Note that since the
-   updated ticket is issued before the handshake completes it is
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 5]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-   possible that the client may not put the new ticket into use before
-   it initiates new connections.  The server MUST NOT assume the client
-   actually received the updated ticket until it successfully verifies
-   the client's finished message.
-
-   The SessionTicket handshake message has been assigned the number
-   TBD2.  The definition of the SessionTicket handshake message is given
-   below.
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case new_session_ticket:  SessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-
-3.4  Interaction with TLS session ID
-
-   If a server is planning on issuing a SessionTicket to a client that
-   does not present one it SHOULD include an empty Session ID in the
-   ServerHello.  If the server includes a non-empty session ID then it
-   is indicating intent to use stateful session resume.  If the client
-   receives a SessionTicket from the server then it discards any Session
-   ID that was sent in the ServerHello.
-
-   When presenting a ticket the client MAY generate and include a
-   Session ID in the TLS ClientHello.  If the server accepts the ticket
-   and the Session ID is not empty then it MUST respond with the same
-   Session ID present in the ClientHello.  This allows the client to
-   easily differentiate when the server is resuming a session or falling
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 6]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-   back to a full handshake.  Since the client generates a Session ID
-   the server MUST NOT rely upon the Session ID having a particular
-   value when validating the ticket.  If a ticket is presented by the
-   client the server MUST NOT attempt to use the Session ID in the
-   ClientHello for stateful session resume.  Alternatively, the client
-   MAY include an empty Session ID in the ClientHello.  In this case the
-   client ignores the Session ID sent in the ServerHello and must
-   determine if the server is resuming a session by the subsequent
-   handshake messages.
-
-4.  Recommended Ticket Construction
-
-   This section describes a recommended format and protection for the
-   ticket.  Note that the ticket is opaque to the client so the
-   structure is not subject to interoperability concerns, so
-   implementations may diverge from this format.  If implementations do
-   diverge from this format they must take security concerns seriously.
-   Clients MUST NOT examine the ticket under the assumption that it
-   complies with this document.
-
-   The server uses two different keys, one 128-bit key for AES
-   encryption and one 128-bit key for HMAC-SHA1.
-
-   The ticket is structured as follows:
-
-      struct {
-          uint32 key_version;
-          opaque iv[16]
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } Ticket;
-
-   Here key_version identifies a particular set of keys.  One
-   possibility is to generate new random keys every time the server is
-   started, and use the timestamp as the key version.  The same
-   mechanisms known from a number of other protocols can be reused for
-   this purpose.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_version (4 octets)and IV (16 octets),
-   followed by the length of the encrypted_state field (2 octets) and
-   its contents (variable length).
-
-
-
-
-
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 7]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ExampleClientIdentity client_identity;
-          uint32 timestamp;
-      } StatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ClientAuthenticationType;
-
-      struct {
-          ClientAuthenticationType client_authentication_type;
-          select (ClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>;
-
-          }
-       } ClientIdentity;
-
-   The structure StatePlaintext stores the TLS session state including
-   the master_secret.  The timestamp within this structure allows the
-   TLS server to expire tickets.  To cover the authentication and key
-   exchange protocols provided by TLS the ClientIdentity structure
-   contains the authentication type of the client used in the initial
-   exchange (see ClientAuthenticationType).  To offer the TLS server
-   with the same capabilities for authentication and authorization a
-   certificate list is included in case of public key based
-   authentication.  The TLS server is therefore able to inspect a number
-   of different attributes within these certificates.  A specific
-   implementation might choose to store a subset of this information or
-   additional information.  Other authentication mechanism such as
-   Kerberos [RFC2712] would require different client identity data.
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be sufficiently authenticated and encrypted to
-   prevent modification or eavesdropping by an attacker.  Several
-   attacks described below will be possible if this is not carefully
-   done.
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 8]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of serve as described
-   below.
-
-5.1  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure an attacker cannot invalidate a chosen session.
-
-5.2  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server,
-   however since the ticket is encrypted and the attacker does not know
-   the secret key a stolen key does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the tickets contents.
-
-5.3  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user or
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC.
-
-5.4  Denial of Service Attacks
-
-   An adversary could store or forge a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-5.5  Ticket Protection Key Lifetime
-
-   The management of the keys used to protect the ticket is beyond the
-   scope of this document.  It is advisable to limit the lifetime of
-   these keys to ensure they are not overused.
-
-
-
-Salowey, et al.          Expires April 21, 2006                 [Page 9]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-5.6  Alternate Ticket Formats and Distribution Schemes
-
-   If a different ticket format or distribution scheme than the ones
-   defined in this document is used then great care must be taken in
-   analyzing the security of the solution.  In particular if a secret is
-   transferred to the client it MUST be done using secure communication
-   so as to prevent attackers from obtaining or modifying the key.  Also
-   the ticket MUST have its integrity and privacy protected with strong
-   cryptographic techniques to prevent a breach in the security of the
-   system.
-
-6.  Acknowledgments
-
-   The authors would like to thank the following people for their help
-   with preparing and reviewing this document: Eric Rescorla, Mohamad
-   Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
-   Rob Dugal and members of the TLS working group.
-
-   [CSSC] describes a solution that is very similar to the one described
-   in this document and gives a detailed analysis of the security
-   considerations involved.  [RFC2712] describes a mechanism for using
-   Kerberos ([RFC1510]) in TLS ciphersuites, which helped inspire the
-   use of tickets to avoid server state.  [I-D.cam-winget-eap-fast]
-   makes use of a similar mechanism to avoid maintaining server state
-   for the cryptographic tunnel.  [SC97] also investigates the concept
-   of stateless sessions.
-
-7.  IANA considerations
-
-   IANA has assigned a TLS extension number of TBD1 (the value 35 is
-   suggested) to the SessionTicket TLS extension from the TLS registry
-   of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
-
-   IANA has assigned a TLS HandshakeType number TBD2 to the
-   SessionTicket handshake type from the TLS registry of HandshakeType
-   values defined in [I-D.ietf-tls-rfc2246-bis].
-
-8.  References
-
-8.1  Normative References
-
-   [AES]      National Institute of Standards and Technology, "Advanced
-              Encryption Standard (AES)", Federal Information
-              Processing Standards (FIPS) Publication 197,
-              November 2001.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-
-
-
-Salowey, et al.          Expires April 21, 2006                [Page 10]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-              Methods and Techniques", NIST Special Publication 800-38A,
-              December 2001.
-
-   [I-D.ietf-tls-rfc2246-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
-              June 2005.
-
-   [I-D.ietf-tls-rfc3546bis]
-              Blake-Wilson, S., "Transport Layer Security (TLS)
-              Extensions", draft-ietf-tls-rfc3546bis-02 (work in
-              progress), October 2005.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [SHA1]     National Institute of Standards and Technology, "Secure
-              Hash Standard (SHS)", Federal Information Processing
-              Standards    (FIPS) Publication  180-2, August 2002.
-
-8.2  Informative References
-
-   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
-              caching for TLS", Transactions on Information and
-              System Security (TISSEC) , Volume 7, Issue 4,
-              November 2004.
-
-   [I-D.cam-winget-eap-fast]
-              Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
-              Flexible Authentication via Secure Tunneling (EAP-FAST)",
-              draft-cam-winget-eap-fast-02 (work in progress),
-              April 2005.
-
-   [I-D.ietf-tls-psk]
-              Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", draft-ietf-tls-psk-09
-              (work in progress), June 2005.
-
-   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
-              Authentication Service (V5)", RFC 1510, September 1993.
-
-
-
-
-Salowey, et al.          Expires April 21, 2006                [Page 11]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   Email: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   Email: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-Salowey, et al.          Expires April 21, 2006                [Page 12]
-
-Internet-Draft      Stateless TLS Session Resumption        October 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Salowey, et al.          Expires April 21, 2006                [Page 13]
-
diff --git a/doc/protocol/draft-salowey-tls-ticket-06.txt b/doc/protocol/draft-salowey-tls-ticket-06.txt
deleted file mode 100644
index 7a142cc559..0000000000
--- a/doc/protocol/draft-salowey-tls-ticket-06.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-Network Working Group                                         J. Salowey
-Internet-Draft                                                   H. Zhou
-Expires: June 18, 2006                                     Cisco Systems
-                                                               P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                       December 15, 2005
-
-
- Transport Layer Security Session Resumption without Server-Side State
-                    draft-salowey-tls-ticket-06.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on June 18, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a mechanism which enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-   ticket and forwards it to the client.  The client can subsequently
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 1]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-   resume a session using the obtained ticket.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.2   SessionTicket TLS extension  . . . . . . . . . . . . . . .  5
-     3.3   SessionTicket handshake message  . . . . . . . . . . . . .  6
-     3.4   Interaction with TLS session ID  . . . . . . . . . . . . .  7
-   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . .  8
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . . 10
-     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10
-     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10
-     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . . 10
-     5.5   Ticket Protection Key Lifetime . . . . . . . . . . . . . . 10
-     5.6   Alternate Ticket Formats and Distribution Schemes  . . . . 11
-   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
-   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 11
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-     8.1   Normative References . . . . . . . . . . . . . . . . . . . 11
-     8.2   Informative References . . . . . . . . . . . . . . . . . . 12
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
-       Intellectual Property and Copyright Statements . . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 2]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) session without requiring session-specific state at the TLS
-   server.  This mechanism may be used with any TLS ciphersuite.  This
-   document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1
-   defined in [I-D.ietf-tls-rfc2246-bis].  The mechanism makes use of
-   TLS extensions defined in [I-D.ietf-tls-rfc3546bis] and defines a new
-   TLS message type.
-
-   This mechanism is useful in the following types of situations
-      (1) servers that handle a large number of transactions from
-      different users
-      (2) servers that desire to cache sessions for a long time
-      (3) ability to load balance requests across servers
-      (4) embedded servers with little memory
-
-2.  Terminology
-
-   Within this document the term 'ticket' refers to a cryptographically
-   protected data structure which is created by the server and consumed
-   by the server to rebuild session specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-   This specification describes a mechanism to distribute encrypted
-   session state information in a ticket from a TLS server to a TLS
-   client and a mechanism for a TLS client to present a ticket to a TLS
-   server to resume a session.  Implementations of this specification
-   are expected to support both mechanisms.  Other specifications can
-   take advantage of the session tickets, perhaps specifying alternative
-   means for distribution or selection.  For example a separate
-   specification may describe an alternate way to distribute a ticket
-   and use the TLS extension in this document to resume the session.
-   This behavior is beyond the scope of the document and would need to
-   be described in a separate specification.
-
-3.1  Overview
-
-   The client indicates that it supports this mechanism by including a
-   SessionTicket TLS extension in the ClientHello message.  The
-   extension will be empty if the client does not already possess a
-   ticket for the server.  The extension is described in Section 3.2
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 3]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the SessionTicket TLS
-   handshake message described in Section 3.3.  This message is sent
-   during the TLS handshake before the ChangeCipherSpec message after
-   the server has successfully verified the client's Finished message.
-
-
-         Client                                               Server
-
-         ClientHello                   -------->
-        (empty SessionTicket extension)
-                                                         ServerHello
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                       SessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   The client caches this ticket along with the master secret and other
-   parameters associated with the current session.  When the client
-   wishes to resume the session, it includes the ticket in the
-   SessionTicket extension within ClientHello message.  The server then
-   decrypts the received ticket, verifies that the ticket is valid and
-   has not been tampered with, retrieves the session state from the
-   contents of the ticket and uses this state to resume the session.
-   The interaction with the TLS Session ID is described in Section 3.4.
-   If the server successfully verifies the client's ticket then it may
-   renew the ticket by including a SessionTicket handshake message after
-   the ServerHello.
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 4]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                      (empty SessionTicket extension)
-                                                        SessionTicket
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-   A recommended ticket format is given in Section 4.
-
-   If the server cannot or does not want to honor the ticket then it can
-   initiate a full handshake with the client.
-
-3.2  SessionTicket TLS extension
-
-   The SessionTicket TLS extension is based on [I-D.ietf-tls-
-   rfc3546bis].  The format of the ticket is an opaque structure used to
-   carry session specific state information.  This extension may be sent
-   in the ClientHello and ServerHello.
-
-   If the client possesses a ticket that it wants to use to resume a
-   session then it includes it in the SessionTicket extension in the
-   ClientHello.  If the client does not have a ticket and it is prepared
-   to receive one in the SessionTicket handshake message then it MUST
-   include a zero length ticket in the SessionTicket extension.  If the
-   client is not prepared to receive a ticket in the SessionTicket
-   handshake message then it MUST NOT include a SessionTicket extension
-   unless it is sending a non-empty ticket it received through some
-   other means from the server.
-
-   The server uses an zero length SessionTicket extension to indicate to
-   the client that it will send a new session ticket using the
-   SessionTicket handshake message described in Section 3.3.  The server
-   MUST send this extension in the ServerHello if the server wishes to
-   issue a new ticket to the client using the SessionTicket handshake
-   message.  The server MUST NOT send this extension if the client does
-   not include a SessionTicket handshake message in the client hello.
-
-   If the server fails to verify the ticket then it falls back to
-   performing a full handshake.  If the ticket is accepted by the server
-   but the handshake fails the client SHOULD delete the ticket.
-
-   The SessionTicket extension has been assigned the number TBD1.  The
-   format of the SessionTicket extension is given below.
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 5]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-
-3.3  SessionTicket handshake message
-
-   This message is sent by the server during the TLS handshake before
-   the ChangeCipherSpec message.  This message MUST be sent if the
-   server included a SessionTicket extension in the ServerHello.  This
-   message MUST NOT be sent if the server did not include a
-   SessionTicket extension in the ServerHello.  In the case of a full
-   handshake, the server MUST verify the client's Finished message
-   before sending the ticket.  The client MUST NOT treat the ticket as
-   valid until it has verified the server's Finished message.  If the
-   server determines that it does not want to include a ticket after it
-   has included the SessionTicket extension in the ServerHello then it
-   MAY send a zero length ticket in the SessionTicket handshake message.
-
-   If the server successfully verifies the client's ticket then it MAY
-   renew the ticket by including a SessionTicket handshake message after
-   the ServerHello in the abbreviated handshake.  The client should
-   start using the new ticket as soon as possible after it verifies the
-   Server's finished message for new connections.  Note that since the
-   updated ticket is issued before the handshake completes it is
-   possible that the client may not put the new ticket into use before
-   it initiates new connections.  The server MUST NOT assume the client
-   actually received the updated ticket until it successfully verifies
-   the client's Finished message.
-
-   The SessionTicket handshake message has been assigned the number
-   TBD2.  The definition of the SessionTicket handshake message is given
-   below.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 6]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case session_ticket:  SessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-
-3.4  Interaction with TLS session ID
-
-   If a server is planning on issuing a SessionTicket to a client that
-   does not present one it SHOULD include an empty Session ID in the
-   ServerHello.  If the server includes a non-empty session ID then it
-   is indicating intent to use stateful session resume.  If the client
-   receives a SessionTicket from the server then it discards any Session
-   ID that was sent in the ServerHello.
-
-   When presenting a ticket the client MAY generate and include a
-   Session ID in the TLS ClientHello.  If the server accepts the ticket
-   and the Session ID is not empty then it MUST respond with the same
-   Session ID present in the ClientHello.  This allows the client to
-   easily differentiate when the server is resuming a session or falling
-   back to a full handshake.  Since the client generates a Session ID
-   the server MUST NOT rely upon the Session ID having a particular
-   value when validating the ticket.  If a ticket is presented by the
-   client the server MUST NOT attempt to use the Session ID in the
-   ClientHello for stateful session resume.  Alternatively, the client
-   MAY include an empty Session ID in the ClientHello.  In this case the
-   client ignores the Session ID sent in the ServerHello and determines
-   if the server is resuming a session by the subsequent handshake
-   messages.
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 7]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-4.  Recommended Ticket Construction
-
-   This section describes a recommended format and protection for the
-   ticket.  Note that the ticket is opaque to the client so the
-   structure is not subject to interoperability concerns, so
-   implementations may diverge from this format.  If implementations do
-   diverge from this format they must take security concerns seriously.
-   Clients MUST NOT examine the ticket under the assumption that it
-   complies with this document.
-
-   The server uses two different keys, one 128-bit key for AES [AES] in
-   CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
-   [SHA1].
-
-   The ticket is structured as follows:
-
-      struct {
-          uint32 key_version;
-          opaque iv[16]
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } Ticket;
-
-   Here key_version identifies a particular set of keys.  One
-   possibility is to generate new random keys every time the server is
-   started, and use the timestamp as the key version.  The same
-   mechanisms known from a number of other protocols can be reused for
-   this purpose.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_version (4 octets)and IV (16 octets),
-   followed by the length of the encrypted_state field (2 octets) and
-   its contents (variable length).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 8]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ExampleClientIdentity client_identity;
-          uint32 timestamp;
-      } StatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ClientAuthenticationType;
-
-      struct {
-          ClientAuthenticationType client_authentication_type;
-          select (ClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>;
-
-          }
-       } ClientIdentity;
-
-   The structure StatePlaintext stores the TLS session state including
-   the master_secret.  The timestamp within this structure allows the
-   TLS server to expire tickets.  To cover the authentication and key
-   exchange protocols provided by TLS the ClientIdentity structure
-   contains the authentication type of the client used in the initial
-   exchange (see ClientAuthenticationType).  To offer the TLS server
-   with the same capabilities for authentication and authorization a
-   certificate list is included in case of public key based
-   authentication.  The TLS server is therefore able to inspect a number
-   of different attributes within these certificates.  A specific
-   implementation might choose to store a subset of this information or
-   additional information.  Other authentication mechanism such as
-   Kerberos [RFC2712] would require different client identity data.
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be sufficiently authenticated and encrypted to
-   prevent modification or eavesdropping by an attacker.  Several
-   attacks described below will be possible if this is not carefully
-   done.
-
-
-
-Salowey, et al.           Expires June 18, 2006                 [Page 9]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of serve as described
-   below.
-
-5.1  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure an attacker cannot invalidate a chosen session.
-
-5.2  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server,
-   however since the ticket is encrypted and the attacker does not know
-   the secret key, a stolen ticket does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the tickets contents.
-
-5.3  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user or
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC-SHA1.
-
-5.4  Denial of Service Attacks
-
-   An adversary could store or forge a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service, the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-5.5  Ticket Protection Key Lifetime
-
-   The management of the keys used to protect the ticket is beyond the
-   scope of this document.  It is advisable to limit the lifetime of
-   these keys to ensure they are not overused.
-
-
-
-Salowey, et al.           Expires June 18, 2006                [Page 10]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-5.6  Alternate Ticket Formats and Distribution Schemes
-
-   If a different ticket format or distribution scheme than the ones
-   defined in this document is used then great care must be taken in
-   analyzing the security of the solution.  In particular if a secret is
-   transferred to the client it MUST be done using secure communication
-   so as to prevent attackers from obtaining or modifying the key.  Also
-   the ticket MUST have its integrity and privacy protected with strong
-   cryptographic techniques to prevent a breach in the security of the
-   system.
-
-6.  Acknowledgments
-
-   The authors would like to thank the following people for their help
-   with preparing and reviewing this document: Eric Rescorla, Mohamad
-   Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
-   Rob Dugal and members of the TLS working group.
-
-   [CSSC] describes a solution that is very similar to the one described
-   in this document and gives a detailed analysis of the security
-   considerations involved.  [RFC2712] describes a mechanism for using
-   Kerberos ([RFC4120]) in TLS ciphersuites, which helped inspire the
-   use of tickets to avoid server state.  [I-D.cam-winget-eap-fast]
-   makes use of a similar mechanism to avoid maintaining server state
-   for the cryptographic tunnel.  [SC97] also investigates the concept
-   of stateless sessions.
-
-7.  IANA considerations
-
-   IANA has assigned a TLS extension number of TBD1 (the value 35 is
-   suggested) to the SessionTicket TLS extension from the TLS registry
-   of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
-
-   IANA has assigned a TLS HandshakeType number TBD2 to the
-   SessionTicket handshake type from the TLS registry of HandshakeType
-   values defined in [I-D.ietf-tls-rfc2246-bis].
-
-8.  References
-
-8.1  Normative References
-
-   [I-D.ietf-tls-rfc2246-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
-              June 2005.
-
-   [I-D.ietf-tls-rfc3546bis]
-              Blake-Wilson, S., "Transport Layer Security (TLS)
-
-
-
-Salowey, et al.           Expires June 18, 2006                [Page 11]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-              Extensions", draft-ietf-tls-rfc3546bis-02 (work in
-              progress), October 2005.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-8.2  Informative References
-
-   [AES]      National Institute of Standards and Technology, "Advanced
-              Encryption Standard (AES)", Federal Information
-              Processing Standards (FIPS) Publication 197,
-              November 2001.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", NIST Special Publication 800-38A,
-              December 2001.
-
-   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
-              caching for TLS", Transactions on Information and
-              System Security (TISSEC) , Volume 7, Issue 4,
-              November 2004.
-
-   [I-D.cam-winget-eap-fast]
-              Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
-              Flexible Authentication via Secure Tunneling (EAP-FAST)",
-              draft-cam-winget-eap-fast-02 (work in progress),
-              April 2005.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                [Page 12]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-   [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-   [SHA1]     National Institute of Standards and Technology, "Secure
-              Hash Standard (SHS)", Federal Information Processing
-              Standards    (FIPS) Publication  180-2, August 2002.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   Email: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   Email: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                [Page 13]
-
-Internet-Draft      Stateless TLS Session Resumption       December 2005
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Salowey, et al.           Expires June 18, 2006                [Page 14]
-
diff --git a/doc/protocol/draft-salowey-tls-ticket-07.txt b/doc/protocol/draft-salowey-tls-ticket-07.txt
deleted file mode 100644
index f78c7f5ed1..0000000000
--- a/doc/protocol/draft-salowey-tls-ticket-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-Network Working Group                                         J. Salowey
-Internet-Draft                                                   H. Zhou
-Expires: July 29, 2006                                     Cisco Systems
-                                                               P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                        January 25, 2006
-
-
- Transport Layer Security Session Resumption without Server-Side State
-                    draft-salowey-tls-ticket-07.txt
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on July 29, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a mechanism which enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-   ticket and forwards it to the client.  The client can subsequently
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 1]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-   resume a session using the obtained ticket.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.2   SessionTicket TLS extension  . . . . . . . . . . . . . . .  5
-     3.3   NewSessionTicket handshake message . . . . . . . . . . . .  6
-     3.4   Interaction with TLS session ID  . . . . . . . . . . . . .  7
-   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . .  8
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-     5.1   Invalidating Sessions  . . . . . . . . . . . . . . . . . . 10
-     5.2   Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 10
-     5.3   Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 10
-     5.4   Denial of Service Attacks  . . . . . . . . . . . . . . . . 10
-     5.5   Ticket Protection Key Management . . . . . . . . . . . . . 10
-     5.6   Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 11
-     5.7   Alternate Ticket Formats and Distribution Schemes  . . . . 11
-     5.8   Identity Privacy, Anonymity and Unlinkability  . . . . . . 11
-   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     8.1   Normative References . . . . . . . . . . . . . . . . . . . 12
-     8.2   Informative References . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-       Intellectual Property and Copyright Statements . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 2]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) session without requiring session-specific state at the TLS
-   server.  This mechanism may be used with any TLS ciphersuite.  This
-   document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1
-   defined in [I-D.ietf-tls-rfc2246-bis].  The mechanism makes use of
-   TLS extensions defined in [I-D.ietf-tls-rfc3546bis] and defines a new
-   TLS message type.
-
-   This mechanism is useful in the following types of situations:
-
-
-      1.  servers that handle a large number of transactions from
-          different users
-      2.  servers that desire to cache sessions for a long time
-      3.  ability to load balance requests across servers
-      4.  embedded servers with little memory
-
-2.  Terminology
-
-   Within this document the term 'ticket' refers to a cryptographically
-   protected data structure which is created by the server and consumed
-   by the server to rebuild session specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-   This specification describes a mechanism to distribute encrypted
-   session state information in the form of a ticket.  The ticket is
-   created by a TLS server and sent to a TLS client.  The TLS client
-   presents the ticket to the TLS server to resume a session.
-   Implementations of this specification are expected to support both
-   mechanisms.  Other specifications can take advantage of the session
-   tickets, perhaps specifying alternative means for distribution or
-   selection.  For example a separate specification may describe an
-   alternate way to distribute a ticket and use the TLS extension in
-   this document to resume the session.  This behavior is beyond the
-   scope of the document and would need to be described in a separate
-   specification.
-
-3.1  Overview
-
-   The client indicates that it supports this mechanism by including a
-   SessionTicket TLS extension in the ClientHello message.  The
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 3]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-   extension will be empty if the client does not already possess a
-   ticket for the server.  The extension is described in Section 3.2
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   TLS handshake message described in Section 3.3.  This message is sent
-   during the TLS handshake before the ChangeCipherSpec message after
-   the server has successfully verified the client's Finished message.
-
-
-         Client                                               Server
-
-         ClientHello                   -------->
-        (empty SessionTicket extension)
-                                                         ServerHello
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                    NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   The client caches this ticket along with the master secret and other
-   parameters associated with the current session.  When the client
-   wishes to resume the session, it includes the ticket in the
-   SessionTicket extension within ClientHello message.  The server then
-   decrypts the received ticket, verifies that the ticket validity,
-   retrieves the session state from the contents of the ticket and uses
-   this state to resume the session.  The interaction with the TLS
-   Session ID is described in Section 3.4.  If the server successfully
-   verifies the client's ticket then it may renew the ticket by
-   including a NewSessionTicket handshake message after the ServerHello.
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 4]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                      (empty SessionTicket extension)
-                                                     NewSessionTicket
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-   A recommended ticket format is given in Section 4.
-
-   If the server cannot or does not want to honor the ticket then it can
-   initiate a full handshake with the client.
-
-3.2  SessionTicket TLS extension
-
-   The SessionTicket TLS extension is based on [I-D.ietf-tls-
-   rfc3546bis].  The format of the ticket is an opaque structure used to
-   carry session specific state information.  This extension may be sent
-   in the ClientHello and ServerHello.
-
-   If the client possesses a ticket that it wants to use to resume a
-   session then it includes the ticket in the SessionTicket extension in
-   the ClientHello.  If the client does not have a ticket and it is
-   prepared to receive one in the NewSessionTicket handshake message
-   then it MUST include a zero length ticket in the SessionTicket
-   extension.  If the client is not prepared to receive a ticket in the
-   NewSessionTicket handshake message then it MUST NOT include a
-   SessionTicket extension unless it is sending a non-empty ticket it
-   received through some other means from the server.
-
-   The server uses an zero length SessionTicket extension to indicate to
-   the client that it will send a new session ticket using the
-   NewSessionTicket handshake message described in Section 3.3.  The
-   server MUST send this extension in the ServerHello if it wishes to
-   issue a new ticket to the client using the NewSessionTicket handshake
-   message.  The server MUST NOT send this extension if it does not
-   receive on in the ClientHello.
-
-   If the server fails to verify the ticket then it falls back to
-   performing a full handshake.  If the ticket is accepted by the server
-   but the handshake fails the client SHOULD delete the ticket.
-
-   The SessionTicket extension has been assigned the number TBD1.  The
-   format of the SessionTicket extension is given at the end of this
-   section.
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 5]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-
-3.3  NewSessionTicket handshake message
-
-   This message is sent by the server during the TLS handshake before
-   the ChangeCipherSpec message.  This message MUST be sent if the
-   server included a SessionTicket extension in the ServerHello.  This
-   message MUST NOT be sent if the server did not include a
-   SessionTicket extension in the ServerHello.  In the case of a full
-   handshake, the server MUST verify the client's Finished message
-   before sending the ticket.  The client MUST NOT treat the ticket as
-   valid until it has verified the server's Finished message.  If the
-   server determines that it does not want to include a ticket after it
-   has included the SessionTicket extension in the ServerHello then it
-   sends a zero length ticket in the NewSessionTicket handshake message.
-
-   If the server successfully verifies the client's ticket then it MAY
-   renew the ticket by including a NewSessionTicket handshake message
-   after the ServerHello in the abbreviated handshake.  The client
-   should start using the new ticket as soon as possible after it
-   verifies the Server's finished message for new connections.  Note
-   that since the updated ticket is issued before the handshake
-   completes it is possible that the client may not put the new ticket
-   into use before it initiates new connections.  The server MUST NOT
-   assume the client actually received the updated ticket until it
-   successfully verifies the client's Finished message.
-
-   The NewSessionTicket handshake message has been assigned the number
-   TBD2 and its definition is given at the end of this section.  The
-   ticket_lifetime_hint field contains a hint from the server about how
-   long the ticket should be stored.  The value indicates the lifetime
-   in seconds as a 32 bit unsigned integer in network byte order.  A
-   value of zero is reserved to indicate that the lifetime of the ticket
-   is unspecified.  A client SHOULD delete the ticket and associated
-   state when the time expires.  It MAY delete the ticket earlier based
-   on local policy.  A server MAY treat a ticket as valid for a shorter
-   or longer period of time than what is stated in the
-   ticket_lifetime_hint.
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 6]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case session_ticket:      NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          uint32 ticket_lifetime_hint;
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-
-3.4  Interaction with TLS session ID
-
-   If a server is planning on issuing a SessionTicket to a client that
-   does not present one it SHOULD include an empty Session ID in the
-   ServerHello.  If the server includes a non-empty session ID then it
-   is indicating intent to use stateful session resume.  If the client
-   receives a SessionTicket from the server then it discards any Session
-   ID that was sent in the ServerHello.
-
-   When presenting a ticket the client MAY generate and include a
-   Session ID in the TLS ClientHello.  If the server accepts the ticket
-   and the Session ID is not empty then it MUST respond with the same
-   Session ID present in the ClientHello.  This allows the client to
-   easily differentiate when the server is resuming a session or falling
-   back to a full handshake.  Since the client generates a Session ID
-   the server MUST NOT rely upon the Session ID having a particular
-   value when validating the ticket.  If a ticket is presented by the
-   client the server MUST NOT attempt to use the Session ID in the
-   ClientHello for stateful session resume.  Alternatively, the client
-   MAY include an empty Session ID in the ClientHello.  In this case the
-   client ignores the Session ID sent in the ServerHello and determines
-   if the server is resuming a session by the subsequent handshake
-   messages.
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 7]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-4.  Recommended Ticket Construction
-
-   This section describes a recommended format and protection for the
-   ticket.  Note that the ticket is opaque to the client so the
-   structure is not subject to interoperability concerns, so
-   implementations may diverge from this format.  If implementations do
-   diverge from this format they must take security concerns seriously.
-   Clients MUST NOT examine the ticket under the assumption that it
-   complies with this document.
-
-   The server uses two different keys, one 128-bit key for AES [AES] in
-   CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
-   [SHA1].
-
-   The ticket is structured as follows:
-
-      struct {
-          opaque key_name[16];
-          opaque iv[16];
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } ticket;
-
-   Here key_name serves to identify a particular set of keys used to
-   protect the ticket.  It enables the server to easily recognize
-   tickets it has issued.  The key_name should be randomly generated to
-   avoid collisions between servers.  One possibility is to generate new
-   random keys and key_name every time the server is started.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_name (16 octets)and IV (16 octets), followed
-   by the length of the encrypted_state field (2 octets) and its
-   contents (variable length).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 8]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ClientIdentity client_identity;
-          uint32 timestamp;
-      } StatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ClientAuthenticationType;
-
-      struct {
-          ClientAuthenticationType client_authentication_type;
-          select (ClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>;
-
-          }
-       } ClientIdentity;
-
-   The structure StatePlaintext stores the TLS session state including
-   the master_secret.  The timestamp within this structure allows the
-   TLS server to expire tickets.  To cover the authentication and key
-   exchange protocols provided by TLS the ClientIdentity structure
-   contains the authentication type of the client used in the initial
-   exchange (see ClientAuthenticationType).  To offer the TLS server
-   with the same capabilities for authentication and authorization a
-   certificate list is included in case of public key based
-   authentication.  The TLS server is therefore able to inspect a number
-   of different attributes within these certificates.  A specific
-   implementation might choose to store a subset of this information or
-   additional information.  Other authentication mechanisms, such as
-   Kerberos [RFC2712], would require different client identity data.
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be sufficiently authenticated and encrypted to
-   prevent modification or eavesdropping by an attacker.  Several
-   attacks described below will be possible if this is not carefully
-   done.
-
-
-
-Salowey, et al.           Expires July 29, 2006                 [Page 9]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of serve as described
-   below.
-
-5.1  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure an attacker cannot invalidate a chosen session.
-
-5.2  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server,
-   however since the ticket is encrypted and the attacker does not know
-   the secret key, a stolen ticket does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the tickets contents.
-
-5.3  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user or
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC-SHA1.
-
-5.4  Denial of Service Attacks
-
-   The key_name field defined in the recommended ticket format helps the
-   server efficiently reject tickets that it did not issue.  However, an
-   adversary could store or generate a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service, the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-5.5  Ticket Protection Key Management
-
-   A full description of the management of the keys used to protect the
-
-
-
-Salowey, et al.           Expires July 29, 2006                [Page 10]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-   ticket is beyond the scope of this document.  A list of RECOMMENDED
-   practices is given below.
-
-   o  The key should be generated securely following the randomness
-      recommendations in [RFC4086]
-   o  The key and cryptographic protection algorithms should be at least
-      128 bits in strength
-   o  The key should not be used for any other purpose than generating
-      and verifying tickets
-   o  The key should be changed regularly
-   o  The key should be changed if the ticket format or cryptographic
-      protection algorithms change
-
-5.6  Ticket Lifetime
-
-   The TLS server controls the lifetime of the ticket.  Servers
-   determine the acceptable lifetime based on the operational and
-   security requirements of the environments in which they are deployed.
-   The ticket lifetime may be longer than the 24 hour lifetime
-   recommended in [RFC2246].  TLS clients may be given a hint of the
-   lifetime of the ticket.  Since the lifetime of a ticket may be
-   unspecified a client has its own local policy which determines when
-   it discards tickets.
-
-5.7  Alternate Ticket Formats and Distribution Schemes
-
-   If the ticket format or distribution scheme defined in this document
-   is not used then great care must be taken in analyzing the security
-   of the solution.  In particular if a confidential information, such
-   as a secret key, is transferred to the client it MUST be done using
-   secure communication so as to prevent attackers from obtaining or
-   modifying the key.  Also the ticket MUST have its integrity and
-   privacy protected with strong cryptographic techniques to prevent a
-   breach in the security of the system.
-
-5.8  Identity Privacy, Anonymity and Unlinkability
-
-   This document mandates that the content of the ticket is
-   confidentiality protected in order to avoid leakage of its content,
-   such as user relevant information.  As such, it prevents disclosure
-   of potentially sensitive information carried within the ticket.
-
-   The initial handshake exchange, which was used to obtain the ticket,
-   might not provide identity confidentiality of the client based on the
-   properties of TLS.  Another relevant security threat is the ability
-   for an on-path adversary to observe multiple TLS handshakes where the
-   same ticket is used and to therefore conclude that they belong to the
-   same communication endpoints.  Application designers that use the
-
-
-
-Salowey, et al.           Expires July 29, 2006                [Page 11]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-   ticket mechanism described in this document should consider that
-   unlinkability [ANON] is not necessarily provided.
-
-   While a full discussion of these topics is beyond the scope of this
-   document, it should be noted that it is possible to issue a ticket
-   using a TLS renegotiation handshake that occurs after a secure tunnel
-   has been established by a previous handshake.  This may help address
-   some privacy and unlinkability issues in some environments.
-
-6.  Acknowledgments
-
-   The authors would like to thank the following people for their help
-   with preparing and reviewing this document: Eric Rescorla, Mohamad
-   Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
-   Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba and members of
-   the TLS working group.
-
-   [CSSC] describes a solution that is very similar to the one described
-   in this document and gives a detailed analysis of the security
-   considerations involved.  [RFC2712] describes a mechanism for using
-   Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
-   of tickets to avoid server state.  [I-D.cam-winget-eap-fast] makes
-   use of a similar mechanism to avoid maintaining server state for the
-   cryptographic tunnel.  [SC97] also investigates the concept of
-   stateless sessions.
-
-7.  IANA considerations
-
-   IANA has assigned a TLS extension number of TBD1 (the value 35 is
-   suggested) to the SessionTicket TLS extension from the TLS registry
-   of ExtensionType values defined in [I-D.ietf-tls-rfc3546bis].
-
-   IANA has assigned a TLS HandshakeType number TBD2 to the
-   NewSessionTicket handshake type from the TLS registry of
-   HandshakeType values defined in [I-D.ietf-tls-rfc2246-bis].
-
-8.  References
-
-8.1  Normative References
-
-   [I-D.ietf-tls-rfc2246-bis]
-              Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", draft-ietf-tls-rfc2246-bis-13 (work in progress),
-              June 2005.
-
-   [I-D.ietf-tls-rfc3546bis]
-              Blake-Wilson, S., "Transport Layer Security (TLS)
-              Extensions", draft-ietf-tls-rfc3546bis-02 (work in
-
-
-
-Salowey, et al.           Expires July 29, 2006                [Page 12]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-              progress), October 2005.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-8.2  Informative References
-
-   [AES]      National Institute of Standards and Technology, "Advanced
-              Encryption Standard (AES)", Federal Information
-              Processing Standards (FIPS) Publication 197,
-              November 2001.
-
-   [ANON]     Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
-              Unobservability, Pseudonymity, and Identity Management - A
-              Consolidated Proposal for Terminology", http://
-              dud.inf.tu-dresden.de/literatur/
-              Anon_Terminology_v0.26-1.pdf Draft 0.26, December 2005.
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", NIST Special Publication 800-38A,
-              December 2001.
-
-   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
-              caching for TLS", Transactions on Information and
-              System Security (TISSEC) , Volume 7, Issue 4,
-              November 2004.
-
-   [I-D.cam-winget-eap-fast]
-              Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "EAP
-              Flexible Authentication via Secure Tunneling (EAP-FAST)",
-              draft-cam-winget-eap-fast-02 (work in progress),
-              April 2005.
-
-   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104,
-              February 1997.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                [Page 13]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-   [SHA1]     National Institute of Standards and Technology, "Secure
-              Hash Standard (SHS)", Federal Information Processing
-              Standards    (FIPS) Publication  180-2, August 2002.
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   Email: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   Email: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   Email: pasi.eronen@nokia.com
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                [Page 14]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                [Page 15]
-
-Internet-Draft      Stateless TLS Session Resumption        January 2006
-
-
-Intellectual Property Statement
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-Salowey, et al.           Expires July 29, 2006                [Page 16]
-
diff --git a/doc/protocol/draft-santesson-tls-gssapi-01.txt b/doc/protocol/draft-santesson-tls-gssapi-01.txt
deleted file mode 100644
index 9f38e49ea1..0000000000
--- a/doc/protocol/draft-santesson-tls-gssapi-01.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Intended Category: Standards Track              A. Medvinsky (Microsoft)
-Expires June 2007                           J. Altman (Secure Endpoints)
-                                                           December 2006
-
-    Generic Security Service Application Program Interface (GSS-API)
-              Extension for Transport Layer Security (TLS)
-                  <draft-santesson-tls-gssapi-01.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Abstract
-
-   This document defines protocol extensions to the Transport Layer
-   Security (TLS) protocol for user authentication and key negotiation
-   based on the Generic Security Service Application Program Interface
-   (GSS-API).
-
-   Full flexibility for negotiation of GSS-API mechanisms is provided,
-   allowing use of arbitrary GSS-API mechanisms provided that they
-   support the GSS-API PRF.
-
-   This document supersedes RFC 2712 [ref] as the mechanism to support
-   Kerberos based authentication and key establishment for a TLS
-   session.
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-Table of Contents
-
-   1  Introduction ................................................    n
-   2  GSS-API TLS extension .......................................    n
-   3  GSS-API Handshake message ...................................    n
-   4  Cipher Suites ...............................................    n
-   4  Message Flow  ...............................................    n
-   5  Key Derivation ..............................................    n
-   6  Security Considerations .....................................    n
-   7  IANA Considerations .........................................    n
-   8  References ..................................................    n
-   Appendix A (if needed)  ........................................    n
-   Authors' Addresses .............................................    n
-   Full Copyright Statement .......................................    n
-   Intellectual Property ..........................................    n
-
-1.  Introduction
-
-   This document defines protocol extensions to the Transport Layer
-   Security (TLS) [N5] protocol for user authentication and key
-   negotiation based on the Generic Security Service Application Program
-   Interface (GSS-API).  The extensions to TLS include a new
-   ExtensionType "gss_api" (section 2), a new HandshakeType "gss_token"
-   (section 3), a new KeyExchangeAlgorithm "gss_prf" (section 5), and
-   new "TLS_GSS" cipher suites (section 4).
-
-   Full flexibility for negotiation of GSS-API mechanisms is provided,
-   allowing use of arbitrary GSS-API mechanisms provided that they
-   support the GSS-API PRF.
-
-   This document supersedes RFC 2712 [ref] as the mechanism to support
-   Kerberos based authentication and key establishment for a TLS
-   session.
-
-1.1  Terminology
-
-   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 [N1].
-
-   The syntax for the supplemental_data handshake message is defined
-   using the TLS Presentation Language, which is specified in Section 4
-   of [N4].
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-2.  GSS-API TLS extension
-
-   This section defines a new TLS extension that conveys a list of GSS
-   mechanism OIDS in ClientHello and ServerHello messages.  The client
-   uses this extension to transmit a list of supported GSS mechanisms to
-   the server.  If the server chooses one of the GSS mechanisms, it
-   returns the selected OID to the client.  The client includes this
-   extension in the ClientHello only if one or more GSS based
-   ciphersuites (defined in section X) are included in the list of
-   supported cipher suites.  Similarly, the server includes this
-   extension in the ServerHello message only if it selected one of the
-   GSS cipher suites.
-
-
-       enum {
-            gss_api(n), (65535)
-       } ExtensionType;
-
-   The "extension_data" field of this extension SHALL contain
-   "GssOIDList" where:
-
-      struct{
-           GssOID  gss_oid_list<0..2^24-1>  // list of supported OIDs
-      }GssOIDList;
-
-      unit16 GssOID<2..254>;
-
-   GssOID contains a sequence of integers of an OBJECT IDENTIFIER (OID)
-   [ref] where the first integer in the sequence specifies the top node
-   of the OID.
-
-   Each OID specifies a specific GSS token exchange scheme.
-
-
-3.  GSS-API Handshake Message
-
-   This section defines a new handshake message to carry GSS tokens.
-   The message is used to send GSS tokens from TLS client to TLS server
-   and vice versa.
-
-      enum {
-           gss_token (nn), (255)
-      } HandshakeType;
-
-      struct {
-                  HandshakeType msg_type;    /* handshake type */
-                   uint24 length;            /* octets in message */
-                   select (HandshakeType) {
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-                          case gss_token:   GssToken;
-                     } body;
-      } Handshake;
-
-      Struct {
-          opaque  GssPayload<1..2^16-1>;
-          opaque  GssStatus[1]
-      } GssToken;
-
-
-   The GssStatus contains a status byte for the GssPayload:
-
-      GssStatus GSS_NORMAL            = { 0x00 };
-      GssStatus GSS_LAST_PAYLOAD      = { 0x01 };
-      GssStatus GSS_ERROR             = { 0x02 };
-
-
-   GSS_NORMAL is set for all GssPayload that does not match the
-   conditions for any other status bytes.
-
-   GSS_LAST_PAYLOAD is set for the last GssPayload in the exchange of
-   GSS-API payloads and signals that the exchange was successfully
-   concluded.
-
-   GSS_ERROR is set if an error state was reached in the exchange of GSS
-   tokens. Receiving a GssToken with this status set results in a fatal
-   error, and the receiver MUST close the connection with a
-   handshake_failure alert.  Immediately following the transmission of a
-   GssToken with this status set, the sender MUST close the connection
-   with a handshake_failure alert.
-
-
-4. Cipher suites
-
-   This document defines the following new cipher suites
-
-   CipherSuite TLS_GSS_API_WITH_RC4_128_SHA         = { 0xnn,0x00 };
-   CipherSuite TLS_GSS_API_WITH_AES_128_CBC_SHA     = { 0xnn,0x01 };
-   CipherSuite TLS_GSS_API_WITH_AES_256_CBC_SHA     = { 0xnn,0x02 };
-
-
-
-5. Key Derivation
-
-   After successful completion of the gss_token messages, the client and
-   server each obtain 46 bytes of key random data using the GSS-API PRF.
-   This data is the TLS pre-master secret.
-
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-   If the GSS-API PRF fails, the connection MUST be closed with a
-   handshake_failure alert.
-
-
-6. Message flow
-
-   Client                                               Server
-
-   ClientHello
-    /* with GSS-API extension */ ----->
-
-                                                   ServerHello
-                                  /* with GSS-API extension */
-                                  <--------    ServerHelloDone
-
-         <-----  gss_token Handskake messages ----->
-          /* multiple iterations with GssPayload */
-
-   ClientKeyExchange [ChangeCipherSpec] Finished
-   -------->
-                                            [ChangeCipherSpec]
-                                <--------             Finished
-   Application Data             <------->     Application Data
-
-
-   If the client is sending the GSSToken message with the
-   GSS_LAST_PAYLOAD flag set then the third leg of the protocol would
-   look like this:
-
-   GSSToken ClientKeyExchange [ChangeCipherSpec] Finished
-
-   However, for a GSS scheme where the server is sending the last GSS
-   token to the client (and the client has no more GSS tokens to send
-   then the third leg of the protocol will be just:
-
-   ClientKeyExchange [ChangeCipherSpec] Finished
-
-
-7  IANA Considerations
-
-   IANA needs to take the following actions:
-
-   1) Create an entry, gss_api (TBD), in the existing registry for
-   ExtensionType (defined in RFC 4366 [N7]).
-
-   2) Create an entry, gss_token (TBD), in the existing registry for
-   HandshakeType (defined in RFC 2246 [N7]).
-
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-   Cipher suite IANA actions TBD
-
-8 References
-
-   Normative references:
-
-   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]      Linn, J., "Generic Security Service Application Program
-             Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [N3]      N. Williams, "A Pseudo-Random Function (PRF) API Extension
-             for theGeneric Security Service Application Program
-             Interface (GSS-API)",RFC 4401, February 2006.
-
-   [N4]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-             2246, January 1999.
-
-   [N5]      Dierks, T. and E. Rescorla, "The Transport Layer Security
-             (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [N6]      Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-             and T. Wright, "Transport Layer Security (TLS) Extensions",
-             RFC 4366, April 2006.
-
-   [N7]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
-             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-             October 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-Appendix A.
-
-   Appednix text
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-Authors' Addresses
-
-
-   Stefan Santesson
-
-   Microsoft
-   Tuborg Boulevard 12
-   2900 Hellerup
-   Denmark
-
-   EMail: stefans@microsoft.com
-
-
-   Ari Medvinsky
-
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: arimed(at)microsoft.com
-
-
-   Jeffrey E. Altman
-
-   Secure Endpoints Inc.
-   255 West 94th Street
-   New York NY 10025
-   USA
-
-   EMail:jaltman@columbia.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT            DNS SRV RR otherName             November 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights. Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org."
-
-
-Expires June 2007
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 9]
diff --git a/doc/protocol/draft-santesson-tls-gssapi-02.txt b/doc/protocol/draft-santesson-tls-gssapi-02.txt
deleted file mode 100644
index ddf76b67c1..0000000000
--- a/doc/protocol/draft-santesson-tls-gssapi-02.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                     Microsoft Corporation
-Updates: 4279 (if approved)                                 July 9, 2007
-Intended status: Standards Track
-Expires: January 10, 2008
-
-
-     Flexible Key Agreement for Transport Layer Security (FKA-TLS)
-                     draft-santesson-tls-gssapi-02
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on January 10, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document defines extensions to RFC 4279 to enable dynamic key
-   sharing in distributed environments.  By using these extensions, the
-   client and the server can use off-shelf libraries to exchange tokens
-   and establish a shared secret, based on a Generic Security Service
-   Application Program Interface (GSS-API) mechanism such as Kerberos as
-   defined in RFC 4121, and then proceed according to RFC 4279 to
-   complete the authentication and provide data protection.
-
-
-
-Zhu                     Expires January 10, 2008                [Page 1]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
-   3.  Protocol Definition . . . . . . . . . . . . . . . . . . . . . . 3
-   4.  Choosing GSS-API Mechanisms . . . . . . . . . . . . . . . . . . 6
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
-   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
-   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                     Expires January 10, 2008                [Page 2]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-1.  Introduction
-
-   [RFC4279] defines Transport Layer Security (TLS) based on pre-shared
-   keys (PSK).  This assumes a pair-wise key sharing scheme that is less
-   scalable and more costly to manage in comparison with a trusted third
-   party scheme such as Kerberos [RFC4120].  In addition, off-shelf GSS-
-   API libraries that allow dynamic key sharing are not currently
-   accessible to TLS applications.  For example, Kerberos [RFC4121] is a
-   GSS-API mechanism that can establish a shared key between a client
-   and a server based on either asymmetric keys [RFC4556] or symmetric
-   keys [RFC4120].
-
-   This document extends [RFC4279] to allow the client and the server
-   establish a shared key on demand by using off-shelf GSS-API
-   libraries, and then proceed according to RFC 4279.  This is a modular
-   approach to leverage Kerberos alike trust infrastructures in securing
-   TLS connections.
-
-
-2.  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 [RFC2119].
-
-
-3.  Protocol Definition
-
-   The GSS-API TLS extension is defined according to [RFC3546].  The
-   extension data carries GSS-API token within the TLS hello messages.
-
-     enum {
-         GSS-API(TBD), (65535)
-     } ExtensionType;
-
-   Initially the client calls GSS_Init_sec_context() [RFC2743] to
-   establish a security context, it MUST set the mutual_req_flag and
-   identify the server by targ_name so that mutual authentication is
-   performed in the course of context establishment.  If the mutual
-   authentication is not available when the context is established
-   successfully, the GSS-API security context MUST be discarded.  The
-   extension_data from the client contains the output token of
-   GSS_Init_sec_context().  If a GSS-API context cannot be established,
-   the GSS-API TLS extension MUST NOT be included in the client hello
-   message and it is a matter of local policy on the client whether to
-   continue or reject the TLS authentication as if the GSS-API TLS
-   extension is not supported.
-
-
-
-
-Zhu                     Expires January 10, 2008                [Page 3]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   Upon receipt of the GSS-API TLS extension from the client, and if the
-   server supports the GSS-API TLS extension, the server calls
-   GSS_Accept_sec_context() with the client GSS-API output token in the
-   client's extension data as the input token.  If
-   GSS_Accept_sec_context() returns a token successfully, the server
-   responds with a GSS-API TLS extension and places the output token in
-   the extension_data.  If GSS_Accept_sec_context() fails, it is a
-   matter of local policy on the server whether to continue or reject
-   the TLS authentication as if the GSS-API TLS extension is not
-   supported.
-
-   The server MUST NOT include a GSS-API TLS extension in the hello
-   message if the cipher_suite in the ServerHello message is not a PSK
-   ciphersuite [RFC4279].
-
-   If the server expects at least one more token to be accepted from the
-   client in order to establish the security context, the additional
-   GSS-API tokens are carried in a new handshake message called the
-   token-transfer message.
-
-          enum {
-             token_transfer(TBD), (255)
-         } HandshakeType;
-
-         struct {
-             HandshakeType msg_type;    /* handshake type */
-             uint24 length;             /* bytes in message */
-             select (HandshakeType) {
-                 case token_transfer: /* NEW */
-                       TokenTranfer;
-             } body;
-         } Handshake;
-
-          enum {
-             gss-api-token(1), (255)
-         } TokenTransferType;
-
-         struct {
-               TokenTransferType token_type; /* token type */
-               opaque token<0..2^16-1>;
-         } TokenTranfer;
-
-   The TokenTranfer structure is filled out as follows:
-
-   o  The token_type is gss-api-token.
-
-
-
-
-
-
-Zhu                     Expires January 10, 2008                [Page 4]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   o  The token field contains the GSS-API context establishment tokens
-      from the client and the server.
-
-   The client calls GSS_Init_sec_context() with the token in the
-   TokenTranfer stucture from the server as the input token, and then
-   places the output token, if any, into the TokenTranfer message and
-   sends the handshake message to the server.  The server calls
-   GSS_Accept_sec_context() with the token in the TokenTranfer structure
-   from the client as the input token, and then places the output token,
-   if any, into the TokenTranfer message and sends the handshake message
-   to the client.  This loop repeats until either the context fails to
-   establish or the context is established successfully.  To prevent an
-   infinite loop, both the client and the server MUST have a policy to
-   limit the maximum number of GSS-API context establishment calls for a
-   given session.  The recommended value is 5.  If the GSS-API context
-   fails to establish, it is a matter of local policy whether to
-   continue or reject the TLS authentication as if the GSS-API TLS
-   extension is not supported.
-
-   When the last GSS-API context establishment token is sent by the
-   client or when the GSS-API context fails to establish on the client
-   side and the local policy allows the TLS authentication to proceed as
-   if the TLS GSS-API extension is not supported, the client sends an
-   empty TokenTransfer handshake message.
-
-   If the GSS-API context fails to establish and local policy allows the
-   TLS authentication continue as if the GSS-API TLS extension is not
-   supported, the server MAY send another ServerHello message in order
-   to choose a different cipher suite.  The client then MUST expect the
-   second ServerHello message from the server before the session is
-   established.  The second ServerHello message MUST differ from the
-   first ServerHello message in the cipher_suite field and only in that
-   field.
-
-   If the client and the server establish a security context
-   successfully, both the client and the server call GSS_Pseudo_random()
-   [RFC4401] to compute a sufficiently long shared secret with the same
-   value based on the negotiated ciphersuite, and then proceed according
-   to [RFC4279] using this shared secret value as the "PSK".  Both
-   psk_identity and psk_identity_hint are empty in the handshake
-   messages when the shared key is established using a GSS-API mechanism
-   as described in this document.
-
-   The following text art summaries the protocol message flow.
-
-
-
-
-
-
-
-Zhu                     Expires January 10, 2008                [Page 5]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-       Client                                               Server
-
-       ClientHello                  -------->
-                                                       ServerHello
-                                   <--------        TokenTransfer*
-                                      .
-                                      .
-                                      .
-       TokenTransfer*               -------->
-
-                                                      ServerHello*
-                                                      Certificate*
-                                                ServerKeyExchange*
-                                               CertificateRequest*
-                                   <--------       ServerHelloDone
-       Certificate*
-       ClientKeyExchange
-       CertificateVerify*
-       [ChangeCipherSpec]
-       Finished                     -------->
-                                                [ChangeCipherSpec]
-                                   <--------              Finished
-       Application Data            <-------->     Application Data
-       
-          Fig. 1. Message flow for a full handshake
-
-       * Indicates optional or situation-dependent messages that are 
-         not always sent.
-
-   There could be multiple TokenTransfer handshake messages, and the
-   last TokenTranster message, if present, is always sent from the
-   client to the server and it can carry an empty token.
-
-
-4.  Choosing GSS-API Mechanisms
-
-   If more than one GSS-API mechanism is shared between the client and
-   the server, it is RECOMMENDED to deploy a pseudo GSS-API mechanism
-   such as [RFC4178] to choose a mutually preferred GSS-API mechanism.
-
-   If the Kerberos client does not have access to the KDC but the server
-   does, [IAKERB] can be chosen to tunnel the Kerberos authentication
-   exchange within the TLS handshake messages.
-
-
-5.  Security Considerations
-
-   When Kerberos as defined in [RFC4120] is used to establish the share
-
-
-
-Zhu                     Expires January 10, 2008                [Page 6]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   key, it is vulnerable to offline dictionary attacks.  The threat is
-   mitigated by deploying kerberos FAST [KRB-FAST].
-
-
-6.  Acknowledgements
-
-   Stefan Santesson, Ari Medvinsky and Jeffery Altman helped editing the
-   earlier revisions of this document.
-
-
-7.  IANA Considerations
-
-   A new handshake message token_transfer is defined according to
-   [RFC4346] and a new TLS extension called the GSS-API extension is
-   defined according to [RFC3546].  The registry need to be updated to
-   include these new types.
-
-   This document defines the type of the transfer tokens in Section 3, a
-   registry need to be setup and the allocation policy is "Specification
-   Required".
-
-
-8.  References
-
-8.1.  Normative References
-
-   [IAKERB]   Zhu, L., "Initial and Pass Through Authentication Using
-              Kerberos V5 and the GSS-API", draft-zhu-ws-kerb-03.txt
-              (work in progress), 2007.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 3546, June 2003.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-
-
-Zhu                     Expires January 10, 2008                [Page 7]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
-              Extension for the Generic Security Service Application
-              Program Interface (GSS-API)", RFC 4401, February 2006.
-
-8.2.  Informative References
-
-   [KRB-FAST]
-              Zhu, L. and S. Hartman, "A Generalized Framework for
-              Kerberos Pre-Authentication",
-              draft-ietf-krb-wg-preauth-framework-06.txt (work in
-              progress), 2007.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-Author's Address
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu                     Expires January 10, 2008                [Page 8]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu                     Expires January 10, 2008                [Page 9]
-
-
diff --git a/doc/protocol/draft-santesson-tls-gssapi-03.txt b/doc/protocol/draft-santesson-tls-gssapi-03.txt
deleted file mode 100644
index 98a615c3d5..0000000000
--- a/doc/protocol/draft-santesson-tls-gssapi-03.txt
+++ /dev/null
@@ -1,900 +0,0 @@
-
-
-NETWORK WORKING GROUP                                             L. Zhu
-Internet-Draft                                                G. Chander
-Updates: 4279 (if approved)                        Microsoft Corporation
-Intended status: Standards Track                               J. Altman
-Expires: January 26, 2008                          Secure Endpoints Inc.
-                                                            S. Santesson
-                                                   Microsoft Corporation
-                                                           July 25, 2007
-
-
-     Flexible Key Agreement for Transport Layer Security (FKA-TLS)
-                     draft-santesson-tls-gssapi-03
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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.
-
-   This Internet-Draft will expire on January 26, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document defines extensions to RFC 4279, "Pre-Shared Key
-   Ciphersuites for Transport Layer Security (TLS)", to enable dynamic
-   key sharing in distributed environments using a Generic Security
-   Service Application Program Interface (GSS-API) mechanism, and then
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 1]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   import that shared key as the "Pre-Shared Key" to complete the TLS
-   handshake.
-
-   This is a modular approach to perform authentication and key exchange
-   based on off-shelf libraries.  And it obviates the need of pair-wise
-   key sharing by enabling the use of the widely-deployed Kerberos alike
-   trust infrastructures that are highly scalable and robust.
-   Furthermore, conforming implementations can provide server
-   authentication without the use of certificates.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
-   3.  Protocol Definition  . . . . . . . . . . . . . . . . . . . . .  3
-   4.  Choosing GSS-API Mechanisms  . . . . . . . . . . . . . . . . .  8
-   5.  Client Authentication  . . . . . . . . . . . . . . . . . . . .  8
-   6.  Protecting GSS-API Authentication Data . . . . . . . . . . . .  8
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 11
-     10.2.  Informative References  . . . . . . . . . . . . . . . . . 11
-   Appendix A.  An FKA-TLS Example: Kerberos TLS  . . . . . . . . . . 13
-   Appendix B.  Additional Use Cases for FXA-TLS  . . . . . . . . . . 13
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
-   Intellectual Property and Copyright Statements . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 2]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-1.  Introduction
-
-   [RFC4279] defines Transport Layer Security (TLS) based on pre-shared
-   keys (PSK).  This assumes a pair-wise key sharing scheme that is less
-   scalable and more costly to manage in comparison with a trusted third
-   party scheme such as Kerberos [RFC4120].  In addition, off-shelf GSS-
-   API libraries that allow dynamic key sharing are not currently
-   accessible to TLS applications.  Lastly, [RFC4279] does not provide
-   true mutual authentication against the server.
-
-   This document extends [RFC4279] to establish a shared key, and
-   optionally provide client or server authentication, by using off-
-   shelf GSS-API libraries, and the established shared key is then
-   imported as "PSK" to [RFC4279].  No new key cipher suite is defined
-   in this document.
-
-   As an example usage scenario, Kerberos [RFC4121] is a GSS-API
-   mechanism that can be selected to establish a shared key between a
-   client and a server based on either asymmetric keys [RFC4556] or
-   symmetric keys [RFC4120].  By using the extensions defined in this
-   document, a TLS connection is secured using the Kerberos version 5
-   mechanism exposed as a generic security service via GSS-API.
-
-   With regard to the previous work for the Kerberos support in TLS,
-   [RFC2712] defines "Addition of Kerberos Cipher Suites to Transport
-   Layer Security (TLS)" which has not been widely implemented due to
-   violations of Kerberos Version 5 library abstraction layers,
-   incompatible implementations from two major distributions (Sun Java
-   and OpenSSL), and its lack of support for credential delegation.
-   This document defines a generic extensible method that addresses the
-   limitations associated with [RFC2712] and integrates Kerberos and
-   TLS.  Relying on [RFC4121] for Kerberos Version 5 support will
-   significantly reduce the challenges associated with implementing this
-   protocol as a replacement for [RFC2712].
-
-
-2.  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 [RFC2119].
-
-
-3.  Protocol Definition
-
-   In this protocol, the on-demand key exchange is implemented by
-   encapsulating the GSS security context establishment within the TLS
-   handshake messages when PSK cipher suites are requested in the
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 3]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   extended ClientHello message.
-
-   The gss_api TLS extension is defined according to [RFC3546].  The
-   extension data carries GSS-API token within the TLS hello messages.
-
-     enum {
-         gss_api(TBD), (65535)
-     } ExtensionType;
-
-   The client MUST NOT include a gss_api TLS extension if there is no
-   PSK ciphersuite [RFC4279] included in the cipher_suites field of the
-   client hello message.
-
-   Initially the client computes the gss_api TLS extension data by
-   calling GSS_Init_sec_context() [RFC2743] to establish a security
-   context.  The TLS client MUST set the mutual_req_flag and identify
-   the server by targ_name so that mutual authentication is performed in
-   the course of context establishment.  The extension_data from the
-   client contains the output token of GSS_Init_sec_context().
-
-   If a GSS-API context cannot be established, the gss_api TLS extension
-   MUST NOT be included in the client hello message and it is a matter
-   of local policy on the client whether to continue or reject the TLS
-   authentication as if the gss_api TLS extension is not supported.
-
-   If the mutual authentication is not available on the established GSS-
-   API context, the PSK key exchange described in Section 2 of [RFC4279]
-   MUST NOT be selected, and the DHE_PSK or RSA_PSK key exchange MUST be
-   negotiated instead in order to authenticate the server.
-
-   Upon receipt of the gss_api TLS extension from the client, and if the
-   server supports the gss_api TLS extension, the server calls
-   GSS_Accept_sec_context() with the client GSS-API output token in the
-   client's extension data as the input token.  If
-   GSS_Accept_sec_context() returns a token successfully, the server
-   responds by including a gss_api TLS extension in the server hello
-   message and places the output token in the extension_data.  If
-   GSS_Accept_sec_context() fails, it is a matter of local policy on the
-   server whether to continue or reject the TLS authentication as if the
-   gss_api TLS extension is not supported.
-
-   The server MUST ignore a TLS gss_api extension in the extended
-   ClientHello if its selected CipherSuite is not a PSK CipherSuite
-   [RFC4279], and the server MUST NOT include a gss_api TLS extension in
-   the server hello message.
-
-   If after the exchange of extended ClientHello and extended
-   ServerHello with the gss_api extension, at least one more additional
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 4]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   GSS token is required in order to complete the GSS security context
-   establishment, the additional GSS-API token is encapsulated in a new
-   TLS Handshake message called the token_transfer message.
-
-         enum {
-             token_transfer(TBD), (255)
-         } HandshakeType;
-
-         struct {
-             HandshakeType msg_type;    /* handshake type */
-             uint24 length;             /* bytes in message */
-             select (HandshakeType) {
-                 case token_transfer: /* NEW */
-                       TokenTransfer;
-             } body;
-         } Handshake;
-
-         enum {
-             gss_api_token(1), (255)
-         } TokenTransferType;
-
-         struct {
-               TokenTransferType token_type; /* token type */
-               opaque token<0..2^16-1>;
-         } TokenTransfer;
-
-   The TokenTransfer structure is filled out as follows:
-
-   o  The token_type is gss_api_token.
-
-   o  The token field contains the GSS-API context establishment tokens
-      from the client and the server.
-
-   The client calls GSS_Init_sec_context() with the token in the
-   TokenTransfer stucture from the server as the input token, and then
-   places the output token, if any, into the TokenTransfer message and
-   sends the handshake message to the server.  The server calls
-   GSS_Accept_sec_context() with the token in the TokenTransfer
-   structure from the client as the input token, and then places the
-   output token, if any, into the TokenTransfer message and sends the
-   handshake message to the client.
-
-   This loop repeats until either the context fails to establish or the
-   context is established successfully.  To prevent an infinite loop,
-   both the client and the server MUST have a policy to limit the
-   maximum number of GSS-API context establishment calls for a given
-   session.  The recommended value is a total of five (5) calls
-   including the GSS_Init_sec_context() and GSS_Accept_sec_context()
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 5]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   from both the client and server.  Exceeding the maximum number of
-   calls is to be treated as a GSS security context establishment
-   failure.  It is RECOMMENDED that the client and server enforce the
-   same maximum number
-
-   If the GSS-API context fails to establish, it is a matter of local
-   policy whether to continue or reject the TLS authentication as if the
-   gss_api TLS extension is not supported.
-
-   When the last GSS-API context establishment token is sent by the
-   client or when the GSS-API context fails to establish on the client
-   side and the local policy allows the TLS authentication to proceed as
-   if the TLS gss_api extension is not supported, the client sends an
-   empty TokenTransfer handshake message.
-
-   If the GSS-API context fails to establish and local policy allows the
-   TLS authentication continue as if the gss_api TLS extension is not
-   supported, the server MAY send another ServerHello message in order
-   to choose a different cipher suite.  The client then MUST expect the
-   second ServerHello message from the server before the session is
-   established.  The additional ServerHello message MUST only differ
-   from the first ServerHello message in the choice of CipherSuite and
-   it MUST NOT include a TLS gss_api extension.  The second ServerHello
-   MUST NOT be present if there is no TokenTransfer message.
-
-   If the client and the server establish a security context
-   successfully, both the client and the server call GSS_Pseudo_random()
-   [RFC4401] to compute a sufficiently long shared secret with the same
-   value based on the negotiated cipher suite (see details below), and
-   then proceed according to [RFC4279] using this shared secret value as
-   the "PSK".
-
-   When the shared key is established using a GSS-API mechanism as
-   described in this document, the identity of the server and the
-   identity of the client MUST be obtained from the GSS security
-   context.  In this case, the PSK identity MUST be processed as
-   follows:
-
-   o  The PSK identity as defined in Section 5.1 of [RFC4279] MUST be
-      specified as an empty string.
-
-   o  If the server key exchange message is present, the PSK identity
-      hint as defined in Section 5.2 of [RFC4279] MUST be empty, and it
-      MUST be ignored by the client.
-
-   The input parameters to GSS_Pseudo_random() to compute the shared
-   secret value MUST be provided as follows:
-
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 6]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   o  The context is the handle to the GSS-API context established in
-      the given session.
-
-   o  The prf_key is GSS_C_PRF_KEY_FULL.
-
-   o  The prf_in contains the UTF8 encoding of the string "GSS-API TLS
-      PSK".
-
-   o  The desired_output_len is 64.  In other words, the output keying
-      mastering size is 64 in bytes.  Note that this is the maximum PSK
-      length required to be supported by implementations conforming to
-      [RFC4279].
-
-   The following text art summaries the protocol message flow.
-
-
-        Client                                               Server
-
-        ClientHello                -------->
-                                  <--------*            ServerHello
-        TokenTransfer*             -------->
-                                  <--------          TokenTransfer*
-                                       .
-                                       .
-                                       .
-        TokenTransfer*             -------->
-                                                       ServerHello*
-                                                       Certificate*
-                                                 ServerKeyExchange*
-                                                CertificateRequest*
-                                  <--------         ServerHelloDone
-        Certificate*
-        ClientKeyExchange
-        CertificateVerify*
-        [ChangeCipherSpec]
-        Finished                   -------->
-                                                 [ChangeCipherSpec]
-                                  <--------                Finished
-        Application Data          <-------->       Application Data
-        
-          Fig. 1. Message flow for a full handshake
-
-       * Indicates optional or situation-dependent messages that are 
-         not always sent.
-
-
-   There could be multiple TokenTransfer handshake messages, and the
-   last TokenTransfer message, if present, is always sent from the
-   client to the server and it can carry an empty token.
-
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 7]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-4.  Choosing GSS-API Mechanisms
-
-   If more than one GSS-API mechanism is shared between the client and
-   the server, it is RECOMMENDED to deploy a pseudo GSS-API mechanism
-   such as [RFC4178] to choose a mutually preferred GSS-API mechanism.
-
-   When Kerberos is selected as the GSS-API mechanism, the extensions
-   defined in [KRB-ANON] can perform server authentication without
-   client authentication, thus provide the functional equivalence to the
-   certificate-based TLS [RFC4346].
-
-   If the Kerberos client does not have access to the KDC but the server
-   does, [IAKERB] can be chosen to tunnel the Kerberos authentication
-   exchange within the TLS handshake messages.
-
-
-5.  Client Authentication
-
-   If the GSS-API mechanism in the gss_api TLS extension provides client
-   authentication [RFC2743], the CertificateRequest, the client
-   Certificate and the CertificateVerify handshake messages MUST NOT be
-   present.  This is illustrated in Appendix A.
-
-
-6.  Protecting GSS-API Authentication Data
-
-   GSS-API [RFC2743] provides security services to callers in a generic
-   fashion, supportable with a range of underlying mechanisms and
-   technologies and hence allowing source-level portability of
-   applications to different environments.  For example, Kerberos is a
-   GSS-API mechanism defined in [RFC4121].  It is possible to design a
-   GSS-API mechanism that can be used with FKA-TLS in order to, for
-   example, provide client authentication, and is so weak that its GSS-
-   API token MUST NOT be in clear text over the open network.  A good
-   example is a GSS-API mechanism that implements basic authentication.
-   Although such mechanisms are unlikely to be standardized and will be
-   encouraged in no circumstance, they exist for practical reasons.  In
-   addition, it is generally beneficial to provide privacy protection
-   for mechanisms that send client identities in the clear.
-
-   In order to provide a standard way for protecting weak GSS-API data
-   for use over FKA-TLS, TLSWrap is defined in this section as a pseudo
-   GSS-API mechanism that wraps around the real GSS-API authentication
-   context establishment tokens.  This pseudo GSS-API mechanism does not
-   provide per-message security.  The real GSS-API mechanism protected
-   by TLSWrap may provide per-message security after the context is
-   established.
-
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 8]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   The syntax of the initial TLSWrap token follows the
-   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
-   TLSWrap pseudo mechanism is identified by the Object Identifier
-   iso.org.dod.internet.security.mechanism.tls-wrap (1.3.6.1.5.5.16).
-   Subsequent TLSWrap tokens MUST NOT be encapsulated in this GSS-API
-   generic token framing.
-
-   TLSWrap encapsulates the TLS handshake and data protection in its
-   context establishment tokens.
-
-   The innerContextToken [RFC2743] for the initial TLSWrap context token
-   contains the ClientHello message encoded according to [RFC4346].  No
-   PSK ciphersuite can be included in the client hello message.  The
-   targ_name is used by the client to identify the server and it follows
-   the name forms defined in Section 4 of [PKU2U].
-
-   Upon receipt of the initial TLSWrap context token, the GSS-API server
-   processes the client hello message.  The output GSS-API context token
-   for TLSWrap contains the ServerHello message and the ServerHelloDone
-   potentially with the optional handshake messages in the order as
-   defined in [RFC4346].
-
-   The GSS-API client then processes the server reply and returns the
-   ClientKeyExchange message and the Finished message potentially with
-   the optional handshake messages in the order as defined in [RFC4346].
-   The client places the real GSS-API authentication mechanism token as
-   an application data record right after the TLS Finished message in
-   the same GSS-API context token for TLSWrap.  Because the real
-   mechanism token is placed after the ChangeCipherSpec message, the
-   GSS-API data for the real mechanism is encrypted.  If the GSS-API
-   server is not authenticated at this point of the TLS handshake for
-   TLSWrap, the TLSWrap context establishment MUST fail and the real
-   authentication mechanism token MUST not be returned.
-
-   The GSS-API server in turn processes the client reply and returns the
-   TLS Finished message, the server places the reply token from the real
-   authentication mechanism, if present, as an application data record.
-
-   If additional TLS messages are needed before the application data,
-   these additional TLS messages are encapsulated in the context token
-   of TLSWrap in the same manner how the client hello message and the
-   server hello message are encapsulated as described above.
-
-   If additional tokens are required by the real authentication
-   mechanism in order to establish the context, these tokens are placed
-   as an application data record, encoded according to [RFC4346] and
-   then returned as TLSWrap GSS-API context tokens, with one TLSWrap
-   context token per each real mechanism context token.  The real
-
-
-
-Zhu, et al.             Expires January 26, 2008                [Page 9]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   mechanism context tokens are decrypted by TLSWrap and then supply to
-   the real mechanism to complete the context establishment.
-
-
-7.  Security Considerations
-
-   As described in Section 3, when the shared key is established using a
-   GSS-API mechanism as described in this document, the identity of the
-   server MUST be obtained from the GSS security context and the
-   identity of the client MUST be obtained from the GSS security
-   context.  Authentication methods such as GSS security context and
-   X.509 certificate mixed MUST NOT conflict.  Such confusion about the
-   identity will interfere with the ability to properly determine the
-   client's authorization privileges, thus potentially result in a
-   security weakness.
-
-   When Kerberos as defined in [RFC4120] is used to establish the share
-   key, it is vulnerable to offline dictionary attacks.  The threat is
-   mitigated by deploying Kerberos FAST [KRB-FAST].
-
-   Shared symmetric keys obtained from mutual calls to
-   GSS_Pseudo_random() are not susceptible to off-line dictionary
-   attacks in the same way that traditional pre-shared keys are.  The
-   strength of the generated keys are determined based upon the security
-   properties of the selected GSS mechanism.  Implementers MUST take
-   into account the Security Considerations associated with the GSS
-   mechanisms they decide to support.
-
-
-8.  Acknowledgements
-
-   Ari Medvinsky was one of the designers of the original TLS Kerberos
-   version 5 CipherSuite and contributed to the first two revisions of
-   this protocol specification.
-
-   Raghu Malpani provided insightful comments and was very helpful along
-   the way.
-
-   Ryan Hurst contributed significantly to the use cases of FKA-TLS.
-
-   Love Hornquist Astrand, Nicolas Williams and Martin Rex provided
-   helpful comments while reviewing early revisions of this document.
-
-
-9.  IANA Considerations
-
-   A new handshake message token_transfer is defined according to
-   [RFC4346] and a new TLS extension called the gss_api extension is
-
-
-
-Zhu, et al.             Expires January 26, 2008               [Page 10]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   defined according to [RFC3546].  The registry needs to be updated to
-   include these new types.
-
-   This document defines the type of the transfer tokens in Section 3, a
-   registry need to be setup and the allocation policy is "Specification
-   Required".
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2743]  Linn, J., "Generic Security Service Application Program
-              Interface Version 2, Update 1", RFC 2743, January 2000.
-
-   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 3546, June 2003.
-
-   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
-              Simple and Protected Generic Security Service Application
-              Program Interface (GSS-API) Negotiation Mechanism",
-              RFC 4178, October 2005.
-
-   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
-              Extension for the Generic Security Service Application
-              Program Interface (GSS-API)", RFC 4401, February 2006.
-
-10.2.  Informative References
-
-   [IAKERB]   Zhu, L., "Initial and Pass Through Authentication Using
-              Kerberos V5 and the GSS-API", draft-zhu-ws-kerb-03.txt
-              (work in progress), 2007.
-
-   [KRB-ANON]
-              Zhu, L. and P. Leach, "Kerberos Anonymity Support",
-              draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
-
-
-
-
-Zhu, et al.             Expires January 26, 2008               [Page 11]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   [KRB-FAST]
-              Zhu, L. and S. Hartman, "A Generalized Framework for
-              Kerberos Pre-Authentication",
-              draft-ietf-krb-wg-preauth-framework-06.txt (work in
-              progress), 2007.
-
-   [PKU2U]    Zhu, L., Altman, J., and A. Medvinsky, "Public Key
-              Cryptography Based User-to-User Authentication - (PKU2U)",
-              draft-zhu-pku2u-02.txt (work in progress), 2007.
-
-   [RFC2487]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
-              TLS", RFC 2487, January 1999.
-
-   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
-              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
-              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
-              A., Peterson, J., Sparks, R., Handley, M., and E.
-              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
-              June 2002.
-
-   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
-              Protocol (XMPP): Core", RFC 3920, October 2004.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
-              Version 5 Generic Security Service Application Program
-              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
-              July 2005.
-
-   [RFC4402]  Williams, N., "A Pseudo-Random Function (PRF) for the
-              Kerberos V Generic Security Service Application Program
-              Interface (GSS-API) Mechanism", RFC 4402, February 2006.
-
-   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP): Technical Specification Road Map", RFC 4510,
-              June 2006.
-
-   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
-              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
-
-
-
-Zhu, et al.             Expires January 26, 2008               [Page 12]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
-              Kerberos and NTLM HTTP Authentication in Microsoft
-              Windows", RFC 4559, June 2006.
-
-
-Appendix A.  An FKA-TLS Example: Kerberos TLS
-
-   This section provides a non-normative description of the message flow
-   when Kerberos Version 5 is used to established the shared secret
-   according to [RFC4121] and that shared secret is then used to secure
-   the TLS connection according to FKA-TLS defined in this document.
-
-          
-          Client                                               Server
-
-          ClientHello(with AP-REQ)  -------->
-                                             ServerHello(with AP-REP)
-                                   <--------          ServerHelloDone
-          ClientKeyExchange
-          [ChangeCipherSpec]
-          Finished                  -------->
-                                                   [ChangeCipherSpec]
-                                   <--------                Finished
-          Application Data         <-------->       Application Data
-
-             Fig. 2. Kerberos FKA-TLS example message flow
-
-
-   In this successful authentication sample, the TLS client sends the
-   Kerberos AP-REQ [RFC4120] in the inital context token according to
-   [RFC4121].  The initial GSS-API context token from the GSS-API client
-   contains the Object Identifier that signifies the Kerberos mechanism
-   and it is encapsulated in the gss_api TLS extension in the client
-   hello message.  The TLS client always requests mutual authentication,
-   and the TLS server then sends a GSS-API context token that contains
-   the AP-REP [RFC4120] according to [RFC4121].  The TLS server's GSS-
-   API context token is encapsulated in the gss_api TLS extension in the
-   server hello message.  The GSS-API context is established at that
-   point and both sides can derive the shared secret value according to
-   [RFC4402].
-
-   In this example, the ServerKeyExchange handshake message is not
-   needed and it is not present.  And according to Section 5 none of the
-   CertificateRequest, the client Certificate or the CertificateVerify
-   handshake messages is present.
-
-
-Appendix B.  Additional Use Cases for FXA-TLS
-
-   TLS runs on layers beneath a wide range of application protocols such
-
-
-
-Zhu, et al.             Expires January 26, 2008               [Page 13]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   as LDAP [RFC4510], SMTP [RFC2487], and XMPP [RFC3920] and above a
-   reliable transport protocol.  TLS can add security to any protocol
-   that uses reliable connections (such as TCP).  TLS is also
-   increasingly being used as the standard method for protecting SIP
-   [RFC3261] application signaling.  TLS can provide authentication and
-   encryption of the SIP signaling associated with VOIP (Voice over IP)
-   and other SIP-based applications.
-
-   Today these applications use public key certificates to verify the
-   identity of endpoints.
-
-   However, it is overwhelmingly complex to manage the assurance level
-   of the certificates when deploying PKI and such complexity has
-   gradually eroded the confidence for the PKI-based systems in general.
-   In addition, the perceived overhead of deploying and managing
-   certificates is fairly high.  As a result, the industry badly needs
-   the ability to secure TLS connections by leveraging the existing
-   credential infrastructure.  For many customers that means Kerberos.
-   It is highly desirable to enable PKI-less deployments yet still offer
-   strong authentication.
-
-   Having Kerberos/GSS-API in the layer above TLS means all TLS
-   applications need to be changed in the protocol level.  In many
-   cases, such changes are not technically feasible.  For example,
-   [RFC4559] provides integration with Kerberos in the HTTP level.  It
-   suffers from a couple of drawbacks, most notably it only supports
-   single-round-trip GSS-API mechanisms and it lacks of channel bindings
-   to the underlying TLS connection which makes in unsuitable for
-   deployment in situations where proxies exists.  Furthermore,
-   [RFC4559] lacks of session-based re-authentication (comparing with
-   TLS).  The root causes of these problems are inherent to the HTTP
-   protocol and can't be fixed trivially.
-
-   Consequently, It is a better solution to integrate Kerberos/GSS-API
-   in the TLS layer.  Such integration allows the existing
-   infrastructure work seamlessly with TLS for the products based on
-   them in ways that were not practical to do before.  For instance, an
-   increasing number of client and server products support TLS natively,
-   but many still lack support.  As an alternative, users may wish to
-   use standalone TLS products that rely on being able to obtain a TLS
-   connection immediately, by simply connecting to a separate port
-   reserved for the purpose.  For example, by default the TCP port for
-   HTTPS is 443, to distinguish it from HTTP on port 80.  TLS can also
-   be used to tunnel an entire network stack to create a VPN, as is the
-   case with OpenVPN.  Many vendors now marry TLS's encryption and
-   authentication capabilities with authorization.  There has also been
-   substantial development since the late 1990s in creating client
-   technology outside of the browser to enable support for client/server
-
-
-
-Zhu, et al.             Expires January 26, 2008               [Page 14]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-   applications.  When compared against traditional IPSec VPN
-   technologies, TLS has some inherent advantages in firewall and NAT
-   traversal that make it easier to administer for large remote-access
-   populations.
-
-   PSK-TLS as defined in [RFC4279] is a good start but this document
-   finishes the job by making it more deployable.  FKA-TLS also fixes
-   the mutual-authentication problem in [RFC4279] in the cases where the
-   PSK can be shared among services on the same host.
-
-
-Authors' Addresses
-
-   Larry Zhu
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: lzhu@microsoft.com
-
-
-   Girish Chander
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   US
-
-   Email: gchander@microsoft.com
-
-
-   Jeffrey Altman
-   Secure Endpoints Inc.
-   255 W 94th St
-   New York, NY  10025
-   US
-
-   Email: jaltman@secure-endpoints.com
-
-
-   Stefan Santesson
-   Microsoft Corporation
-   Tuborg Boulevard 12
-   2900 Hellerup, WA
-   Denmark
-
-   Email: stefans@microsoft.com
-
-
-
-
-Zhu, et al.             Expires January 26, 2008               [Page 15]
-
-Internet-Draft                   FKA-TLS                       July 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Zhu, et al.             Expires January 26, 2008               [Page 16]
-
-
diff --git a/doc/protocol/draft-santesson-tls-supp-00.txt b/doc/protocol/draft-santesson-tls-supp-00.txt
deleted file mode 100644
index 7c72a91a0e..0000000000
--- a/doc/protocol/draft-santesson-tls-supp-00.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346
-Intended Category: Standards track
-Expires September 2006                                        March 2006
-
-
-              TLS Handshake Message for Supplemental Data
-                   <draft-santesson-tls-supp-00.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This specification specifies a TLS handshake message for exchange of
-   supplemental application data.  TLS hello message extensions are used
-   to determine which supplemental data types are supported by both the
-   TLS client and the TLS server.  Then, the supplemental data handshake
-   message is used to exchange the data.  Other documents will define
-   the syntax of these extensions and the syntax of the associated
-   supplemental data types.
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 1]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    March 2006
-
-
-1.  Introduction
-
-   Recent standards activities have proposed different mechanisms for
-   transmitting supplemental application data in the TLS handshake
-   message.  For example, recent proposals transfer data that is not
-   processed by the TLS protocol itself, but assist the TLS-protected
-   application in the authentication and authorization decisions.  One
-   proposal transfers user name hints for locating credentials, and
-   another proposal transfers attribute certificates and SAML assertions
-   for authorization checks.
-
-   In order to avoid definition of multiple handshake messages, one for
-   each new type of application specific supplemental data, this
-   specification defines a new handshake message type that bundles all
-   such data objects together and sends them in a single handshake
-   message.
-
-1.1  Terminology
-
-   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 [STDWORDS].
-
-   The syntax for the supplemental_data handshake message is defined
-   using the TLS Presentation Language, which is specified in Section 4
-   of [N2].
-
-2  Supplemental Data Handshake Message
-
-   The new supplemental_data handshake message type is defined to
-   accommodate communication of supplemental data objects as agreed
-   during the exchange of extensions in the client and server hello
-   messages.  See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3]
-   for other handshake message types.
-
-
-      enum {
-             supplemental_data(TBD), (255)
-         } HandshakeType;
-
-      struct {
-             HandshakeType msg_type;    /* handshake type */
-             uint24 length;             /* octets in message */
-             select (HandshakeType) {
-                    case supplemental_data:   SupplementalData;
-               } body;
-          } Handshake;
-
-
-
-
-Santesson                                                       [Page 2]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    March 2006
-
-
-      struct {
-            SupplementalDataEntry supp_data<1..2^24-1>;
-         } SupplementalData;
-
-      struct {
-            SupplementalDataType supp_data_type;
-            select(SupplementalDataType) { }
-         } SupplementalDataEntry;
-
-      enum {
-            (65535)
-        } SupplementalDataType;
-
-
-   If present, the SupplementalData handshake message MUST contain a non
-   empty SupplementalDataEntry structure carrying data associated with
-   at least one defined SupplementalDataType.  An explicit agreement
-   that governs presence of any associated data MUST be concluded
-   between client and server for each SupplementalDataType. This
-   agreement MUST be concluded through the use of TLS extensions in the
-   client and server hello messages.
-
-   Other documents will specify specific SupplementalDataType and their
-   associated data syntax and processing.  These same specifications
-   must also specify the client and server hello message extensions that
-   are used to negotiate the support for the specified supplemental data
-   type.  This document simply specifies the TLS Handshake Protocol
-   message that will carry the supplemental data objects.
-
-   Different situations require the transfer of supplemental data from
-   the client to the server, require the transfer of supplemental data
-   from server to the client, or require the transfer of supplemental
-   data from the client to the server as well as the transfer from the
-   server to the client.  All three situations are fully supported.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 3]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    March 2006
-
-
-4  Message flow
-
-   The SupplementalData handshake message, if exchanged, MUST be sent as
-   the first handshake message as illustrated in Figure 1 below.
-
-      Client                                               Server
-
-      ClientHello (with extensions) -------->
-
-                                     ServerHello(with extensions)
-                                                SupplementalData*
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      SupplementalData*
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-        *  Indicates optional or situation-dependent messages.
-
-               Figure 1.  Message flow with SupplementalData
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 4]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    March 2006
-
-
-5  Security Considerations
-
-   Each SupplementalDataType included in the handshake message defined
-   in this specification introduces its own unique set of security
-   properties and related considerations.  Security considerations must
-   therefore be defined in each document that defines a supplemetal data
-   type.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 5]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    March 2006
-
-
-6  Normative References
-
-   [N1]        S. Bradner, "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]        T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-               RFC 2246, January 1999.
-
-   [N3]        T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-               RFC 4346, January 2006.
-
-   [N4]        S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-               T. Wright, "Transport Layer Security (TLS) Extensions",
-               RFC 4366, February 2006.
-
-
-7 IANA Considerations
-
-   IANA needs to establish a registry for TLS Supplemental Data Formats.
-   TLS Authorization Data Format identifiers with values in the
-   inclusive range 0-16385 (decimal) are assigned via RFC 2434 [IANA]
-   Standards Action.  Values from the inclusive range 16385-65279
-   (decimal) are assigned via RFC 2434 Specification Required.  Values
-   from the inclusive range 65280-65535 (decimal) are reserved for RFC
-   2434 Private Use.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 6]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    March 2006
-
-
-Author's Address
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans(at)microsoft.com
-
-
-Acknowledgements
-
-   The fundamental architectural idea for the supplemental data
-   handshake message was provided by Russ Housley and Eric Rescorla.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 7]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    March 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires September 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 8]
diff --git a/doc/protocol/draft-santesson-tls-supp-01.txt b/doc/protocol/draft-santesson-tls-supp-01.txt
deleted file mode 100644
index f0528f7b70..0000000000
--- a/doc/protocol/draft-santesson-tls-supp-01.txt
+++ /dev/null
@@ -1,448 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346
-Intended Category: Standards track
-Expires October 2006                                          April 2006
-
-
-              TLS Handshake Message for Supplemental Data
-                   <draft-santesson-tls-supp-01.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This specification specifies a TLS handshake message for exchange of
-   supplemental application data.  TLS hello message extensions are used
-   to determine which supplemental data types are supported by both the
-   TLS client and the TLS server.  Then, the supplemental data handshake
-   message is used to exchange the data.  Other documents will define
-   the syntax of these extensions and the syntax of the associated
-   supplemental data types.
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 1]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-1.  Introduction
-
-   Recent standards activities have proposed different mechanisms for
-   transmitting supplemental application data in the TLS handshake
-   message.  For example, recent proposals transfer data that is not
-   processed by the TLS protocol itself, but assist the TLS-protected
-   application in the authentication and authorization decisions.  One
-   proposal transfers user name hints for locating credentials, and
-   another proposal transfers attribute certificates and SAML assertions
-   for authorization checks.
-
-   In order to avoid definition of multiple handshake messages, one for
-   each new type of application specific supplemental data, this
-   specification defines a new handshake message type that bundles all
-   such data objects together and sends them in a single handshake
-   message.
-
-1.1  Terminology
-
-   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 [STDWORDS].
-
-   The syntax for the supplemental_data handshake message is defined
-   using the TLS Presentation Language, which is specified in Section 4
-   of [N2].
-
-2  Supplemental Data Handshake Message
-
-   The new supplemental_data handshake message type is defined to
-   accommodate communication of supplemental data objects as agreed
-   during the exchange of extensions in the client and server hello
-   messages.  See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3]
-   for other handshake message types.
-
-
-      enum {
-             supplemental_data(TBD), (255)
-         } HandshakeType;
-
-      struct {
-             HandshakeType msg_type;    /* handshake type */
-             uint24 length;             /* octets in message */
-             select (HandshakeType) {
-                    case supplemental_data:   SupplementalData;
-               } body;
-          } Handshake;
-
-
-
-
-Santesson                                                       [Page 2]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-      struct {
-            SupplementalDataEntry supp_data<1..2^24-1>;
-         } SupplementalData;
-
-      struct {
-            SupplementalDataType supp_data_type;
-            select(SupplementalDataType) { }
-         } SupplementalDataEntry;
-
-      enum {
-            (65535)
-        } SupplementalDataType;
-
-
-   If present, the SupplementalData handshake message MUST contain a
-   non-empty SupplementalDataEntry structure carrying data associated
-   with at least one defined SupplementalDataType.  An explicit
-   agreement that governs presence of any supplemental data MUST be
-   concluded between client and server for each SupplementalDataType
-   using the TLS extensions in the client and server hello messages.
-
-   Other documents will specify specific SupplementalDataType and their
-   associated data syntax and processing.  These same specifications
-   must also specify the client and server hello message extensions that
-   are used to negotiate the support for the specified supplemental data
-   type.  This document simply specifies the TLS Handshake Protocol
-   message that will carry the supplemental data objects.
-
-   Different situations require the transfer of supplemental data from
-   the client to the server, require the transfer of supplemental data
-   from server to the client, or require the transfer of supplemental
-   data from the client to the server as well as the transfer from the
-   server to the client.  All three situations are fully supported.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 3]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-4  Message flow
-
-   The SupplementalData handshake message, if exchanged, MUST be sent as
-   the first handshake message as illustrated in Figure 1 below.
-
-      Client                                               Server
-
-      ClientHello (with extensions) -------->
-
-                                     ServerHello(with extensions)
-                                                SupplementalData*
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      SupplementalData*
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-        *  Indicates optional or situation-dependent messages.
-
-               Figure 1.  Message flow with SupplementalData
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 4]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-5  Security Considerations
-
-   Each SupplementalDataType included in the handshake message defined
-   in this specification introduces its own unique set of security
-   properties and related considerations.  Security considerations must
-   therefore be defined in each document that defines a supplemetal data
-   type.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 5]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-6  Normative References
-
-   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-             RFC 2246, January 1999.
-
-   [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-             RFC 4346, January 2006.
-
-   [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-             T. Wright, "Transport Layer Security (TLS) Extensions",
-             RFC 4366, February 2006.
-
-   [N5]      T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-             Considerations Section in RFCs", RFC 2434, October 1998
-
-
-7 IANA Considerations
-
-   IANA needs to take the following actions:
-
-   1) Create an entry, supplemental_data(TBD), in the existing registry
-   for HandshakeType (defined in RFC 2246 [N2]).
-
-   2) Establish a registry for TLS Supplemental Data Formats
-   (SupplementalDataType). Values in the inclusive range 0-16385
-   (decimal) are assigned via RFC 2434 [N5] Standards Action.  Values
-   from the inclusive range 16386-65279 (decimal) are assigned via RFC
-   2434 Specification Required.  Values from the inclusive range
-   65280-65535 (decimal) are reserved for RFC 2434 Private Use.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 6]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-Author's Address
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans(at)microsoft.com
-
-
-Acknowledgements
-
-   The fundamental architectural idea for the supplemental data
-   handshake message was provided by Russ Housley and Eric Rescorla.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 7]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires October 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 8]
diff --git a/doc/protocol/draft-santesson-tls-supp-02.txt b/doc/protocol/draft-santesson-tls-supp-02.txt
deleted file mode 100644
index ac214d3356..0000000000
--- a/doc/protocol/draft-santesson-tls-supp-02.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346
-Intended Category: Standards track
-Expires October 2006                                          April 2006
-
-
-              TLS Handshake Message for Supplemental Data
-                   <draft-santesson-tls-supp-02.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This specification specifies a TLS handshake message for exchange of
-   supplemental application data.  TLS hello message extensions are used
-   to determine which supplemental data types are supported by both the
-   TLS client and the TLS server.  Then, the supplemental data handshake
-   message is used to exchange the data.  Other documents will define
-   the syntax of these extensions and the syntax of the associated
-   supplemental data types.
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 1]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-1.  Introduction
-
-   Recent standards activities have proposed different mechanisms for
-   transmitting supplemental application data in the TLS handshake
-   message.  For example, recent proposals transfer data that is not
-   processed by the TLS protocol itself, but assist the TLS-protected
-   application in the authentication and authorization decisions.  One
-   proposal transfers user name hints for locating credentials, and
-   another proposal transfers attribute certificates and SAML assertions
-   for authorization checks.
-
-   In order to avoid definition of multiple handshake messages, one for
-   each new type of application specific supplemental data, this
-   specification defines a new handshake message type that bundles all
-   data objects, that are to be delivered to the TLS-protected
-   application, together and sends them in a single handshake message.
-
-
-1.1  Terminology
-
-   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 [STDWORDS].
-
-   The syntax for the supplemental_data handshake message is defined
-   using the TLS Presentation Language, which is specified in Section 4
-   of [N2].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 2]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-2  Supplemental Data Handshake Message
-
-   The new supplemental_data handshake message type is defined to
-   accommodate communication of supplemental data objects as agreed
-   during the exchange of extensions in the client and server hello
-   messages.  See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3]
-   for other handshake message types.
-
-   Information provided in a supplemental data object MUST be intended
-   to be used exclusively by applications and protocols above the TLS
-   protocol layer. Any such data MUST NOT need to be processed by the
-   TLS protocol.
-
-
-      enum {
-             supplemental_data(TBD), (255)
-         } HandshakeType;
-
-      struct {
-             HandshakeType msg_type;    /* handshake type */
-             uint24 length;             /* octets in message */
-             select (HandshakeType) {
-                    case supplemental_data:   SupplementalData;
-               } body;
-          } Handshake;
-
-      struct {
-            SupplementalDataEntry supp_data<1..2^24-1>;
-         } SupplementalData;
-
-      struct {
-            SupplementalDataType supp_data_type;
-            select(SupplementalDataType) { }
-         } SupplementalDataEntry;
-
-      enum {
-            (65535)
-        } SupplementalDataType;
-
-   The client MUST NOT send more than one SupplementalData handshake
-   message, and the server MUST NOT send more than one SupplementalData
-   handshake message.  Receiving more than one SupplementalData
-   handshake message results in a fatal error, and the receiver MUST
-   close the connection with a fatal unexpected_message alert.
-
-   If present, the SupplementalData handshake message MUST contain a
-   non-empty SupplementalDataEntry structure carrying data associated
-   with at least one defined SupplementalDataType.  An explicit
-
-
-
-Santesson                                                       [Page 3]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-   agreement that governs presence of any supplemental data MUST be
-   concluded between client and server for each SupplementalDataType
-   using the TLS extensions in the client and server hello messages.
-   Receiving an unexpected SupplementalData handshake message results in
-   a fatal error, and the receiver MUST close the connection with a
-   fatal unexpected_message alert.
-
-   Other documents will specify specific SupplementalDataType and their
-   associated data syntax and processing.  These same specifications
-   must also specify the client and server hello message extensions that
-   are used to negotiate the support for the specified supplemental data
-   type.  This document simply specifies the TLS Handshake Protocol
-   message that will carry the supplemental data objects.
-
-   Different situations require the transfer of supplemental data from
-   the client to the server, require the transfer of supplemental data
-   from server to the client, or require the transfer of supplemental
-   data from the client to the server as well as the transfer from the
-   server to the client.  All three situations are fully supported.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 4]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-4  Message flow
-
-   The SupplementalData handshake message, if exchanged, MUST be sent as
-   the first handshake message as illustrated in Figure 1 below.
-
-     Client                                               Server
-
-     ClientHello (with extensions) -------->
-
-                                    ServerHello(with extensions)
-                                               SupplementalData*
-                                                    Certificate*
-                                              ServerKeyExchange*
-                                             CertificateRequest*
-                                  <--------      ServerHelloDone
-
-     SupplementalData*
-     Certificate*
-     ClientKeyExchange
-     CertificateVerify*
-     [ChangeCipherSpec]
-     Finished                     -------->
-                                              [ChangeCipherSpec]
-                                  <--------             Finished
-     Application Data             <------->     Application Data
-
-       *  Indicates optional or situation-dependent messages.
-
-               Figure 1.  Message flow with SupplementalData
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 5]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-5  Security Considerations
-
-   Each SupplementalDataType included in the handshake message defined
-   in this specification introduces its own unique set of security
-   properties and related considerations.  Security considerations must
-   therefore be defined in each document that defines a supplemetal data
-   type.
-
-   In some cases the SupplementalData information may be sensitive. The
-   double handshake technique can be used to provide protection for the
-   SupplementalData information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   extensions, but it does result in protected communications.  Then, a
-   second handshake that includes the SupplementalData information is
-   performed using the protected communications.  In Figure 2, the
-   number on the right side indicates the amount of protection for the
-   TLS message on that line.  A zero (0) indicates that there is no
-   communication protection; a one (1) indicates that protection is
-   provided by the first TLS session; and a two (2) indicates that
-   protection is provided by both TLS sessions.
-
-   The placement of the SupplementalData message in the TLS Handshake
-   results in the server providing its SupplementalData information
-   before the client is authenticated.  In many situations, servers will
-   not want to provide authorization information until the client is
-   authenticated.  The double handshake illustrated in Figure 2 provides
-   a technique to ensure that the parties are mutually authenticated
-   before either party provides SupplementalData information.
-
-     Client                                                   Server
-
-     ClientHello (no extensions) -------->                            |0
-                                         ServerHello (no extensions)  |0
-                                                        Certificate*  |0
-                                                  ServerKeyExchange*  |0
-                                                 CertificateRequest*  |0
-                                 <--------           ServerHelloDone  |0
-     Certificate*                                                     |0
-     ClientKeyExchange                                                |0
-     CertificateVerify*                                               |0
-     [ChangeCipherSpec]                                               |0
-     Finished                    -------->                            |1
-                                                  [ChangeCipherSpec]  |0
-                                 <--------                  Finished  |1
-     ClientHello (w/ extensions) -------->                            |1
-                                         ServerHello (w/ extensions)  |1
-                                                   SupplementalData*  |1
-                                                        Certificate*  |1
-
-
-
-Santesson                                                       [Page 6]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-                                                  ServerKeyExchange*  |1
-                                                 CertificateRequest*  |1
-                                 <--------           ServerHelloDone  |1
-     SupplementalData*                                                |1
-     Certificate*                                                     |1
-     ClientKeyExchange                                                |1
-     CertificateVerify*                                               |1
-     [ChangeCipherSpec]                                               |1
-     Finished                    -------->                            |2
-                                                  [ChangeCipherSpec]  |1
-                                 <--------                  Finished  |2
-     Application Data            <------->          Application Data  |2
-
-     *  Indicates optional or situation-dependent messages.
-
-          Figure 2. Double Handshake to Protect Supplemental Data
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 7]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-6  Normative References
-
-   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-             RFC 2246, January 1999.
-
-   [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-             RFC 4346, January 2006.
-
-   [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-             T. Wright, "Transport Layer Security (TLS) Extensions",
-             RFC 4366, February 2006.
-
-   [N5]      T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-             Considerations Section in RFCs", RFC 2434, October 1998
-
-
-7 IANA Considerations
-
-   IANA needs to take the following actions:
-
-   1) Create an entry, supplemental_data(TBD), in the existing registry
-   for HandshakeType (defined in RFC 2246 [N2]).
-
-   2) Establish a registry for TLS Supplemental Data Formats
-   (SupplementalDataType). Values in the inclusive range 0-16385
-   (decimal) are assigned via RFC 2434 [N5] Standards Action.  Values
-   from the inclusive range 16386-65279 (decimal) are assigned via RFC
-   2434 IETF Consensus. Values from the inclusive range 65280-65535
-   (decimal) are reserved for RFC 2434 Private Use.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 8]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-Author's Address
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans(at)microsoft.com
-
-
-Acknowledgements
-
-   The fundamental architectural idea for the supplemental data
-   handshake message was provided by Russ Housley and Eric Rescorla.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                       [Page 9]
-
-INTERNET DRAFT TLS Handshake Message for Supplemental Data    April 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires October 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                                                      [Page 10]
diff --git a/doc/protocol/draft-santesson-tls-ume-00.txt b/doc/protocol/draft-santesson-tls-ume-00.txt
deleted file mode 100644
index f2c09e3adb..0000000000
--- a/doc/protocol/draft-santesson-tls-ume-00.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-
-TLS Working Group                               S. Santesson (Microsoft)
-INTERNET-DRAFT                                  A. Medvinsky (Microsoft)
-Intended Category: Informational                     J. Ball (Microsoft)
-Expires June 2006                                          December 2005
-
-
-                       TLS User Mapping Extension
-                    <draft-santesson-tls-ume-00.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This document may not be modified, and derivative works of it may not
-   be created, except to publish it as an RFC and to translate it into
-   languages other than English.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping data in a new handshake message. In particular
-   one such mapping is defined, the UpnDomainHint, which may be used by
-   a server to locate a user in a directory database.
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  User mapping extension ......................................    3
-   3  User mapping handshake protocol .............................    3
-   4  Message flow ................................................    5
-   5  Security Considerations .....................................    6
-   6  References ..................................................    7
-   Appendix A. IPR Disclosure .....................................    8
-   Authors' Addresses .............................................    8
-   Disclaimer .....................................................    9
-   Copyright Statement ............................................    9
-
-1.  Introduction
-
-   This specification documents a TLS extension and a handshake message,
-   which has been defined and implemented by Microsoft to accommodate
-   mapping of users to their user accounts when using TLS client
-   authentication as the authentication method.
-
-   The UPN (User Principal Name) is a name form defined by Microsoft
-   which specifies a user's entry in a directory in the form of
-   userName@domainName.  Traditionally Microsoft has relied on such UPN
-   names to be present in the client certificate when logging on to a
-   domain account.
-
-   This has several drawbacks however since it prevents the use of
-   certificates with an absent UPN and also requires re-issuance of
-   certificates or issuance of multiple certificates to reflect account
-   changes or creation of new accounts.
-
-   The extension defined in this document provide a significant
-   improvement to this situation since 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.
-
-   The new extension (user_mapping) is sent in the Client Hello message.
-   Per convention defined in RFC3546 [N3], the server places the same
-   extension (user_mapping) in the Server Hello message, to inform the
-   client that the server understands this extension. If the server does
-   not understand the extension, it will respond with a non-extended
-   Server Hello message and the client will proceed as normal, ignoring
-   the extension.
-
-   If the new extension is understood, the client will inject a new
-   handshake message prior to the Client's Certificate message. The
-   server will then parse this message, extracting the client's domain,
-   and store it in the context for use when mapping the certificate to
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-   the user's directory account.
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the ClientHello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-   Additionally, if new mapping information were to be considered
-   confidential, the addition of a new handshake message allows the data
-   to be encrypted using the servers public key.
-
-   No other modifications to the protocol are required. The messages are
-   detailed in the following sections.
-
-
-1.1  Terminology
-
-   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 [STDWORDS].
-
-
-2  User mapping extension
-
-   A new extension type (user_mapping(n)) is added to the Extension used
-   in both the Client Hello and Server Hello messages. The extension
-   type is specified as follows and has no data associated with it.
-
-
-      enum {
-           user_mapping(n), (65535)
-      } ExtensionType;
-
-
-3  User mapping handshake protocol
-
-   A new HandshakeType (user_mapping_data) is defined to accommodate
-   communication of generic user mapping data.
-
-   The information in this handshake message carries an unauthenticated
-   hint, inserted by the client side. Upon receipt and successful
-   completion of the TLS handshake, the server MAY use this hint to
-   locate the user's account from which user information and credentials
-   MAY be retrieved to support authentication based on the client
-   certificate.
-
-
-      enum {
-             user_mapping_data(n),(255)
-      } HandshakeType;
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-   The user_mapping_data(n) enumeration results in a new Handshake
-   Message UserMappingData with the following structure:
-
-
-      enum {
-             UpnDomainHint(0), (255)
-      } UserMappingType;
-
-      struct {
-             opaque user_principle_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) {
-                   case UpnDomainHint:
-                        UpnDomainHint;
-             }
-      } UserMappingData;
-
-
-   The user_principal_name parameter, when specified, SHALL be specified
-   in the form:
-
-      user@domain
-
-   For example the UPN 'foo@example.com' represents user 'foo' at domain
-   'example.com'.
-
-   The domain_name parameter, when specified, SHALL contain a domain
-   name in the "preferred name syntax," as specified by RFC 1034 [N4]
-
-   The UpnDomainHint MUST at least contain a non empty
-   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
-   contain both user_principal_name and domain_name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-4  Message flow
-
-   In order to negotiate to send user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension, MAY indicate that they are willing to
-   accept user mapping data by including an extension of type
-   "user_mapping" in the (extended) server hello.  The "extension_data"
-   field of this extension SHALL be empty.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hellos including "user_mapping" extensions),
-   clients MAY send a "UserMappingData" message before the "Certificate"
-   message. The message flow is illustrated in Fig. 1 below.
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      UserMappingData
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow with user mapping data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent according to RFC 2246 [N2].
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-5  Security Considerations
-
-   The UPN sent in the UserMappingData is unauthenticated data that MUST
-   NOT be treated as a trusted identifier. Authentication of the user
-   represented by that UPN MUST rely solely on validation of the client
-   certificate. One way to do this safely is to use the UPN to locate
-   and extract a certificate of the claimed user from a directory and
-   subsequently match this certificate against the validated client
-   certificate from the TLS handshake.
-
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information. It may not be prudent to broadcast this information to
-   just any server at any time, as it can reveal network infrastructure
-   the client and server are using.
-
-   To avoid superfluously sending this information, two techniques
-   SHOULD be used to control its dissemination.
-
-      - The client SHOULD only send the UserMappingData handshake
-        message if it is agreed upon in the Hello exchange, preventing
-        the information from being sent to a server that doesn't
-        understand the User Mapping Extension.
-
-      - The client SHOULD further only send this information if the
-        server belongs to a domain to which the client intends to
-        authenticate using the UPN as identifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-6 References
-
-   Normative references:
-
-   [N1]        S. Bradner, "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]        T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-               RFC 2246, January 1999.
-
-   [N3]        S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-               T. Wright, "Transport Layer Security (TLS) Extensions",
-               RFC 3546, June 2003.
-
-   [N4]        Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-Appendix A. IPR Disclosure
-
-   TBD
-
-Authors' Addresses
-
-
-   Stefan Santesson
-   Microsoft
-   Tuborg Boulevard 12
-   2900 Hellerup
-   Denmark
-
-   EMail: stefans(at)microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   Email: arimed(at)microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   Email: joshball(at)microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT         TLS User Mapping extension          December 2005
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires June 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 9]
diff --git a/doc/protocol/draft-santesson-tls-ume-01.txt b/doc/protocol/draft-santesson-tls-ume-01.txt
deleted file mode 100644
index 903200bbc2..0000000000
--- a/doc/protocol/draft-santesson-tls-ume-01.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-
-TLS Working Group                               S. Santesson (Microsoft)
-INTERNET-DRAFT                                  A. Medvinsky (Microsoft)
-Intended Category: Standards track                   J. Ball (Microsoft)
-Expires July 2006                                           January 2006
-
-
-                       TLS User Mapping Extension
-                    <draft-santesson-tls-ume-01.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This document may not be modified, and derivative works of it may not
-   be created, except to publish it as an RFC and to translate it into
-   languages other than English.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping data in a new handshake message. In particular
-   one such mapping is defined, the UpnDomainHint, which may be used by
-   a server to locate a user in a directory database.
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  User mapping extension ......................................    3
-   3  User mapping handshake protocol .............................    3
-   4  Message flow ................................................    6
-   5  Security Considerations .....................................    7
-   6  References ..................................................    8
-   Appendix A. IPR Disclosure .....................................    9
-   Authors' Addresses .............................................    9
-   Disclaimer .....................................................   10
-   Copyright Statement ............................................   10
-
-1.  Introduction
-
-   This specification documents a TLS extension and a handshake message,
-   which has been defined and implemented by Microsoft to accommodate
-   mapping of users to their user accounts when using TLS client
-   authentication as the authentication method.
-
-   The UPN (User Principal Name) is a name form defined by Microsoft
-   which specifies a user's entry in a directory in the form of
-   userName@domainName.  Traditionally Microsoft has relied on such UPN
-   names to be present in the client certificate when logging on to a
-   domain account.
-
-   This has several drawbacks however since it prevents the use of
-   certificates with an absent UPN and also requires re-issuance of
-   certificates or issuance of multiple certificates to reflect account
-   changes or creation of new accounts.
-
-   The extension defined in this document provide a significant
-   improvement to this situation since 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.
-
-   The new extension (user_mapping) is sent in the Client Hello message.
-   Per convention defined in RFC3546 [N3], the server places the same
-   extension (user_mapping) in the Server Hello message, to inform the
-   client that the server understands this extension. If the server does
-   not understand the extension, it will respond with a Server Hello
-   omitting this extension and the client will proceed as normal,
-   ignoring the extension.
-
-   If the new extension is understood, the client will inject a new
-   handshake message prior to the Client's Certificate message. The
-   server will then parse this message, extracting the client's domain,
-   and store it in the context for use when mapping the certificate to
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-   the user's directory account.
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the ClientHello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-   Additionally, if new mapping information were to be considered
-   confidential, the addition of a new handshake message allows the data
-   to be encrypted using the servers public key.
-
-   No other modifications to the protocol are required. The messages are
-   detailed in the following sections.
-
-
-1.1  Terminology
-
-   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 [STDWORDS].
-
-
-2  User mapping extension
-
-   A new extension type (user_mapping(n)) is added to the Extension used
-   in both the Client Hello and Server Hello messages. The extension
-   type is specified as follows and has no data associated with it.
-
-
-      enum {
-           user_mapping(n), (65535)
-      } ExtensionType;
-
-
-3  User mapping handshake protocol
-
-   A new HandshakeType (user_mapping_data) is defined to accommodate
-   communication of generic user mapping data.
-
-   The information in this handshake message carries an unauthenticated
-   hint, inserted by the client side. Upon receipt and successful
-   completion of the TLS handshake, the server MAY use this hint to
-   locate the user's account from which user information and credentials
-   MAY be retrieved to support authentication based on the client
-   certificate.
-
-
-      enum {
-             user_mapping_data(n),(255)
-      } HandshakeType;
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-   The user_mapping_data(n) enumeration results in a new Handshake
-   Message UserMappingDataList with the following structure:
-
-
-      enum {
-             upn_domain_hint(0), (255)
-      } UserMappingType;
-
-      struct {
-             opaque user_principal_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) {
-                   case upn_domain_hint:
-                        UpnDomainHint;
-             }
-      } UserMappingData;
-
-      struct{
-         UserMappingData user_mapping_data_list<1..2^16-1>;
-      }UserMappingDataList;
-
-
-
-   The user_principal_name parameter, when specified, SHALL be specified
-   in the form:
-
-      user@domain
-
-   For example the UPN 'foo@example.com' represents user 'foo' at domain
-   'example.com'.
-
-   The domain_name parameter, when specified, SHALL contain a domain
-   name in the "preferred name syntax," as specified by RFC 1034 [N4]
-
-   The UpnDomainHint MUST at least contain a non empty
-   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
-   contain both user_principal_name and domain_name.
-
-   The UserMappingData structure contains a single mapping of type
-   UserMappingType.  This structure can be leveraged to define new types
-   of user mapping hints in the future.  The UserMappingDataList MAY
-   carry multiple hints; it is defined as a vector of UserMappingData
-   structures.
-
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-   No preference is given to the order in which hints are specified in
-   this vector.  If the client sends more then one hint then the Server
-   SHOULD use the applicable mapping supported by the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-4  Message flow
-
-   In order to negotiate to send user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension, MAY indicate that they are willing to
-   accept user mapping data by including an extension of type
-   "user_mapping" in the (extended) server hello.  The "extension_data"
-   field of this extension SHALL be empty.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hellos including "user_mapping" extensions),
-   clients MAY send a "UserMappingDataList" message before the
-   "Certificate" message. The message flow is illustrated in Fig. 1
-   below.
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      UserMappingDataList
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow with user mapping data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent according to RFC 2246 [N2].
-
-
-
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-5  Security Considerations
-
-   The UPN sent in the UserMappingDataList is unauthenticated data that
-   MUST NOT be treated as a trusted identifier. Authentication of the
-   user represented by that UPN MUST rely solely on validation of the
-   client certificate. One way to do this safely is to use the UPN to
-   locate and extract a certificate of the claimed user from a directory
-   and subsequently match this certificate against the validated client
-   certificate from the TLS handshake.
-
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information. It may not be prudent to broadcast this information to
-   just any server at any time, as it can reveal network infrastructure
-   the client and server are using.
-
-   To avoid superfluously sending this information, two techniques
-   SHOULD be used to control its dissemination.
-
-      - The client SHOULD only send the UserMappingDataList handshake
-        message if it is agreed upon in the Hello exchange, preventing
-        the information from being sent to a server that doesn't
-        understand the User Mapping Extension.
-
-      - The client SHOULD further only send this information if the
-        server belongs to a domain to which the client intends to
-        authenticate using the UPN as identifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-6 References
-
-   Normative references:
-
-   [N1]        S. Bradner, "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]        T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-               RFC 2246, January 1999.
-
-   [N3]        S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-               T. Wright, "Transport Layer Security (TLS) Extensions",
-               RFC 3546, June 2003.
-
-   [N4]        Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-Appendix A. IPR Disclosure
-
-   TBD
-
-Authors' Addresses
-
-
-   Stefan Santesson
-   Microsoft
-   Tuborg Boulevard 12
-   2900 Hellerup
-   Denmark
-
-   EMail: stefans(at)microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   Email: arimed(at)microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   Email: joshball(at)microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 9]
-
-INTERNET DRAFT         TLS User Mapping extension           January 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires July 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 10]
diff --git a/doc/protocol/draft-santesson-tls-ume-02.txt b/doc/protocol/draft-santesson-tls-ume-02.txt
deleted file mode 100644
index 1a29366825..0000000000
--- a/doc/protocol/draft-santesson-tls-ume-02.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346 (once approved)             A. Medvinsky (Microsoft)
-Intended Category: Standards track                   J. Ball (Microsoft)
-Expires August 2006                                        February 2006
-
-
-                       TLS User Mapping Extension
-                    <draft-santesson-tls-ume-02.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This document may not be modified, and derivative works of it may not
-   be created, except to publish it as an RFC and to translate it into
-   languages other than English.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping data in a new handshake message. One such
-   mapping is defined, the UpnDomainHint, which may be used by a server
-   to locate a user in a directory database. Other mappings may be
-   defined in other documents in the future.
-
-
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  User mapping extension ......................................    3
-   3  User mapping handshake protocol .............................    4
-   4  Message flow ................................................    6
-   5  Security Considerations .....................................    7
-   6  References ..................................................    8
-   7 IANA Considerations ... ......................................    8
-   Authors' Addresses .............................................    9
-   Disclaimer .....................................................   10
-   Copyright Statement ............................................   10
-
-1.  Introduction
-
-   This specification documents a TLS extension and a handshake message,
-   which has been defined and implemented by Microsoft to accommodate
-   mapping of users to their user accounts when using TLS client
-   authentication as the authentication method.
-
-   The UPN (User Principal Name) is a name form defined by Microsoft
-   which specifies a user's entry in a directory in the form of
-   userName@domainName.  Traditionally Microsoft has relied on such UPN
-   names to be present in the client certificate when logging on to a
-   domain account.
-
-   This has several drawbacks however since it prevents the use of
-   certificates with an absent UPN and also requires re-issuance of
-   certificates or issuance of multiple certificates to reflect account
-   changes or creation of new accounts.
-
-   The TLS extension defined in this document provide a significant
-   improvement to this situation since 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.
-
-   The new TLS extension (user_mapping) is sent in the client hello
-   message. Per convention defined in RFC 4366 [N4], the server places
-   the same extension (user_mapping) in the server hello message, to
-   inform the client that the server understands this extension. If the
-   server does not understand the extension, it will respond with a
-   server hello omitting this extension and the client will proceed as
-   normal, ignoring the extension, and not include the
-   UserMappingDataList message in the TLS handshake.
-
-   If the new extension is understood, the client will inject a new
-   handshake message prior to the Client's Certificate message. The
-   server will then parse this message, extracting the client's domain,
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-   and store it in the context for use when mapping the certificate to
-   the user's directory account.
-
-   No other modifications to the protocol are required. The messages are
-   detailed in the following sections.
-
-
-1.1  Terminology
-
-   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 [STDWORDS].
-
-   The syntax for the TLS User Mapping extension is defined using the
-   TLS Presentation Language, which is specified in Section 4 of [N2].
-
-1.2  Design considerations
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the client hello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-   Additionally, if new mapping information were to be considered
-   confidential, the addition of a new handshake message allows the data
-   to be encrypted using the server's public key.
-
-
-2  User mapping extension
-
-   A new extension type (user_mapping(n)) is added to the Extension used
-   in both the client hello and server hello messages. The extension
-   type is specified as follows.
-
-
-      enum {
-           user_mapping(n), (65535)
-      } ExtensionType;
-
-   The "extension_data" field of this extension SHALL contain
-   "UserMappingTypeList" with a list of supported hint types where:
-
-      struct {
-            UserMappingType user_mapping_types<1..2^8-1>
-      } UserMappingTypeList;
-
-   Enumeration of hint types (user_mapping_types) defined in this
-   document is provided in section 3.
-
-   The list of user_mapping_types included in a client hello SHALL
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-   signal the hint types supported by the client. The list of
-   user_mapping_types included in the server hello SHALL signal the hint
-   types preferred by the server.
-
-   If none of the hint types listed by the client is supported by the
-   server, the server SHALL omit the user_mapping extension in the
-   server hello.
-
-   When the user_mapping extension is included in the server hello, the
-   list of hint types in "UserMappingTypeList" SHALL be either equal to,
-   or a subset of, the list provided by the client.
-
-3  User mapping handshake protocol
-
-   A new HandshakeType (user_mapping_data) is defined to accommodate
-   communication of generic user mapping data. See RFC 2246 (TLS 1.0)
-   [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
-
-   The information in this handshake message carries an unauthenticated
-   hint, inserted by the client side. Upon receipt and successful
-   completion of the TLS handshake, the server MAY use this hint to
-   locate the user's account from which user information and credentials
-   MAY be retrieved to support authentication based on the client
-   certificate.
-
-
-      enum {
-             user_mapping_data(n),(255)
-      } HandshakeType;
-
-
-   The user_mapping_data(n) enumeration results in a new Handshake
-   Message UserMappingDataList with the following structure:
-
-
-      enum {
-             upn_domain_hint(0), (255)
-      } UserMappingType;
-
-      struct {
-             opaque user_principal_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) {
-                   case upn_domain_hint:
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-                        UpnDomainHint;
-             }
-      } UserMappingData;
-
-      struct{
-         UserMappingData user_mapping_data_list<1..2^16-1>;
-      }UserMappingDataList;
-
-
-
-   The user_principal_name parameter, when specified, SHALL be specified
-   in the form:
-
-      user@domain
-
-   For example the UPN 'foo@example.com' represents user 'foo' at domain
-   'example.com'.
-
-   The domain_name parameter, when specified, SHALL contain a domain
-   name in the "preferred name syntax," as specified by RFC 1034 [N5]
-
-   The UpnDomainHint MUST at least contain a non empty
-   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
-   contain both user_principal_name and domain_name.
-
-   The UserMappingData structure contains a single mapping of type
-   UserMappingType.  This structure can be leveraged to define new types
-   of user mapping hints in the future.  The UserMappingDataList MAY
-   carry multiple hints; it is defined as a vector of UserMappingData
-   structures.
-
-   No preference is given to the order in which hints are specified in
-   this vector.  If the client sends more then one hint then the Server
-   SHOULD use the applicable mapping supported by the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-4  Message flow
-
-   In order to negotiate to send user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello, which SHALL
-   contain a list of supported hint types.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension, MAY indicate that they are willing to
-   accept user mapping data by including an extension of type
-   "user_mapping" in the (extended) server hello, which SHALL contain a
-   list of preferred hint types.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hello messages including "user_mapping"
-   extensions), clients MAY send a "UserMappingDataList" message before
-   the "Certificate" message. The message flow is illustrated in Fig. 1
-   below.
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      UserMappingDataList
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow with user mapping data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent according to RFC 2246 [N2] and RFC 4346 [N3].
-
-
-
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-5  Security Considerations
-
-   The UPN sent in the UserMappingDataList is unauthenticated data that
-   MUST NOT be treated as a trusted identifier. Authentication of the
-   user represented by that UPN MUST rely solely on validation of the
-   client certificate. One way to do this in the Microsoft environment
-   is to use the UPN to locate and extract a certificate of the claimed
-   user from the trusted directory and subsequently match this
-   certificate against the validated client certificate from the TLS
-   handshake.
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information. It may not be prudent to broadcast this information to
-   just any server at any time, as it can reveal network infrastructure
-   the client and server are using.
-
-   To avoid superfluously sending this information, two techniques
-   SHOULD be used to control its dissemination.
-
-      - The client SHOULD only send the UserMappingDataList handshake
-        message if it is agreed upon in the hello message exchange,
-   preventing
-        the information from being sent to a server that doesn't
-        understand the User Mapping Extension.
-
-      - The client SHOULD further only send this information if the
-        server belongs to a domain to which the client intends to
-        authenticate using the UPN as identifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-6 References
-
-   Normative references:
-
-   [N1]        S. Bradner, "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]        T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-               RFC 2246, January 1999.
-
-   [N3]        T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-               RFC 4346, January 2006.
-
-   [N4]        S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-               T. Wright, "Transport Layer Security (TLS) Extensions",
-               RFC 4366, February 2006.
-
-   [N5]        Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-
-7 IANA Considerations
-
-   IANA needs to establish a registry for TLS UserMappingType values.
-   The first entry in the registry is upn_domain_hint(0). TLS
-   UserMappingType values in the inclusive range 0-63 (decimal) are
-   assigned via RFC 2434 [IANA] Standards Action.  Values from the
-   inclusive range 64-223 (decimal) are assigned via RFC 2434
-   Specification Required.  Values from the inclusive range 224-255
-   (decimal) are reserved for RFC 2434 Private Use.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-Appendix A. IPR Disclosure
-
-   TBD
-
-Authors' Addresses
-
-
-   Stefan Santesson
-   Microsoft
-   Tuborg Boulevard 12
-   2900 Hellerup
-   Denmark
-
-   EMail: stefans(at)microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   Email: arimed(at)microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   Email: joshball(at)microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 9]
-
-INTERNET DRAFT         TLS User Mapping extension          February 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires August 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 10]
diff --git a/doc/protocol/draft-santesson-tls-ume-04.txt b/doc/protocol/draft-santesson-tls-ume-04.txt
deleted file mode 100644
index f774b23bf7..0000000000
--- a/doc/protocol/draft-santesson-tls-ume-04.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346 (once approved)             A. Medvinsky (Microsoft)
-Intended Category: Standards track                   J. Ball (Microsoft)
-Expires September 2006                                        March 2006
-
-
-                       TLS User Mapping Extension
-                    <draft-santesson-tls-ume-04.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping data in a supplemental data handshake message
-   defined in RFC TBD. One such mapping is defined, the UpnDomainHint,
-   which may be used by a server to locate a user in a directory
-   database. Other mappings may be defined in other documents in the
-   future.
-
-   (NOTE TO RFC EDITOR:  Replace "RFC TBD" with the RFC number assigned
-   to draft-santesson-tls-supp-00.txt)
-
-
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  User mapping extension ......................................    3
-   3  User mapping handshake exchange .............................    4
-   4  Message flow ................................................    7
-   5  Security Considerations .....................................    8
-   6  References ..................................................    9
-   7 IANA Considerations ... ......................................    9
-   Authors' Addresses .............................................   10
-   Acknowledgements ...............................................   10
-   Disclaimer .....................................................   11
-   Copyright Statement ............................................   11
-
-1.  Introduction
-
-   This specification defines a TLS extension and a payload for the
-   SupplementalData handshake message, defined in RFC TBD [N6], to
-   accommodate mapping of users to their user accounts when using TLS
-   client authentication as the authentication method.
-
-   The UPN (User Principal Name) is a name form defined by Microsoft
-   which specifies a user's entry in a directory in the form of
-   userName@domainName.  Traditionally Microsoft has relied on such UPN
-   names to be present in the client certificate when logging on to a
-   domain account.
-
-   This has however several drawbacks since it prevents the use of
-   certificates with an absent UPN and also requires re-issuance of
-   certificates or issuance of multiple certificates to reflect account
-   changes or creation of new accounts.
-
-   The TLS extension defined in this document 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.
-
-   The new TLS extension (user_mapping) is sent in the client hello
-   message. Per convention defined in RFC 4366 [N4], the server places
-   the same extension (user_mapping) in the server hello message, to
-   inform the client that the server understands this extension. If the
-   server does not understand the extension, it will respond with a
-   server hello omitting this extension and the client will proceed as
-   normal, ignoring the extension, and not include the
-   UserMappingDataList data in the TLS handshake.
-
-   If the new extension is understood, the client will inject
-   UserMappingDataList data in the SupplementalData handshake message
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-   prior to the Client's Certificate message. The server will then parse
-   this message, extracting the client's domain, and store it in the
-   context for use when mapping the certificate to the user's directory
-   account.
-
-   No other modifications to the protocol are required. The messages are
-   detailed in the following sections.
-
-
-1.1  Terminology
-
-   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 [STDWORDS].
-
-   The syntax for the TLS User Mapping extension is defined using the
-   TLS Presentation Language, which is specified in Section 4 of [N2].
-
-1.2  Design considerations
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the client hello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-   Additionally, if mapping information were to be considered
-   confidential, the addition of a new user mapping message type could
-   allow the data to be encrypted using the server's public key.
-
-
-2  User mapping extension
-
-   A new extension type (user_mapping(TBD)) is added to the Extension
-   used in both the client hello and server hello messages. The
-   extension type is specified as follows.
-
-
-      enum {
-           user_mapping(TBD), (65535)
-      } ExtensionType;
-
-   The "extension_data" field of this extension SHALL contain
-   "UserMappingTypeList" with a list of supported hint types where:
-
-      struct {
-            UserMappingType user_mapping_types<1..2^8-1>
-      } UserMappingTypeList;
-
-   Enumeration of hint types (user_mapping_types) defined in this
-   document is provided in section 3.
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-   The list of user_mapping_types included in a client hello SHALL
-   signal the hint types supported by the client. The list of
-   user_mapping_types included in the server hello SHALL signal the hint
-   types preferred by the server.
-
-   If none of the hint types listed by the client is supported by the
-   server, the server SHALL omit the user_mapping extension in the
-   server hello.
-
-   When the user_mapping extension is included in the server hello, the
-   list of hint types in "UserMappingTypeList" SHALL be either equal to,
-   or a subset of, the list provided by the client.
-
-3  User mapping handshake exchange
-
-   The underlying structure of the SupplementalData handshake message,
-   used to carry information defined in this section, is defined in RFC
-   TBD [N6].
-
-   A new SupplementalDataType [N6] is defined to accommodate
-   communication of generic user mapping data. See RFC 2246 (TLS 1.0)
-   [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
-
-   The information in this data type carries one or more unauthenticated
-   hints, UserMappingDataList, inserted by the client side. Upon receipt
-   and successful completion of the TLS handshake, the server MAY use
-   this hint to locate the user's account from which user information
-   and credentials MAY be retrieved to support authentication based on
-   the client certificate.
-
-
-      struct {
-            SupplementalDataType supp_data_type;
-            select(SupplementalDataType) {
-               case user_mapping_data: UserMappingDataList;
-               }
-      } SupplementalDataEntry;
-
-      enum {
-            user_mapping_data(TBD), (65535)
-      } SupplementalDataType;
-
-
-   The user_mapping_data(n) enumeration results in a new supplemental
-   data type UserMappingDataList with the following structure:
-
-
-      enum {
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-             upn_domain_hint(0), (255)
-      } UserMappingType;
-
-      struct {
-             opaque user_principal_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) {
-                   case upn_domain_hint:
-                        UpnDomainHint;
-             }
-      } UserMappingData;
-
-      struct{
-         UserMappingData user_mapping_data_list<1..2^16-1>;
-      }UserMappingDataList;
-
-
-   The user_principal_name parameter, when specified, SHALL contain a
-   Unicode UPN, encoded as a UTF-8 string in the following form:
-
-      user@domain
-
-   For example the UPN 'foo@example.com' represents user 'foo' at domain
-   'example.com'.
-
-   The domain_name parameter, when specified, SHALL contain a domain
-   name in the "preferred name syntax," as specified by RFC 1123.
-
-   The UpnDomainHint MUST at least contain a non empty
-   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
-   contain both user_principal_name and domain_name.
-
-   The UserMappingData structure contains a single mapping of type
-   UserMappingType.  This structure can be leveraged to define new types
-   of user mapping hints in the future.  The UserMappingDataList MAY
-   carry multiple hints; it is defined as a vector of UserMappingData
-   structures.
-
-   No preference is given to the order in which hints are specified in
-   this vector.  If the client sends more then one hint then the Server
-   SHOULD use the applicable mapping supported by the server.
-
-   This document does not specify how the server stores the
-   user_principal_name, or how exactly it might be used to locate a
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-   certificate.  For instance, it might be appropriate to do a case-
-   insensitive lookup.  It is RECOMMENDED that the server processes the
-   user_principal_name with a stringprep profile [N7] appropriate for
-   the identity in question, such as Nameprep [N8] for the portion
-   domain portion of UPN, SASLprep [N9] for the user portion of the UPN
-   and stringprep appendix B.3 [N7] as mapping table for case folding.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-4  Message flow
-
-   In order to negotiate to send user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello, which SHALL
-   contain a list of supported hint types.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension, MAY indicate that they are willing to
-   accept user mapping data by including an extension of type
-   "user_mapping" in the (extended) server hello, which SHALL contain a
-   list of preferred hint types.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hello messages including "user_mapping"
-   extensions), clients MAY send a "SupplementalData" message containing
-   the "UserMappingDataList" before the "Certificate" message. The
-   message flow is illustrated in Fig. 1 below.
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      SupplementalData
-       /* with UserMappingDataList */
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow with user mapping data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent according to RFC 2246 [N2] and RFC 4346 [N3].
-
-
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-5  Security Considerations
-
-   The UPN sent in the UserMappingDataList is unauthenticated data that
-   MUST NOT be treated as a trusted identifier. Authentication of the
-   user represented by that UPN MUST rely solely on validation of the
-   client certificate. One way to do this in the Microsoft environment
-   is to use the UPN to locate and extract a certificate of the claimed
-   user from the trusted directory and subsequently match this
-   certificate against the validated client certificate from the TLS
-   handshake.
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information. It may not be prudent to broadcast this information to
-   just any server at any time, as it can reveal network infrastructure
-   the client and server are using.
-
-   To avoid superfluously sending this information, two techniques
-   SHOULD be used to control its dissemination.
-
-      - The client SHOULD only send the UserMappingDataList in the
-        supplemental data message if it is agreed upon in the hello
-        message exchange, preventing the information from being sent
-        to a server that doesn't understand the User Mapping Extension.
-
-      - The client SHOULD further only send this information if the
-        server belongs to a domain to which the client intends to
-        authenticate using the UPN as identifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-6 References
-
-   Normative references:
-
-   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-             RFC 2246, January 1999.
-
-   [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-             RFC 4346, January 2006.
-
-   [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-             T. Wright, "Transport Layer Security (TLS) Extensions",
-             RFC 4366, February 2006.
-
-   [N5]      Mockapetris, P., "Domain Names - Concepts and
-             Facilities", STD 13, RFC 1034, November 1987.
-
-   [N6]      S. Santesson, "TLS Handshake Message for Supplementary
-             Data", RFC TBD (currently: draft-santesson-tls-supp-00,
-             Date 2006.
-
-   [N7]      P. Hoffman, M. Blanchet, "Preparation of Internationalized
-             Strings (stringprep)", RFC 3454, December 2002.
-
-   [N8]      P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
-             for Internationalized Domain Names (IDN)", RFC 3491,
-             March 2003.
-
-   [N9]      K. Zeilenga, "SASLprep: Stringprep Profile for User Names
-             and Passwords", RFC 4013, February 2005.
-
-
-
-
-7 IANA Considerations
-
-   IANA needs to establish a registry for TLS UserMappingType values.
-   The first entry in the registry is upn_domain_hint(0). TLS
-   UserMappingType values in the inclusive range 0-63 (decimal) are
-   assigned via RFC 2434 [IANA] Standards Action.  Values from the
-   inclusive range 64-223 (decimal) are assigned via RFC 2434
-   Specification Required.  Values from the inclusive range 224-255
-   (decimal) are reserved for RFC 2434 Private Use.
-
-
-
-
-
-Santesson, et. all                                              [Page 9]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-Authors' Addresses
-
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans(at)microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: arimed(at)microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: joshball(at)microsoft.com
-
-
-
-Acknowledgements
-
-   The authors extend a special thanks to Russ Housley, Eric Resocorla
-   and Paul Leach for their substantial contributions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 10]
-
-INTERNET DRAFT         TLS User Mapping extension             March 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires September 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 11]
diff --git a/doc/protocol/draft-santesson-tls-ume-05.txt b/doc/protocol/draft-santesson-tls-ume-05.txt
deleted file mode 100644
index a9101cb240..0000000000
--- a/doc/protocol/draft-santesson-tls-ume-05.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346 (once approved)             A. Medvinsky (Microsoft)
-Intended Category: Standards track                   J. Ball (Microsoft)
-Expires October 2006                                          April 2006
-
-
-                       TLS User Mapping Extension
-                    <draft-santesson-tls-ume-05.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping data in a supplemental data handshake message
-   defined in RFC TBD. One such mapping is defined, the UpnDomainHint,
-   which may be used by a server to locate a user in a directory
-   database. Other mappings may be defined in other documents in the
-   future.
-
-   (NOTE TO RFC EDITOR:  Replace "RFC TBD" with the RFC number assigned
-   to draft-santesson-tls-supp-00.txt)
-
-
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  User mapping extension ......................................    3
-   3  User mapping handshake exchange .............................    4
-   4  Message flow ................................................    7
-   5  Security Considerations .....................................    8
-   6  References ..................................................    9
-   7 IANA Considerations ... ......................................    9
-   Authors' Addresses .............................................   10
-   Acknowledgements ...............................................   10
-   Disclaimer .....................................................   11
-   Copyright Statement ............................................   11
-
-1.  Introduction
-
-   This specification defines a TLS extension and a payload for the
-   SupplementalData handshake message, defined in RFC TBD [N6], to
-   accommodate mapping of users to their user accounts when using TLS
-   client authentication as the authentication method.
-
-   The UPN (User Principal Name) is a name form defined by Microsoft
-   which specifies a user's entry in a directory in the form of
-   userName@domainName.  Traditionally Microsoft has relied on such UPN
-   names to be present in the client certificate when logging on to a
-   domain account.
-
-   This has however several drawbacks since it prevents the use of
-   certificates with an absent UPN and also requires re-issuance of
-   certificates or issuance of multiple certificates to reflect account
-   changes or creation of new accounts.
-
-   The TLS extension defined in this document 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.
-
-   The new TLS extension (user_mapping) is sent in the client hello
-   message. Per convention defined in RFC 4366 [N4], the server places
-   the same extension (user_mapping) in the server hello message, to
-   inform the client that the server understands this extension. If the
-   server does not understand the extension, it will respond with a
-   server hello omitting this extension and the client will proceed as
-   normal, ignoring the extension, and not include the
-   UserMappingDataList data in the TLS handshake.
-
-   If the new extension is understood, the client will inject
-   UserMappingDataList data in the SupplementalData handshake message
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-   prior to the Client's Certificate message. The server will then parse
-   this message, extracting the client's domain, and store it in the
-   context for use when mapping the certificate to the user's directory
-   account.
-
-   No other modifications to the protocol are required. The messages are
-   detailed in the following sections.
-
-
-1.1  Terminology
-
-   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 [N1].
-
-   The syntax for the TLS User Mapping extension is defined using the
-   TLS Presentation Language, which is specified in Section 4 of [N2].
-
-1.2  Design considerations
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the client hello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-   Additionally, if mapping information were to be considered
-   confidential, the addition of a new user mapping message type could
-   allow the data to be encrypted using the server's public key.
-
-
-2  User mapping extension
-
-   A new extension type (user_mapping(TBD)) is added to the Extension
-   used in both the client hello and server hello messages. The
-   extension type is specified as follows.
-
-
-      enum {
-           user_mapping(TBD), (65535)
-      } ExtensionType;
-
-   The "extension_data" field of this extension SHALL contain
-   "UserMappingTypeList" with a list of supported hint types where:
-
-      struct {
-            UserMappingType user_mapping_types<1..2^8-1>
-      } UserMappingTypeList;
-
-   Enumeration of hint types (user_mapping_types) defined in this
-   document is provided in section 3.
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-   The list of user_mapping_types included in a client hello SHALL
-   signal the hint types supported by the client. The list of
-   user_mapping_types included in the server hello SHALL signal the hint
-   types preferred by the server.
-
-   If none of the hint types listed by the client is supported by the
-   server, the server SHALL omit the user_mapping extension in the
-   server hello.
-
-   When the user_mapping extension is included in the server hello, the
-   list of hint types in "UserMappingTypeList" SHALL be either equal to,
-   or a subset of, the list provided by the client.
-
-3  User mapping handshake exchange
-
-   The underlying structure of the SupplementalData handshake message,
-   used to carry information defined in this section, is defined in RFC
-   TBD [N6].
-
-   A new SupplementalDataType [N6] is defined to accommodate
-   communication of generic user mapping data. See RFC 2246 (TLS 1.0)
-   [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
-
-   The information in this data type carries one or more unauthenticated
-   hints, UserMappingDataList, inserted by the client side. Upon receipt
-   and successful completion of the TLS handshake, the server MAY use
-   this hint to locate the user's account from which user information
-   and credentials MAY be retrieved to support authentication based on
-   the client certificate.
-
-   The hint defined in this specification (upn_domain_hint) specifies
-   two fields, user_principal_name and domain_name. The domain_name
-   field MAY be used when only domain information is needed, e.g. where
-   a user have accounts in multiple domains using the same username
-   name, where that user name is known from another source (e.g. from
-   the client certificate). When the user name is also needed, the
-   upn_domain_hint field MAY be used to indicate both username and
-   domain name. If both fields are present, then the server can make use
-   of whichever one it chooses.
-
-
-      struct {
-            SupplementalDataType supp_data_type;
-            select(SupplementalDataType) {
-               case user_mapping_data: UserMappingDataList;
-               }
-      } SupplementalDataEntry;
-
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-      enum {
-            user_mapping_data(TBD), (65535)
-      } SupplementalDataType;
-
-
-   The user_mapping_data(TBD) enumeration results in a new supplemental
-   data type UserMappingDataList with the following structure:
-
-
-      enum {
-             upn_domain_hint(0), (255)
-      } UserMappingType;
-
-      struct {
-             opaque user_principal_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) {
-                   case upn_domain_hint:
-                        UpnDomainHint;
-             }
-      } UserMappingData;
-
-      struct{
-         UserMappingData user_mapping_data_list<1..2^16-1>;
-      }UserMappingDataList;
-
-
-   The user_principal_name parameter, when specified, SHALL contain a
-   Unicode UPN, encoded as a UTF-8 string in the following form:
-
-      user@domain
-
-   For example the UPN 'foo@example.com' represents user 'foo' at domain
-   'example.com'.
-
-   The user_principal_name field, when specified, SHALL be of the form
-   "user@domain", where "user" is a UTF-8 encoded Unicode string that
-   does not contain the "@" character, and "domain" is a domain name
-   meeting the requirements in the following paragraph.
-
-   The domain_name field, when specified, SHALL contain a domain name in
-   the usual text form: in other words, a sequence of one or more domain
-   labels separated by ".", each domain label starting and ending with
-   an alphanumeric character and possibly also containing "-"
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-   characters.  This field is an "IDN-unaware domain name slot" as
-   defined in RFC 3490 [N7] and therefore, domain names containing non-
-   ASCII characters have to be processed as described in RFC 3490 before
-   being stored in this field.
-
-   The UpnDomainHint MUST at least contain a non empty
-   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
-   contain both user_principal_name and domain_name.
-
-   The UserMappingData structure contains a single mapping of type
-   UserMappingType.  This structure can be leveraged to define new types
-   of user mapping hints in the future.  The UserMappingDataList MAY
-   carry multiple hints; it is defined as a vector of UserMappingData
-   structures.
-
-   No preference is given to the order in which hints are specified in
-   this vector.  If the client sends more then one hint then the Server
-   SHOULD use the applicable mapping supported by the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-4  Message flow
-
-   In order to negotiate to send user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello, which SHALL
-   contain a list of supported hint types.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension, MAY indicate that they are willing to
-   accept user mapping data by including an extension of type
-   "user_mapping" in the (extended) server hello, which SHALL contain a
-   list of preferred hint types.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hello messages including "user_mapping"
-   extensions), clients MAY send a "SupplementalData" message containing
-   the "UserMappingDataList" before the "Certificate" message. The
-   message flow is illustrated in Fig. 1 below.
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      SupplementalData
-       /* with UserMappingDataList */
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow with user mapping data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent according to RFC 2246 [N2] and RFC 4346 [N3].
-
-
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-5  Security Considerations
-
-   The UPN sent in the UserMappingDataList is unauthenticated data that
-   MUST NOT be treated as a trusted identifier. Authentication of the
-   user represented by that UPN MUST rely solely on validation of the
-   client certificate. One way to do this in the Microsoft environment
-   is to use the UPN to locate and extract a certificate of the claimed
-   user from the trusted directory and subsequently match this
-   certificate against the validated client certificate from the TLS
-   handshake.
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information. It may not be prudent to broadcast this information to
-   just any server at any time, as it can reveal network infrastructure
-   the client and server are using.
-
-   To avoid superfluously sending this information, two techniques
-   SHOULD be used to control its dissemination.
-
-      - The client SHOULD only send the UserMappingDataList in the
-        supplemental data message if it is agreed upon in the hello
-        message exchange, preventing the information from being sent
-        to a server that doesn't understand the User Mapping Extension.
-
-      - The client SHOULD further only send this information if the
-        server belongs to a domain to which the client intends to
-        authenticate using the UPN as identifier.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-6 References
-
-   Normative references:
-
-   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-             RFC 2246, January 1999.
-
-   [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-             RFC 4346, January 2006.
-
-   [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-             T. Wright, "Transport Layer Security (TLS) Extensions",
-             RFC 4366, February 2006.
-
-   [N5]      Mockapetris, P., "Domain Names - Concepts and
-             Facilities", STD 13, RFC 1034, November 1987.
-
-   [N6]      S. Santesson, "TLS Handshake Message for Supplementary
-             Data", RFC TBD (currently: draft-santesson-tls-supp-00,
-             Date 2006.
-
-   [N7]      P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
-             Domain Names in Applications (IDNA)", RFC 3490, March 2003
-
-   [N8]      T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-             Considerations Section in RFCs", RFC 2434, October 1998
-
-
-7 IANA Considerations
-
-   IANA needs to take the following actions:
-
-   1) Create an entry, user_mapping(TBD), in the existing registry for
-   ExtensionType (defined in RFC 4366 [N4]).
-
-   2) Create an entry, user_mapping_data(TBD), in the new registry for
-   SupplementalDataType (defined in draft-santesson-tls-supp-00).
-
-   3) Establish a registry for TLS UserMappingType values.  The first
-   entry in the registry is upn_domain_hint(0). TLS UserMappingType
-   values in the inclusive range 0-63 (decimal) are assigned via RFC
-   2434 [N8] Standards Action.  Values from the inclusive range 64-223
-   (decimal) are assigned via RFC 2434 Specification Required.  Values
-   from the inclusive range 224-255 (decimal) are reserved for RFC 2434
-   Private Use.
-
-
-
-Santesson, et. all                                              [Page 9]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-Authors' Addresses
-
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans(at)microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: arimed(at)microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: joshball(at)microsoft.com
-
-
-
-Acknowledgements
-
-   The authors extend a special thanks to Russ Housley, Eric Resocorla
-   and Paul Leach for their substantial contributions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 10]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires October 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 11]
diff --git a/doc/protocol/draft-santesson-tls-ume-06.txt b/doc/protocol/draft-santesson-tls-ume-06.txt
deleted file mode 100644
index 9ea205ae25..0000000000
--- a/doc/protocol/draft-santesson-tls-ume-06.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346 (once approved)             A. Medvinsky (Microsoft)
-Intended Category: Standards track                   J. Ball (Microsoft)
-Expires October 2006                                          April 2006
-
-
-                       TLS User Mapping Extension
-                    <draft-santesson-tls-ume-06.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping hints in a supplemental data handshake message
-   defined in RFC TBD. One such mapping hint is defined, the
-   UpnDomainHint, which may be used by a server to locate a user in a
-   directory database. Other mapping hints may be defined in other
-   documents in the future.
-
-   (NOTE TO RFC EDITOR:  Replace "RFC TBD" with the RFC number assigned
-   to draft-santesson-tls-supp-00.txt)
-
-
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  User mapping extension ......................................    3
-   3  User mapping handshake exchange .............................    4
-   4  Message flow ................................................    7
-   5  Security Considerations .....................................    8
-   6  References ..................................................    9
-   7 IANA Considerations ... ......................................    9
-   Authors' Addresses .............................................   10
-   Acknowledgements ...............................................   10
-   Disclaimer .....................................................   11
-   Copyright Statement ............................................   11
-
-1.  Introduction
-
-   This specification defines a TLS extension and a payload for the
-   SupplementalData handshake message, defined in RFC TBD [N6], to
-   accommodate mapping of users to their user accounts when using TLS
-   client authentication as the authentication method.
-
-   This specification specifies one new user mapping hint type,
-   providing means to send Domain Name hints and User Principal Name
-   hints. Other hint types may be defined in other documents in the
-   future.
-
-   The User Principal Name (UPN) represents a name which specifies a
-   user's entry in a directory in the form of userName@domainName.
-   Traditionally Microsoft has relied on such name form to be present in
-   the client certificate when logging on to a domain account. This has
-   however several drawbacks since it prevents the use of certificates
-   with an absent UPN and also requires re-issuance of certificates or
-   issuance of multiple certificates to reflect account changes or
-   creation of new accounts. 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.
-
-   The new TLS extension (user_mapping) is sent in the client hello
-   message. Per convention defined in RFC 4366 [N4], the server places
-   the same extension (user_mapping) in the server hello message, to
-   inform the client that the server understands this extension. If the
-   server does not understand the extension, it will respond with a
-   server hello omitting this extension and the client will proceed as
-   normal, ignoring the extension, and not include the
-   UserMappingDataList data in the TLS handshake.
-
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-   If the new extension is understood, the client will inject
-   UserMappingDataList data in the SupplementalData handshake message
-   prior to the Client's Certificate message. The server will then parse
-   this message, extracting the client's domain, and store it in the
-   context for use when mapping the certificate to the user's directory
-   account.
-
-   No other modifications to the protocol are required. The messages are
-   detailed in the following sections.
-
-
-1.1  Terminology
-
-   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 [N1].
-
-   The syntax for the TLS User Mapping extension is defined using the
-   TLS Presentation Language, which is specified in Section 4 of [N2].
-
-1.2  Design considerations
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the client hello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-
-
-2  User mapping extension
-
-   A new extension type (user_mapping(TBD)) is added to the Extension
-   used in both the client hello and server hello messages. The
-   extension type is specified as follows.
-
-
-      enum {
-           user_mapping(TBD), (65535)
-      } ExtensionType;
-
-   The "extension_data" field of this extension SHALL contain
-   "UserMappingTypeList" with a list of supported hint types where:
-
-      struct {
-            UserMappingType user_mapping_types<1..2^8-1>
-      } UserMappingTypeList;
-
-   Enumeration of hint types (user_mapping_types) defined in this
-   document is provided in section 3.
-
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-   The list of user_mapping_types included in a client hello SHALL
-   signal the hint types supported by the client. The list of
-   user_mapping_types included in the server hello SHALL signal the hint
-   types preferred by the server.
-
-   If none of the hint types listed by the client is supported by the
-   server, the server SHALL omit the user_mapping extension in the
-   server hello.
-
-   When the user_mapping extension is included in the server hello, the
-   list of hint types in "UserMappingTypeList" SHALL be either equal to,
-   or a subset of, the list provided by the client.
-
-3  User mapping handshake exchange
-
-   The underlying structure of the SupplementalData handshake message,
-   used to carry information defined in this section, is defined in RFC
-   TBD [N6].
-
-   A new SupplementalDataType [N6] is defined to accommodate
-   communication of generic user mapping data. See RFC 2246 (TLS 1.0)
-   [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
-
-   The information in this data type carries one or more unauthenticated
-   hints, UserMappingDataList, inserted by the client side. Upon receipt
-   and successful completion of the TLS handshake, the server MAY use
-   this hint to locate the user's account from which user information
-   and credentials MAY be retrieved to support authentication based on
-   the client certificate.
-
-   The hint defined in this specification (upn_domain_hint) specifies
-   two fields, user_principal_name and domain_name. The domain_name
-   field MAY be used when only domain information is needed, e.g. where
-   a user have accounts in multiple domains using the same username
-   name, where that user name is known from another source (e.g. from
-   the client certificate). When the user name is also needed, the
-   user_principal_name field MAY be used to indicate both username and
-   domain name. If both fields are present, then the server can make use
-   of whichever one it chooses.
-
-
-      struct {
-            SupplementalDataType supp_data_type;
-            select(SupplementalDataType) {
-               case user_mapping_data: UserMappingDataList;
-               }
-      } SupplementalDataEntry;
-
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-      enum {
-            user_mapping_data(TBD), (65535)
-      } SupplementalDataType;
-
-
-   The user_mapping_data(TBD) enumeration results in a new supplemental
-   data type UserMappingDataList with the following structure:
-
-
-      enum {
-             upn_domain_hint(0), (255)
-      } UserMappingType;
-
-      struct {
-             opaque user_principal_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) {
-                   case upn_domain_hint:
-                        UpnDomainHint;
-             }
-      } UserMappingData;
-
-      struct{
-         UserMappingData user_mapping_data_list<1..2^16-1>;
-      }UserMappingDataList;
-
-
-   The user_principal_name field, when specified, SHALL be of the form
-   "user@domain", where "user" is a UTF-8 encoded Unicode string that
-   does not contain the "@" character, and "domain" is a domain name
-   meeting the requirements in the following paragraph.
-
-   The domain_name field, when specified, SHALL contain a domain name in
-   the usual text form: in other words, a sequence of one or more domain
-   labels separated by ".", each domain label starting and ending with
-   an alphanumeric character and possibly also containing "-"
-   characters.  This field is an "IDN-unaware domain name slot" as
-   defined in RFC 3490 [N7] and therefore, domain names containing non-
-   ASCII characters have to be processed as described in RFC 3490 before
-   being stored in this field.
-
-   The UpnDomainHint MUST at least contain a non empty
-   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
-   contain both user_principal_name and domain_name.
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-   The UserMappingData structure contains a single mapping of type
-   UserMappingType.  This structure can be leveraged to define new types
-   of user mapping hints in the future.  The UserMappingDataList MAY
-   carry multiple hints; it is defined as a vector of UserMappingData
-   structures.
-
-   No preference is given to the order in which hints are specified in
-   this vector.  If the client sends more then one hint then the Server
-   SHOULD use the applicable mapping supported by the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-4  Message flow
-
-   In order to negotiate to send user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello, which SHALL
-   contain a list of supported hint types.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension, MAY indicate that they are willing to
-   accept user mapping data by including an extension of type
-   "user_mapping" in the (extended) server hello, which SHALL contain a
-   list of preferred hint types.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hello messages including "user_mapping"
-   extensions), clients MAY send a "SupplementalData" message containing
-   the "UserMappingDataList" before the "Certificate" message. The
-   message flow is illustrated in Fig. 1 below.
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      SupplementalData
-       /* with UserMappingDataList */
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow with user mapping data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent according to RFC 2246 [N2] and RFC 4346 [N3].
-
-   The server MUST expect and gracefully handle the case where the
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-   client chooses to not send any supplementalData handshake message
-   even after successful negotiation of extensions. The client MAY at
-   its own discretion decide that the user mapping hint it initially
-   intended to send no longer is relevant for this session. One such
-   reason could be that the server certificate fails to meet certain
-   requirements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-5  Security Considerations
-
-   The user mapping hint sent in the UserMappingDataList is
-   unauthenticated data that MUST NOT be treated as a trusted
-   identifier. Authentication of the user represented by that user
-   mapping hint MUST rely solely on validation of the client
-   certificate. One way to do this is to use the user mapping hint to
-   locate and extract a certificate of the claimed user from the trusted
-   directory and subsequently match this certificate against the
-   validated client certificate from the TLS handshake.
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information. It may not be prudent to broadcast this information to
-   just any server at any time, as it can reveal network infrastructure
-   the client and server are using.
-
-   To avoid superfluously sending this information, clients SHOULD only
-   send this information if the server belongs to a domain to which the
-   client intends to authenticate using the UPN as identifier.
-
-   In some cases, the user mapping hint may itself be regarded as
-   sensitive. In such case the double handshake technique described in
-   [N6] can be used to provide protection for the user mapping hint
-   information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 9]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-6 References
-
-   Normative references:
-
-   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-             RFC 2246, January 1999.
-
-   [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-             RFC 4346, January 2006.
-
-   [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-             T. Wright, "Transport Layer Security (TLS) Extensions",
-             RFC 4366, February 2006.
-
-   [N5]      Mockapetris, P., "Domain Names - Concepts and
-             Facilities", STD 13, RFC 1034, November 1987.
-
-   [N6]      S. Santesson, "TLS Handshake Message for Supplementary
-             Data", RFC TBD (currently: draft-santesson-tls-supp-02,
-             Date 2006.
-
-   [N7]      P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
-             Domain Names in Applications (IDNA)", RFC 3490, March 2003
-
-   [N8]      T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-             Considerations Section in RFCs", RFC 2434, October 1998
-
-
-7 IANA Considerations
-
-   IANA needs to take the following actions:
-
-   1) Create an entry, user_mapping(TBD), in the existing registry for
-   ExtensionType (defined in RFC 4366 [N4]).
-
-   2) Create an entry, user_mapping_data(TBD), in the new registry for
-   SupplementalDataType (defined in draft-santesson-tls-supp-02).
-
-   3) Establish a registry for TLS UserMappingType values.  The first
-   entry in the registry is upn_domain_hint(0). TLS UserMappingType
-   values in the inclusive range 0-63 (decimal) are assigned via RFC
-   2434 [N8] Standards Action.  Values from the inclusive range 64-223
-   (decimal) are assigned via RFC 2434 Specification Required.  Values
-   from the inclusive range 224-255 (decimal) are reserved for RFC 2434
-   Private Use.
-
-
-
-Santesson, et. all                                             [Page 10]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-Authors' Addresses
-
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans(at)microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: arimed(at)microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: joshball(at)microsoft.com
-
-
-
-Acknowledgements
-
-   The authors extend a special thanks to Russ Housley, Eric Resocorla
-   and Paul Leach for their substantial contributions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 11]
-
-INTERNET DRAFT         TLS User Mapping extension             April 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires October 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 12]
diff --git a/doc/protocol/draft-santesson-tls-ume-07.txt b/doc/protocol/draft-santesson-tls-ume-07.txt
deleted file mode 100644
index 79b62409d6..0000000000
--- a/doc/protocol/draft-santesson-tls-ume-07.txt
+++ /dev/null
@@ -1,728 +0,0 @@
-
-
-
-
-INTERNET-DRAFT                                  S. Santesson (Microsoft)
-Updates: 2246, 4346 (once approved)             A. Medvinsky (Microsoft)
-Intended Category: Standards track                   J. Ball (Microsoft)
-Expires November 2006                                           May 2006
-
-
-                       TLS User Mapping Extension
-                    <draft-santesson-tls-ume-07.txt>
-
-
-Status of this Memo
-
-   By submitting this Internet-Draft, each author represents that any
-   applicable patent or other IPR claims of which he or she is aware
-   have been or will be disclosed, and any of which he or she becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   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 a "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping hints in a supplemental data handshake message
-   defined in RFC TBD. One such mapping hint is defined in an
-   informative section, the UpnDomainHint, which may be used by a server
-   to locate a user in a directory database. Other mapping hints may be
-   defined in other documents in the future.
-
-   (NOTE TO RFC EDITOR:  Replace "RFC TBD" with the RFC number assigned
-   to draft-santesson-tls-supp-00.txt)
-
-
-
-
-
-
-Santesson, et. all                                              [Page 1]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  User mapping extension ......................................    3
-   3  User mapping handshake exchange .............................    4
-   4  Message flow ................................................    6
-   5  Security Considerations .....................................    8
-   6  UPN domain hint (Informative) ...............................    9
-   7  References ..................................................   10
-   8  IANA Considerations .........................................   10
-   Authors' Addresses .............................................   11
-   Acknowledgements ...............................................   11
-   Disclaimer .....................................................   12
-   Copyright Statement ............................................   12
-
-1.  Introduction
-
-   This document has a normative part and an informative part. Sections
-   2-5 are normative. Section 6 is informative.
-
-   This specification defines a TLS extension and a payload for the
-   SupplementalData handshake message, defined in RFC TBD [N6], to
-   accommodate mapping of users to their user accounts when using TLS
-   client authentication as the authentication method.
-
-   The new TLS extension (user_mapping) is sent in the client hello
-   message. Per convention defined in RFC 4366 [N4], the server places
-   the same extension (user_mapping) in the server hello message, to
-   inform the client that the server understands this extension. If the
-   server does not understand the extension, it will respond with a
-   server hello omitting this extension and the client will proceed as
-   normal, ignoring the extension, and not include the
-   UserMappingDataList data in the TLS handshake.
-
-   If the new extension is understood, the client will inject
-   UserMappingDataList data in the SupplementalData handshake message
-   prior to the Client's Certificate message. The server will then parse
-   this message, extracting the client's domain, and store it in the
-   context for use when mapping the certificate to the user's directory
-   account.
-
-   No other modifications to the protocol are required. The messages are
-   detailed in the following sections.
-
-
-1.1  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-
-
-
-Santesson, et. all                                              [Page 2]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in RFC 2119 [N1].
-
-   The syntax for the TLS User Mapping extension is defined using the
-   TLS Presentation Language, which is specified in Section 4 of [N2].
-
-1.2  Design considerations
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the client hello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-
-
-2  User mapping extension
-
-   A new extension type (user_mapping(TBD)) is added to the Extension
-   used in both the client hello and server hello messages. The
-   extension type is specified as follows.
-
-
-      enum {
-           user_mapping(TBD), (65535)
-      } ExtensionType;
-
-   The "extension_data" field of this extension SHALL contain
-   "UserMappingTypeList" with a list of supported hint types where:
-
-      struct {
-            UserMappingType user_mapping_types<1..2^8-1>
-      } UserMappingTypeList;
-
-   Enumeration of hint types (user_mapping_types) defined in this
-   document is provided in section 3.
-
-   The list of user_mapping_types included in a client hello SHALL
-   signal the hint types supported by the client. The list of
-   user_mapping_types included in the server hello SHALL signal the hint
-   types preferred by the server.
-
-   If none of the hint types listed by the client is supported by the
-   server, the server SHALL omit the user_mapping extension in the
-   server hello.
-
-   When the user_mapping extension is included in the server hello, the
-   list of hint types in "UserMappingTypeList" SHALL be either equal to,
-   or a subset of, the list provided by the client.
-
-
-
-
-
-Santesson, et. all                                              [Page 3]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-3  User mapping handshake exchange
-
-   The underlying structure of the SupplementalData handshake message,
-   used to carry information defined in this section, is defined in RFC
-   TBD [N6].
-
-   A new SupplementalDataType [N6] is defined to accommodate
-   communication of generic user mapping data. See RFC 2246 (TLS 1.0)
-   [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
-
-   The information in this data type carries one or more unauthenticated
-   hints, UserMappingDataList, inserted by the client side. Upon receipt
-   and successful completion of the TLS handshake, the server MAY use
-   this hint to locate the user's account from which user information
-   and credentials MAY be retrieved to support authentication based on
-   the client certificate.
-
-
-      struct {
-            SupplementalDataType supp_data_type;
-            select(SupplementalDataType) {
-               case user_mapping_data: UserMappingDataList;
-               }
-      } SupplementalDataEntry;
-
-      enum {
-            user_mapping_data(TBD), (65535)
-      } SupplementalDataType;
-
-
-   The user_mapping_data(TBD) enumeration results in a new supplemental
-   data type UserMappingDataList with the following structure:
-
-
-      enum {
-            (255)
-      } UserMappingType;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) { }
-      } UserMappingData;
-
-      struct{
-         UserMappingData user_mapping_data_list<1..2^16-1>;
-      }UserMappingDataList;
-
-
-
-
-
-Santesson, et. all                                              [Page 4]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-   The UserMappingData structure contains a single mapping of type
-   UserMappingType.  This structure can be leveraged to define new types
-   of user mapping hints in the future.  The UserMappingDataList MAY
-   carry multiple hints; it is defined as a vector of UserMappingData
-   structures.
-
-   No preference is given to the order in which hints are specified in
-   this vector.  If the client sends more then one hint then the Server
-   SHOULD use the applicable mapping supported by the server.
-
-   Implementations MAY support the UPN domain hint as specified in
-   section 6 of this document.  Implementations MAY also support other
-   user mapping types as they are defined.  Definitions of standards-
-   track user mapping types must include a discussion of
-   internationalization considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 5]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-4  Message flow
-
-   In order to negotiate to send user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello, which SHALL
-   contain a list of supported hint types.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension, MAY indicate that they are willing to
-   accept user mapping data by including an extension of type
-   "user_mapping" in the (extended) server hello, which SHALL contain a
-   list of preferred hint types.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hello messages including "user_mapping"
-   extensions), clients MAY send a "SupplementalData" message containing
-   the "UserMappingDataList" before the "Certificate" message. The
-   message flow is illustrated in Fig. 1 below.
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      SupplementalData
-       /* with UserMappingDataList */
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow with user mapping data
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent according to RFC 2246 [N2] and RFC 4346 [N3].
-
-   The server MUST expect and gracefully handle the case where the
-
-
-
-Santesson, et. all                                              [Page 6]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-   client chooses to not send any supplementalData handshake message
-   even after successful negotiation of extensions. The client MAY at
-   its own discretion decide that the user mapping hint it initially
-   intended to send no longer is relevant for this session. One such
-   reason could be that the server certificate fails to meet certain
-   requirements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 7]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-5  Security Considerations
-
-   The user mapping hint sent in the UserMappingDataList is
-   unauthenticated data that MUST NOT be treated as a trusted
-   identifier. Authentication of the user represented by that user
-   mapping hint MUST rely solely on validation of the client
-   certificate. One way to do this is to use the user mapping hint to
-   locate and extract a certificate of the claimed user from the trusted
-   directory and subsequently match this certificate against the
-   validated client certificate from the TLS handshake.
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information. It may not be prudent to broadcast a user mapping hint
-   to just any server at any time.
-
-   To avoid superfluously sending user mapping hints, clients SHOULD
-   only send this information if it recognizes the server as a
-   legitimate recipient. Recognition of the server can be done in many
-   ways. One way to do this could be to recognize the name and address
-   of the server.
-
-   In some cases, the user mapping hint may itself be regarded as
-   sensitive. In such case the double handshake technique described in
-   [N6] can be used to provide protection for the user mapping hint
-   information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                              [Page 8]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-6  UPN domain hint (Informative)
-
-   This specification provides informative description of one user
-   mapping hint type for Domain Name hints and User Principal Name
-   hints. Other hint types may be defined in other documents in the
-   future.
-
-   The User Principal Name (UPN) in this hint type represents a name
-   which specifies a user's entry in a directory in the form
-   userName@domainName. Traditionally Microsoft has relied on such name
-   form to be present in the client certificate when logging on to a
-   domain account. This has however several drawbacks since it prevents
-   the use of certificates with an absent UPN and also requires re-
-   issuance of certificates or issuance of multiple certificates to
-   reflect account changes or creation of new accounts. 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.
-
-   The domain_name field MAY be used when only domain information is
-   needed, e.g. where a user have accounts in multiple domains using the
-   same username name, where that user name is known from another source
-   (e.g. from the client certificate). When the user name is also
-   needed, the user_principal_name field MAY be used to indicate both
-   username and domain name. If both fields are present, then the server
-   can make use of whichever one it chooses.
-
-
-      enum {
-             upn_domain_hint(64), (255)
-      } UserMappingType;
-
-      struct {
-             opaque user_principal_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version
-             select(UserMappingType) {
-                   case upn_domain_hint:
-                        UpnDomainHint;
-             }
-      } UserMappingData;
-
-
-
-
-
-
-Santesson, et. all                                              [Page 9]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-   The user_principal_name field, when specified, SHALL be of the form
-   "user@domain", where "user" is a UTF-8 encoded Unicode string that
-   does not contain the "@" character, and "domain" is a domain name
-   meeting the requirements in the following paragraph.
-
-   The domain_name field, when specified, SHALL contain a domain name in
-   the usual text form: in other words, a sequence of one or more domain
-   labels separated by ".", each domain label starting and ending with
-   an alphanumeric character and possibly also containing "-"
-   characters.  This field is an "IDN-unaware domain name slot" as
-   defined in RFC 3490 [N7] and therefore, domain names containing non-
-   ASCII characters have to be processed as described in RFC 3490 before
-   being stored in this field.
-
-   The UpnDomainHint MUST at least contain a non empty
-   user_principal_name or a non empty domain_name. The UpnDomainHint MAY
-   contain both user_principal_name and domain_name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 10]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-6 References
-
-   Normative references:
-
-   [N1]      S. Bradner, "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]      T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
-             RFC 2246, January 1999.
-
-   [N3]      T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1",
-             RFC 4346, January 2006.
-
-   [N4]      S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen,
-             T. Wright, "Transport Layer Security (TLS) Extensions",
-             RFC 4366, February 2006.
-
-   [N5]      Mockapetris, P., "Domain Names - Concepts and
-             Facilities", STD 13, RFC 1034, November 1987.
-
-   [N6]      S. Santesson, "TLS Handshake Message for Supplementary
-             Data", RFC TBD (currently: draft-santesson-tls-supp-02,
-             Date 2006.
-
-   [N7]      P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing
-             Domain Names in Applications (IDNA)", RFC 3490, March 2003
-
-   [N8]      T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
-             Considerations Section in RFCs", RFC 2434, October 1998
-
-
-7 IANA Considerations
-
-   IANA needs to take the following actions:
-
-   1) Create an entry, user_mapping(TBD), in the existing registry for
-   ExtensionType (defined in RFC 4366 [N4]).
-
-   2) Create an entry, user_mapping_data(TBD), in the new registry for
-   SupplementalDataType (defined in draft-santesson-tls-supp-02).
-
-   3) Establish a registry for TLS UserMappingType values.  The first
-   entry in the registry is upn_domain_hint(64). TLS UserMappingType
-   values in the inclusive range 0-63 (decimal) are assigned via RFC
-   2434 [N8] Standards Action.  Values from the inclusive range 64-223
-   (decimal) are assigned via RFC 2434 Specification Required.  Values
-   from the inclusive range 224-255 (decimal) are reserved for RFC 2434
-   Private Use.
-
-
-
-Santesson, et. all                                             [Page 11]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-Authors' Addresses
-
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans(at)microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: arimed(at)microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   Email: joshball(at)microsoft.com
-
-
-
-Acknowledgements
-
-   The authors extend a special thanks to Russ Housley, Eric Resocorla
-   and Paul Leach for their substantial contributions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 12]
-
-INTERNET DRAFT         TLS User Mapping extension               May 2006
-
-
-Disclaimer
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-
-Expires November 2006
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et. all                                             [Page 13]
diff --git a/doc/protocol/rfc1422.txt b/doc/protocol/rfc1422.txt
deleted file mode 100644
index 37512b33b7..0000000000
--- a/doc/protocol/rfc1422.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            S. Kent
-Request for Comments: 1422                                           BBN
-Obsoletes: 1114                                  IAB IRTF PSRG, IETF PEM
-                                                           February 1993
-
-
-           Privacy Enhancement for Internet Electronic Mail:
-               Part II: Certificate-Based Key Management
-
-Status of this Memo
-
-   This RFC specifies an IAB standards track protocol for the Internet
-   community, and requests discussion and suggestions for improvements.
-   Please refer to the current edition of the "IAB Official Protocol
-   Standards" for the standardization state and status of this protocol.
-   Distribution of this memo is unlimited.
-
-Acknowledgements
-
-   This memo is the outgrowth of a series of meetings of the Privacy and
-   Security Research Group of the Internet Research Task Force (IRTF)
-   and the Privacy-Enhanced Electronic Mail Working Group of the
-   Internet Engineering Task Force (IETF).  I would like to thank the
-   members of the PSRG and the PEM WG for their comments and
-   contributions at the meetings which led to the preparation of this
-   document.  I also would like to thank contributors to the PEM-DEV
-   mailing list who have provided valuable input which is reflected in
-   this memo.
-
-1.  Executive Summary
-
-   This is one of a series of documents defining privacy enhancement
-   mechanisms for electronic mail transferred using Internet mail
-   protocols.  RFC 1421 [6] prescribes protocol extensions and
-   processing procedures for RFC-822 mail messages, given that suitable
-   cryptographic keys are held by originators and recipients as a
-   necessary precondition.  RFC 1423 [7] specifies algorithms, modes and
-   associated identifiers for use in processing privacy-enhanced
-   messages, as called for in RFC 1421 and this document.  This document
-   defines a supporting key management architecture and infrastructure,
-   based on public-key certificate techniques, to provide keying
-   information to message originators and recipients.  RFC 1424 [8]
-   provides additional specifications for services in conjunction with
-   the key management infrastructure described herein.
-
-   The key management architecture described in this document is
-   compatible with the authentication framework described in CCITT 1988
-   X.509 [2].  This document goes beyond X.509 by establishing
-
-
-
-Kent                                                            [Page 1]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   procedures and conventions for a key management infrastructure for
-   use with Privacy Enhanced Mail (PEM) and with other protocols, from
-   both the TCP/IP and OSI suites, in the future.  There are several
-   motivations for establishing these procedures and conventions (as
-   opposed to relying only on the very general framework outlined in
-   X.509):
-
-       -It is important that a certificate management infrastructure
-           for use in the Internet community accommodate a range of
-           clearly-articulated certification policies for both users
-           and   organizations in a well-architected fashion.
-           Mechanisms must be provided to enable each user to be
-           aware of the policies governing any certificate which the
-           user may encounter.  This requires the introduction
-           and standardization of procedures and conventions that are
-           outside the scope of X.509.
-
-       -The procedures for authenticating originators and recipient in
-           the course of message submission and delivery should be
-           simple, automated and uniform despite the existence of
-           differing certificate management policies.  For example,
-           users should not have to engage in careful examination of a
-           complex set of certification relationships in order to
-           evaluate the credibility of a claimed identity.
-
-       -The authentication framework defined by X.509 is designed to
-           operate in the X.500 directory server environment.  However
-           X.500 directory servers are not expected to be ubiquitous
-           in the Internet in the near future, so some conventions
-           are adopted to facilitate operation of the key management
-           infrastructure in the near term.
-
-       -Public key cryptosystems are central to the authentication
-           technology of X.509 and those which enjoy the most
-           widespread use are patented in the U.S.  Although this
-           certification management scheme is compatible with
-           the use of different digital signature algorithms, it is
-           anticipated that the RSA cryptosystem will be used as
-           the primary signature algorithm in establishing the
-           Internet certification hierarchy.  Special license
-           arrangements have been made to facilitate the
-           use of this algorithm in the U.S. portion of Internet
-           environment.
-
-   The infrastructure specified in this document establishes a single
-   root for all certification within the Internet, the Internet Policy
-   Registration Authority (IPRA).  The IPRA establishes global policies,
-   described in this document, which apply to all certification effected
-
-
-
-Kent                                                            [Page 2]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   under this hierarchy.  Beneath IPRA root are Policy Certification
-   Authorities (PCAs), each of which establishes and publishes (in the
-   form of an informational RFC) its policies for registration of users
-   or organizations.  Each PCA is certified by the IPRA. (It is
-   desirable that there be a relatively small number of PCAs, each with
-   a substantively different policy, to facilitate user familiarity with
-   the set of PCA policies.  However there is no explicit requirement
-   that the set of PCAs be limited in this fashion.)  Below PCAs,
-   Certification Authorities (CAs) will be established to certify users
-   and subordinate organizational entities (e.g., departments, offices,
-   subsidiaries, etc.).  Initially, we expect the majority of users will
-   be registered via organizational affiliation, consistent with current
-   practices for how most user mailboxes are provided.  In this sense
-   the registration is analogous to the issuance of a university or
-   company ID card.
-
-   Some CAs are expected to provide certification for residential users
-   in support of users who wish to register independent of any
-   organizational affiliation.  Over time, we anticipate that civil
-   government entities which  already provide analogous identification
-   services in other contexts, e.g.,  driver's licenses, may provide
-   this service.  For users who wish anonymity while taking advantage of
-   PEM privacy facilities, one or more PCAs will be established with
-   policies that allow for registration of users, under subordinate CAs,
-   who do not wish to disclose their identities.
-
-2.  Overview of Approach
-
-   This document defines a key management architecture based on the use
-   of public-key certificates, primarily in support of the message
-   encipherment and authentication procedures defined in RFC 1421.  The
-   concept of public-key certificates is defined in X.509 and this
-   architecture is a compliant subset of that envisioned in X.509.
-
-   Briefly, a (public-key) certificate is a data structure which
-   contains the name of a user (the "subject"), the public component
-   (This document adopts the terms "private component" and "public
-   component" to refer to the quantities which are, respectively, kept
-   secret and made publicly available in asymmetric cryptosystems.  This
-   convention is adopted to avoid possible confusion arising from use of
-   the term "secret key" to refer to either the former quantity or to a
-   key in a symmetric cryptosystem.)  of that user, and the name of an
-   entity (the "issuer") which vouches that the public component is
-   bound to the named user.  This data, along with a time interval over
-   which the binding is claimed to be valid, is cryptographically signed
-   by the issuer using the issuer's private component.  The subject and
-   issuer names in certificates are Distinguished Names (DNs) as defined
-   in the directory system (X.500).
-
-
-
-Kent                                                            [Page 3]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   Once signed, certificates can be stored in directory servers,
-   transmitted via non-secure message exchanges, or distributed via any
-   other means that make certificates easily accessible to message
-   system users, without regard for the security of the transmission
-   medium.  Certificates are used in PEM to provide the originator of a
-   message with the (authenticated) public component of each recipient
-   and to provide each recipient with the (authenticated) public
-   component of the originator.  The following brief discussion
-   illustrates the procedures for both originator and recipients.
-
-   Prior to sending an encrypted message (using PEM), an originator must
-   acquire a certificate for each recipient and must validate these
-   certificates.  Briefly, validation is performed by checking the
-   digital signature in the certificate, using the public component of
-   the issuer whose private component was used to sign the certificate.
-   The issuer's public component is made available via some out of band
-   means (for the IPRA) or is itself distributed in a certificate to
-   which this validation procedure is applied recursively.  In the
-   latter case, the issuer of a user's certificate becomes the subject
-   in a certificate issued by another certifying authority (or a PCA),
-   thus giving rise to a certification hierarchy.  The validity interval
-   for each certificate is checked and Certificate Revocation Lists
-   (CRLs) are checked to ensure that none of the certificates employed
-   in the validation process has been revoked by an issuer.
-
-   Once a certificate for a recipient is validated, the public component
-   contained in the certificate is extracted and used to encrypt the
-   data encryption key (DEK), which, in turn, is used to encrypt the
-   message itself.  The resulting encrypted DEK is incorporated into the
-   Key-Info field of the message header.  Upon receipt of an encrypted
-   message, a recipient employs his private component to decrypt this
-   field, extracting the DEK, and then uses this DEK to decrypt the
-   message.
-
-   In order to provide message integrity and data origin authentication,
-   the originator generates a message integrity code (MIC), signs
-   (encrypts) the MIC using the private component of his public-key
-   pair, and includes the resulting value in the message header in the
-   MIC-Info field.  The certificate of the originator is (optionally)
-   included in the header in the Certificate field as described in RFC
-   1421.  This is done in order to facilitate validation in the absence
-   of ubiquitous directory services.  Upon receipt of a privacy enhanced
-   message, a recipient validates the originator's certificate (using
-   the IPRA public component as the root of a certification path),
-   checks to ensure that it has not been revoked, extracts the public
-   component from the certificate, and uses that value to recover
-   (decrypt) the MIC.  The recovered MIC is compared against the locally
-   calculated MIC to verify the integrity and data origin authenticity
-
-
-
-Kent                                                            [Page 4]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   of the message.
-
-3.  Architecture
-
-   3.1  Scope and Restrictions
-
-   The architecture described below is intended to provide a basis for
-   managing public-key cryptosystem values in support of privacy
-   enhanced electronic mail in the Internet environment.  The
-   architecture describes procedures for registering certification
-   authorities and users, for generating and distributing certificates,
-   and for generating and distributing CRLs.  RFC 1421 describes the
-   syntax and semantics of header fields used to transfer certificates
-   and to represent the DEK and MIC in this public-key context.
-   Definitions of the algorithms, modes of use and associated
-   identifiers are separated in RFC 1423 to facilitate the adoption of
-   additional algorithms in the future.  This document focuses on the
-   management aspects of certificate-based, public-key cryptography for
-   privacy enhanced mail.
-
-   The proposed architecture imposes conventions for the certification
-   hierarchy which are not strictly required by the X.509 recommendation
-   nor by the technology itself.  These conventions are motivated by
-   several factors, primarily the need for authentication semantics
-   compatible with automated validation and the automated determination
-   of the policies under which certificates are issued.
-
-   Specifically, the architecture proposes a system in which user (or
-   mailing list) certificates represent the leaves in a certification
-   hierarchy.  This certification hierarchy is largely isomorphic to the
-   X.500 directory naming hierarchy, with two exceptions: the IPRA forms
-   the root of the tree (the root of the X.500 DIT is not instantiated
-   as a node), and a number of Policy Certification Authorities (PCAs)
-   form the "roots" of subtrees, each of which represents a different
-   certification policy.
-
-   Not every level in the directory hierarchy need correspond to a
-   certification authority.  For example, the appearance of geographic
-   entities in a distinguished name (e.g., countries, states, provinces,
-   localities) does not require that various governments become
-   certifying authorities in order to instantiate this architecture.
-   However, it is anticipated that, over time, a number of such points
-   in the hierarchy will be instantiated as CAs in order to simplify
-   later transition of management to appropriate governmental
-   authorities.
-
-   These conventions minimize the complexity of validating user
-   certificates, e.g., by making explicit the relationship between a
-
-
-
-Kent                                                            [Page 5]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   certificate issuer and the user (via the naming hierarchy). Note that
-   in this architecture, only PCAs may be certified by the IPRA, and
-   every CA's certification path can be traced to a PCA, through zero or
-   more CAs.  If a CA is certified by more than one PCA, each
-   certificate issued by a PCA for the CA must contain a distinct public
-   component.  These conventions result in a certification hierarchy
-   which is a compatible subset of that permitted under X.509, with
-   respect to both syntax and semantics.
-
-   Although the key management architecture described in this document
-   has been designed primarily to support privacy enhanced mail, this
-   infrastructure also may, in principle, be used to support X.400 mail
-   security facilities (as per 1988 X.411) and X.500 directory
-   authentication facilities.  Thus, establishment of this
-   infrastructure paves the way for use of these and other OSI protocols
-   in the Internet in the future.  In the future, these certificates
-   also may be employed in the provision of security services in other
-   protocols in the TCP/IP and OSI suites as well.
-
-   3.2  Relation to X.509 Architecture
-
-   CCITT 1988 Recommendation X.509, "The Directory - Authentication
-   Framework", defines a framework for authentication of entities
-   involved in a distributed directory service.  Strong authentication,
-   as defined in X.509, is accomplished with the use of public-key
-   cryptosystems.  Unforgeable certificates are generated by
-   certification authorities; these authorities may be organized
-   hierarchically, though such organization is not required by X.509.
-   There is no implied mapping between a certification hierarchy and the
-   naming hierarchy imposed by directory system naming attributes.
-
-   This document interprets the X.509 certificate mechanism to serve the
-   needs of PEM in the Internet environment.  The certification
-   hierarchy proposed in this document in support of privacy enhanced
-   mail is intentionally a subset of that allowed under X.509.  This
-   certification hierarchy also embodies semantics which are not
-   explicitly addressed by X.509, but which are consistent with X.509
-   precepts.  An overview of the rationale for these semantics is
-   provided in Section 1.
-
-   3.3  Certificate Definition
-
-   Certificates are central to the key management architecture for X.509
-   and PEM.  This section provides an overview of the syntax and a
-   description of the semantics of certificates.  Appendix A includes
-   the ASN.1 syntax for certificates.   A certificate includes the
-   following contents:
-
-
-
-
-Kent                                                            [Page 6]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-       1.  version
-
-       2.  serial number
-
-       3.  signature (algorithm ID and parameters)
-
-       4.  issuer name
-
-       5.  validity period
-
-       6.  subject name
-
-       7.  subject public key (and associated algorithm ID)
-
-   3.3.1  Version Number
-
-   The version number field is intended to facilitate orderly changes in
-   certificate formats over time.  The initial version number for
-   certificates used in PEM is the X.509 default which has a value of
-   zero (0), indicating the 1988 version.  PEM implementations are
-   encouraged to accept later versions as they are endorsed by
-   CCITT/ISO.
-
-   3.3.2  Serial Number
-
-   The serial number field provides a short form, unique identifier for
-   each certificate generated by an issuer.  An issuer must ensure that
-   no two distinct certificates with the same issuer DN contain the same
-   serial number.  (This requirement must be met even when the
-   certification function is effected on a distributed basis and/or when
-   the same issuer DN is certified under two different PCAs.  This is
-   especially critical for residential CAs certified under different
-   PCAs.) The serial number is used in CRLs to identify revoked
-   certificates, as described in Section 3.4.3.4.  Although this
-   attribute is an integer, PEM UA processing of this attribute need not
-   involve any arithmetic operations.  All PEM UA implementations must
-   be capable of processing serial numbers at least 128 bits in length,
-   and size-independent support serial numbers is encouraged.
-
-   3.3.3  Signature
-
-   This field specifies the algorithm used by the issuer to sign the
-   certificate, and any parameters associated with the algorithm. (The
-   certificate signature is appended to the data structure, as defined
-   by the signature macro in X.509.  This algorithm identification
-   information is replicated with the signature.)  The signature is
-   validated by the UA processing a certificate, in order to determine
-   that the integrity of its contents have not been modified subsequent
-
-
-
-Kent                                                            [Page 7]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   to signing by a CA (IPRA, or PCA).  In this context, a signature is
-   effected through the use of a Certificate Integrity Check (CIC)
-   algorithm and a public-key encryption algorithm.  RFC 1423 contains
-   the definitions and algorithm IDs for signature algorithms employed
-   in this architecture.
-
-   3.3.4  Subject Name
-
-   A certificate provides a representation of its subject's identity in
-   the form of a Distinguished Name (DN).  The fundamental binding
-   ensured by the key management architecture is that between the public
-   component and the user's identity in this form.  A distinguished name
-   is an X.500 directory system concept and if a user is already
-   registered in an X.500 directory, his distinguished name is defined
-   via that registration.  Users who are not registered in a directory
-   should keep in mind likely directory naming structure (schema) when
-   selecting a distinguished name for inclusion in a certificate.
-
-   3.3.5  Issuer Name
-
-   A certificate provides a representation of its issuer's identity, in
-   the form of a Distinguished Name.  The issuer identification is used
-   to select the appropriate issuer public component to employ in
-   performing certificate validation.  (If an issuer (CA) is certified
-   by multiple PCAs, then the issuer DN does not uniquely identify the
-   public component used to sign the certificate.  In such circumstances
-   it may be necessary to attempt certificate validation using multiple
-   public components, from certificates held by the issuer under
-   different PCAs.  If the 1992 version of a certificate is employed,
-   the issuer may employ distinct issuer UIDs in the certificates it
-   issues, to further facilitate selection of the right issuer public
-   component.) The issuer is the certifying authority (IPRA, PCA or CA)
-   who vouches for the binding between the subject identity and the
-   public key contained in the certificate.
-
-   3.3.6  Validity Period
-
-   A certificate carries a pair of date and time indications, indicating
-   the start and end of the time period over which a certificate is
-   intended to be used.  The duration of the interval may be constant
-   for all user certificates issued by a given CA or it might differ
-   based on the nature of the user's affiliation.  For example, an
-   organization might issue certificates with shorter intervals to
-   temporary employees versus permanent employees.  It is recommended
-   that the UTCT (Coordinated Universal Time) values recorded here
-   specify granularity to no more than the minute, even though finer
-   granularity can be expressed in the format.  (Implementors are warned
-   that no DER is defined for UTCT in X.509, thus transformation between
-
-
-
-Kent                                                            [Page 8]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   local and transfer syntax must be performed carefully, e.g., when
-   computing the hash value for a certificate.  For example, a UTCT
-   value which includes explict, zero values for seconds would not
-   produce the same hash value as one in which the seconds were
-   omitted.) It also recommended that all times be expressed as
-   Greenwich Mean Time (Zulu), to simplify comparisons and avoid
-   confusion relating to daylight savings time.  Note that UTCT
-   expresses the value of a year modulo 100 (with no indication of
-   century), hence comparisons involving dates in different centuries
-   must be performed with care.
-
-   The longer the interval, the greater the likelihood that compromise
-   of a private component or name change will render it invalid and thus
-   require that the certificate be revoked.  Once revoked, the
-   certificate must remain on the issuer's CRL (see Section 3.4.3.4)
-   until the validity interval expires.  PCAs may impose restrictions on
-   the maximum validity interval that may be elected by CAs operating in
-   their certification domain (see Appendix B).
-
-   3.3.7  Subject Public Key
-
-   A certificate carries the public component of its associated subject,
-   as well as an indication of the algorithm, and any algorithm
-   parameters, with which the public component is to be used.  This
-   algorithm identifier is independent of that which is specified in the
-   signature field described above.  RFC 1423 specifies the algorithm
-   identifiers which may be used in this context.
-
-   3.4  Roles and Responsibilities
-
-   One way to explain the architecture proposed by this document is to
-   examine the roles which are defined for various entities in the
-   architecture and to describe what is required of each entity in order
-   for the proposed system to work properly.  The following sections
-   identify four types of entities within this architecture: users and
-   user agents, the Internet Policy Registration Authority, Policy
-   Certification Authorities, and other Certification Authorities.  For
-   each type of entity, this document specifies the procedures which the
-   entity must execute as part of the architecture and the
-   responsibilities the entity assumes as a function of its role in the
-   architecture.
-
-   3.4.1  Users and User Agents
-
-   The term User Agent (UA) is taken from CCITT X.400 Message Handling
-   Systems (MHS) Recommendations, which define it as follows: "In the
-   context of message handling, the functional object, a component of
-   MHS, by means of which a single direct user engages in message
-
-
-
-Kent                                                            [Page 9]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   handling."   In the Internet environment, programs such as rand mh
-   and Gnu emacs rmail are UAs.  UAs exchange messages by calling on a
-   supporting Message Transfer Service (MTS), e.g., the SMTP mail relays
-   used in the Internet.
-
-   3.4.1.1  Generating and Protecting Component Pairs
-
-   A UA process supporting PEM must protect the private component of its
-   associated entity (e.g., a human user or a mailing list) from
-   disclosure, though the means by which this is effected is a local
-   matter.  It is essential that the user take all available precautions
-   to protect his private component as the secrecy of this value is
-   central to the security offered by PEM to that user.   For example,
-   the private component might be stored in encrypted form, protected
-   with a locally managed symmetric encryption key (e.g., using DES).
-   The user would supply a password or passphrase which would be
-   employed as a symmetric key to decrypt the private component when
-   required for PEM processing (either on a per message or per session
-   basis).  Alternatively, the private component might be stored on a
-   diskette which would be inserted by the user whenever he originated
-   or received PEM messages.  Explicit zeroing of memory locations where
-   this component transiently resides could provide further protection.
-   Other precautions, based on local operating system security
-   facilities, also should be employed.
-
-   It is recommended that each user employ ancillary software (not
-   otherwise associated with normal UA operation) or hardware to
-   generate his personal public-key component pair.  Software for
-   generating user component pairs will be available as part of the
-   reference implementation of PEM distributed freely in the U.S.
-   portion of the Internet.  It is critically important that the
-   component pair generation procedure be effected in as secure a
-   fashion as possible, to ensure that the resulting private component
-   is unpredictable.  Introduction of adequate randomness into the
-   component pair generation procedure is potentially the most difficult
-   aspect of this process and the user is advised to pay particular
-   attention to this aspect.  (Component pairs employed in public-key
-   cryptosystems tend to be large integers which must be "randomly"
-   selected subject to mathematical constraints imposed by the
-   cryptosystem.  Input(s) used to seed the component pair generation
-   process must be as unpredictable as possible.  An example of a poor
-   random number selection technique is one in which a pseudo-random
-   number generator is seeded solely with the current date and time.  An
-   attacker who could determine approximately when a component pair was
-   generated could easily regenerate candidate component pairs and
-   compare the public component to the user's public component to detect
-   when the corresponding private component had been found.)
-
-
-
-
-Kent                                                           [Page 10]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   There is no requirement imposed by this architecture that anyone
-   other than the user, including any certification authority, have
-   access to the user's private component.  Thus a user may retain his
-   component pair even if his certificate changes, e.g., due to rollover
-   in the validity interval or because of a change of certifying
-   authority.  Even if a user is issued a certificate in the context of
-   his employment, there is generally no requirement that the employer
-   have access to the user's private component.  The rationale is that
-   any messages signed by the user are verifiable using his public
-   component.   In the event that the corresponding private component
-   becomes unavailable, any ENCRYPTED messages directed to the user
-   would be indecipherable and would require retransmission.
-
-   Note that if the user stores messages in ENCRYPTED form, these
-   messages also would become indecipherable in the event that the
-   private component is lost or changed.  To minimize the potential for
-   loss of data in such circumstances messages can be transformed into
-   MIC-ONLY or MIC-CLEAR form if cryptographically-enforced
-   confidentiality is not required for the messages stored within the
-   user's computer.  Alternatively, these transformed messages might be
-   forwarded in ENCRYPTED form to a (trivial) distribution list which
-   serves in a backup capacity and for which the user's employer holds
-   the private component.
-
-   A user may possess multiple certificates which may embody the same or
-   different public components.  For example, these certificates might
-   represent  a current and a former organizational user identity and a
-   residential user identity.  It is recommended that a PEM UA be
-   capable of supporting a user who possess multiple certificates,
-   irrespective of whether the certificates associated with the user
-   contain the same or different DNs or public components.
-
-   3.4.1.2  User Registration
-
-   Most details of user registration are a local matter, subject to
-   policies established by the user's CA and the PCA under which that CA
-   has been certified.  In general a user must provide, at a minimum,
-   his public component and distinguished name to a CA, or a
-   representative thereof, for inclusion in the user's certificate.
-   (The user also might provide a  complete certificate, minus the
-   signature, as described in RFC 1424.)  The CA will employ some means,
-   specified by the CA in accordance with the policy of its PCA, to
-   validate the user's claimed identity and to ensure that the public
-   component provided is associated with the user whose distinguished
-   name is to be bound into the certificate.  (In the case of PERSONA
-   certificates, described below, the procedure is a bit different.) The
-   certifying authority generates a certificate containing the user's
-   distinguished name and public component, the authority's
-
-
-
-Kent                                                           [Page 11]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   distinguished name and other information (see Section 3.3) and signs
-   the result using the private component of the authority.
-
-   3.4.1.3  CRL Management
-
-   Mechanisms for managing a UA certificate cache are, in typical
-   standards parlance, a local matter.  However, proper maintenance of
-   such a cache is critical to the correct, secure operation of a PEM UA
-   and provides a basis for improved performance.  Moreover, use of a
-   cache permits a PEM UA to operate in the absence of directories (and
-   in circumstances where directories are inaccessible).  The following
-   discussion  provides a paradigm for one aspect of cache management,
-   namely the processing of CRLs, the functional equivalent of which
-   must be embodied in any PEM UA implementation compliant with this
-   document.  The specifications for CRLs used with PEM are provided in
-   Section 3.5.
-
-   X.500 makes provision for the storage of CRLs as directory attributes
-   associated with CA entries.  Thus, when X.500 directories become
-   widely available, UAs can retrieve CRLs from directories as required.
-   In the interim, the IPRA will coordinate with PCAs to provide a
-   robust database facility which will contain CRLs issued by the IPRA,
-   by PCAs, and by all CAs.  Access to this database will be provided
-   through mailboxes maintained by each PCA.  Every PEM UA must provide
-   a facility for requesting CRLs from this database using the
-   mechanisms defined in RFC 1424.  Thus the UA must include a
-   configuration parameter which specifies one or more mailbox addresses
-   from which CRLs may be retrieved.  Access to the CRL database may be
-   automated, e.g., as part of the certificate validation process (see
-   Section 3.6) or may be user directed.  Responses to CRL requests will
-   employ the PEM header format specified in RFC 1421 for CRL
-   propagation.  As noted in RFC 1421, every PEM UA must be capable of
-   processing CRLs distributed via such messages.  This message format
-   also may be employed to support a "push" (versus a "pull") model of
-   CRL distribution, i.e., to support unsolicited distribution of CRLs.
-
-   CRLs received by a PEM UA must be validated (A CRL is validated in
-   much the same manner as a certificate, i.e., the CIC (see RFC 1113)
-   is calculated and compared against the decrypted signature value
-   obtained from the CRL.  See Section 3.6 for additional details
-   related to validation of certificates.) prior to being processed
-   against any cached certificate information.  Any cache entries which
-   match CRL entries should be marked as revoked, but it is not
-   necessary to delete cache entries marked as revoked nor to delete
-   subordinate entries.  In processing a CRL against the cache it is
-   important to recall that certificate serial numbers are unique only
-   for each issuer and that multiple, distinct CRLs may be issued under
-   the same CA DN (signed using different private components), so care
-
-
-
-Kent                                                           [Page 12]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   must be exercised in effecting this cache search.  (This situation
-   may arise either because an organizational CA is certified by
-   multiple PCAs, or because multiple residential CAs are certified
-   under different PCAs.)
-
-   This procedure applies to cache entries associated with PCAs and CAs,
-   as well as user entries.  The UA also must retain each CRL to screen
-   incoming messages to detect use of revoked certificates carried in
-   PEM message headers.  Thus a UA must be capable of processing and
-   retaining CRLs issued by the IPRA (which will list revoked PCA
-   certificates), by any PCA (which will list revoked CA certificate
-   issued by that PCA), and by any CA (which will list revoked user or
-   subordinate CA certificates issued by that CA).
-
-   3.4.1.4  Facilitating Interoperation
-
-   In the absence of ubiquitous directory services or knowledge
-   (acquired through out-of-band means) that a recipient already
-   possesses the necessary issuer certificates, it is recommended that
-   an originating (PEM) UA include sufficient certificates to permit
-   validation of the user's public key.  To this end every PEM UA must
-   be capable of including a full (originator) certification path, i.e.,
-   including the user's certificate (using the "Originator-Certificate"
-   field) and every superior (CA/PCA) certificate (using "Issuer-
-   Certificate" fields) back to the IPRA, in a PEM message.  A PEM UA
-   may send less than a full certification path, e.g., based on analysis
-   of a recipient list, but a UA which provides this sort of
-   optimization must also provide the user with a capability to force
-   transmission of a full certification path.
-
-   Optimization for the transmitted originator certification path may be
-   effected by a UA as a side effect of the processing performed during
-   message submission.  When an originator submits an ENCRYPTED message
-   (as per RFC 1421, his UA must validate the certificates of the
-   recipients (see Section 3.6).  In the course of performing this
-   validation the UA can determine the minimum set of certificates which
-   must be included to ensure that all recipients can process the
-   received message.  Submission of a MIC-ONLY or MIC-CLEAR message (as
-   per RFC 1421) does not entail validation of recipient certificates
-   and thus it may not be possible for the originator's UA to determine
-   the minimum certificate set as above.
-
-   3.4.2  The Internet Policy Registration Authority (IPRA)
-
-   The IPRA acts as the root of the certification hierarchy for the
-   Internet community.  The public component of the IPRA forms the
-   foundation for all certificate validation within this hierarchy.  The
-   IPRA will be operated under the auspices of the Internet Society, an
-
-
-
-Kent                                                           [Page 13]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   international, non-profit organization.  The IPRA certifies all PCAs,
-   ensuring that they agree to abide by the Internet-wide policy
-   established by the IPRA.  This policy, and the services provided by
-   the IPRA, are detailed below.
-
-   3.4.2.1  PCA Registration
-
-   The IPRA certifies only PCAs, not CAs or users.  Each PCA must file
-   with the IPRA a description of its proposed policy.  This document
-   will be published as an informational RFC.  A copy of the document,
-   signed by the IPRA (in the form of a PEM MIC-ONLY message) will be
-   made available via electronic mail access by the IPRA.  This
-   convention is adopted so that every Internet user has a reference
-   point for determining the policies associated with the issuance of
-   any certificate which he may encounter.  The existence of a digitally
-   signed copy of the document ensures the immutability of the document.
-   Authorization of a PCA to operate in the Internet hierarchy is
-   signified by the publication of the policy document, and the issuance
-   of a certificate to the PCA, signed by the IPRA.  An outline for PCA
-   policy statements is contained in Section 3.4.3 of this document.
-
-   As part of registration, each PCA will be required to execute a legal
-   agreement with the IPRA, and to pay a fee to defray the costs of
-   operating the IPRA.  Each a PCA must specify its distinguished name.
-   The IPRA will take reasonable precautions to ensure that the
-   distinguished name claimed by a PCA is legitimate, e.g., requiring
-   the PCA to provide documentation supporting its claim to a DN.
-   However, the certification of a PCA by the IPRA does not constitute a
-   endorsement of the PCA's claim to this DN outside of the context of
-   this certification system.
-
-   3.4.2.2  Ensuring the Uniqueness of Distinguished Names
-
-   A fundamental requirement of this certification scheme is that
-   certificates are not issued to distinct entities under the same
-   distinguished name.  This requirement is important to the success of
-   distributed management for the certification hierarchy.  The IPRA
-   will not certify two PCAs with the same distinguished name and no PCA
-   may certify two CAs with the same DN.  However, since PCAs are
-   expected to certify organizational CAs in widely disjoint portions of
-   the directory namespace, and since X.500 directories are not
-   ubiquitous, a facility is required for coordination among PCAs to
-   ensure the uniqueness of CA DNs.  (This architecture allows multiple
-   PCAs to certify residential CAs and thus multiple, distinct
-   residential CAs with identical DNs may come into existence, at least
-   until such time as civil authorities assume responsibilities for such
-   certification.  Thus, on an interim basis, the architecture
-   explicitly accommodates the potential for duplicate residential CA
-
-
-
-Kent                                                           [Page 14]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   DNs.)
-
-   In support of the uniqueness requirement, the IPRA will establish and
-   maintain a database to detect potential, unintended duplicate
-   certification of CA distinguished names.  This database will be made
-   accessible to all PCAs via an email interface.  Each entry in this
-   database will consist of a 4-tuple.  The first element in each entry
-   is a hash value, computed on a canonical, ASN.1 encoded
-   representation of a CA distinguished name.  The second element
-   contains the subjectPublicKey that appears in the CA's certificate.
-   The third element is the distinguished name of the PCA which
-   registered the entry.  The fourth element consists of the date and
-   time at which the entry was made, as established by the IPRA.  This
-   database structure provides a degree of privacy for CAs registered by
-   PCAs, while providing a facility for ensuring global uniqueness of CA
-   DNs certified in this scheme.
-
-   In order to avoid conflicts, a PCA should query the database using a
-   CA DN hash value as a search key, prior to certifying a CA.  The
-   database will return any entries which match the query, i.e., which
-   have the same CA DN.  The PCA can use the information contained in
-   any returned entries to determine if any PCAs should be contacted to
-   resolve possible DN conflicts.  If no potential conflicts appear, a
-   PCA can then submit a candidate entry, consisting of the first three
-   element values, plus any entries returned by the query.  The database
-   will register this entry, supplying the time and date stamp, only if
-   two conditions are met: (1) the first two elements (the CA DN hash
-   and the CA subjectPublicKey) of the candidate entry together must be
-   unique and, (2) any other entries included in the submission must
-   match what the current database would return if the query
-   corresponding to the candidate entry were submitted.
-
-   If the database detects a conflicting entry (failure of case 1
-   above), or if the submission indicates that the PCA's perception of
-   possible conflicting entries is not current (failure of case 2), the
-   submission is rejected and the database will return the potential
-   conflicting entry (entries).  If the submission is successful, the
-   database will return the timestamped new entry.  The database does
-   not, in itself, guarantee uniqueness of CA DNs as it allows for two
-   DNs associated with different public components to be registered.
-   Rather, it is the responsibility of PCAs to coordinate with one
-   another whenever the database indicates a potential DN conflict and
-   to resolve such conflicts prior to certification of CAs.  Details of
-   the protocol used to access the database will be provided in another
-   document.
-
-   As noted earlier, a CA may be certified under more than one PCA,
-   e.g., because the CA wants to issue certificates under two different
-
-
-
-Kent                                                           [Page 15]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   policies.  If a CA is certified by multiple different PCAs, the CA
-   must employ a different public key pair for each PCA.  In such
-   circumstances the certificate issued to the CA by each PCA will
-   contain a different subjectPublicKey and thus will represent a
-   different entry in this database.  The same situation may arise if
-   multiple, equivalent residential CAs are certified by different PCAs.
-
-   To complete the strategy for ensuring uniqueness of DNs, there is a
-   DN subordination requirement levied on CAs.  In general, CAs are
-   expected to sign certificates only if the subject DN in the
-   certificate is subordinate to the issuer (CA) DN.  This ensures that
-   certificates issued by a CA are syntactically constrained to refer to
-   subordinate entities in the X.500 directory information tree (DIT),
-   and this further limits the possibility of duplicate DN registration.
-   CAs may sign certificates which do not comply with this requirement
-   if the certificates are "cross-certificates" or "reverse
-   certificates" (see X.509) used with applications other than PEM.
-
-   The IPRA also will establish and maintain a separate database to
-   detect potential duplicate certification of (residential) user
-   distinguished names.  Each entry in this database will consist of 4-
-   tuple as above, but the first components is the hash of a residential
-   user DN and the third component is the DN of the residential CA DN
-   which registered the user.  This structure provides a degree of
-   privacy for users registered by CAs which service residential users
-   while providing a facility for ensuring global uniqueness of user DNs
-   certified under this scheme.  The same database access facilities are
-   provided as described above for the CA database.  Here it is the
-   responsibility of the CAs to coordinate whenever the database
-   indicates a potential conflict and to resolve the conflict prior to
-   (residential) user certification.
-
-   3.4.2.3  Accuracy of Distinguished Names
-
-   As noted above, the IPRA will make a reasonable effort to ensure that
-   PCA DNs are accurate.  The procedures employed to ensure the accuracy
-   of a CA distinguished name, i.e., the confidence attached to the
-   DN/public component binding implied by a certificate, will vary
-   according to PCA policy.  However, it is expected that every PCA will
-   make a good faith effort to ensure the legitimacy of each CA DN
-   certified by the PCA.  Part of this effort should include a check
-   that the purported CA DN is consistent with any applicable national
-   standards for DN assignment, e.g., NADF recommendations within North
-   America [5,9].
-
-
-
-
-
-
-
-Kent                                                           [Page 16]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   3.4.2.4  Distinguished Name Conventions
-
-   A few basic DN conventions are included in the IPRA policy.  The IPRA
-   will certify PCAs, but not CAs nor users.  PCAs will certify CAs, but
-   not users.  These conventions are required to allow simple
-   certificate validation within PEM, as described later.  Certificates
-   issued by CAs (for use with PEM) will be for users or for other CAs,
-   either of which must have DNs subordinate to that of the issuing CA.
-
-   The attributes employed in constructing DNs will be specified in a
-   list maintained by the IANA, to provide a coordinated basis for
-   attribute identification for all applications employing DNs.  This
-   list will initially be populated with attributes taken from X.520.
-   This document does not impose detailed restrictions on the attributes
-   used to identify different entities to which certificates are issued,
-   but PCAs may impose such restrictions as part of their policies.
-   PCAs, CAs and users are urged to employ only those DN attributes
-   which have printable representations, to facilitate display and
-   entry.
-
-   3.4.2.5  CRL Management
-
-   Among the procedures articulated by each PCA in its policy statement
-   are procedures for the maintenance and distribution of CRLs by the
-   PCA itself and by its subordinate CAs.  The frequency of issue of
-   CRLs may vary according to PCA-specific policy, but every PCA and CA
-   must issue a CRL upon inception to provide a basis for uniform
-   certificate validation procedures throughout the Internet hierarchy.
-   The IPRA will maintain a CRL for all the PCAs it certifies and this
-   CRL will be updated monthly.  Each PCA will maintain a CRL for all of
-   the CAs which it certifies and these CRLs will be updated in
-   accordance with each PCA's policy.   The format for these CRLs is
-   that specified in Section 3.5.2 of the document.
-
-   In the absence of ubiquitous X.500 directory services, the IPRA will
-   require each PCA to provide, for its users, robust database access to
-   CRLs for the Internet hierarchy, i.e., the IPRA CRL, PCA CRLs, and
-   CRLs from all CAs.  The means by which this database is implemented
-   is to be coordinated between the IPRA and PCAs.  This database will
-   be accessible via email as specified in RFC 1424, both for retrieval
-   of (current) CRLs by any user, and for submission of new CRLs by CAs,
-   PCAs and the IPRA.  Individual PCAs also may elect to maintain CRL
-   archives for their CAs, but this is not required by this policy.
-
-   3.4.2.6  Public Key Algorithm Licensing Issues
-
-   This certification hierarchy is architecturally independent of any
-   specific digital signature (public key) algorithm.  Some algorithms,
-
-
-
-Kent                                                           [Page 17]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   employed for signing certificates and validating certificate
-   signatures, are patented in some countries.  The IPRA will not grant
-   a license to any PCA for the use of any signature algorithm in
-   conjunction with the management of this certification hierarchy.  The
-   IPRA will acquire, for itself, any licenses needed for it to sign
-   certificates and CRLs for PCAs, for all algorithms which the IPRA
-   supports.  Every PCA will be required to represent to the IPRA that
-   the PCA has obtained any licenses required to issue (sign)
-   certificates and CRLs in the environment(s) which the PCA will serve.
-
-   For example, the RSA cryptosystem is patented in the United States
-   and thus any PCA operating in the U.S. and using RSA to sign
-   certificates and CRLs must represent that it has a valid license to
-   employ the RSA algorithm in this fashion.  In contrast, a PCA
-   employing RSA and operating outside of the U.S. would represent that
-   it is exempt from these licensing constraints.
-
-   3.4.3  Policy Certification Authorities
-
-   The policy statement submitted by a prospective PCA must address the
-   topics in the following outline.  Additional policy information may
-   be contained in the statement, but PCAs are requested not to use
-   these statements as advertising vehicles.
-
-   1. PCA Identity-  The DN of the PCA must be specified.  A postal
-   address, an Internet mail address, and telephone (and optional fax)
-   numbers must be provided for (human) contact with the PCA.  The date
-   on which this statement is effective, and its scheduled duration must
-   be specified.
-
-   2. PCA Scope- Each PCA must describe the community which the PCA
-   plans to serve.  A PCA should indicate if it will certify
-   organizational, residential, and/or PERSONA CAs.   There is not a
-   requirement that a single PCA serve only one type of CA, but if a PCA
-   serves multiple types of CAs, the policy statement must specify
-   clearly how a user can distinguish among these classes.  If the PCA
-   will operate CAs to directly serve residential or PERSONA users, it
-   must so state.
-
-   3. PCA Security & Privacy- Each PCA must specify the technical and
-   procedural security measures it will employ in the generation and
-   protection of its component pair.  If any security requirements are
-   imposed on CAs certified by the PCA these must be specified as well.
-   A PCA also must specify what measures it will take to protect the
-   privacy of any information collected in the course of certifying CAs.
-   If the PCA operates one or more CAs directly, to serve residential or
-   PERSONA users, then this statement on privacy measures applies to
-   these CAs as well.
-
-
-
-Kent                                                           [Page 18]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   4. Certification Policy-  Each PCA must specify the policy and
-   procedures which govern its certification of CAs and how this policy
-   applies transitively to entities (users or subordinate CAs) certified
-   by these CAs.  For example, a PCA must state what procedure is
-   employed to verify the claimed identity of a CA, and the CA's right
-   to use a DN.  Similarly, if any requirements are imposed on CAs to
-   validate the identity of users, these requirements must be specified.
-   Since all PCAs are required to cooperate in the resolution of
-   potential DN conflicts, each PCA is required to specify the procedure
-   it will employ to resolve such conflicts.  If the PCA imposes a
-   maximum validity interval for the CA certificates it issues, and/or
-   for user (or subordinate CA) certificates issued by the CAs it
-   certifies, then these restrictions must be specified.
-
-   5. CRL Management-  Each PCA must specify the frequency with which it
-   will issue scheduled CRLs.  It also must specify any constraints it
-   imposes on the frequency of scheduled issue of CRLs by the CAs it
-   certifies, and by subordinate CAs.  Both maximum and minimum
-   constraints should be specified.  Since the IPRA policy calls for
-   each CRL issued by a CA to be forwarded to the cognizant PCA, each
-   PCA must specify a mailbox address to which CRLs are to be
-   transmitted.  The PCA also must specify a mailbox address for CRL
-   queries.  If the PCA offers any additional CRL management services,
-   e.g., archiving of old CRLs, then procedures for invoking these
-   services must be specified.  If the PCA requires CAs to provide any
-   additional CRL management services, such services must be specified
-   here.
-
-   6. Naming Conventions- If the PCA imposes any conventions on DNs used
-   by the CAs it certifies, or by entities certified by these CAs, these
-   conventions must be specified.  If any semantics are associated with
-   such conventions, these semantics must be specified.
-
-   7. Business Issues- If a legal agreement must be executed between a
-   PCA and the CAs it certifies, reference to that agreement must be
-   noted, but the agreement itself ought not be a part of the policy
-   statement.  Similarly, if any fees are charged by the PCA this should
-   be noted, but the fee structure per se ought not be part of this
-   policy statement.
-
-   8. Other- Any other topics the PCA deems relevant to a statement of
-   its policy can be included.  However, the PCA should be aware that a
-   policy statement is considered to be an immutable, long lived
-   document and thus considerable care should be exercised in deciding
-   what material is to be included in the statement.
-
-
-
-
-
-
-Kent                                                           [Page 19]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   3.4.4  Certification Authorities
-
-   In X.509 the term "certification authority" is defined as "an
-   authority trusted by one or more users to create and assign
-   certificates".  X.509 imposes few constraints on CAs, but practical
-   implementation of a worldwide certification system requires
-   establishment of technical and procedural conventions by which all
-   CAs are expected to abide.  Such conventions are established
-   throughout this document.  All CAs are required to maintain a
-   database of the DNs which they have certified and to take measures to
-   ensure that they do not certify duplicate DNs, either for users or
-   for subordinate CAs.
-
-   It is critical that the private component of a CA be afforded a high
-   level of security, otherwise the authenticity guarantee implied by
-   certificates signed by the CA is voided.  Some PCAs may impose
-   stringent requirements on CAs within their purview to ensure that a
-   high level of security is afforded the certificate signing process,
-   but not all PCAs are expected to impose such constraints.
-
-   3.4.4.1  Organizational CAs
-
-   Many of the CAs certified by PCAs are expected to represent
-   organizations.  A wide range of organizations are encompassed by this
-   model: commercial, governmental, educational, non-profit,
-   professional societies, etc.  The common thread is that the entities
-   certified by these CAs have some form of affiliation with the
-   organization.  The object classes for organizations, organizational
-   units, organizational persons, organizational roles, etc., as defined
-   in X.521, form the models for entities certified by such CAs.  The
-   affiliation implied by organizational certification motivates the DN
-   subordination requirement cited in Section 3.4.2.4.
-
-   As an example, an organizational user certificate might contain a
-   subject DN of the form: C = "US" SP = "Massachusetts" L = "Cambridge"
-   O = "Bolt Beranek and Newman" OU = "Communications Division" CN =
-   "Steve Kent".  The issuer of this certificate might have a DN of the
-   form: C = "US" SP = "Massachusetts" L = "Cambridge" O= "Bolt Beranek
-   and Newman".  Note that the organizational unit attribute is omitted
-   from the issuer DN, implying that there is no CA dedicated to the
-   "Communications Division".
-
-   3.4.4.2  Residential CAs
-
-   Users may wish to obtain certificates which do not imply any
-   organizational affiliation but which do purport to accurately and
-   uniquely identify them.  Such users can be registered as residential
-   persons and the DN of such a user should be consistent with the
-
-
-
-Kent                                                           [Page 20]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   attributes of the corresponding X.521 object class.  Over time we
-   anticipate that such users will be accommodated by civil government
-   entities who will assume electronic certification responsibility at
-   geographically designated points in the naming hierarchy.  Until
-   civil authorities are prepared to issue certificates of this form,
-   residential user CAs will accommodate such users.
-
-   Because residential CAs may be operated under the auspices of
-   multiple PCAs, there is a potential for the same residential CA DN to
-   be assumed by several distinct entities.  This represents the one
-   exception to the rule articulated throughout this document that no
-   two entities may have the same DN.  This conflict is tolerated so as
-   to allow residential CAs to be established offering different
-   policies.  Two requirements are levied upon residential CAs as a
-   result: (1) residential CAs must employ the residential DN conflict
-   detection database maintained by the IPRA, and (2) residential CAs
-   must coordinate to ensure that they do not assign duplicate
-   certificate serial numbers.
-
-   As an example, a residential user certificate might include a subject
-   name of the form: C = "US" SP = "Massachusetts" L = "Boston" PA = "19
-   North Square" CN = "Paul Revere."  The issuer of that certificate
-   might have a DN of the form: C = "US"  SP = "Massachusetts" L =
-   "Boston".  Note that the issuer DN is superior to the subject DN, as
-   required by the IPRA policy described earlier.
-
-   3.4.4.3  PERSONA CAs
-
-   One or more CAs will be established to accommodate users who wish to
-   conceal their identities while making use of PEM security features,
-   e.g., to preserve the anonymity offered by "arbitrary" mailbox names
-   in the current mail environment.  In this case the certifying
-   authority is explicitly NOT vouching for the identity of the user.
-   All such certificates are issued under a PERSONA CA, subordinate to a
-   PCA with a PERSONA policy, to warn users explicitly that the subject
-   DN is NOT a validated user identity.  To minimize the possibility of
-   syntactic confusion with certificates which do purport to specify an
-   authenticated user identity, a PERSONA certificate is issued as a
-   form of organizational user certificate, not a residential user
-   certificate.  There are no explicit, reserved words used to identify
-   PERSONA user certificates.
-
-   A CA issuing PERSONA certificates must institute procedures to ensure
-   that it does not issue the same subject DN to multiple users (a
-   constraint required for all certificates of any type issued by any
-   CA).  There are no requirements on an issuer of PERSONA certificates
-   to maintain any other records that might bind the true identity of
-   the subject to his certificate.  However, a CA issuing such
-
-
-
-Kent                                                           [Page 21]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   certificates must establish procedures (not specified in this
-   document) in order to allow the holder of a PERSONA certificate to
-   request that his certificate be revoked (i.e., listed on a CRL).
-
-   As an example, a PERSONA user certificate might include a subject DN
-   of the form:  C = "US" SP = "Massachusetts" L = "Boston" O =
-   "Pseudonyms R US" CN = "Paul Revere."  The issuer of this certificate
-   might have a DN of the form: C = "US"  SP = "Massachusetts" L =
-   "Boston" O = "Pseudonyms R US".  Note the differences between this
-   PERSONA user certificate for "Paul Revere" and the corresponding
-   residential user certificate for the same common name.
-
-   3.4.4.4  CA Responsibilities for CRL Management
-
-   As X.500 directory servers become available, CRLs should be
-   maintained and accessed via these servers.  However, prior to
-   widespread deployment of X.500 directories, this document adopts some
-   additional requirements for CRL management by CAs and PCAs.  As per
-   X.509, each CA is required to maintain a CRL (in the format specified
-   by this document in Appendix A) which contains entries for all
-   certificates issued and later revoked by the CA.  Once a certificate
-   is entered on a CRL it remains there until the validity interval
-   expires.  Each PCA is required to maintain a CRL for revoked CA
-   certificates within its domain.  The interval at which a CA issues a
-   CRL is not fixed by this document, but the PCAs may establish minimum
-   and maximum intervals for such issuance.
-
-   As noted earlier, each PCA will provide access to a database
-   containing CRLs issued by the IPRA, PCAs, and all CAs.  In support of
-   this requirement, each CA must supply its current CRL to its PCA in a
-   fashion consistent with CRL issuance rules imposed by the PCA and
-   with the next scheduled issue date specified by the CA (see Section
-   3.5.1).  CAs may distribute CRLs to subordinate UAs using the CRL
-   processing type available in PEM messages (see RFC 1421).  CAs also
-   may provide access to CRLs via the database mechanism described in
-   RFC 1424 and alluded to immediately above.
-
-   3.5  Certificate Revocation
-
-   3.5.1  X.509 CRLs
-
-   X.509 states that it is a CA's responsibility to maintain: "a time-
-   stamped list of the certificates it issued which have been revoked."
-   There are two primary reasons for a CA to revoke a certificate, i.e.,
-   suspected compromise of a private component (invalidating the
-   corresponding public component) or change of user affiliation
-   (invalidating the DN).  The use of Certificate Revocation Lists
-   (CRLs) as defined in X.509 is one means of propagating information
-
-
-
-Kent                                                           [Page 22]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   relative to certificate revocation, though it is not a perfect
-   mechanism.  In particular, an X.509 CRL indicates only the age of the
-   information contained in it; it does not provide any basis for
-   determining if the list is the most current CRL available from a
-   given CA.
-
-   The proposed architecture establishes a format for a CRL in which not
-   only the date of issue, but also the next scheduled date of issue is
-   specified.  Adopting this convention, when the next scheduled issue
-   date arrives a CA (Throughout this section, when the term "CA" is
-   employed, it should be interpreted broadly, to include the IPRA and
-   PCAs as well as organizational, residential, and PERSONA CAs.) will
-   issue a new CRL, even if there are no changes in the list of entries.
-   In this fashion each CA can independently establish and advertise the
-   frequency with which CRLs are issued by that CA.  Note that this does
-   not preclude CRL issuance on a more frequent basis, e.g., in case of
-   some emergency, but no system-wide mechanisms are architected for
-   alerting users that such an unscheduled issuance has taken place.
-   This scheduled CRL issuance convention allows users (UAs) to
-   determine whether a given CRL is "out of date," a facility not
-   available from the (1988) X.509 CRL format.
-
-   The description of CRL management in the text and the format for CRLs
-   specified in X.509 (1988) are inconsistent.  For example, the latter
-   associates an issuer distinguished name with each revoked certificate
-   even though the text states that a CRL contains entries for only a
-   single issuer (which is separately specified in the CRL format).  The
-   CRL format adopted for PEM is a (simplified) format consistent with
-   the text of X.509, but not identical to the accompanying format. The
-   ASN.1 format for CRLs used with PEM is provided in Appendix A.
-
-   X.509 also defines a syntax for the "time-stamped list of revoked
-   certificates representing other CAs."  This syntax, the
-   "AuthorityRevocationList" (ARL) allows the list to include references
-   to certificates issued by CAs other than the list maintainer.  There
-   is no syntactic difference between these two lists except as they are
-   stored in directories.  Since PEM is expected to be used prior to
-   widespread directory deployment, this distinction between ARLs and
-   CRLs is not syntactically significant.  As a simplification, this
-   document specifies the use the CRL format defined below for
-   revocation both of user and of CA certificates.
-
-   3.5.2  PEM CRL Format
-
-   Appendix A contains the ASN.1 description of CRLs specified by this
-   document.  This section provides an informal description of CRL
-   components analogous to that provided for certificates in Section
-   3.3.
-
-
-
-Kent                                                           [Page 23]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-       1. signature (signature algorithm ID and parameters)
-
-       2. issuer
-
-       3. last update
-
-       4. next update
-
-       5. revoked certificates
-
-   The "signature" is a data item completely analogous to the signature
-   data item in a certificate. Similarly, the "issuer" is the DN of the
-   CA which signed the CRL.  The "last update" and "next update" fields
-   contain time and date values (UTCT format) which specify,
-   respectively, when this CRL was issued and when the next CRL is
-   scheduled to be issued.  Finally, "revoked certificates" is a
-   sequence of ordered pairs, in which the first element is the serial
-   number of the revoked certificate and the second element is the time
-   and date of the revocation for that certificate.
-
-   The semantics for this second element are not made clear in X.509.
-   For example, the time and date specified might indicate when a
-   private component was thought to have been compromised or it may
-   reflect when the report of such compromise was reported to the CA.
-
-   For uniformity, this document adopts the latter convention, i.e., the
-   revocation date specifies the time and date at which a CA formally
-   acknowledges a report of a compromise or a change or DN attributes.
-   As with certificates, it is recommended that the UTCT values be of no
-   finer granularity than minutes and that all values be stated in terms
-   of Zulu.
-
-   3.6  Certificate Validation
-
-   3.6.1  Validation Basics
-
-   Every UA must contain the public component of the IPRA as the root
-   for its certificate validation database.  Public components
-   associated with PCAs must be identified as such, so that the
-   certificate validation process described below can operate correctly.
-   Whenever a certificate for a PCA is entered into a UA cache, e.g., if
-   encountered in a PEM message encapsulated header, the certificate
-   must NOT be entered into the cache automatically.  Rather, the user
-   must be notified and must explicitly direct the UA to enter any PCA
-   certificate data into the cache.  This precaution is essential
-   because introduction of a PCA certificate into the cache implies user
-   recognition of the policy associated with the PCA.
-
-
-
-
-Kent                                                           [Page 24]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   Validating a certificate begins with verifying that the signature
-   affixed to the certificate is valid, i.e., that the hash value
-   computed on the certificate contents matches the value that results
-   from decrypting the signature field using the public component of the
-   issuer.  In order to perform this operation the user must possess the
-   public component of the issuer, either via some integrity-assured
-   channel, or by extracting it from another (validated) certificate.
-   In order to rapidly terminate this recursive validation process, we
-   recommend each PCA sign certificates for all CAs within its domain,
-   even CAs which are certified by other, superior CAs in the
-   certification hierarchy.
-
-   The public component needed to validate certificates signed by the
-   IPRA is made available to each user as part of the registration or
-   via the PEM installation process.  Thus a user will be able to
-   validate any PCA certificate immediately.  CAs are certified by PCAs,
-   so validation of a CA certificate requires processing a validation
-   path of length two.  User certificates are issued by CAs (either
-   immediately subordinate to PCAs or subordinate to other CAs), thus
-   validation of a user certificate may require three or more steps.
-   Local caching of validated certificates by a UA can be used to speed
-   up this process significantly.
-
-   Consider the situation in which a user receives a privacy enhanced
-   message from an originator with whom the recipient has never
-   previously corresponded, and assume that the message originator
-   includes a full certification path in the PEM message header.  First
-   the recipient can use the IPRA's public component to validate a PCA
-   certificate contained in an Issuer-Certificate field.  Using the
-   PCA's public component extracted from this certificate, the CA
-   certificate in an Issuer-Certificate field also can be validated.
-   This process cam be repeated until the certificate for the
-   originator, from the Originator-Certificate field, is validated.
-
-   Having performed this certificate validation process, the recipient
-   can extract the originator's public component and use it to decrypt
-   the content of the MIC-Info field.  By comparing the decrypted
-   contents of this field against the MIC computed locally on the
-   message the user verifies the data origin authenticity and integrity
-   of the message.  It is recommended that implementations of privacy
-   enhanced mail cache validated public components (acquired from
-   incoming mail) to speed up this process.  If a message arrives from
-   an originator whose public component is held in the recipient's cache
-   (and if the cache is maintained in a fashion that ensures timely
-   incorporation of received CRLs), the recipient can immediately employ
-   that public component without the need for the certificate validation
-   process described here. (For some digital signature algorithms, the
-   processing required for certificate validation is considerably faster
-
-
-
-Kent                                                           [Page 25]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   than that involved in signing a certificate.  Use of such algorithms
-   serves to minimize the computational burden on UAs.)
-
-   3.6.2  Display of Certificate Validation Data
-
-   PEM provides authenticated identities for message recipients and
-   originators expressed in the form of distinguished names.  Mail
-   systems in which PEM is employed may employ identifiers other than
-   DNs as the primary means of identifying recipients or originators.
-   Thus, in order to benefit from these authentication facilities, each
-   PEM implementation must employ some means of binding native mail
-   system identifiers to distinguished names in a fashion which does not
-   undermine this basic PEM functionality.
-
-   For example, if a human user interacts directly with PEM, then the
-   full DN of the originator of any message received using PEM should be
-   displayed for the user.  Merely displaying the PEM-protected message
-   content, containing an originator name from the native mail system,
-   does not provide equivalent security functionality and could allow
-   spoofing.  If the recipient of a message is a forwarding agent such
-   as a list exploder or mail relay, display of the originator's DN is
-   not a relevant requirement.  In all cases the essential requirement
-   is that the ultimate recipient of a PEM message be able to ascertain
-   the identity of the originator based on the PEM certification system,
-   not on unauthenticated identification information, e.g., extracted
-   from the native message system.
-
-   Conversely, for the originator of an ENCRYPTED message, it is
-   important that recipient identities be linked to the DNs as expressed
-   in PEM certificates.  This can be effected in a variety of ways by
-   the PEM implementation, e.g., by display of recipient DNs upon
-   message submission or by a tightly controlled binding between local
-   aliases and the DNs.  Here too, if the originator is a forwarding
-   process this linkage might be effected via various mechanisms not
-   applicable to direct human interaction.  Again, the essential
-   requirement is to avoid procedures which might undermine the
-   authentication services provided by PEM.
-
-   As described above, it is a local matter how and what certification
-   information is displayed for a human user in the course of submission
-   or delivery of a PEM message.  Nonetheless all PEM implementations
-   must provide a user with the ability to display a full certification
-   path for any certificate employed in PEM upon demand.  Implementors
-   are urged to not overwhelm the user with certification path
-   information which might confuse him or distract him from the critical
-   information cited above.
-
-
-
-
-
-Kent                                                           [Page 26]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   3.6.3  Validation Procedure Details
-
-   Every PEM implementation is required to perform the following
-   validation steps for every public component employed in the
-   submission of an ENCRYPTED PEM message or the delivery of an
-   ENCRYPTED, MIC-ONLY, or MIC-CLEAR PEM message.  Each public component
-   may be acquired from an internal source, e.g., from a (secure) cache
-   at the originator/recipient or it may be obtained from an external
-   source, e.g., the PEM header of an incoming message or a directory.
-   The following procedures applies to the validation of certificates
-   from either type of source.
-
-   Validation of a public component involves constructing a
-   certification path between the component and the public component of
-   the IPRA.  The validity interval for every certificate in this path
-   must be checked.  PEM software must, at a minimum, warn the user if
-   any certificate in the path fails the validity interval check, though
-   the form of this warning is a local matter.  For example, the warning
-   might indicate which certificate in the path had expired.  Local
-   security policy may prohibit use of expired certificates.
-
-   Each certificate also must be checked against the current CRL from
-   the certificate's issuer to ensure that revoked certificates are not
-   employed.  If the UA does not have access to the current CRL for any
-   certificate in the path, the user must be warned.  Again, the form of
-   the warning is a local matter.  For example, the warning might
-   indicate whether the CRL is unavailable or, if available but not
-   current, the CRL issue date should be displayed. Local policy may
-   prohibit use of a public component which cannot be checked against a
-   current CRL, and in such cases the user should receive the same
-   information provided by the warning indications described above.
-
-   If any revoked certificates are encountered in the construction of a
-   certification path, the user must be warned.  The form of the warning
-   is a local matter, but it is recommended that this warning be more
-   stringent than those previously alluded to above.  For example, this
-   warning might display the issuer and subject DNs from the revoked
-   certificate and the date of revocation, and then require the user to
-   provide a positive response before the submission or delivery process
-   may proceed.  In the case of message submission, the warning might
-   display the identity of the recipient affected by this validation
-   failure and the user might be provided with the option to specify
-   that this recipient be dropped from recipient list processing without
-   affecting PEM processing for the remaining recipients.  Local policy
-   may prohibit PEM processing if a revoked certificate is encountered
-   in the course of constructing a certification path.
-
-   Note that in order to comply with these validation procedures, a
-
-
-
-Kent                                                           [Page 27]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   certificate cache must maintain all of the information contained in a
-   certificate, not just the DNs and the public component.  For example
-   the serial number and validity interval must be associated with the
-   cache entry to comply with the checks described above.  Also note
-   that these procedures apply to human interaction in message
-   submission and delivery and are not directly applicable to forwarding
-   processes.  When non human interaction is involved, a compliant PEM
-   implementation must provide parameters to enable a process to specify
-   whether certificate validation will succeed or fail if any of the
-   conditions arise which would result in warnings to a human user.
-
-   Finally, in the course of validating certificates as described above,
-   one additional check must be performed: the subject DN of every
-   certificate must be subordinate to the certificate issuer DN, except
-   if the issuer is the IPRA or a PCA (hence another reason to
-   distinguish the IPRA and PCA entries in a certificate cache).  This
-   requirement is levied upon all PEM implementations as part of
-   maintaining the certification hierarchy constraints defined in this
-   document.  Any certificate which does not comply with these
-   requirements is considered invalid and must be rejected in PEM
-   submission or delivery processing.  The user  must be notified of the
-   nature of this fatal error.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent                                                           [Page 28]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-A.  Appendix A: ASN.1 Syntax for Certificates and CRLs
-
-A.1  Certificate Syntax
-
-   The X.509 certificate format is defined by the following ASN.1
-   syntax:
-
-   Certificate ::= SIGNED SEQUENCE{
-           version [0]     Version DEFAULT v1988,
-           serialNumber    CertificateSerialNumber,
-           signature       AlgorithmIdentifier,
-           issuer          Name,
-           validity        Validity,
-           subject         Name,
-           subjectPublicKeyInfo    SubjectPublicKeyInfo}
-
-   Version ::=     INTEGER {v1988(0)}
-
-   CertificateSerialNumber ::=     INTEGER
-
-   Validity ::=    SEQUENCE{
-           notBefore       UTCTime,
-           notAfter        UTCTime}
-
-   SubjectPublicKeyInfo ::=        SEQUENCE{
-           algorithm               AlgorithmIdentifier,
-           subjectPublicKey        BIT STRING}
-
-
-   AlgorithmIdentifier ::= SEQUENCE{
-           algorithm       OBJECT IDENTIFIER,
-           parameters      ANY DEFINED BY algorithm OPTIONAL}
-
-   The components of this structure are defined by ASN.1 syntax defined
-   in the X.500 Series Recommendations.  RFC 1423 provides references
-   for and the values of AlgorithmIdentifiers used by PEM in the
-   subjectPublicKeyInfo and the signature data items.  It also describes
-   how a signature is generated and the results represented.  Because
-   the certificate is a signed data object, the distinguished encoding
-   rules (see X.509, section 8.7) must be applied prior to signing.
-
-
-
-
-
-
-
-
-
-
-
-Kent                                                           [Page 29]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-A.2  Certificate Revocation List Syntax
-
-   The following ASN.1 syntax, derived from X.509 and aligned with the
-   suggested format in recently submitted defect reports, defines the
-   format of CRLs for use in the PEM environment.
-
-   CertificateRevocationList ::= SIGNED SEQUENCE{
-           signature       AlgorithmIdentifier,
-           issuer          Name,
-           lastUpdate      UTCTime,
-           nextUpdate      UTCTime,
-           revokedCertificates
-                           SEQUENCE OF CRLEntry OPTIONAL}
-
-   CRLEntry ::= SEQUENCE{
-           userCertificate SerialNumber,
-           revocationDate UTCTime}
-
-References
-
-   [1] CCITT Recommendation X.411 (1988), "Message Handling Systems:
-       Message Transfer System: Abstract Service Definition and
-       Procedures".
-
-   [2] CCITT Recommendation X.509 (1988), "The Directory -
-       Authentication Framework".
-
-   [3] CCITT Recommendation X.520 (1988), "The Directory - Selected
-       Attribute Types".
-
-   [4] NIST Special Publication 500-183, "Stable Agreements for Open
-       Systems Interconnection Protocols," Version 4, Edition 1,
-       December 1990.
-
-   [5] North American Directory Forum, "A Naming Scheme for c=US", RFC
-       1255, NADF, September 1991.
-
-   [6] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
-       I: Message Encryption and Authentication Procedures", RFC 1421,
-       DEC, February 1993.
-
-   [7] Balenson, D., "Privacy Enhancement for Internet Electronic Mail:
-       Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS,
-       February 1993.
-
-   [8] Balaski, B., "Privacy Enhancement for Internet Electronic Mail:
-       Part IV: Notary, Co-Issuer, CRL-Storing and CRL-Retrieving
-       Services", RFC 1424, RSA Laboratories, February 1993.
-
-
-
-Kent                                                           [Page 30]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   [9] North American Directory Forum, "NADF Standing Documents: A Brief
-       Overview", RFC 1417, NADF, February 1993.
-
-Patent Statement
-
-   This version of Privacy Enhanced Mail (PEM) relies on the use of
-   patented public key encryption technology for authentication and
-   encryption.  The Internet Standards Process as defined in RFC 1310
-   requires a written statement from the Patent holder that a license
-   will be made available to applicants under reasonable terms and
-   conditions prior to approving a specification as a Proposed, Draft or
-   Internet Standard.
-
-   The Massachusetts Institute of Technology and the Board of Trustees
-   of the Leland Stanford Junior University have granted Public Key
-   Partners (PKP) exclusive sub-licensing rights to the following
-   patents issued in the United States, and all of their corresponding
-   foreign patents:
-
-      Cryptographic Apparatus and Method
-      ("Diffie-Hellman")............................... No. 4,200,770
-
-      Public Key Cryptographic Apparatus
-      and Method ("Hellman-Merkle").................... No. 4,218,582
-
-      Cryptographic Communications System and
-      Method ("RSA")................................... No. 4,405,829
-
-      Exponential Cryptographic Apparatus
-      and Method ("Hellman-Pohlig").................... No. 4,424,414
-
-   These patents are stated by PKP to cover all known methods of
-   practicing the art of Public Key encryption, including the variations
-   collectively known as El Gamal.
-
-   Public Key Partners has provided written assurance to the Internet
-   Society that parties will be able to obtain, under reasonable,
-   nondiscriminatory terms, the right to use the technology covered by
-   these patents.  This assurance is documented in RFC 1170 titled
-   "Public Key Standards and Licenses".  A copy of the written assurance
-   dated April 20, 1990, may be obtained from the Internet Assigned
-   Number Authority (IANA).
-
-   The Internet Society, Internet Architecture Board, Internet
-   Engineering Steering Group and the Corporation for National Research
-   Initiatives take no position on the validity or scope of the patents
-   and patent applications, nor on the appropriateness of the terms of
-   the assurance.  The Internet Society and other groups mentioned above
-
-
-
-Kent                                                           [Page 31]
-
-RFC 1422           Certificate-Based Key Management        February 1993
-
-
-   have not made any determination as to any other intellectual property
-   rights which may apply to the practice of this standard. Any further
-   consideration of these matters is the user's own responsibility.
-
-Security Considerations
-
-   This entire document is about security.
-
-Author's Address
-
-   Steve Kent
-   BBN Communications
-   50 Moulton Street
-   Cambridge, MA 02138
-
-   Phone: (617) 873-3988
-   EMail: kent@BBN.COM
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent                                                           [Page 32]
-
\ No newline at end of file
diff --git a/doc/protocol/rfc1423.txt b/doc/protocol/rfc1423.txt
deleted file mode 100644
index 35d0e01bef..0000000000
--- a/doc/protocol/rfc1423.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Balenson
-Request for Comments: 1423                                           TIS
-Obsoletes: 1115                               IAB IRTF PSRG, IETF PEM WG
-                                                           February 1993
-
-
-           Privacy Enhancement for Internet Electronic Mail:
-              Part III: Algorithms, Modes, and Identifiers
-
-Status of This Memo
-
-   This RFC specifies an IAB standards track protocol for the Internet
-   community, and requests discussion and suggestions for improvements.
-   Please refer to the current edition of the "IAB Official Protocol
-   Standards" for the standardization state and status of this protocol.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document provides definitions, formats, references, and
-   citations for cryptographic algorithms, usage modes, and associated
-   identifiers and parameters used in support of Privacy Enhanced Mail
-   (PEM) in the Internet community.  It is intended to become one member
-   of the set of related PEM RFCs.  This document is organized into four
-   primary sections, dealing with message encryption algorithms, message
-   integrity check algorithms, symmetric key management algorithms, and
-   asymmetric key management algorithms (including both asymmetric
-   encryption and asymmetric signature algorithms).
-
-   Some parts of this material are cited by other documents and it is
-   anticipated that some of the material herein may be changed, added,
-   or replaced without affecting the citing documents.  Therefore,
-   algorithm-specific material has been placed into this separate
-   document.
-
-   Use of other algorithms and/or modes will require case-by-case study
-   to determine applicability and constraints.  The use of additional
-   algorithms may be documented first in Prototype or Experimental RFCs.
-   As experience is gained, these protocols may be considered for
-   incorporation into the standard.  Additional algorithms and modes
-   approved for use in PEM in this context will be specified in
-   successors to this document.
-
-Acknowledgments
-
-   This specification was initially developed by the Internet Research
-   Task Force's Privacy and Security Research Group (IRTF PSRG) and
-   subsequently refined based on discussion in the Internet Engineering
-
-
-
-Balenson                                                        [Page 1]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   Task Force's Privacy Enhanced Mail Working Group (IETF PEM WG).  John
-   Linn contributed significantly to the predecessor of this document
-   (RFC 1115).  I would like to thank the members of the PSRG and PEM
-   WG, as well as all participants in discussions on the "pem-
-   dev@tis.com" mailing list, for their contributions to this document.
-
-Table of Contents
-
-      1.  Message Encryption Algorithms ....................... 2
-      1.1  DES in CBC Mode (DES-CBC) .......................... 2
-      2.  Message Integrity Check Algorithms .................. 4
-      2.1  RSA-MD2 Message Digest Algorithm ................... 4
-      2.2  RSA-MD5 Message Digest Algorithm ................... 5
-      3.  Symmetric Key Management Algorithms ................. 6
-      3.1  DES in ECB mode (DES-ECB) .......................... 6
-      3.2  DES in EDE mode (DES-EDE) .......................... 7
-      4.  Asymmetric Key Management Algorithms ................ 7
-      4.1  Asymmetric Keys .................................... 7
-      4.1.1  RSA Keys ......................................... 7
-      4.2  Asymmetric Encryption Algorithms ..................  9
-      4.2.1  RSAEncryption ...................................  9
-      4.3  Asymmetric Signature Algorithms ................... 10
-      4.3.1  md2WithRSAEncryption ............................ 11
-      5.  Descriptive Grammar ................................ 11
-      References ............................................. 12
-      Patent Statement ....................................... 13
-      Security Considerations ................................ 14
-      Author's Address ....................................... 14
-
-1.  Message Encryption Algorithms
-
-   This section identifies the alternative message encryption algorithms
-   and modes that shall be used to encrypt message text and, when
-   asymmetric key management is employed in an ENCRYPTED PEM message, for
-   encryption of message signatures.  Character string identifiers are
-   assigned and any parameters required by the message encryption
-   algorithm are defined for incorporation in an encapsulated "DEK-
-   Info:" header field.
-
-   Only one alternative is currently defined in this category.
-
-1.1  DES in CBC Mode (DES-CBC)
-
-   Message text and, if required, message signatures are encrypted using
-   the Data Encryption Standard (DES) algorithm in the Cipher Block
-   Chaining (CBC) mode of operation.  The DES algorithm is defined in
-   FIPS PUB 46-1 [1], and is equivalent to the Data Encryption Algorithm
-   (DEA) provided in ANSI X3.92-1981 [2].  The CBC mode of operation of
-
-
-
-Balenson                                                        [Page 2]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   DES is defined in FIPS PUB 81 [3], and is equivalent to those
-   provided in ANSI X3.106 [4] and in ISO IS 8372 [5].  The character
-   string "DES-CBC" within an encapsulated PEM header field indicates
-   the use of this algorithm/mode combination.
-
-   The input to the DES CBC encryption process shall be padded to a
-   multiple of 8 octets, in the following manner.  Let n be the length
-   in octets of the input.  Pad the input by appending 8-(n mod 8)
-   octets to the end of the message, each having the value 8-(n mod 8),
-   the number of octets being added.  In hexadecimal, the possible
-   paddings are:  01, 0202, 030303, 04040404, 0505050505, 060606060606,
-   07070707070707, and 0808080808080808.  All input is padded with 1 to
-   8 octets to produce a multiple of 8 octets in length.  The padding
-   can be removed unambiguously after decryption.
-
-   The DES CBC encryption process requires a 64-bit cryptographic key.
-   A new, pseudorandom key shall be generated for each ENCRYPTED PEM
-   message.  Of the 64 bits, 56 are used directly by the DES CBC
-   process, and 8 are odd parity bits, with one parity bit occupying the
-   right-most bit of each octet.  When symmetric key management is
-   employed, the setting and checking of odd parity bits is encouraged,
-   since these bits could detect an error in the decryption of a DES key
-   encrypted under a symmetric key management algorithm (e.g., DES ECB).
-   When asymmetric key management is employed, the setting of odd parity
-   bits is encouraged, but the checking of odd parity bits is
-   discouraged, in order to facilitate interoperability, and since an
-   error in the decryption of a DES key can be detected by other means
-   (e.g., an incorrect PKCS #1 encryption-block format).  In all cases,
-   the encrypted form of a DES key shall carry all 64 bits of the key,
-   including the 8 parity bits, though those bits may have no meaning.
-
-   The DES CBC encryption process also requires a 64-bit Initialization
-   Vector (IV).  A new, pseudorandom IV shall be generated for each
-   ENCRYPTED PEM message.  Section 4.3.1 of [7] provides rationale for
-   this requirement, even given the fact that individual DES keys are
-   generated for individual messages.  The IV is transmitted with the
-   message within an encapsulated PEM header field.
-
-   When this algorithm/mode combination is used for message text
-   encryption, the "DEK-Info:" header field carries exactly two
-   arguments.  The first argument identifies the DES CBC algorithm/mode
-   using the character string defined above.  The second argument
-   contains the IV, represented as a contiguous string of 16 ASCII
-   hexadecimal digits.
-
-   When symmetric key management is employed with this algorithm/mode
-   combination, a symmetrically encrypted DES key will be represented in
-   the third argument of a "Key-Info:" header field as a contiguous
-
-
-
-Balenson                                                        [Page 3]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   string of 16 ASCII hexadecimal digits (corresponding to a 64-bit
-   key).
-
-   To avoid any potential ambiguity regarding the ordering of the octets
-   of a DES key that is input as a data value to another encryption
-   process (e.g., RSAEncryption), the following holds true.  The first
-   (or left-most displayed, if one thinks in terms of a key's "print"
-   representation) (For purposes of discussion in this document, data
-   values are normalized in terms of their "print" representation.  For a
-   octet stream, the "first" octet would appear as the one on the "left",
-   and the "last" octet would appear on the "right".) octet of the key
-   (i.e., bits 1-8 per FIPS PUB 46-1), when considered as a data value,
-   has numerical weight 2**56.  The last (or right-most displayed) octet
-   (i.e., bits 57-64 per FIPS PUB 46-1) has numerical weight 2**0.
-
-2.  Message Integrity Check Algorithms
-
-   This section identifies the alternative algorithms that shall be used
-   to compute Message Integrity Check (MIC) values for PEM messages.
-   Character string identifiers and ASN.1 object identifiers are
-   assigned for incorporation in encapsulated "MIC-Info:" and "Key-
-   Info:" header fields to indicate the choice of MIC algorithm
-   employed.
-
-   A compliant PEM implementation shall be able to process all of the
-   alternative MIC algorithms defined here on incoming messages.  It is
-   a sender option as to which alternative is employed on an outbound
-   message.
-
-2.1  RSA-MD2 Message Digest Algorithm
-
-   The RSA-MD2 message digest is computed using the algorithm defined in
-   RFC 1319 [9].  ( An error has been identified in RFC 1319.  The
-   statement in the text of Section 3.2 which reads "Set C[j] to S[c xor
-   L]" should read "Set C[j] to S[c xor L] xor C[j]".  Note that the C
-   source code in the appendix of RFC 1319 is correct.)  The character
-   string "RSA-MD2" within an encapsulated PEM header field indicates the
-   use of this algorithm.  Also, as defined in RFC 1319, the ASN.1 object
-   identifier
-
-     md2 OBJECT IDENTIFIER ::= {
-         iso(1) member-body(2) US(840) rsadsi(113549)
-         digestAlgorithm(2) 2
-     }
-
-   identifies this algorithm.  When this object identifier is used with
-   the ASN.1 type AlgorithmIdentifier, the parameters component of that
-   type is the ASN.1 type NULL.
-
-
-
-Balenson                                                        [Page 4]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   The RSA-MD2 message digest algorithm accepts as input a message of
-   any length and produces as output a 16-octet quantity.  When
-   symmetric key management is employed, an RSA-MD2 MIC is encrypted by
-   splitting the MIC into two 8-octet halves, independently encrypting
-   each half, and concatenating the results.
-
-   When symmetric key management is employed with this MIC algorithm,
-   the symmetrically encrypted MD2 message digest is represented in a
-   the fourth argument of a "Key-Info:" header field as a contiguous
-   string of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD2
-   message digest).
-
-   To avoid any potential ambiguity regarding the ordering of the octets
-   of an MD2 message digest that is input as a data value to another
-   encryption process (e.g., RSAEncryption), the following holds true.
-   The first (or left-most displayed, if one thinks in terms of a
-   digest's "print" representation) octet of the digest (i.e., digest[0]
-   as specified in RFC 1319), when considered as an RSA data value, has
-   numerical weight 2**120.  The last (or right-most displayed) octet
-   (i.e., digest[15] as specified in RFC 1319) has numerical weight
-   2**0.
-
-2.2  RSA-MD5 Message Digest Algorithm
-
-   The RSA-MD5 message digest is computed using the algorithm defined in
-   RFC 1321 [10].  The character string "RSA-MD5" within an encapsulated
-   PEM header field indicates the use of this algorithm.  Also, as
-   defined in RFC 1321, the object identifier
-
-     md5 OBJECT IDENTIFIER ::= {
-         iso(1) member-body(2) US(840) rsadsi(113549)
-         digestAlgorithm(2) 5
-     }
-
-   identifies this algorithm.  When this object identifier is used with
-   the ASN.1 type AlgorithmIdentifier, the parameters component of that
-   type is the ASN.1 type NULL.
-
-   The RSA-MD5 message digest algorithm accepts as input a message of
-   any length and produces as output a 16-octet quantity.  When
-   symmetric key management is employed, an RSA-MD5 MIC is encrypted by
-   splitting the MIC into two 8-octet halves, independently encrypting
-   each half, and concatenating the results.
-
-   When symmetric key management is employed with this MIC algorithm,
-   the symmetrically encrypted MD5 message digest is represented in the
-   fourth argument of a "Key-Info:" header field as a contiguous string
-   of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD5
-
-
-
-Balenson                                                        [Page 5]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   message digest).
-
-   To avoid any potential ambiguity regarding the ordering of the octets
-   of a MD5 message digest that is input as an RSA data value to the RSA
-   encryption process, the following holds true.  The first (or left-
-   most displayed, if one thinks in terms of a digest's "print"
-   representation) octet of the digest (i.e., the low-order octet of A
-   as specified in RFC 1321), when considered as an RSA data value, has
-   numerical weight 2**120.  The last (or right-most displayed) octet
-   (i.e., the high-order octet of D as specified in RFC 1321) has
-   numerical weight 2**0.
-
-3.  Symmetric Key Management Algorithms
-
-   This section identifies the alternative algorithms and modes that
-   shall be used when symmetric key management is employed, to encrypt
-   data encryption keys (DEKs) and message integrity check (MIC) values.
-   Character string identifiers are assigned for incorporation in
-   encapsulated "Key-Info:" header fields to indicate the choice of
-   algorithm employed.
-
-   All alternatives presently defined in this category correspond to
-   different usage modes of the DES algorithm, rather than to other
-   algorithms.
-
-   When symmetric key management is employed, the symmetrically
-   encrypted DEK and MIC, carried in the third and fourth arguments of a
-   "Key-Info:" header field, respectively, are each represented as a
-   string of contiguous ASCII hexadecimal digits.  The manner in which
-   to use the following symmetric encryption algorithms and the length
-   of the symmetrically encrypted DEK and MIC may vary depending on the
-   length of the underlying DEK and MIC.  Section 1, Message Encryption
-   Algorithms, and Section 2, Message Integrity Check Algorithms,
-   provide information on the proper manner in which a DEK and MIC,
-   respectively, are symmetrically encrypted when the size of the DEK or
-   MIC is not equal to the symmetric encryption algorithm's input block
-   size.  These sections also provide information on the proper format
-   and length of the symmetrically encrypted DEK and MIC, respectively.
-
-3.1  DES in ECB Mode (DES-ECB)
-
-   The DES algorithm in Electronic Codebook (ECB) mode [1][3] is used
-   for DEK and MIC encryption when symmetric key management is employed.
-   The character string "DES-ECB" within an encapsulated PEM header
-   field indicates use of this algorithm/mode combination.
-
-   A compliant PEM implementation supporting symmetric key management
-   shall support this algorithm/mode combination.
-
-
-
-Balenson                                                        [Page 6]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-3.2  DES in EDE Mode (DES-EDE)
-
-   The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) multiple
-   encryption mode, as defined by ANSI X9.17 [6] for encryption and
-   decryption with pairs of 64-bit keys, may be used for DEK and MIC
-   encryption when symmetric key management is employed.  The character
-   string "DES-EDE" within an encapsulated a PEM header field indicates
-   use of this algorithm/mode combination.
-
-   A compliant PEM implementation supporting symmetric key management
-   may optionally support this algorithm/mode combination.
-
-4.  Asymmetric Key Management Algorithms
-
-   This section identifies the alternative asymmetric keys and the
-   alternative asymmetric key management algorithms with which those
-   keys shall be used, namely the asymmetric encryption algorithms with
-   which DEKs and MICs are encrypted, and the asymmetric signature
-   algorithms with which certificates and certificate revocation lists
-   (CRLs) are signed.
-
-4.1  Asymmetric Keys
-
-   This section describes the asymmetric keys that shall be used with
-   the asymmetric encryption algorithms and the signature algorithms
-   described later.  ASN.1 object identifiers are identified for
-   incorporation in a public-key certificate to identify the
-   algorithm(s) with which the accompanying public key is to be
-   employed.
-
-4.1.1  RSA Keys
-
-   An RSA asymmetric key pair is comprised of matching public and
-   private keys.
-
-   An RSA public key consists of an encryption exponent e and an
-   arithmetic modulus n, which are both public quantities typically
-   carried in a public-key certificate.  For the value of e, Annex C to
-   X.509 suggests the use of Fermat's Number F4 (65537 decimal, or
-   1+2**16) as a value "common to the whole environment in order to
-   reduce transmission capacity and complexity of transformation", i.e.,
-   the value can be transmitted as 3 octets and at most seventeen (17)
-   multiplications are required to effect exponentiation.  As an
-   alternative, the number three (3) can be employed as the value for e,
-   requiring even less octets for transmission and yielding even faster
-   exponentiation.  For purposes of PEM, the value of e shall be either
-   F4 or the number three (3).  The use of the number three (3) for the
-   value of e is encouraged, to permit rapid certificate validation.
-
-
-
-Balenson                                                        [Page 7]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   An RSA private key consists of a decryption exponent d, which should
-   be kept secret, and the arithmetic modulus n.  Other values may be
-   stored with a private key to facilitate efficient private key
-   operations (see PKCS #1 [11]).
-
-   For purposes of PEM, the modulus n may vary in size from 508 to 1024
-   bits.
-
-   Two ASN.1 object identifiers have been defined to identify RSA public
-   keys.  In Annex H of X.509 [8], the object identifier
-
-     rsa OBJECT IDENTIFIER ::= {
-         joint-iso-ccitt(2) ds(5) algorithm(8)
-         encryptionAlgorithm(1) 1
-     }
-
-   is defined to identify an RSA public key.  A single parameter,
-   KeySize, the length of the public key modulus in bits, is defined for
-   use in conjunction with this object identifier.  When this object
-   identifier is used with the ASN.1 type AlgorithmIdentifier, the
-   parameters component of that type is the number of bits in the
-   modulus, ASN.1 encoded as an INTEGER.
-
-   Alternatively, in PKCS #1 [11], the ASN.1 object identifier
-
-     rsaEncryption OBJECT IDENTIFIER ::= {
-         iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
-         pkcs-1(1) 1
-     }
-
-   is defined to identify both an RSA public key and the RSAEncryption
-   process.  There are no parameters defined in conjunction with this
-   object identifier, hence, when it is used with the ASN.1 type
-   AlgorithmIdentifier, the parameters component of that type is the
-   ASN.1 type NULL.
-
-   A compliant PEM implementation may optionally generate an RSA
-   public-key certificate that identifies the enclosed RSA public key
-   (within the SubjectPublicKeyInformation component) with either the
-   "rsa" or the "rsaEncryption" object identifier.  Use of the "rsa"
-   object identifier is encouraged, since it is, in some sense, more
-   generic in its identification of a key, without indicating how the
-   key will be used.  However, to facilitate interoperability, a
-   compliant PEM implementation shall accept RSA public-key certificates
-   that identify the enclosed RSA public key with either the "rsa" or
-   the "rsaEncryption" object identifier.  In all cases, an RSA public
-   key identified in an RSA public-key certificate with either the "rsa"
-   or "rsaEncryption" object identifier, shall be used according to the
-
-
-
-Balenson                                                        [Page 8]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   procedures defined below for asymmetric encryption algorithms and
-   asymmetric signature algorithms.
-
-4.2  Asymmetric Encryption Algorithms
-
-   This section identifies the alternative algorithms that shall be used
-   when asymmetric key management is employed, to encrypt DEKs and MICs.
-   Character string identifiers are assigned for incorporation in "MIC-
-   Info:" and "Key-Info:" header fields to indicate the choice of
-   algorithm employed.
-
-   Only one alternative is presently defined in this category.
-
-4.2.1  RSAEncryption
-
-   The RSAEncryption public-key encryption algorithm, defined in PKCS #1
-   [11], is used for DEK and MIC encryption when asymmetric key
-   management is employed.  The character string "RSA" within a "MIC-
-   Info:" or "Key-Info:" header field indicates the use of this
-   algorithm.
-
-   All PEM implementations supporting asymmetric key management shall
-   support this algorithm.
-
-   As described in PKCS #1, all quantities input as data values to the
-   RSAEncryption process shall be properly justified and padded to the
-   length of the modulus prior to the encryption process.  In general,
-   an RSAEncryption input value is formed by concatenating a leading
-   NULL octet, a block type BT, a padding string PS, a NULL octet, and
-   the data quantity D, that is,
-
-     RSA input value = 0x00 || BT || PS || 0x00 || D.
-
-   To prepare a DEK for RSAEncryption, the PKCS #1 "block type 02"
-   encryption-block formatting scheme is employed.  The block type BT is
-   a single octet containing the value 0x02 and the padding string PS is
-   one or more octets (enough octets to make the length of the complete
-   RSA input value equal to the length of the modulus) each containing a
-   pseudorandomly generated, non-zero value.  For multiple recipient
-   messages, a different, pseudorandom padding string should be used for
-   each recipient.  The data quantity D is the DEK itself, which is
-   right-justified within the RSA input such that the last (or rightmost
-   displayed, if one thinks in terms of the "print" representation)
-   octet of the DEK is aligned with the right-most, or least-
-   significant, octet of the RSA input.  Proceeding to the left, each of
-   the remaining octets of the DEK, up through the first (or left-most
-   displayed) octet, are each aligned in the next more significant octet
-   of the RSA input.
-
-
-
-Balenson                                                        [Page 9]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   To prepare a MIC for RSAEncryption, the PKCS #1 "block type 01"
-   encryption-block formatting scheme is employed.  The block type BT is
-   a single octet containing the value 0x01 and the padding string PS is
-   one or more octets (enough octets to make the length of the complete
-   RSA input value equal to the length of the modulus) each containing
-   the value 0xFF.  The data quantity D is comprised of the MIC and the
-   MIC algorithm identifier which are ASN.1 encoded as the following
-   sequence.
-
-     SEQUENCE {
-         digestAlgorithm   AlgorithmIdentifier,
-         digest            OCTET STRING
-     }
-
-   The ASN.1 type AlgorithmIdentifier is defined in X.509 as follows.
-
-     AlgorithmIdentifier ::= SEQUENCE {
-         algorithm         OBJECT IDENTIFIER,
-         parameters        ANY DEFINED BY algorithm OPTIONAL
-     }
-
-   An RSA input block is encrypted using the RSA algorithm with the
-   first (or left-most) octet taken as the most significant octet, and
-   the last (or right-most) octet taken as the least significant octet.
-   The resulting RSA output block is interpreted in a similar manner.
-
-   When RSAEncryption is used to encrypt a DEK, the second argument in a
-   "MIC-Info:" header field, an asymmetrically encrypted DEK, is
-   represented using the printable encoding technique defined in Section
-   4.3.2.4 of RFC 1421 [12].
-
-   When RSAEncryption is used to sign a MIC, the third argument in a
-   "MIC-Info:" header field, an asymmetrically signed MIC, is
-   represented using the printable encoding technique defined in Section
-   4.3.2.4 of RFC 1421.
-
-4.3  Asymmetric Signature Algorithms
-
-   This section identifies the alternative algorithms which shall be
-   used to asymmetrically sign certificates and certificate revocation
-   lists (CRLs) in accordance with the SIGNED macro defined in Annex G
-   of X.509.  ASN.1 object identifiers are identified for incorporation
-   in certificates and CRLs to indicate the choice of algorithm
-   employed.
-
-   Only one alternative is presently defined in this category.
-
-
-
-
-
-Balenson                                                       [Page 10]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-4.3.1  md2WithRSAEncryption
-
-   The md2WithRSAEncryption signature algorithm is used to sign
-   certificates and CRLs.  The algorithm is defined in PKCS #1 [11].  It
-   combines the RSA-MD2 message digest algorithm described here in
-   Section 2.2 with the RSAEncryption asymmetric encryption algorithm
-   described here in Section 4.2.1.  As defined in PKCS #1, the ASN.1
-   object identifier
-
-     md2WithRSAEncryption OBJECT IDENTIFIER ::= {
-         iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
-         pkcs-1(1) 2
-     }
-
-   identifies this algorithm.  When this object identifier is used with
-   the ASN.1 type AlgorithmIdentifier, the parameters component of that
-   type is the ASN.1 type NULL.
-
-   There is some ambiguity in X.509 regarding the definition of the
-   SIGNED macro and, in particular, the representation of a signature in
-   a certificate or a CRL.  The interpretation selected for PEM requires
-   that the data to be signed (in our case, an MD2 message digest) is
-   first ASN.1 encoded as an OCTET STRING and the result is encrypted
-   (in our case, using RSAEncryption) to form the signed quantity, which
-   is then ASN.1 encoded as a BIT STRING.
-
-5.  Descriptive Grammar
-
-   ; Addendum to PEM BNF representation, using RFC 822 notation
-   ; Provides specification for official PEM cryptographic algorithms,
-   ; modes, identifiers and formats.
-
-   ; Imports <hexchar> and <encbin> from RFC [1421]
-
-       <dekalgid> ::= "DES-CBC"
-       <ikalgid>  ::= "DES-EDE" / "DES-ECB" / "RSA"
-       <sigalgid> ::= "RSA"
-       <micalgid> ::= "RSA-MD2" / "RSA-MD5"
-
-       <dekparameters> ::= <DESCBCparameters>
-       <DESCBCparameters> ::= <IV>
-       <IV> ::= <hexchar16>
-
-       <symencdek> ::= <DESECBencDESCBC> / <DESEDEencDESCBC>
-       <DESECBencDESCBC> ::= <hexchar16>
-       <DESEDEencDESCBC> ::= <hexchar16>
-
-       <symencmic> ::= <DESECBencRSAMD2> / <DESECBencRSAMD5>
-
-
-
-Balenson                                                       [Page 11]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-       <DESECBencRSAMD2> ::= 2*2<hexchar16>
-       <DESECBencRSAMD5> ::= 2*2<hexchar16>
-
-       <asymsignmic> ::= <RSAsignmic>
-       <RSAsignmic> ::= <encbin>
-
-       <asymencdek> ::= <RSAencdek>
-       <RSAencdek> ::= <encbin>
-
-       <hexchar16> ::= 16*16<hexchar>
-
-References
-
-   [1] Federal Information Processing Standards Publication (FIPS PUB)
-       46-1, Data Encryption Standard, Reaffirmed 1988 January 22
-       (supersedes FIPS PUB 46, 1977 January 15).
-
-   [2] ANSI X3.92-1981, American National Standard Data Encryption
-       Algorithm, American National Standards Institute, Approved 30
-       December 1980.
-
-   [3] Federal Information Processing Standards Publication (FIPS PUB)
-       81, DES Modes of Operation, 1980 December 2.
-
-   [4] ANSI X3.106-1983, American National Standard for Information
-       Systems - Data Encryption Algorithm - Modes of Operation,
-       American National Standards Institute, Approved 16 May 1983.
-
-   [5] ISO 8372, Information Processing Systems: Data Encipherment:
-       Modes of Operation of a 64-bit Block Cipher.
-
-   [6] ANSI X9.17-1985, American National Standard, Financial
-       Institution Key Management (Wholesale), American Bankers
-       Association, April 4, 1985, Section 7.2.
-
-   [7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High-
-       Level Network Protocols", ACM Computing Surveys, Vol. 15, No. 2,
-       June 1983, pp. 135-171.
-
-   [8] CCITT Recommendation X.509, "The Directory - Authentication
-       Framework", November 1988, (Developed in collaboration, and
-       technically aligned, with ISO 9594-8).
-
-   [9] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, RSA
-       Laboratories, April 1992.
-
-  [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
-       Laboratory for Computer Science and RSA Data Security, Inc.,
-
-
-
-Balenson                                                       [Page 12]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-       April 1992.
-
-  [11] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data Security,
-       Inc., June 3, 1991.
-
-  [12] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
-       I: Message Encryption and Authentication Procedures", RFC 1421,
-       DEC, February 1993.
-
-  [13] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
-       II: Certificate-Based Key Management", RFC 1422, BBN, February
-       1993.
-
-  [14] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
-       Part IV: Key Certification and Related Services", RFC 1424, RSA
-       Laboratories, February 1993.
-
-Patent Statement
-
-   This version of Privacy Enhanced Mail (PEM) relies on the use of
-   patented public key encryption technology for authentication and
-   encryption.  The Internet Standards Process as defined in RFC 1310
-   requires a written statement from the Patent holder that a license
-   will be made available to applicants under reasonable terms and
-   conditions prior to approving a specification as a Proposed, Draft or
-   Internet Standard.
-
-   The Massachusetts Institute of Technology and the Board of Trustees
-   of the Leland Stanford Junior University have granted Public Key
-   Partners (PKP) exclusive sub-licensing rights to the following
-   patents issued in the United States, and all of their corresponding
-   foreign patents:
-
-      Cryptographic Apparatus and Method
-      ("Diffie-Hellman")............................... No. 4,200,770
-
-      Public Key Cryptographic Apparatus
-      and Method ("Hellman-Merkle").................... No. 4,218,582
-
-      Cryptographic Communications System and
-      Method ("RSA")................................... No. 4,405,829
-
-      Exponential Cryptographic Apparatus
-      and Method ("Hellman-Pohlig").................... No. 4,424,414
-
-   These patents are stated by PKP to cover all known methods of
-   practicing the art of Public Key encryption, including the variations
-   collectively known as El Gamal.
-
-
-
-Balenson                                                       [Page 13]
-
-RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
-
-
-   Public Key Partners has provided written assurance to the Internet
-   Society that parties will be able to obtain, under reasonable,
-   nondiscriminatory terms, the right to use the technology covered by
-   these patents.  This assurance is documented in RFC 1170 titled
-   "Public Key Standards and Licenses".  A copy of the written assurance
-   dated April 20, 1990, may be obtained from the Internet Assigned
-   Number Authority (IANA).
-
-   The Internet Society, Internet Architecture Board, Internet
-   Engineering Steering Group and the Corporation for National Research
-   Initiatives take no position on the validity or scope of the patents
-   and patent applications, nor on the appropriateness of the terms of
-   the assurance.  The Internet Society and other groups mentioned above
-   have not made any determination as to any other intellectual property
-   rights which may apply to the practice of this standard. Any further
-   consideration of these matters is the user's own responsibility.
-
-Security Considerations
-
-   This entire document is about security.
-
-Author's Address
-
-   David Balenson
-   Trusted Information Systems
-   3060 Washington Road
-   Glenwood, Maryland 21738
-
-   Phone: 301-854-6889
-   EMail: balenson@tis.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Balenson                                                       [Page 14]
-
\ No newline at end of file
diff --git a/doc/protocol/rfc2246.txt b/doc/protocol/rfc2246.txt
deleted file mode 100644
index 2e838cf5d5..0000000000
--- a/doc/protocol/rfc2246.txt
+++ /dev/null
@@ -1,4483 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         T. Dierks
-Request for Comments: 2246                                     Certicom
-Category: Standards Track                                      C. Allen
-                                                               Certicom
-                                                           January 1999
-
-
-                            The TLS Protocol
-                              Version 1.0
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   This document specifies Version 1.0 of the Transport Layer Security
-   (TLS) protocol. The TLS protocol provides communications privacy over
-   the Internet. The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1.       Introduction                                              3
-   2.       Goals                                                     4
-   3.       Goals of this document                                    5
-   4.       Presentation language                                     5
-   4.1.     Basic block size                                          6
-   4.2.     Miscellaneous                                             6
-   4.3.     Vectors                                                   6
-   4.4.     Numbers                                                   7
-   4.5.     Enumerateds                                               7
-   4.6.     Constructed types                                         8
-   4.6.1.   Variants                                                  9
-   4.7.     Cryptographic attributes                                 10
-   4.8.     Constants                                                11
-   5.       HMAC and the pseudorandom function                       11
-   6.       The TLS Record Protocol                                  13
-   6.1.     Connection states                                        14
-
-
-
-Dierks & Allen              Standards Track                     [Page 1]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   6.2.     Record layer                                             16
-   6.2.1.   Fragmentation                                            16
-   6.2.2.   Record compression and decompression                     17
-   6.2.3.   Record payload protection                                18
-   6.2.3.1. Null or standard stream cipher                           19
-   6.2.3.2. CBC block cipher                                         19
-   6.3.     Key calculation                                          21
-   6.3.1.   Export key generation example                            22
-   7.       The TLS Handshake Protocol                               23
-   7.1.     Change cipher spec protocol                              24
-   7.2.     Alert protocol                                           24
-   7.2.1.   Closure alerts                                           25
-   7.2.2.   Error alerts                                             26
-   7.3.     Handshake Protocol overview                              29
-   7.4.     Handshake protocol                                       32
-   7.4.1.   Hello messages                                           33
-   7.4.1.1. Hello request                                            33
-   7.4.1.2. Client hello                                             34
-   7.4.1.3. Server hello                                             36
-   7.4.2.   Server certificate                                       37
-   7.4.3.   Server key exchange message                              39
-   7.4.4.   Certificate request                                      41
-   7.4.5.   Server hello done                                        42
-   7.4.6.   Client certificate                                       43
-   7.4.7.   Client key exchange message                              43
-   7.4.7.1. RSA encrypted premaster secret message                   44
-   7.4.7.2. Client Diffie-Hellman public value                       45
-   7.4.8.   Certificate verify                                       45
-   7.4.9.   Finished                                                 46
-   8.       Cryptographic computations                               47
-   8.1.     Computing the master secret                              47
-   8.1.1.   RSA                                                      48
-   8.1.2.   Diffie-Hellman                                           48
-   9.       Mandatory Cipher Suites                                  48
-   10.      Application data protocol                                48
-   A.       Protocol constant values                                 49
-   A.1.     Record layer                                             49
-   A.2.     Change cipher specs message                              50
-   A.3.     Alert messages                                           50
-   A.4.     Handshake protocol                                       51
-   A.4.1.   Hello messages                                           51
-   A.4.2.   Server authentication and key exchange messages          52
-   A.4.3.   Client authentication and key exchange messages          53
-   A.4.4.   Handshake finalization message                           54
-   A.5.     The CipherSuite                                          54
-   A.6.     The Security Parameters                                  56
-   B.       Glossary                                                 57
-   C.       CipherSuite definitions                                  61
-
-
-
-Dierks & Allen              Standards Track                     [Page 2]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   D.       Implementation Notes                                     64
-   D.1.     Temporary RSA keys                                       64
-   D.2.     Random Number Generation and Seeding                     64
-   D.3.     Certificates and authentication                          65
-   D.4.     CipherSuites                                             65
-   E.       Backward Compatibility With SSL                          66
-   E.1.     Version 2 client hello                                   67
-   E.2.     Avoiding man-in-the-middle version rollback              68
-   F.       Security analysis                                        69
-   F.1.     Handshake protocol                                       69
-   F.1.1.   Authentication and key exchange                          69
-   F.1.1.1. Anonymous key exchange                                   69
-   F.1.1.2. RSA key exchange and authentication                      70
-   F.1.1.3. Diffie-Hellman key exchange with authentication          71
-   F.1.2.   Version rollback attacks                                 71
-   F.1.3.   Detecting attacks against the handshake protocol         72
-   F.1.4.   Resuming sessions                                        72
-   F.1.5.   MD5 and SHA                                              72
-   F.2.     Protecting application data                              72
-   F.3.     Final notes                                              73
-   G.       Patent Statement                                         74
-            Security Considerations                                  75
-            References                                               75
-            Credits                                                  77
-            Comments                                                 78
-            Full Copyright Statement                                 80
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications. The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol. At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-     - The connection is private. Symmetric cryptography is used for
-       data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for
-       this symmetric encryption are generated uniquely for each
-       connection and are based on a secret negotiated by another
-       protocol (such as the TLS Handshake Protocol). The Record
-       Protocol can also be used without encryption.
-
-     - The connection is reliable. Message transport includes a message
-       integrity check using a keyed MAC. Secure hash functions (e.g.,
-       SHA, MD5, etc.) are used for MAC computations. The Record
-       Protocol can operate without a MAC, but is generally only used in
-
-
-
-Dierks & Allen              Standards Track                     [Page 3]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       this mode while another protocol is using the Record Protocol as
-       a transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher
-   level protocols. One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data. The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-     - The peer's identity can be authenticated using asymmetric, or
-       public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-       authentication can be made optional, but is generally required
-       for at least one of the peers.
-
-     - The negotiation of a shared secret is secure: the negotiated
-       secret is unavailable to eavesdroppers, and for any authenticated
-       connection the secret cannot be obtained, even by an attacker who
-       can place himself in the middle of the connection.
-
-     - The negotiation is reliable: no attacker can modify the
-       negotiation communication without being detected by the parties
-       to the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are:
-
-    1. Cryptographic security: TLS should be used to establish a secure
-       connection between two parties.
-
-    2. Interoperability: Independent programmers should be able to
-       develop applications utilizing TLS that will then be able to
-       successfully exchange cryptographic parameters without knowledge
-       of one another's code.
-
-    3. Extensibility: TLS seeks to provide a framework into which new
-       public key and bulk encryption methods can be incorporated as
-       necessary. This will also accomplish two sub-goals: to prevent
-
-
-
-Dierks & Allen              Standards Track                     [Page 4]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       the need to create a new protocol (and risking the introduction
-       of possible new weaknesses) and to avoid the need to implement an
-       entire new security library.
-
-    4. Relative efficiency: Cryptographic operations tend to be highly
-       CPU intensive, particularly public key operations. For this
-       reason, the TLS protocol has incorporated an optional session
-       caching scheme to reduce the number of connections that need to
-       be established from scratch. Additionally, care has been taken to
-       reduce network activity.
-
-3. Goals of this document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape. The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that TLS 1.0 and SSL 3.0 do not interoperate
-   (although TLS 1.0 does incorporate a mechanism by which a TLS
-   implementation can back down to SSL 3.0). This document is intended
-   primarily for readers who will be implementing the protocol and those
-   doing cryptographic analysis of it. The specification has been
-   written with this in mind, and it is intended to reflect the needs of
-   those two groups. For that reason, many of the algorithm-dependent
-   data structures and rules are included in the body of the text (as
-   opposed to in an appendix), providing easier access to them.
-
-   This document is not intended to supply any details of service
-   definition nor interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation language
-
-   This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
-   have general application beyond that particular goal.
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                     [Page 5]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-4.1. Basic block size
-
-   The representation of all data items is explicitly specified. The
-   basic data block size is one byte (i.e. 8 bits). Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom. From the bytestream a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements. The size of the vector may be specified at documentation
-   time or left unspecified until runtime. In either case the length
-   declares the number of bytes, not the number of elements, in the
-   vector. The syntax for specifying a new type T' that is a fixed
-   length vector of type T is
-
-       T T'[n];
-
-   Here T' occupies n bytes in the data stream, where n is a multiple of
-   the size of T. The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-
-
-
-
-
-Dierks & Allen              Standards Track                     [Page 6]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Variable length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   encoded, the actual length precedes the vector's contents in the byte
-   stream. The length will be in the form of a number consuming as many
-   bytes as required to hold the vector's specified maximum (ceiling)
-   length. A variable length vector with an actual length field of zero
-   is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque. It can never be empty. The
-   actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4). On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty. Its encoding will include a two byte actual length
-   field prepended to the vector. The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17 byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8). All larger
-   numeric data types are formed from fixed length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned. The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum. A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type. Only enumerateds of the same
-   type may be assigned or compared. Every element of an enumerated must
-
-
-
-
-Dierks & Allen              Standards Track                     [Page 7]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   be assigned a value, as demonstrated in the following example.  Since
-   the elements of the enumerated are not ordered, they can be assigned
-   any unique value, in any order.
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value. The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2 or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type. In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue. Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed types
-
-   Structure types may be constructed from primitive types for
-   convenience. Each specification declares a new, unique type. The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-
-
-
-
-
-Dierks & Allen              Standards Track                     [Page 8]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   The fields within a structure may be qualified using the type's name
-   using a syntax much like that available for enumerateds. For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment. The selector must be an enumerated
-   type that defines the possible variants the structure defines. There
-   must be a case arm for every element of the enumeration declared in
-   the select. The body of the variant structure may be given a label
-   for reference. The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type. For example, a
-
-
-
-Dierks & Allen              Standards Track                     [Page 9]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-4.7. Cryptographic attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively. A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification. Cryptographic keys
-   are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm. A digitally-signed element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-   In RSA signing, a 36-byte structure of two hashes (one SHA and one
-   MD5) is signed (encrypted with the private key). It is encoded with
-   PKCS #1 block type 0 or type 1 as described in [PKCS1].
-
-   In DSS, the 20 bytes of the SHA hash are run directly through the
-   Digital Signing Algorithm with no additional hashing. This produces
-   two values, r and s. The DSS signature is an opaque vector, as above,
-   the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically-secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext. All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items which are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key. A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-
-
-Dierks & Allen              Standards Track                    [Page 10]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   An RSA encrypted value is encoded with PKCS #1 block type 2 as
-   described in [PKCS1].
-
-   In the following example:
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   The contents of hash are used as input for the signing algorithm,
-   then the entire structure is encrypted with a stream cipher. The
-   length of this structure, in bytes would be equal to 2 bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm. This is known
-   due to the fact that the algorithm and key used for the signing are
-   known prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values. No fields
-   of a multi-element structure or vector may be elided.
-
-   For example,
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the pseudorandom function
-
-   A number of operations in the TLS record and handshake layer required
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret. Forging the MAC is infeasible without knowledge of the MAC
-   secret. The construction we use for this operation is known as HMAC,
-   described in [HMAC].
-
-   HMAC can be used with a variety of different hash algorithms. TLS
-   uses it in the handshake with two different algorithms: MD5 and SHA-
-   1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 11]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   data). Additional hash algorithms can be defined by cipher suites and
-   used to protect record data, but MD5 and SHA-1 are hard coded into
-   the description of the handshaking for this version of the protocol.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In order to make the PRF as secure as possible, it uses two hash
-   algorithms in a way which should guarantee its security if either
-   algorithm remains secure.
-
-   First, we define a data expansion function, P_hash(secret, data)
-   which uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data. For example, if P_SHA-1 was being used to
-   create 64 bytes of data, it would have to be iterated 4 times
-   (through A(4)), creating 80 bytes of output data; the last 16 bytes
-   of the final iteration would then be discarded, leaving 64 bytes of
-   output data.
-
-   TLS's PRF is created by splitting the secret into two halves and
-   using one half to generate data with P_MD5 and the other half to
-   generate data with P_SHA-1, then exclusive-or'ing the outputs of
-   these two expansion functions together.
-
-   S1 and S2 are the two halves of the secret and each is the same
-   length. S1 is taken from the first half of the secret, S2 from the
-   second half. Their length is created by rounding up the length of the
-   overall secret divided by two; thus, if the original secret is an odd
-   number of bytes long, the last byte of S1 will be the same as the
-   first byte of S2.
-
-       L_S = length in bytes of secret;
-       L_S1 = L_S2 = ceil(L_S / 2);
-
-
-
-Dierks & Allen              Standards Track                    [Page 12]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   The secret is partitioned into two halves (with the possibility of
-   one shared byte) as described above, S1 taking the first L_S1 bytes
-   and S2 the last L_S2 bytes.
-
-   The PRF is then defined as the result of mixing the two pseudorandom
-   streams by exclusive-or'ing them together.
-
-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
-                                  P_SHA-1(S2, label + seed);
-
-   The label is an ASCII string. It should be included in the exact form
-   it is given without a length byte or trailing null character.  For
-   example, the label "slithy toves" would be processed by hashing the
-   following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
-   byte outputs, the boundaries of their internal iterations will not be
-   aligned; to generate a 80 byte output will involve P_MD5 being
-   iterated through A(5), while P_SHA-1 will only iterate through A(4).
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol. At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result. Received data is
-   decrypted, verified, decompressed, and reassembled, then delivered to
-   higher level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol. In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol. Any new record types should
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.2). If a TLS
-   implementation receives a record type it does not understand, it
-   should just ignore it. Any protocol designed for use over TLS must be
-   carefully designed to deal with all possible attacks against it.
-   Note that because the type and length of a record are not protected
-   by encryption, care should be take to minimize the value of traffic
-   analysis of these values.
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 13]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-6.1. Connection states
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol. It specifies a compression algorithm, encryption algorithm,
-   and MAC algorithm. In addition, the parameters for these algorithms
-   are known: the MAC secret and the bulk encryption keys and IVs for
-   the connection in both the read and the write directions. Logically,
-   there are always four connection states outstanding: the current read
-   and write states, and the pending read and write states. All records
-   are processed under the current read and write states. The security
-   parameters for the pending states can be set by the TLS Handshake
-   Protocol, and the Handshake Protocol can selectively make either of
-   the pending states current, in which case the appropriate current
-   state is disposed of and replaced with the pending state; the pending
-   state is then reinitialized to an empty state. It is illegal to make
-   a state which has not been initialized with security parameters a
-   current state. The initial current state always specifies that no
-   encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-       Whether this entity is considered the "client" or the "server" in
-       this connection.
-
-   bulk encryption algorithm
-       An algorithm to be used for bulk encryption. This specification
-       includes the key size of this algorithm, how much of that key is
-       secret, whether it is a block or stream cipher, the block size of
-       the cipher (if appropriate), and whether it is considered an
-       "export" cipher.
-
-   MAC algorithm
-       An algorithm to be used for message authentication. This
-       specification includes the size of the hash which is returned by
-       the MAC algorithm.
-
-   compression algorithm
-       An algorithm to be used for data compression. This specification
-       must include all information the algorithm requires to do
-       compression.
-
-   master secret
-       A 48 byte secret shared between the two peers in the connection.
-
-   client random
-       A 32 byte value provided by the client.
-
-
-
-Dierks & Allen              Standards Track                    [Page 14]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   server random
-       A 32 byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { true, false } IsExportable;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           IsExportable           is_exportable;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following six items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-       client write IV (for block ciphers only)
-       server write IV (for block ciphers only)
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa. The algorithm used for generating
-   these items from the security parameters is described in section 6.3.
-
-
-
-Dierks & Allen              Standards Track                    [Page 15]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states. These current states must be updated for each
-   record processed. Each connection state includes the following
-   elements:
-
-   compression state
-       The current state of the compression algorithm.
-
-   cipher state
-       The current state of the encryption algorithm. This will consist
-       of the scheduled key for that connection. In addition, for block
-       ciphers running in CBC mode (the only mode specified for TLS),
-       this will initially contain the IV for that connection state and
-       be updated to contain the ciphertext of the last block encrypted
-       or decrypted as records are processed. For stream ciphers, this
-       will contain whatever the necessary state information is to allow
-       the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-       The MAC secret for this connection as generated above.
-
-   sequence number
-       Each connection state contains a sequence number, which is
-       maintained separately for read and write states. The sequence
-       number must be set to zero whenever a connection state is made
-       the active state. Sequence numbers are of type uint64 and may not
-       exceed 2^64-1. A sequence number is incremented after each
-       record: specifically, the first record which is transmitted under
-       a particular connection state should use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less. Client message
-   boundaries are not preserved in the record layer (i.e., multiple
-   client messages of the same ContentType may be coalesced into a
-   single TLSPlaintext record, or a single message may be fragmented
-   across several records).
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-
-
-Dierks & Allen              Standards Track                    [Page 16]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-       The higher level protocol used to process the enclosed fragment.
-
-   version
-       The version of the protocol being employed. This document
-       describes TLS Version 1.0, which uses the version { 3, 1 }. The
-       version value 3.1 is historical: TLS version 1.0 is a minor
-       modification to the SSL 3.0 protocol, which bears the version
-       value 3.0. (See Appendix A.1).
-
-   length
-       The length (in bytes) of the following TLSPlaintext.fragment.
-       The length should not exceed 2^14.
-
-   fragment
-       The application data. This data is transparent and treated as an
-       independent block to be dealt with by the higher level protocol
-       specified by the type field.
-
- Note: Data of different TLS Record layer content types may be
-       interleaved. Application data is generally of lower precedence
-       for transmission than other content types.
-
-6.2.2. Record compression and decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state. There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null. The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure. Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 17]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes. If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-       The length (in bytes) of the following TLSCompressed.fragment.
-       The length should not exceed 2^14 + 1024.
-
-   fragment
-       The compressed form of TLSPlaintext.fragment.
-
- Note: A CompressionMethod.null operation is an identity operation; no
-       fields are altered.
-
-   Implementation note:
-       Decompression functions are responsible for ensuring that
-       messages cannot cause internal buffer overflows.
-
-6.2.3. Record payload protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext. The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra or repeated messages are detectable.
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-       The type field is identical to TLSCompressed.type.
-
-   version
-       The version field is identical to TLSCompressed.version.
-
-
-
-Dierks & Allen              Standards Track                    [Page 18]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   length
-       The length (in bytes) of the following TLSCiphertext.fragment.
-       The length may not exceed 2^14 + 2048.
-
-   fragment
-       The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or standard stream cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
-   A.6) convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-       The sequence number for this record.
-
-   hash
-       The hashing algorithm specified by
-       SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption. The stream cipher
-   encrypts the entire block, including the MAC. For stream ciphers that
-   do not use a synchronization vector (such as RC4), the stream cipher
-   state from the end of one record is simply used on the subsequent
-   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
-   consists of the identity operation (i.e., the data is not encrypted
-   and the MAC size is zero implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC block cipher
-
-   For block ciphers (such as RC2 or DES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-
-
-Dierks & Allen              Standards Track                    [Page 19]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       block-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   padding
-       Padding that is added to force the length of the plaintext to be
-       an integral multiple of the block cipher's block length. The
-       padding may be any length up to 255 bytes long, as long as it
-       results in the TLSCiphertext.length being an integral multiple of
-       the block length. Lengths longer than necessary might be
-       desirable to frustrate attacks on a protocol based on analysis of
-       the lengths of exchanged messages. Each uint8 in the padding data
-       vector must be filled with the padding length value.
-
-   padding_length
-       The padding length should be such that the total size of the
-       GenericBlockCipher structure is a multiple of the cipher's block
-       length. Legal values range from zero to 255, inclusive. This
-       length specifies the length of the padding field exclusive of the
-       padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of TLSCompressed.length, CipherSpec.hash_size, and
-   padding_length.
-
- Example: If the block length is 8 bytes, the content length
-          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-          bytes, the length before padding is 82 bytes. Thus, the
-          padding length modulo 8 must be equal to 6 in order to make
-          the total length an even multiple of 8 bytes (the block
-          length). The padding length can be 6, 14, 22, and so on,
-          through 254. If the padding length were the minimum necessary,
-          6, the padding would be 6 bytes, each containing the value 6.
-          Thus, the last 8 octets of the GenericBlockCipher before block
-          encryption would be xx 06 06 06 06 06 06 06, where xx is the
-          last octet of the MAC.
-
- Note: With block ciphers in CBC mode (Cipher Block Chaining) the
-       initialization vector (IV) for the first record is generated with
-       the other keys and secrets when the security parameters are set.
-       The IV for subsequent records is the last ciphertext block from
-       the previous record.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 20]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-6.3. Key calculation
-
-   The Record Protocol requires an algorithm to generate keys, IVs, and
-   MAC secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets, keys, and non-export IVs required by
-   the current connection state (see Appendix A.6). CipherSpecs require
-   a client write MAC secret, a server write MAC secret, a client write
-   key, a server write key, a client write IV, and a server write IV,
-   which are generated from the master secret in that order. Unused
-   values are empty.
-
-   When generating keys and MAC secrets, the master secret is used as an
-   entropy source, and the random values provide unencrypted salt
-   material and IVs for exportable ciphers.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-                          SecurityParameters.client_random);
-
-   until enough output has been generated. Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-       client_write_IV[SecurityParameters.IV_size]
-       server_write_IV[SecurityParameters.IV_size]
-
-   The client_write_IV and server_write_IV are only generated for non-
-   export block ciphers. For exportable block ciphers, the
-   initialization vectors are generated later, as described below. Any
-   extra key_block material is discarded.
-
-   Implementation note:
-       The cipher spec which is defined in this document which requires
-       the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
-       keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
-       104 bytes of key material.
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 21]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Exportable encryption algorithms (for which CipherSpec.is_exportable
-   is true) require additional processing as follows to derive their
-   final write keys:
-
-       final_client_write_key =
-       PRF(SecurityParameters.client_write_key,
-                                  "client write key",
-                                  SecurityParameters.client_random +
-                                  SecurityParameters.server_random);
-       final_server_write_key =
-       PRF(SecurityParameters.server_write_key,
-                                  "server write key",
-                                  SecurityParameters.client_random +
-                                  SecurityParameters.server_random);
-
-   Exportable encryption algorithms derive their IVs solely from the
-   random values from the hello messages:
-
-       iv_block = PRF("", "IV block", SecurityParameters.client_random +
-                      SecurityParameters.server_random);
-
-   The iv_block is partitioned into two initialization vectors as the
-   key_block was above:
-
-       client_write_IV[SecurityParameters.IV_size]
-       server_write_IV[SecurityParameters.IV_size]
-
-   Note that the PRF is used without a secret in this case: this just
-   means that the secret has a length of zero bytes and contributes
-   nothing to the hashing in the PRF.
-
-6.3.1. Export key generation example
-
-   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
-   each of the two encryption keys and 16 bytes for each of the MAC
-   keys, for a total of 42 bytes of key material. The PRF output is
-   stored in the key_block. The key_block is partitioned, and the write
-   keys are salted because this is an exportable encryption algorithm.
-
-       key_block               = PRF(master_secret,
-                                     "key expansion",
-                                     server_random +
-                                     client_random)[0..41]
-       client_write_MAC_secret = key_block[0..15]
-       server_write_MAC_secret = key_block[16..31]
-       client_write_key        = key_block[32..36]
-       server_write_key        = key_block[37..41]
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 22]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       final_client_write_key  = PRF(client_write_key,
-                                     "client write key",
-                                     client_random +
-                                     server_random)[0..15]
-       final_server_write_key  = PRF(server_write_key,
-                                     "server write key",
-                                     client_random +
-                                     server_random)[0..15]
-
-       iv_block                = PRF("", "IV block", client_random +
-                                     server_random)[0..15]
-       client_write_IV = iv_block[0..7]
-       server_write_IV = iv_block[8..15]
-
-7. The TLS Handshake Protocol
-
-   The TLS Handshake Protocol consists of a suite of three sub-protocols
-   which are used to allow peers to agree upon security parameters for
-   the record layer, authenticate themselves, instantiate negotiated
-   security parameters, and report error conditions to each other.
-
-   The Handshake Protocol is responsible for negotiating a session,
-   which consists of the following items:
-
-   session identifier
-       An arbitrary byte sequence chosen by the server to identify an
-       active or resumable session state.
-
-   peer certificate
-       X509v3 [X509] certificate of the peer. This element of the state
-       may be null.
-
-   compression method
-       The algorithm used to compress data prior to encryption.
-
-   cipher spec
-       Specifies the bulk data encryption algorithm (such as null, DES,
-       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
-       cryptographic attributes such as the hash_size. (See Appendix A.6
-       for formal definition)
-
-   master secret
-       48-byte secret shared between the client and server.
-
-   is resumable
-       A flag indicating whether the session can be used to initiate new
-       connections.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 23]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data. Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change cipher spec protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies. The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state. The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and server
-   to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys. Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender should instruct
-   the record layer to make the write pending state the write active
-   state. (See section 6.1.) The change cipher spec message is sent
-   during the handshake after the security parameters have been agreed
-   upon, but before the verifying finished message is sent (see section
-   7.4.9).
-
-7.2. Alert protocol
-
-   One of the content types supported by the TLS Record layer is the
-   alert type. Alert messages convey the severity of the message and a
-   description of the alert. Alert messages with a level of fatal result
-   in the immediate termination of the connection. In this case, other
-   connections corresponding to the session may continue, but the
-   session identifier must be invalidated, preventing the failed session
-   from being used to establish new connections. Like other messages,
-   alert messages are encrypted and compressed, as specified by the
-   current connection state.
-
-       enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-
-
-
-Dierks & Allen              Standards Track                    [Page 24]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-           decompression_failure(30),
-           handshake_failure(40),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           (255)
-       } AlertDescription;
-
-       struct {
-           AlertLevel level;
-           AlertDescription description;
-       } Alert;
-
-7.2.1. Closure alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack. Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-       This message notifies the recipient that the sender will not send
-       any more messages on this connection. The session becomes
-       unresumable if any connection is terminated without proper
-       close_notify messages with level equal to warning.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Each party is required to send a close_notify alert before closing
-   the write side of the connection. It is required that the other party
-   respond with a close_notify alert of its own and close down the
-   connection immediately, discarding any pending writes. It is not
-   required for the initiator of the close to wait for the responding
-   close_notify alert before closing the read side of the connection.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 25]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended. If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation may choose to close the
-   transport without waiting for the responding close_notify. No part of
-   this standard should be taken to dictate the manner in which a usage
-   profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   NB: It is assumed that closing a connection reliably delivers
-       pending data before destroying the transport.
-
-7.2.2. Error alerts
-
-   Error handling in the TLS Handshake protocol is very simple. When an
-   error is detected, the detecting party sends a message to the other
-   party. Upon transmission or receipt of an fatal alert message, both
-   parties immediately close the connection. Servers and clients are
-   required to forget any session-identifiers, keys, and secrets
-   associated with a failed connection. The following error alerts are
-   defined:
-
-   unexpected_message
-       An inappropriate message was received. This alert is always fatal
-       and should never be observed in communication between proper
-       implementations.
-
-   bad_record_mac
-       This alert is returned if a record is received with an incorrect
-       MAC. This message is always fatal.
-
-   decryption_failed
-       A TLSCiphertext decrypted in an invalid way: either it wasn`t an
-       even multiple of the block length or its padding values, when
-       checked, weren`t correct. This message is always fatal.
-
-   record_overflow
-       A TLSCiphertext record was received which had a length more than
-       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-       with more than 2^14+1024 bytes. This message is always fatal.
-
-   decompression_failure
-       The decompression function received improper input (e.g. data
-       that would expand to excessive length). This message is always
-       fatal.
-
-
-
-Dierks & Allen              Standards Track                    [Page 26]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   handshake_failure
-       Reception of a handshake_failure alert message indicates that the
-       sender was unable to negotiate an acceptable set of security
-       parameters given the options available. This is a fatal error.
-
-   bad_certificate
-       A certificate was corrupt, contained signatures that did not
-       verify correctly, etc.
-
-   unsupported_certificate
-       A certificate was of an unsupported type.
-
-   certificate_revoked
-       A certificate was revoked by its signer.
-
-   certificate_expired
-       A certificate has expired or is not currently valid.
-
-   certificate_unknown
-       Some other (unspecified) issue arose in processing the
-       certificate, rendering it unacceptable.
-
-   illegal_parameter
-       A field in the handshake was out of range or inconsistent with
-       other fields. This is always fatal.
-
-   unknown_ca
-       A valid certificate chain or partial chain was received, but the
-       certificate was not accepted because the CA certificate could not
-       be located or couldn`t be matched with a known, trusted CA.  This
-       message is always fatal.
-
-   access_denied
-       A valid certificate was received, but when access control was
-       applied, the sender decided not to proceed with negotiation.
-       This message is always fatal.
-
-   decode_error
-       A message could not be decoded because some field was out of the
-       specified range or the length of the message was incorrect. This
-       message is always fatal.
-
-   decrypt_error
-       A handshake cryptographic operation failed, including being
-       unable to correctly verify a signature, decrypt a key exchange,
-       or validate a finished message.
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 27]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   export_restriction
-       A negotiation not in compliance with export restrictions was
-       detected; for example, attempting to transfer a 1024 bit
-       ephemeral RSA key for the RSA_EXPORT handshake method. This
-       message is always fatal.
-
-   protocol_version
-       The protocol version the client has attempted to negotiate is
-       recognized, but not supported. (For example, old protocol
-       versions might be avoided for security reasons). This message is
-       always fatal.
-
-   insufficient_security
-       Returned instead of handshake_failure when a negotiation has
-       failed specifically because the server requires ciphers more
-       secure than those supported by the client. This message is always
-       fatal.
-
-   internal_error
-       An internal error unrelated to the peer or the correctness of the
-       protocol makes it impossible to continue (such as a memory
-       allocation failure). This message is always fatal.
-
-   user_canceled
-       This handshake is being canceled for some reason unrelated to a
-       protocol failure. If the user cancels an operation after the
-       handshake is complete, just closing the connection by sending a
-       close_notify is more appropriate. This alert should be followed
-       by a close_notify. This message is generally a warning.
-
-   no_renegotiation
-       Sent by the client in response to a hello request or by the
-       server in response to a client hello after initial handshaking.
-       Either of these would normally lead to renegotiation; when that
-       is not appropriate, the recipient should respond with this alert;
-       at that point, the original requester can decide whether to
-       proceed with the connection. One case where this would be
-       appropriate would be where a server has spawned a process to
-       satisfy a request; the process might receive security parameters
-       (key length, authentication, etc.) at startup and it might be
-       difficult to communicate changes to these parameters after that
-       point. This message is always a warning.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party may determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 28]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   receiving party may decide at its discretion whether to treat this as
-   a fatal error or not. However, all messages which are transmitted
-   with a level of fatal must be treated as fatal messages.
-
-7.3. Handshake Protocol overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer. When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-     - Exchange hello messages to agree on algorithms, exchange random
-       values, and check for session resumption.
-
-     - Exchange the necessary cryptographic parameters to allow the
-       client and server to agree on a premaster secret.
-
-     - Exchange certificates and cryptographic information to allow the
-       client and server to authenticate themselves.
-
-     - Generate a master secret from the premaster secret and exchanged
-       random values.
-
-     - Provide security parameters to the record layer.
-
-     - Allow the client and server to verify that their peer has
-       calculated the same security parameters and that the handshake
-       occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on TLS always
-   negotiating the strongest possible connection between two peers:
-   there are a number of ways a man in the middle attacker can attempt
-   to make two entities drop down to the least secure method they
-   support. The protocol has been designed to minimize this risk, but
-   there are still attacks available: for example, an attacker could
-   block access to the port a secure service runs on, or attempt to get
-   the peers to negotiate an unauthenticated connection. The fundamental
-   rule is that higher levels must be cognizant of what their security
-   requirements are and never transmit information over a channel less
-   secure than what they require. The TLS protocol is secure, in that
-   any cipher suite offers its promised level of security: if you
-   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
-   certificate you have verified, you can expect to be that secure.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 29]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   However, you should never send data over a link encrypted with 40 bit
-   security unless you feel that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail. The client hello
-   and server hello are used to establish security enhancement
-   capabilities between client and server. The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method. Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange. New key exchange methods can be created by
-   specifying a format for these messages and defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret. This secret should be quite long; currently defined key
-   exchange methods exchange secrets which range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated. Additionally, a server key exchange
-   message may be sent, if it is required (e.g. if their server has no
-   certificate, or if its certificate is for signing only). If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected. Now the
-   server will send the server hello done message, indicating that the
-   hello-message phase of the handshake is complete. The server will
-   then wait for a client response. If the server has sent a certificate
-   request message, the client must send the certificate message. The
-   client key exchange message is now sent, and the content of that
-   message will depend on the public key algorithm selected between the
-   client hello and the server hello. If the client has sent a
-   certificate with signing ability, a digitally-signed certificate
-   verify message is sent to explicitly verify the certificate.
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec. The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets. In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 30]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Cipher Spec. At this point, the handshake is complete and the client
-   and server may begin to exchange application layer data. (See flow
-   chart below.)
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1 - Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-       independent TLS Protocol content type, and is not actually a TLS
-       handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters) the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed. The server then checks its session cache for a match.  If
-   a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value. At this point, both
-   client and server must send change cipher spec messages and proceed
-   directly to finished messages. Once the re-establishment is complete,
-   the client and server may begin to exchange application layer data.
-   (See flow chart below.) If a Session ID match is not found, the
-   server generates a new session ID and the TLS client and server
-   perform a full handshake.
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 31]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2 - Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake protocol
-
-   The TLS Handshake Protocol is one of the defined higher level clients
-   of the TLS Record Protocol. This protocol is used to negotiate the
-   secure attributes of a session. Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-       enum {
-           hello_request(0), client_hello(1), server_hello(2),
-           certificate(11), server_key_exchange (12),
-           certificate_request(13), server_hello_done(14),
-           certificate_verify(15), client_key_exchange(16),
-           finished(20), (255)
-       } HandshakeType;
-
-       struct {
-           HandshakeType msg_type;    /* handshake type */
-           uint24 length;             /* bytes in message */
-           select (HandshakeType) {
-               case hello_request:       HelloRequest;
-               case client_hello:        ClientHello;
-               case server_hello:        ServerHello;
-               case certificate:         Certificate;
-               case server_key_exchange: ServerKeyExchange;
-               case certificate_request: CertificateRequest;
-               case server_hello_done:   ServerHelloDone;
-               case certificate_verify:  CertificateVerify;
-               case client_key_exchange: ClientKeyExchange;
-               case finished:            Finished;
-           } body;
-       } Handshake;
-
-
-
-Dierks & Allen              Standards Track                    [Page 32]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   The handshake protocol messages are presented below in the order they
-   must be sent; sending handshake messages in an unexpected order
-   results in a fatal error. Unneeded handshake messages can be omitted,
-   however. Note one exception to the ordering: the Certificate message
-   is used twice in the handshake (from server to client, then from
-   client to server), but described only in its first position. The one
-   message which is not bound by these ordering rules in the Hello
-   Request message, which can be sent at any time, but which should be
-   ignored by the client if it arrives in the middle of a handshake.
-
-7.4.1. Hello messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server. When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null. The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-       The hello request message may be sent by the server at any time.
-
-   Meaning of this message:
-       Hello request is a simple notification that the client should
-       begin the negotiation process anew by sending a client hello
-       message when convenient. This message will be ignored by the
-       client if the client is currently negotiating a session. This
-       message may be ignored by the client if it does not wish to
-       renegotiate a session, or the client may, if it wishes, respond
-       with a no_renegotiation alert. Since handshake messages are
-       intended to have transmission precedence over application data,
-       it is expected that the negotiation will begin before no more
-       than a few records are received from the client. If the server
-       sends a hello request but does not receive a client hello in
-       response, it may close the connection with a fatal alert.
-
-   After sending a hello request, servers should not repeat the request
-   until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-       struct { } HelloRequest;
-
- Note: This message should never be included in the message hashes which
-       are maintained throughout the handshake and used in the finished
-       messages and the certificate verify message.
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 33]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-7.4.1.2. Client hello
-
-   When this message will be sent:
-       When a client first connects to a server it is required to send
-       the client hello as its first message. The client can also send a
-       client hello in response to a hello request or on its own
-       initiative in order to renegotiate the security parameters in an
-       existing connection.
-
-       Structure of this message:
-           The client hello message includes a random structure, which is
-           used later in the protocol.
-
-           struct {
-              uint32 gmt_unix_time;
-              opaque random_bytes[28];
-           } Random;
-
-       gmt_unix_time
-       The current time and date in standard UNIX 32-bit format (seconds
-       since the midnight starting Jan 1, 1970, GMT) according to the
-       sender's internal clock. Clocks are not required to be set
-       correctly by the basic TLS Protocol; higher level or application
-       protocols may define additional requirements.
-
-   random_bytes
-       28 bytes generated by a secure random number generator.
-
-   The client hello message includes a variable length session
-   identifier. If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse. The session identifier may be from an earlier connection, this
-   connection, or another currently active connection. The second option
-   is useful if the client only wishes to update the random structures
-   and derived values of a connection, while the third option makes it
-   possible to establish several independent secure connections without
-   repeating the full handshake protocol. These independent connections
-   may occur sequentially or simultaneously; a SessionID becomes valid
-   when the handshake negotiating it completes with the exchange of
-   Finished messages and persists until removed due to aging or because
-   a fatal error was encountered on a connection associated with the
-   session. The actual contents of the SessionID are defined by the
-   server.
-
-       opaque SessionID<0..32>;
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 34]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Warning:
-       Because the SessionID is transmitted without encryption or
-       immediate MAC protection, servers must not place confidential
-       information in session identifiers or let the contents of fake
-       session identifiers cause any breach of security. (Note that the
-       content of the handshake as a whole, including the SessionID, is
-       protected by the Finished messages exchanged at the end of the
-       handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first). Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length) and a MAC algorithm. The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-       uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-       enum { null(0), (255) } CompressionMethod;
-
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
-           CompressionMethod compression_methods<1..2^8-1>;
-       } ClientHello;
-
-   client_version
-       The version of the TLS protocol by which the client wishes to
-       communicate during this session. This should be the latest
-       (highest valued) version supported by the client. For this
-       version of the specification, the version will be 3.1 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       A client-generated random structure.
-
-   session_id
-       The ID of a session the client wishes to use for this connection.
-       This field should be empty if no session_id is available or the
-       client wishes to generate new security parameters.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 35]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   cipher_suites
-       This is a list of the cryptographic options supported by the
-       client, with the client's first preference first. If the
-       session_id field is not empty (implying a session resumption
-       request) this vector must include at least the cipher_suite from
-       that session. Values are defined in Appendix A.5.
-
-   compression_methods
-       This is a list of the compression methods supported by the
-       client, sorted by client preference. If the session_id field is
-       not empty (implying a session resumption request) it must include
-       the compression_method from that session. This vector must
-       contain, and all implementations must support,
-       CompressionMethod.null. Thus, a client and server will always be
-       able to agree on a compression method.
-
-   After sending the client hello message, the client waits for a server
-   hello message. Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-   Forward compatibility note:
-       In the interests of forward compatibility, it is permitted for a
-       client hello message to include extra data after the compression
-       methods. This data must be included in the handshake hashes, but
-       must otherwise be ignored. This is the only handshake message for
-       which this is legal; for all other messages, the amount of data
-       in the message must match the description of the message
-       precisely.
-
-7.4.1.3. Server hello
-
-   When this message will be sent:
-       The server will send this message in response to a client hello
-       message when it was able to find an acceptable set of algorithms.
-       If it cannot find such a match, it will respond with a handshake
-       failure alert.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-           CompressionMethod compression_method;
-       } ServerHello;
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 36]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   server_version
-       This field will contain the lower of that suggested by the client
-       in the client hello and the highest supported by the server. For
-       this version of the specification, the version is 3.1 (See
-       Appendix E for details about backward compatibility).
-
-   random
-       This structure is generated by the server and must be different
-       from (and independent of) ClientHello.random.
-
-   session_id
-       This is the identity of the session corresponding to this
-       connection. If the ClientHello.session_id was non-empty, the
-       server will look in its session cache for a match. If a match is
-       found and the server is willing to establish the new connection
-       using the specified session state, the server will respond with
-       the same value as was supplied by the client. This indicates a
-       resumed session and dictates that the parties must proceed
-       directly to the finished messages. Otherwise this field will
-       contain a different value identifying the new session. The server
-       may return an empty session_id to indicate that the session will
-       not be cached and therefore cannot be resumed. If a session is
-       resumed, it must be resumed using the same cipher suite it was
-       originally negotiated with.
-
-   cipher_suite
-       The single cipher suite selected by the server from the list in
-       ClientHello.cipher_suites. For resumed sessions this field is the
-       value from the state of the session being resumed.
-
-   compression_method
-       The single compression algorithm selected by the server from the
-       list in ClientHello.compression_methods. For resumed sessions
-       this field is the value from the resumed session state.
-
-7.4.2. Server certificate
-
-   When this message will be sent:
-       The server must send a certificate whenever the agreed-upon key
-       exchange method is not an anonymous one. This message will always
-       immediately follow the server hello message.
-
-   Meaning of this message:
-       The certificate type must be appropriate for the selected cipher
-       suite's key exchange algorithm, and is generally an X.509v3
-       certificate. It must contain a key which matches the key exchange
-       method, as follows. Unless otherwise specified, the signing
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 37]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       algorithm for the certificate must be the same as the algorithm
-       for the certificate key. Unless otherwise specified, the public
-       key may be of any length.
-
-       Key Exchange Algorithm  Certificate Key Type
-
-       RSA                     RSA public key; the certificate must
-                               allow the key to be used for encryption.
-
-       RSA_EXPORT              RSA public key of length greater than
-                               512 bits which can be used for signing,
-                               or a key of 512 bits or shorter which
-                               can be used for either encryption or
-                               signing.
-
-       DHE_DSS                 DSS public key.
-
-       DHE_DSS_EXPORT          DSS public key.
-
-       DHE_RSA                 RSA public key which can be used for
-                               signing.
-
-       DHE_RSA_EXPORT          RSA public key which can be used for
-                               signing.
-
-       DH_DSS                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate should be DSS.
-
-       DH_RSA                  Diffie-Hellman key. The algorithm used
-                               to sign the certificate should be RSA.
-
-   All certificate profiles, key and cryptographic formats are defined
-   by the IETF PKIX working group [PKIX]. When a key usage extension is
-   present, the digitalSignature bit must be set for the key to be
-   eligible for signing, as described above, and the keyEncipherment bit
-   must be present to allow encryption, as described above. The
-   keyAgreement bit must be set on Diffie-Hellman certificates.
-
-   As CipherSuites which specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-       opaque ASN.1Cert<1..2^24-1>;
-
-       struct {
-           ASN.1Cert certificate_list<0..2^24-1>;
-       } Certificate;
-
-
-
-Dierks & Allen              Standards Track                    [Page 38]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   certificate_list
-       This is a sequence (chain) of X.509v3 certificates. The sender's
-       certificate must come first in the list. Each following
-       certificate must directly certify the one preceding it. Because
-       certificate validation requires that root keys be distributed
-       independently, the self-signed certificate which specifies the
-       root certificate authority may optionally be omitted from the
-       chain, under the assumption that the remote end must already
-       possess it in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message. Note that a client may
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
- Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-       vector because PKCS #6 [PKCS6] extended certificates are not
-       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
-       the task of parsing the list more difficult.
-
-7.4.3. Server key exchange message
-
-   When this message will be sent:
-       This message will be sent immediately after the server
-       certificate message (or the server hello message, if this is an
-       anonymous negotiation).
-
-       The server key exchange message is sent by the server only when
-       the server certificate message (if sent) does not contain enough
-       data to allow the client to exchange a premaster secret. This is
-       true for the following key exchange methods:
-
-           RSA_EXPORT (if the public key in the server certificate is
-           longer than 512 bits)
-           DHE_DSS
-           DHE_DSS_EXPORT
-           DHE_RSA
-           DHE_RSA_EXPORT
-           DH_anon
-
-       It is not legal to send the server key exchange message for the
-       following key exchange methods:
-
-           RSA
-           RSA_EXPORT (when the public key in the server certificate is
-           less than or equal to 512 bits in length)
-           DH_DSS
-           DH_RSA
-
-
-
-Dierks & Allen              Standards Track                    [Page 39]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Meaning of this message:
-       This message conveys cryptographic information to allow the
-       client to communicate the premaster secret: either an RSA public
-       key to encrypt the premaster secret with, or a Diffie-Hellman
-       public key with which the client can complete a key exchange
-       (with the result being the premaster secret.)
-
-   As additional CipherSuites are defined for TLS which include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
- Note: According to current US export law, RSA moduli larger than 512
-       bits may not be used for key exchange in software exported from
-       the US. With this message, the larger RSA keys encoded in
-       certificates may be used to sign temporary shorter RSA keys for
-       the RSA_EXPORT key exchange method.
-
-   Structure of this message:
-       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-       struct {
-           opaque rsa_modulus<1..2^16-1>;
-           opaque rsa_exponent<1..2^16-1>;
-       } ServerRSAParams;
-
-       rsa_modulus
-           The modulus of the server's temporary RSA key.
-
-       rsa_exponent
-           The public exponent of the server's temporary RSA key.
-
-       struct {
-           opaque dh_p<1..2^16-1>;
-           opaque dh_g<1..2^16-1>;
-           opaque dh_Ys<1..2^16-1>;
-       } ServerDHParams;     /* Ephemeral DH parameters */
-
-       dh_p
-           The prime modulus used for the Diffie-Hellman operation.
-
-       dh_g
-           The generator used for the Diffie-Hellman operation.
-
-       dh_Ys
-           The server's Diffie-Hellman public value (g^X mod p).
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 40]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case diffie_hellman:
-                   ServerDHParams params;
-                   Signature signed_params;
-               case rsa:
-                   ServerRSAParams params;
-                   Signature signed_params;
-           };
-       } ServerKeyExchange;
-
-       params
-           The server's key exchange parameters.
-
-       signed_params
-           For non-anonymous key exchanges, a hash of the corresponding
-           params value, with the signature appropriate to that hash
-           applied.
-
-       md5_hash
-           MD5(ClientHello.random + ServerHello.random + ServerParams);
-
-       sha_hash
-           SHA(ClientHello.random + ServerHello.random + ServerParams);
-
-       enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-       select (SignatureAlgorithm)
-       {   case anonymous: struct { };
-           case rsa:
-               digitally-signed struct {
-                   opaque md5_hash[16];
-                   opaque sha_hash[20];
-               };
-           case dsa:
-               digitally-signed struct {
-                   opaque sha_hash[20];
-               };
-       } Signature;
-
-7.4.4. Certificate request
-
-   When this message will be sent:
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite. This
-       message, if sent, will immediately follow the Server Key Exchange
-       message (if it is sent; otherwise, the Server Certificate
-       message).
-
-
-
-Dierks & Allen              Standards Track                    [Page 41]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Structure of this message:
-       enum {
-           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-           (255)
-       } ClientCertificateType;
-
-       opaque DistinguishedName<1..2^16-1>;
-
-       struct {
-           ClientCertificateType certificate_types<1..2^8-1>;
-           DistinguishedName certificate_authorities<3..2^16-1>;
-       } CertificateRequest;
-
-       certificate_types
-              This field is a list of the types of certificates requested,
-              sorted in order of the server's preference.
-
-       certificate_authorities
-           A list of the distinguished names of acceptable certificate
-           authorities. These distinguished names may specify a desired
-           distinguished name for a root CA or for a subordinate CA;
-           thus, this message can be used both to describe known roots
-           and a desired authorization space.
-
- Note: DistinguishedName is derived from [X509].
-
- Note: It is a fatal handshake_failure alert for an anonymous server to
-       request client identification.
-
-7.4.5. Server hello done
-
-   When this message will be sent:
-       The server hello done message is sent by the server to indicate
-       the end of the server hello and associated messages. After
-       sending this message the server will wait for a client response.
-
-   Meaning of this message:
-       This message means that the server is done sending messages to
-       support the key exchange, and the client can proceed with its
-       phase of the key exchange.
-
-       Upon receipt of the server hello done message the client should
-       verify that the server provided a valid certificate if required
-       and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-       struct { } ServerHelloDone;
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 42]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-7.4.6. Client certificate
-
-   When this message will be sent:
-       This is the first message the client can send after receiving a
-       server hello done message. This message is only sent if the
-       server requests a certificate. If no suitable certificate is
-       available, the client should send a certificate message
-       containing no certificates. If client authentication is required
-       by the server for the handshake to continue, it may respond with
-       a fatal handshake failure alert. Client certificates are sent
-       using the Certificate structure defined in Section 7.4.2.
-
- Note: When using a static Diffie-Hellman based key exchange method
-       (DH_DSS or DH_RSA), if client authentication is requested, the
-       Diffie-Hellman group and generator encoded in the client's
-       certificate must match the server specified Diffie-Hellman
-       parameters if the client's parameters are to be used for the key
-       exchange.
-
-7.4.7. Client key exchange message
-
-   When this message will be sent:
-       This message is always sent by the client. It will immediately
-       follow the client certificate message, if it is sent. Otherwise
-       it will be the first message sent by the client after it receives
-       the server hello done message.
-
-   Meaning of this message:
-       With this message, the premaster secret is set, either though
-       direct transmission of the RSA-encrypted secret, or by the
-       transmission of Diffie-Hellman parameters which will allow each
-       side to agree upon the same premaster secret. When the key
-       exchange method is DH_RSA or DH_DSS, client certification has
-       been requested, and the client was able to respond with a
-       certificate which contained a Diffie-Hellman public key whose
-       parameters (group and generator) matched those specified by the
-       server in its certificate, this message will not contain any
-       data.
-
-   Structure of this message:
-       The choice of messages depends on which key exchange method has
-       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
-       definition.
-
-       struct {
-           select (KeyExchangeAlgorithm) {
-               case rsa: EncryptedPreMasterSecret;
-               case diffie_hellman: ClientDiffieHellmanPublic;
-
-
-
-Dierks & Allen              Standards Track                    [Page 43]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-           } exchange_keys;
-       } ClientKeyExchange;
-
-7.4.7.1. RSA encrypted premaster secret message
-
-   Meaning of this message:
-       If RSA is being used for key agreement and authentication, the
-       client generates a 48-byte premaster secret, encrypts it using
-       the public key from the server's certificate or the temporary RSA
-       key provided in a server key exchange message, and sends the
-       result in an encrypted premaster secret message. This structure
-       is a variant of the client key exchange message, not a message in
-       itself.
-
-   Structure of this message:
-       struct {
-           ProtocolVersion client_version;
-           opaque random[46];
-       } PreMasterSecret;
-
-       client_version
-           The latest (newest) version supported by the client. This is
-           used to detect version roll-back attacks. Upon receiving the
-           premaster secret, the server should check that this value
-           matches the value transmitted by the client in the client
-           hello message.
-
-       random
-           46 securely-generated random bytes.
-
-       struct {
-           public-key-encrypted PreMasterSecret pre_master_secret;
-       } EncryptedPreMasterSecret;
-
- Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
-       to attack a TLS server which is using PKCS#1 encoded RSA. The
-       attack takes advantage of the fact that by failing in different
-       ways, a TLS server can be coerced into revealing whether a
-       particular message, when decrypted, is properly PKCS#1 formatted
-       or not.
-
-       The best way to avoid vulnerability to this attack is to treat
-       incorrectly formatted messages in a manner indistinguishable from
-       correctly formatted RSA blocks. Thus, when it receives an
-       incorrectly formatted RSA block, a server should generate a
-       random 48-byte value and proceed using it as the premaster
-       secret. Thus, the server will act identically whether the
-       received RSA block is correctly encoded or not.
-
-
-
-Dierks & Allen              Standards Track                    [Page 44]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       pre_master_secret
-           This random value is generated by the client and is used to
-           generate the master secret, as specified in Section 8.1.
-
-7.4.7.2. Client Diffie-Hellman public value
-
-   Meaning of this message:
-       This structure conveys the client's Diffie-Hellman public value
-       (Yc) if it was not already included in the client's certificate.
-       The encoding used for Yc is determined by the enumerated
-       PublicValueEncoding. This structure is a variant of the client
-       key exchange message, not a message in itself.
-
-   Structure of this message:
-       enum { implicit, explicit } PublicValueEncoding;
-
-       implicit
-           If the client certificate already contains a suitable
-           Diffie-Hellman key, then Yc is implicit and does not need to
-           be sent again. In this case, the Client Key Exchange message
-           will be sent, but will be empty.
-
-       explicit
-           Yc needs to be sent.
-
-       struct {
-           select (PublicValueEncoding) {
-               case implicit: struct { };
-               case explicit: opaque dh_Yc<1..2^16-1>;
-           } dh_public;
-       } ClientDiffieHellmanPublic;
-
-       dh_Yc
-           The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-       This message is used to provide explicit verification of a client
-       certificate. This message is only sent following a client
-       certificate that has signing capability (i.e. all certificates
-       except those containing fixed Diffie-Hellman parameters). When
-       sent, it will immediately follow the client key exchange message.
-
-   Structure of this message:
-       struct {
-            Signature signature;
-       } CertificateVerify;
-
-
-
-Dierks & Allen              Standards Track                    [Page 45]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       The Signature type is defined in 7.4.3.
-
-       CertificateVerify.signature.md5_hash
-           MD5(handshake_messages);
-
-       Certificate.signature.sha_hash
-           SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages. This is the concatenation of all the Handshake structures
-   as defined in 7.4 exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-       A finished message is always sent immediately after a change
-       cipher spec message to verify that the key exchange and
-       authentication processes were successful. It is essential that a
-       change cipher spec message be received between the other
-       handshake messages and the Finished message.
-
-   Meaning of this message:
-       The finished message is the first protected with the just-
-       negotiated algorithms, keys, and secrets. Recipients of finished
-       messages must verify that the contents are correct.  Once a side
-       has sent its Finished message and received and validated the
-       Finished message from its peer, it may begin to send and receive
-       application data over the connection.
-
-       struct {
-           opaque verify_data[12];
-       } Finished;
-
-       verify_data
-           PRF(master_secret, finished_label, MD5(handshake_messages) +
-           SHA-1(handshake_messages)) [0..11];
-
-       finished_label
-           For Finished messages sent by the client, the string "client
-           finished". For Finished messages sent by the server, the
-           string "server finished".
-
-       handshake_messages
-           All of the data from all handshake messages up to but not
-           including this message. This is only data visible at the
-           handshake layer and does not include record layer headers.
-
-
-
-Dierks & Allen              Standards Track                    [Page 46]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-           This is the concatenation of all the Handshake structures as
-           defined in 7.4 exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The hash contained in finished messages sent by the server
-   incorporate Sender.server; those sent by the client incorporate
-   Sender.client. The value handshake_messages includes all handshake
-   messages starting at client hello up to, but not including, this
-   finished message. This may be different from handshake_messages in
-   Section 7.4.8 because it would include the certificate verify message
-   (if sent). Also, the handshake_messages for the finished message sent
-   by the client will be different from that for the finished message
-   sent by the server, because the one which is sent second will include
-   the prior one.
-
- Note: Change cipher spec messages, alerts and any other record types
-       are not handshake messages and are not included in the hash
-       computations. Also, Hello Request messages are omitted from
-       handshake hashes.
-
-8. Cryptographic computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values. The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message. The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages. All that remains is to calculate
-   the master secret.
-
-8.1. Computing the master secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret. The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length. The length of
-   the premaster secret will vary depending on key exchange method.
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 47]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a 48-
-   byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server. The server uses its
-   private key to decrypt the pre_master_secret. Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed. The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.
-
- Note: Diffie-Hellman parameters are specified by the server, and may
-       be either ephemeral or contained within the server's certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
-
-10. Application data protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed and encrypted based on the current connection
-   state. The messages are treated as transparent data to the record
-   layer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 48]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-A. Protocol constant values
-
-   This section describes protocol types and constants.
-
-A.1. Record layer
-
-    struct {
-        uint8 major, minor;
-    } ProtocolVersion;
-
-    ProtocolVersion version = { 3, 1 };     /* TLS v1.0 */
-
-    enum {
-        change_cipher_spec(20), alert(21), handshake(22),
-        application_data(23), (255)
-    } ContentType;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSPlaintext.length];
-    } TLSPlaintext;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        opaque fragment[TLSCompressed.length];
-    } TLSCompressed;
-
-    struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-            case stream: GenericStreamCipher;
-            case block:  GenericBlockCipher;
-        } fragment;
-    } TLSCiphertext;
-
-    stream-ciphered struct {
-        opaque content[TLSCompressed.length];
-        opaque MAC[CipherSpec.hash_size];
-    } GenericStreamCipher;
-
-    block-ciphered struct {
-        opaque content[TLSCompressed.length];
-
-
-
-Dierks & Allen              Standards Track                    [Page 49]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-        opaque MAC[CipherSpec.hash_size];
-        uint8 padding[GenericBlockCipher.padding_length];
-        uint8 padding_length;
-    } GenericBlockCipher;
-
-A.2. Change cipher specs message
-
-    struct {
-        enum { change_cipher_spec(1), (255) } type;
-    } ChangeCipherSpec;
-
-A.3. Alert messages
-
-    enum { warning(1), fatal(2), (255) } AlertLevel;
-
-        enum {
-            close_notify(0),
-            unexpected_message(10),
-            bad_record_mac(20),
-            decryption_failed(21),
-            record_overflow(22),
-            decompression_failure(30),
-            handshake_failure(40),
-            bad_certificate(42),
-            unsupported_certificate(43),
-            certificate_revoked(44),
-            certificate_expired(45),
-            certificate_unknown(46),
-            illegal_parameter(47),
-            unknown_ca(48),
-            access_denied(49),
-            decode_error(50),
-            decrypt_error(51),
-            export_restriction(60),
-            protocol_version(70),
-            insufficient_security(71),
-            internal_error(80),
-            user_canceled(90),
-            no_renegotiation(100),
-            (255)
-        } AlertDescription;
-
-    struct {
-        AlertLevel level;
-        AlertDescription description;
-    } Alert;
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 50]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-A.4. Handshake protocol
-
-    enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), (255)
-    } HandshakeType;
-
-    struct {
-        HandshakeType msg_type;
-        uint24 length;
-        select (HandshakeType) {
-            case hello_request:       HelloRequest;
-            case client_hello:        ClientHello;
-            case server_hello:        ServerHello;
-            case certificate:         Certificate;
-            case server_key_exchange: ServerKeyExchange;
-            case certificate_request: CertificateRequest;
-            case server_hello_done:   ServerHelloDone;
-            case certificate_verify:  CertificateVerify;
-            case client_key_exchange: ClientKeyExchange;
-            case finished:            Finished;
-        } body;
-    } Handshake;
-
-A.4.1. Hello messages
-
-    struct { } HelloRequest;
-
-    struct {
-        uint32 gmt_unix_time;
-        opaque random_bytes[28];
-    } Random;
-
-    opaque SessionID<0..32>;
-
-    uint8 CipherSuite[2];
-
-    enum { null(0), (255) } CompressionMethod;
-
-    struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Allen              Standards Track                    [Page 51]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-    } ClientHello;
-
-    struct {
-        ProtocolVersion server_version;
-        Random random;
-        SessionID session_id;
-        CipherSuite cipher_suite;
-        CompressionMethod compression_method;
-    } ServerHello;
-
-A.4.2. Server authentication and key exchange messages
-
-    opaque ASN.1Cert<2^24-1>;
-
-    struct {
-        ASN.1Cert certificate_list<1..2^24-1>;
-    } Certificate;
-
-    enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-    struct {
-        opaque RSA_modulus<1..2^16-1>;
-        opaque RSA_exponent<1..2^16-1>;
-    } ServerRSAParams;
-
-    struct {
-        opaque DH_p<1..2^16-1>;
-        opaque DH_g<1..2^16-1>;
-        opaque DH_Ys<1..2^16-1>;
-    } ServerDHParams;
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case diffie_hellman:
-                ServerDHParams params;
-                Signature signed_params;
-            case rsa:
-                ServerRSAParams params;
-                Signature signed_params;
-        };
-    } ServerKeyExchange;
-
-    enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-    select (SignatureAlgorithm)
-    {   case anonymous: struct { };
-        case rsa:
-            digitally-signed struct {
-
-
-
-Dierks & Allen              Standards Track                    [Page 52]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-                opaque md5_hash[16];
-                opaque sha_hash[20];
-            };
-        case dsa:
-            digitally-signed struct {
-                opaque sha_hash[20];
-            };
-    } Signature;
-
-    enum {
-        rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-        (255)
-    } ClientCertificateType;
-
-    opaque DistinguishedName<1..2^16-1>;
-
-    struct {
-        ClientCertificateType certificate_types<1..2^8-1>;
-        DistinguishedName certificate_authorities<3..2^16-1>;
-    } CertificateRequest;
-
-    struct { } ServerHelloDone;
-
-A.4.3. Client authentication and key exchange messages
-
-    struct {
-        select (KeyExchangeAlgorithm) {
-            case rsa: EncryptedPreMasterSecret;
-            case diffie_hellman: DiffieHellmanClientPublicValue;
-        } exchange_keys;
-    } ClientKeyExchange;
-
-    struct {
-        ProtocolVersion client_version;
-        opaque random[46];
-
-    } PreMasterSecret;
-
-    struct {
-        public-key-encrypted PreMasterSecret pre_master_secret;
-    } EncryptedPreMasterSecret;
-
-    enum { implicit, explicit } PublicValueEncoding;
-
-    struct {
-        select (PublicValueEncoding) {
-            case implicit: struct {};
-            case explicit: opaque DH_Yc<1..2^16-1>;
-
-
-
-Dierks & Allen              Standards Track                    [Page 53]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-        } dh_public;
-    } ClientDiffieHellmanPublic;
-
-    struct {
-        Signature signature;
-    } CertificateVerify;
-
-A.4.4. Handshake finalization message
-
-    struct {
-        opaque verify_data[12];
-    } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.0.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange. The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-
-
-
-Dierks & Allen              Standards Track                    [Page 54]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate, which has been
-   signed by the CA. The signing algorithm used is specified after the
-   DH or DHE parameter. The server can request an RSA or DSS signature-
-   capable certificate from the client for client authentication or it
-   may request a Diffie-Hellman certificate. Any Diffie-Hellman
-   certificate provided by the client must use the parameters (group and
-   generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous
-   Diffie-Hellman communications in which neither party is
-   authenticated. Note that this mode is vulnerable to man-in-the-middle
-   attacks and is therefore deprecated.
-
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
- Note: All cipher suites whose first byte is 0xFF are considered
-       private and can be used for defining local/experimental
-       algorithms. Interoperability of such types is a local matter.
-
- Note: Additional cipher suites can be registered by publishing an RFC
-       which specifies the cipher suites, including the necessary TLS
-       protocol information, including message encoding, premaster
-       secret derivation, symmetric encryption and MAC calculation and
-       appropriate reference information for the algorithms involved.
-       The RFC editor's office may, at its discretion, choose to publish
-       specifications for cipher suites which are not completely
-       described (e.g., for classified algorithms) if it finds the
-       specification to be of technical interest and completely
-       specified.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 55]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-       reserved to avoid collision with Fortezza-based cipher suites in
-       SSL 3.
-
-A.6. The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS Record Layer in order
-   to initialize a connection state. SecurityParameters includes:
-
-       enum { null(0), (255) } CompressionMethod;
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { true, false } IsExportable;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-   /* The algorithms specified in CompressionMethod,
-   BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd entity;
-           BulkCipherAlgorithm bulk_cipher_algorithm;
-           CipherType cipher_type;
-           uint8 key_size;
-           uint8 key_material_length;
-           IsExportable is_exportable;
-           MACAlgorithm mac_algorithm;
-           uint8 hash_size;
-           CompressionMethod compression_algorithm;
-           opaque master_secret[48];
-           opaque client_random[32];
-           opaque server_random[32];
-       } SecurityParameters;
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 56]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-B. Glossary
-
-   application protocol
-       An application protocol is a protocol that normally layers
-       directly on top of the transport layer (e.g., TCP/IP). Examples
-       include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-       See public key cryptography.
-
-   authentication
-       Authentication is the ability of one entity to determine the
-       identity of another entity.
-
-   block cipher
-       A block cipher is an algorithm that operates on plaintext in
-       groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-       A symmetric encryption algorithm used to encrypt large quantities
-       of data.
-
-   cipher block chaining (CBC)
-       CBC is a mode in which every plaintext block encrypted with a
-       block cipher is first exclusive-ORed with the previous ciphertext
-       block (or, in the case of the first block, with the
-       initialization vector). For decryption, every block is first
-       decrypted, then exclusive-ORed with the previous ciphertext block
-       (or IV).
-
-   certificate
-       As part of the X.509 protocol (a.k.a. ISO Authentication
-       framework), certificates are assigned by a trusted Certificate
-       Authority and provide a strong binding between a party's identity
-       or some other attributes and its public key.
-
-   client
-       The application entity that initiates a TLS connection to a
-       server. This may or may not imply that the client initiated the
-       underlying transport connection. The primary operational
-       difference between the server and client is that the server is
-       generally authenticated, while the client is only optionally
-       authenticated.
-
-   client write key
-       The key used to encrypt data written by the client.
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 57]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   client write MAC secret
-       The secret data used to authenticate data written by the client.
-
-   connection
-       A connection is a transport (in the OSI layering model
-       definition) that provides a suitable type of service. For TLS,
-       such connections are peer to peer relationships. The connections
-       are transient. Every connection is associated with one session.
-
-   Data Encryption Standard
-       DES is a very widely used symmetric encryption algorithm. DES is
-       a block cipher with a 56 bit key and an 8 byte block size. Note
-       that in TLS, for key generation purposes, DES is treated as
-       having an 8 byte key length (64 bits), but it still only provides
-       56 bits of protection. (The low bit of each key byte is presumed
-       to be set to produce odd parity in that key byte.) DES can also
-       be operated in a mode where three independent keys and three
-       encryptions are used for each block of data; this uses 168 bits
-       of key (24 bytes in the TLS key generation method) and provides
-       the equivalent of 112 bits of security. [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-       A standard for digital signing, including the Digital Signing
-       Algorithm, approved by the National Institute of Standards and
-       Technology, defined in NIST FIPS PUB 186, "Digital Signature
-       Standard," published May, 1994 by the U.S. Dept. of Commerce.
-       [DSS]
-
-   digital signatures
-       Digital signatures utilize public key cryptography and one-way
-       hash functions to produce a signature of the data that can be
-       authenticated, and is difficult to forge or repudiate.
-
-   handshake
-       An initial negotiation between client and server that establishes
-       the parameters of their transactions.
-
-   Initialization Vector (IV)
-       When a block cipher is used in CBC mode, the initialization
-       vector is exclusive-ORed with the first plaintext block prior to
-       encryption.
-
-   IDEA
-       A 64-bit block cipher designed by Xuejia Lai and James Massey.
-       [IDEA]
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 58]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Message Authentication Code (MAC)
-       A Message Authentication Code is a one-way hash computed from a
-       message and some secret data. It is difficult to forge without
-       knowing the secret data. Its purpose is to detect if the message
-       has been altered.
-
-   master secret
-       Secure secret data used for generating encryption keys, MAC
-       secrets, and IVs.
-
-   MD5
-       MD5 is a secure hashing function that converts an arbitrarily
-       long data stream into a digest of fixed size (16 bytes). [MD5]
-
-   public key cryptography
-       A class of cryptographic techniques employing two-key ciphers.
-       Messages encrypted with the public key can only be decrypted with
-       the associated private key. Conversely, messages signed with the
-       private key can be verified with the public key.
-
-   one-way hash function
-       A one-way transformation that converts an arbitrary amount of
-       data into a fixed-length hash. It is computationally hard to
-       reverse the transformation or to find collisions. MD5 and SHA are
-       examples of one-way hash functions.
-
-   RC2
-       A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-       [RSADSI] described in [RC2].
-
-   RC4
-       A stream cipher licensed by RSA Data Security [RSADSI]. A
-       compatible cipher is described in [RC4].
-
-   RSA
-       A very widely used public-key algorithm that can be used for
-       either encryption or digital signing. [RSA]
-
-   salt
-       Non-secret random data used to make export encryption keys resist
-       precomputation attacks.
-
-   server
-       The server is the application entity that responds to requests
-       for connections from clients. See also under client.
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 59]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   session
-       A TLS session is an association between a client and a server.
-       Sessions are created by the handshake protocol. Sessions define a
-       set of cryptographic security parameters, which can be shared
-       among multiple connections. Sessions are used to avoid the
-       expensive negotiation of new security parameters for each
-       connection.
-
-   session identifier
-       A session identifier is a value generated by a server that
-       identifies a particular session.
-
-   server write key
-       The key used to encrypt data written by the server.
-
-   server write MAC secret
-       The secret data used to authenticate data written by the server.
-
-   SHA
-       The Secure Hash Algorithm is defined in FIPS PUB 180-1. It
-       produces a 20-byte output. Note that all references to SHA
-       actually use the modified SHA-1 algorithm. [SHA]
-
-   SSL
-       Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
-       SSL Version 3.0
-
-   stream cipher
-       An encryption algorithm that converts a key into a
-       cryptographically-strong keystream, which is then exclusive-ORed
-       with the plaintext.
-
-   symmetric cipher
-       See bulk cipher.
-
-   Transport Layer Security (TLS)
-       This protocol; also, the Transport Layer Security working group
-       of the Internet Engineering Task Force (IETF). See "Comments" at
-       the end of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 60]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-C. CipherSuite definitions
-
-CipherSuite                      Is       Key          Cipher      Hash
-                             Exportable Exchange
-
-TLS_NULL_WITH_NULL_NULL               * NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                 * RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                 * RSA            NULL         SHA
-TLS_RSA_EXPORT_WITH_RC4_40_MD5        * RSA_EXPORT     RC4_40       MD5
-TLS_RSA_WITH_RC4_128_MD5                RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA            RC4_128      SHA
-TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5    * RSA_EXPORT     RC2_CBC_40   MD5
-TLS_RSA_WITH_IDEA_CBC_SHA               RSA            IDEA_CBC     SHA
-TLS_RSA_EXPORT_WITH_DES40_CBC_SHA     * RSA_EXPORT     DES40_CBC    SHA
-TLS_RSA_WITH_DES_CBC_SHA                RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA            3DES_EDE_CBC SHA
-TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA  * DH_DSS_EXPORT  DES40_CBC    SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA             DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA  * DH_RSA_EXPORT  DES40_CBC    SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA             DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC    SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA            DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC    SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA            DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_EXPORT_WITH_RC4_40_MD5    * DH_anon_EXPORT RC4_40       MD5
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon        RC4_128      MD5
-TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA   DH_anon        DES40_CBC    SHA
-TLS_DH_anon_WITH_DES_CBC_SHA            DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon        3DES_EDE_CBC SHA
-
-
-   * Indicates IsExportable is True
-
-      Key
-      Exchange
-      Algorithm       Description                        Key size limit
-
-      DHE_DSS         Ephemeral DH with DSS signatures   None
-      DHE_DSS_EXPORT  Ephemeral DH with DSS signatures   DH = 512 bits
-      DHE_RSA         Ephemeral DH with RSA signatures   None
-      DHE_RSA_EXPORT  Ephemeral DH with RSA signatures   DH = 512 bits,
-                                                         RSA = none
-      DH_anon         Anonymous DH, no signatures        None
-      DH_anon_EXPORT  Anonymous DH, no signatures        DH = 512 bits
-
-
-
-Dierks & Allen              Standards Track                    [Page 61]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-      DH_DSS          DH with DSS-based certificates     None
-      DH_DSS_EXPORT   DH with DSS-based certificates     DH = 512 bits
-      DH_RSA          DH with RSA-based certificates     None
-      DH_RSA_EXPORT   DH with RSA-based certificates     DH = 512 bits,
-                                                         RSA = none
-      NULL            No key exchange                    N/A
-      RSA             RSA key exchange                   None
-      RSA_EXPORT      RSA key exchange                   RSA = 512 bits
-
-   Key size limit
-       The key size limit gives the size of the largest public key that
-       can be legally used for encryption in cipher suites that are
-       exportable.
-
-                         Key      Expanded   Effective   IV    Block
-    Cipher       Type  Material Key Material  Key Bits  Size   Size
-
-    NULL       * Stream   0          0           0        0     N/A
-    IDEA_CBC     Block   16         16         128        8      8
-    RC2_CBC_40 * Block    5         16          40        8      8
-    RC4_40     * Stream   5         16          40        0     N/A
-    RC4_128      Stream  16         16         128        0     N/A
-    DES40_CBC  * Block    5          8          40        8      8
-    DES_CBC      Block    8          8          56        8      8
-    3DES_EDE_CBC Block   24         24         168        8      8
-
-   * Indicates IsExportable is true.
-
-   Type
-       Indicates whether this is a stream cipher or a block cipher
-       running in CBC mode.
-
-   Key Material
-       The number of bytes from the key_block that are used for
-       generating the write keys.
-
-   Expanded Key Material
-       The number of bytes actually fed into the encryption algorithm
-
-   Effective Key Bits
-       How much entropy material is in the key material being fed into
-       the encryption routines.
-
-   IV Size
-       How much data needs to be generated for the initialization
-       vector. Zero for stream ciphers; equal to the block size for
-       block ciphers.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 62]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Block Size
-       The amount of data a block cipher enciphers in one chunk; a
-       block cipher running in CBC mode can only encrypt an even
-       multiple of its block size.
-
-      Hash      Hash      Padding
-    function    Size       Size
-      NULL       0          0
-      MD5        16         48
-      SHA        20         40
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 63]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes. This
-   section provides several recommendations to assist implementors.
-
-D.1. Temporary RSA keys
-
-   US Export restrictions limit RSA keys used for encryption to 512
-   bits, but do not place any limit on lengths of RSA keys used for
-   signing operations. Certificates often need to be larger than 512
-   bits, since 512-bit RSA keys are not secure enough for high-value
-   transactions or for applications requiring long-term security. Some
-   certificates are also designated signing-only, in which case they
-   cannot be used for key exchange.
-
-   When the public key in the certificate cannot be used for encryption,
-   the server signs a temporary RSA key, which is then exchanged. In
-   exportable applications, the temporary RSA key should be the maximum
-   allowable length (i.e., 512 bits). Because 512-bit RSA keys are
-   relatively insecure, they should be changed often. For typical
-   electronic commerce applications, it is suggested that keys be
-   changed daily or every 500 transactions, and more often if possible.
-   Note that while it is acceptable to use the same temporary key for
-   multiple transactions, it must be signed each time it is used.
-
-   RSA key generation is a time-consuming process. In many cases, a
-   low-priority process can be assigned the task of key generation.
-
-   Whenever a new key is completed, the existing temporary key can be
-   replaced with the new one.
-
-D.2. Random Number Generation and Seeding
-
-   TLS requires a cryptographically-secure pseudorandom number generator
-   (PRNG). Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state. (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte. For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more. To seed a 128-bit PRNG, one
-   would thus require approximately 100 such timer values.
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 64]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
- Warning: The seeding functions in RSAREF and versions of BSAFE prior to
-          3.0 are order-independent. For example, if 1000 seed bits are
-          supplied, one at a time, in 1000 separate calls to the seed
-          function, the PRNG will end up in a state which depends only
-          on the number of 0 or 1 seed bits in the seed data (i.e.,
-          there are 1001 possible final states). Applications using
-          BSAFE or RSAREF must take extra care to ensure proper seeding.
-          This may be accomplished by accumulating seed bits into a
-          buffer and processing them all at once or by processing an
-          incrementing counter with every seed bit; either method will
-          reintroduce order dependence into the seeding process.
-
-D.3. Certificates and authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages. Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA). The selection and
-   addition of trusted CAs should be done very carefully. Users should
-   be able to view information about the certificate and root CA.
-
-D.4. CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   which provide no or minimal security. A proper implementation will
-   probably not support many cipher suites. For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys. Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-
-   the-middle attacks. Applications should also enforce minimum and
-   maximum key sizes. For example, certificate chains containing 512-bit
-   RSA keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 65]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-E. Backward Compatibility With SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols which are secured by
-   TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port: for example, the https protocol (HTTP secured by SSL
-   or TLS) uses port 443 regardless of which security protocol it is
-   using. Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
-   is easy. TLS clients who wish to negotiate with SSL 3.0 servers
-   should send client hello messages using the SSL 3.0 record format and
-   client hello structure, sending {3, 1} for the version field to note
-   that they support TLS 1.0. If the server supports only SSL 3.0, it
-   will respond with an SSL 3.0 server hello; if it supports TLS, with a
-   TLS server hello. The negotiation then proceeds as appropriate for
-   the negotiated protocol.
-
-   Similarly, a TLS server which wishes to interoperate with SSL 3.0
-   clients should accept SSL 3.0 client hello messages and respond with
-   an SSL 3.0 server hello if an SSL 3.0 client hello is received which
-   has a version field of {3, 0}, denoting that this client does not
-   support TLS.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it should initiate the
-   connection in that native protocol.
-
-   TLS 1.0 clients that support SSL Version 2.0 servers must send SSL
-   Version 2.0 client hello messages [SSL2]. TLS servers should accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port. The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
- Warning: The ability to send Version 2.0 client hello messages will be
-          phased out with all due haste. Implementors should make every
-          effort to move forward as quickly as possible. Version 3.0
-          provides better mechanisms for moving to newer versions.
-
-   The following cipher specifications are carryovers from SSL Version
-   2.0. These are assumed to use RSA for key exchange and
-   authentication.
-
-       V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-       V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-       V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-
-
-
-Dierks & Allen              Standards Track                    [Page 66]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                  = { 0x04,0x00,0x80 };
-       V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-       V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-       V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-   Cipher specifications native to TLS can be included in Version 2.0
-   client hello messages using the syntax below. Any V2CipherSpec
-   element with its first byte equal to zero will be ignored by Version
-   2.0 servers. Clients sending any of the above V2CipherSpecs should
-   also include the TLS equivalent (see Appendix A.5):
-
-       V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
-E.1. Version 2 client hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model. The true definition is still assumed
-   to be the SSL Version 2.0 specification.
-
-       uint8 V2CipherSpec[3];
-
-       struct {
-           uint8 msg_type;
-           Version version;
-           uint16 cipher_spec_length;
-           uint16 session_id_length;
-           uint16 challenge_length;
-           V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-           opaque session_id[V2ClientHello.session_id_length];
-           Random challenge;
-       } V2ClientHello;
-
-   msg_type
-       This field, in conjunction with the version field, identifies a
-       version 2 client hello message. The value should be one (1).
-
-   version
-       The highest version of the protocol supported by the client
-       (equals ProtocolVersion.version, see Appendix A.1).
-
-   cipher_spec_length
-       This field is the total length of the field cipher_specs. It
-       cannot be zero and must be a multiple of the V2CipherSpec length
-       (3).
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 67]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   session_id_length
-       This field must have a value of either zero or 16. If zero, the
-       client is creating a new session. If 16, the session_id field
-       will contain the 16 bytes of session identification.
-
-   challenge_length
-       The length in bytes of the client's challenge to the server to
-       authenticate itself. This value must be 32.
-
-   cipher_specs
-       This is a list of all CipherSpecs the client is willing and able
-       to use. There must be at least one CipherSpec acceptable to the
-       server.
-
-   session_id
-       If this field's length is not zero, it will contain the
-       identification for a session that the client wishes to resume.
-
-   challenge
-       The client challenge to the server for the server to identify
-       itself is a (nearly) arbitrary length random. The TLS server will
-       right justify the challenge data to become the ClientHello.random
-       data (padded with leading zeroes, if necessary), as specified in
-       this protocol specification. If the length of the challenge is
-       greater than 32 bytes, only the last 32 bytes are used. It is
-       legitimate (but not necessary) for a V3 server to reject a V2
-       ClientHello that has fewer than 16 bytes of challenge data.
-
- Note: Requests to resume a TLS session should use a TLS client hello.
-
-E.2. Avoiding man-in-the-middle version rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   should use special PKCS #1 block formatting. This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random). After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS should issue an
-   error if these eight padding bytes are 0x03. Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 68]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-F. Security analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel. This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol. Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session. The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and key exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity. Whenever the server is authenticated, the channel is
-   secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients. If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server. Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers. The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1). The master_secret is required to
-   generate the certificate verify and finished messages, encryption
-   keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
-   a correct finished message, parties thus prove that they know the
-   correct pre_master_secret.
-
-F.1.1.1. Anonymous key exchange
-
-   Completely anonymous sessions can be established using RSA or
-   Diffie-Hellman for key exchange. With anonymous RSA, the client
-   encrypts a pre_master_secret with the server's uncertified public key
-
-
-
-Dierks & Allen              Standards Track                    [Page 69]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   extracted from the server key exchange message. The result is sent in
-   a client key exchange message. Since eavesdroppers do not know the
-   server's private key, it will be infeasible for them to decode the
-   pre_master_secret. (Note that no anonymous RSA Cipher Suites are
-   defined in this document).
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message. Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e. the pre_master_secret).
-
- Warning: Completely anonymous connections only provide protection
-          against passive eavesdropping. Unless an independent tamper-
-          proof channel is used to verify that the finished messages
-          were not replaced by an attacker, server authentication is
-          required in environments where active man-in-the-middle
-          attacks are a concern.
-
-F.1.1.2. RSA key exchange and authentication
-
-   With RSA, key exchange and server authentication are combined. The
-   public key may be either contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA or
-   DSS certificate. The signature includes the current
-   ClientHello.random, so old signatures and temporary keys cannot be
-   replayed. Servers may use a single temporary RSA key for multiple
-   negotiation sessions.
-
- Note: The temporary RSA key option is useful if servers need large
-       certificates but must comply with government-imposed size limits
-       on keys used for key exchange.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key. By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.8). The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages. These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 70]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-F.1.1.3. Diffie-Hellman key exchange with authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   can use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters. In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange. Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate. To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-F.1.2. Version rollback attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack. This solution is not secure against
-   attackers who can brute force the key and substitute a new
-   ENCRYPTED-KEY-DATA message containing the same key (but with normal
-   padding) before the application specified wait threshold has expired.
-   Parties concerned about attacks of this scale should not be using
-   40-bit encryption keys anyway. Altering the padding of the least-
-   significant 8 bytes of the PKCS padding does not impact security for
-   the size of the signed hashes and RSA key lengths used in the
-   protocol, since this is essentially equivalent to increasing the
-   input block size by 8 bytes.
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 71]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-F.1.3. Detecting attacks against the handshake protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally choose. Because many implementations will support 40-bit
-   exportable encryption and some may even support null encryption or
-   MAC algorithms, this attack is of particular concern.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages. If this occurs, the client and server will
-   compute different values for the handshake message hashes. As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-F.1.4. Resuming sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret. Provided that the master_secret has not been
-   compromised and that the secure hash operations used to produce the
-   encryption keys and MAC secrets are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake. An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired. Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5. MD5 and SHA
-
-   TLS uses hash functions very conservatively. Where possible, both MD5
-   and SHA are used in tandem to ensure that non-catastrophic flaws in
-   one algorithm will not break the overall protocol.
-
-F.2. Protecting application data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-
-
-Dierks & Allen              Standards Track                    [Page 72]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Outgoing data is protected with a MAC before transmission. To prevent
-   message replay or modification attacks, the MAC is computed from the
-   MAC secret, the sequence number, the message length, the message
-   contents, and two fixed character strings. The message type field is
-   necessary to ensure that messages intended for one TLS Record Layer
-   client are not redirected to another. The sequence number ensures
-   that attempts to delete or reorder messages will be detected. Since
-   sequence numbers are 64-bits long, they should never overflow.
-   Messages from one party cannot be inserted into the other's output,
-   since they use independent MAC secrets. Similarly, the server-write
-   and client-write keys are independent so stream cipher keys are used
-   only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read. Similarly, compromise of a MAC key can make
-   message modification attacks possible. Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
- Note: MAC secrets may be larger than encryption keys, so messages can
-       remain tamper resistant even if encryption keys are broken.
-
-F.3. Final notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure. In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used. Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution. Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 73]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-G. Patent Statement
-
-   Some of the cryptographic algorithms proposed for use in this
-   protocol have patent claims on them. In addition Netscape
-   Communications Corporation has a patent claim on the Secure Sockets
-   Layer (SSL) work that this standard is based on. The Internet
-   Standards Process as defined in RFC 2026 requests that a statement be
-   obtained from a Patent holder indicating that a license will be made
-   available to applicants under reasonable terms and conditions.
-
-   The Massachusetts Institute of Technology has granted RSA Data
-   Security, Inc., exclusive sub-licensing rights to the following
-   patent issued in the United States:
-
-       Cryptographic Communications System and Method ("RSA"), No.
-       4,405,829
-
-   Netscape Communications Corporation has been issued the following
-   patent in the United States:
-
-       Secure Socket Layer Application Program Apparatus And Method
-       ("SSL"), No. 5,657,390
-
-   Netscape Communications has issued the following statement:
-
-       Intellectual Property Rights
-
-       Secure Sockets Layer
-
-       The United States Patent and Trademark Office ("the PTO")
-       recently issued U.S. Patent No. 5,657,390 ("the SSL Patent")  to
-       Netscape for inventions described as Secure Sockets Layers
-       ("SSL"). The IETF is currently considering adopting SSL as a
-       transport protocol with security features.  Netscape encourages
-       the royalty-free adoption and use of the SSL protocol upon the
-       following terms and conditions:
-
-         * If you already have a valid SSL Ref license today which
-           includes source code from Netscape, an additional patent
-           license under the SSL patent is not required.
-
-         * If you don't have an SSL Ref license, you may have a royalty
-           free license to build implementations covered by the SSL
-           Patent Claims or the IETF TLS specification provided that you
-           do not to assert any patent rights against Netscape or other
-           companies for the implementation of SSL or the IETF TLS
-           recommendation.
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 74]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-       What are "Patent Claims":
-
-       Patent claims are claims in an issued foreign or domestic patent
-       that:
-
-        1) must be infringed in order to implement methods or build
-           products according to the IETF TLS specification;  or
-
-        2) patent claims which require the elements of the SSL patent
-           claims and/or their equivalents to be infringed.
-
-   The Internet Society, Internet Architecture Board, Internet
-   Engineering Steering Group and the Corporation for National Research
-   Initiatives take no position on the validity or scope of the patents
-   and patent applications, nor on the appropriateness of the terms of
-   the assurance. The Internet Society and other groups mentioned above
-   have not made any determination as to any other intellectual property
-   rights which may apply to the practice of this standard.  Any further
-   consideration of these matters is the user's own responsibility.
-
-Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-References
-
-   [3DES]   W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
-            IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
-
-   [BLEI]   Bleichenbacher D., "Chosen Ciphertext Attacks against
-            Protocols Based on RSA Encryption Standard PKCS #1" in
-            Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
-            1--12, 1998.
-
-   [DES]    ANSI X3.106, "American National Standard for Information
-            Systems-Data Link Encryption," American National Standards
-            Institute, 1983.
-
-   [DH1]    W. Diffie and M. E. Hellman, "New Directions in
-            Cryptography," IEEE Transactions on Information Theory, V.
-            IT-22, n. 6, Jun 1977, pp. 74-84.
-
-   [DSS]    NIST FIPS PUB 186, "Digital Signature Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, May 18, 1994.
-
-   [FTP]    Postel J., and J. Reynolds, "File Transfer Protocol", STD 9,
-            RFC 959, October 1985.
-
-
-
-Dierks & Allen              Standards Track                    [Page 75]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   [HTTP]   Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
-            Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
-
-   [HMAC]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
-            Hashing for Message Authentication," RFC 2104, February
-            1997.
-
-   [IDEA]   X. Lai, "On the Design and Security of Block Ciphers," ETH
-            Series in Information Processing, v. 1, Konstanz: Hartung-
-            Gorre Verlag, 1992.
-
-   [MD2]    Kaliski, B., "The MD2 Message Digest Algorithm", RFC 1319,
-            April 1992.
-
-   [MD5]    Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
-            April 1992.
-
-   [PKCS1]  RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
-            version 1.5, November 1993.
-
-   [PKCS6]  RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKCS7]  RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
-            Standard," version 1.5, November 1993.
-
-   [PKIX]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-            Public Key Infrastructure: Part I: X.509 Certificate and CRL
-            Profile", RFC 2459, January 1999.
-
-   [RC2]    Rivest, R., "A Description of the RC2(r) Encryption
-            Algorithm", RFC 2268, January 1998.
-
-   [RC4]    Thayer, R. and K. Kaukonen, A Stream Cipher Encryption
-            Algorithm, Work in Progress.
-
-   [RSA]    R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-            Obtaining Digital Signatures and Public-Key Cryptosystems,"
-            Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-
-            126.
-
-   [RSADSI] Contact RSA Data Security, Inc., Tel: 415-595-8782
-
-   [SCH]    B. Schneier. Applied Cryptography: Protocols, Algorithms,
-            and Source Code in C, Published by John Wiley & Sons, Inc.
-            1994.
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 76]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   [SHA]    NIST FIPS PUB 180-1, "Secure Hash Standard," National
-            Institute of Standards and Technology, U.S. Department of
-            Commerce, Work in Progress, May 31, 1994.
-
-   [SSL2]   Hickman, Kipp, "The SSL Protocol", Netscape Communications
-            Corp., Feb 9, 1995.
-
-   [SSL3]   A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
-            Netscape Communications Corp., Nov 18, 1996.
-
-   [TCP]    Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
-            September 1981.
-
-   [TEL]    Postel J., and J. Reynolds, "Telnet Protocol
-            Specifications", STD 8, RFC 854, May 1993.
-
-   [TEL]    Postel J., and J. Reynolds, "Telnet Option Specifications",
-            STD 8, RFC 855, May 1993.
-
-   [X509]   CCITT. Recommendation X.509: "The Directory - Authentication
-            Framework". 1988.
-
-   [XDR]    R. Srinivansan, Sun Microsystems, RFC-1832: XDR: External
-            Data Representation Standard, August 1995.
-
-Credits
-
-   Win Treese
-   Open Market
-
-   EMail: treese@openmarket.com
-
-
-   Editors
-
-   Christopher Allen                  Tim Dierks
-   Certicom                           Certicom
-
-   EMail: callen@certicom.com         EMail: tdierks@certicom.com
-
-
-   Authors' Addresses
-
-   Tim Dierks                         Philip L. Karlton
-   Certicom                           Netscape Communications
-
-   EMail: tdierks@certicom.com
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 77]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Alan O. Freier                     Paul C. Kocher
-   Netscape Communications            Independent Consultant
-
-   EMail: freier@netscape.com         EMail: pck@netcom.com
-
-
-   Other contributors
-
-   Martin Abadi                       Robert Relyea
-   Digital Equipment Corporation      Netscape Communications
-
-   EMail: ma@pa.dec.com               EMail: relyea@netscape.com
-
-   Ran Canetti                        Jim Roskind
-   IBM Watson Research Center         Netscape Communications
-
-   EMail: canetti@watson.ibm.com      EMail: jar@netscape.com
-
-
-   Taher Elgamal                      Micheal J. Sabin, Ph. D.
-   Securify                           Consulting Engineer
-
-   EMail: elgamal@securify.com        EMail: msabin@netcom.com
-
-
-   Anil R. Gangolli                   Dan Simon
-   Structured Arts Computing Corp.    Microsoft
-
-   EMail: gangolli@structuredarts.com EMail:  dansimon@microsoft.com
-
-
-   Kipp E.B. Hickman                  Tom Weinstein
-   Netscape Communications            Netscape Communications
-
-   EMail: kipp@netscape.com           EMail: tomw@netscape.com
-
-
-   Hugo Krawczyk
-   IBM Watson Research Center
-
-   EMail: hugo@watson.ibm.com
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <ietf-tls@lists.consensus.com>. Information on the
-   group and information on how to subscribe to the list is at
-   <http://lists.consensus.com/>.
-
-
-
-Dierks & Allen              Standards Track                    [Page 78]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-   Archives of the list can be found at:
-       <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 79]
-
-RFC 2246              The TLS Protocol Version 1.0          January 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Allen              Standards Track                    [Page 80]
-
diff --git a/doc/protocol/rfc2253.txt b/doc/protocol/rfc2253.txt
deleted file mode 100644
index a7439eed77..0000000000
--- a/doc/protocol/rfc2253.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Wahl
-Request for Comments: 2253                           Critical Angle Inc.
-Obsoletes: 1779                                                 S. Kille
-Category: Standards Track                                     Isode Ltd.
-                                                                T. Howes
-                                           Netscape Communications Corp.
-                                                           December 1997
-
-
-              Lightweight Directory Access Protocol (v3):
-           UTF-8 String Representation of Distinguished Names
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-IESG Note
-
-   This document describes a directory access protocol that provides
-   both read and update access.  Update access requires secure
-   authentication, but this document does not mandate implementation of
-   any satisfactory authentication mechanisms.
-
-   In accordance with RFC 2026, section 4.4.1, this specification is
-   being approved by IESG as a Proposed Standard despite this
-   limitation, for the following reasons:
-
-   a. to encourage implementation and interoperability testing of
-      these protocols (with or without update access) before they
-      are deployed, and
-
-   b. to encourage deployment and use of these protocols in read-only
-      applications.  (e.g. applications where LDAPv3 is used as
-      a query language for directories which are updated by some
-      secure mechanism other than LDAP), and
-
-   c. to avoid delaying the advancement and deployment of other Internet
-      standards-track protocols which require the ability to query, but
-      not update, LDAPv3 directory servers.
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 1]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-   Readers are hereby warned that until mandatory authentication
-   mechanisms are standardized, clients and servers written according to
-   this specification which make use of update functionality are
-   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
-   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
-   Implementors are hereby discouraged from deploying LDAPv3 clients or
-   servers which implement the update functionality, until a Proposed
-   Standard for mandatory authentication in LDAPv3 has been approved and
-   published as an RFC.
-
-Abstract
-
-   The X.500 Directory uses distinguished names as the primary keys to
-   entries in the directory.  Distinguished Names are encoded in ASN.1
-   in the X.500 Directory protocols.  In the Lightweight Directory
-   Access Protocol, a string representation of distinguished names is
-   transferred.  This specification defines the string format for
-   representing names, which is designed to give a clean representation
-   of commonly used distinguished names, while being able to represent
-   any distinguished name.
-
-   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 [6].
-
-1.  Background
-
-   This specification assumes familiarity with X.500 [1], and the
-   concept of Distinguished Name.  It is important to have a common
-   format to be able to unambiguously represent a distinguished name.
-   The primary goal of this specification is ease of encoding and
-   decoding.  A secondary goal is to have names that are human readable.
-   It is not expected that LDAP clients with a human user interface
-   would display these strings directly to the user, but would most
-   likely be performing translations (such as expressing attribute type
-   names in one of the local national languages).
-
-2.  Converting DistinguishedName from ASN.1 to a String
-
-   In X.501 [2] the ASN.1 structure of distinguished name is defined as:
-
-       DistinguishedName ::= RDNSequence
-
-       RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 2]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
-        AttributeTypeAndValue
-
-       AttributeTypeAndValue ::= SEQUENCE {
-        type  AttributeType,
-        value AttributeValue }
-
-   The following sections define the algorithm for converting from an
-   ASN.1 structured representation to a UTF-8 string representation.
-
-2.1. Converting the RDNSequence
-
-   If the RDNSequence is an empty sequence, the result is the empty or
-   zero length string.
-
-   Otherwise, the output consists of the string encodings of each
-   RelativeDistinguishedName in the RDNSequence (according to 2.2),
-   starting with the last element of the sequence and moving backwards
-   toward the first.
-
-   The encodings of adjoining RelativeDistinguishedNames are separated
-   by a comma character (',' ASCII 44).
-
-2.2.  Converting RelativeDistinguishedName
-
-   When converting from an ASN.1 RelativeDistinguishedName to a string,
-   the output consists of the string encodings of each
-   AttributeTypeAndValue (according to 2.3), in any order.
-
-   Where there is a multi-valued RDN, the outputs from adjoining
-   AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
-   character.
-
-2.3.  Converting AttributeTypeAndValue
-
-   The AttributeTypeAndValue is encoded as the string representation of
-   the AttributeType, followed by an equals character ('=' ASCII 61),
-   followed by the string representation of the AttributeValue.  The
-   encoding of the AttributeValue is given in section 2.4.
-
-   If the AttributeType is in a published table of attribute types
-   associated with LDAP [4], then the type name string from that table
-   is used, otherwise it is encoded as the dotted-decimal encoding of
-   the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
-   described in [3].  As an example, strings for a few of the attribute
-   types frequently seen in RDNs include:
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 3]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-                    String  X.500 AttributeType
-                    ------------------------------
-                    CN      commonName
-                    L       localityName
-                    ST      stateOrProvinceName
-                    O       organizationName
-                    OU      organizationalUnitName
-                    C       countryName
-                    STREET  streetAddress
-                    DC      domainComponent
-                    UID     userid
-
-2.4.  Converting an AttributeValue from ASN.1 to a String
-
-   If the AttributeValue is of a type which does not have a string
-   representation defined for it, then it is simply encoded as an
-   octothorpe character ('#' ASCII 35) followed by the hexadecimal
-   representation of each of the bytes of the BER encoding of the X.500
-   AttributeValue.  This form SHOULD be used if the AttributeType is of
-   the dotted-decimal form.
-
-   Otherwise, if the AttributeValue is of a type which has a string
-   representation, the value is converted first to a UTF-8 string
-   according to its syntax specification (see for example section 6 of
-   [4]).
-
-   If the UTF-8 string does not have any of the following characters
-   which need escaping, then that string can be used as the string
-   representation of the value.
-
-    o   a space or "#" character occurring at the beginning of the
-        string
-
-    o   a space character occurring at the end of the string
-
-    o   one of the characters ",", "+", """, "\", "<", ">" or ";"
-
-   Implementations MAY escape other characters.
-
-   If a character to be escaped is one of the list shown above, then it
-   is prefixed by a backslash ('\' ASCII 92).
-
-   Otherwise the character to be escaped is replaced by a backslash and
-   two hex digits, which form a single byte in the code of the
-   character.
-
-   Examples of the escaping mechanism are shown in section 5.
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 4]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-3. Parsing a String back to a Distinguished Name
-
-   The structure of the string is specified in a BNF grammar, based on
-   the grammar defined in RFC 822 [5].  Server implementations parsing a
-   DN string generated by an LDAPv2 client MUST also accept (and ignore)
-   the variants given in section 4 of this document.
-
-distinguishedName = [name]                    ; may be empty string
-
-name       = name-component *("," name-component)
-
-name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
-
-attributeTypeAndValue = attributeType "=" attributeValue
-
-attributeType = (ALPHA 1*keychar) / oid
-keychar    = ALPHA / DIGIT / "-"
-
-oid        = 1*DIGIT *("." 1*DIGIT)
-
-attributeValue = string
-
-string     = *( stringchar / pair )
-             / "#" hexstring
-             / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
-
-quotechar     = <any character except "\" or QUOTATION >
-
-special    = "," / "=" / "+" / "<" /  ">" / "#" / ";"
-
-pair       = "\" ( special / "\" / QUOTATION / hexpair )
-stringchar = <any character except one of special, "\" or QUOTATION >
-
-hexstring  = 1*hexpair
-hexpair    = hexchar hexchar
-
-hexchar    = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
-             / "a" / "b" / "c" / "d" / "e" / "f"
-
-ALPHA      =  <any ASCII alphabetic character>
-                                         ; (decimal 65-90 and 97-122)
-DIGIT      =  <any ASCII decimal digit>  ; (decimal 48-57)
-QUOTATION  =  <the ASCII double quotation mark character '"' decimal 34>
-
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 5]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-4.  Relationship with RFC 1779 and LDAPv2
-
-   The syntax given in this document is more restrictive than the syntax
-   in RFC 1779.  Implementations parsing a string generated by an LDAPv2
-   client MUST accept the syntax of RFC 1779.  Implementations MUST NOT,
-   however, generate any of the RFC 1779 encodings which are not
-   described above in section 2.
-
-   Implementations MUST allow a semicolon character to be used instead
-   of a comma to separate RDNs in a distinguished name, and MUST also
-   allow whitespace characters to be present on either side of the comma
-   or semicolon.  The whitespace characters are ignored, and the
-   semicolon replaced with a comma.
-
-   Implementations MUST allow an oid in the attribute type to be
-   prefixed by one of the character strings "oid." or "OID.".
-
-   Implementations MUST allow for space (' ' ASCII 32) characters to be
-   present between name-component and ',', between attributeTypeAndValue
-   and '+', between attributeType and '=', and between '=' and
-   attributeValue.  These space characters are ignored when parsing.
-
-   Implementations MUST allow a value to be surrounded by quote ('"'
-   ASCII 34) characters, which are not part of the value.  Inside the
-   quoted value, the following characters can occur without any
-   escaping:
-
-                   ",", "=", "+", "<", ">", "#" and ";"
-
-5.  Examples
-
-   This notation is designed to be convenient for common forms of name.
-   This section gives a few examples of distinguished names written
-   using this notation.  First is a name containing three relative
-   distinguished names (RDNs):
-
-   CN=Steve Kille,O=Isode Limited,C=GB
-
-   Here is an example name containing three RDNs, in which the first RDN
-   is multi-valued:
-
-   OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
-
-   This example shows the method of quoting of a comma in an
-   organization name:
-
-   CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 6]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-   An example name in which a value contains a carriage return
-   character:
-
-   CN=Before\0DAfter,O=Test,C=GB
-
-   An example name in which an RDN was of an unrecognized type.  The
-   value is the BER encoding of an OCTET STRING containing two bytes
-   0x48 and 0x69.
-
-   1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
-
-   Finally, an example of an RDN surname value consisting of 5 letters:
-
-   Unicode Letter Description      10646 code UTF-8  Quoted
-   =============================== ========== ====== =======
-   LATIN CAPITAL LETTER L          U0000004C  0x4C   L
-   LATIN SMALL LETTER U            U00000075  0x75   u
-   LATIN SMALL LETTER C WITH CARON U0000010D  0xC48D \C4\8D
-   LATIN SMALL LETTER I            U00000069  0x69   i
-   LATIN SMALL LETTER C WITH ACUTE U00000107  0xC487 \C4\87
-
-   Could be written in printable ASCII (useful for debugging purposes):
-
-   SN=Lu\C4\8Di\C4\87
-
-6.  References
-
-   [1] The Directory -- overview of concepts, models and services.
-       ITU-T Rec. X.500(1993).
-
-   [2] The Directory -- Models. ITU-T Rec. X.501(1993).
-
-   [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
-       Access  Protocol (v3)", RFC 2251, December 1997.
-
-   [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
-       Directory Access Protocol (v3): Attribute Syntax Definitions",
-       RFC 2252, December 1997.
-
-   [5] Crocker, D., "Standard of the Format of ARPA-Internet Text
-       Messages", STD 11, RFC 822, August 1982.
-
-   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Levels", RFC 2119.
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 7]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-7.  Security Considerations
-
-7.1. Disclosure
-
-   Distinguished Names typically consist of descriptive information
-   about the entries they name, which can be people, organizations,
-   devices or other real-world objects.  This frequently includes some
-   of the following kinds of information:
-
-   - the common name of the object (i.e. a person's full name)
-   - an email or TCP/IP address
-   - its physical location (country, locality, city, street address)
-   - organizational attributes (such as department name or affiliation)
-
-   Most countries have privacy laws regarding the publication of
-   information about people.
-
-7.2. Use of Distinguished Names in Security Applications
-
-   The transformations of an AttributeValue value from its X.501 form to
-   an LDAP string representation are not always reversible back to the
-   same BER or DER form.  An example of a situation which requires the
-   DER form of a distinguished name is the verification of an X.509
-   certificate.
-
-   For example, a distinguished name consisting of one RDN with one AVA,
-   in which the type is commonName and the value is of the TeletexString
-   choice with the letters 'Sam' would be represented in LDAP as the
-   string CN=Sam.  Another distinguished name in which the value is
-   still 'Sam' but of the PrintableString choice would have the same
-   representation CN=Sam.
-
-   Applications which require the reconstruction of the DER form of the
-   value SHOULD NOT use the string representation of attribute syntaxes
-   when converting a distinguished name to the LDAP format.  Instead,
-   they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
-   as described in the first paragraph of section 2.4.
-
-8.  Authors' Addresses
-
-   Mark Wahl
-   Critical Angle Inc.
-   4815 W. Braker Lane #502-385
-   Austin, TX 78759
-   USA
-
-   EMail:  M.Wahl@critical-angle.com
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 8]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-   Steve Kille
-   Isode Ltd.
-   The Dome
-   The Square
-   Richmond, Surrey
-   TW9 1DT
-   England
-
-   Phone:  +44-181-332-9091
-   EMail:  S.Kille@ISODE.COM
-
-
-   Tim Howes
-   Netscape Communications Corp.
-   501 E. Middlefield Rd, MS MV068
-   Mountain View, CA 94043
-   USA
-
-   Phone:  +1 650 937-3419
-   EMail:   howes@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                    [Page 9]
-
-RFC 2253               LADPv3 Distinguished Names          December 1997
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al.              Proposed Standard                   [Page 10]
-
diff --git a/doc/protocol/rfc2279.txt b/doc/protocol/rfc2279.txt
deleted file mode 100644
index 3a3495cbe4..0000000000
--- a/doc/protocol/rfc2279.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       F. Yergeau
-Request for Comments: 2279                           Alis Technologies
-Obsoletes: 2044                                           January 1998
-Category: Standards Track
-
-
-              UTF-8, a transformation format of ISO 10646
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   ISO/IEC 10646-1 defines a multi-octet character set called the
-   Universal Character Set (UCS) which encompasses most of the world's
-   writing systems. Multi-octet characters, however, are not compatible
-   with many current applications and protocols, and this has led to the
-   development of a few so-called UCS transformation formats (UTF), each
-   with different characteristics.  UTF-8, the object of this memo, has
-   the characteristic of preserving the full US-ASCII range, providing
-   compatibility with file systems, parsers and other software that rely
-   on US-ASCII values but are transparent to other values. This memo
-   updates and replaces RFC 2044, in particular addressing the question
-   of versions of the relevant standards.
-
-1.  Introduction
-
-   ISO/IEC 10646-1 [ISO-10646] defines a multi-octet character set
-   called the Universal Character Set (UCS), which encompasses most of
-   the world's writing systems.  Two multi-octet encodings are defined,
-   a four-octet per character encoding called UCS-4 and a two-octet per
-   character encoding called UCS-2, able to address only the first 64K
-   characters of the UCS (the Basic Multilingual Plane, BMP), outside of
-   which there are currently no assignments.
-
-   It is noteworthy that the same set of characters is defined by the
-   Unicode standard [UNICODE], which further defines additional
-   character properties and other application details of great interest
-   to implementors, but does not have the UCS-4 encoding.  Up to the
-
-
-
-Yergeau                     Standards Track                     [Page 1]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-   present time, changes in Unicode and amendments to ISO/IEC 10646 have
-   tracked each other, so that the character repertoires and code point
-   assignments have remained in sync.  The relevant standardization
-   committees have committed to maintain this very useful synchronism.
-
-   The UCS-2 and UCS-4 encodings, however, are hard to use in many
-   current applications and protocols that assume 8 or even 7 bit
-   characters.  Even newer systems able to deal with 16 bit characters
-   cannot process UCS-4 data. This situation has led to the development
-   of so-called UCS transformation formats (UTF), each with different
-   characteristics.
-
-   UTF-1 has only historical interest, having been removed from ISO/IEC
-   10646.  UTF-7 has the quality of encoding the full BMP repertoire
-   using only octets with the high-order bit clear (7 bit US-ASCII
-   values, [US-ASCII]), and is thus deemed a mail-safe encoding
-   ([RFC2152]).  UTF-8, the object of this memo, uses all bits of an
-   octet, but has the quality of preserving the full US-ASCII range:
-   US-ASCII characters are encoded in one octet having the normal US-
-   ASCII value, and any octet with such a value can only stand for an
-   US-ASCII character, and nothing else.
-
-   UTF-16 is a scheme for transforming a subset of the UCS-4 repertoire
-   into pairs of UCS-2 values from a reserved range.  UTF-16 impacts
-   UTF-8 in that UCS-2 values from the reserved range must be treated
-   specially in the UTF-8 transformation.
-
-   UTF-8 encodes UCS-2 or UCS-4 characters as a varying number of
-   octets, where the number of octets, and the value of each, depend on
-   the integer value assigned to the character in ISO/IEC 10646.  This
-   transformation format has the following characteristics (all values
-   are in hexadecimal):
-
-   -  Character values from 0000 0000 to 0000 007F (US-ASCII repertoire)
-      correspond to octets 00 to 7F (7 bit US-ASCII values). A direct
-      consequence is that a plain ASCII string is also a valid UTF-8
-      string.
-
-   -  US-ASCII values do not appear otherwise in a UTF-8 encoded
-      character stream.  This provides compatibility with file systems
-      or other software (e.g. the printf() function in C libraries) that
-      parse based on US-ASCII values but are transparent to other
-      values.
-
-   -  Round-trip conversion is easy between UTF-8 and either of UCS-4,
-      UCS-2.
-
-
-
-
-
-Yergeau                     Standards Track                     [Page 2]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-   -  The first octet of a multi-octet sequence indicates the number of
-      octets in the sequence.
-
-   -  The octet values FE and FF never appear.
-
-   -  Character boundaries are easily found from anywhere in an octet
-      stream.
-
-   -  The lexicographic sorting order of UCS-4 strings is preserved.  Of
-      course this is of limited interest since the sort order is not
-      culturally valid in either case.
-
-   -  The Boyer-Moore fast search algorithm can be used with UTF-8 data.
-
-   -  UTF-8 strings can be fairly reliably recognized as such by a
-      simple algorithm, i.e. the probability that a string of characters
-      in any other encoding appears as valid UTF-8 is low, diminishing
-      with increasing string length.
-
-   UTF-8 was originally a project of the X/Open Joint
-   Internationalization Group XOJIG with the objective to specify a File
-   System Safe UCS Transformation Format [FSS-UTF] that is compatible
-   with UNIX systems, supporting multilingual text in a single encoding.
-   The original authors were Gary Miller, Greger Leijonhufvud and John
-   Entenmann.  Later, Ken Thompson and Rob Pike did significant work for
-   the formal UTF-8.
-
-   A description can also be found in Unicode Technical Report #4 and in
-   the Unicode Standard, version 2.0 [UNICODE].  The definitive
-   reference, including provisions for UTF-16 data within UTF-8, is
-   Annex R of ISO/IEC 10646-1 [ISO-10646].
-
-2.  UTF-8 definition
-
-   In UTF-8, characters are encoded using sequences of 1 to 6 octets.
-   The only octet of a "sequence" of one has the higher-order bit set to
-   0, the remaining 7 bits being used to encode the character value. In
-   a sequence of n octets, n>1, the initial octet has the n higher-order
-   bits set to 1, followed by a bit set to 0.  The remaining bit(s) of
-   that octet contain bits from the value of the character to be
-   encoded.  The following octet(s) all have the higher-order bit set to
-   1 and the following bit set to 0, leaving 6 bits in each to contain
-   bits from the character to be encoded.
-
-   The table below summarizes the format of these different octet types.
-   The letter x indicates bits available for encoding bits of the UCS-4
-   character value.
-
-
-
-
-Yergeau                     Standards Track                     [Page 3]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-   UCS-4 range (hex.)           UTF-8 octet sequence (binary)
-   0000 0000-0000 007F   0xxxxxxx
-   0000 0080-0000 07FF   110xxxxx 10xxxxxx
-   0000 0800-0000 FFFF   1110xxxx 10xxxxxx 10xxxxxx
-
-   0001 0000-001F FFFF   11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
-   0020 0000-03FF FFFF   111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
-   0400 0000-7FFF FFFF   1111110x 10xxxxxx ... 10xxxxxx
-
-   Encoding from UCS-4 to UTF-8 proceeds as follows:
-
-   1) Determine the number of octets required from the character value
-      and the first column of the table above.  It is important to note
-      that the rows of the table are mutually exclusive, i.e. there is
-      only one valid way to encode a given UCS-4 character.
-
-   2) Prepare the high-order bits of the octets as per the second column
-      of the table.
-
-   3) Fill in the bits marked x from the bits of the character value,
-      starting from the lower-order bits of the character value and
-      putting them first in the last octet of the sequence, then the
-      next to last, etc. until all x bits are filled in.
-
-      The algorithm for encoding UCS-2 (or Unicode) to UTF-8 can be
-      obtained from the above, in principle, by simply extending each
-      UCS-2 character with two zero-valued octets.  However, pairs of
-      UCS-2 values between D800 and DFFF (surrogate pairs in Unicode
-      parlance), being actually UCS-4 characters transformed through
-      UTF-16, need special treatment: the UTF-16 transformation must be
-      undone, yielding a UCS-4 character that is then transformed as
-      above.
-
-      Decoding from UTF-8 to UCS-4 proceeds as follows:
-
-   1) Initialize the 4 octets of the UCS-4 character with all bits set
-      to 0.
-
-   2) Determine which bits encode the character value from the number of
-      octets in the sequence and the second column of the table above
-      (the bits marked x).
-
-   3) Distribute the bits from the sequence to the UCS-4 character,
-      first the lower-order bits from the last octet of the sequence and
-      proceeding to the left until no x bits are left.
-
-      If the UTF-8 sequence is no more than three octets long, decoding
-      can proceed directly to UCS-2.
-
-
-
-Yergeau                     Standards Track                     [Page 4]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-        NOTE -- actual implementations of the decoding algorithm above
-        should protect against decoding invalid sequences.  For
-        instance, a naive implementation may (wrongly) decode the
-        invalid UTF-8 sequence C0 80 into the character U+0000, which
-        may have security consequences and/or cause other problems.  See
-        the Security Considerations section below.
-
-   A more detailed algorithm and formulae can be found in [FSS_UTF],
-   [UNICODE] or Annex R to [ISO-10646].
-
-3.  Versions of the standards
-
-   ISO/IEC 10646 is updated from time to time by published amendments;
-   similarly, different versions of the Unicode standard exist: 1.0, 1.1
-   and 2.0 as of this writing.  Each new version obsoletes and replaces
-   the previous one, but implementations, and more significantly data,
-   are not updated instantly.
-
-   In general, the changes amount to adding new characters, which does
-   not pose particular problems with old data.  Amendment 5 to ISO/IEC
-   10646, however, has moved and expanded the Korean Hangul block,
-   thereby making any previous data containing Hangul characters invalid
-   under the new version.  Unicode 2.0 has the same difference from
-   Unicode 1.1. The official justification for allowing such an
-   incompatible change was that no implementations and no data
-   containing Hangul existed, a statement that is likely to be true but
-   remains unprovable.  The incident has been dubbed the "Korean mess",
-   and the relevant committees have pledged to never, ever again make
-   such an incompatible change.
-
-   New versions, and in particular any incompatible changes, have q
-   conseuences regarding MIME character encoding labels, to be discussed
-   in section 5.
-
-4.  Examples
-
-   The UCS-2 sequence "A<NOT IDENTICAL TO><ALPHA>." (0041, 2262, 0391,
-   002E) may be encoded in UTF-8 as follows:
-
-   41 E2 89 A2 CE 91 2E
-
-   The UCS-2 sequence representing the Hangul characters for the Korean
-   word "hangugo" (D55C, AD6D, C5B4) may be encoded as follows:
-
-   ED 95 9C EA B5 AD EC 96 B4
-
-
-
-
-
-
-Yergeau                     Standards Track                     [Page 5]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-   The UCS-2 sequence representing the Han characters for the Japanese
-   word "nihongo" (65E5, 672C, 8A9E) may be encoded as follows:
-
-   E6 97 A5 E6 9C AC E8 AA 9E
-
-5.  MIME registration
-
-   This memo is meant to serve as the basis for registration of a MIME
-   character set parameter (charset) [CHARSET-REG].  The proposed
-   charset parameter value is "UTF-8".  This string labels media types
-   containing text consisting of characters from the repertoire of
-   ISO/IEC 10646 including all amendments at least up to amendment 5
-   (Korean block), encoded to a sequence of octets using the encoding
-   scheme outlined above.  UTF-8 is suitable for use in MIME content
-   types under the "text" top-level type.
-
-   It is noteworthy that the label "UTF-8" does not contain a version
-   identification, referring generically to ISO/IEC 10646.  This is
-   intentional, the rationale being as follows:
-
-   A MIME charset label is designed to give just the information needed
-   to interpret a sequence of bytes received on the wire into a sequence
-   of characters, nothing more (see RFC 2045, section 2.2, in [MIME]).
-   As long as a character set standard does not change incompatibly,
-   version numbers serve no purpose, because one gains nothing by
-   learning from the tag that newly assigned characters may be received
-   that one doesn't know about.  The tag itself doesn't teach anything
-   about the new characters, which are going to be received anyway.
-
-   Hence, as long as the standards evolve compatibly, the apparent
-   advantage of having labels that identify the versions is only that,
-   apparent.  But there is a disadvantage to such version-dependent
-   labels: when an older application receives data accompanied by a
-   newer, unknown label, it may fail to recognize the label and be
-   completely unable to deal with the data, whereas a generic, known
-   label would have triggered mostly correct processing of the data,
-   which may well not contain any new characters.
-
-   Now the "Korean mess" (ISO/IEC 10646 amendment 5) is an incompatible
-   change, in principle contradicting the appropriateness of a version
-   independent MIME charset label as described above.  But the
-   compatibility problem can only appear with data containing Korean
-   Hangul characters encoded according to Unicode 1.1 (or equivalently
-   ISO/IEC 10646 before amendment 5), and there is arguably no such data
-   to worry about, this being the very reason the incompatible change
-   was deemed acceptable.
-
-
-
-
-
-Yergeau                     Standards Track                     [Page 6]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-   In practice, then, a version-independent label is warranted, provided
-   the label is understood to refer to all versions after Amendment 5,
-   and provided no incompatible change actually occurs.  Should
-   incompatible changes occur in a later version of ISO/IEC 10646, the
-   MIME charset label defined here will stay aligned with the previous
-   version until and unless the IETF specifically decides otherwise.
-
-   It is also proposed to register the charset parameter value
-   "UNICODE-1-1-UTF-8", for the exclusive purpose of labelling text data
-   containing Hangul syllables encoded to UTF-8 without taking into
-   account Amendment 5 of ISO/IEC 10646 (i.e. using the pre-amendment 5
-   code point assignments).  Any other UTF-8 data SHOULD NOT use this
-   label, in particular data not containing any Hangul syllables, and it
-   is felt important to strongly recommend against creating any new
-   Hangul-containing data without taking Amendment 5 of ISO/IEC 10646
-   into account.
-
-6.  Security Considerations
-
-   Implementors of UTF-8 need to consider the security aspects of how
-   they handle illegal UTF-8 sequences.  It is conceivable that in some
-   circumstances an attacker would be able to exploit an incautious
-   UTF-8 parser by sending it an octet sequence that is not permitted by
-   the UTF-8 syntax.
-
-   A particularly subtle form of this attack could be carried out
-   against a parser which performs security-critical validity checks
-   against the UTF-8 encoded form of its input, but interprets certain
-   illegal octet sequences as characters.  For example, a parser might
-   prohibit the NUL character when encoded as the single-octet sequence
-   00, but allow the illegal two-octet sequence C0 80 and interpret it
-   as a NUL character.  Another example might be a parser which
-   prohibits the octet sequence 2F 2E 2E 2F ("/../"), yet permits the
-   illegal octet sequence 2F C0 AE 2E 2F.
-
-Acknowledgments
-
-   The following have participated in the drafting and discussion of
-   this memo:
-
-   James E. Agenbroad    Andries Brouwer
-   Martin J. D|rst       Ned Freed
-   David Goldsmith       Edwin F. Hart
-   Kent Karlsson         Markus Kuhn
-   Michael Kung          Alain LaBonte
-   John Gardiner Myers   Murray Sargent
-   Keld Simonsen         Arnold Winkler
-
-
-
-
-Yergeau                     Standards Track                     [Page 7]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-Bibliography
-
-   [CHARSET-REG]  Freed, N., and J. Postel, "IANA Charset Registration
-                  Procedures", BCP 19, RFC 2278, January 1998.
-
-   [FSS_UTF]      X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm.
-                  22p. pbk. 172g.  4/95, X/Open Company Ltd., "File
-                  System Safe UCS Transformation Format (FSS_UTF)",
-                  X/Open Preleminary Specification, Document Number
-                  P316.  Also published in Unicode Technical Report #4.
-
-   [ISO-10646]    ISO/IEC 10646-1:1993. International Standard --
-                  Information technology -- Universal Multiple-Octet
-                  Coded Character Set (UCS) -- Part 1: Architecture and
-                  Basic Multilingual Plane.  Five amendments and a
-                  technical corrigendum have been published up to now.
-                  UTF-8 is described in Annex R, published as Amendment
-                  2.  UTF-16 is described in Annex Q, published as
-                  Amendment 1. 17 other amendments are currently at
-                  various stages of standardization.
-
-   [MIME]         Freed, N., and N. Borenstein, "Multipurpose Internet
-                  Mail Extensions (MIME) Part One:  Format of Internet
-                  Message Bodies", RFC 2045.  N. Freed, N. Borenstein,
-                  "Multipurpose Internet Mail Extensions (MIME) Part
-                  Two:  Media Types", RFC 2046.  K. Moore, "MIME
-                  (Multipurpose Internet Mail Extensions) Part Three:
-                  Message Header Extensions for Non-ASCII Text", RFC
-                  2047.  N.  Freed, J. Klensin, J. Postel, "Multipurpose
-                  Internet Mail Extensions (MIME) Part Four:
-                  Registration Procedures", RFC 2048.  N. Freed, N.
-                  Borenstein, " Multipurpose Internet Mail Extensions
-                  (MIME) Part Five: Conformance Criteria and Examples",
-                  RFC 2049.  All November 1996.
-
-   [RFC2152]      Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe
-                  Transformation Format of Unicode", RFC 1642, Taligent
-                  inc., May 1997. (Obsoletes RFC1642)
-
-   [UNICODE]      The Unicode Consortium, "The Unicode Standard --
-                  Version 2.0", Addison-Wesley, 1996.
-
-   [US-ASCII]     Coded Character Set--7-bit American Standard Code for
-                  Information Interchange, ANSI X3.4-1986.
-
-
-
-
-
-
-
-Yergeau                     Standards Track                     [Page 8]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-Author's Address
-
-   Francois Yergeau
-   Alis Technologies
-   100, boul. Alexis-Nihon
-   Suite 600
-   Montreal  QC  H4M 2P2
-   Canada
-
-   Phone: +1 (514) 747-2547
-   Fax:   +1 (514) 747-2561
-   EMail: fyergeau@alis.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yergeau                     Standards Track                     [Page 9]
-
-RFC 2279                         UTF-8                      January 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Yergeau                     Standards Track                    [Page 10]
-
diff --git a/doc/protocol/rfc2313.txt b/doc/protocol/rfc2313.txt
deleted file mode 100644
index f9471eba6b..0000000000
--- a/doc/protocol/rfc2313.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Kaliski
-Request for Comments: 2313                      RSA Laboratories East
-Category: Informational                                    March 1998
-
-
-                        PKCS #1: RSA Encryption
-                              Version 1.5
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Overview
-
-   This document describes a method for encrypting data using the RSA
-   public-key cryptosystem.
-
-1. Scope
-
-   This document describes a method for encrypting data using the RSA
-   public-key cryptosystem. Its intended use is in the construction of
-   digital signatures and digital envelopes, as described in PKCS #7:
-
-        o    For digital signatures, the content to be signed
-             is first reduced to a message digest with a
-             message-digest algorithm (such as MD5), and then
-             an octet string containing the message digest is
-             encrypted with the RSA private key of the signer
-             of the content. The content and the encrypted
-             message digest are represented together according
-             to the syntax in PKCS #7 to yield a digital
-             signature. This application is compatible with
-             Privacy-Enhanced Mail (PEM) methods.
-
-        o    For digital envelopes, the content to be enveloped
-             is first encrypted under a content-encryption key
-             with a content-encryption algorithm (such as DES),
-             and then the content-encryption key is encrypted
-             with the RSA public keys of the recipients of the
-             content. The encrypted content and the encrypted
-
-
-
-
-
-Kaliski                      Informational                      [Page 1]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-             content-encryption key are represented together
-             according to the syntax in PKCS #7 to yield a
-             digital envelope. This application is also
-             compatible with PEM methods.
-
-   The document also describes a syntax for RSA public keys and private
-   keys. The public-key syntax would be used in certificates; the
-   private-key syntax would be used typically in PKCS #8 private-key
-   information. The public-key syntax is identical to that in both X.509
-   and Privacy-Enhanced Mail.  Thus X.509/PEM RSA keys can be used in
-   this document.
-
-   The document also defines three signature algorithms for use in
-   signing X.509/PEM certificates and certificate-revocation lists, PKCS
-   #6 extended certificates, and other objects employing digital
-   signatures such as X.401 message tokens.
-
-   Details on message-digest and content-encryption algorithms are
-   outside the scope of this document, as are details on sources of the
-   pseudorandom bits required by certain methods in this document.
-
-2. References
-
-   FIPS PUB 46-1  National Bureau of Standards. FIPS PUB 46-1:
-             Data Encryption Standard. January 1988.
-
-   PKCS #6   RSA Laboratories. PKCS #6: Extended-Certificate
-             Syntax. Version 1.5, November 1993.
-
-   PKCS #7   RSA Laboratories. PKCS #7: Cryptographic Message
-             Syntax. Version 1.5, November 1993.
-
-   PKCS #8   RSA Laboratories. PKCS #8: Private-Key Information
-             Syntax. Version 1.2, November 1993.
-
-   RFC 1319  Kaliski, B., "The MD2 Message-Digest
-             Algorithm," RFC 1319, April 1992.
-
-   RFC 1320  Rivest, R., "The MD4 Message-Digest
-             Algorithm," RFC 1320, April 1992.
-
-   RFC 1321  Rivest, R., "The MD5 Message-Digest
-             Algorithm," RFC 1321, April 1992.
-
-   RFC 1423  Balenson, D., "Privacy Enhancement for
-             Internet Electronic Mail: Part III: Algorithms,
-             Modes, and Identifiers," RFC 1423, February 1993.
-
-
-
-
-Kaliski                      Informational                      [Page 2]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   X.208     CCITT. Recommendation X.208: Specification of
-             Abstract Syntax Notation One (ASN.1). 1988.
-
-   X.209     CCITT. Recommendation X.209: Specification of
-             Basic Encoding Rules for Abstract Syntax Notation
-             One (ASN.1). 1988.
-
-   X.411     CCITT. Recommendation X.411: Message Handling
-             Systems: Message Transfer System: Abstract Service
-             Definition and Procedures.1988.
-
-   X.509     CCITT. Recommendation X.509: The Directory--
-             Authentication Framework. 1988.
-
-   [dBB92]   B. den Boer and A. Bosselaers. An attack on the
-             last two rounds of MD4. In J. Feigenbaum, editor,
-             Advances in Cryptology---CRYPTO '91 Proceedings,
-             volume 576 of Lecture Notes in Computer Science,
-             pages 194-203. Springer-Verlag, New York, 1992.
-
-   [dBB93]   B. den Boer  and A. Bosselaers. Collisions for the
-             compression function of MD5. Presented at
-             EUROCRYPT '93 (Lofthus, Norway, May 24-27, 1993).
-
-   [DO86]    Y. Desmedt and A.M. Odlyzko. A chosen text attack
-             on the RSA cryptosystem and some discrete
-             logarithm schemes. In H.C. Williams, editor,
-             Advances in Cryptology---CRYPTO '85 Proceedings,
-             volume 218 of Lecture Notes in Computer Science,
-             pages 516-521. Springer-Verlag, New York, 1986.
-
-   [Has88]   Johan Hastad. Solving simultaneous modular
-             equations. SIAM Journal on Computing,
-             17(2):336-341, April 1988.
-
-   [IM90]    Colin I'Anson and Chris Mitchell. Security defects
-             in CCITT Recommendation X.509--The directory
-             authentication framework. Computer Communications
-             Review, :30-34, April 1990.
-
-   [Mer90]   R.C. Merkle. Note on MD4. Unpublished manuscript,
-             1990.
-
-   [Mil76]   G.L. Miller. Riemann's hypothesis and tests for
-             primality. Journal of Computer and Systems
-             Sciences, 13(3):300-307, 1976.
-
-
-
-
-
-Kaliski                      Informational                      [Page 3]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   [QC82]    J.-J. Quisquater and C. Couvreur. Fast
-             decipherment algorithm for RSA public-key
-             cryptosystem. Electronics Letters, 18(21):905-907,
-             October 1982.
-
-   [RSA78]   R.L. Rivest, A. Shamir, and L. Adleman. A method
-             for obtaining digital signatures and public-key
-             cryptosystems. Communications of the ACM,
-             21(2):120-126, February 1978.
-
-3. Definitions
-
-   For the purposes of this document, the following definitions apply.
-
-   AlgorithmIdentifier: A type that identifies an algorithm (by object
-   identifier) and associated parameters. This type is defined in X.509.
-
-   ASN.1: Abstract Syntax Notation One, as defined in X.208.
-
-   BER: Basic Encoding Rules, as defined in X.209.
-
-   DES: Data Encryption Standard, as defined in FIPS PUB 46-1.
-
-   MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as
-   defined in RFC 1319.
-
-   MD4: RSA Data Security, Inc.'s MD4 message-digest algorithm, as
-   defined in RFC 1320.
-
-   MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as
-   defined in RFC 1321.
-
-   modulus: Integer constructed as the product of two primes.
-
-   PEM: Internet Privacy-Enhanced Mail, as defined in RFC 1423 and
-   related documents.
-
-   RSA: The RSA public-key cryptosystem, as defined in [RSA78].
-
-   private key: Modulus and private exponent.
-
-   public key: Modulus and public exponent.
-
-4. Symbols and abbreviations
-
-   Upper-case symbols (e.g., BT) denote octet strings and bit strings
-   (in the case of the signature S); lower-case symbols (e.g., c) denote
-   integers.
-
-
-
-Kaliski                      Informational                      [Page 4]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   ab   hexadecimal octet value  c    exponent
-   BT   block type               d    private exponent
-   D    data                     e    public exponent
-   EB   encryption block         k    length of modulus in
-                                        octets
-   ED   encrypted data           n    modulus
-   M    message                  p, q  prime factors of modulus
-   MD   message digest           x    integer encryption block
-   MD'  comparative message      y    integer encrypted data
-          digest
-   PS   padding string           mod n  modulo n
-   S    signature                X || Y  concatenation of X, Y
-                                 ||X||  length in octets of X
-5. General overview
-
-   The next six sections specify key generation, key syntax, the
-   encryption process, the decryption process, signature algorithms, and
-   object identifiers.
-
-   Each entity shall generate a pair of keys: a public key and a private
-   key. The encryption process shall be performed with one of the keys
-   and the decryption process shall be performed with the other key.
-   Thus the encryption process can be either a public-key operation or a
-   private-key operation, and so can the decryption process. Both
-   processes transform an octet string to another octet string. The
-   processes are inverses of each other if one process uses an entity's
-   public key and the other process uses the same entity's private key.
-
-   The encryption and decryption processes can implement either the
-   classic RSA transformations, or variations with padding.
-
-6. Key generation
-
-   This section describes RSA key generation.
-
-   Each entity shall select a positive integer e as its public exponent.
-
-   Each entity shall privately and randomly select two distinct odd
-   primes p and q such that (p-1) and e have no common divisors, and
-   (q-1) and e have no common divisors.
-
-   The public modulus n shall be the product of the private prime
-   factors p and q:
-
-                                 n = pq .
-
-   The private exponent shall be a positive integer d such that de-1 is
-   divisible by both p-1 and q-1.
-
-
-
-Kaliski                      Informational                      [Page 5]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   The length of the modulus n in octets is the integer k satisfying
-
-                        2^(8(k-1)) <= n < 2^(8k) .
-
-   The length k of the modulus must be at least 12 octets to accommodate
-   the block formats in this document (see Section 8).
-
-   Notes.
-
-        1.   The public exponent may be standardized in
-             specific applications. The values 3 and F4 (65537) may have
-             some practical advantages, as noted in X.509 Annex C.
-
-        2.   Some additional conditions on the choice of primes
-             may well be taken into account in order to deter
-             factorization of the modulus. These security conditions
-             fall outside the scope of this document. The lower bound on
-             the length k is to accommodate the block formats, not for
-             security.
-
-7. Key syntax
-
-   This section gives the syntax for RSA public and private keys.
-
-7.1 Public-key syntax
-
-   An RSA public key shall have ASN.1 type RSAPublicKey:
-
-   RSAPublicKey ::= SEQUENCE {
-     modulus INTEGER, -- n
-     publicExponent INTEGER -- e }
-
-   (This type is specified in X.509 and is retained here for
-   compatibility.)
-
-   The fields of type RSAPublicKey have the following meanings:
-
-        o    modulus is the modulus n.
-
-        o    publicExponent is the public exponent e.
-
-
-
-
-
-
-
-
-
-
-
-Kaliski                      Informational                      [Page 6]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-7.2 Private-key syntax
-
-   An RSA private key shall have ASN.1 type RSAPrivateKey:
-
-   RSAPrivateKey ::= SEQUENCE {
-     version Version,
-     modulus INTEGER, -- n
-     publicExponent INTEGER, -- e
-     privateExponent INTEGER, -- d
-     prime1 INTEGER, -- p
-     prime2 INTEGER, -- q
-     exponent1 INTEGER, -- d mod (p-1)
-     exponent2 INTEGER, -- d mod (q-1)
-     coefficient INTEGER -- (inverse of q) mod p }
-
-   Version ::= INTEGER
-
-   The fields of type RSAPrivateKey have the following meanings:
-
-        o    version is the version number, for compatibility
-             with future revisions of this document. It shall
-             be 0 for this version of the document.
-
-        o    modulus is the modulus n.
-
-        o    publicExponent is the public exponent e.
-
-        o    privateExponent is the private exponent d.
-
-        o    prime1 is the prime factor p of n.
-
-        o    prime2 is the prime factor q of n.
-
-        o    exponent1 is d mod (p-1).
-
-        o    exponent2 is d mod (q-1).
-
-        o    coefficient is the Chinese Remainder Theorem
-             coefficient q-1 mod p.
-
-   Notes.
-
-        1.   An RSA private key logically consists of only the
-             modulus n and the private exponent d. The presence of the
-             values p, q, d mod (p-1), d mod (p-1), and q-1 mod p is
-             intended for efficiency, as Quisquater and Couvreur have
-             shown [QC82]. A private-key syntax that does not include
-
-
-
-
-Kaliski                      Informational                      [Page 7]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-             all the extra values can be converted readily to the syntax
-             defined here, provided the public key is known, according
-             to a result by Miller [Mil76].
-
-        2.   The presence of the public exponent e is intended
-             to make it straightforward to derive a public key from the
-             private key.
-
-8. Encryption process
-
-   This section describes the RSA encryption process.
-
-   The encryption process consists of four steps: encryption- block
-   formatting, octet-string-to-integer conversion, RSA computation, and
-   integer-to-octet-string conversion. The input to the encryption
-   process shall be an octet string D, the data; an integer n, the
-   modulus; and an integer c, the exponent. For a public-key operation,
-   the integer c shall be an entity's public exponent e; for a private-
-   key operation, it shall be an entity's private exponent d. The output
-   from the encryption process shall be an octet string ED, the
-   encrypted data.
-
-   The length of the data D shall not be more than k-11 octets, which is
-   positive since the length k of the modulus is at least 12 octets.
-   This limitation guarantees that the length of the padding string PS
-   is at least eight octets, which is a security condition.
-
-   Notes.
-
-        1.   In typical applications of this document to
-             encrypt content-encryption keys and message digests, one
-             would have ||D|| <= 30. Thus the length of the RSA modulus
-             will need to be at least 328 bits (41 octets), which is
-             reasonable and consistent with security recommendations.
-
-        2.   The encryption process does not provide an
-             explicit integrity check to facilitate error detection
-             should the encrypted data be corrupted in transmission.
-             However, the structure of the encryption block guarantees
-             that the probability that corruption is undetected is less
-             than 2-16, which is an upper bound on the probability that
-             a random encryption block looks like block type 02.
-
-        3.   Application of private-key operations as defined
-             here to data other than an octet string containing a
-             message digest is not recommended and is subject to further
-             study.
-
-
-
-
-Kaliski                      Informational                      [Page 8]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-        4.   This document may be extended to handle data of
-             length more than k-11 octets.
-
-8.1 Encryption-block formatting
-
-   A block type BT, a padding string PS, and the data D shall be
-   formatted into an octet string EB, the encryption block.
-
-              EB = 00 || BT || PS || 00 || D .           (1)
-
-   The block type BT shall be a single octet indicating the structure of
-   the encryption block. For this version of the document it shall have
-   value 00, 01, or 02. For a private- key operation, the block type
-   shall be 00 or 01. For a public-key operation, it shall be 02.
-
-   The padding string PS shall consist of k-3-||D|| octets. For block
-   type 00, the octets shall have value 00; for block type 01, they
-   shall have value FF; and for block type 02, they shall be
-   pseudorandomly generated and nonzero. This makes the length of the
-   encryption block EB equal to k.
-
-   Notes.
-
-        1.   The leading 00 octet ensures that the encryption
-             block, converted to an integer, is less than the modulus.
-
-        2.   For block type 00, the data D must begin with a
-             nonzero octet or have known length so that the encryption
-             block can be parsed unambiguously. For block types 01 and
-             02, the encryption block can be parsed unambiguously since
-             the padding string PS contains no octets with value 00 and
-             the padding string is separated from the data D by an octet
-             with value 00.
-
-        3.   Block type 01 is recommended for private-key
-             operations. Block type 01 has the property that the
-             encryption block, converted to an integer, is guaranteed to
-             be large, which prevents certain attacks of the kind
-             proposed by Desmedt and Odlyzko [DO86].
-
-        4.   Block types 01 and 02 are compatible with PEM RSA
-             encryption of content-encryption keys and message digests
-             as described in RFC 1423.
-
-
-
-
-
-
-
-
-Kaliski                      Informational                      [Page 9]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-        5.   For block type 02, it is recommended that the
-             pseudorandom octets be generated independently for each
-             encryption process, especially if the same data is input to
-             more than one encryption process.  Hastad's results [Has88]
-             motivate this recommendation.
-
-        6.   For block type 02, the padding string is at least
-             eight octets long, which is a security condition for
-             public-key operations that prevents an attacker from
-             recoving data by trying all possible encryption blocks. For
-             simplicity, the minimum length is the same for block type
-             01.
-
-        7.   This document may be extended in the future to
-             include other block types.
-
-8.2 Octet-string-to-integer conversion
-
-   The encryption block EB shall be converted to an integer x, the
-   integer encryption block. Let EB1, ..., EBk be the octets of EB from
-   first to last. Then the integer x shall satisfy
-
-                                     k
-                x =  SUM  2^(8(k-i)) EBi .              (2)
-                                   i = 1
-
-   In other words, the first octet of EB has the most significance in
-   the integer and the last octet of EB has the least significance.
-
-   Note. The integer encryption block x satisfies 0 <= x <  n since EB1
-   = 00 and 2^(8(k-1)) <= n.
-
-8.3 RSA computation
-
-   The integer encryption block x shall be raised to the power c modulo
-   n to give an integer y, the integer encrypted data.
-
-                       y = x^c mod n,  0 <= y < n .
-
-   This is the classic RSA computation.
-
-8.4 Integer-to-octet-string conversion
-
-   The integer encrypted data y shall be converted to an octet string ED
-   of length k, the encrypted data. The encrypted data ED shall satisfy
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 10]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-                                     k
-                y =  SUM  2^(8(k-i)) EDi .              (3)
-                                   i = 1
-
-   where ED1, ..., EDk are the octets of ED from first to last.
-
-   In other words, the first octet of ED has the most significance in
-   the integer and the last octet of ED has the least significance.
-
-9. Decryption process
-
-   This section describes the RSA decryption process.
-
-   The decryption process consists of four steps: octet-string-to-
-   integer conversion, RSA computation, integer-to-octet-string
-   conversion, and encryption-block parsing. The input to the decryption
-   process shall be an octet string ED, the encrypted data; an integer
-   n, the modulus; and an integer c, the exponent. For a public-key
-   operation, the integer c shall be an entity's public exponent e; for
-   a private-key operation, it shall be an entity's private exponent d.
-   The output from the decryption process shall be an octet string D,
-   the data.
-
-   It is an error if the length of the encrypted data ED is not k.
-
-   For brevity, the decryption process is described in terms of the
-   encryption process.
-
-9.1 Octet-string-to-integer conversion
-
-   The encrypted data ED shall be converted to an integer y, the integer
-   encrypted data, according to Equation (3).
-
-   It is an error if the integer encrypted data y does not satisfy 0 <=
-   y < n.
-
-9.2 RSA computation
-
-   The integer encrypted data y shall be raised to the power c modulo n
-   to give an integer x, the integer encryption block.
-
-                       x = y^c mod n,  0 <= x < n .
-
-   This is the classic RSA computation.
-
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 11]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-9.3 Integer-to-octet-string conversion
-
-   The integer encryption block x shall be converted to an octet string
-   EB of length k, the encryption block, according to Equation (2).
-
-9.4 Encryption-block parsing
-
-   The encryption block EB shall be parsed into a block type BT, a
-   padding string PS, and the data D according to Equation (1).
-
-   It is an error if any of the following conditions occurs:
-
-        o    The encryption block EB cannot be parsed
-             unambiguously (see notes to Section 8.1).
-
-        o    The padding string PS consists of fewer than eight
-             octets, or is inconsistent with the block type BT.
-
-        o    The decryption process is a public-key operation
-             and the block type BT is not 00 or 01, or the decryption
-             process is a private-key operation and the block type is
-             not 02.
-
-10. Signature algorithms
-
-   This section defines three signature algorithms based on the RSA
-   encryption process described in Sections 8 and 9. The intended use of
-   the signature algorithms is in signing X.509/PEM certificates and
-   certificate-revocation lists, PKCS #6 extended certificates, and
-   other objects employing digital signatures such as X.401 message
-   tokens. The algorithms are not intended for use in constructing
-   digital signatures in PKCS #7. The first signature algorithm
-   (informally, "MD2 with RSA") combines the MD2 message-digest
-   algorithm with RSA, the second (informally, "MD4 with RSA") combines
-   the MD4 message-digest algorithm with RSA, and the third (informally,
-   "MD5 with RSA") combines the MD5 message-digest algorithm with RSA.
-
-   This section describes the signature process and the verification
-   process for the two algorithms. The "selected" message-digest
-   algorithm shall be either MD2 or MD5, depending on the signature
-   algorithm. The signature process shall be performed with an entity's
-   private key and the verification process shall be performed with an
-   entity's public key. The signature process transforms an octet string
-   (the message) to a bit string (the signature); the verification
-   process determines whether a bit string (the signature) is the
-   signature of an octet string (the message).
-
-
-
-
-
-Kaliski                      Informational                     [Page 12]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   Note. The only difference between the signature algorithms defined
-   here and one of the the methods by which signatures (encrypted
-   message digests) are constructed in PKCS #7 is that signatures here
-   are represented here as bit strings, for consistency with the X.509
-   SIGNED macro. In PKCS #7 encrypted message digests are octet strings.
-
-10.1 Signature process
-
-   The signature process consists of four steps: message digesting, data
-   encoding, RSA encryption, and octet-string-to-bit-string conversion.
-   The input to the signature process shall be an octet string M, the
-   message; and a signer's private key. The output from the signature
-   process shall be a bit string S, the signature.
-
-10.1.1 Message digesting
-
-   The message M shall be digested with the selected message- digest
-   algorithm to give an octet string MD, the message digest.
-
-10.1.2 Data encoding
-
-   The message digest MD and a message-digest algorithm identifier shall
-   be combined into an ASN.1 value of type DigestInfo, described below,
-   which shall be BER-encoded to give an octet string D, the data.
-
-   DigestInfo ::= SEQUENCE {
-     digestAlgorithm DigestAlgorithmIdentifier,
-     digest Digest }
-
-   DigestAlgorithmIdentifier ::= AlgorithmIdentifier
-
-   Digest ::= OCTET STRING
-
-   The fields of type DigestInfo have the following meanings:
-
-        o    digestAlgorithm identifies the message-digest
-             algorithm (and any associated parameters). For
-             this application, it should identify the selected
-             message-digest algorithm, MD2, MD4 or MD5. For
-             reference, the relevant object identifiers are the
-             following:
-
-
-
-
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 13]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   md2 OBJECT IDENTIFIER ::=
-
-     { iso(1) member-body(2) US(840) rsadsi(113549)
-         digestAlgorithm(2) 2 } md4 OBJECT IDENTIFIER ::=
-     { iso(1) member-body(2) US(840) rsadsi(113549)
-         digestAlgorithm(2) 4 } md5 OBJECT IDENTIFIER ::=
-     { iso(1) member-body(2) US(840) rsadsi(113549)
-         digestAlgorithm(2) 5 }
-
-             For these object identifiers, the parameters field of the
-             digestAlgorithm value should be NULL.
-
-        o    digest is the result of the message-digesting
-             process, i.e., the message digest MD.
-
-   Notes.
-
-        1.   A message-digest algorithm identifier is included
-             in the DigestInfo value to limit the damage resulting from
-             the compromise of one message-digest algorithm. For
-             instance, suppose an adversary were able to find messages
-             with a given MD2 message digest.  That adversary might try
-             to forge a signature on a message by finding an innocuous-
-             looking message with the same MD2 message digest, and
-             coercing a signer to sign the innocuous-looking message.
-             This attack would succeed only if the signer used MD2. If
-             the DigestInfo value contained only the message digest,
-             however, an adversary could attack signers that use any
-             message digest.
-
-        2.   Although it may be claimed that the use of a
-             SEQUENCE type violates the literal statement in the X.509
-             SIGNED and SIGNATURE macros that a signature is an
-             ENCRYPTED OCTET STRING (as opposed to ENCRYPTED SEQUENCE),
-             such a literal interpretation need not be required, as
-             I'Anson and Mitchell point out [IM90].
-
-        3.  No reason is known that MD4 would not be
-             for very high security digital signature schemes, but
-             because MD4 was designed to be exceptionally fast, it is
-             "at the edge" in terms of risking successful cryptanalytic
-             attack.  A message-digest algorithm can be considered
-             "broken" if someone can find a collision: two messages with
-             the same digest. While collisions have been found in
-             variants of MD4 with only two digesting "rounds"
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 14]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-             [Mer90][dBB92], none have been found in MD4 itself, which
-             has three rounds. After further critical review, it may be
-             appropriate to consider MD4 for very high security
-             applications.
-
-             MD5, which has four rounds and is proportionally slower
-             than MD4, is recommended until the completion of MD4's
-             review. The reported "pseudocollisions" in MD5's internal
-             compression function [dBB93] do not appear to have any
-             practical impact on  MD5's security.
-
-             MD2, the slowest of the three, has the most conservative
-             design. No attacks on MD2 have been published.
-
-10.1.3 RSA encryption
-
-   The data D shall be encrypted with the signer's RSA private key as
-   described in Section 7 to give an octet string ED, the encrypted
-   data. The block type shall be 01. (See Section 8.1.)
-
-10.1.4 Octet-string-to-bit-string conversion
-
-   The encrypted data ED shall be converted into a bit string S, the
-   signature. Specifically, the most significant bit of the first octet
-   of the encrypted data shall become the first bit of the signature,
-   and so on through the least significant bit of the last octet of the
-   encrypted data, which shall become the last bit of the signature.
-
-   Note. The length in bits of the signature S is a multiple of eight.
-
-10.2 Verification process
-
-   The verification process for both signature algorithms consists of
-   four steps: bit-string-to-octet-string conversion, RSA decryption,
-   data decoding, and message digesting and comparison. The input to the
-   verification process shall be an octet string M, the message; a
-   signer's public key; and a bit string S, the signature. The output
-   from the verification process shall be an indication of success or
-   failure.
-
-10.2.1 Bit-string-to-octet-string conversion
-
-   The signature S shall be converted into an octet string ED, the
-   encrypted data. Specifically, assuming that the length in bits of the
-   signature S is a multiple of eight, the first bit of the signature
-   shall become the most significant bit of the first octet of the
-
-
-
-
-
-Kaliski                      Informational                     [Page 15]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   encrypted data, and so on through the last bit of the signature,
-   which shall become the least significant bit of the last octet of the
-   encrypted data.
-
-   It is an error if the length in bits of the signature S is not a
-   multiple of eight.
-
-10.2.2 RSA decryption
-
-   The encrypted data ED shall be decrypted with the signer's RSA public
-   key as described in Section 8 to give an octet string D, the data.
-
-   It is an error if the block type recovered in the decryption process
-   is not 01. (See Section 9.4.)
-
-10.2.3 Data decoding
-
-   The data D shall be BER-decoded to give an ASN.1 value of type
-   DigestInfo, which shall be separated into a message digest MD and a
-   message-digest algorithm identifier. The message-digest algorithm
-   identifier shall determine the "selected" message-digest algorithm
-   for the next step.
-
-   It is an error if the message-digest algorithm identifier does not
-   identify the MD2, MD4 or MD5 message-digest algorithm.
-
-10.2.4 Message digesting and comparison
-
-   The message M shall be digested with the selected message-digest
-   algorithm to give an octet string MD', the comparative message
-   digest. The verification process shall succeed if the comparative
-   message digest MD' is the same as the message digest MD, and the
-   verification process shall fail otherwise.
-
-11. Object identifiers
-
-   This document defines five object identifiers: pkcs-1, rsaEncryption,
-   md2WithRSAEncryption, md4WithRSAEncryption, and md5WithRSAEncryption.
-
-   The object identifier pkcs-1 identifies this document.
-
-   pkcs-1 OBJECT IDENTIFIER ::=
-
-     { iso(1) member-body(2) US(840) rsadsi(113549)
-         pkcs(1) 1 }
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 16]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   The object identifier rsaEncryption identifies RSA public and private
-   keys as defined in Section 7 and the RSA encryption and decryption
-   processes defined in Sections 8 and 9.
-
-   rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
-
-   The rsaEncryption object identifier is intended to be used in the
-   algorithm field of a value of type AlgorithmIdentifier. The
-   parameters field of that type, which has the algorithm-specific
-   syntax ANY DEFINED BY algorithm, would have ASN.1 type NULL for this
-   algorithm.
-
-   The object identifiers md2WithRSAEncryption, md4WithRSAEncryption,
-   md5WithRSAEncryption, identify, respectively, the "MD2 with RSA,"
-   "MD4 with RSA," and "MD5 with RSA" signature and verification
-   processes defined in Section 10.
-
-   md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
-   md4WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 3 }
-   md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
-
-   These object identifiers are intended to be used in the algorithm
-   field of a value of type AlgorithmIdentifier. The parameters field of
-   that type, which has the algorithm-specific syntax ANY DEFINED BY
-   algorithm, would have ASN.1 type NULL for these algorithms.
-
-   Note. X.509's object identifier rsa also identifies RSA public keys
-   as defined in Section 7, but does not identify private keys, and
-   identifies different encryption and decryption processes. It is
-   expected that some applications will identify public keys by rsa.
-   Such public keys are compatible with this document; an rsaEncryption
-   process under an rsa public key is the same as the rsaEncryption
-   process under an rsaEncryption public key.
-
-Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-Revision history
-
-   Versions 1.0-1.3
-
-   Versions 1.0-1.3 were distributed to participants in RSA Data
-   Security, Inc.'s Public-Key Cryptography Standards meetings in
-   February and March 1991.
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 17]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-   Version 1.4
-
-   Version 1.4 is part of the June 3, 1991 initial public release of
-   PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop
-   document SEC-SIG-91-18.
-
-   Version 1.5
-
-   Version 1.5 incorporates several editorial changes, including updates
-   to the references and the addition of a revision history. The
-   following substantive changes were made:
-
-        o    Section 10: "MD4 with RSA" signature and
-             verification processes are added.
-
-        o    Section 11: md4WithRSAEncryption object identifier
-             is added.
-
-   Supersedes June 3, 1991 version, which was also published as NIST/OSI
-   Implementors' Workshop document SEC-SIG-91-18.
-
-Acknowledgements
-
-   This document is based on a contribution of RSA Laboratories, a
-   division of RSA Data Security, Inc.  Any substantial use of the text
-   from this document must acknowledge RSA Data Security, Inc. RSA Data
-   Security, Inc.  requests that all material mentioning or referencing
-   this document identify this as "RSA Data Security, Inc. PKCS #1".
-
-Author's Address
-
-   Burt Kaliski
-   RSA Laboratories East
-   20 Crosby Drive
-   Bedford, MA  01730
-
-   Phone: (617) 687-7000
-   EMail: burt@rsa.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 18]
-
-RFC 2313                PKCS #1: RSA Encryption               March 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaliski                      Informational                     [Page 19]
-
diff --git a/doc/protocol/rfc2440.txt b/doc/protocol/rfc2440.txt
deleted file mode 100644
index 82da085d85..0000000000
--- a/doc/protocol/rfc2440.txt
+++ /dev/null
@@ -1,3643 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Callas
-Request for Comments: 2440                           Network Associates
-Category: Standards Track                                L. Donnerhacke
-                                     IN-Root-CA Individual Network e.V.
-                                                              H. Finney
-                                                     Network Associates
-                                                              R. Thayer
-                                                        EIS Corporation
-                                                          November 1998
-
-
-                         OpenPGP Message Format
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-IESG Note
-
-   This document defines many tag values, yet it doesn't describe a
-   mechanism for adding new tags (for new features).  Traditionally the
-   Internet Assigned Numbers Authority (IANA) handles the allocation of
-   new values for future expansion and RFCs usually define the procedure
-   to be used by the IANA.  However, there are subtle (and not so
-   subtle) interactions that may occur in this protocol between new
-   features and existing features which result in a significant
-   reduction in over all security.  Therefore, this document does not
-   define an extension procedure.  Instead requests to define new tag
-   values (say for new encryption algorithms for example) should be
-   forwarded to the IESG Security Area Directors for consideration or
-   forwarding to the appropriate IETF Working Group for consideration.
-
-Abstract
-
-   This document is maintained in order to publish all necessary
-   information needed to develop interoperable applications based on the
-   OpenPGP format. It is not a step-by-step cookbook for writing an
-   application. It describes only the format and methods needed to read,
-   check, generate, and write conforming packets crossing any network.
-   It does not deal with storage and implementation questions.  It does,
-
-
-
-Callas, et. al.             Standards Track                     [Page 1]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   however, discuss implementation issues necessary to avoid security
-   flaws.
-
-   Open-PGP software uses a combination of strong public-key and
-   symmetric cryptography to provide security services for electronic
-   communications and data storage.  These services include
-   confidentiality, key management, authentication, and digital
-   signatures. This document specifies the message formats used in
-   OpenPGP.
-
-Table of Contents
-
-            Status of this Memo                                       1
-            IESG Note                                                 1
-            Abstract                                                  1
-            Table of Contents                                         2
-   1.       Introduction                                              4
-   1.1.     Terms                                                     5
-   2.       General functions                                         5
-   2.1.     Confidentiality via Encryption                            5
-   2.2.     Authentication via Digital signature                      6
-   2.3.     Compression                                               7
-   2.4.     Conversion to Radix-64                                    7
-   2.5.     Signature-Only Applications                               7
-   3.       Data Element Formats                                      7
-   3.1.     Scalar numbers                                            8
-   3.2.     Multi-Precision Integers                                  8
-   3.3.     Key IDs                                                   8
-   3.4.     Text                                                      8
-   3.5.     Time fields                                               9
-   3.6.     String-to-key (S2K) specifiers                            9
-   3.6.1.   String-to-key (S2k) specifier types                       9
-   3.6.1.1. Simple S2K                                                9
-   3.6.1.2. Salted S2K                                               10
-   3.6.1.3. Iterated and Salted S2K                                  10
-   3.6.2.   String-to-key usage                                      11
-   3.6.2.1. Secret key encryption                                    11
-   3.6.2.2. Symmetric-key message encryption                         11
-   4.       Packet Syntax                                            12
-   4.1.     Overview                                                 12
-   4.2.     Packet Headers                                           12
-   4.2.1.   Old-Format Packet Lengths                                13
-   4.2.2.   New-Format Packet Lengths                                13
-   4.2.2.1. One-Octet Lengths                                        14
-   4.2.2.2. Two-Octet Lengths                                        14
-   4.2.2.3. Five-Octet Lengths                                       14
-   4.2.2.4. Partial Body Lengths                                     14
-   4.2.3.   Packet Length Examples                                   14
-
-
-
-Callas, et. al.             Standards Track                     [Page 2]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   4.3.     Packet Tags                                              15
-   5.       Packet Types                                             16
-   5.1.     Public-Key Encrypted Session Key Packets (Tag 1)         16
-   5.2.     Signature Packet (Tag 2)                                 17
-   5.2.1.   Signature Types                                          17
-   5.2.2.   Version 3 Signature Packet Format                        19
-   5.2.3.   Version 4 Signature Packet Format                        21
-   5.2.3.1. Signature Subpacket Specification                        22
-   5.2.3.2. Signature Subpacket Types                                24
-   5.2.3.3. Signature creation time                                  25
-   5.2.3.4. Issuer                                                   25
-   5.2.3.5. Key expiration time                                      25
-   5.2.3.6. Preferred symmetric algorithms                           25
-   5.2.3.7. Preferred hash algorithms                                25
-   5.2.3.8. Preferred compression algorithms                         26
-   5.2.3.9. Signature expiration time                                26
-   5.2.3.10.Exportable Certification                                 26
-   5.2.3.11.Revocable                                                27
-   5.2.3.12.Trust signature                                          27
-   5.2.3.13.Regular expression                                       27
-   5.2.3.14.Revocation key                                           27
-   5.2.3.15.Notation Data                                            28
-   5.2.3.16.Key server preferences                                   28
-   5.2.3.17.Preferred key server                                     29
-   5.2.3.18.Primary user id                                          29
-   5.2.3.19.Policy URL                                               29
-   5.2.3.20.Key Flags                                                29
-   5.2.3.21.Signer's User ID                                         30
-   5.2.3.22.Reason for Revocation                                    30
-   5.2.4.   Computing Signatures                                     31
-   5.2.4.1. Subpacket Hints                                          32
-   5.3.     Symmetric-Key Encrypted Session-Key Packets (Tag 3)      32
-   5.4.     One-Pass Signature Packets (Tag 4)                       33
-   5.5.     Key Material Packet                                      34
-   5.5.1.   Key Packet Variants                                      34
-   5.5.1.1. Public Key Packet (Tag 6)                                34
-   5.5.1.2. Public Subkey Packet (Tag 14)                            34
-   5.5.1.3. Secret Key Packet (Tag 5)                                35
-   5.5.1.4. Secret Subkey Packet (Tag 7)                             35
-   5.5.2.   Public Key Packet Formats                                35
-   5.5.3.   Secret Key Packet Formats                                37
-   5.6.     Compressed Data Packet (Tag 8)                           38
-   5.7.     Symmetrically Encrypted Data Packet (Tag 9)              39
-   5.8.     Marker Packet (Obsolete Literal Packet) (Tag 10)         39
-   5.9.     Literal Data Packet (Tag 11)                             40
-   5.10.    Trust Packet (Tag 12)                                    40
-   5.11.    User ID Packet (Tag 13)                                  41
-   6.       Radix-64 Conversions                                     41
-
-
-
-Callas, et. al.             Standards Track                     [Page 3]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   6.1.     An Implementation of the CRC-24 in "C"                   42
-   6.2.     Forming ASCII Armor                                      42
-   6.3.     Encoding Binary in Radix-64                              44
-   6.4.     Decoding Radix-64                                        46
-   6.5.     Examples of Radix-64                                     46
-   6.6.     Example of an ASCII Armored Message                      47
-   7.       Cleartext signature framework                            47
-   7.1.     Dash-Escaped Text                                        47
-   8.       Regular Expressions                                      48
-   9.       Constants                                                49
-   9.1.     Public Key Algorithms                                    49
-   9.2.     Symmetric Key Algorithms                                 49
-   9.3.     Compression Algorithms                                   50
-   9.4.     Hash Algorithms                                          50
-   10.      Packet Composition                                       50
-   10.1.    Transferable Public Keys                                 50
-   10.2.    OpenPGP Messages                                         52
-   10.3.    Detached Signatures                                      52
-   11.      Enhanced Key Formats                                     52
-   11.1.    Key Structures                                           52
-   11.2.    Key IDs and Fingerprints                                 53
-   12.      Notes on Algorithms                                      54
-   12.1.    Symmetric Algorithm Preferences                          54
-   12.2.    Other Algorithm Preferences                              55
-   12.2.1.  Compression Preferences                                  56
-   12.2.2.  Hash Algorithm Preferences                               56
-   12.3.    Plaintext                                                56
-   12.4.    RSA                                                      56
-   12.5.    Elgamal                                                  57
-   12.6.    DSA                                                      58
-   12.7.    Reserved Algorithm Numbers                               58
-   12.8.    OpenPGP CFB mode                                         58
-   13.      Security Considerations                                  59
-   14.      Implementation Nits                                      60
-   15.      Authors and Working Group Chair                          62
-   16.      References                                               63
-   17.      Full Copyright Statement                                 65
-
-1. Introduction
-
-   This document provides information on the message-exchange packet
-   formats used by OpenPGP to provide encryption, decryption, signing,
-   and key management functions. It builds on the foundation provided in
-   RFC 1991 "PGP Message Exchange Formats."
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                     [Page 4]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-1.1. Terms
-
-     * OpenPGP - This is a definition for security software that uses
-       PGP 5.x as a basis.
-
-     * PGP - Pretty Good Privacy. PGP is a family of software systems
-       developed by Philip R. Zimmermann from which OpenPGP is based.
-
-     * PGP 2.6.x - This version of PGP has many variants, hence the term
-       PGP 2.6.x. It used only RSA, MD5, and IDEA for its cryptographic
-       transforms. An informational RFC, RFC 1991, was written
-       describing this version of PGP.
-
-     * PGP 5.x - This version of PGP is formerly known as "PGP 3" in the
-       community and also in the predecessor of this document, RFC 1991.
-       It has new formats and corrects a number of problems in the PGP
-       2.6.x design. It is referred to here as PGP 5.x because that
-       software was the first release of the "PGP 3" code base.
-
-   "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of
-   Network Associates, Inc. and are used with permission.
-
-   This document uses the terms "MUST", "SHOULD", and "MAY" as defined
-   in RFC 2119, along with the negated forms of those terms.
-
-2. General functions
-
-   OpenPGP provides data integrity services for messages and data files
-   by using these core technologies:
-
-     - digital signatures
-
-     - encryption
-
-     - compression
-
-     - radix-64 conversion
-
-   In addition, OpenPGP provides key management and certificate
-   services, but many of these are beyond the scope of this document.
-
-2.1. Confidentiality via Encryption
-
-   OpenPGP uses two encryption methods to provide confidentiality:
-   symmetric-key encryption and public key encryption. With public-key
-   encryption, the object is encrypted using a symmetric encryption
-   algorithm.  Each symmetric key is used only once. A new "session key"
-   is generated as a random number for each message. Since it is used
-
-
-
-Callas, et. al.             Standards Track                     [Page 5]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   only once, the session key is bound to the message and transmitted
-   with it.  To protect the key, it is encrypted with the receiver's
-   public key. The sequence is as follows:
-
-   1.  The sender creates a message.
-
-   2.  The sending OpenPGP generates a random number to be used as a
-       session key for this message only.
-
-   3.  The session key is encrypted using each recipient's public key.
-       These "encrypted session keys" start the message.
-
-   4.  The sending OpenPGP encrypts the message using the session key,
-       which forms the remainder of the message. Note that the message
-       is also usually compressed.
-
-   5.  The receiving OpenPGP decrypts the session key using the
-       recipient's private key.
-
-   6.  The receiving OpenPGP decrypts the message using the session key.
-       If the message was compressed, it will be decompressed.
-
-   With symmetric-key encryption, an object may be encrypted with a
-   symmetric key derived from a passphrase (or other shared secret), or
-   a two-stage mechanism similar to the public-key method described
-   above in which a session key is itself encrypted with a symmetric
-   algorithm keyed from a shared secret.
-
-   Both digital signature and confidentiality services may be applied to
-   the same message. First, a signature is generated for the message and
-   attached to the message. Then, the message plus signature is
-   encrypted using a symmetric session key. Finally, the session key is
-   encrypted using public-key encryption and prefixed to the encrypted
-   block.
-
-2.2. Authentication via Digital signature
-
-   The digital signature uses a hash code or message digest algorithm,
-   and a public-key signature algorithm. The sequence is as follows:
-
-   1.  The sender creates a message.
-
-   2.  The sending software generates a hash code of the message.
-
-   3.  The sending software generates a signature from the hash code
-       using the sender's private key.
-
-   4.  The binary signature is attached to the message.
-
-
-
-Callas, et. al.             Standards Track                     [Page 6]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   5.  The receiving software keeps a copy of the message signature.
-
-   6.  The receiving software generates a new hash code for the
-       received message and verifies it using the message's signature.
-       If the verification is successful, the message is accepted as
-       authentic.
-
-2.3. Compression
-
-   OpenPGP implementations MAY compress the message after applying the
-   signature but before encryption.
-
-2.4. Conversion to Radix-64
-
-   OpenPGP's underlying native representation for encrypted messages,
-   signature certificates, and keys is a stream of arbitrary octets.
-   Some systems only permit the use of blocks consisting of seven-bit,
-   printable text. For transporting OpenPGP's native raw binary octets
-   through channels that are not safe to raw binary data, a printable
-   encoding of these binary octets is needed.  OpenPGP provides the
-   service of converting the raw 8-bit binary octet stream to a stream
-   of printable ASCII characters, called Radix-64 encoding or ASCII
-   Armor.
-
-   Implementations SHOULD provide Radix-64 conversions.
-
-   Note that many applications, particularly messaging applications,
-   will want more advanced features as described in the OpenPGP-MIME
-   document, RFC 2015. An application that implements OpenPGP for
-   messaging SHOULD implement OpenPGP-MIME.
-
-2.5. Signature-Only Applications
-
-   OpenPGP is designed for applications that use both encryption and
-   signatures, but there are a number of problems that are solved by a
-   signature-only implementation. Although this specification requires
-   both encryption and signatures, it is reasonable for there to be
-   subset implementations that are non-comformant only in that they omit
-   encryption.
-
-3. Data Element Formats
-
-   This section describes the data elements used by OpenPGP.
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                     [Page 7]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-3.1. Scalar numbers
-
-   Scalar numbers are unsigned, and are always stored in big-endian
-   format. Using n[k] to refer to the kth octet being interpreted, the
-   value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a
-   four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
-   n[3]).
-
-3.2. Multi-Precision Integers
-
-   Multi-Precision Integers (also called MPIs) are unsigned integers
-   used to hold large integers such as the ones used in cryptographic
-   calculations.
-
-   An MPI consists of two pieces: a two-octet scalar that is the length
-   of the MPI in bits followed by a string of octets that contain the
-   actual integer.
-
-   These octets form a big-endian number; a big-endian number can be
-   made into an MPI by prefixing it with the appropriate length.
-
-   Examples:
-
-   (all numbers are in hexadecimal)
-
-   The string of octets [00 01 01] forms an MPI with the value 1. The
-   string [00 09 01 FF] forms an MPI with the value of 511.
-
-   Additional rules:
-
-   The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.
-
-   The length field of an MPI describes the length starting from its
-   most significant non-zero bit. Thus, the MPI [00 02 01] is not formed
-   correctly. It should be [00 01 01].
-
-3.3. Key IDs
-
-   A Key ID is an eight-octet scalar that identifies a key.
-   Implementations SHOULD NOT assume that Key IDs are unique. The
-   section, "Enhanced Key Formats" below describes how Key IDs are
-   formed.
-
-3.4. Text
-
-   The default character set for text is the UTF-8 [RFC2279] encoding of
-   Unicode [ISO10646].
-
-
-
-
-Callas, et. al.             Standards Track                     [Page 8]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-3.5. Time fields
-
-   A time field is an unsigned four-octet number containing the number
-   of seconds elapsed since midnight, 1 January 1970 UTC.
-
-3.6. String-to-key (S2K) specifiers
-
-   String-to-key (S2K) specifiers are used to convert passphrase strings
-   into symmetric-key encryption/decryption keys.  They are used in two
-   places, currently: to encrypt the secret part of private keys in the
-   private keyring, and to convert passphrases to encryption keys for
-   symmetrically encrypted messages.
-
-3.6.1. String-to-key (S2k) specifier types
-
-   There are three types of S2K specifiers currently supported, as
-   follows:
-
-3.6.1.1. Simple S2K
-
-   This directly hashes the string to produce the key data.  See below
-   for how this hashing is done.
-
-       Octet 0:        0x00
-       Octet 1:        hash algorithm
-
-   Simple S2K hashes the passphrase to produce the session key.  The
-   manner in which this is done depends on the size of the session key
-   (which will depend on the cipher used) and the size of the hash
-   algorithm's output. If the hash size is greater than or equal to the
-   session key size, the high-order (leftmost) octets of the hash are
-   used as the key.
-
-   If the hash size is less than the key size, multiple instances of the
-   hash context are created -- enough to produce the required key data.
-   These instances are preloaded with 0, 1, 2, ... octets of zeros (that
-   is to say, the first instance has no preloading, the second gets
-   preloaded with 1 octet of zero, the third is preloaded with two
-   octets of zeros, and so forth).
-
-   As the data is hashed, it is given independently to each hash
-   context. Since the contexts have been initialized differently, they
-   will each produce different hash output.  Once the passphrase is
-   hashed, the output data from the multiple hashes is concatenated,
-   first hash leftmost, to produce the key data, with any excess octets
-   on the right discarded.
-
-
-
-
-
-Callas, et. al.             Standards Track                     [Page 9]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-3.6.1.2. Salted S2K
-
-   This includes a "salt" value in the S2K specifier -- some arbitrary
-   data -- that gets hashed along with the passphrase string, to help
-   prevent dictionary attacks.
-
-       Octet 0:        0x01
-       Octet 1:        hash algorithm
-       Octets 2-9:     8-octet salt value
-
-   Salted S2K is exactly like Simple S2K, except that the input to the
-   hash function(s) consists of the 8 octets of salt from the S2K
-   specifier, followed by the passphrase.
-
-3.6.1.3. Iterated and Salted S2K
-
-   This includes both a salt and an octet count.  The salt is combined
-   with the passphrase and the resulting value is hashed repeatedly.
-   This further increases the amount of work an attacker must do to try
-   dictionary attacks.
-
-       Octet  0:        0x03
-       Octet  1:        hash algorithm
-       Octets 2-9:      8-octet salt value
-       Octet  10:       count, a one-octet, coded value
-
-   The count is coded into a one-octet number using the following
-   formula:
-
-       #define EXPBIAS 6
-           count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
-
-   The above formula is in C, where "Int32" is a type for a 32-bit
-   integer, and the variable "c" is the coded count, Octet 10.
-
-   Iterated-Salted S2K hashes the passphrase and salt data multiple
-   times. The total number of octets to be hashed is specified in the
-   encoded count in the S2K specifier.  Note that the resulting count
-   value is an octet count of how many octets will be hashed, not an
-   iteration count.
-
-   Initially, one or more hash contexts are set up as with the other S2K
-   algorithms, depending on how many octets of key data are needed.
-   Then the salt, followed by the passphrase data is repeatedly hashed
-   until the number of octets specified by the octet count has been
-   hashed.  The one exception is that if the octet count is less than
-   the size of the salt plus passphrase, the full salt plus passphrase
-   will be hashed even though that is greater than the octet count.
-
-
-
-Callas, et. al.             Standards Track                    [Page 10]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   After the hashing is done the data is unloaded from the hash
-   context(s) as with the other S2K algorithms.
-
-3.6.2. String-to-key usage
-
-   Implementations SHOULD use salted or iterated-and-salted S2K
-   specifiers, as simple S2K specifiers are more vulnerable to
-   dictionary attacks.
-
-3.6.2.1. Secret key encryption
-
-   An S2K specifier can be stored in the secret keyring to specify how
-   to convert the passphrase to a key that unlocks the secret data.
-   Older versions of PGP just stored a cipher algorithm octet preceding
-   the secret data or a zero to indicate that the secret data was
-   unencrypted. The MD5 hash function was always used to convert the
-   passphrase to a key for the specified cipher algorithm.
-
-   For compatibility, when an S2K specifier is used, the special value
-   255 is stored in the position where the hash algorithm octet would
-   have been in the old data structure.  This is then followed
-   immediately by a one-octet algorithm identifier, and then by the S2K
-   specifier as encoded above.
-
-   Therefore, preceding the secret data there will be one of these
-   possibilities:
-
-       0:           secret data is unencrypted (no pass phrase)
-       255:         followed by algorithm octet and S2K specifier
-       Cipher alg:  use Simple S2K algorithm using MD5 hash
-
-   This last possibility, the cipher algorithm number with an implicit
-   use of MD5 and IDEA, is provided for backward compatibility; it MAY
-   be understood, but SHOULD NOT be generated, and is deprecated.
-
-   These are followed by an 8-octet Initial Vector for the decryption of
-   the secret values, if they are encrypted, and then the secret key
-   values themselves.
-
-3.6.2.2. Symmetric-key message encryption
-
-   OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet
-   at the front of a message.  This is used to allow S2K specifiers to
-   be used for the passphrase conversion or to create messages with a
-   mix of symmetric-key ESKs and public-key ESKs. This allows a message
-   to be decrypted either with a passphrase or a public key.
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 11]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   PGP 2.X always used IDEA with Simple string-to-key conversion when
-   encrypting a message with a symmetric algorithm. This is deprecated,
-   but MAY be used for backward-compatibility.
-
-4. Packet Syntax
-
-   This section describes the packets used by OpenPGP.
-
-4.1. Overview
-
-   An OpenPGP message is constructed from a number of records that are
-   traditionally called packets. A packet is a chunk of data that has a
-   tag specifying its meaning. An OpenPGP message, keyring, certificate,
-   and so forth consists of a number of packets. Some of those packets
-   may contain other OpenPGP packets (for example, a compressed data
-   packet, when uncompressed, contains OpenPGP packets).
-
-   Each packet consists of a packet header, followed by the packet body.
-   The packet header is of variable length.
-
-4.2. Packet Headers
-
-   The first octet of the packet header is called the "Packet Tag." It
-   determines the format of the header and denotes the packet contents.
-   The remainder of the packet header is the length of the packet.
-
-   Note that the most significant bit is the left-most bit, called bit
-   7. A mask for this bit is 0x80 in hexadecimal.
-
-              +---------------+
-         PTag |7 6 5 4 3 2 1 0|
-              +---------------+
-         Bit 7 -- Always one
-         Bit 6 -- New packet format if set
-
-   PGP 2.6.x only uses old format packets. Thus, software that
-   interoperates with those versions of PGP must only use old format
-   packets. If interoperability is not an issue, either format may be
-   used. Note that old format packets have four bits of content tags,
-   and new format packets have six; some features cannot be used and
-   still be backward-compatible.
-
-   Old format packets contain:
-
-         Bits 5-2 -- content tag
-         Bits 1-0 - length-type
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 12]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   New format packets contain:
-
-         Bits 5-0 -- content tag
-
-4.2.1. Old-Format Packet Lengths
-
-   The meaning of the length-type in old-format packets is:
-
-   0 - The packet has a one-octet length. The header is 2 octets long.
-
-   1 - The packet has a two-octet length. The header is 3 octets long.
-
-   2 - The packet has a four-octet length. The header is 5 octets long.
-
-   3 - The packet is of indeterminate length.  The header is 1 octet
-       long, and the implementation must determine how long the packet
-       is. If the packet is in a file, this means that the packet
-       extends until the end of the file. In general, an implementation
-       SHOULD NOT use indeterminate length packets except where the end
-       of the data will be clear from the context, and even then it is
-       better to use a definite length, or a new-format header. The
-       new-format headers described below have a mechanism for precisely
-       encoding data of indeterminate length.
-
-4.2.2. New-Format Packet Lengths
-
-   New format packets have four possible ways of encoding length:
-
-    1. A one-octet Body Length header encodes packet lengths of up to
-       191 octets.
-
-   2. A two-octet Body Length header encodes packet lengths of 192 to
-       8383 octets.
-
-    3. A five-octet Body Length header encodes packet lengths of up to
-       4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
-       encodes a four-octet scalar number.)
-
-    4. When the length of the packet body is not known in advance by the
-       issuer, Partial Body Length headers encode a packet of
-       indeterminate length, effectively making it a stream.
-
-
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 13]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-4.2.2.1. One-Octet Lengths
-
-   A one-octet Body Length header encodes a length of from 0 to 191
-   octets. This type of length header is recognized because the one
-   octet value is less than 192.  The body length is equal to:
-
-       bodyLen = 1st_octet;
-
-4.2.2.2. Two-Octet Lengths
-
-   A two-octet Body Length header encodes a length of from 192 to 8383
-   octets.  It is recognized because its first octet is in the range 192
-   to 223.  The body length is equal to:
-
-       bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
-
-4.2.2.3. Five-Octet Lengths
-
-   A five-octet Body Length header consists of a single octet holding
-   the value 255, followed by a four-octet scalar. The body length is
-   equal to:
-
-       bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
-                 (4th_octet << 8)  | 5th_octet
-
-4.2.2.4. Partial Body Lengths
-
-   A Partial Body Length header is one octet long and encodes the length
-   of only part of the data packet. This length is a power of 2, from 1
-   to 1,073,741,824 (2 to the 30th power).  It is recognized by its one
-   octet value that is greater than or equal to 224, and less than 255.
-   The partial body length is equal to:
-
-       partialBodyLen = 1 << (1st_octet & 0x1f);
-
-   Each Partial Body Length header is followed by a portion of the
-   packet body data. The Partial Body Length header specifies this
-   portion's length. Another length header (of one of the three types --
-   one octet, two-octet, or partial) follows that portion. The last
-   length header in the packet MUST NOT be a partial Body Length header.
-   Partial Body Length headers may only be used for the non-final parts
-   of the packet.
-
-4.2.3. Packet Length Examples
-
-   These examples show ways that new-format packets might encode the
-   packet lengths.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 14]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   A packet with length 100 may have its length encoded in one octet:
-   0x64. This is followed by 100 octets of data.
-
-   A packet with length 1723 may have its length coded in two octets:
-   0xC5, 0xFB.  This header is followed by the 1723 octets of data.
-
-   A packet with length 100000 may have its length encoded in five
-   octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
-
-   It might also be encoded in the following octet stream: 0xEF, first
-   32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
-   octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693
-   octets of data.  This is just one possible encoding, and many
-   variations are possible on the size of the Partial Body Length
-   headers, as long as a regular Body Length header encodes the last
-   portion of the data. Note also that the last Body Length header can
-   be a zero-length header.
-
-   An implementation MAY use Partial Body Lengths for data packets, be
-   they literal, compressed, or encrypted. The first partial length MUST
-   be at least 512 octets long. Partial Body Lengths MUST NOT be used
-   for any other packet types.
-
-   Please note that in all of these explanations, the total length of
-   the packet is the length of the header(s) plus the length of the
-   body.
-
-4.3. Packet Tags
-
-   The packet tag denotes what type of packet the body holds. Note that
-   old format headers can only have tags less than 16, whereas new
-   format headers can have tags as great as 63. The defined tags (in
-   decimal) are:
-
-       0        -- Reserved - a packet tag must not have this value
-       1        -- Public-Key Encrypted Session Key Packet
-       2        -- Signature Packet
-       3        -- Symmetric-Key Encrypted Session Key Packet
-       4        -- One-Pass Signature Packet
-       5        -- Secret Key Packet
-       6        -- Public Key Packet
-       7        -- Secret Subkey Packet
-       8        -- Compressed Data Packet
-       9        -- Symmetrically Encrypted Data Packet
-       10       -- Marker Packet
-       11       -- Literal Data Packet
-       12       -- Trust Packet
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 15]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-       13       -- User ID Packet
-       14       -- Public Subkey Packet
-       60 to 63 -- Private or Experimental Values
-
-5. Packet Types
-
-5.1. Public-Key Encrypted Session Key Packets (Tag 1)
-
-   A Public-Key Encrypted Session Key packet holds the session key used
-   to encrypt a message. Zero or more Encrypted Session Key packets
-   (either Public-Key or Symmetric-Key) may precede a Symmetrically
-   Encrypted Data Packet, which holds an encrypted message.  The message
-   is encrypted with the session key, and the session key is itself
-   encrypted and stored in the Encrypted Session Key packet(s).  The
-   Symmetrically Encrypted Data Packet is preceded by one Public-Key
-   Encrypted Session Key packet for each OpenPGP key to which the
-   message is encrypted.  The recipient of the message finds a session
-   key that is encrypted to their public key, decrypts the session key,
-   and then uses the session key to decrypt the message.
-
-   The body of this packet consists of:
-
-     - A one-octet number giving the version number of the packet type.
-       The currently defined value for packet version is 3. An
-       implementation should accept, but not generate a version of 2,
-       which is equivalent to V3 in all other respects.
-
-     - An eight-octet number that gives the key ID of the public key
-       that the session key is encrypted to.
-
-     - A one-octet number giving the public key algorithm used.
-
-     - A string of octets that is the encrypted session key. This string
-       takes up the remainder of the packet, and its contents are
-       dependent on the public key algorithm used.
-
-   Algorithm Specific Fields for RSA encryption
-
-     - multiprecision integer (MPI) of RSA encrypted value m**e mod n.
-
-   Algorithm Specific Fields for Elgamal encryption:
-
-     - MPI of Elgamal (Diffie-Hellman) value g**k mod p.
-
-     - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 16]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   The value "m" in the above formulas is derived from the session key
-   as follows.  First the session key is prefixed with a one-octet
-   algorithm identifier that specifies the symmetric encryption
-   algorithm used to encrypt the following Symmetrically Encrypted Data
-   Packet.  Then a two-octet checksum is appended which is equal to the
-   sum of the preceding session key octets, not including the algorithm
-   identifier, modulo 65536.  This value is then padded as described in
-   PKCS-1 block type 02 [RFC2313] to form the "m" value used in the
-   formulas above.
-
-   Note that when an implementation forms several PKESKs with one
-   session key, forming a message that can be decrypted by several keys,
-   the implementation MUST make new PKCS-1 padding for each key.
-
-   An implementation MAY accept or use a Key ID of zero as a "wild card"
-   or "speculative" Key ID. In this case, the receiving implementation
-   would try all available private keys, checking for a valid decrypted
-   session key. This format helps reduce traffic analysis of messages.
-
-5.2. Signature Packet (Tag 2)
-
-   A signature packet describes a binding between some public key and
-   some data. The most common signatures are a signature of a file or a
-   block of text, and a signature that is a certification of a user ID.
-
-   Two versions of signature packets are defined.  Version 3 provides
-   basic signature information, while version 4 provides an expandable
-   format with subpackets that can specify more information about the
-   signature. PGP 2.6.x only accepts version 3 signatures.
-
-   Implementations MUST accept V3 signatures. Implementations SHOULD
-   generate V4 signatures.  Implementations MAY generate a V3 signature
-   that can be verified by PGP 2.6.x.
-
-   Note that if an implementation is creating an encrypted and signed
-   message that is encrypted to a V3 key, it is reasonable to create a
-   V3 signature.
-
-5.2.1. Signature Types
-
-   There are a number of possible meanings for a signature, which are
-   specified in a signature type octet in any given signature. These
-   meanings are:
-
-   0x00: Signature of a binary document.
-         Typically, this means the signer owns it, created it, or
-         certifies that it has not been modified.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 17]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   0x01: Signature of a canonical text document.
-         Typically, this means the signer owns it, created it, or
-         certifies that it has not been modified.  The signature is
-         calculated over the text data with its line endings converted
-         to <CR><LF> and trailing blanks removed.
-
-   0x02: Standalone signature.
-         This signature is a signature of only its own subpacket
-         contents. It is calculated identically to a signature over a
-         zero-length binary document. Note that it doesn't make sense to
-         have a V3 standalone signature.
-
-   0x10: Generic certification of a User ID and Public Key packet.
-         The issuer of this certification does not make any particular
-         assertion as to how well the certifier has checked that the
-         owner of the key is in fact the person described by the user
-         ID.  Note that all PGP "key signatures" are this type of
-         certification.
-
-   0x11: Persona certification of a User ID and Public Key packet.
-         The issuer of this certification has not done any verification
-         of the claim that the owner of this key is the user ID
-         specified.
-
-   0x12: Casual certification of a User ID and Public Key packet.
-         The issuer of this certification has done some casual
-         verification of the claim of identity.
-
-   0x13: Positive certification of a User ID and Public Key packet.
-         The issuer of this certification has done substantial
-         verification of the claim of identity.
-
-         Please note that the vagueness of these certification claims is
-         not a flaw, but a feature of the system. Because PGP places
-         final authority for validity upon the receiver of a
-         certification, it may be that one authority's casual
-         certification might be more rigorous than some other
-         authority's positive certification. These classifications allow
-         a certification authority to issue fine-grained claims.
-
-   0x18: Subkey Binding Signature
-         This signature is a statement by the top-level signing key
-         indicates that it owns the subkey. This signature is calculated
-         directly on the subkey itself, not on any User ID or other
-         packets.
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 18]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   0x1F: Signature directly on a key
-         This signature is calculated directly on a key.  It binds the
-         information in the signature subpackets to the key, and is
-         appropriate to be used for subpackets that provide information
-         about the key, such as the revocation key subpacket. It is also
-         appropriate for statements that non-self certifiers want to
-         make about the key itself, rather than the binding between a
-         key and a name.
-
-   0x20: Key revocation signature
-         The signature is calculated directly on the key being revoked.
-         A revoked key is not to be used.  Only revocation signatures by
-         the key being revoked, or by an authorized revocation key,
-         should be considered valid revocation signatures.
-
-   0x28: Subkey revocation signature
-         The signature is calculated directly on the subkey being
-         revoked.  A revoked subkey is not to be used.  Only revocation
-         signatures by the top-level signature key that is bound to this
-         subkey, or by an authorized revocation key, should be
-         considered valid revocation signatures.
-
-   0x30: Certification revocation signature
-         This signature revokes an earlier user ID certification
-         signature (signature class 0x10 through 0x13). It should be
-         issued by the same key that issued the revoked signature or an
-         authorized revocation key The signature should have a later
-         creation date than the signature it revokes.
-
-   0x40: Timestamp signature.
-         This signature is only meaningful for the timestamp contained
-         in it.
-
-5.2.2. Version 3 Signature Packet Format
-
-   The body of a version 3 Signature Packet contains:
-
-     - One-octet version number (3).
-
-     - One-octet length of following hashed material.  MUST be 5.
-
-         - One-octet signature type.
-
-         - Four-octet creation time.
-
-     - Eight-octet key ID of signer.
-
-     - One-octet public key algorithm.
-
-
-
-Callas, et. al.             Standards Track                    [Page 19]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-     - One-octet hash algorithm.
-
-     - Two-octet field holding left 16 bits of signed hash value.
-
-     - One or more multi-precision integers comprising the signature.
-       This portion is algorithm specific, as described below.
-
-   The data being signed is hashed, and then the signature type and
-   creation time from the signature packet are hashed (5 additional
-   octets).  The resulting hash value is used in the signature
-   algorithm. The high 16 bits (first two octets) of the hash are
-   included in the signature packet to provide a quick test to reject
-   some invalid signatures.
-
-   Algorithm Specific Fields for RSA signatures:
-
-     - multiprecision integer (MPI) of RSA signature value m**d.
-
-   Algorithm Specific Fields for DSA signatures:
-
-     - MPI of DSA value r.
-
-     - MPI of DSA value s.
-
-   The signature calculation is based on a hash of the signed data, as
-   described above.  The details of the calculation are different for
-   DSA signature than for RSA signatures.
-
-   With RSA signatures, the hash value is encoded as described in PKCS-1
-   section 10.1.2, "Data encoding", producing an ASN.1 value of type
-   DigestInfo, and then padded using PKCS-1 block type 01 [RFC2313].
-   This requires inserting the hash value as an octet string into an
-   ASN.1 structure. The object identifier for the type of hash being
-   used is included in the structure.  The hexadecimal representations
-   for the currently defined hash algorithms are:
-
-     - MD2:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02
-
-     - MD5:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
-
-     - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
-
-     - SHA-1:      0x2B, 0x0E, 0x03, 0x02, 0x1A
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 20]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   The ASN.1 OIDs are:
-
-     - MD2:        1.2.840.113549.2.2
-
-     - MD5:        1.2.840.113549.2.5
-
-     - RIPEMD-160: 1.3.36.3.2.1
-
-     - SHA-1:      1.3.14.3.2.26
-
-   The full hash prefixes for these are:
-
-       MD2:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
-                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00,
-                   0x04, 0x10
-
-       MD5:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
-                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
-                   0x04, 0x10
-
-       RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
-                   0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
-
-       SHA-1:      0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
-                   0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
-
-   DSA signatures MUST use hashes with a size of 160 bits, to match q,
-   the size of the group generated by the DSA key's generator value.
-   The hash function result is treated as a 160 bit number and used
-   directly in the DSA signature algorithm.
-
-5.2.3. Version 4 Signature Packet Format
-
-   The body of a version 4 Signature Packet contains:
-
-     - One-octet version number (4).
-
-     - One-octet signature type.
-
-     - One-octet public key algorithm.
-
-     - One-octet hash algorithm.
-
-     - Two-octet scalar octet count for following hashed subpacket
-       data. Note that this is the length in octets of all of the hashed
-       subpackets; a pointer incremented by this number will skip over
-       the hashed subpackets.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 21]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-     - Hashed subpacket data. (zero or more subpackets)
-
-     - Two-octet scalar octet count for following unhashed subpacket
-       data. Note that this is the length in octets of all of the
-       unhashed subpackets; a pointer incremented by this number will
-       skip over the unhashed subpackets.
-
-     - Unhashed subpacket data. (zero or more subpackets)
-
-     - Two-octet field holding left 16 bits of signed hash value.
-
-     - One or more multi-precision integers comprising the signature.
-       This portion is algorithm specific, as described above.
-
-   The data being signed is hashed, and then the signature data from the
-   version number through the hashed subpacket data (inclusive) is
-   hashed. The resulting hash value is what is signed.  The left 16 bits
-   of the hash are included in the signature packet to provide a quick
-   test to reject some invalid signatures.
-
-   There are two fields consisting of signature subpackets.  The first
-   field is hashed with the rest of the signature data, while the second
-   is unhashed.  The second set of subpackets is not cryptographically
-   protected by the signature and should include only advisory
-   information.
-
-   The algorithms for converting the hash function result to a signature
-   are described in a section below.
-
-5.2.3.1. Signature Subpacket Specification
-
-   The subpacket fields consist of zero or more signature subpackets.
-   Each set of subpackets is preceded by a two-octet scalar count of the
-   length of the set of subpackets.
-
-   Each subpacket consists of a subpacket header and a body.  The header
-   consists of:
-
-     - the subpacket length (1,  2, or 5 octets)
-
-     - the subpacket type (1 octet)
-
-   and is followed by the subpacket specific data.
-
-   The length includes the type octet but not this length. Its format is
-   similar to the "new" format packet header lengths, but cannot have
-   partial body lengths. That is:
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 22]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-       if the 1st octet <  192, then
-           lengthOfLength = 1
-           subpacketLen = 1st_octet
-
-       if the 1st octet >= 192 and < 255, then
-           lengthOfLength = 2
-           subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
-
-       if the 1st octet = 255, then
-           lengthOfLength = 5
-           subpacket length = [four-octet scalar starting at 2nd_octet]
-
-   The value of the subpacket type octet may be:
-
-       2 = signature creation time
-       3 = signature expiration time
-       4 = exportable certification
-       5 = trust signature
-       6 = regular expression
-       7 = revocable
-       9 = key expiration time
-       10 = placeholder for backward compatibility
-       11 = preferred symmetric algorithms
-       12 = revocation key
-       16 = issuer key ID
-       20 = notation data
-       21 = preferred hash algorithms
-       22 = preferred compression algorithms
-       23 = key server preferences
-       24 = preferred key server
-       25 = primary user id
-       26 = policy URL
-       27 = key flags
-       28 = signer's user id
-       29 = reason for revocation
-       100 to 110 = internal or user-defined
-
-   An implementation SHOULD ignore any subpacket of a type that it does
-   not recognize.
-
-   Bit 7 of the subpacket type is the "critical" bit.  If set, it
-   denotes that the subpacket is one that is critical for the evaluator
-   of the signature to recognize.  If a subpacket is encountered that is
-   marked critical but is unknown to the evaluating software, the
-   evaluator SHOULD consider the signature to be in error.
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 23]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   An evaluator may "recognize" a subpacket, but not implement it. The
-   purpose of the critical bit is to allow the signer to tell an
-   evaluator that it would prefer a new, unknown feature to generate an
-   error than be ignored.
-
-   Implementations SHOULD implement "preferences".
-
-5.2.3.2. Signature Subpacket Types
-
-   A number of subpackets are currently defined.  Some subpackets apply
-   to the signature itself and some are attributes of the key.
-   Subpackets that are found on a self-signature are placed on a user id
-   certification made by the key itself. Note that a key may have more
-   than one user id, and thus may have more than one self-signature, and
-   differing subpackets.
-
-   A self-signature is a binding signature made by the key the signature
-   refers to. There are three types of self-signatures, the
-   certification signatures (types 0x10-0x13), the direct-key signature
-   (type 0x1f), and the subkey binding signature (type 0x18). For
-   certification self-signatures, each user ID may have a self-
-   signature, and thus different subpackets in those self-signatures.
-   For subkey binding signatures, each subkey in fact has a self-
-   signature. Subpackets that appear in a certification self-signature
-   apply to the username, and subpackets that appear in the subkey
-   self-signature apply to the subkey. Lastly, subpackets on the direct
-   key signature apply to the entire key.
-
-   Implementing software should interpret a self-signature's preference
-   subpackets as narrowly as possible. For example, suppose a key has
-   two usernames, Alice and Bob. Suppose that Alice prefers the
-   symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If the
-   software locates this key via Alice's name, then the preferred
-   algorithm is CAST5, if software locates the key via Bob's name, then
-   the preferred algorithm is IDEA. If the key is located by key id,
-   then algorithm of the default user id of the key provides the default
-   symmetric algorithm.
-
-   A subpacket may be found either in the hashed or unhashed subpacket
-   sections of a signature. If a subpacket is not hashed, then the
-   information in it cannot be considered definitive because it is not
-   part of the signature proper.
-
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 24]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-5.2.3.3. Signature creation time
-
-   (4 octet time field)
-
-   The time the signature was made.
-
-   MUST be present in the hashed area.
-
-5.2.3.4. Issuer
-
-   (8 octet key ID)
-
-   The OpenPGP key ID of the key issuing the signature.
-
-5.2.3.5. Key expiration time
-
-   (4 octet time field)
-
-   The validity period of the key.  This is the number of seconds after
-   the key creation time that the key expires.  If this is not present
-   or has a value of zero, the key never expires. This is found only on
-   a self-signature.
-
-5.2.3.6. Preferred symmetric algorithms
-
-   (sequence of one-octet values)
-
-   Symmetric algorithm numbers that indicate which algorithms the key
-   holder prefers to use.  The subpacket body is an ordered list of
-   octets with the most preferred listed first. It is assumed that only
-   algorithms listed are supported by the recipient's software.
-   Algorithm numbers in section 9. This is only found on a self-
-   signature.
-
-5.2.3.7. Preferred hash algorithms
-
-   (array of one-octet values)
-
-   Message digest algorithm numbers that indicate which algorithms the
-   key holder prefers to receive. Like the preferred symmetric
-   algorithms, the list is ordered. Algorithm numbers are in section 6.
-   This is only found on a self-signature.
-
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 25]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-5.2.3.8. Preferred compression algorithms
-
-   (array of one-octet values)
-
-   Compression algorithm numbers that indicate which algorithms the key
-   holder prefers to use. Like the preferred symmetric algorithms, the
-   list is ordered. Algorithm numbers are in section 6. If this
-   subpacket is not included, ZIP is preferred. A zero denotes that
-   uncompressed data is preferred; the key holder's software might have
-   no compression software in that implementation. This is only found on
-   a self-signature.
-
-5.2.3.9. Signature expiration time
-
-   (4 octet time field)
-
-   The validity period of the signature.  This is the number of seconds
-   after the signature creation time that the signature expires. If this
-   is not present or has a value of zero, it never expires.
-
-5.2.3.10. Exportable Certification
-
-   (1 octet of exportability, 0 for not, 1 for exportable)
-
-   This subpacket denotes whether a certification signature is
-   "exportable", to be used by other users than the signature's issuer.
-   The packet body contains a boolean flag indicating whether the
-   signature is exportable. If this packet is not present, the
-   certification is exportable; it is equivalent to a flag containing a
-   1.
-
-   Non-exportable, or "local", certifications are signatures made by a
-   user to mark a key as valid within that user's implementation only.
-   Thus, when an implementation prepares a user's copy of a key for
-   transport to another user (this is the process of "exporting" the
-   key), any local certification signatures are deleted from the key.
-
-   The receiver of a transported key "imports" it, and likewise trims
-   any local certifications. In normal operation, there won't be any,
-   assuming the import is performed on an exported key. However, there
-   are instances where this can reasonably happen. For example, if an
-   implementation allows keys to be imported from a key database in
-   addition to an exported key, then this situation can arise.
-
-   Some implementations do not represent the interest of a single user
-   (for example, a key server). Such implementations always trim local
-   certifications from any key they handle.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 26]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-5.2.3.11. Revocable
-
-   (1 octet of revocability, 0 for not, 1 for revocable)
-
-   Signature's revocability status.  Packet body contains a boolean flag
-   indicating whether the signature is revocable.  Signatures that are
-   not revocable have any later revocation signatures ignored.  They
-   represent a commitment by the signer that he cannot revoke his
-   signature for the life of his key.  If this packet is not present,
-   the signature is revocable.
-
-5.2.3.12. Trust signature
-
-   (1 octet "level" (depth), 1 octet of trust amount)
-
-   Signer asserts that the key is not only valid, but also trustworthy,
-   at the specified level.  Level 0 has the same meaning as an ordinary
-   validity signature.  Level 1 means that the signed key is asserted to
-   be a valid trusted introducer, with the 2nd octet of the body
-   specifying the degree of trust. Level 2 means that the signed key is
-   asserted to be trusted to issue level 1 trust signatures, i.e. that
-   it is a "meta introducer". Generally, a level n trust signature
-   asserts that a key is trusted to issue level n-1 trust signatures.
-   The trust amount is in a range from 0-255, interpreted such that
-   values less than 120 indicate partial trust and values of 120 or
-   greater indicate complete trust.  Implementations SHOULD emit values
-   of 60 for partial trust and 120 for complete trust.
-
-5.2.3.13. Regular expression
-
-   (null-terminated regular expression)
-
-   Used in conjunction with trust signature packets (of level > 0) to
-   limit the scope of trust that is extended.  Only signatures by the
-   target key on user IDs that match the regular expression in the body
-   of this packet have trust extended by the trust signature subpacket.
-   The regular expression uses the same syntax as the Henry Spencer's
-   "almost public domain" regular expression package. A description of
-   the syntax is found in a section below.
-
-5.2.3.14. Revocation key
-
-   (1 octet of class, 1 octet of algid, 20 octets of fingerprint)
-
-   Authorizes the specified key to issue revocation signatures for this
-   key.  Class octet must have bit 0x80 set. If the bit 0x40 is set,
-   then this means that the revocation information is sensitive.  Other
-   bits are for future expansion to other kinds of authorizations. This
-
-
-
-Callas, et. al.             Standards Track                    [Page 27]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   is found on a self-signature.
-
-   If the "sensitive" flag is set, the keyholder feels this subpacket
-   contains private trust information that describes a real-world
-   sensitive relationship. If this flag is set, implementations SHOULD
-   NOT export this signature to other users except in cases where the
-   data needs to be available: when the signature is being sent to the
-   designated revoker, or when it is accompanied by a revocation
-   signature from that revoker.  Note that it may be appropriate to
-   isolate this subpacket within a separate signature so that it is not
-   combined with other subpackets that need to be exported.
-
-5.2.3.15. Notation Data
-
-       (4 octets of flags, 2 octets of name length (M),
-                           2 octets of value length (N),
-                           M octets of name data,
-                           N octets of value data)
-
-   This subpacket describes a "notation" on the signature that the
-   issuer wishes to make. The notation has a name and a value, each of
-   which are strings of octets. There may be more than one notation in a
-   signature. Notations can be used for any extension the issuer of the
-   signature cares to make. The "flags" field holds four octets of
-   flags.
-
-   All undefined flags MUST be zero. Defined flags are:
-
-       First octet: 0x80 = human-readable. This note is text, a note
-                           from one person to another, and has no
-                           meaning to software.
-       Other octets: none.
-
-5.2.3.16. Key server preferences
-
-   (N octets of flags)
-
-   This is a list of flags that indicate preferences that the key holder
-   has about how the key is handled on a key server. All undefined flags
-   MUST be zero.
-
-   First octet: 0x80 = No-modify
-       the key holder requests that this key only be modified or updated
-       by the key holder or an administrator of the key server.
-
-   This is found only on a self-signature.
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 28]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-5.2.3.17. Preferred key server
-
-   (String)
-
-   This is a URL of a key server that the key holder prefers be used for
-   updates. Note that keys with multiple user ids can have a preferred
-   key server for each user id. Note also that since this is a URL, the
-   key server can actually be a copy of the key retrieved by ftp, http,
-   finger, etc.
-
-5.2.3.18. Primary user id
-
-   (1 octet, boolean)
-
-   This is a flag in a user id's self signature that states whether this
-   user id is the main user id for this key. It is reasonable for an
-   implementation to resolve ambiguities in preferences, etc. by
-   referring to the primary user id. If this flag is absent, its value
-   is zero. If more than one user id in a key is marked as primary, the
-   implementation may resolve the ambiguity in any way it sees fit.
-
-5.2.3.19. Policy URL
-
-   (String)
-
-   This subpacket contains a URL of a document that describes the policy
-   that the signature was issued under.
-
-5.2.3.20. Key Flags
-
-   (Octet string)
-
-   This subpacket contains a list of binary flags that hold information
-   about a key. It is a string of octets, and an implementation MUST NOT
-   assume a fixed size. This is so it can grow over time. If a list is
-   shorter than an implementation expects, the unstated flags are
-   considered to be zero. The defined flags are:
-
-       First octet:
-
-       0x01 - This key may be used to certify other keys.
-
-       0x02 - This key may be used to sign data.
-
-       0x04 - This key may be used to encrypt communications.
-
-       0x08 - This key may be used to encrypt storage.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 29]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-       0x10 - The private component of this key may have been split by a
-       secret-sharing mechanism.
-
-       0x80 - The private component of this key may be in the possession
-       of more than one person.
-
-   Usage notes:
-
-   The flags in this packet may appear in self-signatures or in
-   certification signatures. They mean different things depending on who
-   is making the statement -- for example, a certification signature
-   that has the "sign data" flag is stating that the certification is
-   for that use. On the other hand, the "communications encryption" flag
-   in a self-signature is stating a preference that a given key be used
-   for communications. Note however, that it is a thorny issue to
-   determine what is "communications" and what is "storage." This
-   decision is left wholly up to the implementation; the authors of this
-   document do not claim any special wisdom on the issue, and realize
-   that accepted opinion may change.
-
-   The "split key" (0x10) and "group key" (0x80) flags are placed on a
-   self-signature only; they are meaningless on a certification
-   signature. They SHOULD be placed only on a direct-key signature (type
-   0x1f) or a subkey signature (type 0x18), one that refers to the key
-   the flag applies to.
-
-5.2.3.21. Signer's User ID
-
-   This subpacket allows a keyholder to state which user id is
-   responsible for the signing. Many keyholders use a single key for
-   different purposes, such as business communications as well as
-   personal communications. This subpacket allows such a keyholder to
-   state which of their roles is making a signature.
-
-5.2.3.22. Reason for Revocation
-
-   (1 octet of revocation code, N octets of reason string)
-
-   This subpacket is used only in key revocation and certification
-   revocation signatures. It describes the reason why the key or
-   certificate was revoked.
-
-   The first octet contains a machine-readable code that denotes the
-   reason for the revocation:
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 30]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-       0x00 - No reason specified (key revocations or cert revocations)
-       0x01 - Key is superceded (key revocations)
-       0x02 - Key material has been compromised (key revocations)
-       0x03 - Key is no longer used (key revocations)
-       0x20 - User id information is no longer valid (cert revocations)
-
-   Following the revocation code is a string of octets which gives
-   information about the reason for revocation in human-readable form
-   (UTF-8). The string may be null, that is, of zero length. The length
-   of the subpacket is the length of the reason string plus one.
-
-5.2.4. Computing Signatures
-
-   All signatures are formed by producing a hash over the signature
-   data, and then using the resulting hash in the signature algorithm.
-
-   The signature data is simple to compute for document signatures
-   (types 0x00 and 0x01), for which the document itself is the data.
-   For standalone signatures, this is a null string.
-
-   When a signature is made over a key, the hash data starts with the
-   octet 0x99, followed by a two-octet length of the key, and then body
-   of the key packet. (Note that this is an old-style packet header for
-   a key packet with two-octet length.) A subkey signature (type 0x18)
-   then hashes the subkey, using the same format as the main key. Key
-   revocation signatures (types 0x20 and 0x28) hash only the key being
-   revoked.
-
-   A certification signature (type 0x10 through 0x13) hashes the user id
-   being bound to the key into the hash context after the above data. A
-   V3 certification hashes the contents of the name packet, without any
-   header. A V4 certification hashes the constant 0xb4 (which is an
-   old-style packet header with the length-of-length set to zero), a
-   four-octet number giving the length of the username, and then the
-   username data.
-
-   Once the data body is hashed, then a trailer is hashed. A V3
-   signature hashes five octets of the packet body, starting from the
-   signature type field. This data is the signature type, followed by
-   the four-octet signature time. A V4 signature hashes the packet body
-   starting from its first field, the version number, through the end of
-   the hashed subpacket data. Thus, the fields hashed are the signature
-   version, the signature type, the public key algorithm, the hash
-   algorithm, the hashed subpacket length, and the hashed subpacket
-   body.
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 31]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   V4 signatures also hash in a final trailer of six octets: the version
-   of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian
-   number that is the length of the hashed data from the signature
-   packet (note that this number does not include these final six
-   octets.
-
-   After all this has been hashed, the resulting hash field is used in
-   the signature algorithm, and placed at the end of the signature
-   packet.
-
-5.2.4.1. Subpacket Hints
-
-   An implementation SHOULD put the two mandatory subpackets, creation
-   time and issuer, as the first subpackets in the subpacket list,
-   simply to make it easier for the implementer to find them.
-
-   It is certainly possible for a signature to contain conflicting
-   information in subpackets. For example, a signature may contain
-   multiple copies of a preference or multiple expiration times. In most
-   cases, an implementation SHOULD use the last subpacket in the
-   signature, but MAY use any conflict resolution scheme that makes more
-   sense. Please note that we are intentionally leaving conflict
-   resolution to the implementer; most conflicts are simply syntax
-   errors, and the wishy-washy language here allows a receiver to be
-   generous in what they accept, while putting pressure on a creator to
-   be stingy in what they generate.
-
-   Some apparent conflicts may actually make sense -- for example,
-   suppose a keyholder has an V3 key and a V4 key that share the same
-   RSA key material. Either of these keys can verify a signature created
-   by the other, and it may be reasonable for a signature to contain an
-   issuer subpacket for each key, as a way of explicitly tying those
-   keys to the signature.
-
-5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3)
-
-   The Symmetric-Key Encrypted Session Key packet holds the symmetric-
-   key encryption of a session key used to encrypt a message.  Zero or
-   more Encrypted Session Key packets and/or Symmetric-Key Encrypted
-   Session Key packets may precede a Symmetrically Encrypted Data Packet
-   that holds an encrypted message.  The message is encrypted with a
-   session key, and the session key is itself encrypted and stored in
-   the Encrypted Session Key packet or the Symmetric-Key Encrypted
-   Session Key packet.
-
-   If the Symmetrically Encrypted Data Packet is preceded by one or more
-   Symmetric-Key Encrypted Session Key packets, each specifies a
-   passphrase that may be used to decrypt the message.  This allows a
-
-
-
-Callas, et. al.             Standards Track                    [Page 32]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   message to be encrypted to a number of public keys, and also to one
-   or more pass phrases. This packet type is new, and is not generated
-   by PGP 2.x or PGP 5.0.
-
-   The body of this packet consists of:
-
-     - A one-octet version number. The only currently defined version
-       is 4.
-
-     - A one-octet number describing the symmetric algorithm used.
-
-     - A string-to-key (S2K) specifier, length as defined above.
-
-     - Optionally, the encrypted session key itself, which is decrypted
-       with the string-to-key object.
-
-   If the encrypted session key is not present (which can be detected on
-   the basis of packet length and S2K specifier size), then the S2K
-   algorithm applied to the passphrase produces the session key for
-   decrypting the file, using the symmetric cipher algorithm from the
-   Symmetric-Key Encrypted Session Key packet.
-
-   If the encrypted session key is present, the result of applying the
-   S2K algorithm to the passphrase is used to decrypt just that
-   encrypted session key field, using CFB mode with an IV of all zeros.
-    The decryption result consists of a one-octet algorithm identifier
-   that specifies the symmetric-key encryption algorithm used to encrypt
-   the following Symmetrically Encrypted Data Packet, followed by the
-   session key octets themselves.
-
-   Note: because an all-zero IV is used for this decryption, the S2K
-   specifier MUST use a salt value, either a Salted S2K or an Iterated-
-   Salted S2K.  The salt value will insure that the decryption key is
-   not repeated even if the passphrase is reused.
-
-5.4. One-Pass Signature Packets (Tag 4)
-
-   The One-Pass Signature packet precedes the signed data and contains
-   enough information to allow the receiver to begin calculating any
-   hashes needed to verify the signature.  It allows the Signature
-   Packet to be placed at the end of the message, so that the signer can
-   compute the entire signed message in one pass.
-
-   A One-Pass Signature does not interoperate with PGP 2.6.x or earlier.
-
-   The body of this packet consists of:
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 33]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-     - A one-octet version number. The current version is 3.
-
-     - A one-octet signature type. Signature types are described in
-       section 5.2.1.
-
-     - A one-octet number describing the hash algorithm used.
-
-     - A one-octet number describing the public key algorithm used.
-
-     - An eight-octet number holding the key ID of the signing key.
-
-     - A one-octet number holding a flag showing whether the signature
-       is nested.  A zero value indicates that the next packet is
-       another One-Pass Signature packet that describes another
-       signature to be applied to the same message data.
-
-   Note that if a message contains more than one one-pass signature,
-   then the signature packets bracket the message; that is, the first
-   signature packet after the message corresponds to the last one-pass
-   packet and the final signature packet corresponds to the first one-
-   pass packet.
-
-5.5. Key Material Packet
-
-   A key material packet contains all the information about a public or
-   private key.  There are four variants of this packet type, and two
-   major versions. Consequently, this section is complex.
-
-5.5.1. Key Packet Variants
-
-5.5.1.1. Public Key Packet (Tag 6)
-
-   A Public Key packet starts a series of packets that forms an OpenPGP
-   key (sometimes called an OpenPGP certificate).
-
-5.5.1.2. Public Subkey Packet (Tag 14)
-
-   A Public Subkey packet (tag 14) has exactly the same format as a
-   Public Key packet, but denotes a subkey. One or more subkeys may be
-   associated with a top-level key.  By convention, the top-level key
-   provides signature services, and the subkeys provide encryption
-   services.
-
-   Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet.
-   This tag was selected for reuse because no previous version of PGP
-   ever emitted comment packets but they did properly ignore them.
-   Public Subkey packets are ignored by PGP 2.6.x and do not cause it to
-   fail, providing a limited degree of backward compatibility.
-
-
-
-Callas, et. al.             Standards Track                    [Page 34]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-5.5.1.3. Secret Key Packet (Tag 5)
-
-   A Secret Key packet contains all the information that is found in a
-   Public Key packet, including the public key material, but also
-   includes the secret key material after all the public key fields.
-
-5.5.1.4. Secret Subkey Packet (Tag 7)
-
-   A Secret Subkey packet (tag 7) is the subkey analog of the Secret Key
-   packet, and has exactly the same format.
-
-5.5.2. Public Key Packet Formats
-
-   There are two versions of key-material packets. Version 3 packets
-   were first generated by PGP 2.6. Version 2 packets are identical in
-   format to Version 3 packets, but are generated by PGP 2.5 or before.
-   V2 packets are deprecated and they MUST NOT be generated.  PGP 5.0
-   introduced version 4 packets, with new fields and semantics.  PGP
-   2.6.x will not accept key-material packets with versions greater than
-   3.
-
-   OpenPGP implementations SHOULD create keys with version 4 format. An
-   implementation MAY generate a V3 key to ensure interoperability with
-   old software; note, however, that V4 keys correct some security
-   deficiencies in V3 keys. These deficiencies are described below. An
-   implementation MUST NOT create a V3 key with a public key algorithm
-   other than RSA.
-
-   A version 3 public key or public subkey packet contains:
-
-     - A one-octet version number (3).
-
-     - A four-octet number denoting the time that the key was created.
-
-     - A two-octet number denoting the time in days that this key is
-       valid. If this number is zero, then it does not expire.
-
-     - A one-octet number denoting the public key algorithm of this key
-
-     - A series of multi-precision integers comprising the key
-       material:
-
-         - a multiprecision integer (MPI) of RSA public modulus n;
-
-         - an MPI of RSA public encryption exponent e.
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 35]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   V3 keys SHOULD only be used for backward compatibility because of
-   three weaknesses in them. First, it is relatively easy to construct a
-   V3 key that has the same key ID as any other key because the key ID
-   is simply the low 64 bits of the public modulus. Secondly, because
-   the fingerprint of a V3 key hashes the key material, but not its
-   length, which increases the opportunity for fingerprint collisions.
-   Third, there are minor weaknesses in the MD5 hash algorithm that make
-   developers prefer other algorithms. See below for a fuller discussion
-   of key IDs and fingerprints.
-
-   The version 4 format is similar to the version 3 format except for
-   the absence of a validity period.  This has been moved to the
-   signature packet.  In addition, fingerprints of version 4 keys are
-   calculated differently from version 3 keys, as described in section
-   "Enhanced Key Formats."
-
-   A version 4 packet contains:
-
-     - A one-octet version number (4).
-
-     - A four-octet number denoting the time that the key was created.
-
-     - A one-octet number denoting the public key algorithm of this key
-
-     - A series of multi-precision integers comprising the key
-       material.  This algorithm-specific portion is:
-
-       Algorithm Specific Fields for RSA public keys:
-
-         - multiprecision integer (MPI) of RSA public modulus n;
-
-         - MPI of RSA public encryption exponent e.
-
-       Algorithm Specific Fields for DSA public keys:
-
-         - MPI of DSA prime p;
-
-         - MPI of DSA group order q (q is a prime divisor of p-1);
-
-         - MPI of DSA group generator g;
-
-         - MPI of DSA public key value y (= g**x where x is secret).
-
-       Algorithm Specific Fields for Elgamal public keys:
-
-         - MPI of Elgamal prime p;
-
-         - MPI of Elgamal group generator g;
-
-
-
-Callas, et. al.             Standards Track                    [Page 36]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-         - MPI of Elgamal public key value y (= g**x where x is
-           secret).
-
-5.5.3. Secret Key Packet Formats
-
-   The Secret Key and Secret Subkey packets contain all the data of the
-   Public Key and Public Subkey packets, with additional algorithm-
-   specific secret key data appended, in encrypted form.
-
-   The packet contains:
-
-     - A Public Key or Public Subkey packet, as described above
-
-     - One octet indicating string-to-key usage conventions.  0
-       indicates that the secret key data is not encrypted.  255
-       indicates that a string-to-key specifier is being given.  Any
-       other value is a symmetric-key encryption algorithm specifier.
-
-     - [Optional] If string-to-key usage octet was 255, a one-octet
-       symmetric encryption algorithm.
-
-     - [Optional] If string-to-key usage octet was 255, a string-to-key
-       specifier.  The length of the string-to-key specifier is implied
-       by its type, as described above.
-
-     - [Optional] If secret data is encrypted, eight-octet Initial
-       Vector (IV).
-
-     - Encrypted multi-precision integers comprising the secret key
-       data. These algorithm-specific fields are as described below.
-
-     - Two-octet checksum of the plaintext of the algorithm-specific
-       portion (sum of all octets, mod 65536).
-
-       Algorithm Specific Fields for RSA secret keys:
-
-       - multiprecision integer (MPI) of RSA secret exponent d.
-
-       - MPI of RSA secret prime value p.
-
-       - MPI of RSA secret prime value q (p < q).
-
-       - MPI of u, the multiplicative inverse of p, mod q.
-
-       Algorithm Specific Fields for DSA secret keys:
-
-       - MPI of DSA secret exponent x.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 37]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-       Algorithm Specific Fields for Elgamal secret keys:
-
-       - MPI of Elgamal secret exponent x.
-
-   Secret MPI values can be encrypted using a passphrase.  If a string-
-   to-key specifier is given, that describes the algorithm for
-   converting the passphrase to a key, else a simple MD5 hash of the
-   passphrase is used.  Implementations SHOULD use a string-to-key
-   specifier; the simple hash is for backward compatibility. The cipher
-   for encrypting the MPIs is specified in the secret key packet.
-
-   Encryption/decryption of the secret data is done in CFB mode using
-   the key created from the passphrase and the Initial Vector from the
-   packet. A different mode is used with V3 keys (which are only RSA)
-   than with other key formats. With V3 keys, the MPI bit count prefix
-   (i.e., the first two octets) is not encrypted.  Only the MPI non-
-   prefix data is encrypted.  Furthermore, the CFB state is
-   resynchronized at the beginning of each new MPI value, so that the
-   CFB block boundary is aligned with the start of the MPI data.
-
-   With V4 keys, a simpler method is used.  All secret MPI values are
-   encrypted in CFB mode, including the MPI bitcount prefix.
-
-   The 16-bit checksum that follows the algorithm-specific portion is
-   the algebraic sum, mod 65536, of the plaintext of all the algorithm-
-   specific octets (including MPI prefix and data).  With V3 keys, the
-   checksum is stored in the clear.  With V4 keys, the checksum is
-   encrypted like the algorithm-specific data.  This value is used to
-   check that the passphrase was correct.
-
-5.6. Compressed Data Packet (Tag 8)
-
-   The Compressed Data packet contains compressed data. Typically, this
-   packet is found as the contents of an encrypted packet, or following
-   a Signature or One-Pass Signature packet, and contains literal data
-   packets.
-
-   The body of this packet consists of:
-
-     - One octet that gives the algorithm used to compress the packet.
-
-     - The remainder of the packet is compressed data.
-
-   A Compressed Data Packet's body contains an block that compresses
-   some set of packets. See section "Packet Composition" for details on
-   how messages are formed.
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 38]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   ZIP-compressed packets are compressed with raw RFC 1951 DEFLATE
-   blocks. Note that PGP V2.6 uses 13 bits of compression. If an
-   implementation uses more bits of compression, PGP V2.6 cannot
-   decompress it.
-
-   ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style
-   blocks.
-
-5.7. Symmetrically Encrypted Data Packet (Tag 9)
-
-   The Symmetrically Encrypted Data packet contains data encrypted with
-   a symmetric-key algorithm. When it has been decrypted, it will
-   typically contain other packets (often literal data packets or
-   compressed data packets).
-
-   The body of this packet consists of:
-
-     - Encrypted data, the output of the selected symmetric-key cipher
-       operating in PGP's variant of Cipher Feedback (CFB) mode.
-
-   The symmetric cipher used may be specified in an Public-Key or
-   Symmetric-Key Encrypted Session Key packet that precedes the
-   Symmetrically Encrypted Data Packet.  In that case, the cipher
-   algorithm octet is prefixed to the session key before it is
-   encrypted.  If no packets of these types precede the encrypted data,
-   the IDEA algorithm is used with the session key calculated as the MD5
-   hash of the passphrase.
-
-   The data is encrypted in CFB mode, with a CFB shift size equal to the
-   cipher's block size.  The Initial Vector (IV) is specified as all
-   zeros.  Instead of using an IV, OpenPGP prefixes a 10-octet string to
-   the data before it is encrypted.  The first eight octets are random,
-   and the 9th and 10th octets are copies of the 7th and 8th octets,
-   respectively. After encrypting the first 10 octets, the CFB state is
-   resynchronized if the cipher block size is 8 octets or less.  The
-   last 8 octets of ciphertext are passed through the cipher and the
-   block boundary is reset.
-
-   The repetition of 16 bits in the 80 bits of random data prefixed to
-   the message allows the receiver to immediately check whether the
-   session key is incorrect.
-
-5.8. Marker Packet (Obsolete Literal Packet) (Tag 10)
-
-   An experimental version of PGP used this packet as the Literal
-   packet, but no released version of PGP generated Literal packets with
-   this tag. With PGP 5.x, this packet has been re-assigned and is
-   reserved for use as the Marker packet.
-
-
-
-Callas, et. al.             Standards Track                    [Page 39]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   The body of this packet consists of:
-
-     - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
-
-   Such a packet MUST be ignored when received.  It may be placed at the
-   beginning of a message that uses features not available in PGP 2.6.x
-   in order to cause that version to report that newer software is
-   necessary to process the message.
-
-5.9. Literal Data Packet (Tag 11)
-
-   A Literal Data packet contains the body of a message; data that is
-   not to be further interpreted.
-
-   The body of this packet consists of:
-
-     - A one-octet field that describes how the data is formatted.
-
-   If it is a 'b' (0x62), then the literal packet contains binary data.
-   If it is a 't' (0x74), then it contains text data, and thus may need
-   line ends converted to local form, or other text-mode changes.  RFC
-   1991 also defined a value of 'l' as a 'local' mode for machine-local
-   conversions.  This use is now deprecated.
-
-     - File name as a string (one-octet length, followed by file name),
-       if the encrypted data should be saved as a file.
-
-   If the special name "_CONSOLE" is used, the message is considered to
-   be "for your eyes only".  This advises that the message data is
-   unusually sensitive, and the receiving program should process it more
-   carefully, perhaps avoiding storing the received data to disk, for
-   example.
-
-     - A four-octet number that indicates the modification date of the
-       file, or the creation time of the packet, or a zero that
-       indicates the present time.
-
-     - The remainder of the packet is literal data.
-
-   Text data is stored with <CR><LF> text endings (i.e. network-normal
-   line endings).  These should be converted to native line endings by
-   the receiving software.
-
-5.10. Trust Packet (Tag 12)
-
-   The Trust packet is used only within keyrings and is not normally
-   exported.  Trust packets contain data that record the user's
-   specifications of which key holders are trustworthy introducers,
-
-
-
-Callas, et. al.             Standards Track                    [Page 40]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   along with other information that implementing software uses for
-   trust information.
-
-   Trust packets SHOULD NOT be emitted to output streams that are
-   transferred to other users, and they SHOULD be ignored on any input
-   other than local keyring files.
-
-5.11. User ID Packet (Tag 13)
-
-   A User ID packet consists of data that is intended to represent the
-   name and email address of the key holder.  By convention, it includes
-   an RFC 822 mail name, but there are no restrictions on its content.
-   The packet length in the header specifies the length of the user id.
-   If it is text, it is encoded in UTF-8.
-
-6. Radix-64 Conversions
-
-   As stated in the introduction, OpenPGP's underlying native
-   representation for objects is a stream of arbitrary octets, and some
-   systems desire these objects to be immune to damage caused by
-   character set translation, data conversions, etc.
-
-   In principle, any printable encoding scheme that met the requirements
-   of the unsafe channel would suffice, since it would not change the
-   underlying binary bit streams of the native OpenPGP data structures.
-   The OpenPGP standard specifies one such printable encoding scheme to
-   ensure interoperability.
-
-   OpenPGP's Radix-64 encoding is composed of two parts: a base64
-   encoding of the binary data, and a checksum.  The base64 encoding is
-   identical to the MIME base64 content-transfer-encoding [RFC2231,
-   Section 6.8]. An OpenPGP implementation MAY use ASCII Armor to
-   protect the raw binary data.
-
-   The checksum is a 24-bit CRC converted to four characters of radix-64
-   encoding by the same MIME base64 transformation, preceded by an
-   equals sign (=).  The CRC is computed by using the generator 0x864CFB
-   and an initialization of 0xB704CE.  The accumulation is done on the
-   data before it is converted to radix-64, rather than on the converted
-   data.  A sample implementation of this algorithm is in the next
-   section.
-
-   The checksum with its leading equal sign MAY appear on the first line
-   after the Base64 encoded data.
-
-   Rationale for CRC-24: The size of 24 bits fits evenly into printable
-   base64.  The nonzero initialization can detect more errors than a
-   zero initialization.
-
-
-
-Callas, et. al.             Standards Track                    [Page 41]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-6.1. An Implementation of the CRC-24 in "C"
-
-       #define CRC24_INIT 0xb704ceL
-       #define CRC24_POLY 0x1864cfbL
-
-       typedef long crc24;
-       crc24 crc_octets(unsigned char *octets, size_t len)
-       {
-           crc24 crc = CRC24_INIT;
-           int i;
-
-           while (len--) {
-               crc ^= (*octets++) << 16;
-               for (i = 0; i < 8; i++) {
-                   crc <<= 1;
-                   if (crc & 0x1000000)
-                       crc ^= CRC24_POLY;
-               }
-           }
-           return crc & 0xffffffL;
-       }
-
-6.2. Forming ASCII Armor
-
-   When OpenPGP encodes data into ASCII Armor, it puts specific headers
-   around the data, so OpenPGP can reconstruct the data later. OpenPGP
-   informs the user what kind of data is encoded in the ASCII armor
-   through the use of the headers.
-
-   Concatenating the following data creates ASCII Armor:
-
-     - An Armor Header Line, appropriate for the type of data
-
-     - Armor Headers
-
-     - A blank (zero-length, or containing only whitespace) line
-
-     - The ASCII-Armored data
-
-     - An Armor Checksum
-
-     - The Armor Tail, which depends on the Armor Header Line.
-
-   An Armor Header Line consists of the appropriate header line text
-   surrounded by five (5) dashes ('-', 0x2D) on either side of the
-   header line text.  The header line text is chosen based upon the type
-   of data that is being encoded in Armor, and how it is being encoded.
-   Header line texts include the following strings:
-
-
-
-Callas, et. al.             Standards Track                    [Page 42]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   BEGIN PGP MESSAGE
-       Used for signed, encrypted, or compressed files.
-
-   BEGIN PGP PUBLIC KEY BLOCK
-       Used for armoring public keys
-
-   BEGIN PGP PRIVATE KEY BLOCK
-       Used for armoring private keys
-
-   BEGIN PGP MESSAGE, PART X/Y
-       Used for multi-part messages, where the armor is split amongst Y
-       parts, and this is the Xth part out of Y.
-
-   BEGIN PGP MESSAGE, PART X
-       Used for multi-part messages, where this is the Xth part of an
-       unspecified number of parts. Requires the MESSAGE-ID Armor Header
-       to be used.
-
-   BEGIN PGP SIGNATURE
-       Used for detached signatures, OpenPGP/MIME signatures, and
-       natures following clearsigned messages. Note that PGP 2.x s BEGIN
-       PGP MESSAGE for detached signatures.
-
-   The Armor Headers are pairs of strings that can give the user or the
-   receiving OpenPGP implementation some information about how to decode
-   or use the message.  The Armor Headers are a part of the armor, not a
-   part of the message, and hence are not protected by any signatures
-   applied to the message.
-
-   The format of an Armor Header is that of a key-value pair.  A colon
-   (':' 0x38) and a single space (0x20) separate the key and value.
-   OpenPGP should consider improperly formatted Armor Headers to be
-   corruption of the ASCII Armor.  Unknown keys should be reported to
-   the user, but OpenPGP should continue to process the message.
-
-   Currently defined Armor Header Keys are:
-
-     - "Version", that states the OpenPGP Version used to encode the
-       message.
-
-     - "Comment", a user-defined comment.
-
-     - "MessageID", a 32-character string of printable characters.  The
-       string must be the same for all parts of a multi-part message
-       that uses the "PART X" Armor Header.  MessageID strings should be
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 43]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-       unique enough that the recipient of the mail can associate all
-       the parts of a message with each other. A good checksum or
-       cryptographic hash function is sufficient.
-
-     - "Hash", a comma-separated list of hash algorithms used in this
-       message. This is used only in clear-signed messages.
-
-     - "Charset", a description of the character set that the plaintext
-       is in. Please note that OpenPGP defines text to be in UTF-8 by
-       default. An implementation will get best results by translating
-       into and out of UTF-8. However, there are many instances where
-       this is easier said than done. Also, there are communities of
-       users who have no need for UTF-8 because they are all happy with
-       a character set like ISO Latin-5 or a Japanese character set. In
-       such instances, an implementation MAY override the UTF-8 default
-       by using this header key. An implementation MAY implement this
-       key and any translations it cares to; an implementation MAY
-       ignore it and assume all text is UTF-8.
-
-       The MessageID SHOULD NOT appear unless it is in a multi-part
-       message. If it appears at all, it MUST be computed from the
-       finished (encrypted, signed, etc.) message in a deterministic
-       fashion, rather than contain a purely random value.  This is to
-       allow the legitimate recipient to determine that the MessageID
-       cannot serve as a covert means of leaking cryptographic key
-       information.
-
-   The Armor Tail Line is composed in the same manner as the Armor
-   Header Line, except the string "BEGIN" is replaced by the string
-   "END."
-
-6.3. Encoding Binary in Radix-64
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters. Proceeding from left to right, a
-   24-bit input group is formed by concatenating three 8-bit input
-   groups. These 24 bits are then treated as four concatenated 6-bit
-   groups, each of which is translated into a single digit in the
-   Radix-64 alphabet. When encoding a bit stream with the Radix-64
-   encoding, the bit stream must be presumed to be ordered with the
-   most-significant-bit first. That is, the first bit in the stream will
-   be the high-order bit in the first 8-bit octet, and the eighth bit
-   will be the low-order bit in the first 8-bit octet, and so on.
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 44]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-         +--first octet--+-second octet--+--third octet--+
-         |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
-         +-----------+---+-------+-------+---+-----------+
-         |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
-         +--1.index--+--2.index--+--3.index--+--4.index--+
-
-   Each 6-bit group is used as an index into an array of 64 printable
-   characters from the table below. The character referenced by the
-   index is placed in the output string.
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A            17 R            34 i            51 z
-         1 B            18 S            35 j            52 0
-         2 C            19 T            36 k            53 1
-         3 D            20 U            37 l            54 2
-         4 E            21 V            38 m            55 3
-         5 F            22 W            39 n            56 4
-         6 G            23 X            40 o            57 5
-         7 H            24 Y            41 p            58 6
-         8 I            25 Z            42 q            59 7
-         9 J            26 a            43 r            60 8
-        10 K            27 b            44 s            61 9
-        11 L            28 c            45 t            62 +
-        12 M            29 d            46 u            63 /
-        13 N            30 e            47 v
-        14 O            31 f            48 w         (pad) =
-        15 P            32 g            49 x
-        16 Q            33 h            50 y
-
-   The encoded output stream must be represented in lines of no more
-   than 76 characters each.
-
-   Special processing is performed if fewer than 24 bits are available
-   at the end of the data being encoded. There are three possibilities:
-
-    1. The last data group has 24 bits (3 octets). No special
-       processing is needed.
-
-    2. The last data group has 16 bits (2 octets). The first two 6-bit
-       groups are processed as above. The third (incomplete) data group
-       has two zero-value bits added to it, and is processed as above.
-       A pad character (=) is added to the output.
-
-    3. The last data group has 8 bits (1 octet). The first 6-bit group
-       is processed as above. The second (incomplete) data group has
-       four zero-value bits added to it, and is processed as above. Two
-       pad characters (=) are added to the output.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 45]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-6.4. Decoding Radix-64
-
-   Any characters outside of the base64 alphabet are ignored in Radix-64
-   data. Decoding software must ignore all line breaks or other
-   characters not found in the table above.
-
-   In Radix-64 data, characters other than those in the table, line
-   breaks, and other white space probably indicate a transmission error,
-   about which a warning message or even a message rejection might be
-   appropriate under some circumstances.
-
-   Because it is used only for padding at the end of the data, the
-   occurrence of any "=" characters may be taken as evidence that the
-   end of the data has been reached (without truncation in transit). No
-   such assurance is possible, however, when the number of octets
-   transmitted was a multiple of three and no "=" characters are
-   present.
-
-6.5. Examples of Radix-64
-
-       Input data:  0x14fb9c03d97e
-       Hex:     1   4    f   b    9   c     | 0   3    d   9    7   e
-       8-bit:   00010100 11111011 10011100  | 00000011 11011001
-       11111110
-       6-bit:   000101 001111 101110 011100 | 000000 111101 100111
-       111110
-       Decimal: 5      15     46     28       0      61     37     62
-       Output:  F      P      u      c        A      9      l      +
-
-       Input data:  0x14fb9c03d9
-       Hex:     1   4    f   b    9   c     | 0   3    d   9
-       8-bit:   00010100 11111011 10011100  | 00000011 11011001
-                                                       pad with 00
-       6-bit:   000101 001111 101110 011100 | 000000 111101 100100
-       Decimal: 5      15     46     28       0      61     36
-                                                          pad with =
-       Output:  F      P      u      c        A      9      k      =
-
-       Input data:  0x14fb9c03
-       Hex:     1   4    f   b    9   c     | 0   3
-       8-bit:   00010100 11111011 10011100  | 00000011
-                                              pad with 0000
-       6-bit:   000101 001111 101110 011100 | 000000 110000
-       Decimal: 5      15     46     28       0      48
-                                                   pad with =      =
-       Output:  F      P      u      c        A      w      =      =
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 46]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-6.6. Example of an ASCII Armored Message
-
-
-  -----BEGIN PGP MESSAGE-----
-  Version: OpenPrivacy 0.99
-
-  yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
-  vBSFjNSiVHsuAA==
-  =njUN
-  -----END PGP MESSAGE-----
-
-   Note that this example is indented by two spaces.
-
-7. Cleartext signature framework
-
-   It is desirable to sign a textual octet stream without ASCII armoring
-   the stream itself, so the signed text is still readable without
-   special software. In order to bind a signature to such a cleartext,
-   this framework is used.  (Note that RFC 2015 defines another way to
-   clear sign messages for environments that support MIME.)
-
-   The cleartext signed message consists of:
-
-     - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
-       single line,
-
-     - One or more "Hash" Armor Headers,
-
-     - Exactly one empty line not included into the message digest,
-
-     - The dash-escaped cleartext that is included into the message
-       digest,
-
-     - The ASCII armored signature(s) including the '-----BEGIN PGP
-       SIGNATURE-----' Armor Header and Armor Tail Lines.
-
-   If the "Hash" armor header is given, the specified message digest
-   algorithm is used for the signature. If there are no such headers,
-   MD5 is used, an implementation MAY omit them for V2.x compatibility.
-   If more than one message digest is used in the signature, the "Hash"
-   armor header contains a comma-delimited list of used message digests.
-
-   Current message digest names are described below with the algorithm
-   IDs.
-
-7.1. Dash-Escaped Text
-
-   The cleartext content of the message must also be dash-escaped.
-
-
-
-Callas, et. al.             Standards Track                    [Page 47]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   Dash escaped cleartext is the ordinary cleartext where every line
-   starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
-   (0x2D) and space ' ' (0x20). This prevents the parser from
-   recognizing armor headers of the cleartext itself. The message digest
-   is computed using the cleartext itself, not the dash escaped form.
-
-   As with binary signatures on text documents, a cleartext signature is
-   calculated on the text using canonical <CR><LF> line endings.  The
-   line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
-   SIGNATURE-----' line that terminates the signed text is not
-   considered part of the signed text.
-
-   Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
-   any line is ignored when the cleartext signature is calculated.
-
-8. Regular Expressions
-
-   A regular expression is zero or more branches, separated by '|'. It
-   matches anything that matches one of the branches.
-
-   A branch is zero or more pieces, concatenated. It matches a match for
-   the first, followed by a match for the second, etc.
-
-   A piece is an atom possibly followed by '*', '+', or '?'. An atom
-   followed by '*' matches a sequence of 0 or more matches of the atom.
-   An atom followed by '+' matches a sequence of 1 or more matches of
-   the atom. An atom followed by '?' matches a match of the atom, or the
-   null string.
-
-   An atom is a regular expression in parentheses (matching a match for
-   the regular expression), a range (see below), '.' (matching any
-   single character), '^' (matching the null string at the beginning of
-   the input string), '$' (matching the null string at the end of the
-   input string), a '\' followed by a single character (matching that
-   character), or a single character with no other significance
-   (matching that character).
-
-   A range is a sequence of characters enclosed in '[]'. It normally
-   matches any single character from the sequence. If the sequence
-   begins with '^', it matches any single character not from the rest of
-   the sequence. If two characters in the sequence are separated by '-',
-   this is shorthand for the full list of ASCII characters between them
-   (e.g. '[0-9]' matches any decimal digit). To include a literal ']' in
-   the sequence, make it the first character (following a possible '^').
-   To include a literal '-', make it the first or last character.
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 48]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-9. Constants
-
-   This section describes the constants used in OpenPGP.
-
-   Note that these tables are not exhaustive lists; an implementation
-   MAY implement an algorithm not on these lists.
-
-   See the section "Notes on Algorithms" below for more discussion of
-   the algorithms.
-
-9.1. Public Key Algorithms
-
-       ID           Algorithm
-       --           ---------
-       1          - RSA (Encrypt or Sign)
-       2          - RSA Encrypt-Only
-       3          - RSA Sign-Only
-       16         - Elgamal (Encrypt-Only), see [ELGAMAL]
-       17         - DSA (Digital Signature Standard)
-       18         - Reserved for Elliptic Curve
-       19         - Reserved for ECDSA
-       20         - Elgamal (Encrypt or Sign)
-
-
-
-
-
-       21         - Reserved for Diffie-Hellman (X9.42,
-                    as defined for IETF-S/MIME)
-       100 to 110 - Private/Experimental algorithm.
-
-   Implementations MUST implement DSA for signatures, and Elgamal for
-   encryption. Implementations SHOULD implement RSA keys.
-   Implementations MAY implement any other algorithm.
-
-9.2. Symmetric Key Algorithms
-
-       ID           Algorithm
-       --           ---------
-       0          - Plaintext or unencrypted data
-       1          - IDEA [IDEA]
-       2          - Triple-DES (DES-EDE, as per spec -
-                    168 bit key derived from 192)
-       3          - CAST5 (128 bit key, as per RFC 2144)
-       4          - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
-       5          - SAFER-SK128 (13 rounds) [SAFER]
-       6          - Reserved for DES/SK
-       7          - Reserved for AES with 128-bit key
-
-
-
-Callas, et. al.             Standards Track                    [Page 49]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-       8          - Reserved for AES with 192-bit key
-       9          - Reserved for AES with 256-bit key
-       100 to 110 - Private/Experimental algorithm.
-
-   Implementations MUST implement Triple-DES. Implementations SHOULD
-   implement IDEA and CAST5.Implementations MAY implement any other
-   algorithm.
-
-9.3. Compression Algorithms
-
-       ID           Algorithm
-       --           ---------
-       0          - Uncompressed
-       1          - ZIP (RFC 1951)
-       2          - ZLIB (RFC 1950)
-       100 to 110 - Private/Experimental algorithm.
-
-   Implementations MUST implement uncompressed data. Implementations
-   SHOULD implement ZIP. Implementations MAY implement ZLIB.
-
-9.4. Hash Algorithms
-
-       ID           Algorithm                              Text Name
-       --           ---------                              ---- ----
-       1          - MD5                                    "MD5"
-       2          - SHA-1                                  "SHA1"
-       3          - RIPE-MD/160                            "RIPEMD160"
-       4          - Reserved for double-width SHA (experimental)
-       5          - MD2                                    "MD2"
-       6          - Reserved for TIGER/192                 "TIGER192"
-       7          - Reserved for HAVAL (5 pass, 160-bit)
-       "HAVAL-5-160"
-       100 to 110 - Private/Experimental algorithm.
-
-   Implementations MUST implement SHA-1. Implementations SHOULD
-   implement MD5.
-
-10. Packet Composition
-
-   OpenPGP packets are assembled into sequences in order to create
-   messages and to transfer keys.  Not all possible packet sequences are
-   meaningful and correct.  This describes the rules for how packets
-   should be placed into sequences.
-
-10.1. Transferable Public Keys
-
-   OpenPGP users may transfer public keys. The essential elements of a
-   transferable public key are:
-
-
-
-Callas, et. al.             Standards Track                    [Page 50]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-     - One Public Key packet
-
-     - Zero or more revocation signatures
-
-     - One or more User ID packets
-
-     - After each User ID packet, zero or more signature packets
-       (certifications)
-
-     - Zero or more Subkey packets
-
-     - After each Subkey packet, one signature packet, optionally a
-       revocation.
-
-   The Public Key packet occurs first.  Each of the following User ID
-   packets provides the identity of the owner of this public key.  If
-   there are multiple User ID packets, this corresponds to multiple
-   means of identifying the same unique individual user; for example, a
-   user may have more than one email address, and construct a User ID
-   for each one.
-
-   Immediately following each User ID packet, there are zero or more
-   signature packets. Each signature packet is calculated on the
-   immediately preceding User ID packet and the initial Public Key
-   packet. The signature serves to certify the corresponding public key
-   and user ID.  In effect, the signer is testifying to his or her
-   belief that this public key belongs to the user identified by this
-   user ID.
-
-   After the User ID packets there may be one or more Subkey packets.
-   In general, subkeys are provided in cases where the top-level public
-   key is a signature-only key.  However, any V4 key may have subkeys,
-   and the subkeys may be encryption-only keys, signature-only keys, or
-   general-purpose keys.
-
-   Each Subkey packet must be followed by one Signature packet, which
-   should be a subkey binding signature issued by the top level key.
-
-   Subkey and Key packets may each be followed by a revocation Signature
-   packet to indicate that the key is revoked.  Revocation signatures
-   are only accepted if they are issued by the key itself, or by a key
-   that is authorized to issue revocations via a revocation key
-   subpacket in a self-signature by the top level key.
-
-   Transferable public key packet sequences may be concatenated to allow
-   transferring multiple public keys in one operation.
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 51]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-10.2. OpenPGP Messages
-
-   An OpenPGP message is a packet or sequence of packets that
-   corresponds to the following grammatical rules (comma represents
-   sequential composition, and vertical bar separates alternatives):
-
-   OpenPGP Message :- Encrypted Message | Signed Message |
-                      Compressed Message | Literal Message.
-
-   Compressed Message :- Compressed Data Packet.
-
-   Literal Message :- Literal Data Packet.
-
-   ESK :- Public Key Encrypted Session Key Packet |
-          Symmetric-Key Encrypted Session Key Packet.
-
-   ESK Sequence :- ESK | ESK Sequence, ESK.
-
-   Encrypted Message :- Symmetrically Encrypted Data Packet |
-               ESK Sequence, Symmetrically Encrypted Data Packet.
-
-   One-Pass Signed Message :- One-Pass Signature Packet,
-               OpenPGP Message, Corresponding Signature Packet.
-
-   Signed Message :- Signature Packet, OpenPGP Message |
-               One-Pass Signed Message.
-
-   In addition, decrypting a Symmetrically Encrypted Data packet and
-
-   decompressing a Compressed Data packet must yield a valid OpenPGP
-   Message.
-
-10.3. Detached Signatures
-
-   Some OpenPGP applications use so-called "detached signatures." For
-   example, a program bundle may contain a file, and with it a second
-   file that is a detached signature of the first file. These detached
-   signatures are simply a signature packet stored separately from the
-   data that they are a signature of.
-
-11. Enhanced Key Formats
-
-11.1. Key Structures
-
-   The format of an OpenPGP V3 key is as follows.  Entries in square
-   brackets are optional and ellipses indicate repetition.
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 52]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-           RSA Public Key
-              [Revocation Self Signature]
-               User ID [Signature ...]
-              [User ID [Signature ...] ...]
-
-   Each signature certifies the RSA public key and the preceding user
-   ID. The RSA public key can have many user IDs and each user ID can
-   have many signatures.
-
-   The format of an OpenPGP V4 key that uses two public keys is similar
-   except that the other keys are added to the end as 'subkeys' of the
-   primary key.
-
-           Primary-Key
-              [Revocation Self Signature]
-              [Direct Key Self Signature...]
-               User ID [Signature ...]
-              [User ID [Signature ...] ...]
-              [[Subkey [Binding-Signature-Revocation]
-                      Primary-Key-Binding-Signature] ...]
-
-   A subkey always has a single signature after it that is issued using
-   the primary key to tie the two keys together.  This binding signature
-   may be in either V3 or V4 format, but V4 is preferred, of course.
-
-   In the above diagram, if the binding signature of a subkey has been
-   revoked, the revoked binding signature may be removed, leaving only
-   one signature.
-
-   In a key that has a main key and subkeys, the primary key MUST be a
-   key capable of signing. The subkeys may be keys of any other type.
-   There may be other constructions of V4 keys, too. For example, there
-   may be a single-key RSA key in V4 format, a DSA primary key with an
-   RSA encryption key, or RSA primary key with an Elgamal subkey, etc.
-
-   It is also possible to have a signature-only subkey. This permits a
-   primary key that collects certifications (key signatures) but is used
-   only used for certifying subkeys that are used for encryption and
-   signatures.
-
-11.2. Key IDs and Fingerprints
-
-   For a V3 key, the eight-octet key ID consists of the low 64 bits of
-   the public modulus of the RSA key.
-
-   The fingerprint of a V3 key is formed by hashing the body (but not
-   the two-octet length) of the MPIs that form the key material (public
-   modulus n, followed by exponent e) with MD5.
-
-
-
-Callas, et. al.             Standards Track                    [Page 53]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
-   Tag, followed by the two-octet packet length, followed by the entire
-   Public Key packet starting with the version field.  The key ID is the
-   low order 64 bits of the fingerprint.  Here are the fields of the
-   hash material, with the example of a DSA key:
-
-  a.1) 0x99 (1 octet)
-
-  a.2) high order length octet of (b)-(f) (1 octet)
-
-  a.3) low order length octet of (b)-(f) (1 octet)
-
-    b) version number = 4 (1 octet);
-
-    c) time stamp of key creation (4 octets);
-
-    d) algorithm (1 octet): 17 = DSA (example);
-
-    e) Algorithm specific fields.
-
-   Algorithm Specific Fields for DSA keys (example):
-
-  e.1) MPI of DSA prime p;
-
-  e.2) MPI of DSA group order q (q is a prime divisor of p-1);
-
-  e.3) MPI of DSA group generator g;
-
-  e.4) MPI of DSA public key value y (= g**x where x is secret).
-
-   Note that it is possible for there to be collisions of key IDs -- two
-   different keys with the same key ID. Note that there is a much
-   smaller, but still non-zero probability that two different keys have
-   the same fingerprint.
-
-   Also note that if V3 and V4 format keys share the same RSA key
-   material, they will have different key ids as well as different
-   fingerprints.
-
-12. Notes on Algorithms
-
-12.1. Symmetric Algorithm Preferences
-
-   The symmetric algorithm preference is an ordered list of algorithms
-   that the keyholder accepts. Since it is found on a self-signature, it
-   is possible that a keyholder may have different preferences. For
-   example, Alice may have TripleDES only specified for "alice@work.com"
-   but CAST5, Blowfish, and TripleDES specified for "alice@home.org".
-
-
-
-Callas, et. al.             Standards Track                    [Page 54]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   Note that it is also possible for preferences to be in a subkey's
-   binding signature.
-
-   Since TripleDES is the MUST-implement algorithm, if it is not
-   explicitly in the list, it is tacitly at the end. However, it is good
-   form to place it there explicitly. Note also that if an
-   implementation does not implement the preference, then it is
-   implicitly a TripleDES-only implementation.
-
-   An implementation MUST not use a symmetric algorithm that is not in
-   the recipient's preference list. When encrypting to more than one
-   recipient, the implementation finds a suitable algorithm by taking
-   the intersection of the preferences of the recipients. Note that the
-   MUST-implement algorithm, TripleDES, ensures that the intersection is
-   not null. The implementation may use any mechanism to pick an
-   algorithm in the intersection.
-
-   If an implementation can decrypt a message that a keyholder doesn't
-   have in their preferences, the implementation SHOULD decrypt the
-   message anyway, but MUST warn the keyholder than protocol has been
-   violated. (For example, suppose that Alice, above, has software that
-   implements all algorithms in this specification. Nonetheless, she
-   prefers subsets for work or home. If she is sent a message encrypted
-   with IDEA, which is not in her preferences, the software warns her
-   that someone sent her an IDEA-encrypted message, but it would ideally
-   decrypt it anyway.)
-
-   An implementation that is striving for backward compatibility MAY
-   consider a V3 key with a V3 self-signature to be an implicit
-   preference for IDEA, and no ability to do TripleDES. This is
-   technically non-compliant, but an implementation MAY violate the
-   above rule in this case only and use IDEA to encrypt the message,
-   provided that the message creator is warned. Ideally, though, the
-   implementation would follow the rule by actually generating two
-   messages, because it is possible that the OpenPGP user's
-   implementation does not have IDEA, and thus could not read the
-   message. Consequently, an implementation MAY, but SHOULD NOT use IDEA
-   in an algorithm conflict with a V3 key.
-
-12.2. Other Algorithm Preferences
-
-   Other algorithm preferences work similarly to the symmetric algorithm
-   preference, in that they specify which algorithms the keyholder
-   accepts. There are two interesting cases that other comments need to
-   be made about, though, the compression preferences and the hash
-   preferences.
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 55]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-12.2.1. Compression Preferences
-
-   Compression has been an integral part of PGP since its first days.
-   OpenPGP and all previous versions of PGP have offered compression.
-   And in this specification, the default is for messages to be
-   compressed, although an implementation is not required to do so.
-   Consequently, the compression preference gives a way for a keyholder
-   to request that messages not be compressed, presumably because they
-   are using a minimal implementation that does not include compression.
-   Additionally, this gives a keyholder a way to state that it can
-   support alternate algorithms.
-
-   Like the algorithm preferences, an implementation MUST NOT use an
-   algorithm that is not in the preference vector. If the preferences
-   are not present, then they are assumed to be [ZIP(1),
-   UNCOMPRESSED(0)].
-
-12.2.2. Hash Algorithm Preferences
-
-   Typically, the choice of a hash algorithm is something the signer
-   does, rather than the verifier, because a signer does not typically
-   know who is going to be verifying the signature. This preference,
-   though, allows a protocol based upon digital signatures ease in
-   negotiation.
-
-   Thus, if Alice is authenticating herself to Bob with a signature, it
-   makes sense for her to use a hash algorithm that Bob's software uses.
-   This preference allows Bob to state in his key which algorithms Alice
-   may use.
-
-12.3. Plaintext
-
-   Algorithm 0, "plaintext", may only be used to denote secret keys that
-   are stored in the clear. Implementations must not use plaintext in
-   Symmetrically Encrypted Data Packets; they must use Literal Data
-   Packets to encode unencrypted or literal data.
-
-12.4. RSA
-
-   There are algorithm types for RSA-signature-only, and RSA-encrypt-
-   only keys. These types are deprecated. The "key flags" subpacket in a
-   signature is a much better way to express the same idea, and
-   generalizes it to all algorithms. An implementation SHOULD NOT create
-   such a key, but MAY interpret it.
-
-   An implementation SHOULD NOT implement RSA keys of size less than 768
-   bits.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 56]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   It is permissible for an implementation to support RSA merely for
-   backward compatibility; for example, such an implementation would
-   support V3 keys with IDEA symmetric cryptography. Note that this is
-   an exception to the other MUST-implement rules. An implementation
-   that supports RSA in V4 keys MUST implement the MUST-implement
-   features.
-
-12.5. Elgamal
-
-   If an Elgamal key is to be used for both signing and encryption,
-   extra care must be taken in creating the key.
-
-   An ElGamal key consists of a generator g, a prime modulus p, a secret
-   exponent x, and a public value y = g^x mod p.
-
-   The generator and prime must be chosen so that solving the discrete
-   log problem is intractable.  The group g should generate the
-   multiplicative group mod p-1 or a large subgroup of it, and the order
-   of g should have at least one large prime factor.  A good choice is
-   to use a "strong" Sophie-Germain prime in choosing p, so that both p
-   and (p-1)/2 are primes. In fact, this choice is so good that
-   implementors SHOULD do it, as it avoids a small subgroup attack.
-
-   In addition, a result of Bleichenbacher [BLEICHENBACHER] shows that
-   if the generator g has only small prime factors, and if g divides the
-   order of the group it generates, then signatures can be forged.  In
-   particular, choosing g=2 is a bad choice if the group order may be
-   even. On the other hand, a generator of 2 is a fine choice for an
-   encryption-only key, as this will make the encryption faster.
-
-   While verifying Elgamal signatures, note that it is important to test
-   that r and s are less than p.  If this test is not done then
-   signatures can be trivially forged by using large r values of
-   approximately twice the length of p.  This attack is also discussed
-   in the Bleichenbacher paper.
-
-   Details on safe use of Elgamal signatures may be found in [MENEZES],
-   which discusses all the weaknesses described above.
-
-   If an implementation allows Elgamal signatures, then it MUST use the
-   algorithm identifier 20 for an Elgamal public key that can sign.
-
-   An implementation SHOULD NOT implement Elgamal keys of size less than
-   768 bits. For long-term security, Elgamal keys should be 1024 bits or
-   longer.
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 57]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-12.6. DSA
-
-   An implementation SHOULD NOT implement DSA keys of size less than 768
-   bits. Note that present DSA is limited to a maximum of 1024 bit keys,
-   which are recommended for long-term use.
-
-12.7. Reserved Algorithm Numbers
-
-   A number of algorithm IDs have been reserved for algorithms that
-   would be useful to use in an OpenPGP implementation, yet there are
-   issues that prevent an implementor from actually implementing the
-   algorithm. These are marked in the Public Algorithms section as
-   "(reserved for)".
-
-   The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
-   and X9.42 (21) do not have the necessary parameters, parameter order,
-   or semantics defined.
-
-   The reserved symmetric key algorithm, DES/SK (6), does not have
-   semantics defined.
-
-   The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do
-   not have OIDs. The reserved algorithm number 4, reserved for a
-   double-width variant of SHA1, is not presently defined.
-
-   We have reserver three algorithm IDs for the US NIST's Advanced
-   Encryption Standard. This algorithm will work with (at least) 128,
-   192, and 256-bit keys. We expect that this algorithm will be selected
-   from the candidate algorithms in the year 2000.
-
-12.8. OpenPGP CFB mode
-
-   OpenPGP does symmetric encryption using a variant of Cipher Feedback
-   Mode (CFB mode). This section describes the procedure it uses in
-   detail. This mode is what is used for Symmetrically Encrypted Data
-   Packets; the mechanism used for encrypting secret key material is
-   similar, but described in those sections above.
-
-   OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
-   prefixes the plaintext with ten octets of random data, such that
-   octets 9 and 10 match octets 7 and 8.  It does a CFB "resync" after
-   encrypting those ten octets.
-
-   Note that for an algorithm that has a larger block size than 64 bits,
-   the equivalent function will be done with that entire block.  For
-   example, a 16-octet block algorithm would operate on 16 octets, and
-   then produce two octets of check, and then work on 16-octet blocks.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 58]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   Step by step, here is the procedure:
-
-   1.  The feedback register (FR) is set to the IV, which is all zeros.
-
-   2.  FR is encrypted to produce FRE (FR Encrypted).  This is the
-       encryption of an all-zero value.
-
-   3.  FRE is xored with the first 8 octets of random data prefixed to
-       the plaintext to produce C1-C8, the first 8 octets of ciphertext.
-
-   4.  FR is loaded with C1-C8.
-
-   5.  FR is encrypted to produce FRE, the encryption of the first 8
-       octets of ciphertext.
-
-   6.  The left two octets of FRE get xored with the next two octets of
-       data that were prefixed to the plaintext.  This produces C9-C10,
-       the next two octets of ciphertext.
-
-   7.  (The resync step) FR is loaded with C3-C10.
-
-   8.  FR is encrypted to produce FRE.
-
-   9.  FRE is xored with the first 8 octets of the given plaintext, now
-       that we have finished encrypting the 10 octets of prefixed data.
-       This produces C11-C18, the next 8 octets of ciphertext.
-
-   10.  FR is loaded with C11-C18
-
-   11.  FR is encrypted to produce FRE.
-
-   12.  FRE is xored with the next 8 octets of plaintext, to produce the
-       next 8 octets of ciphertext.  These are loaded into FR and the
-       process is repeated until the plaintext is used up.
-
-13. Security Considerations
-
-   As with any technology involving cryptography, you should check the
-   current literature to determine if any algorithms used here have been
-   found to be vulnerable to attack.
-
-   This specification uses Public Key Cryptography technologies.
-   Possession of the private key portion of a public-private key pair is
-   assumed to be controlled by the proper party or parties.
-
-   Certain operations in this specification involve the use of random
-   numbers.  An appropriate entropy source should be used to generate
-   these numbers.  See RFC 1750.
-
-
-
-Callas, et. al.             Standards Track                    [Page 59]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   The MD5 hash algorithm has been found to have weaknesses (pseudo-
-   collisions in the compress function) that make some people deprecate
-   its use.  They consider the SHA-1 algorithm better.
-
-   Many security protocol designers think that it is a bad idea to use a
-   single key for both privacy (encryption) and integrity (signatures).
-   In fact, this was one of the motivating forces behind the V4 key
-   format with separate signature and encryption keys. If you as an
-   implementor promote dual-use keys, you should at least be aware of
-   this controversy.
-
-   The DSA algorithm will work with any 160-bit hash, but it is
-   sensitive to the quality of the hash algorithm, if the hash algorithm
-   is broken, it can leak the secret key. The Digital Signature Standard
-   (DSS) specifies that DSA be used with SHA-1.  RIPEMD-160 is
-   considered by many cryptographers to be as strong. An implementation
-   should take care which hash algorithms are used with DSA, as a weak
-   hash can not only allow a signature to be forged, but could leak the
-   secret key. These same considerations about the quality of the hash
-   algorithm apply to Elgamal signatures.
-
-   If you are building an authentication system, the recipient may
-   specify a preferred signing algorithm. However, the signer would be
-   foolish to use a weak algorithm simply because the recipient requests
-   it.
-
-   Some of the encryption algorithms mentioned in this document have
-   been analyzed less than others.  For example, although CAST5 is
-   presently considered strong, it has been analyzed less than Triple-
-   DES. Other algorithms may have other controversies surrounding them.
-
-   Some technologies mentioned here may be subject to government control
-   in some countries.
-
-14. Implementation Nits
-
-   This section is a collection of comments to help an implementer,
-   particularly with an eye to backward compatibility. Previous
-   implementations of PGP are not OpenPGP-compliant. Often the
-   differences are small, but small differences are frequently more
-   vexing than large differences. Thus, this list of potential problems
-   and gotchas for a developer who is trying to be backward-compatible.
-
-     * PGP 5.x does not accept V4 signatures for anything other than
-       key material.
-
-     * PGP 5.x does not recognize the "five-octet" lengths in new-format
-       headers or in signature subpacket lengths.
-
-
-
-Callas, et. al.             Standards Track                    [Page 60]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-     * PGP 5.0 rejects an encrypted session key if the keylength differs
-       from the S2K symmetric algorithm. This is a bug in its validation
-       function.
-
-     * PGP 5.0 does not handle multiple one-pass signature headers and
-       trailers. Signing one will compress the one-pass signed literal
-       and prefix a V3 signature instead of doing a nested one-pass
-       signature.
-
-     * When exporting a private key, PGP 2.x generates the header "BEGIN
-       PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK".
-       All previous versions ignore the implied data type, and look
-       directly at the packet data type.
-
-     * In a clear-signed signature, PGP 5.0 will figure out the correct
-       hash algorithm if there is no "Hash:" header, but it will reject
-       a mismatch between the header and the actual algorithm used. The
-       "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x
-       rejects the "Hash:" header and assumes MD5. There are a number of
-       enhanced variants of PGP 2.6.x that have been modified for SHA-1
-       signatures.
-
-     * PGP 5.0 can read an RSA key in V4 format, but can only recognize
-       it with a V3 keyid, and can properly use only a V3 format RSA
-       key.
-
-     * Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign
-       keys. They only handle Elgamal Encrypt-only keys.
-
-     * There are many ways possible for two keys to have the same key
-       material, but different fingerprints (and thus key ids). Perhaps
-       the most interesting is an RSA key that has been "upgraded" to V4
-       format, but since a V4 fingerprint is constructed by hashing the
-       key creation time along with other things, two V4 keys created at
-       different times, yet with the same key material will have
-       different fingerprints.
-
-     * If an implementation is using zlib to interoperate with PGP 2.x,
-       then the "windowBits" parameter should be set to -13.
-
-
-
-
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 61]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-15. Authors and Working Group Chair
-
-   The working group can be contacted via the current chair:
-
-   John W. Noerenberg, II
-   Qualcomm, Inc
-   6455 Lusk Blvd
-   San Diego, CA 92131 USA
-
-   Phone: +1 619-658-3510
-   EMail: jwn2@qualcomm.com
-
-
-   The principal authors of this memo are:
-
-   Jon Callas
-   Network Associates, Inc.
-   3965 Freedom Circle
-   Santa Clara, CA 95054, USA
-
-   Phone: +1 408-346-5860
-   EMail: jon@pgp.com, jcallas@nai.com
-
-
-   Lutz Donnerhacke
-   IKS GmbH
-   Wildenbruchstr. 15
-   07745 Jena, Germany
-
-   Phone: +49-3641-675642
-   EMail: lutz@iks-jena.de
-
-
-   Hal Finney
-   Network Associates, Inc.
-   3965 Freedom Circle
-   Santa Clara, CA 95054, USA
-
-   EMail: hal@pgp.com
-
-
-   Rodney Thayer
-   EIS Corporation
-   Clearwater, FL 33767, USA
-
-   EMail: rodney@unitran.com
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 62]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   This memo also draws on much previous work from a number of other
-   authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
-   Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
-   Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
-   Philip R. Zimmermann.
-
-16. References
-
-   [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
-                    signatures without knowing the secret key,"
-                    Eurocrypt 96.  Note that the version in the
-                    proceedings has an error.  A revised version is
-                    available at the time of writing from
-                    <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc
-                    /ElGamal.ps>
-
-   [BLOWFISH]       Schneier, B. "Description of a New Variable-Length
-                    Key, 64-Bit Block Cipher (Blowfish)" Fast Software
-                    Encryption, Cambridge Security Workshop Proceedings
-                    (December 1993), Springer-Verlag, 1994, pp191-204
-
-                    <http://www.counterpane.com/bfsverlag.html>
-
-   [DONNERHACKE]    Donnerhacke, L., et. al, "PGP263in - an improved
-                    international version of PGP", ftp://ftp.iks-
-                    jena.de/mitarb/lutz/crypt/software/pgp/
-
-   [ELGAMAL]        T. ElGamal, "A Public-Key Cryptosystem and a
-                    Signature Scheme Based on Discrete Logarithms," IEEE
-                    Transactions on Information Theory, v. IT-31, n. 4,
-                    1985, pp. 469-472.
-
-   [IDEA]           Lai, X, "On the design and security of block
-                    ciphers", ETH Series in Information Processing, J.L.
-                    Massey (editor), Vol. 1, Hartung-Gorre Verlag
-                    Knostanz, Technische Hochschule (Zurich), 1992
-
-   [ISO-10646]      ISO/IEC 10646-1:1993. International Standard --
-                    Information technology -- Universal Multiple-Octet
-                    Coded Character Set (UCS) -- Part 1: Architecture
-                    and Basic Multilingual Plane.  UTF-8 is described in
-                    Annex R, adopted but not yet published.  UTF-16 is
-                    described in Annex Q, adopted but not yet published.
-
-   [MENEZES]        Alfred Menezes, Paul van Oorschot, and Scott
-                    Vanstone, "Handbook of Applied Cryptography," CRC
-                    Press, 1996.
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 63]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-   [RFC822]         Crocker, D., "Standard for the format of ARPA
-                    Internet text messages", STD 11, RFC 822, August
-                    1982.
-
-   [RFC1423]        Balenson, D., "Privacy Enhancement for Internet
-                    Electronic Mail: Part III: Algorithms, Modes, and
-                    Identifiers", RFC 1423, October 1993.
-
-   [RFC1641]        Goldsmith, D. and M. Davis, "Using Unicode with
-                    MIME", RFC 1641, July 1994.
-
-   [RFC1750]        Eastlake, D., Crocker, S. and J. Schiller,
-                    "Randomness Recommendations for Security", RFC 1750,
-                    December 1994.
-
-   [RFC1951]        Deutsch, P., "DEFLATE Compressed Data Format
-                    Specification version 1.3.", RFC 1951, May 1996.
-
-   [RFC1983]        Malkin, G., "Internet Users' Glossary", FYI 18, RFC
-                    1983, August 1996.
-
-   [RFC1991]        Atkins, D., Stallings, W. and P. Zimmermann, "PGP
-                    Message Exchange Formats", RFC 1991, August 1996.
-
-   [RFC2015]        Elkins, M., "MIME Security with Pretty Good Privacy
-                    (PGP)", RFC 2015, October 1996.
-
-   [RFC2231]        Borenstein, N. and N. Freed, "Multipurpose Internet
-                    Mail Extensions (MIME) Part One: Format of Internet
-                    Message Bodies.", RFC 2231, November 1996.
-
-   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
-                    Requirement Level", BCP 14, RFC 2119, March 1997.
-
-   [RFC2144]        Adams, C., "The CAST-128 Encryption Algorithm", RFC
-                    2144, May 1997.
-
-   [RFC2279]        Yergeau., F., "UTF-8, a transformation format of
-                    Unicode and ISO 10646", RFC 2279, January 1998.
-
-   [RFC2313]        Kaliski, B., "PKCS #1: RSA Encryption Standard
-                    version 1.5", RFC 2313, March 1998.
-
-   [SAFER]          Massey, J.L. "SAFER K-64: One Year Later", B.
-                    Preneel, editor, Fast Software Encryption, Second
-                    International Workshop (LNCS 1008) pp212-241,
-                    Springer-Verlag 1995
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 64]
-
-RFC 2440                 OpenPGP Message Format            November 1998
-
-
-17.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Callas, et. al.             Standards Track                    [Page 65]
-
diff --git a/doc/protocol/rfc2631.txt b/doc/protocol/rfc2631.txt
deleted file mode 100644
index ef73821517..0000000000
--- a/doc/protocol/rfc2631.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       E. Rescorla
-Request for Comments: 2631                                    RTFM Inc.
-Category: Standards Track                                     June 1999
-
-
-                  Diffie-Hellman Key Agreement Method
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   This document standardizes one particular Diffie-Hellman variant,
-   based on the ANSI X9.42 draft, developed by the ANSI X9F1 working
-   group. Diffie-Hellman is a key agreement algorithm used by two
-   parties to agree on a shared secret. An algorithm for converting the
-   shared secret into an arbitrary amount of keying material is
-   provided. The resulting keying material is used as a symmetric
-   encryption key.  The Diffie-Hellman variant described requires the
-   recipient to have a certificate, but the originator may have a static
-   key pair (with the public key placed in a certificate) or an
-   ephemeral key pair.
-
-Table of Contents
-
-   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
-   1.1. Requirements Terminology  . . . . . . . . . . . . . . . .   2
-   2. Overview Of Method  . . . . . . . . . . . . . . . . . . . .   2
-   2.1. Key Agreement . . . . . . . . . . . . . . . . . . . . . .   2
-   2.1.1. Generation of ZZ  . . . . . . . . . . . . . . . . . . .   3
-   2.1.2. Generation of Keying Material . . . . . . . . . . . . .   3
-   2.1.3. KEK Computation . . . . . . . . . . . . . . . . . . . .   4
-   2.1.4. Keylengths for common algorithms  . . . . . . . . . . .   5
-   2.1.5. Public Key Validation . . . . . . . . . . . . . . . . .   5
-   2.1.6. Example 1 . . . . . . . . . . . . . . . . . . . . . . .   5
-   2.1.7. Example 2 . . . . . . . . . . . . . . . . . . . . . . .   6
-   2.2. Key and Parameter Requirements  . . . . . . . . . . . . .   7
-   2.2.1. Group Parameter Generation  . . . . . . . . . . . . . .   7
-   2.2.1.1. Generation of p, q  . . . . . . . . . . . . . . . . .   8
-
-
-
-Rescorla                    Standards Track                     [Page 1]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-   2.2.1.2. Generation of g . . . . . . . . . . . . . . . . . . .   9
-   2.2.2. Group Parameter Validation  . . . . . . . . . . . . . .   9
-   2.3. Ephemeral-Static Mode . . . . . . . . . . . . . . . . . .  10
-   2.4. Static-Static Mode  . . . . . . . . . . . . . . . . . . .  10
-   2.4. Acknowledgements  . . . . . . . . . . . . . . . . . . . .  10
-   2.4. References  . . . . . . . . . . . . . . . . . . . . . . .  11
-   Security Considerations  . . . . . . . . . . . . . . . . . . .  12
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . .  12
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . .  13
-
-1.  Introduction
-
-   In [DH76] Diffie and Hellman describe a means for two parties to
-   agree upon a shared secret in such a way that the secret will be
-   unavailable to eavesdroppers. This secret may then be converted into
-   cryptographic keying material for other (symmetric) algorithms.  A
-   large number of minor variants of this process exist. This document
-   describes one such variant, based on the ANSI X9.42 specification.
-
-1.1.  Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in [RFC2119].
-
-2.  Overview Of Method
-
-   Diffie-Hellman key agreement requires that both the sender and
-   recipient of a message have key pairs. By combining one's private key
-   and the other party's public key, both parties can compute the same
-   shared secret number. This number can then be converted into
-   cryptographic keying material.  That keying material is typically
-   used as a key-encryption key (KEK) to encrypt (wrap) a content-
-   encryption key (CEK) which is in turn used to encrypt the message
-   data.
-
-2.1.  Key Agreement
-
-   The first stage of the key agreement process is to compute a shared
-   secret number, called ZZ.  When the same originator and recipient
-   public/private key pairs are used, the same ZZ value will result.
-   The ZZ value is then converted into a shared symmetric cryptographic
-   key. When the originator employs a static private/public key pair,
-   the introduction of a public random value ensures that the resulting
-   symmetric key will be different for each key agreement.
-
-
-
-
-
-
-Rescorla                    Standards Track                     [Page 2]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-2.1.1.  Generation of ZZ
-
-   X9.42 defines that the shared secret ZZ is generated as follows:
-
-     ZZ = g ^ (xb * xa) mod p
-
-   Note that the individual parties actually perform the computations:
-
-     ZZ = (yb ^ xa)  mod p  = (ya ^ xb)  mod p
-
-   where ^ denotes exponentiation
-
-         ya is party a's public key; ya = g ^ xa mod p
-         yb is party b's public key; yb = g ^ xb mod p
-         xa is party a's private key
-         xb is party b's private key
-         p is a large prime
-         q is a large prime
-         g = h^{(p-1)/q} mod p, where
-         h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
-           (g has order q mod p; i.e. g^q mod p = 1 if g!=1)
-         j a large integer such that p=qj + 1
-         (See Section 2.2 for criteria for keys and parameters)
-
-   In [CMS], the recipient's key is identified by the CMS
-   RecipientIdentifier, which points to the recipient's certificate.
-   The sender's public key is identified using the
-   OriginatorIdentifierOrKey field, either by reference to the sender's
-   certificate or by inline inclusion of a public key.
-
-2.1.2.  Generation of Keying Material
-
-   X9.42 provides an algorithm for generating an essentially arbitrary
-   amount of keying material from ZZ. Our algorithm is derived from that
-   algorithm by mandating some optional fields and omitting others.
-
-     KM = H ( ZZ || OtherInfo)
-
-   H is the message digest function SHA-1 [FIPS-180] ZZ is the shared
-   secret value computed in Section 2.1.1. Leading zeros MUST be
-   preserved, so that ZZ occupies as many octets as p. For instance, if
-   p is 1024 bits, ZZ should be 128 bytes long.  OtherInfo is the DER
-   encoding of the following structure:
-
-     OtherInfo ::= SEQUENCE {
-       keyInfo KeySpecificInfo,
-       partyAInfo [0] OCTET STRING OPTIONAL,
-       suppPubInfo [2] OCTET STRING
-
-
-
-Rescorla                    Standards Track                     [Page 3]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-     }
-
-     KeySpecificInfo ::= SEQUENCE {
-       algorithm OBJECT IDENTIFIER,
-       counter OCTET STRING SIZE (4..4) }
-
-   Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1,
-   EXPLICIT tagging is implicit unless IMPLICIT is explicitly
-   specified.)
-
-   algorithm is the ASN.1 algorithm OID of the CEK wrapping algorithm
-     with which this KEK will be used. Note that this is NOT an
-     AlgorithmIdentifier, but simply the OBJECT IDENTIFIER. No
-     parameters are used.
-
-   counter is a 32 bit number, represented in network byte order. Its
-     initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01
-     (hex), and it is incremented by one every time the above key
-     generation function is run for a given KEK.
-
-   partyAInfo is a random string provided by the sender. In CMS, it is
-     provided as a parameter in the UserKeyingMaterial field (encoded as
-     an OCTET STRING). If provided, partyAInfo MUST contain 512 bits.
-
-   suppPubInfo is the length of the generated KEK, in bits, represented
-     as a 32 bit number in network byte order. E.g. for 3DES it would be
-     the byte sequence 00 00 00 C0.
-
-   To generate a KEK, one generates one or more KM blocks (incrementing
-   counter appropriately) until enough material has been generated.  The
-   KM blocks are concatenated left to right I.e. KM(counter=1) ||
-   KM(counter=2)...
-
-   Note that the only source of secret entropy in this computation is
-   ZZ.  Even if a string longer than ZZ is generated, the effective key
-   space of the KEK is limited by the size of ZZ, in addition to any
-   security level considerations imposed by the parameters p and q.
-   However, if partyAInfo is different for each message, a different KEK
-   will be generated for each message. Note that partyAInfo MUST be used
-   in Static-Static mode, but MAY appear in Ephemeral-Static mode.
-
-2.1.3.  KEK Computation
-
-   Each key encryption algorithm requires a specific size key (n). The
-   KEK is generated by mapping the left n-most bytes of KM onto the key.
-   For 3DES, which requires 192 bits of keying material, the algorithm
-   must be run twice, once with a counter value of 1 (to generate K1',
-   K2', and the first 32 bits of K3') and once with a counter value of 2
-
-
-
-Rescorla                    Standards Track                     [Page 4]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-   (to generate the last 32 bits of K3). K1',K2' and K3' are then parity
-   adjusted to generate the 3 DES keys K1,K2 and K3.  For RC2-128, which
-   requires 128 bits of keying material, the algorithm is run once, with
-   a counter value of 1, and the left-most 128 bits are directly
-   converted to an RC2 key. Similarly, for RC2-40, which requires 40
-   bits of keying material, the algorithm is run once, with a counter
-   value of 1, and the leftmost 40 bits are used as the key.
-
-2.1.4.  Keylengths for common algorithms
-
-   Some common key encryption algorithms have KEKs of the following
-   lengths.
-
-     3-key 3DES      192 bits
-     RC2-128        128 bits
-     RC2-40         40 bits
-
-   RC2 effective key lengths are equal to RC2 real key lengths.
-
-2.1.5.  Public Key Validation
-
-   The following algorithm MAY be used to validate a received public key
-   y.
-
-     1. Verify that y lies within the interval [2,p-1]. If it does not,
-        the key is invalid.
-     2. Compute y^q mod p. If the result == 1, the key is valid.
-        Otherwise the key is invalid.
-
-   The primary purpose of public key validation is to prevent a small
-   subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static
-   mode is used, this check may not be necessary. See also [P1363] for
-   more information on Public Key validation.
-
-   Note that this procedure may be subject to pending patents.
-
-2.1.6.  Example 1
-
-   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
-                      0a 0b 0c 0d 0e 0f 10 11 12 13
-
-   The key wrap algorithm is 3DES-EDE wrap.
-
-   No partyAInfo is used.
-
-   Consequently, the input to the first invocation of SHA-1 is:
-
-   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
-
-
-
-Rescorla                    Standards Track                     [Page 5]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-   30 1d
-      30 13
-         06 0b 2a 86 48 86 f7 0d 01 09 10 03 06          ; 3DES wrap OID
-         04 04
-            00 00 00 01                                        ; Counter
-      a2 06
-         04 04
-         00 00 00 c0                                        ; key length
-
-   And the output is the 20 bytes:
-
-   a0 96 61 39 23 76 f7 04 4d 90 52 a3 97 88 32 46 b6 7f 5f 1e
-
-   The input to the second invocation of SHA-1 is:
-
-   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
-   30 1d
-      30 13
-         06 0b 2a 86 48 86 f7 0d 01 09 10 03 06          ; 3DES wrap OID
-         04 04
-            00 00 00 02                                        ; Counter
-      a2 06
-         04 04
-         00 00 00 c0                                        ; key length
-
-   And the output is the 20 bytes:
-
-   f6 3e b5 fb 5f 56 d9 b6 a8 34 03 91 c2 d3 45 34 93 2e 11 30
-
-   Consequently,
-   K1'=a0 96 61 39 23 76 f7 04
-   K2'=4d 90 52 a3 97 88 32 46
-   K3'=b6 7f 5f 1e f6 3e b5 fb
-
-   Note: These keys are not parity adjusted
-
-2.1.7.  Example 2
-
-   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
-                      0a 0b 0c 0d 0e 0f 10 11 12 13
-
-   The key wrap algorithm is RC2-128 key wrap, so we need 128 bits (16
-   bytes) of keying material.
-
-   The partyAInfo used is the 64 bytes
-
-   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
-   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
-
-
-
-Rescorla                    Standards Track                     [Page 6]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
-   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
-
-   Consequently, the input to SHA-1 is:
-
-   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
-   30 61
-      30 13
-         06 0b 2a 86 48 86 f7 0d 01 09 10 03 07           ; RC2 wrap OID
-         04 04
-            00 00 00 01                                        ; Counter
-      a0 42
-         04 40
-            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
-            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
-            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
-            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
-      a2 06
-         04 04
-            00 00 00 80                                     ; key length
-
-   And the output is the 20 bytes:
-
-   48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 3e 7b 5d e9
-
-   Consequently,
-   K=48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0
-
-2.2.  Key and Parameter Requirements
-
-   X9.42 requires that the group parameters be of the form p=jq + 1
-   where q is a large prime of length m and j>=2. An algorithm for
-   generating primes of this form (derived from the algorithms in FIPS
-   PUB 186-1[FIPS-186] and [X942]can be found in appendix A.
-
-   X9.42 requires that the private key x be in the interval [2, (q -
-   2)].  x should be randomly generated in this interval. y is then
-   computed by calculating g^x mod p.  To comply with this memo, m MUST
-   be >=160 bits in length, (consequently, q MUST be at least 160 bits
-   long). When symmetric ciphers stronger than DES are to be used, a
-   larger m may be advisable. p must be a minimum of 512 bits long.
-
-2.2.1.  Group Parameter Generation
-
-   Agents SHOULD generate domain parameters (g,p,q) using the following
-   algorithm, derived from [FIPS-186] and [X942]. When this algorithm is
-   used, the correctness of the generation procedure can be verified by
-   a third party by the algorithm of 2.2.2.
-
-
-
-Rescorla                    Standards Track                     [Page 7]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-2.2.1.1.  Generation of p, q
-
-   This algorithm generates a p, q pair where q is of length m and p is
-   of length L.
-
-   1. Set m' = m/160 where / represents integer division with rounding
-      upwards. I.e. 200/160 = 2.
-
-   2. Set L'=  L/160
-
-   3. Set N'=  L/1024
-
-   4. Select an arbitrary bit string SEED such that the length of SEED
-      >= m
-
-   5. Set U = 0
-
-   6. For i = 0 to m' - 1
-
-        U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
-
-   Note that for m=160, this reduces to the algorithm of [FIPS-186]
-
-        U = SHA1[SEED] XOR SHA1[(SEED+1) mod 2^160 ].
-
-   5. Form q from U by computing U mod (2^m) and setting the most
-      significant bit (the 2^(m-1) bit) and the least significant bit to
-      1. In terms of boolean operations, q = U OR 2^(m-1) OR 1. Note
-      that 2^(m-1) < q < 2^m
-
-   6. Use a robust primality algorithm to test whether q is prime.
-
-   7. If q is not prime then go to 4.
-
-   8. Let counter = 0
-
-   9. Set R = seed + 2*m' + (L' * counter)
-
-   10. Set V = 0
-
-   12. For i = 0 to L'-1 do
-
-       V = V + SHA1(R + i) * 2^(160 * i)
-
-   13. Set W = V mod 2^L
-
-   14. Set X = W OR 2^(L-1)
-
-
-
-
-Rescorla                    Standards Track                     [Page 8]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-   Note that 0 <= W < 2^(L-1) and hence X >= 2^(L-1)
-
-   15. Set p = X - (X mod (2*q)) + 1
-
-   6. If p > 2^(L-1) use a robust primality test to test whether p is
-      prime. Else go to 18.
-
-   17. If p is prime output p, q, seed, counter and stop.
-
-   18. Set counter = counter + 1
-
-   19. If counter < (4096 * N) then go to 8.
-
-   20. Output "failure"
-
-   Note: A robust primality test is one where the probability of a non-
-   prime number passing the test is at most 2^-80. [FIPS-186] provides a
-   suitable algorithm, as does [X942].
-
-2.2.1.2.  Generation of g
-
-   This section gives an algorithm (derived from [FIPS-186]) for
-   generating g.
-
-   1. Let j = (p - 1)/q.
-
-   2. Set h = any integer, where 1 < h < p - 1 and h differs
-      from any value previously tried.
-
-   3. Set g = h^j mod p
-
-   4. If g = 1 go to step 2
-
-2.2.2.  Group Parameter Validation
-
-   The ASN.1 for DH keys in [PKIX] includes elements j and validation-
-   Parms which MAY be used by recipients of a key to verify that the
-   group parameters were correctly generated. Two checks are possible:
-
-     1. Verify that p=qj + 1. This demonstrates that the parameters meet
-        the X9.42 parameter criteria.
-     2. Verify that when the p,q generation procedure of [FIPS-186]
-        Appendix 2 is followed with seed 'seed', that p is found when
-        'counter' = pgenCounter.
-
-     This demonstrates that the parameters were randomly chosen and
-     do not have a special form.
-
-
-
-
-Rescorla                    Standards Track                     [Page 9]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-   Whether agents provide validation information in their certificates
-   is a local matter between the agents and their CA.
-
-2.3.  Ephemeral-Static Mode
-
-   In Ephemeral-Static mode, the recipient has a static (and certified)
-   key pair, but the sender generates a new key pair for each message
-   and sends it using the originatorKey production. If the sender's key
-   is freshly generated for each message, the shared secret ZZ will be
-   similarly different for each message and partyAInfo MAY be omitted,
-   since it serves merely to decouple multiple KEKs generated by the
-   same set of pairwise keys. If, however, the same ephemeral sender key
-   is used for multiple messages (e.g. it is cached as a performance
-   optimization) then a separate partyAInfo MUST be used for each
-   message. All implementations of this standard MUST implement
-   Ephemeral-Static mode.
-
-   In order to resist small subgroup attacks, the recipient SHOULD
-   perform the check described in 2.1.5. If an opponent cannot determine
-   success or failure of a decryption operation by the recipient, the
-   recipient MAY choose to omit this check. See also [LL97] for a method
-   of generating keys which are not subject to small subgroup attack.
-
-2.4.  Static-Static Mode
-
-   In Static-Static mode, both the sender and the recipient have a
-   static (and certified) key pair. Since the sender's and recipient's
-   keys are therefore the same for each message, ZZ will be the same for
-   each message. Thus, partyAInfo MUST be used (and different for each
-   message) in order to ensure that different messages use different
-   KEKs. Implementations MAY implement Static-Static mode.
-
-   In order to prevent small subgroup attacks, both originator and
-   recipient SHOULD either perform the validation step described in
-   Section 2.1.5 or verify that the CA has properly verified the
-   validity of the key.  See also [LL97] for a method of generating keys
-   which are not subject to small subgroup attack.
-
-Acknowledgements
-
-   The Key Agreement method described in this document is based on work
-   done by the ANSI X9F1 working group. The author wishes to extend his
-   thanks for their assistance.
-
-   The author also wishes to thank Stephen Henson, Paul Hoffman, Russ
-   Housley, Burt Kaliski, Brian Korver, John Linn, Jim Schaad, Mark
-   Schertler, Peter Yee, and Robert Zuccherato for their expert advice
-   and review.
-
-
-
-Rescorla                    Standards Track                    [Page 10]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-References
-
-   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630,
-               June 1999.
-
-   [FIPS-46-1] Federal Information Processing Standards Publication
-               (FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed
-               1988 January 22 (supersedes FIPS PUB 46, 1977 January
-               15).
-
-   [FIPS-81]   Federal Information Processing Standards Publication
-               (FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
-
-   [FIPS-180]  Federal Information Processing Standards Publication
-               (FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
-
-   [FIPS-186]  Federal Information Processing Standards Publication
-               (FIPS PUB) 186, "Digital Signature Standard", 1994 May
-               19.
-
-   [P1363]     "Standard Specifications for Public Key Cryptography",
-               IEEE P1363 working group draft, 1998, Annex D.
-
-   [PKIX]      Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-               X.509 Public Key Infrastructure Certificate and CRL
-               Profile", RFC 2459, January 1999.
-
-   [LAW98]     L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
-               "An efficient protocol for authenticated key agreement",
-               Technical report CORR 98-05, University of Waterloo,
-               1998.
-
-   [LL97]      C.H. Lim and P.J. Lee, "A key recovery attack on discrete
-               log-based schemes using a prime order subgroup", B.S.
-               Kaliski, Jr., editor, Advances in Cryptology - Crypto
-               '97, Lecture Notes in Computer Science, vol. 1295, 1997,
-               Springer-Verlag, pp. 249-263.
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [X942]      "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV
-               Algorithms", ANSI draft, 1998.
-
-
-
-
-
-
-
-
-Rescorla                    Standards Track                    [Page 11]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-Security Considerations
-
-   All the security in this system is provided by the secrecy of the
-   private keying material. If either sender or recipient private keys
-   are disclosed, all messages sent or received using that key are
-   compromised. Similarly, loss of the private key results in an
-   inability to read messages sent using that key.
-
-   Static Diffie-Hellman keys are vulnerable to a small subgroup attack
-   [LAW98]. In practice, this issue arises for both sides in Static-
-   Static mode and for the receiver during Ephemeral-Static mode.
-   Sections 2.3 and 2.4 describe appropriate practices to protect
-   against this attack. Alternatively, it is possible to generate keys
-   in such a fashion that they are resistant to this attack. See [LL97]
-
-   The security level provided by these methods depends on several
-   factors. It depends on the length of the symmetric key (typically, a
-   2^l security level if the length is l bits); the size of the prime q
-   (a 2^{m/2} security level); and the size of the prime p (where the
-   security level grows as a subexponential function of the size in
-   bits).  A good design principle is to have a balanced system, where
-   all three security levels are approximately the same. If many keys
-   are derived from a given pair of primes p and q, it may be prudent to
-   have higher levels for the primes. In any case, the overall security
-   is limited by the lowest of the three levels.
-
-Author's Address
-
-   Eric Rescorla
-   RTFM Inc.
-   30 Newell Road, #16
-   East Palo Alto, CA 94303
-
-   EMail: ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                    Standards Track                    [Page 12]
-
-RFC 2631          Diffie-Hellman Key Agreement Method          June 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                    Standards Track                    [Page 13]
-
diff --git a/doc/protocol/rfc2712.txt b/doc/protocol/rfc2712.txt
deleted file mode 100644
index 4888e2e2d7..0000000000
--- a/doc/protocol/rfc2712.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      A. Medvinsky
-Request for Comments: 2712                                       Excite
-Category: Standards Track                                        M. Hur
-                                                  CyberSafe Corporation
-                                                           October 1999
-
-
-  Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-IESG Note:
-
-   The 40-bit ciphersuites defined in this memo are included only for
-   the purpose of documenting the fact that those ciphersuite codes have
-   already been assigned.  40-bit ciphersuites were designed to comply
-   with US-centric, and now obsolete, export restrictions.  They were
-   never secure, and nowadays are inadequate even for casual
-   applications.  Implementation and use of the 40-bit ciphersuites
-   defined in this document, and elsewhere, is strongly discouraged.
-
-1. Abstract
-
-   This document proposes the addition of new cipher suites to the TLS
-   protocol [1] to support Kerberos-based authentication.  Kerberos
-   credentials are used to achieve mutual authentication and to
-   establish a master secret which is subsequently used to secure
-   client-server communication.
-
-2. Introduction
-
-   Flexibility is one of the main strengths of the TLS protocol.
-   Clients and servers can negotiate cipher suites to meet specific
-   security and administrative policies.  However, to date,
-   authentication in TLS is limited only to public key solutions.  As a
-   result, TLS does not fully support organizations with heterogeneous
-   security deployments that include authentication systems based on
-   symmetric cryptography.  Kerberos, originally developed at MIT, is
-
-
-
-Medvinsky & Hur             Standards Track                     [Page 1]
-
-RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
-
-
-   based on an open standard [2] and is the most widely deployed
-   symmetric key authentication system.  This document proposes a new
-   option for negotiating Kerberos authentication within the TLS
-   framework.  This achieves mutual authentication and the establishment
-   of a master secret using Kerberos credentials.  The proposed changes
-   are minimal and, in fact, no different from adding a new public key
-   algorithm to the TLS framework.
-
-3. Kerberos Authentication Option In TLS
-
-   This section describes the addition of the Kerberos authentication
-   option to the TLS protocol.  Throughout this document, we refer to
-   the basic SSL handshake shown in Figure 1.  For a review of the TLS
-   handshake see [1].
-
-  CLIENT                                             SERVER
-  ------                                             ------
- ClientHello
-                    -------------------------------->
-                                                     ServerHello
-                                                     Certificate *
-                                                     ServerKeyExchange*
-                                                     CertificateRequest*
-                                                     ServerHelloDone
-                    <-------------------------------
- Certificate*
- ClientKeyExchange
- CertificateVerify*
- change cipher spec
- Finished
-     |              -------------------------------->
-     |                                               change cipher spec
-     |                                               Finished
-     |                                                   |
-     |                                                   |
- Application Data   <------------------------------->Application Data
-
- FIGURE 1: The TLS protocol.  All messages followed by a star are
-           optional.  Note: This figure was taken from an IETF document
-           [1].
-
-   The TLS security context is negotiated in the client and server hello
-   messages.  For example: TLS_RSA_WITH_RC4_MD5 means the initial
-   authentication will be done using the RSA public key algorithm, RC4
-   will be used for the session key, and MACs will be based on the MD5
-   algorithm.  Thus, to facilitate the Kerberos authentication option,
-   we must start by defining new cipher suites including (but not
-   limited to):
-
-
-
-Medvinsky & Hur             Standards Track                     [Page 2]
-
-RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
-
-
- CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
- CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
- CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
- CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
- CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
- CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
- CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
- CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
-
- CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26 };
- CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27 };
- CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28 };
- CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29 };
- CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A };
- CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B };
-
-   To establish a Kerberos-based security context, one or more of the
-   above cipher suites must be specified in the client hello message.
-   If the TLS server supports the Kerberos authentication option, the
-   server hello message, sent to the client, will confirm the Kerberos
-   cipher suite selected by the server.  The server's certificate, the
-   client
-
-   CertificateRequest, and the ServerKeyExchange shown in Figure 1 will
-   be omitted since authentication and the establishment of a master
-   secret will be done using the client's Kerberos credentials for the
-   TLS server.  The client's certificate will be omitted for the same
-   reason.  Note that these messages are specified as optional in the
-   TLS protocol; therefore, omitting them is permissible.
-
-   The Kerberos option must be added to the ClientKeyExchange message as
-   shown in Figure 2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Medvinsky & Hur             Standards Track                     [Page 3]
-
-RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
-
-
- struct
- {
-     select (KeyExchangeAlgorithm)
-     {
-         case krb5:            KerberosWrapper;       /* new addition */
-         case rsa:             EncryptedPreMasterSecret;
-         case diffie_hellman:  ClientDiffieHellmanPublic;
-     } Exchange_keys;
-
- } ClientKeyExchange;
-
- struct
- {
-     opaque Ticket;
-     opaque authenticator;            /* optional */
-     opaque EncryptedPreMasterSecret; /* encrypted with the session key
-                                         which is sealed in the ticket */
- } KerberosWrapper;                   /* new addition */
-
-         FIGURE 2: The Kerberos option in the ClientKeyExchange.
-
-   To use the Kerberos authentication option, the TLS client must obtain
-   a service ticket for the TLS server.  In TLS, the ClientKeyExchange
-   message is used to pass a random 48-byte pre-master secret to the
-   server.
-
-   The client and server then use the pre-master secret to independently
-   derive the master secret, which in turn is used for generating
-   session keys and for MAC computations.  Thus, if the Kerberos option
-   is selected, the pre-master secret structure is the same as that used
-   in the RSA case; it is encrypted under the Kerberos session key and
-   sent to the TLS server along with the Kerberos credentials (see
-   Figure 2).  The ticket and authenticator are encoded per RFC 1510
-   (ASN.1 encoding).  Once the ClientKeyExchange message is received,
-   the server's secret key is used to unwrap the credentials and extract
-   the pre-master secret.
-
-   Note that a Kerberos authenticator is not required, since the master
-   secret derived by the client and server is seeded with a random value
-   passed in the server hello message, thus foiling replay attacks.
-   However, the authenticator may still prove useful for passing
-   authorization information and is thus allotted an optional field (see
-   Figure 2).
-
-   Lastly, the client and server exchange the finished messages to
-   complete the handshake.  At this point we have achieved the
-   following:
-
-
-
-
-Medvinsky & Hur             Standards Track                     [Page 4]
-
-RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
-
-
-   1) A master secret, used to protect all subsequent communication, is
-      securely established.
-
-   2) Mutual client-server authentication is achieved, since the TLS
-      server proves knowledge of the master secret in the finished
-      message.
-
-   Note that the Kerberos option fits in seamlessly, without adding any
-   new messages.
-
-4. Naming Conventions:
-
-   To obtain an appropriate service ticket, the TLS client must
-   determine the principal name of the TLS server.  The Kerberos service
-   naming convention is used for this purpose, as follows:
-
-     host/MachineName@Realm
-      where:
-        - The literal, "host", follows the Kerberos convention when not
-          concerned about the protection domain on a particular machine.
-        - "MachineName" is the particular instance of the service.
-        - The Kerberos "Realm" is the domain name of the machine.
-
-5. Summary
-
-   The proposed Kerberos authentication option is added in exactly the
-   same manner as a new public key algorithm would be added to TLS.
-   Furthermore, it establishes the master secret in exactly the same
-   manner.
-
-6. Security Considerations
-
-   Kerberos ciphersuites are subject to the same security considerations
-   as the TLS protocol.  In addition, just as a public key
-   implementation must take care to protect the private key (for example
-   the PIN for a smartcard), a Kerberos implementation must take care to
-   protect the long lived secret that is shared between the principal
-   and the KDC.  In particular, a weak password may be subject to a
-   dictionary attack.  In order to strengthen the initial authentication
-   to a KDC, an implementor may choose to utilize secondary
-   authentication via a token card, or one may utilize initial
-   authentication to the KDC based on public key cryptography (commonly
-   known as PKINIT - a product of the Common Authentication Technology
-   working group of the IETF).
-
-
-
-
-
-
-
-Medvinsky & Hur             Standards Track                     [Page 5]
-
-RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
-
-
-7. Acknowledgements
-
-   We would like to thank Clifford Neuman for his invaluable comments on
-   earlier versions of this document.
-
-8. References
-
-   [1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
-       2246, January 1999.
-
-   [2] Kohl J. and C. Neuman, "The Kerberos Network Authentication
-       Service (V5)", RFC 1510, September 1993.
-
-9. Authors' Addresses
-
-   Ari Medvinsky
-   Excite
-   555 Broadway
-   Redwood City, CA 94063
-
-   Phone: +1 650 569 2119
-   EMail: amedvins@excitecorp.com
-   http://www.excite.com
-
-
-   Matthew Hur
-   CyberSafe Corporation
-   1605 NW Sammamish Road
-   Issaquah WA 98027-5378
-
-   Phone: +1 425 391 6000
-   EMail: matt.hur@cybersafe.com
-   http://www.cybersafe.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Medvinsky & Hur             Standards Track                     [Page 6]
-
-RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
-
-
-10. Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Medvinsky & Hur             Standards Track                     [Page 7]
-
diff --git a/doc/protocol/rfc2817.txt b/doc/protocol/rfc2817.txt
deleted file mode 100644
index d7b7e703bb..0000000000
--- a/doc/protocol/rfc2817.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           R. Khare
-Request for Comments: 2817                     4K Associates / UC Irvine
-Updates: 2616                                                S. Lawrence
-Category: Standards Track                          Agranat Systems, Inc.
-                                                                May 2000
-
-
-                    Upgrading to TLS Within HTTP/1.1
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
-   initiate Transport Layer Security (TLS) over an existing TCP
-   connection. This allows unsecured and secured HTTP traffic to share
-   the same well known port (in this case, http: at 80 rather than
-   https: at 443). It also enables "virtual hosting", so a single HTTP +
-   TLS server can disambiguate traffic intended for several hostnames at
-   a single IP address.
-
-   Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this
-   memo also documents the HTTP CONNECT method for establishing end-to-
-   end tunnels across HTTP proxies. Finally, this memo establishes new
-   IANA registries for public HTTP status codes, as well as public or
-   private Upgrade product tokens.
-
-   This memo does NOT affect the current definition of the 'https' URI
-   scheme, which already defines a separate namespace
-   (http://example.org/ and https://example.org/ are not equivalent).
-
-
-
-
-
-
-
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 1]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-Table of Contents
-
-   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . .  4
-   3.  Client Requested Upgrade to HTTP over TLS  . . . . . . . . . .  4
-   3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.2 Mandatory Upgrade  . . . . . . . . . . . . . . . . . . . . . .  4
-   3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . .  4
-   4.  Server Requested Upgrade to HTTP over TLS  . . . . . . . . . .  5
-   4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . .  5
-   4.2 Mandatory Advertisement  . . . . . . . . . . . . . . . . . . .  5
-   5.  Upgrade across Proxies . . . . . . . . . . . . . . . . . . . .  6
-   5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . .  6
-   5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . .  6
-   5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . .  7
-   6.  Rationale for the use of a 4xx (client error) Status Code  . .  7
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   7.1 HTTP Status Code Registry  . . . . . . . . . . . . . . . . . .  8
-   7.2 HTTP Upgrade Token Registry  . . . . . . . . . . . . . . . . .  8
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
-   8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
-   8.2 Security Considerations for CONNECT  . . . . . . . . . . . . . 10
-       References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
-       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
-
-1. Motivation
-
-   The historical practice of deploying HTTP over SSL3 [3] has
-   distinguished the combination from HTTP alone by a unique URI scheme
-   and the TCP port number. The scheme 'http' meant the HTTP protocol
-   alone on port 80, while 'https' meant the HTTP protocol over SSL on
-   port 443.  Parallel well-known port numbers have similarly been
-   requested -- and in some cases, granted -- to distinguish between
-   secured and unsecured use of other application protocols (e.g.
-   snews, ftps). This approach effectively halves the number of
-   available well known ports.
-
-   At the Washington DC IETF meeting in December 1997, the Applications
-   Area Directors and the IESG reaffirmed that the practice of issuing
-   parallel "secure" port numbers should be deprecated. The HTTP/1.1
-   Upgrade mechanism can apply Transport Layer Security [6] to an open
-   HTTP connection.
-
-
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 2]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-   In the nearly two years since, there has been broad acceptance of the
-   concept behind this proposal, but little interest in implementing
-   alternatives to port 443 for generic Web browsing. In fact, nothing
-   in this memo affects the current interpretation of https: URIs.
-   However, new application protocols built atop HTTP, such as the
-   Internet Printing Protocol [7], call for just such a mechanism in
-   order to move ahead in the IETF standards process.
-
-   The Upgrade mechanism also solves the "virtual hosting" problem.
-   Rather than allocating multiple IP addresses to a single host, an
-   HTTP/1.1 server will use the Host: header to disambiguate the
-   intended web service. As HTTP/1.1 usage has grown more prevalent,
-   more ISPs are offering name-based virtual hosting, thus delaying IP
-   address space exhaustion.
-
-   TLS (and SSL) have been hobbled by the same limitation as earlier
-   versions of HTTP: the initial handshake does not specify the intended
-   hostname, relying exclusively on the IP address. Using a cleartext
-   HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
-   certificates based on the initial Host: header -- will allow ISPs to
-   provide secure name-based virtual hosting as well.
-
-2. Introduction
-
-   TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-
-   to-end connection, optionally including strong mutual authentication,
-   using a variety of cryptosystems. Initially, a handshake phase uses
-   three subprotocols to set up a record layer, authenticate endpoints,
-   set parameters, as well as report errors.  Then, there is an ongoing
-   layered record protocol that handles encryption, compression, and
-   reassembly for the remainder of the connection. The latter is
-   intended to be completely transparent. For example, there is no
-   dependency between TLS's record markers and or certificates and
-   HTTP/1.1's chunked encoding or authentication.
-
-   Either the client or server can use the HTTP/1.1 [1] Upgrade
-   mechanism (Section 14.42) to indicate that a TLS-secured connection
-   is desired or necessary. This memo defines the "TLS/1.0" Upgrade
-   token, and a new HTTP Status Code, "426 Upgrade Required".
-
-   Section 3 and Section 4 describe the operation of a directly
-   connected client and server. Intermediate proxies must establish an
-   end-to-end tunnel before applying those operations, as explained in
-   Section 5.
-
-
-
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 3]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-2.1 Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in RFC 2119 [11].
-
-3. Client Requested Upgrade to HTTP over TLS
-
-   When the client sends an HTTP/1.1 request with an Upgrade header
-   field containing the token "TLS/1.0", it is requesting the server to
-   complete the current HTTP/1.1 request after switching to TLS/1.0.
-
-3.1 Optional Upgrade
-
-   A client MAY offer to switch to secured operation during any clear
-   HTTP request when an unsecured response would be acceptable:
-
-       GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
-       Host: example.bank.com
-       Upgrade: TLS/1.0
-       Connection: Upgrade
-
-   In this case, the server MAY respond to the clear HTTP operation
-   normally, OR switch to secured operation (as detailed in the next
-   section).
-
-   Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be
-   supplied within a Connection header field (section 14.10) whenever
-   Upgrade is present in an HTTP/1.1 message".
-
-3.2 Mandatory Upgrade
-
-   If an unsecured response would be unacceptable, a client MUST send an
-   OPTIONS request first to complete the switch to TLS/1.0 (if
-   possible).
-
-       OPTIONS * HTTP/1.1
-       Host: example.bank.com
-       Upgrade: TLS/1.0
-       Connection: Upgrade
-
-3.3 Server Acceptance of Upgrade Request
-
-   As specified in HTTP/1.1 [1], if the server is prepared to initiate
-   the TLS handshake, it MUST send the intermediate "101 Switching
-   Protocol" and MUST include an Upgrade response header specifying the
-   tokens of the protocol stack it is switching to:
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 4]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-       HTTP/1.1 101 Switching Protocols
-       Upgrade: TLS/1.0, HTTP/1.1
-       Connection: Upgrade
-
-   Note that the protocol tokens listed in the Upgrade header of a 101
-   Switching Protocols response specify an ordered 'bottom-up' stack.
-
-   As specified in  HTTP/1.1 [1], Section 10.1.2: "The server will
-   switch protocols to those defined by the response's Upgrade header
-   field immediately after the empty line which terminates the 101
-   response".
-
-   Once the TLS handshake completes successfully, the server MUST
-   continue with the response to the original request. Any TLS handshake
-   failure MUST lead to disconnection, per the TLS error alert
-   specification.
-
-4. Server Requested Upgrade to HTTP over TLS
-
-   The Upgrade response header field advertises possible protocol
-   upgrades a server MAY accept. In conjunction with the "426 Upgrade
-   Required" status code, a server can advertise the exact protocol
-   upgrade(s) that a client MUST accept to complete the request.
-
-4.1 Optional Advertisement
-
-   As specified in HTTP/1.1 [1], the server MAY include an Upgrade
-   header in any response other than 101 or 426 to indicate a
-   willingness to switch to any (combination) of the protocols listed.
-
-4.2 Mandatory Advertisement
-
-   A server MAY indicate that a client request can not be completed
-   without TLS using the "426 Upgrade Required" status code, which MUST
-   include an an Upgrade header field specifying the token of the
-   required TLS version.
-
-       HTTP/1.1 426 Upgrade Required
-       Upgrade: TLS/1.0, HTTP/1.1
-       Connection: Upgrade
-
-   The server SHOULD include a message body in the 426 response which
-   indicates in human readable form the reason for the error and
-   describes any alternative courses which may be available to the user.
-
-   Note that even if a client is willing to use TLS, it must use the
-   operations in Section 3 to proceed; the TLS handshake cannot begin
-   immediately after the 426 response.
-
-
-
-Khare & Lawrence            Standards Track                     [Page 5]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-5. Upgrade across Proxies
-
-   As a hop-by-hop header, Upgrade is negotiated between each pair of
-   HTTP counterparties.  If a User Agent sends a request with an Upgrade
-   header to a proxy, it is requesting a change to the protocol between
-   itself and the proxy, not an end-to-end change.
-
-   Since TLS, in particular, requires end-to-end connectivity to provide
-   authentication and prevent man-in-the-middle attacks, this memo
-   specifies the CONNECT method to establish a tunnel across proxies.
-
-   Once a tunnel is established, any of the operations in Section 3 can
-   be used to establish a TLS connection.
-
-5.1 Implications of Hop By Hop Upgrade
-
-   If an origin server receives an Upgrade header from a proxy and
-   responds with a 101 Switching Protocols response, it is changing the
-   protocol only on the connection between the proxy and itself.
-   Similarly, a proxy might return a 101 response to its client to
-   change the protocol on that connection independently of the protocols
-   it is using to communicate toward the origin server.
-
-   These scenarios also complicate diagnosis of a 426 response.  Since
-   Upgrade is a hop-by-hop header, a proxy that does not recognize 426
-   might remove the accompanying Upgrade header and prevent the client
-   from determining the required protocol switch.  If a client receives
-   a 426 status without an accompanying Upgrade header, it will need to
-   request an end to end tunnel connection as described in Section 5.2
-   and repeat the request in order to obtain the required upgrade
-   information.
-
-   This hop-by-hop definition of Upgrade was a deliberate choice.  It
-   allows for incremental deployment on either side of proxies, and for
-   optimized protocols between cascaded proxies without the knowledge of
-   the parties that are not a part of the change.
-
-5.2 Requesting a Tunnel with CONNECT
-
-   A CONNECT method requests that a proxy establish a tunnel connection
-   on its behalf. The Request-URI portion of the Request-Line is always
-   an 'authority' as defined by URI Generic Syntax [2], which is to say
-   the host name and port number destination of the requested connection
-   separated by a colon:
-
-      CONNECT server.example.com:80 HTTP/1.1
-      Host: server.example.com:80
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 6]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-   Other HTTP mechanisms can be used normally with the CONNECT method --
-   except end-to-end protocol Upgrade requests, of course, since the
-   tunnel must be established first.
-
-   For example, proxy authentication might be used to establish the
-   authority to create a tunnel:
-
-      CONNECT server.example.com:80 HTTP/1.1
-      Host: server.example.com:80
-      Proxy-Authorization: basic aGVsbG86d29ybGQ=
-
-   Like any other pipelined HTTP/1.1 request, data to be tunneled may be
-   sent immediately after the blank line. The usual caveats also apply:
-   data may be discarded if the eventual response is negative, and the
-   connection may be reset with no response if more than one TCP segment
-   is outstanding.
-
-5.3 Establishing a Tunnel with CONNECT
-
-   Any successful (2xx) response to a CONNECT request indicates that the
-   proxy has established a connection to the requested host and port,
-   and has switched to tunneling the current connection to that server
-   connection.
-
-   It may be the case that the proxy itself can only reach the requested
-   origin server through another proxy.  In this case, the first proxy
-   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
-   to the authority.  A proxy MUST NOT respond with any 2xx status code
-   unless it has either a direct or tunnel connection established to the
-   authority.
-
-   An origin server which receives a CONNECT request for itself MAY
-   respond with a 2xx status code to indicate that a connection is
-   established.
-
-   If at any point either one of the peers gets disconnected, any
-   outstanding data that came from that peer will be passed to the other
-   one, and after that also the other connection will be terminated by
-   the proxy. If there is outstanding data to that peer undelivered,
-   that data will be discarded.
-
-6. Rationale for the use of a 4xx (client error) Status Code
-
-   Reliable, interoperable negotiation of Upgrade features requires an
-   unambiguous failure signal. The 426 Upgrade Required status code
-   allows a server to definitively state the precise protocol extensions
-   a given resource must be served with.
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 7]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-   It might at first appear that the response should have been some form
-   of redirection (a 3xx code), by analogy to an old-style redirection
-   to an https: URI.  User agents that do not understand Upgrade:
-   preclude this.
-
-   Suppose that a 3xx code had been assigned for "Upgrade Required"; a
-   user agent that did not recognize it would treat it as 300.  It would
-   then properly look for a "Location" header in the response and
-   attempt to repeat the request at the URL in that header field. Since
-   it did not know to Upgrade to incorporate the TLS layer, it would at
-   best fail again at the new URL.
-
-7. IANA Considerations
-
-   IANA shall create registries for two name spaces, as described in BCP
-   26 [10]:
-
-   o  HTTP Status Codes
-   o  HTTP Upgrade Tokens
-
-7.1 HTTP Status Code Registry
-
-   The HTTP Status Code Registry defines the name space for the Status-
-   Code token in the Status line of an HTTP response.  The initial
-   values for this name space are those specified by:
-
-   1.  Draft Standard for HTTP/1.1 [1]
-   2.  Web Distributed Authoring and Versioning [4] [defines 420-424]
-   3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
-   4.  Section 6 [defines 426]
-
-   Values to be added to this name space SHOULD be subject to review in
-   the form of a standards track document within the IETF Applications
-   Area.  Any such document SHOULD be traceable through statuses of
-   either 'Obsoletes' or 'Updates' to the Draft Standard for
-   HTTP/1.1 [1].
-
-7.2 HTTP Upgrade Token Registry
-
-   The HTTP Upgrade Token Registry defines the name space for product
-   tokens used to identify protocols in the Upgrade HTTP header field.
-   Each registered token should be associated with one or a set of
-   specifications, and with contact information.
-
-   The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey
-   the production for 'product':
-
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 8]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-      product         = token ["/" product-version]
-      product-version = token
-
-   Registrations should be allowed on a First Come First Served basis as
-   described in BCP 26 [10]. These specifications need not be IETF
-   documents or be subject to IESG review, but should obey the following
-   rules:
-
-   1.  A token, once registered, stays registered forever.
-   2.  The registration MUST name a responsible party for the
-       registration.
-   3.  The registration MUST name a point of contact.
-   4.  The registration MAY name the documentation required for the
-       token.
-   5.  The responsible party MAY change the registration at any time.
-       The IANA will keep a record of all such changes, and make them
-       available upon request.
-   6.  The responsible party for the first registration of a "product"
-       token MUST approve later registrations of a "version" token
-       together with that "product" token before they can be registered.
-   7.  If absolutely required, the IESG MAY reassign the responsibility
-       for a token. This will normally only be used in the case when a
-       responsible party cannot be contacted.
-
-   This specification defines the protocol token "TLS/1.0" as the
-   identifier for the protocol specified by The TLS Protocol [6].
-
-   It is NOT required that specifications for upgrade tokens be made
-   publicly available, but the contact information for the registration
-   SHOULD be.
-
-8. Security Considerations
-
-   The potential for a man-in-the-middle attack (deleting the Upgrade
-   header) remains the same as current, mixed http/https practice:
-
-   o  Removing the Upgrade header is similar to rewriting web pages to
-      change https:// links to http:// links.
-   o  The risk is only present if the server is willing to vend such
-      information over both a secure and an insecure channel in the
-      first place.
-   o  If the client knows for a fact that a server is TLS-compliant, it
-      can insist on it by only sending an Upgrade request with a no-op
-      method like OPTIONS.
-   o  Finally, as the https: specification warns, "users should
-      carefully examine the certificate presented by the server to
-      determine if it meets their expectations".
-
-
-
-
-Khare & Lawrence            Standards Track                     [Page 9]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-   Furthermore, for clients that do not explicitly try to invoke TLS,
-   servers can use the Upgrade header in any response other than 101 or
-   426 to advertise TLS compliance. Since TLS compliance should be
-   considered a feature of the server and not the resource at hand, it
-   should be sufficient to send it once, and let clients cache that
-   fact.
-
-8.1 Implications for the https: URI Scheme
-
-   While nothing in this memo affects the definition of the 'https' URI
-   scheme, widespread adoption of this mechanism for HyperText content
-   could use 'http' to identify both secure and non-secure resources.
-
-   The choice of what security characteristics are required on the
-   connection is left to the client and server.  This allows either
-   party to use any information available in making this determination.
-   For example, user agents may rely on user preference settings or
-   information about the security of the network such as 'TLS required
-   on all POST operations not on my local net', or servers may apply
-   resource access rules such as 'the FORM on this page must be served
-   and submitted using TLS'.
-
-8.2 Security Considerations for CONNECT
-
-   A generic TCP tunnel is fraught with security risks. First, such
-   authorization should be limited to a small number of known ports.
-   The Upgrade: mechanism defined here only requires onward tunneling at
-   port 80. Second, since tunneled data is opaque to the proxy, there
-   are additional risks to tunneling to other well-known or reserved
-   ports. A putative HTTP client CONNECTing to port 25 could relay spam
-   via SMTP, for example.
-
-References
-
-   [1]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
-        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
-        HTTP/1.1", RFC 2616, June 1999.
-
-   [2]  Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic
-        Syntax", RFC 2396, August 1998.
-
-   [3]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
-
-   [4]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
-        "Web Distributed Authoring and Versioning", RFC 2518, February
-        1999.
-
-
-
-
-
-Khare & Lawrence            Standards Track                    [Page 10]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-   [5]  Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections
-        Protocol",  Work In Progress.
-
-   [6]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
-        1999.
-
-   [7]  Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
-        Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
-        1999.
-
-   [8]  Luotonen, A., "Tunneling TCP based protocols through Web proxy
-        servers",  Work In Progress.  (Also available in: Luotonen, Ari.
-        Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
-
-   [9]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
-        1999.
-
-   [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-Authors' Addresses
-
-   Rohit Khare
-   4K Associates / UC Irvine
-   3207 Palo Verde
-   Irvine, CA  92612
-   US
-
-   Phone: +1 626 806 7574
-   EMail: rohit@4K-associates.com
-   URI:   http://www.4K-associates.com/
-
-
-   Scott Lawrence
-   Agranat Systems, Inc.
-   5 Clocktower Place
-   Suite 400
-   Maynard, MA  01754
-   US
-
-   Phone: +1 978 461 0888
-   EMail: lawrence@agranat.com
-   URI:   http://www.agranat.com/
-
-
-
-
-
-Khare & Lawrence            Standards Track                    [Page 11]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-Appendix A. Acknowledgments
-
-   The CONNECT method was originally described in a Work in Progress
-   titled, "Tunneling TCP based protocols through Web proxy servers",
-   [8] by Ari Luotonen of Netscape Communications Corporation.  It was
-   widely implemented by HTTP proxies, but was never made a part of any
-   IETF Standards Track document. The method name CONNECT was reserved,
-   but not defined in [1].
-
-   The definition provided here is derived directly from that earlier
-   memo, with some editorial changes and conformance to the stylistic
-   conventions since established in other HTTP specifications.
-
-   Additional Thanks to:
-
-   o  Paul Hoffman for his work on the STARTTLS command extension for
-      ESMTP.
-   o  Roy Fielding for assistance with the rationale behind Upgrade:
-      and its interaction with OPTIONS.
-   o  Eric Rescorla for his work on standardizing the existing https:
-      practice to compare with.
-   o  Marshall Rose, for the xml2rfc document type description and tools
-      [9].
-   o  Jim Whitehead, for sorting out the current range of available HTTP
-      status codes.
-   o  Henrik Frystyk Nielsen, whose work on the Mandatory extension
-      mechanism pointed out a hop-by-hop Upgrade still requires
-      tunneling.
-   o  Harald Alvestrand for improvements to the token registration
-      rules.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Khare & Lawrence            Standards Track                    [Page 12]
-
-RFC 2817                  HTTP Upgrade to TLS                   May 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Khare & Lawrence            Standards Track                    [Page 13]
-
diff --git a/doc/protocol/rfc2818.txt b/doc/protocol/rfc2818.txt
deleted file mode 100644
index 219a1c427f..0000000000
--- a/doc/protocol/rfc2818.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       E. Rescorla
-Request for Comments: 2818                                   RTFM, Inc.
-Category: Informational                                        May 2000
-
-
-                             HTTP Over TLS
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This memo describes how to use TLS to secure HTTP connections over
-   the Internet. Current practice is to layer HTTP over SSL (the
-   predecessor to TLS), distinguishing secured traffic from insecure
-   traffic by the use of a different server port. This document
-   documents that practice using TLS. A companion document describes a
-   method for using HTTP/TLS over the same port as normal HTTP
-   [RFC2817].
-
-Table of Contents
-
-   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . 2
-   1.1. Requirements Terminology  . . . . . . . . . . . . . . . 2
-   2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 2
-   2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2
-   2.2. Connection Closure  . . . . . . . . . . . . . . . . . . 2
-   2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 3
-   2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3
-   2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . 4
-   2.4. URI Format  . . . . . . . . . . . . . . . . . . . . . . 4
-   3. Endpoint Identification . . . . . . . . . . . . . . . . . 4
-   3.1. Server Identity . . . . . . . . . . . . . . . . . . . . 4
-   3.2. Client Identity . . . . . . . . . . . . . . . . . . . . 5
-   References . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Security Considerations  . . . . . . . . . . . . . . . . . . 6
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . 7
-
-
-
-
-
-
-Rescorla                     Informational                      [Page 1]
-
-RFC 2818                     HTTP Over TLS                      May 2000
-
-
-1.  Introduction
-
-   HTTP [RFC2616] was originally used in the clear on the Internet.
-   However, increased use of HTTP for sensitive applications has
-   required security measures. SSL, and its successor TLS [RFC2246] were
-   designed to provide channel-oriented security. This document
-   describes how to use HTTP over TLS.
-
-1.1.  Requirements Terminology
-
-   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
-   "MAY" that appear in this document are to be interpreted as described
-   in [RFC2119].
-
-2.  HTTP Over TLS
-
-   Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
-   precisely as you would use HTTP over TCP.
-
-2.1.  Connection Initiation
-
-   The agent acting as the HTTP client should also act as the TLS
-   client.  It should initiate a connection to the server on the
-   appropriate port and then send the TLS ClientHello to begin the TLS
-   handshake. When the TLS handshake has finished. The client may then
-   initiate the first HTTP request.  All HTTP data MUST be sent as TLS
-   "application data".  Normal HTTP behavior, including retained
-   connections should be followed.
-
-2.2.  Connection Closure
-
-   TLS provides a facility for secure connection closure. When a valid
-   closure alert is received, an implementation can be assured that no
-   further data will be received on that connection.  TLS
-   implementations MUST initiate an exchange of closure alerts before
-   closing a connection. A TLS implementation MAY, after sending a
-   closure alert, close the connection without waiting for the peer to
-   send its closure alert, generating an "incomplete close".  Note that
-   an implementation which does this MAY choose to reuse the session.
-   This SHOULD only be done when the application knows (typically
-   through detecting HTTP message boundaries) that it has received all
-   the message data that it cares about.
-
-   As specified in [RFC2246], any implementation which receives a
-   connection close without first receiving a valid closure alert (a
-   "premature close") MUST NOT reuse that session.  Note that a
-   premature close does not call into question the security of the data
-   already received, but simply indicates that subsequent data might
-
-
-
-Rescorla                     Informational                      [Page 2]
-
-RFC 2818                     HTTP Over TLS                      May 2000
-
-
-   have been truncated. Because TLS is oblivious to HTTP
-   request/response boundaries, it is necessary to examine the HTTP data
-   itself (specifically the Content-Length header) to determine whether
-   the truncation occurred inside a message or between messages.
-
-2.2.1.  Client Behavior
-
-   Because HTTP uses connection closure to signal end of server data,
-   client implementations MUST treat any premature closes as errors and
-   the data received as potentially truncated.  While in some cases the
-   HTTP protocol allows the client to find out whether truncation took
-   place so that, if it received the complete reply, it may tolerate
-   such errors following the principle to "[be] strict when sending and
-   tolerant when receiving" [RFC1958], often truncation does not show in
-   the HTTP protocol data; two cases in particular deserve special note:
-
-     A HTTP response without a Content-Length header. Since data length
-     in this situation is signalled by connection close a premature
-     close generated by the server cannot be distinguished from a
-     spurious close generated by an attacker.
-
-     A HTTP response with a valid Content-Length header closed before
-     all data has been read. Because TLS does not provide document
-     oriented protection, it is impossible to determine whether the
-     server has miscomputed the Content-Length or an attacker has
-     truncated the connection.
-
-   There is one exception to the above rule. When encountering a
-   premature close, a client SHOULD treat as completed all requests for
-   which it has received as much data as specified in the Content-Length
-   header.
-
-   A client detecting an incomplete close SHOULD recover gracefully.  It
-   MAY resume a TLS session closed in this fashion.
-
-   Clients MUST send a closure alert before closing the connection.
-   Clients which are unprepared to receive any more data MAY choose not
-   to wait for the server's closure alert and simply close the
-   connection, thus generating an incomplete close on the server side.
-
-2.2.2.  Server Behavior
-
-   RFC 2616 permits an HTTP client to close the connection at any time,
-   and requires servers to recover gracefully.  In particular, servers
-   SHOULD be prepared to receive an incomplete close from the client,
-   since the client can often determine when the end of server data is.
-   Servers SHOULD be willing to resume TLS sessions closed in this
-   fashion.
-
-
-
-Rescorla                     Informational                      [Page 3]
-
-RFC 2818                     HTTP Over TLS                      May 2000
-
-
-   Implementation note: In HTTP implementations which do not use
-   persistent connections, the server ordinarily expects to be able to
-   signal end of data by closing the connection. When Content-Length is
-   used, however, the client may have already sent the closure alert and
-   dropped the connection.
-
-   Servers MUST attempt to initiate an exchange of closure alerts with
-   the client before closing the connection. Servers MAY close the
-   connection after sending the closure alert, thus generating an
-   incomplete close on the client side.
-
-2.3.  Port Number
-
-   The first data that an HTTP server expects to receive from the client
-   is the Request-Line production. The first data that a TLS server (and
-   hence an HTTP/TLS server) expects to receive is the ClientHello.
-   Consequently, common practice has been to run HTTP/TLS over a
-   separate port in order to distinguish which protocol is being used.
-   When HTTP/TLS is being run over a TCP/IP connection, the default port
-   is 443. This does not preclude HTTP/TLS from being run over another
-   transport. TLS only presumes a reliable connection-oriented data
-   stream.
-
-2.4.  URI Format
-
-   HTTP/TLS is differentiated from HTTP URIs by using the 'https'
-   protocol identifier in place of the 'http' protocol identifier. An
-   example URI specifying HTTP/TLS is:
-
-     https://www.example.com/~smith/home.html
-
-3.  Endpoint Identification
-
-3.1.  Server Identity
-
-   In general, HTTP/TLS requests are generated by dereferencing a URI.
-   As a consequence, the hostname for the server is known to the client.
-   If the hostname is available, the client MUST check it against the
-   server's identity as presented in the server's Certificate message,
-   in order to prevent man-in-the-middle attacks.
-
-   If the client has external information as to the expected identity of
-   the server, the hostname check MAY be omitted. (For instance, a
-   client may be connecting to a machine whose address and hostname are
-   dynamic but the client knows the certificate that the server will
-   present.) In such cases, it is important to narrow the scope of
-   acceptable certificates as much as possible in order to prevent man
-
-
-
-
-Rescorla                     Informational                      [Page 4]
-
-RFC 2818                     HTTP Over TLS                      May 2000
-
-
-   in the middle attacks.  In special cases, it may be appropriate for
-   the client to simply ignore the server's identity, but it must be
-   understood that this leaves the connection open to active attack.
-
-   If a subjectAltName extension of type dNSName is present, that MUST
-   be used as the identity. Otherwise, the (most specific) Common Name
-   field in the Subject field of the certificate MUST be used. Although
-   the use of the Common Name is existing practice, it is deprecated and
-   Certification Authorities are encouraged to use the dNSName instead.
-
-   Matching is performed using the matching rules specified by
-   [RFC2459].  If more than one identity of a given type is present in
-   the certificate (e.g., more than one dNSName name, a match in any one
-   of the set is considered acceptable.) Names may contain the wildcard
-   character * which is considered to match any single domain name
-   component or component fragment. E.g., *.a.com matches foo.a.com but
-   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
-
-   In some cases, the URI is specified as an IP address rather than a
-   hostname. In this case, the iPAddress subjectAltName must be present
-   in the certificate and must exactly match the IP in the URI.
-
-   If the hostname does not match the identity in the certificate, user
-   oriented clients MUST either notify the user (clients MAY give the
-   user the opportunity to continue with the connection in any case) or
-   terminate the connection with a bad certificate error. Automated
-   clients MUST log the error to an appropriate audit log (if available)
-   and SHOULD terminate the connection (with a bad certificate error).
-   Automated clients MAY provide a configuration setting that disables
-   this check, but MUST provide a setting which enables it.
-
-   Note that in many cases the URI itself comes from an untrusted
-   source. The above-described check provides no protection against
-   attacks where this source is compromised. For example, if the URI was
-   obtained by clicking on an HTML page which was itself obtained
-   without using HTTP/TLS, a man in the middle could have replaced the
-   URI.  In order to prevent this form of attack, users should carefully
-   examine the certificate presented by the server to determine if it
-   meets their expectations.
-
-3.2.  Client Identity
-
-   Typically, the server has no external knowledge of what the client's
-   identity ought to be and so checks (other than that the client has a
-   certificate chain rooted in an appropriate CA) are not possible. If a
-   server has such knowledge (typically from some source external to
-   HTTP or TLS) it SHOULD check the identity as described above.
-
-
-
-
-Rescorla                     Informational                      [Page 5]
-
-RFC 2818                     HTTP Over TLS                      May 2000
-
-
-References
-
-   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-             Public Key Infrastructure: Part I: X.509 Certificate and
-             CRL Profile", RFC 2459, January 1999.
-
-   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
-             L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
-             Protocol, HTTP/1.1", RFC 2616, June 1999.
-
-   [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
-             January 1999.
-
-   [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
-             HTTP/1.1", RFC 2817, May 2000.
-
-Security Considerations
-
-   This entire document is about security.
-
-Author's Address
-
-   Eric Rescorla
-   RTFM, Inc.
-   30 Newell Road, #16
-   East Palo Alto, CA 94303
-
-   Phone: (650) 328-8631
-   EMail: ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                     Informational                      [Page 6]
-
-RFC 2818                     HTTP Over TLS                      May 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla                     Informational                      [Page 7]
-
diff --git a/doc/protocol/rfc2945.txt b/doc/protocol/rfc2945.txt
deleted file mode 100644
index 983c441c35..0000000000
--- a/doc/protocol/rfc2945.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                              T. Wu
-Request for Comments: 2945                           Stanford University
-Category: Standards Track                                 September 2000
-
-
-             The SRP Authentication and Key Exchange System
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document describes a cryptographically strong network
-   authentication mechanism known as the Secure Remote Password (SRP)
-   protocol.  This mechanism is suitable for negotiating secure
-   connections using a user-supplied password, while eliminating the
-   security problems traditionally associated with reusable passwords.
-   This system also performs a secure key exchange in the process of
-   authentication, allowing security layers (privacy and/or integrity
-   protection) to be enabled during the session.  Trusted key servers
-   and certificate infrastructures are not required, and clients are not
-   required to store or manage any long-term keys.  SRP offers both
-   security and deployment advantages over existing challenge-response
-   techniques, making it an ideal drop-in replacement where secure
-   password authentication is needed.
-
-1. Introduction
-
-   The lack of a secure authentication mechanism that is also easy to
-   use has been a long-standing problem with the vast majority of
-   Internet protocols currently in use.  The problem is two-fold: Users
-   like to use passwords that they can remember, but most password-based
-   authentication systems offer little protection against even passive
-   attackers, especially if weak and easily-guessed passwords are used.
-
-   Eavesdropping on a TCP/IP network can be carried out very easily and
-   very effectively against protocols that transmit passwords in the
-   clear.  Even so-called "challenge-response" techniques like the one
-   described in [RFC 2095] and [RFC 1760], which are designed to defeat
-
-
-
-Wu                          Standards Track                     [Page 1]
-
-RFC 2945        SRP Authentication & Key Exchange System  September 2000
-
-
-   simple sniffing attacks, can be compromised by what is known as a
-   "dictionary attack".  This occurs when an attacker captures the
-   messages exchanged during a legitimate run of the protocol and uses
-   that information to verify a series of guessed passwords taken from a
-   precompiled "dictionary" of common passwords.  This works because
-   users often choose simple, easy-to-remember passwords, which
-   invariably are also easy to guess.
-
-   Many existing mechanisms also require the password database on the
-   host to be kept secret because the password P or some private hash
-   h(P) is stored there and would compromise security if revealed.  That
-   approach often degenerates into "security through obscurity" and goes
-   against the UNIX convention of keeping a "public" password file whose
-   contents can be revealed without destroying system security.
-
-   SRP meets the strictest requirements laid down in [RFC 1704] for a
-   non-disclosing authentication protocol.  It offers complete
-   protection against both passive and active attacks, and accomplishes
-   this efficiently using a single Diffie-Hellman-style round of
-   computation, making it feasible to use in both interactive and non-
-   interactive authentication for a wide range of Internet protocols.
-   Since it retains its security when used with low-entropy passwords,
-   it can be seamlessly integrated into existing user applications.
-
-2. Conventions and Terminology
-
-   The protocol described by this document is sometimes referred to as
-   "SRP-3" for historical purposes.  This particular protocol is
-   described in [SRP] and is believed to have very good logical and
-   cryptographic resistance to both eavesdropping and active attacks.
-
-   This document does not attempt to describe SRP in the context of any
-   particular Internet protocol; instead it describes an abstract
-   protocol that can be easily fitted to a particular application.  For
-   example, the specific format of messages (including padding) is not
-   specified.  Those issues have been left to the protocol implementor
-   to decide.
-
-   The one implementation issue worth specifying here is the mapping
-   between strings and integers.  Internet protocols are byte-oriented,
-   while SRP performs algebraic operations on its messages, so it is
-   logical to define at least one method by which integers can be
-   converted into a string of bytes and vice versa.
-
-   An n-byte string S can be converted to an integer as follows:
-
-   i = S[n-1] + 256 * S[n-2] + 256^2 * S[n-3] + ... + 256^(n-1) * S[0]
-
-
-
-
-Wu                          Standards Track                     [Page 2]
-
-RFC 2945        SRP Authentication & Key Exchange System  September 2000
-
-
-   where i is the integer and S[x] is the value of the x'th byte of S.
-   In human terms, the string of bytes is the integer expressed in base
-   256, with the most significant digit first.  When converting back to
-   a string, S[0] must be non-zero (padding is considered to be a
-   separate, independent process).  This conversion method is suitable
-   for file storage, in-memory representation, and network transmission
-   of large integer values.  Unless otherwise specified, this mapping
-   will be assumed.
-
-   If implementations require padding a string that represents an
-   integer value, it is recommended that they use zero bytes and add
-   them to the beginning of the string.  The conversion back to integer
-   automatically discards leading zero bytes, making this padding scheme
-   less prone to error.
-
-   The SHA hash function, when used in this document, refers to the
-   SHA-1 message digest algorithm described in [SHA1].
-
-3. The SRP-SHA1 mechanism
-
-   This section describes an implementation of the SRP authentication
-   and key-exchange protocol that employs the SHA hash function to
-   generate session keys and authentication proofs.
-
-   The host stores user passwords as triplets of the form
-
-        { <username>, <password verifier>, <salt> }
-
-   Password entries are generated as follows:
-
-        <salt> = random()
-        x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
-        <password verifier> = v = g^x % N
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.  Most implementations perform the exponentiation and
-   remainder in a single stage to avoid generating unwieldy intermediate
-   results.  Note that the 160-bit output of SHA is implicitly converted
-   to an integer before it is operated upon.
-
-   Authentication is generally initiated by the client.
-
-      Client                             Host
-     --------                           ------
-      U = <username>              -->
-                                     <--    s = <salt from passwd file>
-
-
-
-
-Wu                          Standards Track                     [Page 3]
-
-RFC 2945        SRP Authentication & Key Exchange System  September 2000
-
-
-   Upon identifying himself to the host, the client will receive the
-   salt stored on the host under his username.
-
-      a = random()
-      A = g^a % N                 -->
-                                         v = <stored password verifier>
-                                         b = random()
-                                  <--    B = (v + g^b) % N
-
-      p = <raw password>
-      x = SHA(s | SHA(U | ":" | p))
-
-      S = (B - g^x) ^ (a + u * x) % N    S = (A * v^u) ^ b % N
-      K = SHA_Interleave(S)              K = SHA_Interleave(S)
-      (this function is described
-       in the next section)
-
-   The client generates a random number, raises g to that power modulo
-   the field prime, and sends the result to the host.  The host does the
-   same thing and also adds the public verifier before sending it to the
-   client.  Both sides then construct the shared session key based on
-   the respective formulae.
-
-   The parameter u is a 32-bit unsigned integer which takes its value
-   from the first 32 bits of the SHA1 hash of B, MSB first.
-
-   The client MUST abort authentication if B % N is zero.
-
-   The host MUST abort the authentication attempt if A % N is zero.  The
-   host MUST send B after receiving A from the client, never before.
-
-   At this point, the client and server should have a common session key
-   that is secure (i.e. not known to an outside party).  To finish
-   authentication, they must prove to each other that their keys are
-   identical.
-
-        M = H(H(N) XOR H(g) | H(U) | s | A | B | K)
-                                    -->
-                                    <--    H(A | M | K)
-
-   The server will calculate M using its own K and compare it against
-   the client's response.  If they do not match, the server MUST abort
-   and signal an error before it attempts to answer the client's
-   challenge.  Not doing so could compromise the security of the user's
-   password.
-
-
-
-
-
-
-Wu                          Standards Track                     [Page 4]
-
-RFC 2945        SRP Authentication & Key Exchange System  September 2000
-
-
-   If the server receives a correct response, it issues its own proof to
-   the client.  The client will compute the expected response using its
-   own K to verify the authenticity of the server.  If the client
-   responded correctly, the server MUST respond with its hash value.
-
-   The transactions in this protocol description do not necessarily have
-   a one-to-one correspondence with actual protocol messages.  This
-   description is only intended to illustrate the relationships between
-   the different parameters and how they are computed.  It is possible,
-   for example, for an implementation of the SRP-SHA1 mechanism to
-   consolidate some of the flows as follows:
-
-        Client                             Host
-       --------                           ------
-        U, A                        -->
-                                    <--    s, B
-        H(H(N) XOR H(g) | H(U) | s | A | B | K)
-                                    -->
-                                    <--    H(A | M | K)
-
-   The values of N and g used in this protocol must be agreed upon by
-   the two parties in question.  They can be set in advance, or the host
-   can supply them to the client.  In the latter case, the host should
-   send the parameters in the first message along with the salt.  For
-   maximum security, N should be a safe prime (i.e. a number of the form
-   N = 2q + 1, where q is also prime).  Also, g should be a generator
-   modulo N (see [SRP] for details), which means that for any X where 0
-   < X < N, there exists a value x for which g^x % N == X.
-
-3.1.  Interleaved SHA
-
-   The SHA_Interleave function used in SRP-SHA1 is used to generate a
-   session key that is twice as long as the 160-bit output of SHA1.  To
-   compute this function, remove all leading zero bytes from the input.
-   If the length of the resulting string is odd, also remove the first
-   byte.  Call the resulting string T.  Extract the even-numbered bytes
-   into a string E and the odd-numbered bytes into a string F, i.e.
-
-     E = T[0] | T[2] | T[4] | ...
-     F = T[1] | T[3] | T[5] | ...
-
-   Both E and F should be exactly half the length of T.  Hash each one
-   with regular SHA1, i.e.
-
-     G = SHA(E)
-     H = SHA(F)
-
-
-
-
-
-Wu                          Standards Track                     [Page 5]
-
-RFC 2945        SRP Authentication & Key Exchange System  September 2000
-
-
-   Interleave the two hashes back together to form the output, i.e.
-
-     result = G[0] | H[0] | G[1] | H[1] | ... | G[19] | H[19]
-
-   The result will be 40 bytes (320 bits) long.
-
-3.2.  Other Hash Algorithms
-
-   SRP can be used with hash functions other than SHA.  If the hash
-   function produces an output of a different length than SHA (20
-   bytes), it may change the length of some of the messages in the
-   protocol, but the fundamental operation will be unaffected.
-
-   Earlier versions of the SRP mechanism used the MD5 hash function,
-   described in [RFC 1321].  Keyed hash transforms are also recommended
-   for use with SRP; one possible construction uses HMAC [RFC 2104],
-   using K to key the hash in each direction instead of concatenating it
-   with the other parameters.
-
-   Any hash function used with SRP should produce an output of at least
-   16 bytes and have the property that small changes in the input cause
-   significant nonlinear changes in the output.  [SRP] covers these
-   issues in more depth.
-
-4. Security Considerations
-
-   This entire memo discusses an authentication and key-exchange system
-   that protects passwords and exchanges keys across an untrusted
-   network.  This system improves security by eliminating the need to
-   send cleartext passwords over the network and by enabling encryption
-   through its secure key-exchange mechanism.
-
-   The private values for a and b correspond roughly to the private
-   values in a Diffie-Hellman exchange and have similar constraints of
-   length and entropy.  Implementations may choose to increase the
-   length of the parameter u, as long as both client and server agree,
-   but it is not recommended that it be shorter than 32 bits.
-
-   SRP has been designed not only to counter the threat of casual
-   password-sniffing, but also to prevent a determined attacker equipped
-   with a dictionary of passwords from guessing at passwords using
-   captured network traffic.  The SRP protocol itself also resists
-   active network attacks, and implementations can use the securely
-   exchanged keys to protect the session against hijacking and provide
-   confidentiality.
-
-
-
-
-
-
-Wu                          Standards Track                     [Page 6]
-
-RFC 2945        SRP Authentication & Key Exchange System  September 2000
-
-
-   SRP also has the added advantage of permitting the host to store
-   passwords in a form that is not directly useful to an attacker.  Even
-   if the host's password database were publicly revealed, the attacker
-   would still need an expensive dictionary search to obtain any
-   passwords.  The exponential computation required to validate a guess
-   in this case is much more time-consuming than the hash currently used
-   by most UNIX systems.  Hosts are still advised, though, to try their
-   best to keep their password files secure.
-
-5. References
-
-   [RFC 1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-               April 1992.
-
-   [RFC 1704]  Haller, N. and R. Atkinson, "On Internet Authentication",
-               RFC 1704, October 1994.
-
-   [RFC 1760]  Haller, N., "The S/Key One-Time Password System", RFC
-               1760, Feburary 1995.
-
-   [RFC 2095]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
-               AUTHorize Extension for Simple Challenge/Response", RFC
-               2095, January 1997.
-
-   [RFC 2104]  Krawczyk, H., Bellare, M. and  R. Canetti, "HMAC: Keyed-
-               Hashing for Message Authentication", RFC 2104, February
-               1997.
-
-   [SHA1]      National Institute of Standards and Technology (NIST),
-               "Announcing the Secure Hash Standard", FIPS 180-1, U.S.
-               Department of Commerce, April 1995.
-
-   [SRP]       T. Wu, "The Secure Remote Password Protocol", In
-               Proceedings of the 1998 Internet Society Symposium on
-               Network and Distributed Systems Security, San Diego, CA,
-               pp. 97-111.
-
-6. Author's Address
-
-   Thomas Wu
-   Stanford University
-   Stanford, CA 94305
-
-   EMail: tjw@cs.Stanford.EDU
-
-
-
-
-
-
-
-Wu                          Standards Track                     [Page 7]
-
-RFC 2945        SRP Authentication & Key Exchange System  September 2000
-
-
-7.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wu                          Standards Track                     [Page 8]
-
diff --git a/doc/protocol/rfc2985.txt b/doc/protocol/rfc2985.txt
deleted file mode 100644
index bf9fd84889..0000000000
--- a/doc/protocol/rfc2985.txt
+++ /dev/null
@@ -1,2355 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Nystrom
-Request for Comments: 2985                                      B. Kaliski
-Category: Informational                                       RSA Security
-                                                             November 2000
-
-
-          PKCS #9: Selected Object Classes and Attribute Types
-                              Version 2.0
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This memo represents a republication of PKCS #9 v2.0 from RSA
-   Laboratories' Public-Key Cryptography Standards (PKCS) series, and
-   change control is retained within the PKCS process.  The body of this
-   document, except for the security considerations section, is taken
-   directly from that specification.
-
-   This memo provides a selection of object classes and attribute types
-   for use in conjunction with public-key cryptography and Lightweight
-   Directory Access Protocol (LDAP) accessible directories.  It also
-   includes ASN.1 syntax for all constructs.
-
-Table of Contents
-
-   1.  Introduction ................................................. 2
-   2.  Definitions, notation and document convention ................ 2
-   2.1  Definitions ................................................. 2
-   2.2  Notation and document convention ............................ 3
-   3.  Overview ..................................................... 4
-   4.  Auxiliary object classes ..................................... 5
-   4.1  The "pkcsEntity" auxiliary object class ..................... 5
-   4.2  The "naturalPerson" auxiliary object class .................. 6
-   5.  Selected attribute types ..................................... 6
-   5.1  Attribute types for use with the "pkcsEntity" object class .. 6
-   5.2  Attribute types for use with the "naturalPerson" object class 7
-   5.3  Attribute types for use in PKCS #7 data .................... 12
-   5.4  Attribute types for use in PKCS #10 certificate requests ... 16
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 1]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   5.5  Attribute types for use in PKCS #12 "PFX" PDUs or PKCS #15
-        tokens ..................................................... 17
-   5.6  Attributes defined in S/MIMIE .............................. 18
-   6.  Matching rules .............................................. 19
-   6.1  Case ignore match .......................................... 19
-   6.2  Signing time match ......................................... 20
-   7.  Security Considerations ..................................... 20
-   8.  Authors' Addresses .......................................... 21
-   A.  ASN.1 module ................................................ 22
-   B.  BNF schema summary .......................................... 30
-   B.1  Syntaxes ................................................... 30
-   B.2  Object classes ............................................. 31
-   B.3  Attribute types ............................................ 32
-   B.4  Matching rules ............................................. 36
-   C.  Intellectual property considerations ........................ 37
-   D.  Revision history ............................................ 37
-   E.  References .................................................. 39
-   F.  Contact information & About PKCS ............................ 41
-   Full Copyright Statement ........................................ 41
-
-1. Introduction
-
-   This document defines two new auxiliary object classes, pkcsEntity
-   and naturalPerson, and selected attribute types for use with these
-   classes.  It also defines some attribute types for use in conjunction
-   with PKCS #7 [14] (and S/MIME CMS [3]) digitally signed messages,
-   PKCS #10 [16] certificate-signing requests, PKCS #12 [17] personal
-   information exchanges and PKCS #15 [18] cryptographic tokens.
-   Matching rules for use with these attributes are also defined,
-   whenever necessary.
-
-2. Definitions, notation and document conventions
-
- 2.1 Definitions
-
-   For the purposes of this document, the following definitions apply.
-
-   ASN.1           Abstract Syntax Notation One, as defined in [5].
-
-   Attributes      An ASN.1 type that specifies a set of attributes.
-                   Each attribute contains an attribute type (specified
-                   by object identifier) and one or more attribute
-                   values.  Some attribute types are restricted in their
-                   definition to have a single value; others may have
-                   multiple values.  This type is defined in [7].
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 2]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   CertificationRequestInfo
-                   An ASN.1 type that specifies a subject name, a public
-                   key, and a set of attributes.  This type is defined
-                   in [16].
-
-   ContentInfo     An ASN.1 type that specifies content exchanged
-                   between entities.  The contentType field, which has
-                   type OBJECT IDENTIFIER, specifies the content type,
-                   and the content field, whose type is defined by the
-                   contentType field, contains the content value.  This
-                   type is defined in [14] and [3].
-
-   PrivateKeyInfo  A type that specifies a private key and a set of
-                   extended attributes.  This type and the associated
-                   EncryptedPrivateKeyInfo type are defined in [15].
-
-   SignerInfo      A type that specifies per-signer information in the
-                   signed-data content type, including a set of
-                   attributes authenticated by the signer, and a set of
-                   attributes not authenticated by the signer.  This
-                   type is defined in [14] and [3].
-
-   DER             Distinguished Encoding Rules for ASN.1, as defined in
-                   [6].
-
-   UCS             Universal Multiple-Octet Coded Character Set, as
-                   defined in [11].
-
-   UTF8String      UCS Transformation Format encoded string.  The UTF-8
-                   encoding is defined in [11].
-
- 2.2 Notation and document conventions
-
-   In this document, all attribute type and object class definitions are
-   written in the ASN.1 value notation defined in [5].  Appendix B
-   contains most of these definitions written in the augmented BNF
-   notation defined in [2] as well.  This has been done in an attempt to
-   simplify the task of integrating this work into LDAP [22] development
-   environments.
-
-   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [1].
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 3]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-3. Overview
-
-   This document specifies two new auxiliary object classes, pkcsEntity
-   and naturalPerson, and some new attribute types and matching rules.
-   All ASN.1 object classes, attributes, matching rules and types are
-   exported for use in other environments.
-
-   Attribute types defined in this document that are useful in
-   conjunction with storage of PKCS-related data and the pkcsEntity
-   object class includes PKCS #12 PFX PDUs, PKCS #15 tokens and
-   encrypted private keys.
-
-   Attribute types defined in this document that are useful in
-   conjunction with PKCS #10 certificate requests and the naturalPerson
-   object class includes electronic-mail address, pseudonym,
-   unstructured name, and unstructured address.
-
-   Attribute types defined in this document that are useful in PKCS #7
-   digitally signed messages are content type, message digest, signing
-   time, sequence number, random nonce and countersignature.  The
-   attributes would be used in the authenticatedAttributes and
-   unauthenticatedAttributes fields of a SignerInfo or an
-   AuthenticatedData ([3]) value.
-
-   Attribute types that are useful especially in PKCS #10 certification
-   requests are the challenge password and the extension-request
-   attribute.  The attributes would be used in the attributes field of a
-   CertificationRequestInfo value.
-
-   Note - The attributes types (from [8]) in Table 1, and probably
-   several others, might also be helpful in PKCS #10, PKCS #12 and PKCS
-   #15-aware applications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 4]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-       businessCategory            preferredDeliveryMethod
-       commonName                  presentationAddress
-       countryName                 registeredAddress
-       description                 roleOccupant
-       destinationIndicator        serialNumber
-       facsimileTelephoneNumber    stateOrProvinceName
-       iSDNAddress                 streetAddress
-       localityName                supportedApplicationContext
-       member                      surname
-       objectClass                 telephoneNumber
-       organizationName            teletexTerminalIdentifier
-       physicalDeliveryOfficeName  telexNumber
-       postalAddress               title
-       postalCode                  x121Address
-       postOfficeBox
-
-   Table 1: ISO/IEC 9594-6 attribute types useful in PKCS documents
-
-4. Auxiliary object classes
-
-   This document defines two new auxiliary object classes: pkcsEntity
-   and naturalPerson.
-
- 4.1 The pkcsEntity auxiliary object class
-
-   The pkcsEntity object class is a general-purpose auxiliary object
-   class that is intended to hold attributes about PKCS-related
-   entities.  It has been designed for use within directory services
-   based on the LDAP protocol [22] and the X.500 family of protocols,
-   where support for PKCS-defined attributes is considered useful.
-
-   pkcsEntity OBJECT-CLASS ::=     {
-           SUBCLASS OF { top }
-           KIND auxiliary
-           MAY CONTAIN { PKCSEntityAttributeSet }
-           ID pkcs-9-oc-pkcsEntity
-   }
-
-   PKCSEntityAttributeSet ATTRIBUTE ::= {
-           pKCS7PDU |
-           userPKCS12 |
-           pKCS15Token |
-           encryptedPrivateKeyInfo,
-           ... -- For future extensions
-   }
-
-   Attributes in the PKCSEntityAttributeSet are defined in Section 5.
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 5]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
- 4.2 The naturalPerson auxiliary object class
-
-   The naturalPerson object class is a general-purpose auxiliary object
-   class that is intended to hold attributes about human beings.  It has
-   been designed for use within directory services based on the LDAP
-   protocol [22] and the X.500 family of protocols, where support for
-   these attributes is considered useful.
-
-   naturalPerson OBJECT-CLASS      ::=     {
-           SUBCLASS OF { top }
-           KIND auxiliary
-           MAY CONTAIN { NaturalPersonAttributeSet }
-           ID pkcs-9-oc-naturalPerson
-   }
-
-   NaturalPersonAttributeSet ATTRIBUTE ::= {
-           emailAddress |
-           unstructuredName |
-           unstructuredAddress |
-           dateOfBirth |
-           placeOfBirth |
-           gender |
-           countryOfCitizenship |
-           countryOfResidence |
-           pseudonym |
-           serialNumber,
-           ... -- For future extensions
-   }
-
-   Attributes in the NaturalPersonAttributeSet are defined in Section 5.
-
-5. Selected attribute types
-
- 5.1 Attribute types for use with the "pkcsEntity" object class
-
-  5.1.1 PKCS #7 PDU
-
-   PKCS #7 provides several formats for enveloped, signed and otherwise
-   protected data.  When such information is stored in a directory
-   service, the pKCS7PDU attribute may be used.
-
-   pKCS7PDU ATTRIBUTE ::= {
-           WITH SYNTAX ContentInfo
-           ID pkcs-9-at-pkcs7PDU
-   }
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 6]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  5.1.2 PKCS #12 token
-
-   PKCS #12 provides a format for exchange of personal identity
-   information.  When such information is stored in a directory service,
-   the userPKCS12 attribute should be used.
-
-   userPKCS12 ATTRIBUTE ::= {
-           WITH SYNTAX PFX
-           ID pkcs-9-at-userPKCS12
-   }
-
-   This type was originally defined in [20].
-
-  5.1.3 PKCS #15 token
-
-   PKCS #15 provides a format for cryptographic tokens.  When software
-   variants of such tokens are stored in a directory service, the
-   pKCS15Token attribute should be used.
-
-   pKCS15Token ATTRIBUTE ::= {
-           WITH SYNTAX PKCS15Token
-           ID pkcs-9-at-pkcs15Token
-   }
-
-  5.1.4 PKCS #8 encrypted private key information
-
-   PKCS #8 provides a format for encrypted private keys.  When such
-   information is stored in a directory service, the
-   encryptedPrivateKeyInfo attribute should be used.
-
-   encryptedPrivateKeyInfo ATTRIBUTE ::= {
-           WITH SYNTAX EncryptedPrivateKeyInfo
-           ID pkcs-9-at-encryptedPrivateKeyInfo
-   }
-
- 5.2 Attribute types for use with the "naturalPerson" object class
-
-  5.2.1 Electronic-mail address
-
-   The emailAddress attribute type specifies the electronic-mail address
-   or addresses of a subject as an unstructured ASCII string.  The
-   interpretation of electronic-mail addresses is intended to be
-   specified by certificate issuers etc.; no particular interpretation
-   is required.
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 7]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   emailAddress ATTRIBUTE ::= {
-           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-emailAddress))
-           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
-           ID pkcs-9-at-emailAdress
-   }
-
-   An electronic-mail address attribute can have multiple attribute
-   values.  When comparing two email addresses, case is irrelevant.  The
-   pkcs9CaseIgnoreMatch is defined in Section 6.
-
-   Note - It is likely that other standards bodies overseeing
-   electronic-mail systems will, or have, registered electronic-mail
-   address attribute types specific to their system.  The electronic-
-   mail address attribute type defined here was intended as a short-term
-   substitute for those specific attribute types, but is included here
-   for backwards-compatibility reasons.
-
-  5.2.2 Unstructured name
-
-   The unstructuredName attribute type specifies the name or names of a
-   subject as an unstructured ASCII string.  The interpretation of
-   unstructured names is intended to be specified by certificate issuers
-   etc.; no particular interpretation is required.
-
-   unstructuredName ATTRIBUTE ::= {
-           WITH SYNTAX PKCS9String {pkcs-9-ub-unstructuredName}
-           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
-           ID pkcs-9-at-unstructuredName
-   }
-
-   PKCS9String { INTEGER : maxSize} ::= CHOICE {
-           ia5String       IA5String (SIZE(1..maxSize)),
-           directoryString DirectoryString {maxSize}
-   }
-
-   An unstructured-name attribute can have multiple attribute values.
-   When comparing two unstructured names, case is irrelevant.
-
-   The PKCS9String type is defined as a choice of IA5String and
-   DirectoryString.  Applications SHOULD use the IA5String type when
-   generating attribute values in accordance with this version of this
-   document, unless internationalization issues makes this impossible.
-   In that case, the UTF8String alternative of the DirectoryString
-   alternative is the preferred choice.  PKCS #9-attribute processing
-   systems MUST be able to recognize and process all string types in
-   PKCS9String values.
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 8]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   Note - Version 1.1 of this document defined unstructuredName as
-   having the syntax IA5String, but did contain a note explaining that
-   this might be changed to a CHOICE of different string types in future
-   versions.  To better accommodate international names, this type has
-   been extended to also include a directory string in this version of
-   this document.  Since [21] does not support a directory string type
-   containing IA5Strings, a separate syntax object identifier has been
-   defined (see [21] and Appendix B).
-
-  5.2.3 Unstructured address
-
-   The unstructuredAddress attribute type specifies the address or
-   addresses of a subject as an unstructured directory string.  The
-   interpretation of unstructured addresses is intended to be specified
-   by certificate issuers etc; no particular interpretation is required.
-   A likely interpretation is as an alternative to the postalAddress
-   attribute type defined in [8].
-
-   unstructuredAddress ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-unstructuredAddress}
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           ID pkcs-9-at-unstructuredAddress
-   }
-
-   An unstructured-address attribute can have multiple attribute values.
-   The caseIgnoreMatch matching rule is defined in [8].
-
-   Note 1 - It is recommended to use the ASN.1 type TeletexString's
-   new-line character (hexadecimal code 0d) as a line separator in
-   multi-line addresses.
-
-   Note 2 - Previous versions of this document defined
-   unstructuredAddress as having the following syntax:
-
-   CHOICE {
-           teletexString TeletexString,
-           printableString PrintableString,
-   }
-
-   But also mentioned the possibility of a future definition as follows:
-
-   CHOICE {
-           teletexString TeletexString,
-           printableString PrintableString,
-           universalString UniversalString
-   }
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 9]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   In this version of this document, the X.520 type DirectoryString has
-   been used in order to be more aligned with international standards
-   and current practice.  When generating attribute values in accordance
-   with this version of this document, applications SHOULD use the
-   PrintableString alternative unless internationalization issues makes
-   this impossible.  In those cases, the UTF8String alternative SHOULD
-   be used.  PKCS #9-attribute processing systems MUST be able to
-   recognize and process all string types in DirectoryString values.
-
-  5.2.4 Date of birth
-
-   The dateOfBirth attribute specifies the date of birth for the subject
-   it is associated with.
-
-   dateOfBirth ATTRIBUTE ::= {
-           WITH SYNTAX GeneralizedTime
-           EQUALITY MATCHING RULE generalizedTimeMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-dateOfBirth
-   }
-
-   dateOfBirth attributes must be single-valued.  The
-   generalizedTimeMatch matching rule is defined in [8].
-
-  5.2.5 Place of birth
-
-   The placeOfBirth attribute specifies the place of birth for the
-   subject it is associated with.
-
-   placeOfBirth ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-placeOfBirth}
-           EQUALITY MATCHING RULE caseExactMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-placeOfBirth
-   }
-
-   placeOfBirth attributes must be single-valued.  The caseExactMatch
-   matching rule is defined in [8].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 10]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  5.2.6 Gender
-
-   The gender attribute specifies the gender of the subject it is
-   associated with.
-
-   gender ATTRIBUTE ::= {
-           WITH SYNTAX PrintableString (SIZE(1) ^
-                       FROM ("M" | "F" | "m" | "f"))
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-gender
-   }
-
-   The letter "M" (or "m") represents "male" and the letter "F" (or "f")
-   represents "female".  gender attributes must be single-valued.
-
-  5.2.7 Country of citizenship
-
-   The countryOfCitizenship attribute specifies the (claimed) countries
-   of citizenship for the subject it is associated with.  It SHALL be a
-   2-letter acronym of a country in accordance with [4].
-
-   countryOfCitizenship ATTRIBUTE ::= {
-           WITH SYNTAX PrintableString (SIZE(2) ^ CONSTRAINED BY {
-           -- Must be a two-letter country acronym in accordance with
-           -- ISO/IEC 3166 --})
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           ID pkcs-9-at-countryOfCitizenship
-   }
-
-   Attributes of this type need not be single-valued.
-
-  5.2.8 Country of residence
-
-   The countryOfResidence attribute specifies the (claimed) country of
-   residence for the subject is associated with.  It SHALL be a 2-letter
-   acronym of a country in accordance with [4].
-
-   countryOfResidence ATTRIBUTE ::= {
-           WITH SYNTAX PrintableString (SIZE(2) ^ CONSTRAINED BY {
-           -- Must be a two-letter country acronym in accordance with
-           -- ISO/IEC 3166 --})
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           ID pkcs-9-at-countryOfResidence
-   }
-
-   Attributes of this type need not be single-valued, since it is
-   possible to be a resident of several countries.
-
-
-
-Nystrom & Kaliski            Informational                     [Page 11]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  5.2.9 Pseudonym
-
-   The pseudonym attribute type shall contain a pseudonym of a subject.
-   The exact interpretation of pseudonyms is intended to be specified by
-   certificate issuers etc.; no particular interpretation is required.
-
-   pseudonym ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-pseudonym}
-           EQUALITY MATCHING RULE caseExactMatch
-           ID id-at-pseudonym
-   }
-
-   Note - The pseudonym attribute has received an object identifier in
-   the joint-iso-itu-t object identifier tree.
-
-   The caseExactMatch matching rule is defined in [8].
-
-  5.2.10 Serial number
-
-   The serialNumber attribute is defined in [8].
-
- 5.3 Attribute types for use in PKCS #7 data
-
-  5.3.1 Content type
-
-   The contentType attribute type specifies the content type of the
-   ContentInfo value being signed in PKCS #7 (or S/MIME CMS) digitally
-   signed data.  In such data, the contentType attribute type is
-   required if there are any PKCS #7 authenticated attributes.
-
-   contentType ATTRIBUTE ::= {
-           WITH SYNTAX ContentType
-           EQUALITY MATCHING RULE objectIdentifierMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-contentType
-   }
-
-   ContentType ::= OBJECT IDENTIFIER
-
-   As indicated, content-type attributes must have a single attribute
-   value.  For two content-type values to match, their octet string
-   representation must be of equal length and corresponding octets
-   identical.  The objectIdentifierMatch matching rule is defined in
-   [7].
-
-   Note - This attribute type is described in [3] as well.
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 12]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  5.3.2 Message digest
-
-   The messageDigest attribute type specifies the message digest of the
-   contents octets of the DER-encoding of the content field of the
-   ContentInfo value being signed in PKCS #7 digitally signed data,
-   where the message digest is computed under the signer's message
-   digest algorithm.  The message-digest attribute type is required in
-   these cases if there are any PKCS #7 authenticated attributes
-   present.
-
-   messageDigest ATTRIBUTE ::= {
-           WITH SYNTAX MessageDigest
-           EQUALITY MATCHING RULE octetStringMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-messageDigest
-   }
-
-   MessageDigest ::= OCTET STRING
-
-   As indicated, a message-digest attribute must have a single attribute
-   value.  For two messageDigest values to match, their octet string
-   representation must be of equal length and corresponding octets
-   identical.  The octetStringMatch matching rule is defined in [8].
-
-   Note - This attribute is described in [3] as well.
-
-  5.3.3 Signing time
-
-   The signingTime attribute type is intended for PKCS #7 digitally
-   signed data.  It specifies the time at which the signer (purportedly)
-   performed the signing process.
-
-   signingTime ATTRIBUTE ::= {
-           WITH SYNTAX SigningTime
-           EQUALITY MATCHING RULE signingTimeMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-signingTime
-   }
-
-   SigningTime ::= Time -- imported from ISO/IEC 9594-8
-
-   A signing-time attribute must have a single attribute value.
-
-   The signingTimeMatch matching rule (defined in Section 6.1) returns
-   TRUE if an attribute value represents the same time as a presented
-   value.
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 13]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   Quoting from [3]:
-   "Dates between 1 January 1950 and 31 December 2049 (inclusive) MUST
-   be encoded as UTCTime.  Any dates with year values before 1950 or
-   after 2049 MUST be encoded as GeneralizedTime.  [Further,] UTCTime
-   values MUST be expressed in Greenwich Mean Time (Zulu) and MUST
-   include seconds (i.e., times are YYMMDDHHMMSSZ), even where the
-   number of seconds is zero.  Midnight (GMT) must be represented as
-   "YYMMDD000000Z".  Century information is implicit, and the century
-   shall be determined as follows:
-
-   - Where YY is greater than or equal to 50, the year shall be
-     interpreted as 19YY; and
-   - Where YY is less than 50, the year shall be interpreted as 20YY.
-
-   GeneralizedTime values shall be expressed in Greenwich Mean Time
-   (Zulu) and must include seconds (i.e., times are YYYYMMDDHHMMSSZ),
-   even where the number of seconds is zero.  GeneralizedTime values
-   must not include fractional seconds."
-
-   Note 1 - The definition of SigningTime matches the definition of Time
-   specified in [10].
-
-   Note 2 - No requirement is imposed concerning the correctness of the
-   signing time, and acceptance of a purported signing time is a matter
-   of a recipient's discretion.  It is expected, however, that some
-   signers, such as time-stamp servers, will be trusted implicitly.
-
-  5.3.4 Random nonce
-
-   The randomNonce attribute type is intended for PKCS #7 digitally
-   signed data.  It may be used by a signer unable (or unwilling) to
-   specify the time at which the signing process was performed.  Used in
-   a correct manner, it will make it possible for the signer to protect
-   against certain attacks, i.e. replay attacks.
-
-   randomNonce ATTRIBUTE ::= {
-           WITH SYNTAX RandomNonce
-           EQUALITY MATCHING RULE octetStringMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-randomNonce
-   }
-
-   RandomNonce ::= OCTET STRING (SIZE(4..MAX))
-           -- At least four bytes long
-
-   A random nonce attribute must have a single attribute value.
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 14]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  5.3.5 Sequence number
-
-   The sequenceNumber attribute type is intended for PKCS #7 digitally
-   signed data.  A signer wishing to associate a sequence number to all
-   signature operations (much like a physical checkbook) may use it as
-   an alternative to the randomNonce attribute.  Used in a correct
-   manner, it will make it possible for the signer to protect against
-   certain attacks, i.e. replay attacks.
-
-   sequenceNumber ATTRIBUTE ::= {
-           WITH SYNTAX SequenceNumber
-           EQUALITY MATCHING RULE integerMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-sequenceNumber
-   }
-
-   SequenceNumber ::= INTEGER (1..MAX)
-
-   A sequence number attribute must have a single attribute value.
-
-   The integerMatch matching rule is defined in [8].
-
-  5.3.6 Countersignature
-
-   The counterSignature attribute type specifies one or more signatures
-   on the content octets of the DER encoding of the encryptedDigest
-   field of a SignerInfo value in PKCS #7 digitally signed data.  Thus,
-   the countersignature attribute type countersigns (signs in serial)
-   another signature.  The countersignature attribute must be an
-   unauthenticated PKCS #7 attribute; it cannot be an authenticated
-   attribute.
-
-   counterSignature ATTRIBUTE ::= {
-           WITH SYNTAX SignerInfo
-           ID pkcs-9-at-counterSignature
-   }
-
-   Countersignature values have the same meaning as SignerInfo values
-   for ordinary signatures (see Section 9 of [14] and Section 5.3 of
-   [3]), except that:
-
-   1. The authenticatedAttributes field must contain a messageDigest
-   attribute if it contains any other attributes, but need not contain a
-   contentType attribute, as there is no content type for
-   countersignatures; and
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 15]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   2. The input to the message-digesting process is the content octets
-   of the DER encoding of the signatureValue field of the SignerInfo
-   value with which the attribute is associated.
-
-   A countersignature attribute can have multiple attribute values.
-
-   Note 1 - The fact that a countersignature is computed on a signature
-   (encrypted digest) means that the countersigning process need not
-   know the original content input to the signing process.  This has
-   advantages both in efficiency and in confidentiality.
-
-   Note 2 - A countersignature, since it has type SignerInfo, can itself
-   contain a countersignature attribute.  Thus it is possible to
-   construct arbitrarily long series of countersignatures.
-
- 5.4 Attribute types for use with PKCS #10 certificate requests
-
-  5.4.1 Challenge password
-
-   The challengePassword attribute type specifies a password by which an
-   entity may request certificate revocation.  The interpretation of
-   challenge passwords is intended to be specified by certificate
-   issuers etc; no particular interpretation is required.
-
-   challengePassword ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-challengePassword}
-           EQUALITY MATCHING RULE caseExactMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-challengePassword
-   }
-
-   A challenge-password attribute must have a single attribute value.
-
-   ChallengePassword attribute values generated in accordance with this
-   version of this document SHOULD use the PrintableString encoding
-   whenever possible.  If internationalization issues make this
-   impossible, the UTF8String alternative SHOULD be used.  PKCS #9-
-   attribute processing systems MUST be able to recognize and process
-   all string types in DirectoryString values.
-
-   Note - Version 1.1 of this document defined challengePassword as
-   having the syntax CHOICE {PrintableString, T61String}, but did
-   contain a note explaining that this might be changed to a CHOICE of
-   different string types in the future See also Note 2 in section
-   5.2.3.
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 16]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  5.4.2 Extension request
-
-   The extensionRequest attribute type may be used to carry information
-   about certificate extensions the requester wishes to be included in a
-   certificate.
-
-   extensionRequest ATTRIBUTE ::= {
-           WITH SYNTAX ExtensionRequest
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-extensionRequest
-   }
-
-   ExtensionRequest ::= Extensions
-
-   The Extensions type is imported from [10].
-
-  5.4.3 Extended-certificate attributes (deprecated)
-
-   The extendedCertificateAttributes attribute type specified a set of
-   attributes for a PKCS #6 [13] extended certificate in a PKCS #10
-   certification request (the value of the extended certificate-
-   attributes attribute would become the extension in the requested PKCS
-   #6 extended certificate).  Since the status of PKCS #6 is historic
-   after the introduction of X.509 v3 certificates [10], the use of this
-   attribute is deprecated.
-
-   extendedCertificateAttributes ATTRIBUTE ::= {
-           WITH SYNTAX SET OF Attribute
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-extendedCertificateAttributes
-   }
-
-   An extended certificate attributes attribute must have a single
-   attribute value (that value is a set, which itself may contain
-   multiple values, but there must be only one set).
-
- 5.5 Attributes for use in PKCS #12 "PFX" PDUs or PKCS #15 tokens
-
-  5.5.1 Friendly name
-
-   The friendlyName attribute type specifies a user-friendly name of the
-   object it belongs to.  It is referenced in [17].
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 17]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   friendlyName ATTRIBUTE ::= {
-           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-friendlyName
-   }
-
-   As indicated, friendlyName attributes must have a single attribute
-   value.
-
-  5.5.2 Local key identifier
-
-   The localKeyId attribute type specifies an identifier for a
-   particular key.  It is only to be used locally in applications.  This
-   attribute is referenced in [17].
-
-   localKeyId ATTRIBUTE ::= {
-           WITH SYNTAX OCTET STRING
-           EQUALITY MATCHING RULE octetStringMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-localKeyId
-   }
-
-   As indicated, localKeyId attributes must have a single attribute
-   value.  For two localKeyId values to match, their octet string
-   representation must be of equal length and corresponding octets
-   identical.
-
- 5.6 Attributes defined in S/MIME
-
-   S/MIME (c.f. [12]) defines some attributes and object identifiers in
-   the PKCS #9 object identifier tree.  For completeness, they are
-   mentioned here.
-
-  5.6.1 Signing description
-
-   The signingDescription attribute is intended to provide a short
-   synopsis of a message that can be used to present a user with an
-   additional confirmation step before committing to a cryptographic
-   operation.  In most cases, the replication of the "Subject:" line
-   from the header of a message should be sufficient and is recommended.
-
-   signingDescription ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-signingDescription}
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-signingDescription
-   }
-
-
-
-Nystrom & Kaliski            Informational                     [Page 18]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  5.6.2 S/MIME capabilities
-
-   The syntax and semantics of the smimeCapabilities attribute is
-   defined in [12].  It is included here for the sake of completeness.
-
-   smimeCapabilities ATTRIBUTE ::= {
-           WITH SYNTAX SMIMECapabilities
-           SINGLE VALUE
-           ID pkcs-9-at-smimeCapabilities
-   }
-
-   SMIMECapabilities ::= SEQUENCE OF SMIMECapability
-
-   SMIMECapability ::= SEQUENCE {
-           algorithm  ALGORITHM.&id ({SMIMEv3Algorithms}),
-           parameters ALGORITHM.&Type ({SMIMEv3Algorithms}{@algorithm})
-   }
-
-   SMIMEv3Algorithms ALGORITHM ::= {... -- See RFC 2633 -- }
-
-6. Matching rules
-
-   This section defines matching rules used in the definition of
-   attributes in this document.
-
- 6.1 Case ignore match
-
-   The pkcs9CaseIgnoreMatch rule compares for equality a presented
-   string with an attribute value of type PKCS9String, without regard to
-   the case (upper or lower) of the strings (e.g. "Pkcs" and "PKCS"
-   match).
-
-   pkcs9CaseIgnoreMatch MATCHING-RULE ::= {
-           SYNTAX  PKCS9String {pkcs9-ub-match}
-           ID              id-mr-pkcs9CaseIgnoreMatch
-   }
-
-   The rule returns TRUE if the strings are the same length and
-   corresponding characters are identical except possibly with regard to
-   case.
-
-   Where the strings being matched are of different ASN.1 syntax, the
-   comparison proceeds as normal so long as the corresponding characters
-   are in both character sets.  Otherwise matching fails.
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 19]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
- 6.2 Signing time match
-
-   The signingTimeMatch rule compares for equality a presented value
-   with an attribute value of type SigningTime.
-
-   signingTimeMatch MATCHING-RULE ::= {
-           SYNTAX SigningTime
-           ID pkcs-9-mr-signingTimeMatch
-   }
-
-   The rule returns TRUE if the attribute value represents the same time
-   as the presented value.  If a time is specified with seconds (or
-   fractional seconds) absent, the number of seconds (fractional
-   seconds) is assumed to be zero.
-
-   Where the strings being matched are of different ASN.1 syntax, the
-   comparison proceeds as follows:
-
-   a) Convert both values to DER-encoded values of type GeneralizedTime,
-     coordinated universal time.  If this is not possible the matching
-     fails.
-
-   b) Compare the strings for equality.  The rule returns TRUE if and
-     only if the strings are of the same length and corresponding octets
-     are identical.
-
-7. Security Considerations
-
-   Attributes of directory entries are used to provide descriptive
-   information about the real-world objects they represent, which can be
-   people, organizations or devices.  Most countries have privacy laws
-   regarding the publication of information about people.
-
-   The challengePassword attribute should not be stored un-encrypted in
-   a directory.
-
-   Users of directory-aware applications making use of attributes
-   defined for use with the pkcsEntity object class should make sure
-   that the class's attributes are adequately protected, since they may
-   potentially be read by third parties.  If a password-protected value
-   is stored (PKCS #8, #12 or #15), the directory should authenticate
-   the requester before delivering the value to prevent an off-line
-   password-search attack.  Note that this potentially raises non-
-   repudiation issues since the directory itself can try a password
-   search to recover a private value, if stored this way.
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 20]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-8. Authors' Addresses
-
-   Magnus Nystrom
-   RSA Security
-   Box 10704
-   S-121 29 Stockholm
-   Sweden
-
-   EMail: magnus@rsasecurity.com
-
-
-   Burt Kaliski
-   RSA Security
-   20 Crosby Drive
-   Bedford, MA 01730 USA
-
-   EMail: bkaliski@rsasecurity.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 21]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-APPENDICES
-
-A. ASN.1 module
-
-   This appendix includes all of the ASN.1 type and value definitions
-   contained in this document in the form of the ASN.1 module PKCS-9.
-
-   PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-   pkcs-9(9) modules(0) pkcs-9(1)}
-
-   DEFINITIONS IMPLICIT TAGS ::=
-
-   BEGIN
-
-   -- EXPORTS All --
-   -- All types and values defined in this module is exported for use
-   -- in other ASN.1 modules.
-
-   IMPORTS
-
-   informationFramework, authenticationFramework,
-   selectedAttributeTypes, upperBounds , id-at
-           FROM UsefulDefinitions {joint-iso-itu-t ds(5) module(1)
-           usefulDefinitions(0) 3}
-
-   ub-name
-           FROM UpperBounds upperBounds
-
-   OBJECT-CLASS, ATTRIBUTE, MATCHING-RULE, Attribute, top,
-   objectIdentifierMatch
-           FROM InformationFramework informationFramework
-
-   ALGORITHM, Extensions, Time
-           FROM AuthenticationFramework authenticationFramework
-
-   DirectoryString, octetStringMatch, caseIgnoreMatch, caseExactMatch,
-   generalizedTimeMatch, integerMatch, serialNumber
-           FROM SelectedAttributeTypes selectedAttributeTypes
-
-   ContentInfo, SignerInfo
-           FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840)
-           rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
-
-   EncryptedPrivateKeyInfo
-           FROM PKCS-8 {iso(1) member-body(2) us(840) rsadsi(113549)
-           pkcs(1) pkcs-8(8) modules(1) pkcs-8(1)}
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 22]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   PFX
-           FROM PKCS-12 {iso(1) member-body(2) us(840) rsadsi(113549)
-           pkcs(1) pkcs-12(12) modules(0) pkcs-12(1)}
-
-   PKCS15Token
-           FROM PKCS-15 {iso(1) member-body(2) us(840) rsadsi(113549)
-           pkcs(1) pkcs-15(15) modules(1) pkcs-15(1)};
-
-   -- Upper bounds
-
-   pkcs-9-ub-pkcs9String         INTEGER ::= 255
-   pkcs-9-ub-emailAddress        INTEGER ::= pkcs-9-ub-pkcs9String
-   pkcs-9-ub-unstructuredName    INTEGER ::= pkcs-9-ub-pkcs9String
-   pkcs-9-ub-unstructuredAddress INTEGER ::= pkcs-9-ub-pkcs9String
-   pkcs-9-ub-challengePassword   INTEGER ::= pkcs-9-ub-pkcs9String
-   pkcs-9-ub-friendlyName        INTEGER ::= pkcs-9-ub-pkcs9String
-   pkcs-9-ub-signingDescription  INTEGER ::= pkcs-9-ub-pkcs9String
-   pkcs-9-ub-match               INTEGER ::= pkcs-9-ub-pkcs9String
-   pkcs-9-ub-pseudonym           INTEGER ::= ub-name
-   pkcs-9-ub-placeOfBirth        INTEGER ::= ub-name
-
-   -- Object Identifiers
-
-   pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
-                                 rsadsi(113549) pkcs(1) 9}
-
-     -- Main arcs
-   pkcs-9-mo OBJECT IDENTIFIER ::= {pkcs-9 0}  -- Modules branch
-   pkcs-9-oc OBJECT IDENTIFIER ::= {pkcs-9 24} -- Object class branch
-   pkcs-9-at OBJECT IDENTIFIER ::= {pkcs-9 25} -- Attribute branch, for
-                                               -- new  attributes
-   pkcs-9-sx OBJECT IDENTIFIER ::= {pkcs-9 26} -- For syntaxes (RFC 2252)
-   pkcs-9-mr OBJECT IDENTIFIER ::= {pkcs-9 27} -- Matching rules
-
-     -- Object classes
-   pkcs-9-oc-pkcsEntity    OBJECT IDENTIFIER ::= {pkcs-9-oc 1}
-   pkcs-9-oc-naturalPerson OBJECT IDENTIFIER ::= {pkcs-9-oc 2}
-
-     -- Attributes
-   pkcs-9-at-emailAddress        OBJECT IDENTIFIER ::= {pkcs-9 1}
-   pkcs-9-at-unstructuredName    OBJECT IDENTIFIER ::= {pkcs-9 2}
-   pkcs-9-at-contentType         OBJECT IDENTIFIER ::= {pkcs-9 3}
-   pkcs-9-at-messageDigest       OBJECT IDENTIFIER ::= {pkcs-9 4}
-   pkcs-9-at-signingTime         OBJECT IDENTIFIER ::= {pkcs-9 5}
-   pkcs-9-at-counterSignature    OBJECT IDENTIFIER ::= {pkcs-9 6}
-   pkcs-9-at-challengePassword   OBJECT IDENTIFIER ::= {pkcs-9 7}
-   pkcs-9-at-unstructuredAddress OBJECT IDENTIFIER ::= {pkcs-9 8}
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 23]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   pkcs-9-at-extendedCertificateAttributes
-                                 OBJECT IDENTIFIER ::= {pkcs-9 9}
-
-   -- Obsolete (?) attribute identifiers, purportedly from "tentative
-   -- PKCS #9 draft"
-   -- pkcs-9-at-issuerAndSerialNumber OBJECT IDENTIFIER ::= {pkcs-9 10}
-   -- pkcs-9-at-passwordCheck         OBJECT IDENTIFIER ::= {pkcs-9 11}
-   -- pkcs-9-at-publicKey             OBJECT IDENTIFIER ::= {pkcs-9 12}
-
-   pkcs-9-at-signingDescription       OBJECT IDENTIFIER ::= {pkcs-9 13}
-   pkcs-9-at-extensionRequest         OBJECT IDENTIFIER ::= {pkcs-9 14}
-   pkcs-9-at-smimeCapabilities        OBJECT IDENTIFIER ::= {pkcs-9 15}
-
-   -- Unused (?)
-   -- pkcs-9-at-?                     OBJECT IDENTIFIER ::= {pkcs-9 17}
-   -- pkcs-9-at-?                     OBJECT IDENTIFIER ::= {pkcs-9 18}
-   -- pkcs-9-at-?                     OBJECT IDENTIFIER ::= {pkcs-9 19}
-
-   pkcs-9-at-friendlyName             OBJECT IDENTIFIER ::= {pkcs-9 20}
-   pkcs-9-at-localKeyId               OBJECT IDENTIFIER ::= {pkcs-9 21}
-   pkcs-9-at-userPKCS12               OBJECT IDENTIFIER ::=
-                                         {2 16 840 1 113730 3 1 216}
-   pkcs-9-at-pkcs15Token              OBJECT IDENTIFIER ::= {pkcs-9-at 1}
-   pkcs-9-at-encryptedPrivateKeyInfo  OBJECT IDENTIFIER ::= {pkcs-9-at 2}
-   pkcs-9-at-randomNonce              OBJECT IDENTIFIER ::= {pkcs-9-at 3}
-   pkcs-9-at-sequenceNumber           OBJECT IDENTIFIER ::= {pkcs-9-at 4}
-   pkcs-9-at-pkcs7PDU                 OBJECT IDENTIFIER ::= {pkcs-9-at 5}
-
-     -- IETF PKIX Attribute branch
-   ietf-at                            OBJECT IDENTIFIER ::=
-                                         {1 3 6 1 5 5 7 9}
-
-   pkcs-9-at-dateOfBirth              OBJECT IDENTIFIER ::= {ietf-at 1}
-   pkcs-9-at-placeOfBirth             OBJECT IDENTIFIER ::= {ietf-at 2}
-   pkcs-9-at-gender                   OBJECT IDENTIFIER ::= {ietf-at 3}
-   pkcs-9-at-countryOfCitizenship     OBJECT IDENTIFIER ::= {ietf-at 4}
-   pkcs-9-at-countryOfResidence       OBJECT IDENTIFIER ::= {ietf-at 5}
-
-     -- Syntaxes (for use with LDAP accessible directories)
-   pkcs-9-sx-pkcs9String              OBJECT IDENTIFIER ::= {pkcs-9-sx 1}
-   pkcs-9-sx-signingTime              OBJECT IDENTIFIER ::= {pkcs-9-sx 2}
-
-     -- Matching rules
-   pkcs-9-mr-caseIgnoreMatch          OBJECT IDENTIFIER ::= {pkcs-9-mr 1}
-   pkcs-9-mr-signingTimeMatch         OBJECT IDENTIFIER ::= {pkcs-9-mr 2}
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 24]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-     -- Arcs with attributes defined elsewhere
-   smime                              OBJECT IDENTIFIER ::= {pkcs-9 16}
-
-     -- Main arc for S/MIME (RFC 2633)
-   certTypes                          OBJECT IDENTIFIER ::= {pkcs-9 22}
-
-     -- Main arc for certificate types defined in PKCS #12
-   crlTypes                           OBJECT IDENTIFIER ::= {pkcs-9 23}
-
-     -- Main arc for crl types defined in PKCS #12
-
-     -- Other object identifiers
-   id-at-pseudonym                    OBJECT IDENTIFIER ::= {id-at 65}
-
-   -- Useful types
-
-   PKCS9String {INTEGER : maxSize} ::= CHOICE {
-           ia5String IA5String (SIZE(1..maxSize)),
-           directoryString DirectoryString {maxSize}
-   }
-
-   -- Object classes
-
-   pkcsEntity OBJECT-CLASS ::= {
-           SUBCLASS OF     { top }
-           KIND            auxiliary
-           MAY CONTAIN     { PKCSEntityAttributeSet }
-           ID              pkcs-9-oc-pkcsEntity
-   }
-
-   naturalPerson OBJECT-CLASS ::= {
-           SUBCLASS OF     { top }
-           KIND            auxiliary
-           MAY CONTAIN     { NaturalPersonAttributeSet }
-           ID              pkcs-9-oc-naturalPerson
-   }
-
-   -- Attribute sets
-
-   PKCSEntityAttributeSet ATTRIBUTE ::= {
-           pKCS7PDU |
-           userPKCS12 |
-           pKCS15Token |
-           encryptedPrivateKeyInfo,
-           ... -- For future extensions
-   }
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 25]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   NaturalPersonAttributeSet ATTRIBUTE ::= {
-           emailAddress |
-           unstructuredName |
-           unstructuredAddress |
-           dateOfBirth |
-           placeOfBirth |
-           gender |
-           countryOfCitizenship |
-           countryOfResidence |
-           pseudonym |
-           serialNumber,
-           ... -- For future extensions
-   }
-
-   -- Attributes
-
-   pKCS7PDU ATTRIBUTE ::= {
-           WITH SYNTAX ContentInfo
-           ID pkcs-9-at-pkcs7PDU
-   }
-
-   userPKCS12 ATTRIBUTE ::= {
-           WITH SYNTAX PFX
-           ID pkcs-9-at-userPKCS12
-   }
-
-   pKCS15Token ATTRIBUTE ::= {
-           WITH SYNTAX PKCS15Token
-           ID pkcs-9-at-pkcs15Token
-   }
-
-   encryptedPrivateKeyInfo ATTRIBUTE ::= {
-           WITH SYNTAX EncryptedPrivateKeyInfo
-           ID pkcs-9-at-encryptedPrivateKeyInfo
-   }
-
-   emailAddress ATTRIBUTE ::= {
-           WITH SYNTAX IA5String (SIZE(1..pkcs-9-ub-emailAddress))
-           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
-           ID pkcs-9-at-emailAddress
-   }
-
-   unstructuredName ATTRIBUTE ::= {
-           WITH SYNTAX PKCS9String {pkcs-9-ub-unstructuredName}
-           EQUALITY MATCHING RULE pkcs9CaseIgnoreMatch
-           ID pkcs-9-at-unstructuredName
-   }
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 26]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   unstructuredAddress ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-unstructuredAddress}
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           ID pkcs-9-at-unstructuredAddress
-   }
-
-   dateOfBirth ATTRIBUTE ::= {
-           WITH SYNTAX GeneralizedTime
-           EQUALITY MATCHING RULE generalizedTimeMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-dateOfBirth
-   }
-
-   placeOfBirth ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-placeOfBirth}
-           EQUALITY MATCHING RULE caseExactMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-placeOfBirth
-   }
-
-   gender ATTRIBUTE ::= {
-           WITH SYNTAX PrintableString (SIZE(1) ^
-                       FROM ("M" | "F" | "m" | "f"))
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-gender
-   }
-
-   countryOfCitizenship ATTRIBUTE ::= {
-           WITH SYNTAX PrintableString (SIZE(2))(CONSTRAINED BY {
-           -- Must be a two-letter country acronym in accordance with
-           -- ISO/IEC 3166 --})
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           ID pkcs-9-at-countryOfCitizenship
-   }
-
-   countryOfResidence ATTRIBUTE ::= {
-           WITH SYNTAX PrintableString (SIZE(2))(CONSTRAINED BY {
-           -- Must be a two-letter country acronym in accordance with
-           -- ISO/IEC 3166 --})
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           ID pkcs-9-at-countryOfResidence
-   }
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 27]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   pseudonym ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-pseudonym}
-           EQUALITY MATCHING RULE caseExactMatch
-           ID id-at-pseudonym
-   }
-
-   contentType ATTRIBUTE ::= {
-           WITH SYNTAX ContentType
-           EQUALITY MATCHING RULE objectIdentifierMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-contentType
-   }
-
-   ContentType ::= OBJECT IDENTIFIER
-
-   messageDigest ATTRIBUTE ::= {
-           WITH SYNTAX MessageDigest
-           EQUALITY MATCHING RULE octetStringMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-messageDigest
-   }
-
-   MessageDigest ::= OCTET STRING
-
-   signingTime ATTRIBUTE ::= {
-           WITH SYNTAX SigningTime
-           EQUALITY MATCHING RULE signingTimeMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-signingTime
-   }
-
-   SigningTime ::= Time -- imported from ISO/IEC 9594-8
-
-   randomNonce ATTRIBUTE ::= {
-           WITH SYNTAX RandomNonce
-           EQUALITY MATCHING RULE octetStringMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-randomNonce
-   }
-
-   RandomNonce ::= OCTET STRING (SIZE(4..MAX))
-           -- At least four bytes long
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 28]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   sequenceNumber ATTRIBUTE ::= {
-           WITH SYNTAX SequenceNumber
-           EQUALITY MATCHING RULE integerMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-sequenceNumber
-   }
-
-   SequenceNumber ::= INTEGER (1..MAX)
-
-   counterSignature ATTRIBUTE ::= {
-           WITH SYNTAX SignerInfo
-           ID pkcs-9-at-counterSignature
-   }
-
-   challengePassword ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-challengePassword}
-           EQUALITY MATCHING RULE caseExactMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-challengePassword
-   }
-
-   extensionRequest ATTRIBUTE ::= {
-           WITH SYNTAX ExtensionRequest
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-extensionRequest
-   }
-
-   ExtensionRequest ::= Extensions
-
-   extendedCertificateAttributes ATTRIBUTE ::= {
-           WITH SYNTAX SET OF Attribute
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-extendedCertificateAttributes
-   }
-
-   friendlyName ATTRIBUTE ::= {
-           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-friendlyName
-   }
-
-   localKeyId ATTRIBUTE ::= {
-           WITH SYNTAX OCTET STRING
-           EQUALITY MATCHING RULE octetStringMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-localKeyId
-   }
-
-
-
-Nystrom & Kaliski            Informational                     [Page 29]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   signingDescription ATTRIBUTE ::= {
-           WITH SYNTAX DirectoryString {pkcs-9-ub-signingDescription}
-           EQUALITY MATCHING RULE caseIgnoreMatch
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-signingDescription
-   }
-
-   smimeCapabilities ATTRIBUTE ::= {
-           WITH SYNTAX SMIMECapabilities
-           SINGLE VALUE TRUE
-           ID pkcs-9-at-smimeCapabilities
-   }
-
-   SMIMECapabilities ::= SEQUENCE OF SMIMECapability
-
-   SMIMECapability ::= SEQUENCE {
-           algorithm  ALGORITHM.&id ({SMIMEv3Algorithms}),
-           parameters ALGORITHM.&Type ({SMIMEv3Algorithms}{@algorithm})
-   }
-
-   SMIMEv3Algorithms ALGORITHM ::= {...-- See RFC 2633 --}
-
-    -- Matching rules
-
-   pkcs9CaseIgnoreMatch MATCHING-RULE ::= {
-           SYNTAX PKCS9String {pkcs-9-ub-match}
-           ID pkcs-9-mr-caseIgnoreMatch
-   }
-
-   signingTimeMatch MATCHING-RULE ::= {
-           SYNTAX SigningTime
-           ID pkcs-9-mr-signingTimeMatch
-   }
-
-   END
-
-B. BNF schema summary This appendix provides augmented BNF [2]
-   definitions of the object class and most attribute types specified in
-   this document along with their associated syntaxes and matching
-   rules.  The ABNF definitions have been done in accordance with [21],
-   in an attempt to ease integration with LDAP-accessible Directory
-   systems.  Lines have been folded in some cases to improve
-   readability.
-
- B.1 Syntaxes
-
-   This section defines all syntaxes that are used in this document.
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 30]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  B.1.1 PKCS9String
-
-   (
-           1.2.840.113549.1.9.26.1
-           DESC 'PKCS9String'
-   )
-
-   The encoding of a value in this syntax is the string value itself.
-
-  B.1.2 SigningTime
-
-   (
-           1.2.840.113549.1.9.26.2
-           DESC 'SigningTime'
-   )
-
-   Values in this syntax are encoded as printable strings, represented
-   as specified in [5].  Note that the time zone must be specified.  For
-   example, "199412161032Z".
-
- B.2 Object classes
-
-  B.2.1 pkcsEntity
-
-   (
-           1.2.840.113549.1.9.24.1
-           NAME 'pkcsEntity'
-           SUP top
-           AUXILIARY
-           MAY (
-           pKCS7PDU $ userPKCS12 $ pKCS15Token $ encryptedPrivateKeyInfo
-           )
-   )
-
-  B.2.2 naturalPerson
-
-   (
-           1.2.840.113549.1.9.24.2
-           NAME 'naturalPerson'
-           SUP top
-           AUXILIARY
-           MAY (
-           emailAddress $ unstructuredName $ unstructuredAddress $
-           dateOfBirth & placeOfBirth & gender & countryOfCitizenship &
-           countryOfResidence & pseudonym & serialNumber
-           )
-   )
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 31]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
- B.3 Attribute types
-
-  B.3.1 pKCS7PDU
-
-   This attribute is to be stored and requested in binary form, as
-   pKCS7PDU;binary.  The attribute values are BER- or DER-encoded
-   ContentInfo values.
-
-   (
-           1.2.840.113549.1.9.25.5
-           NAME 'pKCS7PDU'
-           DESC 'PKCS #7 ContentInfo PDU'
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
-   )
-
-  B.3.2 userPKCS12
-
-   This attribute is to be stored and requested in binary form, as
-   userPKCS12;binary.  The attribute values are PFX PDUs stored as
-   binary (BER- or DER-encoded) data.
-
-   (
-           2.16.840.1.113730.3.1.216
-           NAME 'userPKCS12'
-           DESC 'PKCS #12 PFX PDU for exchange of personal information'
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
-   )
-
-  B.3.3 pKCS15Token
-
-   This attribute is to be stored and requested in binary form, as
-   pKCS15Token;binary.  The attribute values are PKCS15Token PDUs stored
-   as binary (BER- or DER-encoded) data.
-
-   (
-           1.2.840.113549.1.9.25.1
-           NAME 'pKCS15Token'
-           DESC 'PKCS #15 token PDU'
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
-   )
-
-  B.3.4 encryptedPrivateKeyInfo
-
-   This attribute is to be stored and requested in binary form, as
-   encryptedPrivateKeyInfo;binary.  The attribute values are
-   EncryptedPrivateKeyInfo PDUs stored as binary (BER- or DER-encoded)
-   data.
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 32]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   (
-           1.2.840.113549.1.9.25.2
-           NAME 'encryptedPrivateKeyInfo'
-           DESC 'PKCS #8 encrypted private key info'
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
-   )
-
-  B.3.5 emailAddress
-
-   (
-           1.2.840.113549.1.9.1
-           NAME 'emailAddress'
-           DESC 'Email address'
-           EQUALITY pkcs9CaseIgnoreMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
-   )
-
-  B.3.6 unstructuredName
-
-   (
-           1.2.840.113549.1.9.2
-           NAME 'unstructuredName'
-           DESC 'PKCS #9 unstructured name'
-           EQUALITY pkcs9CaseIgnoreMatch
-           SYNTAX 1.2.840.113549.1.9.26.1
-   )
-
-  B.3.7 unstructuredAddress
-
-   (
-           1.2.840.113549.1.9.8
-           NAME 'unstructuredAddress'
-           DESC 'PKCS #9 unstructured address'
-           EQUALITY caseIgnoreMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
-   )
-
-  B.3.8 dateOfBirth
-
-   (
-           1.3.6.1.5.5.7.9.1
-           NAME 'dateOfBirth'
-           DESC 'Date of birth'
-           EQUALITY generalizedTimeMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
-           SINGLE-VALUE
-   )
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 33]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  B.3.9 placeOfBirth
-
-   (
-           1.3.6.1.5.5.7.9.2
-           NAME 'placeOfBirth'
-           DESC 'Place of birth'
-           EQUALITY caseExactMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
-           SINGLE-VALUE
-   )
-
-  B.3.10 gender
-
-   (
-           1.3.6.1.5.5.7.9.3
-           NAME 'gender'
-           DESC 'Gender'
-           EQUALITY caseIgnoreMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
-           SINGLE-VALUE
-   )
-
-  B.3.11 countryOfCitizenship
-
-   (
-           1.3.6.1.5.5.7.9.4
-           NAME 'countryOfCitizenship'
-           DESC 'Country of citizenship'
-           EQUALITY caseIgnoreMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
-   )
-
-  B.3.12 countryOfResidence
-
-   (
-           1.3.6.1.5.5.7.9.5
-           NAME 'countryOfResidence'
-           DESC 'Country of residence'
-           EQUALITY caseIgnoreMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
-   )
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 34]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  B.3.13 pseudonym
-
-   (
-           2.5.4.65
-           NAME 'pseudonym'
-           DESC 'Pseudonym'
-           EQUALITY caseExactMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
-   )
-
-  B.3.14 contentType
-
-   In the (highly unlikely) event of this attribute being stored in a
-   Directory it is to be stored and requested in binary form, as
-   contentType;binary.  Attribute values shall be OCTET STRINGs stored
-   as binary (BER- or DER-encoded) data.
-
-   (
-           1.2.840.113549.1.9.3
-           NAME 'contentType'
-           DESC 'PKCS #7 content type attribute'
-           EQUALITY objectIdentifierMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
-           SINGLE-VALUE
-   )
-
-  B.3.15 messageDigest
-
-   In the (highly unlikely) event of this attribute being stored in a
-   Directory it is to be stored and requested in binary form, as
-   messageDigest;binary.  Attribute values shall be OCTET STRINGs stored
-   as binary (BER- or DER-encoded) data.
-
-   (
-           1.2.840.113549.1.9.4
-           NAME 'messageDigest'
-           DESC 'PKCS #7 mesage digest attribute'
-           EQUALITY octetStringMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
-           SINGLE-VALUE
-   )
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 35]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  B.3.16 signingTime
-
-   (
-           1.2.840.113549.1.9.5
-           NAME 'signingTime'
-           DESC 'PKCS #7 signing time'
-           EQUALITY signingTimeMatch
-           SYNTAX 1.2.840.113549.1.9.26.2
-           SINGLE-VALUE
-   )
-
-  B.3.17 counterSignature
-
-   In the (highly unlikely) event that this attribute is to be stored in
-   a directory, it is to be stored and requested in binary form, as
-   counterSignature;binary.  Attribute values shall be stored as binary
-   (BER- or DER-encoded) data.
-
-   (
-           1.2.840.113549.1.9.6
-           NAME 'counterSignature'
-           DESC 'PKCS #7 countersignature'
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.5
-   )
-
-  B.3.18 challengePassword
-
-   (
-           1.2.840.113549.1.9.7
-           NAME 'challengePassword'
-           DESC 'Challenge password for certificate revocations'
-           EQUALITY caseExactMatch
-           SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
-           SINGLE-VALUE
-   )
-
-   Note - It is not recommended to store unprotected values of this
-   attribute in a directory.
-
- B.4 Matching rules
-
-  B.4.1 pkcs9CaseIgnoreMatch
-
-   (
-           1.2.840.113549.1.9.27.1
-           NAME 'pkcs9CaseIgnoreMatch'
-           SYNTAX 1.2.840.113549.1.9.26.1
-   )
-
-
-
-Nystrom & Kaliski            Informational                     [Page 36]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-  B.4.2 signingTimeMatch
-
-   (
-           1.2.840.113549.1.9.27.3
-           NAME 'signingTimeMatch'
-           SYNTAX 1.2.840.113549.1.9.26.2
-   )
-
-C. Intellectual property considerations
-
-   RSA Security makes no patent claims on the general constructions
-   described in this document, although specific underlying techniques
-   may be covered.
-
-   License to copy this document is granted provided that it is
-   identified as "RSA Security Inc.  Public-Key Cryptography Standards
-   (PKCS)" in all material mentioning or referencing this document.
-
-   RSA Security makes no representations regarding intellectual property
-   claims by other parties.  Such determination is the responsibility of
-   the user.
-
-D. Revision history
-
-   Version 1.0
-
-      Version 1.0 was part of the June 3, 1991 initial public release of
-      PKCS.  Version 1.0 was also published as NIST/OSI Implementors'
-      Workshop document SEC-SIG-91-24.
-
-      Version 1.1
-
-      Version 1.1 incorporated several editorial changes, including
-      updates to the references and the addition of a revision history.
-      The following substantive changes were made:
-
-      - Section 6: challengePassword, unstructuredAddress, and
-        extendedCertificateAttributes attribute types were added
-      - Section 7: challengePassword, unstructuredAddress, and
-        extendedCertificateAttributes object identifiers were added
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 37]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   Version 2.0
-
-   Version 2.0 incorporates several editorial changes as well.  In
-   addition, the following substantive changes have been made:
-
-      - Addition of a Section defining two new auxiliary object classes,
-        pkcsEntity and naturalPerson
-      - Addition of several new attribute types and matching rules for
-        use in conjunction with these object classes and elsewhere
-      - Update of all ASN.1 to be in line with the 1997 version of this
-        syntax
-      - Addition a "compilable" ASN.1 module
-      - Addition, in accordance with [21], an ABNF description of all
-        attributes and object classes
-      - Addition of an intellectual property considerations section
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 38]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-E. References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-        Specifications: ABNF", RFC 2234, November 1997.
-
-   [3]  Housley, R., "Cryptographic Message Syntax CMS", RFC 2630, June
-        1999.
-
-   [4]  ISO/IEC 3166-1:Codes for the representation of names of
-        countries and their subdivisions - Part 1: Country codes. 1997.
-
-   [5]  ISO/IEC 8824-1:1999: Information technology - Abstract Syntax
-        Notation One (ASN.1) - Specification of basic notation.1999.
-
-   [6]  ISO/IEC 8825-1:1999: Information technology - ASN.1 Encoding
-        Rules: Specification of Basic Encoding Rules (BER), Canonical
-        Encoding Rules (CER) and Distinguished Encoding Rules (DER).
-        1999.
-
-   [7]  ISO/IEC 9594-2:1997: Information technology - Open Systems
-        Interconnection - The Directory: Models. 1997.
-
-   [8]  ISO/IEC 9594-6:1997: Information technology - Open Systems
-        Interconnection - The Directory: Selected attribute types. 1997.
-
-   [9]  ISO/IEC 9594-7:1997: Information technology - Open Systems
-        Interconnection - The Directory: Selected object classes. 1997.
-
-   [10] ISO/IEC 9594-8:1997: Information technology - Open Systems
-        Interconnection - The Directory: Authentication framework. 1997.
-
-   [11] ISO/IEC 10646-1: Information Technology - Universal Multiple-
-        Octet Coded Character Set (UCS) - Part 1: Architecture and Basic
-        Multilingual Plane. 1993.
-
-   [12] Ramsdell, R., "S/MIME Version 3 Message Specification", RFC
-        2633, June 1999.
-
-   [13] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard.
-        Version 1.5, November 1993.
-
-   [14] RSA Laboratories. PKCS #7: Cryptographic Message Syntax
-        Standard. Version 1.5, November 1993.
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 39]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-   [15] RSA Laboratories. PKCS #8: Private-Key Information Syntax
-        Standard. Version 1.2, November 1993.
-
-   [16] RSA Laboratories. PKCS #10: Certification Request Syntax
-        Standard. Version 1.0, November 1993.
-
-   [17] RSA Laboratories. PKCS #12: Personal Information Exchange Syntax
-        Standard. Version 1.0, June 1999.
-
-   [18] RSA Laboratories. PKCS #15: Cryptographic Token Information
-        Format Standard. Version 1.1, June 2000.
-
-   [19] Santesson, S., Polk, W., Barzin, P. and M. Nystrom, "Internet
-        X.509 Public Key Infrastructure - Qualified Certificates
-        Profile", Work in Progress.
-
-   [20] Smith, M. "Definition of the inetOrgPerson LDAP Object Class",
-        RFC 2798, April 2000.
-
-   [21] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
-        Directory Access Protocol (v3): Attribute Syntax Definitions",
-        RFC 2252, December 1997.
-
-   [22] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
-        Protocol (v3)", RFC 2251, December 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 40]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-F. Contact information & About PKCS
-
-   The Public-Key Cryptography Standards are specifications produced by
-   RSA Laboratories in cooperation with secure systems developers
-   worldwide for the purpose of accelerating the deployment of public-
-   key cryptography.  First published in 1991 as a result of meetings
-   with a small group of early adopters of public-key technology, the
-   PKCS documents have become widely referenced and implemented.
-   Contributions from the PKCS series have become part of many formal
-   and de facto standards, including ANSI X9 documents, PKIX, SET,
-   S/MIME, and SSL.
-
-   Further development of PKCS occurs through mailing list discussions
-   and occasional workshops, and suggestions for improvement are
-   welcome.  For more information, contact:
-
-   PKCS Editor
-   RSA Laboratories
-   20 Crosby Drive
-   Bedford, MA  01730 USA
-   pkcs-editor@rsasecurity.com
-   http://www.rsasecurity.com/rsalabs/PKCS
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 41]
-
-RFC 2985      Selected Object Classes and Attribute Types  November 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others provided that the above copyright notice and this paragraph
-   are included on all such copies.  However, this document itself may
-   not be modified in any way, such as by removing the copyright notice
-   or references to the Internet Society or other Internet
-   organizations, except as required to translate it into languages
-   other than English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  IMPLIED, INCLUDING
-   BUT NOT  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 42]
-
diff --git a/doc/protocol/rfc2986.txt b/doc/protocol/rfc2986.txt
deleted file mode 100644
index ec8f1e3318..0000000000
--- a/doc/protocol/rfc2986.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Nystrom
-Request for Comments: 2986                                    B. Kaliski
-Obsoletes: 2314                                             RSA Security
-Category: Informational                                    November 2000
-
-
-          PKCS #10: Certification Request Syntax Specification
-                              Version 1.7
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This memo represents a republication of PKCS #10 v1.7 from RSA
-   Laboratories' Public-Key Cryptography Standards (PKCS) series, and
-   change control is retained within the PKCS process.  The body of this
-   document, except for the security considerations section, is taken
-   directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.
-
-   This memo describes a syntax for certification requests.
-
-Table of Contents
-
-   1.  Introduction ................................................. 2
-   2.  Definitions and notation ..................................... 2
-   2.1  Definitions ................................................. 2
-   2.2  Notation .................................................... 4
-   3.  Overview ..................................................... 4
-   4.  Certification request syntax ................................. 5
-   4.1  CertificationRequestInfo .................................... 5
-   4.2  CertificationRequest ........................................ 7
-   5.  Security Considerations ...................................... 8
-   6.  Authors' Addresses ........................................... 8
-   A.  ASN.1 module ................................................. 9
-   B.  Intellectual property considerations ........................ 10
-   C.  Revision history ............................................ 10
-   D.  References .................................................. 11
-   E.  Contact information & About PKCS ............................ 12
-   Full Copyright Statement ........................................ 14
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 1]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-1. Introduction
-
-   This document describes syntax for certification requests.  A
-   certification request consists of a distinguished name, a public key,
-   and optionally a set of attributes, collectively signed by the entity
-   requesting certification.  Certification requests are sent to a
-   certification authority, which transforms the request into an X.509
-   [9] public-key certificate.  (In what form the certification
-   authority returns the newly signed certificate is outside the scope
-   of this document.  A PKCS #7 [2] message is one possibility.)
-
-   The intention of including a set of attributes is twofold: to provide
-   other information about a given entity , or a "challenge password" by
-   which the entity may later request certificate revocation; and to
-   provide attributes for inclusion in X.509 certificates.  A non-
-   exhaustive list of attributes is given in PKCS #9 [3].
-
-   Certification authorities may also require non-electronic forms of
-   request and may return non-electronic replies.  It is expected that
-   descriptions of such forms, which are outside the scope of this
-   document, will be available from certification authorities.
-
-   The preliminary intended application of this document is to support
-   PKCS #7 cryptographic messages, but it is expected that other
-   applications will be developed (see e.g. [4]).
-
-2. Definitions and notation
-
- 2.1 Definitions
-
-   For the purposes of this document, the following definitions apply.
-
-   ALGORITHM       An information object class defined in X.509 to
-                   describe objects composed of an algorithm (a unique
-                   object identifier) and its parameters (any ASN.1
-                   type).  The values of objects in this class can be
-                   represented by the ASN.1 type AlgorithmIdentifier{}.
-                   ALGORITHM is defined as the "useful" information
-                   object class TYPE-IDENTIFIER, specified in [11],
-                   Annex A.
-
-   AlgorithmIdentifier{}
-                   A useful parameterized version of X.509 type
-                   AlgorithmIdentifier is defined in this document.
-                   This type tightly binds pairs of algorithm object
-                   identifiers to their associated parameter types.
-                   When referenced, the single parameter of
-                   AlgorithmIdentifier{} specifies a constraint on the
-
-
-
-Nystrom & Kaliski            Informational                      [Page 2]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-                   pairs of values that may appear in that instance of
-                   the type.  The encoded values of
-                   AlgorithmIdentifier{} are equivalent to those of type
-                   AlgorithmIdentifier.
-
-   ASN.1           Abstract Syntax Notation One, as defined in the ASN.1
-                   standards ([10], [11], [12], and [13]).
-
-   ATTRIBUTE       This class describes objects composed of an attribute
-                   (a unique object identifier) and an associated set of
-                   attribute values (any ASN.1 type).  The values of
-                   objects in this class can be represented by type
-                   Attribute{}.
-
-   Attribute{}     A useful parameterized version of X.501 [8] type
-                   Attribute is defined in this document.  This type
-                   tightly binds pairs of attribute type object
-                   identifiers to one or more attribute values types.
-                   In the ASN.1 open type notation, an attribute type is
-                   defined as ATTRIBUTE.&id and an attribute value as
-                   ATTRIBUTE.&Type.  When referenced, the single
-                   parameter of Attribute{} specifies a constraint on
-                   the pairs of values that may appear in an instance of
-                   the type.  The encoded values of Attribute{} are
-                   equivalent to those of type Attribute.
-
-   BER             Basic Encoding Rules for ASN.1, as defined in X.690
-                   ([14]).
-
-   Certificate     A type that binds a subject entity's distinguished
-                   name to a public key with a digital signature.  This
-                   type is defined in X.509.  This type also contains
-                   the distinguished name of the certificate issuer (the
-                   signer), an issuer-specific serial number, the
-                   issuer's signature algorithm identifier, a validity
-                   period, and an optional set of certificate
-                   extensions.
-
-   DER             Distinguished Encoding Rules for ASN.1, as defined in
-                   X.690.  DER is a subset of BER.
-
-   Name            A type that uniquely identifies or "distinguishes"
-                   objects in an X.500 [7] directory.  This type is
-                   defined in X.501.  In an X.509 certificate, the type
-                   identifies the certificate issuer and the certificate
-                   subject, the entity whose public key is certified.
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 3]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-  2.2 Notation
-
-   No special notation is used in this document.
-
-3. Overview
-
-   A certification request consists of three parts: "certification
-   request information," a signature algorithm identifier, and a digital
-   signature on the certification request information.  The
-   certification request information consists of the entity's
-   distinguished name, the entity's public key, and a set of attributes
-   providing other information about the entity.
-
-   The process by which a certification request is constructed involves
-   the following steps:
-
-        1. A CertificationRequestInfo value containing a subject
-           distinguished name, a subject public key, and optionally a
-           set of attributes is constructed by an entity requesting
-           certification.
-
-        2. The CertificationRequestInfo value is signed with the subject
-           entity's private key.  (See Section 4.2.)
-
-        3. The CertificationRequestInfo value, a signature algorithm
-           identifier, and the entity's signature are collected together
-           into a CertificationRequest value, defined below.
-
-   A certification authority fulfills the request by authenticating the
-   requesting entity and verifying the entity's signature, and, if the
-   request is valid, constructing an X.509 certificate from the
-   distinguished name and public key, the issuer name, and the
-   certification authority's choice of serial number, validity period,
-   and signature algorithm.  If the certification request contains any
-   PKCS #9 attributes, the certification authority may also use the
-   values in these attributes as well as other information known to the
-   certification authority to construct X.509 certificate extensions.
-
-   In what form the certification authority returns the new certificate
-   is outside the scope of this document.  One possibility is a PKCS #7
-   cryptographic message with content type signedData, following the
-   degenerate case where there are no signers.  The return message may
-   include a certification path from the new certificate to the
-   certification authority.  It may also include other certificates such
-   as cross-certificates that the certification authority considers
-   helpful, and it may include certificate-revocation lists (CRLs).
-   Another possibility is that the certification authority inserts the
-   new certificate into a central database.
-
-
-
-Nystrom & Kaliski            Informational                      [Page 4]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-   Note 1 - An entity would typically send a certification request after
-   generating a public-key/private-key pair, but may also do so after a
-   change in the entity's distinguished name.
-
-   Note 2 - The signature on the certification request prevents an
-   entity from requesting a certificate with another party's public key.
-   Such an attack would give the entity the minor ability to pretend to
-   be the originator of any message signed by the other party.  This
-   attack is significant only if the entity does not know the message
-   being signed and the signed part of the message does not identify the
-   signer.  The entity would still not be able to decrypt messages
-   intended for the other party, of course.
-
-   Note 3 - How the entity sends the certification request to a
-   certification authority is outside the scope of this document.  Both
-   paper and electronic forms are possible.
-
-   Note 4 - This document is not compatible with the certification
-   request syntax for Privacy-Enhanced Mail, as described in RFC 1424
-   [5].  The syntax here differs in three respects: It allows a set of
-   attributes; it does not include issuer name, serial number, or
-   validity period; and it does not require an "innocuous" message to be
-   signed.  This document is designed to minimize request size, an
-   important feature for certification authorities accepting requests on
-   paper.
-
-4. Certification request syntax
-
-   This section is divided into two parts.  The first part describes the
-   certification-request-information type CertificationRequestInfo, and
-   the second part describes the top-level type CertificationRequest.
-
- 4.1 CertificationRequestInfo
-
-   Certification request information shall have ASN.1 type
-   CertificationRequestInfo:
-
-   CertificationRequestInfo ::= SEQUENCE {
-        version       INTEGER { v1(0) } (v1,...),
-        subject       Name,
-        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
-        attributes    [0] Attributes{{ CRIAttributes }}
-   }
-
-   SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE {
-        algorithm        AlgorithmIdentifier {{IOSet}},
-        subjectPublicKey BIT STRING
-   }
-
-
-
-Nystrom & Kaliski            Informational                      [Page 5]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-   PKInfoAlgorithms ALGORITHM ::= {
-        ...  -- add any locally defined algorithms here -- }
-
-   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}
-
-   CRIAttributes  ATTRIBUTE  ::= {
-        ... -- add any locally defined attributes here -- }
-
-   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
-        type   ATTRIBUTE.&id({IOSet}),
-        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
-   }
-
-   The components of type CertificationRequestInfo have the following
-   meanings:
-
-        version is the version number, for compatibility with future
-          revisions of this document.  It shall be 0 for this version of
-          the standard.
-
-        subject is the distinguished name of the certificate subject
-          (the entity whose public key is to be certified).
-
-        subjectPublicKeyInfo contains information about the public key
-          being certified.  The information identifies the entity's
-          public-key algorithm (and any associated parameters); examples
-          of public-key algorithms include the rsaEncryption object
-          identifier from PKCS #1 [1].  The information also includes a
-          bit-string representation of the entity's public key.  For the
-          public-key algorithm just mentioned, the bit string contains
-          the DER encoding of a value of PKCS #1 type RSAPublicKey.  The
-          values of type SubjectPublicKeyInfo{} allowed for
-          subjectPKInfo are constrained to the values specified by the
-          information object set PKInfoAlgorithms, which includes the
-          extension marker (...).  Definitions of specific algorithm
-          objects are left to specifications that reference this
-          document.  Such specifications will be interoperable with
-          their future versions if any additional algorithm objects are
-          added after the extension marker.
-
-        attributes is a collection of attributes providing additional
-          information about the subject of the certificate.  Some
-          attribute types that might be useful here are defined in PKCS
-          #9.  An example is the challenge-password attribute, which
-          specifies a password by which the entity may request
-          certificate revocation.  Another example is information to
-          appear in X.509 certificate extensions (e.g. the
-          extensionRequest attribute from PKCS #9).  The values of type
-
-
-
-Nystrom & Kaliski            Informational                      [Page 6]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-          Attributes{} allowed for attributes are constrained to the
-          values specified by the information object set CRIAttributes.
-          Definitions of specific attribute objects are left to
-          specifications that reference this document.  Such
-          specifications will be interoperable with their future
-          versions if any additional attribute objects are added after
-          the extension marker.
-
- 4.2 CertificationRequest
-
-   A certification request shall have ASN.1 type CertificationRequest:
-
-   CertificationRequest ::= SEQUENCE {
-        certificationRequestInfo CertificationRequestInfo,
-        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
-        signature          BIT STRING
-   }
-
-   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
-        algorithm          ALGORITHM.&id({IOSet}),
-        parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
-   }
-
-   SignatureAlgorithms ALGORITHM ::= {
-        ... -- add any locally defined algorithms here -- }
-
-   The components of type CertificationRequest have the following
-   meanings:
-
-        certificateRequestInfo is the "certification request
-          information." It is the value being signed.
-
-        signatureAlgorithm identifies the signature algorithm (and any
-          associated parameters) under which the certification-request
-          information is signed.  For example, a specification might
-          include an ALGORITHM object for PKCS #1's
-          md5WithRSAEncryption in the information object set
-          SignatureAlgorithms:
-
-          SignatureAlgorithms ALGORITHM ::= {
-               ...,
-               { NULL IDENTIFIED BY md5WithRSAEncryption }
-          }
-
-        signature is the result of signing the certification request
-          information with the certification request subject's private
-          key.
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 7]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-   The signature process consists of two steps:
-
-        1. The value of the certificationRequestInfo component is DER
-           encoded, yielding an octet string.
-
-        2. The result of step 1 is signed with the certification request
-           subject's private key under the specified signature
-           algorithm, yielding a bit string, the signature.
-
-   Note - An equivalent syntax for CertificationRequest could be
-   written:
-
-   CertificationRequest ::= SIGNED { EncodedCertificationRequestInfo }
-        (CONSTRAINED BY { -- Verify or sign encoded
-         -- CertificationRequestInfo -- })
-
-   EncodedCertificationRequestInfo ::=
-        TYPE-IDENTIFIER.&Type(CertificationRequestInfo)
-
-   SIGNED { ToBeSigned } ::= SEQUENCE {
-        toBeSigned ToBeSigned,
-        algorithm  AlgorithmIdentifier { {SignatureAlgorithms} },
-        signature  BIT STRING
-   }
-
-5. Security Considerations
-
-   Security issues are discussed throughout this memo.
-
-6. Authors' Addresses
-
-   Magnus Nystrom
-   RSA Security
-   Box 10704
-   S-121 29 Stockholm
-   Sweden
-
-   EMail: magnus@rsasecurity.com
-
-
-   Burt Kaliski
-   RSA Security
-   20 Crosby Drive
-   Bedford, MA 01730 USA
-
-   EMail: bkaliski@rsasecurity.com
-
-
-
-
-
-Nystrom & Kaliski            Informational                      [Page 8]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-APPENDICES
-
-A. ASN.1 Module
-
-   This appendix includes all of the ASN.1 type and value definitions
-   contained in this document in the form of the ASN.1 module PKCS-10.
-
-   PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-   pkcs-10(10) modules(1) pkcs-10(1)}
-
-   DEFINITIONS IMPLICIT TAGS ::=
-
-   BEGIN
-
-   -- EXPORTS All --
-
-   -- All types and values defined in this module are exported for use
-   -- in other ASN.1 modules.
-
-   IMPORTS
-
-   informationFramework, authenticationFramework
-        FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
-        usefulDefinitions(0) 3}
-
-   ATTRIBUTE, Name
-        FROM InformationFramework informationFramework
-
-   ALGORITHM
-        FROM AuthenticationFramework authenticationFramework;
-
-   -- Certificate requests
-   CertificationRequestInfo ::= SEQUENCE {
-        version       INTEGER { v1(0) } (v1,...),
-        subject       Name,
-        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
-        attributes    [0] Attributes{{ CRIAttributes }}
-   }
-
-   SubjectPublicKeyInfo {ALGORITHM: IOSet} ::= SEQUENCE {
-        algorithm        AlgorithmIdentifier {{IOSet}},
-        subjectPublicKey BIT STRING
-   }
-
-   PKInfoAlgorithms ALGORITHM ::= {
-        ...  -- add any locally defined algorithms here -- }
-
-   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}
-
-
-
-Nystrom & Kaliski            Informational                      [Page 9]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-   CRIAttributes  ATTRIBUTE  ::= {
-        ... -- add any locally defined attributes here -- }
-
-   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
-        type   ATTRIBUTE.&id({IOSet}),
-        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
-   }
-
-   CertificationRequest ::= SEQUENCE {
-        certificationRequestInfo CertificationRequestInfo,
-        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
-        signature          BIT STRING
-   }
-
-   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
-        algorithm  ALGORITHM.&id({IOSet}),
-        parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
-   }
-
-   SignatureAlgorithms ALGORITHM ::= {
-        ... -- add any locally defined algorithms here -- }
-
-   END
-
-B. Intellectual property considerations
-
-   RSA Security makes no patent claims on the general constructions
-   described in this document, although specific underlying techniques
-   may be covered.
-
-   License to copy this document is granted provided that it is
-   identified as "RSA Security Inc.  Public-Key Cryptography Standards
-   (PKCS)" in all material mentioning or referencing this document.
-
-   RSA Security makes no representations regarding intellectual property
-   claims by other parties.  Such determination is the responsibility of
-   the user.
-
-C. Revision history
-
-   Version 1.0
-
-         Version 1.0 was the previous version of this document (also
-         published as "version 1.5" in [6]).
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 10]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-   Version 1.7
-
-         This version incorporates several editorial changes, including
-         updates to the references, and changes to ASN.1 type
-         definitions.  The following substantive changes have been made:
-
-         - This version refers to X.680-X.690, the current international
-           standards for ASN.1 and its encoding rules.  All references
-           to X.208 and X.209 have been eliminated.
-
-         - The X.690 standard requires that the encoded values of SET OF
-           components be sorted in ascending order under DER.
-           Regardless of this, applications should not rely on the
-           ordering of attribute components.
-
-         - All references to PKCS #6 Extended-Certificate Syntax
-           Standard have been removed.  With the addition of extensions
-           to X.509 version 3 certificates, RSA Laboratories is
-           withdrawing support for PKCS #6.
-
-   Note - The reason for using version 1.7 for this document is to avoid
-   confusion with [6], which is named version 1.5, and an unsupported
-   PKCS #10 version named Version 1.6.
-
-D. References
-
-   [1]  RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 2.0,
-        October 1998.
-
-   [2]  RSA Laboratories. PKCS #7: Cryptographic Message Syntax
-        Standard.  Version 1.5, November 1993.
-
-   [3]  RSA Laboratories. PKCS #9: Selected Attribute Types. Version
-        2.0, February 2000.
-
-   [4]  Adams, C. and S. Farrell, "Internet X.509 Public Key
-        Infrastructure - Certificate Management Protocols", RFC 2510,
-        March 1999.
-
-   [5]  Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
-        Part IV: Key Certification and Related Services", RFC 1424,
-        February 1993.
-
-   [6]  Kaliski, B., "PKCS #10: Certification Request Syntax Version
-        1.5", RFC 2314, March 1998.
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 11]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-   [7]  ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1998,
-        Information technology - Open Systems Interconnection - The
-        Directory: Overview of concepts, models and services.
-
-   [8]  ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1995,
-        Information technology - Open Systems Interconnection - The
-        Directory: Models.
-
-   [9]  ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
-        Information technology - Open Systems Interconnection -The
-        Directory:  Authentication framework.
-
-   [10] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
-        Information Technology - Abstract Syntax Notation One (ASN.1):
-        Specification of Basic Notation.
-
-   [11] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998,
-        Information Technology - Abstract Syntax Notation One (ASN.1):
-        Information Object Specification.
-
-   [12] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
-        Information Technology - Abstract Syntax Notation One (ASN.1):
-        Constraint Specification.
-
-   [13] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
-        Information Technology - Abstract Syntax Notation One (ASN.1):
-        Parameterization of ASN.1 Specifications.
-
-   [14] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
-        Information Technology - ASN.1 Encoding Rules: Specification of
-        Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
-        Distinguished Encoding Rules (DER).
-
-E. Contact Information & About PKCS
-
-   The Public-Key Cryptography Standards are specifications produced by
-   RSA Laboratories in cooperation with secure systems developers
-   worldwide for the purpose of accelerating the deployment of public-
-   key cryptography.  First published in 1991 as a result of meetings
-   with a small group of early adopters of public-key technology, the
-   PKCS documents have become widely referenced and implemented.
-   Contributions from the PKCS series have become part of many formal
-   and de facto standards, including ANSI X9 documents, PKIX, SET,
-   S/MIME, and SSL.
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 12]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-   Further development of PKCS occurs through mailing list discussions
-   and occasional workshops, and suggestions for improvement are
-   welcome.  For more information, contact:
-
-        PKCS Editor
-        RSA Laboratories
-        20 Crosby Drive
-        Bedford, MA  01730 USA
-        pkcs-editor@rsasecurity.com
-        http://www.rsasecurity.com/rsalabs/pkcs
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 13]
-
-RFC 2986       Certification Request Syntax Specification  November 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society 2000. All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others provided that the above copyright notice and this paragraph
-   are included on all such copies.  However, this document itself may
-   not be modified in any way, such as by removing the copyright notice
-   or references to the Internet Society or other Internet
-   organizations, except as required to translate it into languages
-   other than English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  IMPLIED, INCLUDING
-   BUT NOT  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Nystrom & Kaliski            Informational                     [Page 14]
-
diff --git a/doc/protocol/rfc3039.txt b/doc/protocol/rfc3039.txt
deleted file mode 100644
index 983dc156c3..0000000000
--- a/doc/protocol/rfc3039.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Santesson
-Request for Comments: 3039                                      AddTrust
-Category: Standards Track                                        W. Polk
-                                                                    NIST
-                                                               P. Barzin
-                                                                  SECUDE
-                                                              M. Nystrom
-                                                            RSA Security
-                                                            January 2001
-
-
-                Internet X.509 Public Key Infrastructure
-                     Qualified Certificates Profile
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document forms a certificate profile for Qualified Certificates,
-   based on RFC 2459, for use in the Internet.  The term Qualified
-   Certificate is used to describe a certificate with a certain
-   qualified status within applicable governing law.  Further, Qualified
-   Certificates are issued exclusively to physical persons.
-
-   The goal of this document is to define a general syntax independent
-   of local legal requirements.  The profile is however designed to
-   allow further profiling in order to meet specific local needs.
-
-   It is important to note that the profile does not define any legal
-   requirements for Qualified Certificates.
-
-   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.
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 1]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-Table of Contents
-
-   1  Introduction ................................................    2
-   2  Requirements and Assumptions ................................    3
-   2.1  Properties ................................................    4
-   2.2  Statement of Purpose ......................................    5
-   2.3  Policy Issues .............................................    5
-   2.4  Uniqueness of names .......................................    5
-   3  Certificate and Certificate Extensions Profile ..............    6
-   3.1  Basic Certificate Fields ..................................    6
-   3.1.1  Issuer ..................................................    6
-   3.1.2  Subject .................................................    6
-   3.2  Certificate Extensions ....................................    9
-   3.2.1  Subject Directory Attributes ............................    9
-   3.2.2  Certificate Policies ....................................   10
-   3.2.3  Key Usage ...............................................   10
-   3.2.4  Biometric Information ...................................   11
-   3.2.5  Qualified Certificate Statements ........................   12
-   4  Security Considerations .....................................   14
-   5  References ..................................................   15
-   6  Intellectual Property Rights ................................   16
-   A  ASN.1 definitions ...........................................   17
-   A.1  1988 ASN.1 Module .........................................   17
-   A.2  1993 ASN.1 Module .........................................   19
-   B  A Note on Attributes ........................................   24
-   C.  Example Certificate ........................................   24
-   C.1  ASN.1 Structure ...........................................   25
-   C.1.1 Extensions ...............................................   25
-   C.1.2 The certificate ..........................................   27
-   C.2  ASN.1 Dump ................................................   29
-   C.3  DER-encoding ..............................................   32
-   C.4  CA's public key ...........................................   33
-   Authors' Addresses .............................................   34
-   Full Copyright Statement .......................................   35
-
-1  Introduction
-
-   This specification is one part of a family of standards for the X.509
-   Public Key Infrastructure (PKI) for the Internet.  It is based on RFC
-   2459, which defines underlying certificate formats and semantics
-   needed for a full implementation of this standard.
-
-   The standard profiles the format for a specific type of certificates
-   named Qualified Certificates.  The term Qualified Certificates and
-   the assumptions that affects the scope of this document are discussed
-   in Section 2.
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 2]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-   Section 3 defines requirements on information content in Qualified
-   Certificates.  This profile addresses two fields in the basic
-   certificate as well as five certificate extensions.  The certificate
-   fields are the subject and issuer fields.  The certificate extensions
-   are subject directory attributes, certificate policies, key usage, a
-   private extension for storage of biometric data and a private
-   extension for storage of statements related to Qualified
-   Certificates.  The private extensions are presented in the 1993
-   Abstract Syntax Notation One (ASN.1), but in conformance with RFC
-   2459 the 1988 ASN.1 module in Appendix A contains all normative
-   definitions (the 1993 module in Appendix A is informative).
-
-   In Section 4, some security considerations are discussed in order to
-   clarify the security context in which Qualified Certificates are
-   assumed to be utilized.  Section 5 contains the references.
-
-   Appendix A contains all relevant ASN.1 [X.680] structures that are
-   not already defined in RFC 2459.  Appendix B contains a note on
-   attributes.  Appendix C contains an example certificate.  Appendix D
-   contains authors' addresses and Appendix E contains the IETF
-   Copyright Statement.
-
-   It should be noted that this specification does not define the
-   specific semantics of Qualified Certificates, and does not define the
-   policies that should be used with them.  That is, this document
-   defines what information should go into Qualified Certificates, but
-   not what that information means.  A system that uses Qualified
-   Certificates must define its own semantics for the information in
-   Qualified Certificates.  It is expected that laws and corporate
-   policies will make these definitions.
-
-2  Requirements and Assumptions
-
-   The term "Qualified Certificate" has been used by the European
-   Commission to describe a certain type of certificates with specific
-   relevance for European legislation.  This specification is intended
-   to support this class of certificates, but its scope is not limited
-   to this application.
-
-   Within this standard the term "Qualified Certificate" is used more
-   generally, describing the format for a certificate whose primary
-   purpose is identifying a person with high level of assurance in
-   public non-repudiation services.  The actual mechanisms that will
-   decide whether a certificate should or should not be considered to be
-   a "Qualified Certificate" in regard to any legislation are outside
-   the scope of this standard.
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 3]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-   Harmonization in the field of Qualified Certificates is essential
-   within several aspects that fall outside the scope of RFC 2459.  The
-   most important aspects that affect the scope of this specification
-   are:
-
-   -  Definition of names and identity information in order to identify
-      the associated subject in a uniform way.
-
-   -  Definition of information which identifies the CA and the
-      jurisdiction under which the CA operates when issuing a particular
-      certificate.
-
-   -  Definition of key usage extension usage for Qualified
-      Certificates.
-
-   -  Definition of information structure for storage of biometric
-      information.
-
-   -  Definition of a standardized way to store predefined statements
-      with relevance for Qualified Certificates.
-
-   -  Requirements for critical extensions.
-
-2.1  Properties
-
-   A Qualified Certificate as defined in this standard is assumed to
-   have the following properties:
-
-   -  The certificate is issued by a CA that makes a public statement
-      that the certificate serves the purpose of a Qualified
-      Certificate, as discussed in Section 2.2
-
-   -  The certificate indicates a certificate policy consistent with
-      liabilities, practices and procedures undertaken by the CA, as
-      discussed in 2.3
-
-   -  The certificate is issued to a natural person (living human
-      being).
-
-   -  The certificate contains an identity based on a pseudonym or a
-      real name of the subject.
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 4]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-2.2  Statement of Purpose
-
-   For a certificate to serve the purpose of being a Qualified
-   Certificate, this profile assumes that the CA will have to include in
-   the certificate information that explicitly defines this intent.
-
-   The function of this information is thus to assist any concerned
-   entity in evaluating the risk associated with creating or accepting
-   signatures that are based on a Qualified Certificate.
-
-   This profile defines two complementary ways to include this
-   information:
-
-   -  As information defined by a certificate policy included in the
-      certificate policies extension, and
-
-   -  As a statement included in the Qualified Certificates Statements
-      extension.
-
-2.3  Policy Issues
-
-   Certain policy aspects define the context in which this profile is to
-   be understood and used.  It is however outside the scope of this
-   profile to specify any policies or legal aspects that will govern
-   services that issue or utilize certificates according to this
-   profile.
-
-   It is however assumed that the issuing CA will undertake to follow a
-   publicly available certificate policy that is consistent with its
-   liabilities, practices and procedures.
-
-2.4  Uniqueness of names
-
-   Distinguished name is originally defined in X.501 [X.501] as a
-   representation of a directory name, defined as a construct that
-   identifies a particular object from among the set of all objects.  An
-   object can be assigned a distinguished name without being represented
-   by an entry in the Directory, but this name is then the name its
-   object entry could have had if it were represented in the Directory.
-   In the context of qualified certificates, a distinguished name
-   denotes a set of attribute values [X.501] which forms a name that is
-   unambiguous within a certain domain that forms either a real or a
-   virtual DIT (Directory Information Tree)[X.501].  In the case of
-   subject names the domain is assumed to be at least the issuing domain
-   of the CA.  The distinguished name MUST be unique for each subject
-   entity certified by the one CA as defined by the issuer name field,
-   during the whole life time of the CA.
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 5]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-3  Certificate and Certificate Extensions Profile
-
-   This section defines a profile for Qualified Certificates.  The
-   profile is based on the Internet certificate profile RFC 2459 which
-   in turn is based on the X.509 version 3 format.  For full
-   implementation of this section implementers are REQUIRED to consult
-   the underlying formats and semantics defined in RFC 2459.
-
-   ASN.1 definitions relevant for this section that are not supplied by
-   RFC 2459 are supplied in Appendix A.
-
-3.1  Basic Certificate Fields
-
-   This specification provides additional details regarding the contents
-   of two fields in the basic certificate.  These fields are the issuer
-   and subject fields.
-
-3.1.1  Issuer
-
-   The issuer field SHALL identify the organization responsible for
-   issuing the certificate.  The name SHOULD be an officially registered
-   name of the organization.
-
-   The identity of the issuer SHALL be specified using an appropriate
-   subset of the following attributes:
-
-         domainComponent;
-         countryName;
-         stateOrProvinceName;
-         organizationName;
-         localityName; and
-         serialNumber.
-
-   Additional attributes MAY be present but they SHOULD NOT be necessary
-   to identify the issuing organization.
-
-   Attributes present in the issuer field SHOULD be consistent with the
-   laws under which the issuer operates.
-
-   A relying party MAY have to consult associated certificate policies
-   and/or the issuer's CPS, in order to determine the semantics of name
-   fields and the laws under which the issuer operates.
-
-3.1.2  Subject
-
-   The subject field of a certificate compliant with this profile SHALL
-   contain a distinguished name of the subject (see 2.4 for definition
-   of distinguished name).
-
-
-
-Santesson, et al.           Standards Track                     [Page 6]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-   The subject field SHALL contain an appropriate subset of the
-   following attributes:
-
-      countryName;
-      commonName;
-      surname;
-      givenName;
-      pseudonym;
-      serialNumber;
-      organizationName;
-      organizationalUnitName;
-      stateOrProvinceName
-      localityName and
-      postalAddress.
-
-   Other attributes may be present but MUST NOT be necessary to
-   distinguish the subject name from other subject names within the
-   issuer domain.
-
-   Of these attributes, the subject field SHALL include at least one of
-   the following:
-
-      Choice   I:  commonName
-      Choice  II:  givenName
-      Choice III:  pseudonym
-
-   The countryName attribute value specifies a general context in which
-   other attributes are to be understood.  The country attribute does
-   not necessarily indicate the subject's country of citizenship or
-   country of residence, nor does it have to indicate the country of
-   issuance.
-
-   Note: Many X.500 implementations require the presence of countryName
-   in the DIT.  In cases where the subject name, as specified in the
-   subject field, specifies a public X.500 directory entry, the
-   countryName attribute SHOULD always be present.
-
-   The commonName attribute value SHALL, when present, contain a name of
-   the subject.  This MAY be in the subject's preferred presentation
-   format, or a format preferred by the CA, or some other format.
-   Pseudonyms, nicknames and names with spelling other than defined by
-   the registered name MAY be used.  To understand the nature of the
-   name presented in commonName, complying applications MAY have to
-   examine present values of the givenName and surname attributes, or
-   the pseudonym attribute.
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 7]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-   Note: Many client implementations presuppose the presence of the
-   commonName attribute value in the subject field and use this value to
-   display the subject's name regardless of present givenName, surname
-   or pseudonym attribute values.
-
-   The surname and givenName attribute types SHALL, if present, contain
-   the registered name of the subject, in accordance with the laws under
-   which the CA prepares the certificate.  These attributes SHALL be
-   used in the subject field if the commonName attribute is not present.
-   In cases where the subject only has a single name registered, the
-   givenName attribute SHALL be used and the surname attribute SHALL be
-   omitted.
-
-   The pseudonym attribute type SHALL, if present, contain a pseudonym
-   of the subject.  Use of the pseudonym attribute MUST NOT be combined
-   with use of any of the attributes surname and/or givenName.
-
-   The serialNumber attribute type SHALL, when present, be used to
-   differentiate between names where the subject field would otherwise
-   be identical.  This attribute has no defined semantics beyond
-   ensuring uniqueness of subject names.  It MAY contain a number or
-   code assigned by the CA or an identifier assigned by a government or
-   civil authority.  It is the CA's responsibility to ensure that the
-   serialNumber is sufficient to resolve any subject name collisions.
-
-   The organizationName and the organizationalUnitName attribute types
-   SHALL, when present, be used to store the name and relevant
-   information of an organization with which the subject is associated.
-   The type of association between the organization and the subject is
-   beyond the scope of this document.
-
-   The postalAddress, the stateOrProvinceName and the localityName
-   attribute types SHALL, when present, be used to store address and
-   geographical information with which the subject is associated.  If an
-   organizationName value also is present then the postalAddress,
-   stateOrProvinceName and localityName attribute values SHALL be
-   associated with the specified organization.  The type of association
-   between the postalAddress, stateOrProvinceName and the localityName
-   and either the subject or the organizationName is beyond the scope of
-   this document.
-
-   Compliant implementations SHALL be able to interpret the attributes
-   named in this section.
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 8]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-3.2  Certificate Extensions
-
-   This specification provides additional details regarding the contents
-   of five certificate extensions.  These extensions are the subject
-   directory attributes, certificate policies, key usage, private
-   extension for biometric information and private extension for
-   Qualified Certificate statements.
-
-3.2.1  Subject Directory Attributes
-
-   The subjectDirectoryAttributes extension MAY contain additional
-   attributes, associated with the subject, as complement to present
-   information in the subject field and the subject alternative name
-   extension.
-
-   Attributes suitable for storage in this extension are attributes,
-   which are not part of the subject's distinguished name, but which MAY
-   still be useful for other purposes (e.g., authorization).
-
-   This extension MUST NOT be marked critical.
-
-   Compliant implementations SHALL be able to interpret the following
-   attributes:
-
-      title;
-      dateOfBirth;
-      placeOfBirth;
-      gender;
-      countryOfCitizenship; and
-      countryOfResidence.
-
-   Other attributes MAY be included according to local definitions.
-
-   The title attribute type SHALL, when present, be used to store a
-   designated position or function of the subject within the
-   organization specified by present organizational attributes in the
-   subject field.  The association between the title, the subject and
-   the organization is beyond the scope of this document.
-
-   The dateOfBirth attribute SHALL, when present, contain the value of
-   the date of birth of the subject.  The manner in which the date of
-   birth is associated with the subject is outside the scope of this
-   document.
-
-   The placeOfBirth attribute SHALL, when present, contain the value of
-   the place of birth of the subject.  The manner in which the place of
-   birth is associated with the subject is outside the scope of this
-   document.
-
-
-
-Santesson, et al.           Standards Track                     [Page 9]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-   The gender attribute SHALL, when present, contain the value of the
-   gender of the subject.  For females the value "F" (or "f") and for
-   males the value "M" (or "m") have to be used.  The manner in which
-   the gender is associated with the subject is outside the scope of
-   this document.
-
-   The countryOfCitizenship attribute SHALL, when present, contain the
-   identifier of at least one of the subject's claimed countries of
-   citizenship at the time that the certificate was issued.  If the
-   subject is a citizen of more than one country, more than one country
-   MAY be present.  Determination of citizenship is a matter of law and
-   is outside the scope of this document.
-
-   The countryOfResidence attribute SHALL, when present, contain the
-   value of at least one country in which the subject is resident.  If
-   the subject is a resident of more than one country, more than one
-   country MAY be present.  Determination of residence is a matter of
-   law and is outside the scope of this document.
-
-3.2.2 Certificate Policies
-
-   The certificate policies extension SHALL contain the identifier of at
-   least one certificate policy which reflects the practices and
-   procedures undertaken by the CA.  The certificate policy extension
-   MAY be marked critical.
-
-   Information provided by the issuer stating the purpose of the
-   certificate as discussed in Section 2.2 SHOULD be evident through
-   indicated policies.
-
-   The certificate policies extension SHOULD include all policy
-   information needed for validation of the certificate.  If policy
-   information is included in the QCStatements extension (see 3.2.5),
-   then this information SHOULD also be defined by indicated policies.
-
-   Certificate policies MAY be combined with any qualifier defined in
-   RFC 2459.
-
-3.2.3  Key Usage
-
-   The key usage extension SHALL be present.  If the key usage
-   nonRepudiation bit is asserted then it SHOULD NOT be combined with
-   any other key usage , i.e., if set, the key usage non-repudiation
-   SHOULD be set exclusively.
-
-   The key usage extension MAY be marked critical.
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 10]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-3.2.4  Biometric Information
-
-   This section defines an extension for storage of biometric
-   information.  Biometric information is stored in the form of a hash
-   of a biometric template.
-
-   The purpose of this extension is to provide means for authentication
-   of biometric information.  The biometric information that corresponds
-   to the stored hash is not stored in this extension, but the extension
-   MAY include an URI pointing to a location where this information can
-   be obtained.  If included, this URI does not imply that this is the
-   only way to access this information.
-
-   It is RECOMMENDED that biometric information in this extension is
-   limited to information types suitable for human verification, i.e.,
-   where the decision of whether the information is an accurate
-   representation of the subject is naturally performed by a person.
-   This implies a usage where the biometric information is represented
-   by, for example, a graphical image displayed to the relying party,
-   which MAY be used by the relying party to enhance identification of
-   the subject.
-
-   This extension MUST NOT be marked critical.
-
-      biometricInfo  EXTENSION ::= {
-          SYNTAX             BiometricSyntax
-          IDENTIFIED BY      id-pe-biometricInfo }
-
-      id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}
-
-      BiometricSyntax ::= SEQUENCE OF BiometricData
-
-      BiometricData ::= SEQUENCE {
-          typeOfBiometricData  TypeOfBiometricData,
-          hashAlgorithm        AlgorithmIdentifier,
-          biometricDataHash    OCTET STRING,
-          sourceDataUri        IA5String OPTIONAL }
-
-      TypeOfBiometricData ::= CHOICE {
-          predefinedBiometricType    PredefinedBiometricType,
-          biometricDataID            OBJECT IDENTIFIER }
-
-      PredefinedBiometricType ::= INTEGER { picture(0),
-          handwritten-signature(1)} (picture|handwritten-signature,...)
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 11]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-   The predefined biometric type picture, when present, SHALL identify
-   that the source picture is in the form of a displayable graphical
-   image of the subject.  The hash of the graphical image SHALL only be
-   calculated over the image data excluding any labels defining the
-   image type.
-
-   The predefined biometric type handwritten-signature, when present,
-   SHALL identify that the source data is in the form of a displayable
-   graphical image of the subject's handwritten signature.  The hash of
-   the graphical image SHALL only be calculated over the image data
-   excluding any labels defining the image type.
-
-3.2.5  Qualified Certificate Statements
-
-   This section defines an extension for inclusion of defined statements
-   related to Qualified Certificates.
-
-   A typical statement suitable for inclusion in this extension MAY be a
-   statement by the issuer that the certificate is issued as a Qualified
-   Certificate in accordance with a particular legal system (as
-   discussed in Section 2.2).
-
-   Other statements suitable for inclusion in this extension MAY be
-   statements related to the applicable legal jurisdiction within which
-   the certificate is issued.  As an example this MAY include a maximum
-   reliance limit for the certificate indicating restrictions on CA's
-   liability.
-
-   Each statement SHALL include an object identifier for the statement
-   and MAY also include optional qualifying data contained in the
-   statementInfo parameter.
-
-   If the statementInfo parameter is included then the object identifier
-   of the statement SHALL define the syntax and SHOULD define the
-   semantics of this parameter.  If the object identifier does not
-   define the semantics, a relying party may have to consult a relevant
-   certificate policy or CPS to determine the exact semantics.
-
-   This extension may be critical or non-critical.  If the extension is
-   critical, this means that all statements included in the extension
-   are regarded as critical.
-
-      qcStatements  EXTENSION ::= {
-          SYNTAX             QCStatements
-          IDENTIFIED BY      id-pe-qcStatements }
-
-      id-pe-qcStatements     OBJECT IDENTIFIER ::= { id-pe 3 }
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 12]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-      QCStatements ::= SEQUENCE OF QCStatement
-
-      QCStatement ::= SEQUENCE {
-          statementId   QC-STATEMENT.&Id({SupportedStatements}),
-          statementInfo QC-STATEMENT.&Type
-          ({SupportedStatements}{@statementId}) OPTIONAL }
-
-      SupportedStatements QC-STATEMENT ::= { qcStatement-1,...}
-
-3.2.5.1 Predefined Statements
-
-   This profile includes one predefined object identifier (id-qcs-
-   pkixQCSyntax-v1), identifying conformance with syntax and semantics
-   defined in this profile.  This Qualified Certificate profile is
-   referred to as version 1.
-
-      qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation
-          IDENTIFIED BY id-qcs-pkixQCSyntax-v1 }
-      --  This statement identifies conformance with syntax and
-      --  semantics defined in this Qualified Certificate profile
-      --  (Version 1). The SemanticsInformation may optionally contain
-      --  additional semantics information as specified.
-
-      SemanticsInformation ::= SEQUENCE {
-          semanticsIdentifier        OBJECT IDENTIFIER   OPTIONAL,
-          nameRegistrationAuthorities NameRegistrationAuthorities
-                                                          OPTIONAL }
-          (WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
-           WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
-
-      NameRegistrationAuthorities ::=  SEQUENCE SIZE (1..MAX) OF
-          GeneralName
-
-   The SementicsInformation component identified by id-qcs-
-   pkixQCSyntax-v1 MAY contain a semantics identifier and MAY identify
-   one or more name registration authorities.
-
-   The semanticsIdentifier component, if present, SHALL contain an OID,
-   defining semantics for attributes and names in basic certificate
-   fields and certificate extensions.  The OID may define semantics for
-   all, or for a subgroup of all present attributes and/or names.
-
-   The NameRegistrationAuthorities component, if present, SHALL contain
-   a name of one or more name registration authorities, responsible for
-   registration of attributes or names associated with the subject.  The
-   association between an identified name registration authority and
-   present attributes MAY be defined by a semantics identifier OID, by a
-   certificate policy (or CPS) or some other implicit factors.
-
-
-
-Santesson, et al.           Standards Track                    [Page 13]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-   If a value of type SemanticsInformation is present in a QCStatement
-   then at least one of the fields semanticsIdentifier and
-   nameRegistrationAuthorities must be present, as indicated.
-
-4  Security Considerations
-
-   The legal value of a digital signature that is validated with a
-   Qualified Certificate will be highly dependent upon the policy
-   governing the use of the associated private key.  Both the private
-   key holder as well as the relying party should make sure that the
-   private key is used only with the consent of the legitimate key
-   holder.
-
-   Since the public keys are for public use with legal implications for
-   involved parties, certain conditions should exist before CAs issue
-   certificates as Qualified Certificates.  The associated private keys
-   must be unique for the subject, and must be maintained under the
-   subject's sole control.  That is, a CA should not issue a qualified
-   certificate if the means to use the private key is not protected
-   against unintended usage.  This implies that the CA have some
-   knowledge about the subject's cryptographic module.
-
-   The CA must further verify that the public key contained in the
-   certificate is legitimately representing the subject.
-
-   CAs should not issue CA certificates with policy mapping extensions
-   indicating acceptance of another CA's policy unless these conditions
-   are met.
-
-   Combining the nonRepudiation bit in the keyUsage certificate
-   extension with other keyUsage bits may have security implications and
-   this specification therefore recommends against such practices.
-
-   The ability to compare two qualified certificates to determine if
-   they represent the same physical entity is dependent on the semantics
-   of the subjects' names.  The semantics of a particular attribute may
-   be different for different issuers.  Comparing names without
-   knowledge of the semantics of names in these particular certificates
-   may provide misleading results.
-
-   This specification is a profile of RFC 2459.  The security
-   considerations section of that document applies to this specification
-   as well.
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 14]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-5 References
-
-   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
-              Sataluri, "Using Domains in LDAP/X.500 Distinguished
-              Names", RFC 2247, January 1998.
-
-   [RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-              X.509 Public Key Infrastructure: Certificate and CRL
-              Profile", RFC 2459, January 1999.
-
-   [RFC 2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
-              Classes and Attribute Types Version 2.0", RFC 2985,
-              November 2000.
-
-   [X.501]    ITU-T Recommendation X.501: Information Technology - Open
-              Systems Interconnection - The Directory: Models, June
-              1993.
-
-   [X.509]    ITU-T Recommendation X.509: Information Technology - Open
-              Systems Interconnection - The Directory: Authentication
-              Framework, June 1997.
-
-   [X.520]    ITU-T Recommendation X.520: Information Technology - Open
-              Systems Interconnection - The Directory: Selected
-              Attribute Types, June 1993.
-
-   [X.680]    ITU-T Recommendation X.680: Information Technology -
-              Abstract Syntax Notation One, 1997.
-
-   [ISO 3166] ISO Standard 3166: Codes for the representation of names
-              of countries, 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 15]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-6 Intellectual Property Rights
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 16]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-A. ASN.1 definitions
-
-   As in RFC 2459, ASN.1 modules are supplied in two different variants
-   of the ASN.1 syntax.
-
-   Appendix A.1 is in the 1988 syntax, and does not use macros.
-   However, since the module imports type definitions from modules in
-   RFC 2459 which are not completely in the 1988 syntax, the same
-   comments as in RFC 2459 regarding its use applies here as well; i.e.,
-   Appendix A.1 may be parsed by an 1988 ASN.1-parser by removing the
-   definitions for the UNIVERSAL types and all references to them in RFC
-   2459's 1988 modules.
-
-   Appendix A.2 is in the 1993 syntax.  However, since the module
-   imports type definitions from modules in RFC 2459 which are not
-   completely in the 1993 syntax, the same comments as in RFC 2459
-   regarding its use applies here as well; i.e., Appendix A.2 may be
-   parsed by an 1993 ASN.1-parser by removing the UTF8String choice from
-   the definition of DirectoryString in the module PKIX1Explicit93 in
-   RFC 2459.  Appendix A.2 may be parsed "as is" by an 1997 ASN.1
-   parser, however.
-
-   In case of discrepancies between these modules, the 1988 module is
-   the normative one.
-
-A.1 1988 ASN.1 Module
-
-PKIXqualified88 {iso(1) identified-organization(3) dod(6)
-    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-    id-mod-qualified-cert-88(10) }
-
-DEFINITIONS EXPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
-IMPORTS
-
-GeneralName
-    FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
-    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-    id-pkix1-implicit-88(2)}
-
-AlgorithmIdentifier, DirectoryString, Attribute, AttributeType,
-    id-pkix, id-pe, id-at
-    FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
-    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-
-
-
-Santesson, et al.           Standards Track                    [Page 17]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-    id-pkix1-explicit-88(1)};
-
--- Locally defined OIDs
-
--- Arc for QC personal data attributes
-id-pda  OBJECT IDENTIFIER ::= { id-pkix 9 }
--- Arc for QC statements
-id-qcs  OBJECT IDENTIFIER ::= { id-pkix 11 }
-
--- Attributes
-
-id-at-serialNumber          AttributeType ::= { id-at 5 }
-SerialNumber ::=            PrintableString (SIZE(1..64))
-
-id-at-postalAddress         AttributeType ::= { id-at 16 }
-PostalAddress ::=           SEQUENCE SIZE (1..6) OF DirectoryString
-
-id-at-pseudonym             AttributeType ::= { id-at 65 }
-Pseudonym ::=               DirectoryString
-
-domainComponent             AttributeType ::=
-                            { 0 9 2342 19200300 100 1 25 }
-DomainComponent ::=         IA5String
-
-id-pda-dateOfBirth          AttributeType ::= { id-pda 1 }
-DateOfBirth ::=             GeneralizedTime
-
-id-pda-placeOfBirth         AttributeType ::= { id-pda 2 }
-PlaceOfBirth ::=            DirectoryString
-
-id-pda-gender               AttributeType ::= { id-pda 3 }
-Gender ::=                  PrintableString (SIZE(1))
-                            -- "M", "F", "m" or "f"
-
-id-pda-countryOfCitizenship AttributeType ::= { id-pda 4 }
-CountryOfCitizenship ::=    PrintableString (SIZE (2))
-                            -- ISO 3166 Country Code
-
-id-pda-countryOfResidence   AttributeType ::= { id-pda 5 }
-CountryOfResidence ::=      PrintableString (SIZE (2))
-                            -- ISO 3166 Country Code
-
--- Private extensions
-
--- Biometric info extension
-
-id-pe-biometricInfo OBJECT IDENTIFIER  ::= {id-pe 2}
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 18]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-BiometricSyntax ::= SEQUENCE OF BiometricData
-
-BiometricData ::= SEQUENCE {
-    typeOfBiometricData  TypeOfBiometricData,
-    hashAlgorithm        AlgorithmIdentifier,
-    biometricDataHash    OCTET STRING,
-    sourceDataUri        IA5String OPTIONAL }
-
-TypeOfBiometricData ::= CHOICE {
-    predefinedBiometricType   PredefinedBiometricType,
-    biometricDataOid          OBJECT IDENTIFIER }
-
-PredefinedBiometricType ::= INTEGER {
-    picture(0),handwritten-signature(1)}
-    (picture|handwritten-signature)
-
--- QC Statements Extension
-
-id-pe-qcStatements OBJECT IDENTIFIER ::= { id-pe 3}
-
-QCStatements ::= SEQUENCE OF QCStatement
-
-QCStatement ::= SEQUENCE {
-    statementId        OBJECT IDENTIFIER,
-    statementInfo      ANY DEFINED BY statementId OPTIONAL}
-
--- QC statements
-id-qcs-pkixQCSyntax-v1   OBJECT IDENTIFIER ::= { id-qcs 1 }
-
---  This statement identifies conformance with syntax and
---  semantics defined in this Qualified Certificate profile
---  (Version 1). This statement may optionally contain
---  additional semantics information as specified below.
-
-SemanticsInformation  ::= SEQUENCE {
-    semanticsIndentifier        OBJECT IDENTIFIER OPTIONAL,
-    nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
-    } -- At least one field shall be present
-
-NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
-END
-
-A.2 1993 ASN.1  Module
-
-PKIXqualified93 {iso(1) identified-organization(3) dod(6)
-    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-    id-mod-qualified-cert-93(11) }
-
-
-
-Santesson, et al.           Standards Track                    [Page 19]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-DEFINITIONS EXPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
-IMPORTS
-
-authorityKeyIdentifier, subjectKeyIdentifier, keyUsage,
-    extendedKeyUsage, privateKeyUsagePeriod, certificatePolicies,
-    policyMappings, subjectAltName, issuerAltName, basicConstraints,
-    nameConstraints, policyConstraints, cRLDistributionPoints,
-    subjectDirectoryAttributes, authorityInfoAccess, GeneralName,
-    OTHER-NAME
-    FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
-    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-    id-pkix1-implicit-93(4)}
-
-id-pkix, AlgorithmIdentifier, ATTRIBUTE, Extension, EXTENSION,
-    DirectoryString{}, ub-name, id-pe, id-at, id-at-commonName,
-    id-at-surname, id-at-countryName, id-at-localityName,
-    id-at-stateOrProvinceName, id-at-organizationName,
-    id-at-organizationalUnitName, id-at-givenName, id-at-dnQualifier,
-    pkcs9email, title, organizationName, organizationalUnitName,
-    stateOrProvinceName, localityName, countryName,
-    generationQualifier, dnQualifier, initials, givenName, surname,
-    commonName, name
-    FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
-    internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-    id-pkix1-explicit-93(3)};
-
--- Object Identifiers
-
--- Externally defined OIDs
-id-at-serialNumber  OBJECT IDENTIFIER ::= { id-at 5}
-id-at-postalAddress OBJECT IDENTIFIER ::= { id-at 16 }
-id-at-pseudonym     OBJECT IDENTIFIER ::= { id-at 65 }
-id-domainComponent  OBJECT IDENTIFIER ::= { 0 9 2342 19200300 100 1 25 }
-
--- Locally defined OIDs
-
--- Arc for QC personal data attributes
-
-id-pda  OBJECT IDENTIFIER ::= { id-pkix 9 }
--- Arc for QC statements
-id-qcs  OBJECT IDENTIFIER ::= { id-pkix 11 }
-
--- Private extensions
-
-
-
-Santesson, et al.           Standards Track                    [Page 20]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-id-pe-biometricInfo         OBJECT IDENTIFIER ::= { id-pe 2 }
-id-pe-qcStatements          OBJECT IDENTIFIER ::= { id-pe 3 }
-
--- Personal data attributes
-id-pda-dateOfBirth          OBJECT IDENTIFIER ::= { id-pda 1 }
-id-pda-placeOfBirth         OBJECT IDENTIFIER ::= { id-pda 2 }
-id-pda-gender               OBJECT IDENTIFIER ::= { id-pda 3 }
-id-pda-countryOfCitizenship OBJECT IDENTIFIER ::= { id-pda 4 }
-id-pda-countryOfResidence   OBJECT IDENTIFIER ::= { id-pda 5 }
-
--- QC statements
-id-qcs-pkixQCSyntax-v1      OBJECT IDENTIFIER ::= { id-qcs 1 }
-
--- Object Sets
-
--- The following information object set is defined to constrain the
--- set of legal certificate extensions. Note that this set is an
--- extension of the ExtensionSet defined in RFC 2459.
-ExtensionSet EXTENSION ::= {
-    authorityKeyIdentifier |
-    subjectKeyIdentifier |
-    keyUsage |
-    extendedKeyUsage |
-    privateKeyUsagePeriod |
-    certificatePolicies |
-    policyMappings |
-    subjectAltName |
-    issuerAltName |
-    basicConstraints |
-    nameConstraints |
-    policyConstraints |
-    cRLDistributionPoints |
-    subjectDirectoryAttributes |
-    authorityInfoAccess |
-    biometricInfo |
-    qcStatements, ... }
-
--- The following information object set is defined to constrain the
--- set of attributes applications are required to recognize in
--- distinguished names. The set may of course be augmented to meet
--- local requirements.  Note that deleting members of the set may
--- prevent interoperability with conforming implementations, and that
--- this set is an extension of the SupportedAttributes set in RFC 2459.
-
-SupportedAttributes ATTRIBUTE ::= {
-    countryName | commonName | surname | givenName | pseudonym |
-    serialNumber | organizationName | organizationalUnitName |
-    stateOrProvinceName | localityName | postalAddress |
-
-
-
-Santesson, et al.           Standards Track                    [Page 21]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-    pkcs9email | domainComponent | dnQualifier,
-    ... -- For future extensions -- }
-
--- The following information object set is defined to constrain the
--- set of attributes applications are required to recognize in
--- subjectDirectoryAttribute extensions. The set may be augmented to
--- meet local requirements.  Note that deleting members of the set
--- may prevent interoperability with conforming implementations.
-PersonalDataAttributeSet ATTRIBUTE ::= {
-    title | dateOfBirth | placeOfBirth | gender | countryOfCitizenship |
-    countryOfResidence, ... }
-
--- Attributes
-
--- serialNumber from X.520
-serialNumber ATTRIBUTE ::= {
-    WITH SYNTAX PrintableString (SIZE(1..64))
-    ID          id-at-serialNumber }
-
--- postalAddress from X.520
-postalAddress ATTRIBUTE ::= {
-    WITH SYNTAX SEQUENCE SIZE (1..6) OF DirectoryString { 30 }
-    ID          id-at-postalAddress }
-
--- pseudonym from (forthcoming) X.520)
-pseudonym ATTRIBUTE ::= {
-    WITH SYNTAX DirectoryString { ub-name }
-    ID          id-at-pseudonym }
-
--- domainComponent from RFC 2247
-domainComponent ATTRIBUTE ::= {
-    WITH SYNTAX IA5String
-    ID          id-domainComponent }
-
-dateOfBirth ATTRIBUTE ::= {
-    WITH SYNTAX GeneralizedTime
-    ID          id-pda-dateOfBirth }
-
-placeOfBirth ATTRIBUTE ::= {
-    WITH SYNTAX DirectoryString { ub-name }
-    ID          id-pda-placeOfBirth }
-
-gender ATTRIBUTE ::= {
-    WITH SYNTAX PrintableString (SIZE(1) ^ FROM("M"|"F"|"m"|"f"))
-    ID          id-pda-gender }
-
-countryOfCitizenship ATTRIBUTE ::= {
-    WITH SYNTAX PrintableString (SIZE (2))
-
-
-
-Santesson, et al.           Standards Track                    [Page 22]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-        (CONSTRAINED BY { -- ISO 3166 codes only -- })
-    ID          id-pda-countryOfCitizenship }
-
-countryOfResidence ATTRIBUTE ::= {
-    WITH SYNTAX PrintableString (SIZE (2))
-        (CONSTRAINED BY { -- ISO 3166 codes only -- })
-    ID          id-pda-countryOfResidence }
-
--- Private extensions
-
--- Biometric info extension
-
-biometricInfo  EXTENSION ::= {
-    SYNTAX             BiometricSyntax
-    IDENTIFIED BY      id-pe-biometricInfo }
-
-BiometricSyntax ::= SEQUENCE OF BiometricData
-
-BiometricData ::= SEQUENCE {
-    typeOfBiometricData TypeOfBiometricData,
-    hashAlgorithm       AlgorithmIdentifier,
-    biometricDataHash   OCTET STRING,
-    sourceDataUri       IA5String OPTIONAL,
-    ... -- For future extensions -- }
-
-TypeOfBiometricData ::= CHOICE {
-    predefinedBiometricType PredefinedBiometricType,
-    biometricDataOid        OBJECT IDENTIFIER }
-
-PredefinedBiometricType ::= INTEGER { picture(0),
-    handwritten-signature(1)} (picture|handwritten-signature,...)
-
--- QC Statements Extension
-
-qcStatements  EXTENSION ::= {
-    SYNTAX        QCStatements
-    IDENTIFIED BY id-pe-qcStatements }
-
-QCStatements ::= SEQUENCE OF QCStatement
-
-QCStatement ::= SEQUENCE {
-    statementId   QC-STATEMENT.&id({SupportedStatements}),
-    statementInfo QC-STATEMENT.&Type
-    ({SupportedStatements}{@statementId}) OPTIONAL }
-
-QC-STATEMENT ::= CLASS {
-    &id   OBJECT IDENTIFIER UNIQUE,
-    &Type OPTIONAL }
-
-
-
-Santesson, et al.           Standards Track                    [Page 23]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-WITH SYNTAX {
-    [SYNTAX &Type] IDENTIFIED BY &id }
-
-qcStatement-1 QC-STATEMENT ::= { SYNTAX SemanticsInformation
-    IDENTIFIED BY id-qcs-pkixQCSyntax-v1}
-    --  This statement identifies conformance with syntax and
-    --  semantics defined in this Qualified Certificate profile
-    --  (Version 1). The SemanticsInformation may optionally contain
-    --  additional semantics information as specified.
-
-SemanticsInformation ::= SEQUENCE {
-    semanticsIdentifier         OBJECT IDENTIFIER OPTIONAL,
-    nameRegistrationAuthorities NameRegistrationAuthorities OPTIONAL
-    }(WITH COMPONENTS {..., semanticsIdentifier PRESENT}|
-      WITH COMPONENTS {..., nameRegistrationAuthorities PRESENT})
-
-NameRegistrationAuthorities ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
--- The following information object set is defined to constrain the
--- set of attributes applications are required to recognize as QCSs.
-SupportedStatements QC-STATEMENT ::= {
-    qcStatement-1, ... -- For future extensions -- }
-
-END
-
-B. A Note on Attributes
-
-   This document defines several new attributes, both for use in the
-   subject field of issued certificates and in the
-   subjectDirectoryAttributes extension.  In the interest of conformity,
-   they have been defined here using the ASN.1 ATTRIBUTE definition from
-   RFC 2459, which is sufficient for the purposes of this document, but
-   greatly simplified in comparison with ISO/ITU's definition.  A
-   complete definition of these new attributes (including matching
-   rules), along with object classes to support them in LDAP-accessible
-   directories, can be found in [PKCS 9].
-
-C. Example Certificate
-
-   This section contains the ASN.1 structure, an ASN.1 dump, and the
-   DER-encoding of a certificate issued in conformance with this
-   profile.  The example has been developed with the help of the OSS
-   ASN.1 compiler.  The certificate has the following characteristics:
-
-      1.  The certificate is signed with RSA and the SHA-1 hash
-          algorithm
-      2.  The issuer's distinguished name is O=GMD - Forschungszentrum
-          Informationstechnik GmbH; C=DE
-
-
-
-Santesson, et al.           Standards Track                    [Page 24]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-      3.  The subject's distinguished name is CN=Petra M.  Barzin, O=GMD
-          - Forschungszentrum Informationstechnik GmbH, C=DE
-      4.  The certificate was issued on May 1, 2000 and will expire on
-          November 1, 2000
-      5.  The certificate contains a 1024 bit RSA key
-      6.  The certificate includes a critical key usage extension
-          exclusively indicating non-repudiation
-      7.  The certificate includes a certificate policy identifier
-          extension indicating the practices and procedures undertaken
-          by the issuing CA (object identifier 1.3.36.8.1.1).  The
-          certificate policy object identifier is defined by TeleTrust,
-          Germany.  It is required to be set in a certificate conformant
-          to the German digital signature law.
-      8.  The certificate includes a subject directory attributes
-          extension containing the following attributes:
-
-          surname:               Barzin
-          given name:            Petra
-          date of birth:         October, 14th 1971
-          place of birth:        Darmstadt
-          country of citizenship:Germany
-          gender:                Female
-
-      9.  The certificate includes a qualified statement private
-          extension indicating that the naming registration authority's
-          name as "municipality@darmstadt.de".
-      10. The certificate includes, in conformance with RFC 2459, an
-          authority key identifier extension.
-
-C.1 ASN.1 Structure
-
-C.1.1 Extensions
-
-   Since extensions are DER-encoded already when placed in the structure
-   to be signed, they are for clarity shown here in the value notation
-   defined in [X.680].
-
-C.1.1.1 The subjectDirectoryAttributes extension
-
-   petrasSubjDirAttrs AttributesSyntax ::= {
-       {
-           type id-pda-countryOfCitizenship,
-           values {
-               PrintableString : "DE"
-           }
-       },
-       {
-           type id-pda-gender,
-
-
-
-Santesson, et al.           Standards Track                    [Page 25]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-           values {
-               PrintableString : "F"
-           }
-       },
-       {
-           type id-pda-dateOfBirth,
-           values {
-               GeneralizedTime : "197110140000Z"
-           }
-       },
-       {
-           type id-pda-placeOfBirth,
-           values {
-               DirectoryString : utf8String : "Darmstadt"
-           }
-       }
-   }
-
-C.1.1.2 The keyUsage extension
-
-   petrasKeyUsage KeyUsage ::= {nonRepudiation}
-
-C.1.1.3 The certificatePolicies extension
-
-   petrasCertificatePolicies CertificatePoliciesSyntax ::= {
-       {
-           policyIdentifier {1 3 36 8 1 1}
-       }
-   }
-
-C.1.1.4 The qcStatements extension
-
-   petrasQCStatement QCStatements ::= {
-       {
-           statementId   id-qcs-pkixQCSyntax-v1,
-           statementInfo SemanticsInformation : {
-               nameRegistrationAuthorities {
-                   rfc822Name : "municipality@darmstadt.de"
-               }
-          }
-       }
-   }
-
-C.1.1.5 The authorityKeyIdentifier extension
-
-   petrasAKI AuthorityKeyIdentifier ::= {
-       keyIdentifier '000102030405060708090A0B0C0D0E0FFEDCBA98'H
-   }
-
-
-
-Santesson, et al.           Standards Track                    [Page 26]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-C.1.2 The certificate
-
-   The signed portion of the certificate is shown here in the value
-   notation defined in [X.680].  Note that extension values are already
-   DER encoded in this structure.  Some values has been truncated for
-   readability purposes.
-
-   {
-     version v3,
-     serialNumber 1234567890,
-     signature
-     {
-       algorithm { 1 2 840 113549 1 1 5 },
-       parameters RSAParams : NULL
-     },
-     issuer rdnSequence :
-       {
-         {
-           {
-             type { 2 5 4 6 },
-             value PrintableString : "DE"
-           }
-         },
-         {
-           {
-             type { 2 5 4 10 },
-             value UTF8String :
-               "GMD - Forschungszentrum Informationstechnik GmbH"
-           }
-         }
-       },
-     validity
-     {
-       notBefore utcTime : "000501100000Z",
-       notAfter utcTime : "001101100000Z"
-     },
-     subject rdnSequence :
-       {
-         {
-           {
-             type { 2 5 4 6 },
-             value PrintableString : "DE"
-           }
-         },
-         {
-           {
-             type { 2 5 4 10 },
-             value UTF8String :
-
-
-
-Santesson, et al.           Standards Track                    [Page 27]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-               "GMD Forschungszentrum Informationstechnik GmbH"
-           }
-         },
-         {
-           {
-             type { 2 5 4 4 },
-             value UTF8String : "Barzin"
-           },
-           {
-             type { 2 5 4 42 },
-             value UTF8String : "Petra"
-           }
-         }
-       },
-     subjectPublicKeyInfo
-     {
-       algorithm
-       {
-         algorithm { 1 2 840 113549 1 1 1 },
-         parameters RSAParams : NULL
-       },
-       subjectPublicKey '00110000 10000001 10000111 00000010 1000 ...'B
-     },
-     extensions
-     {
-       {
-         extnId { 2 5 29 9 },  -- subjectDirectoryAttributes
-         extnValue '305B301006082B06010505070904310413024445300F0 ...'H
-       },
-       {
-         extnId { 2 5 29 15 }, -- keyUsage
-         critical TRUE,
-         extnValue '03020640'H
-       },
-       {
-         extnId { 2 5 29 32 }, -- certificatePolicies
-         extnValue '3009300706052B24080101'H
-       },
-       {
-         extnId { 2 5 29 35 }, -- authorityKeyIdentifier
-         extnValue '30168014000102030405060708090A0B0C0D0E0FFEDCBA98'H
-       },
-       {
-         extnId { 1 3 6 1 5 5 7 1 3 }, -- qcStatements
-         extnValue '302B302906082B06010505070B01301D301B81196D756 ...'H
-       }
-     }
-   }
-
-
-
-Santesson, et al.           Standards Track                    [Page 28]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-C.2 ASN.1 dump
-
-   This section contains an ASN.1 dump of the signed portion of the
-   certificate.  Some values has been truncated for readability
-   purposes.
-
-   TBSCertificate SEQUENCE: tag = [UNIVERSAL 16] constructed;
-     length = 631
-     version : tag = [0] constructed; length = 3
-       Version INTEGER: tag = [UNIVERSAL 2] primitive; length = 1
-         2
-     serialNumber CertificateSerialNumber INTEGER: tag = [UNIVERSAL 2]
-       primitive; length = 4
-       1234567890
-     signature AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16]
-       constructed; length = 13
-       algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-         length = 9
-         { 1 2 840 113549 1 1 5 }
-       parameters OpenType: NULL: tag = [UNIVERSAL 5] primitive;
-         length = 0
-         NULL
-     issuer Name CHOICE
-       rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16]
-         constructed; length = 72
-         RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
-           constructed; length = 11
-           AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
-             constructed; length = 9
-             type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-               length = 3
-               { 2 5 4 6 }
-             value OpenType: PrintableString: tag = [UNIVERSAL 19]
-               primitive; length = 2
-               "DE"
-         RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
-           constructed; length = 57
-           AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
-           constructed; length = 55
-             type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-               length = 3
-               { 2 5 4 10 }
-             value OpenType : UTF8String: tag = [UNIVERSAL 12]
-               primitive; length = 48
-               0x474d44202d20466f72736368756e67737a656e7472756d2049...
-     validity Validity SEQUENCE: tag = [UNIVERSAL 16] constructed;
-       length = 30
-       notBefore Time CHOICE
-
-
-
-Santesson, et al.           Standards Track                    [Page 29]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-         utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13
-           000501100000Z
-       notAfter Time CHOICE
-         utcTime UTCTime: tag = [UNIVERSAL 23] primitive; length = 13
-           001101100000Z
-     subject Name CHOICE
-       rdnSequence RDNSequence SEQUENCE OF: tag = [UNIVERSAL 16]
-         constructed; length = 101
-         RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
-           constructed; length = 11
-           AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
-             constructed; length = 9
-             type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-               length = 3
-               { 2 5 4 6 }
-             value OpenType: PrintableString: tag = [UNIVERSAL 19]
-               primitive; length = 2
-               "DE"
-         RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
-           constructed; length = 55
-           AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
-             constructed; length = 53
-             type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-               length = 3
-               { 2 5 4 10 }
-             value OpenType: UTF8String: tag = [UNIVERSAL 12]
-               primitive; length = 46
-               0x474d4420466f72736368756e67737a656e7472756d20496e66...
-         RelativeDistinguishedName SET OF: tag = [UNIVERSAL 17]
-           constructed; length = 29
-           AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
-             constructed; length = 13
-             type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-               length = 3
-               { 2 5 4 4 }
-             value OpenType: UTF8String: tag = [UNIVERSAL 12]
-               primitive; length = 6
-               0x4261727a696e
-           AttributeTypeAndValue SEQUENCE: tag = [UNIVERSAL 16]
-             constructed; length = 12
-             type OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-               length = 3
-               { 2 5 4 42 }
-             value OpenType: UTF8String: tag = [UNIVERSAL 12]
-               primitive; length = 5
-               0x5065747261
-     subjectPublicKeyInfo SubjectPublicKeyInfo SEQUENCE: tag =
-       [UNIVERSAL 16] constructed; length = 157
-
-
-
-Santesson, et al.           Standards Track                    [Page 30]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-       algorithm AlgorithmIdentifier SEQUENCE: tag = [UNIVERSAL 16]
-         constructed; length = 13
-         algorithm OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-           length = 9
-           { 1 2 840 113549 1 1 1 }
-         parameters OpenType: NULL: tag = [UNIVERSAL 5] primitive;
-           length = 0
-           NULL
-       subjectPublicKey BIT STRING: tag = [UNIVERSAL 3] primitive;
-         length = 139
-         0x0030818702818100b8488400d4b6088be48ead459ca19ec717aaf3d1d...
-     extensions : tag = [3] constructed; length = 233
-       Extensions SEQUENCE OF: tag = [UNIVERSAL 16] constructed;
-         length = 230
-         Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
-           length = 100
-           extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-             length = 3
-             { 2 5 29 9 }
-           extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
-             length = 93
-             0x305b301006082b06010505070904310413024445300f06082b060...
-         Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
-           length = 14
-           extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-             length = 3
-             { 2 5 29 15 }
-           critical BOOLEAN: tag = [UNIVERSAL 1] primitive; length = 1
-             TRUE
-           extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
-             length = 4
-             0x03020640
-         Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
-           length = 18
-           extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-             length = 3
-             { 2 5 29 32 }
-           extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
-             length = 11
-             0x3009300706052b24080101
-         Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
-           length = 31
-           extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-             length = 3
-             { 2 5 29 35 }
-           extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
-             length = 24
-             0x30168014000102030405060708090a0b0c0d0e0ffedcba98
-
-
-
-Santesson, et al.           Standards Track                    [Page 31]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-         Extension SEQUENCE: tag = [UNIVERSAL 16] constructed;
-           length = 57
-           extnId OBJECT IDENTIFIER: tag = [UNIVERSAL 6] primitive;
-             length = 8
-             { 1 3 6 1 5 5 7 1 3 }
-           extnValue OCTET STRING: tag = [UNIVERSAL 4] primitive;
-             length = 45
-             0x302b302906082b06010505070b01301d301b81196d756e6963697...
-
-C.3 DER-encoding
-
-   This section contains the full, DER-encoded certificate, in hex.
-
-   3082030E30820277A0030201020204499602D2300D06092A864886F70D010105
-   05003048310B300906035504061302444531393037060355040A0C30474D4420
-   2D20466F72736368756E67737A656E7472756D20496E666F726D6174696F6E73
-   746563686E696B20476D6248301E170D3030303530313130303030305A170D30
-   30313130313130303030305A3065310B30090603550406130244453137303506
-   0355040A0C2E474D4420466F72736368756E67737A656E7472756D20496E666F
-   726D6174696F6E73746563686E696B20476D6248311D300C060355042A0C0550
-   65747261300D06035504040C064261727A696E30819D300D06092A864886F70D
-   010101050003818B0030818702818100B8488400D4B6088BE48EAD459CA19EC7
-   17AAF3D1D4EE3ECCA496128A13597D16CC8B85EB37EFCE110C63B01E684E5CF6
-   32291EAC60FD153C266EAAC36AD4CEA92319F9BFDD261AD2BFE41EAB4E17FE67
-   8341EE52D9A0A8B4DEC07B7ACC76762514045CEE9994E0CF37BAE05F8DE33B35
-   FF98BCE77742CE4B12273BD122137FE9020105A381E93081E630640603551D09
-   045D305B301006082B06010505070904310413024445300F06082B0601050507
-   09033103130146301D06082B060105050709013111180F313937313130313430
-   30303030305A301706082B06010505070902310B0C094461726D737461647430
-   0E0603551D0F0101FF04040302064030120603551D20040B3009300706052B24
-   080101301F0603551D23041830168014000102030405060708090A0B0C0D0E0F
-   FEDCBA98303906082B06010505070103042D302B302906082B06010505070B01
-   301D301B81196D756E69636970616C697479406461726D73746164742E646530
-   0D06092A864886F70D01010505000381810048FD14D9AFE961E4321D9AA40CC0
-   1C12893550CF76FBECBDE448926B0AE6F904AB89E7B5F808666FB007218AC18D
-   28CE1E2D40FBF8C16B275CBA0547D7885B74059DEC736223368FC1602A510BC1
-   EB31E39F3967BE6B413D48BC743A0AB19C57FD20F3B393E8FEBD8B05CAA5007D
-   AD36F9D789AEF636A0AC0F93BCB3711B5907
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 32]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-C.4 CA's public RSA key
-
-   This section contains the DER-encoded public RSA key of the CA who
-   signed the example certificate.  It is included with the purpose of
-   simplifying verifications of the example certificate.
-
-   30818902818100ad1f35964b3674c807b9f8a645d2c8174e514b69a4b46a7382
-   915abbc44eccede914dae8fcc023abcea9c53380e641795cb0dda664b872fc10
-   9f9bbb852bf42d994f634c681608e388dce240b558513e5b60027bd1a07cef9c
-   9b6db37c7e1f1abd238eed96e4b669056b260f55e83f14e6027127c9deb3ad18
-   afcd3f8a5f5bf50203010001
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 33]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-Authors' Addresses
-
-   Stefan Santesson
-   AddTrust AB
-   P.O. Box 465
-   S-201 24 Malmo
-   Sweden
-
-   EMail: stefan@addtrust.com
-
-
-   Tim Polk
-   NIST
-   Building 820, Room 426
-   Gaithersburg, MD 20899, USA
-
-   EMail: wpolk@nist.gov
-
-
-   Petra Barzin
-   SECUDE - Sicherheitstechnologie Informationssysteme GmbH
-   Landwehrstrasse 50a
-   D-64293 Darmstadt
-   Germany
-
-   EMail: barzin@secude.com
-
-
-   Magnus Nystrom
-   RSA Security AB
-   Box 10704
-   S-121 29 Stockholm
-   Sweden
-
-   EMail: magnus@rsasecurity.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 34]
-
-RFC 3039             Qualified Certificates Profile         January 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 35]
-
diff --git a/doc/protocol/rfc3268.txt b/doc/protocol/rfc3268.txt
deleted file mode 100644
index 80e79dbc80..0000000000
--- a/doc/protocol/rfc3268.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           P. Chown
-Request for Comments: 3268                            Skygate Technology
-Category: Standards Track                                      June 2002
-
-
-  Advanced Encryption Standard (AES) Ciphersuites for Transport Layer
-                             Security (TLS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document proposes several new ciphersuites.  At present, the
-   symmetric ciphers supported by Transport Layer Security (TLS) are
-   RC2, RC4, International Data Encryption Algorithm (IDEA), Data
-   Encryption Standard (DES), and triple DES.  The protocol would be
-   enhanced by the addition of Advanced Encryption Standard (AES)
-   ciphersuites.
-
-Overview
-
-   At present, the symmetric ciphers supported by TLS are RC2, RC4,
-   IDEA, DES, and triple DES.  The protocol would be enhanced by the
-   addition of AES [AES] ciphersuites, for the following reasons:
-
-   1. RC2, RC4, and IDEA are all subject to intellectual property
-      claims.  RSA Security Inc. has trademark rights in the names RC2
-      and RC4, and claims that the RC4 algorithm itself is a trade
-      secret.  Ascom Systec Ltd. owns a patent on the IDEA algorithm.
-
-   2. Triple DES is much less efficient than more modern ciphers.
-
-   3. Now that the AES process is completed there will be commercial
-      pressure to use the selected cipher.  The AES is efficient and has
-      withstood extensive cryptanalytic efforts.  The AES is therefore a
-      desirable choice.
-
-
-
-
-
-Chown                       Standards Track                     [Page 1]
-
-RFC 3268                AES Ciphersuites for TLS               June 2002
-
-
-   4. Currently the DHE ciphersuites only allow triple DES (along with
-      some "export" variants which do not use a satisfactory key
-      length).  At the same time the DHE ciphersuites are the only ones
-      to offer forward secrecy.
-
-   This document proposes several new ciphersuites, with the aim of
-   overcoming these problems.
-
-Cipher Usage
-
-   The new ciphersuites proposed here are very similar to the following,
-   defined in [TLS]:
-
-   TLS_RSA_WITH_3DES_EDE_CBC_SHA
-   TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
-   TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
-   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
-   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
-   TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
-
-   All the ciphersuites described here use the AES in cipher block
-   chaining (CBC) mode.  Furthermore, they use SHA-1 [SHA-1] in an HMAC
-   construction as described in section 5 of [TLS].  (Although the TLS
-   ciphersuite names include the text "SHA", this actually refers to the
-   modified SHA-1 version of the algorithm.)
-
-   The ciphersuites differ in the type of certificate and key exchange
-   method.  The ciphersuites defined here use the following options for
-   this part of the protocol:
-
-   CipherSuite                        Certificate type (if applicable)
-                                      and key exchange algorithm
-
-   TLS_RSA_WITH_AES_128_CBC_SHA       RSA
-   TLS_DH_DSS_WITH_AES_128_CBC_SHA    DH_DSS
-   TLS_DH_RSA_WITH_AES_128_CBC_SHA    DH_RSA
-   TLS_DHE_DSS_WITH_AES_128_CBC_SHA   DHE_DSS
-   TLS_DHE_RSA_WITH_AES_128_CBC_SHA   DHE_RSA
-   TLS_DH_anon_WITH_AES_128_CBC_SHA   DH_anon
-
-   TLS_RSA_WITH_AES_256_CBC_SHA       RSA
-   TLS_DH_DSS_WITH_AES_256_CBC_SHA    DH_DSS
-   TLS_DH_RSA_WITH_AES_256_CBC_SHA    DH_RSA
-   TLS_DHE_DSS_WITH_AES_256_CBC_SHA   DHE_DSS
-   TLS_DHE_RSA_WITH_AES_256_CBC_SHA   DHE_RSA
-   TLS_DH_anon_WITH_AES_256_CBC_SHA   DH_anon
-
-
-
-
-
-Chown                       Standards Track                     [Page 2]
-
-RFC 3268                AES Ciphersuites for TLS               June 2002
-
-
-   For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA
-   and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS].
-
-   The AES supports key lengths of 128, 192 and 256 bits.  However, this
-   document only defines ciphersuites for 128- and 256-bit keys.  This
-   is to avoid unnecessary proliferation of ciphersuites.  Rijndael
-   actually allows for 192- and 256-bit block sizes as well as the 128-
-   bit blocks mandated by the AES process.  The ciphersuites defined
-   here all use 128-bit blocks.
-
-   The new ciphersuites will have the following definitions:
-
-   CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
-   CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
-   CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
-   CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
-   CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
-   CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
-
-   CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
-   CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
-   CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
-   CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
-   CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
-   CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
-
-Security Considerations
-
-   It is not believed that the new ciphersuites are ever less secure
-   than the corresponding older ones.  The AES is believed to be secure,
-   and it has withstood extensive cryptanalytic attack.
-
-   The ephemeral Diffie-Hellman ciphersuites provide forward secrecy
-   without any known reduction in security in other areas.  To obtain
-   the maximum benefit from these ciphersuites:
-
-   1. The ephemeral keys should only be used once.  With the TLS
-      protocol as currently defined there is no significant efficiency
-      gain from reusing ephemeral keys.
-
-   2. Ephemeral keys should be destroyed securely when they are no
-      longer required.
-
-   3. The random number generator used to create ephemeral keys must not
-      reveal past output even when its internal state is compromised.
-
-
-
-
-
-
-Chown                       Standards Track                     [Page 3]
-
-RFC 3268                AES Ciphersuites for TLS               June 2002
-
-
-   [TLS] describes the anonymous Diffie-Hellman (ADH) ciphersuites as
-   deprecated.  The ADH ciphersuites defined here are not deprecated.
-   However, when they are used, particular care must be taken:
-
-   1. ADH provides confidentiality but not authentication.  This means
-      that (if authentication is required) the communicating parties
-      must authenticate to each other by some means other than TLS.
-
-   2. ADH is vulnerable to man-in-the-middle attacks, as a consequence
-      of the lack of authentication.  The parties must have a way of
-      determining whether they are participating in the same TLS
-      connection.  If they are not, they can deduce that they are under
-      attack, and presumably abort the connection.
-
-      For example, if the parties share a secret, it is possible to
-      compute a MAC of the TLS Finished message.  An attacker would have
-      to negotiate two different TLS connections; one with each
-      communicating party.  The Finished messages would be different in
-      each case, because they depend on the parties' public keys (among
-      other things).  For this reason, the MACs computed by each party
-      would be different.
-
-      It is important to note that authentication techniques which do
-      not use the Finished message do not usually provide protection
-      from this attack.  For example, the client could authenticate to
-      the server with a password, but it would still be vulnerable to
-      man-in-the-middle attacks.
-
-      Recent research has identified a chosen plaintext attack which
-      applies to all ciphersuites defined in [TLS] which use CBC mode.
-      This weakness does not affect the common use of TLS on the World
-      Wide Web, but may affect the use of TLS in other applications.
-      When TLS is used in an application where this attack is possible,
-      attackers can determine the truth or otherwise of a hypothesis
-      that particular plaintext data was sent earlier in the session.
-      No key material is compromised.
-
-      It is likely that the CBC construction will be changed in a future
-      revision of the TLS protocol.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use other technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-
-
-
-Chown                       Standards Track                     [Page 4]
-
-RFC 3268                AES Ciphersuites for TLS               June 2002
-
-
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-   During the development of the AES, NIST published the following
-   statement on intellectual property:
-
-      SPECIAL NOTE - Intellectual Property
-
-      NIST reminds all interested parties that the adoption of AES is
-      being conducted as an open standards-setting activity.
-      Specifically, NIST has requested that all interested parties
-      identify to NIST any patents or inventions that may be required
-      for the use of AES.  NIST hereby gives public notice that it may
-      seek redress under the antitrust laws of the United States against
-      any party in the future who might seek to exercise patent rights
-      against any user of AES that have not been disclosed to NIST in
-      response to this request for information.
-
-Acknowledgements
-
-   I would like to thank the ietf-tls mailing list contributors who have
-   made helpful suggestions for this document.
-
-References
-
-   [TLS]    Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-            2246, January 1999.
-
-   [AES]    National Institute of Standards and Technology,
-            "Specification for the Advanced Encryption Standard (AES)"
-            FIPS 197.  November 26, 2001.
-
-   [SHA-1]  FIPS PUB 180-1, "Secure Hash Standard," National Institute
-            of Standards and Technology, U.S. Department of Commerce,
-            April 17, 1995.
-
-
-
-
-
-Chown                       Standards Track                     [Page 5]
-
-RFC 3268                AES Ciphersuites for TLS               June 2002
-
-
-Author's Address
-
-   Pete Chown
-   Skygate Technology Ltd
-   8 Lombard Road
-   London
-   SW19 3TZ
-   United Kingdom
-
-   Phone: +44 20 8542 7856
-   EMail: pc@skygate.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Chown                       Standards Track                     [Page 6]
-
-RFC 3268                AES Ciphersuites for TLS               June 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Chown                       Standards Track                     [Page 7]
-
diff --git a/doc/protocol/rfc3279.txt b/doc/protocol/rfc3279.txt
deleted file mode 100644
index 04e7b075d4..0000000000
--- a/doc/protocol/rfc3279.txt
+++ /dev/null
@@ -1,1515 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            W. Polk
-Request for Comments: 3279                                          NIST
-Obsoletes: 2528                                               R. Housley
-Category: Standards Track                               RSA Laboratories
-                                                              L. Bassham
-                                                                    NIST
-                                                              April 2002
-
-                   Algorithms and Identifiers for the
-                Internet X.509 Public Key Infrastructure
-       Certificate and Certificate Revocation List (CRL) Profile
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document specifies algorithm identifiers and ASN.1 encoding
-   formats for digital signatures and subject public keys used in the
-   Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
-   are used to sign certificates and certificate revocation list (CRLs).
-   Certificates include the public key of the named subject.
-
-Table of Contents
-
-   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
-   2  Algorithm Support . . . . . . . . . . . . . . . . . . . .   3
-   2.1  One-Way Hash Functions  . . . . . . . . . . . . . . . .   3
-   2.1.1  MD2 One-Way Hash Functions  . . . . . . . . . . . . .   3
-   2.1.2  MD5 One-Way Hash Functions  . . . . . . . . . . . . .   4
-   2.1.3  SHA-1 One-Way Hash Functions  . . . . . . . . . . . .   4
-   2.2  Signature Algorithms  . . . . . . . . . . . . . . . . .   4
-   2.2.1  RSA Signature Algorithm . . . . . . . . . . . . . . .   5
-   2.2.2  DSA Signature Algorithm . . . . . . . . . . . . . . .   6
-   2.2.3  Elliptic Curve Digital Signature Algorithm  . . . . .   7
-   2.3  Subject Public Key Algorithms . . . . . . . . . . . . .   7
-   2.3.1  RSA Keys  . . . . . . . . . . . . . . . . . . . . . .   8
-   2.3.2  DSA Signature Keys  . . . . . . . . . . . . . . . . .   9
-   2.3.3  Diffie-Hellman Key Exchange Keys  . . . . . . . . . .  10
-
-
-
-Polk, et al.                Standards Track                     [Page 1]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   2.3.4  KEA Public Keys . . . . . . . . . . . . . . . . . . .  11
-   2.3.5  ECDSA and ECDH Public Keys  . . . . . . . . . . . . .  13
-   3  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . .  18
-   4  References  . . . . . . . . . . . . . . . . . . . . . . .  24
-   5  Security Considerations . . . . . . . . . . . . . . . . .  25
-   6  Intellectual Property Rights  . . . . . . . . . . . . . .  26
-   7  Author Addresses  . . . . . . . . . . . . . . . . . . . .  26
-   8  Full Copyright Statement  . . . . . . . . . . . . . . . .  27
-
-1  Introduction
-
-   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].
-
-   This document specifies algorithm identifiers and ASN.1 [X.660]
-   encoding formats for digital signatures and subject public keys used
-   in the Internet X.509 Public Key Infrastructure (PKI).  This
-   specification supplements [RFC 3280], "Internet X.509 Public Key
-   Infrastructure:  Certificate and Certificate Revocation List (CRL)
-   Profile."  Implementations of this specification MUST also conform to
-   RFC 3280.
-
-   This specification defines the contents of the signatureAlgorithm,
-   signatureValue, signature, and subjectPublicKeyInfo fields within
-   Internet X.509 certificates and CRLs.
-
-   This document identifies one-way hash functions for use in the
-   generation of digital signatures.  These algorithms are used in
-   conjunction with digital signature algorithms.
-
-   This specification describes the encoding of digital signatures
-   generated with the following cryptographic algorithms:
-
-      * Rivest-Shamir-Adelman (RSA);
-      * Digital Signature Algorithm (DSA); and
-      * Elliptic Curve Digital Signature Algorithm (ECDSA).
-
-   This document specifies the contents of the subjectPublicKeyInfo
-   field in Internet X.509 certificates.  For each algorithm, the
-   appropriate alternatives for the the keyUsage extension are provided.
-   This specification describes encoding formats for public keys used
-   with the following cryptographic algorithms:
-
-      * Rivest-Shamir-Adelman (RSA);
-      * Digital Signature Algorithm (DSA);
-      * Diffie-Hellman (DH);
-      * Key Encryption Algorithm (KEA);
-
-
-
-Polk, et al.                Standards Track                     [Page 2]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-      * Elliptic Curve Digital Signature Algorithm (ECDSA); and
-      * Elliptic Curve Diffie-Hellman (ECDH).
-
-2  Algorithm Support
-
-   This section describes cryptographic algorithms which may be used
-   with the Internet X.509 certificate and CRL profile [RFC 3280].  This
-   section describes one-way hash functions and digital signature
-   algorithms which may be used to sign certificates and CRLs, and
-   identifies object identifiers (OIDs) for public keys contained in a
-   certificate.
-
-   Conforming CAs and applications MUST, at a minimum, support digital
-   signatures and public keys for one of the specified algorithms.  When
-   using any of the algorithms identified in this specification,
-   conforming CAs and applications MUST support them as described.
-
-2.1  One-way Hash Functions
-
-   This section identifies one-way hash functions for use in the
-   Internet X.509 PKI.  One-way hash functions are also called message
-   digest algorithms.  SHA-1 is the preferred one-way hash function for
-   the Internet X.509 PKI.  However, PEM uses MD2 for certificates [RFC
-   1422] [RFC 1423] and MD5 is used in other legacy applications.  For
-   these reasons, MD2 and MD5 are included in this profile.  The data
-   that is hashed for certificate and CRL signing is fully described in
-   [RFC 3280].
-
-2.1.1  MD2 One-way Hash Function
-
-   MD2 was developed by Ron Rivest for RSA Security.  RSA Security has
-   recently placed the MD2 algorithm in the public domain.  Previously,
-   RSA Data Security had granted license for use of MD2 for non-
-   commercial Internet Privacy-Enhanced Mail (PEM).  MD2 may continue to
-   be used with PEM certificates, but SHA-1 is preferred.  MD2 produces
-   a 128-bit "hash" of the input.  MD2 is fully described in [RFC 1319].
-
-   At the Selected Areas in Cryptography '95 conference in May 1995,
-   Rogier and Chauvaud presented an attack on MD2 that can nearly find
-   collisions [RC95].  Collisions occur when one can find two different
-   messages that generate the same message digest.  A checksum operation
-   in MD2 is the only remaining obstacle to the success of the attack.
-   For this reason, the use of MD2 for new applications is discouraged.
-   It is still reasonable to use MD2 to verify existing signatures, as
-   the ability to find collisions in MD2 does not enable an attacker to
-   find new messages having a previously computed hash value.
-
-
-
-
-
-Polk, et al.                Standards Track                     [Page 3]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-2.1.2  MD5 One-way Hash Function
-
-   MD5 was developed by Ron Rivest for RSA Security.  RSA Security has
-   placed the MD5 algorithm in the public domain.  MD5 produces a 128-
-   bit "hash" of the input.  MD5 is fully described in [RFC 1321].
-
-   Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
-   but there are no other known cryptanalytic results.  The use of MD5
-   for new applications is discouraged.  It is still reasonable to use
-   MD5 to verify existing signatures.
-
-2.1.3  SHA-1 One-way Hash Function
-
-   SHA-1 was developed by the U.S. Government.  SHA-1 produces a 160-bit
-   "hash" of the input.  SHA-1 is fully described in [FIPS 180-1].  RFC
-   3174 [RFC 3174] also describes SHA-1, and it provides an
-   implementation of the algorithm.
-
-2.2  Signature Algorithms
-
-   Certificates and CRLs conforming to [RFC 3280] may be signed with any
-   public key signature algorithm.  The certificate or CRL indicates the
-   algorithm through an algorithm identifier which appears in the
-   signatureAlgorithm field within the Certificate or CertificateList.
-   This algorithm identifier is an OID and has optionally associated
-   parameters.  This section identifies algorithm identifiers and
-   parameters that MUST be used in the signatureAlgorithm field in a
-   Certificate or CertificateList.
-
-   Signature algorithms are always used in conjunction with a one-way
-   hash function.
-
-   This section identifies OIDS for RSA, DSA, and ECDSA.  The contents
-   of the parameters component for each algorithm vary; details are
-   provided for each algorithm.
-
-   The data to be signed (e.g., the one-way hash function output value)
-   is formatted for the signature algorithm to be used.  Then, a private
-   key operation (e.g., RSA encryption) is performed to generate the
-   signature value.  This signature value is then ASN.1 encoded as a BIT
-   STRING and included in the Certificate or CertificateList in the
-   signature field.
-
-
-
-
-
-
-
-
-
-Polk, et al.                Standards Track                     [Page 4]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-2.2.1  RSA Signature Algorithm
-
-   The RSA algorithm is named for its inventors: Rivest, Shamir, and
-   Adleman.  This profile includes three signature algorithms based on
-   the RSA asymmetric encryption algorithm.  The signature algorithms
-   combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
-   functions.
-
-   The signature algorithm with SHA-1 and the RSA encryption algorithm
-   is implemented using the padding and encoding conventions described
-   in PKCS #1 [RFC 2313].  The message digest is computed using the
-   SHA-1 hash algorithm.
-
-   The RSA signature algorithm, as specified in PKCS #1 [RFC 2313]
-   includes a data encoding step.  In this step, the message digest and
-   the OID for the one-way hash function used to compute the digest are
-   combined.  When performing the data encoding step, the md2, md5, and
-   id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way
-   hash functions, respectively:
-
-      md2  OBJECT IDENTIFIER ::= {
-           iso(1) member-body(2) US(840) rsadsi(113549)
-           digestAlgorithm(2) 2 }
-
-      md5  OBJECT IDENTIFIER ::= {
-           iso(1) member-body(2) US(840) rsadsi(113549)
-           digestAlgorithm(2) 5 }
-
-      id-sha1  OBJECT IDENTIFIER ::= {
-           iso(1) identified-organization(3) oiw(14) secsig(3)
-           algorithms(2) 26 }
-
-   The signature algorithm with MD2 and the RSA encryption algorithm is
-   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
-   ASN.1 OID used to identify this signature algorithm is:
-
-      md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
-          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-          pkcs-1(1) 2  }
-
-   The signature algorithm with MD5 and the RSA encryption algorithm is
-   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
-   ASN.1 OID used to identify this signature algorithm is:
-
-      md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
-          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-          pkcs-1(1) 4  }
-
-
-
-
-Polk, et al.                Standards Track                     [Page 5]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   The ASN.1 object identifier used to identify this signature algorithm
-   is:
-
-      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
-          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
-          pkcs-1(1) 5  }
-
-   When any of these three OIDs appears within the ASN.1 type
-   AlgorithmIdentifier, the parameters component of that type SHALL be
-   the ASN.1 type NULL.
-
-   The RSA signature generation process and the encoding of the result
-   is described in detail in PKCS #1 [RFC 2313].
-
-2.2.2  DSA Signature Algorithm
-
-   The Digital Signature Algorithm (DSA) is defined in the Digital
-   Signature Standard (DSS).  DSA was developed by the U.S. Government,
-   and DSA is used in conjunction with the SHA-1 one-way hash function.
-   DSA is fully described in [FIPS 186].  The ASN.1 OID used to identify
-   this signature algorithm is:
-
-      id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
-           iso(1) member-body(2) us(840) x9-57 (10040)
-           x9cm(4) 3 }
-
-   When the id-dsa-with-sha1 algorithm identifier appears as the
-   algorithm field in an AlgorithmIdentifier, the encoding SHALL omit
-   the parameters field.  That is, the AlgorithmIdentifier SHALL be a
-   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.
-
-   The DSA parameters in the subjectPublicKeyInfo field of the
-   certificate of the issuer SHALL apply to the verification of the
-   signature.
-
-   When signing, the DSA algorithm generates two values.  These values
-   are commonly referred to as r and s.  To easily transfer these two
-   values as one signature, they SHALL be ASN.1 encoded using the
-   following ASN.1 structure:
-
-      Dss-Sig-Value  ::=  SEQUENCE  {
-              r       INTEGER,
-              s       INTEGER  }
-
-
-
-
-
-
-
-
-Polk, et al.                Standards Track                     [Page 6]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-2.2.3 ECDSA Signature Algorithm
-
-   The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
-   [X9.62].  The ASN.1 object identifiers used to identify ECDSA are
-   defined in the following arc:
-
-      ansi-X9-62  OBJECT IDENTIFIER ::= {
-           iso(1) member-body(2) us(840) 10045 }
-
-      id-ecSigType OBJECT IDENTIFIER  ::=  {
-           ansi-X9-62 signatures(4) }
-
-   ECDSA is used in conjunction with the SHA-1 one-way hash function.
-   The ASN.1 object identifier used to identify ECDSA with SHA-1 is:
-
-      ecdsa-with-SHA1  OBJECT IDENTIFIER ::= {
-           id-ecSigType 1 }
-
-   When the ecdsa-with-SHA1 algorithm identifier appears as the
-   algorithm field in an AlgorithmIdentifier, the encoding MUST omit the
-   parameters field.  That is, the AlgorithmIdentifier SHALL be a
-   SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.
-
-   The elliptic curve parameters in the subjectPublicKeyInfo field of
-   the certificate of the issuer SHALL apply to the verification of the
-   signature.
-
-   When signing, the ECDSA algorithm generates two values.  These values
-   are commonly referred to as r and s.  To easily transfer these two
-   values as one signature, they MUST be ASN.1 encoded using the
-   following ASN.1 structure:
-
-      Ecdsa-Sig-Value  ::=  SEQUENCE  {
-           r     INTEGER,
-           s     INTEGER  }
-
-2.3  Subject Public Key Algorithms
-
-   Certificates conforming to [RFC 3280] may convey a public key for any
-   public key algorithm.  The certificate indicates the algorithm
-   through an algorithm identifier.  This algorithm identifier is an OID
-   and optionally associated parameters.
-
-   This section identifies preferred OIDs and parameters for the RSA,
-   DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms.  Conforming CAs
-   MUST use the identified OIDs when issuing certificates containing
-
-
-
-
-
-Polk, et al.                Standards Track                     [Page 7]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   public keys for these algorithms.  Conforming applications supporting
-   any of these algorithms MUST, at a minimum, recognize the OID
-   identified in this section.
-
-2.3.1  RSA Keys
-
-   The OID rsaEncryption identifies RSA public keys.
-
-      pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
-                     rsadsi(113549) pkcs(1) 1 }
-
-      rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}
-
-   The rsaEncryption OID is intended to be used in the algorithm field
-   of a value of type AlgorithmIdentifier.  The parameters field MUST
-   have ASN.1 type NULL for this algorithm identifier.
-
-   The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:
-
-      RSAPublicKey ::= SEQUENCE {
-         modulus            INTEGER,    -- n
-         publicExponent     INTEGER  }  -- e
-
-   where modulus is the modulus n, and publicExponent is the public
-   exponent e.  The DER encoded RSAPublicKey is the value of the BIT
-   STRING subjectPublicKey.
-
-   This OID is used in public key certificates for both RSA signature
-   keys and RSA encryption keys.  The intended application for the key
-   MAY be indicated in the key usage field (see [RFC 3280]).  The use of
-   a single key for both signature and encryption purposes is not
-   recommended, but is not forbidden.
-
-   If the keyUsage extension is present in an end entity certificate
-   which conveys an RSA public key, any combination of the following
-   values MAY be present:
-
-      digitalSignature;
-      nonRepudiation;
-      keyEncipherment; and
-      dataEncipherment.
-
-   If the keyUsage extension is present in a CA or CRL issuer
-   certificate which conveys an RSA public key, any combination of the
-   following values MAY be present:
-
-      digitalSignature;
-      nonRepudiation;
-
-
-
-Polk, et al.                Standards Track                     [Page 8]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-      keyEncipherment;
-      dataEncipherment;
-      keyCertSign; and
-      cRLSign.
-
-   However, this specification RECOMMENDS that if keyCertSign or cRLSign
-   is present, both keyEncipherment and dataEncipherment SHOULD NOT be
-   present.
-
-2.3.2  DSA Signature Keys
-
-   The Digital Signature Algorithm (DSA) is defined in the Digital
-   Signature Standard (DSS) [FIPS 186].  The DSA OID supported by this
-   profile is:
-
-      id-dsa OBJECT IDENTIFIER ::= {
-           iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
-
-   The id-dsa algorithm syntax includes optional domain parameters.
-   These parameters are commonly referred to as p, q, and g.  When
-   omitted, the parameters component MUST be omitted entirely.  That is,
-   the AlgorithmIdentifier MUST be a SEQUENCE of one component: the
-   OBJECT IDENTIFIER id-dsa.
-
-   If the DSA domain parameters are present in the subjectPublicKeyInfo
-   AlgorithmIdentifier, the parameters are included using the following
-   ASN.1 structure:
-
-      Dss-Parms  ::=  SEQUENCE  {
-          p             INTEGER,
-          q             INTEGER,
-          g             INTEGER  }
-
-   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
-   within a certificate where the parameters may be used.  If the DSA
-   algorithm parameters are omitted from the subjectPublicKeyInfo
-   AlgorithmIdentifier and the CA signed the subject certificate using
-   DSA, then the certificate issuer's DSA parameters apply to the
-   subject's DSA key.  If the DSA domain parameters are omitted from the
-   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
-   subject certificate using a signature algorithm other than DSA, then
-   the subject's DSA domain parameters are distributed by other means.
-   If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
-   parameters component, the CA signed the subject with a signature
-   algorithm other than DSA, and the subject's DSA parameters are not
-   available through other means, then clients MUST reject the
-   certificate.
-
-
-
-
-Polk, et al.                Standards Track                     [Page 9]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this
-   encoding shall be used as the contents (i.e., the value) of the
-   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
-   data element.
-
-      DSAPublicKey ::= INTEGER -- public key, Y
-
-   If the keyUsage extension is present in an end entity certificate
-   which conveys a DSA public key, any combination of the following
-   values MAY be present:
-
-      digitalSignature;
-      nonRepudiation;
-
-   If the keyUsage extension is present in a CA or CRL issuer
-   certificate which conveys a DSA public key, any combination of the
-   following values MAY be present:
-
-      digitalSignature;
-      nonRepudiation;
-      keyCertSign; and
-      cRLSign.
-
-2.3.3  Diffie-Hellman Key Exchange Keys
-
-   The Diffie-Hellman OID supported by this profile is defined in
-   [X9.42].
-
-      dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-                us(840) ansi-x942(10046) number-type(2) 1 }
-
-   The dhpublicnumber OID is intended to be used in the algorithm field
-   of a value of type AlgorithmIdentifier.  The parameters field of that
-   type, which has the algorithm-specific syntax ANY DEFINED BY
-   algorithm, have the ASN.1 type DomainParameters for this algorithm.
-
-      DomainParameters ::= SEQUENCE {
-            p       INTEGER, -- odd prime, p=jq +1
-            g       INTEGER, -- generator, g
-            q       INTEGER, -- factor of p-1
-            j       INTEGER OPTIONAL, -- subgroup factor
-            validationParms  ValidationParms OPTIONAL }
-
-      ValidationParms ::= SEQUENCE {
-            seed             BIT STRING,
-            pgenCounter      INTEGER }
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 10]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   The fields of type DomainParameters have the following meanings:
-
-      p identifies the prime p defining the Galois field;
-
-      g specifies the generator of the multiplicative subgroup of order
-      g;
-
-      q specifies the prime factor of p-1;
-
-      j optionally specifies the value that satisfies the equation
-      p=jq+1 to support the optional verification of group parameters;
-
-      seed optionally specifies the bit string parameter used as the
-      seed for the domain parameter generation process; and
-
-      pgenCounter optionally specifies the integer value output as part
-      of the of the domain parameter prime generation process.
-
-   If either of the domain parameter generation components (pgenCounter
-   or seed) is provided, the other MUST be present as well.
-
-   The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER;
-   this encoding shall be used as the contents (i.e., the value) of the
-   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
-   data element.
-
-      DHPublicKey ::= INTEGER -- public key, y = g^x mod p
-
-   If the keyUsage extension is present in a certificate which conveys a
-   DH public key, the following values may be present:
-
-      keyAgreement;
-      encipherOnly; and
-      decipherOnly.
-
-   If present, the keyUsage extension MUST assert keyAgreement and MAY
-   assert either encipherOnly and decipherOnly.  The keyUsage extension
-   MUST NOT assert both encipherOnly and decipherOnly.
-
-2.3.4 KEA Public Keys
-
-   This section identifies the preferred OID and parameters for the
-   inclusion of a KEA public key in a certificate.  The Key Exchange
-   Algorithm (KEA) is a key agreement algorithm.  Two parties may
-   generate a "pairwise key" if and only if they share the same KEA
-   parameters.  The KEA parameters are not included in a certificate;
-   instead a domain identifier is supplied in the parameters field.
-
-
-
-
-Polk, et al.                Standards Track                    [Page 11]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   When the SubjectPublicKeyInfo field contains a KEA key, the algorithm
-   identifier and parameters SHALL be as defined in [SDN.701r]:
-
-      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
-             { 2 16 840 1 101 2 1 1 22 }
-
-      KEA-Parms-Id     ::= OCTET STRING
-
-   CAs MUST populate the parameters field of the AlgorithmIdentifier
-   within the SubjectPublicKeyInfo field of each certificate containing
-   a KEA public key with an 80-bit parameter identifier (OCTET STRING),
-   also known as the domain identifier.  The domain identifier is
-   computed in three steps:
-
-      (1) the KEA domain parameters (p, q, and g) are DER encoded using
-      the Dss-Parms structure;
-
-      (2) a 160-bit SHA-1 hash is generated from the parameters; and
-
-      (3) the 160-bit hash is reduced to 80-bits by performing an
-      "exclusive or" of the 80 high order bits with the 80 low order
-      bits.
-
-   The resulting value is encoded such that the most significant byte of
-   the 80-bit value is the first octet in the octet string.  The Dss-
-   Parms is provided above in Section 2.3.2.
-
-   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
-   such that the most significant bit (MSB) of y becomes the MSB of the
-   BIT STRING value field and the least significant bit (LSB) of y
-   becomes the LSB of the BIT STRING value field.  This results in the
-   following encoding:
-
-      BIT STRING tag;
-      BIT STRING length;
-      0 (indicating that there are zero unused bits in the final octet
-      of y); and
-      BIT STRING value field including y.
-
-   The key usage extension may optionally appear in a KEA certificate.
-   If a KEA certificate includes the keyUsage extension, only the
-   following values may be asserted:
-
-      keyAgreement;
-      encipherOnly; and
-      decipherOnly.
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 12]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   If present, the keyUsage extension MUST assert keyAgreement and MAY
-   assert either encipherOnly and decipherOnly.  The keyUsage extension
-   MUST NOT assert both encipherOnly and decipherOnly.
-
-2.3.5 ECDSA and ECDH Keys
-
-   This section identifies the preferred OID and parameter encoding for
-   the inclusion of an ECDSA or ECDH public key in a certificate.  The
-   Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
-   [X9.62].  ECDSA is the elliptic curve mathematical analog of the
-   Digital Signature Algorithm [FIPS 186].  The Elliptic Curve Diffie
-   Hellman (ECDH) algorithm is a key agreement algorithm defined in
-   [X9.63].
-
-   ECDH is the elliptic curve mathematical analog of the Diffie-Hellman
-   key agreement algorithm as specified in [X9.42].  The ECDSA and ECDH
-   specifications use the same OIDs and parameter encodings.  The ASN.1
-   object identifiers used to identify these public keys are defined in
-   the following arc:
-
-   ansi-X9-62 OBJECT IDENTIFIER ::=
-                             { iso(1) member-body(2) us(840) 10045 }
-
-   When certificates contain an ECDSA or ECDH public key, the
-   id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey
-   algorithm identifier is defined as follows:
-
-     id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }
-
-     id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
-
-   This OID is used in public key certificates for both ECDSA signature
-   keys and ECDH encryption keys.  The intended application for the key
-   may be indicated in the key usage field (see [RFC 3280]).  The use of
-   a single key for both signature and encryption purposes is not
-   recommended, but is not forbidden.
-
-   ECDSA and ECDH require use of certain parameters with the public key.
-   The parameters may be inherited from the issuer, implicitly included
-   through reference to a "named curve," or explicitly included in the
-   certificate.
-
-      EcpkParameters ::= CHOICE {
-        ecParameters  ECParameters,
-        namedCurve    OBJECT IDENTIFIER,
-        implicitlyCA  NULL }
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 13]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   When the parameters are inherited, the parameters field SHALL contain
-   implictlyCA, which is the ASN.1 value NULL.  When parameters are
-   specified by reference, the parameters field SHALL contain the
-   named-Curve choice, which is an object identifier.  When the
-   parameters are explicitly included, they SHALL be encoded in the
-   ASN.1 structure ECParameters:
-
-      ECParameters ::= SEQUENCE {
-         version   ECPVer,          -- version is always 1
-         fieldID   FieldID,         -- identifies the finite field over
-                                    -- which the curve is defined
-         curve     Curve,           -- coefficients a and b of the
-                                    -- elliptic curve
-         base      ECPoint,         -- specifies the base point P
-                                    -- on the elliptic curve
-         order     INTEGER,         -- the order n of the base point
-         cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
-         }
-
-      ECPVer ::= INTEGER {ecpVer1(1)}
-
-      Curve ::= SEQUENCE {
-         a         FieldElement,
-         b         FieldElement,
-         seed      BIT STRING OPTIONAL }
-
-      FieldElement ::= OCTET STRING
-
-      ECPoint ::= OCTET STRING
-
-   The value of FieldElement SHALL be the octet string representation of
-   a field element following the conversion routine in [X9.62], Section
-   4.3.3.  The value of ECPoint SHALL be the octet string representation
-   of an elliptic curve point following the conversion routine in
-   [X9.62], Section 4.3.6.  Note that this octet string may represent an
-   elliptic curve point in compressed or uncompressed form.
-
-   Implementations that support elliptic curve according to this
-   specification MUST support the uncompressed form and MAY support the
-   compressed form.
-
-   The components of type ECParameters have the following meanings:
-
-      version specifies the version number of the elliptic curve
-      parameters.  It MUST have the value 1 (ecpVer1).
-
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 14]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-      fieldID identifies the finite field over which the elliptic curve
-      is defined.  Finite fields are represented by values of the
-      parameterized type FieldID, constrained to the values of the
-      objects defined in the information object set FieldTypes.
-      Additional detail regarding fieldID is provided below.
-
-      curve specifies the coefficients a and b of the elliptic curve E.
-      Each coefficient is represented as a value of type FieldElement,
-      an OCTET STRING. seed is an optional parameter used to derive the
-      coefficients of a randomly generated elliptic curve.
-
-      base specifies the base point P on the elliptic curve.  The base
-      point is represented as a value of type ECPoint, an OCTET STRING.
-
-      order specifies the order n of the base point.
-
-      cofactor is the integer h = #E(Fq)/n.  This parameter is specified
-      as OPTIONAL.  However, the cofactor MUST be included in ECDH
-      public key parameters.  The cofactor is not required to support
-      ECDSA, except in parameter validation.  The cofactor MAY be
-      included to support parameter validation for ECDSA keys.
-      Parameter validation is not required by this specification.
-
-   The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place
-   within a certificate where the parameters may be used.  If the
-   elliptic curve parameters are specified as implicitlyCA in the
-   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
-   subject certificate using ECDSA, then the certificate issuer's ECDSA
-   parameters apply to the subject's ECDSA key.  If the elliptic curve
-   parameters are specified as implicitlyCA in the SubjectPublicKeyInfo
-   AlgorithmIdentifier and the CA signed the certificate using a
-   signature algorithm other than ECDSA, then clients MUST not make use
-   of the elliptic curve public key.
-
-      FieldID ::= SEQUENCE {
-         fieldType   OBJECT IDENTIFIER,
-         parameters  ANY DEFINED BY fieldType }
-
-   FieldID is a SEQUENCE of two components, fieldType and parameters.
-   The fieldType contains an object identifier value that uniquely
-   identifies the type contained in the parameters.
-
-   The object identifier id-fieldType specifies an arc containing the
-   object identifiers of each field type.  It has the following value:
-
-      id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 15]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   The object identifiers prime-field and characteristic-two-field name
-   the two kinds of fields defined in this Standard.  They have the
-   following values:
-
-      prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
-
-      Prime-p ::= INTEGER    -- Field size p (p in bits)
-
-      characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
-
-      Characteristic-two ::= SEQUENCE {
-         m           INTEGER,                      -- Field size 2^m
-         basis       OBJECT IDENTIFIER,
-         parameters  ANY DEFINED BY basis }
-
-   The object identifier id-characteristic-two-basis specifies an arc
-   containing the object identifiers for each type of basis for the
-   characteristic-two finite fields.  It has the following value:
-
-      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
-           characteristic-two-field basisType(1) }
-
-   The object identifiers gnBasis, tpBasis and ppBasis name the three
-   kinds of basis for characteristic-two finite fields defined by
-   [X9.62].  They have the following values:
-
-      gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
-
-      -- for gnBasis, the value of the parameters field is NULL
-
-      tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
-
-      -- type of parameters field for tpBasis is Trinomial
-
-      Trinomial ::= INTEGER
-
-      ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
-
-      -- type of parameters field for ppBasis is Pentanomial
-
-      Pentanomial ::= SEQUENCE {
-         k1  INTEGER,
-         k2  INTEGER,
-         k3  INTEGER }
-
-
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 16]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   The elliptic curve public key (an ECPoint which is an OCTET STRING)
-   is mapped to a subjectPublicKey (a BIT STRING) as follows:  the most
-   significant bit of the OCTET STRING becomes the most significant bit
-   of the BIT STRING, and the least significant bit of the OCTET STRING
-   becomes the least significant bit of the BIT STRING.  Note that this
-   octet string may represent an elliptic curve point in compressed or
-   uncompressed form.  Implementations that support elliptic curve
-   according to this specification MUST support the uncompressed form
-   and MAY support the compressed form.
-
-   If the keyUsage extension is present in a CA or CRL issuer
-   certificate which conveys an elliptic curve public key, any
-   combination of the following values MAY be present:
-
-      digitalSignature;
-      nonRepudiation; and
-      keyAgreement.
-
-   If the keyAgreement value is present, either of the following values
-   MAY be present:
-
-      encipherOnly; and
-      decipherOnly.
-
-   The keyUsage extension MUST NOT assert both encipherOnly and
-   decipherOnly.
-
-   If the keyUsage extension is present in a CA certificate which
-   conveys an elliptic curve public key, any combination of the
-   following values MAY be present:
-
-      digitalSignature;
-      nonRepudiation;
-      keyAgreement;
-      keyCertSign; and
-      cRLSign.
-
-   As above, if the keyUsage extension asserts keyAgreement then it MAY
-   assert either encipherOnly and decipherOnly.  However, this
-   specification RECOMMENDS that if keyCertSign or cRLSign is present,
-   keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
-
-
-
-
-
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 17]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-3  ASN.1 Module
-
-   PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
-   internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
-   id-mod-pkix1-algorithms(17) }
-
-   DEFINITIONS EXPLICIT TAGS ::= BEGIN
-
-   -- EXPORTS All;
-
-   -- IMPORTS NONE;
-
-   --
-   --   One-way Hash Functions
-   --
-
-   md2  OBJECT IDENTIFIER ::= {
-     iso(1) member-body(2) us(840) rsadsi(113549)
-     digestAlgorithm(2) 2 }
-
-   md5  OBJECT IDENTIFIER ::= {
-     iso(1) member-body(2) us(840) rsadsi(113549)
-     digestAlgorithm(2) 5 }
-
-   id-sha1  OBJECT IDENTIFIER ::= {
-     iso(1) identified-organization(3) oiw(14) secsig(3)
-     algorithms(2) 26 }
-
-   --
-   --   DSA Keys and Signatures
-   --
-
-   -- OID for DSA public key
-
-   id-dsa OBJECT IDENTIFIER ::= {
-        iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
-
-   -- encoding for DSA public key
-
-   DSAPublicKey ::= INTEGER  -- public key, y
-
-   Dss-Parms  ::=  SEQUENCE  {
-      p             INTEGER,
-      q             INTEGER,
-      g             INTEGER  }
-
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 18]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   -- OID for DSA signature generated with SHA-1 hash
-
-   id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
-        iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
-
-   -- encoding for DSA signature generated with SHA-1 hash
-
-   Dss-Sig-Value  ::=  SEQUENCE  {
-      r       INTEGER,
-      s       INTEGER  }
-
-   --
-   --   RSA Keys and Signatures
-   --
-
-   -- arc for RSA public key and RSA signature OIDs
-
-   pkcs-1 OBJECT IDENTIFIER ::= {
-         iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
-
-   -- OID for RSA public keys
-
-   rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }
-
-   -- OID for RSA signature generated with MD2 hash
-
-   md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }
-
-   -- OID for RSA signature generated with MD5 hash
-
-   md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }
-
-   -- OID for RSA signature generated with SHA-1 hash
-
-   sha1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }
-
-   -- encoding for RSA public key
-
-   RSAPublicKey ::= SEQUENCE {
-      modulus            INTEGER,    -- n
-      publicExponent     INTEGER  }  -- e
-
-
-
-
-
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 19]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   --
-   --   Diffie-Hellman Keys
-   --
-
-   dhpublicnumber OBJECT IDENTIFIER ::= {
-        iso(1) member-body(2) us(840) ansi-x942(10046)
-        number-type(2) 1 }
-
-   -- encoding for DSA public key
-
-   DHPublicKey ::= INTEGER  -- public key, y = g^x mod p
-
-   DomainParameters ::= SEQUENCE {
-      p       INTEGER,           -- odd prime, p=jq +1
-      g       INTEGER,           -- generator, g
-      q       INTEGER,           -- factor of p-1
-      j       INTEGER OPTIONAL,  -- subgroup factor, j>= 2
-      validationParms  ValidationParms OPTIONAL }
-
-   ValidationParms ::= SEQUENCE {
-      seed             BIT STRING,
-      pgenCounter      INTEGER }
-
-   --
-   --   KEA Keys
-   --
-
-   id-keyExchangeAlgorithm  OBJECT IDENTIFIER  ::=
-        { 2 16 840 1 101 2 1 1 22 }
-
-   KEA-Parms-Id ::= OCTET STRING
-
-   --
-   --   Elliptic Curve Keys, Signatures, and Curves
-   --
-
-   ansi-X9-62 OBJECT IDENTIFIER ::= {
-        iso(1) member-body(2) us(840) 10045 }
-
-   FieldID ::= SEQUENCE {                    -- Finite field
-      fieldType   OBJECT IDENTIFIER,
-      parameters  ANY DEFINED BY fieldType }
-
-   -- Arc for ECDSA signature OIDS
-
-   id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 20]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   -- OID for ECDSA signatures with SHA-1
-
-   ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
-
-   -- OID for an elliptic curve signature
-   -- format for the value of an ECDSA signature value
-
-   ECDSA-Sig-Value ::= SEQUENCE {
-      r     INTEGER,
-      s     INTEGER }
-
-   -- recognized field type OIDs are defined in the following arc
-
-   id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
-
-   -- where fieldType is prime-field, the parameters are of type Prime-p
-
-   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
-
-   Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime
-
-   -- where fieldType is characteristic-two-field, the parameters are
-   -- of type Characteristic-two
-
-   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
-
-   Characteristic-two ::= SEQUENCE {
-      m           INTEGER,                   -- Field size 2^m
-      basis       OBJECT IDENTIFIER,
-      parameters  ANY DEFINED BY basis }
-
-   -- recognized basis type OIDs are defined in the following arc
-
-   id-characteristic-two-basis OBJECT IDENTIFIER ::= {
-        characteristic-two-field basisType(3) }
-
-   -- gnbasis is identified by OID gnBasis and indicates
-   -- parameters are NULL
-
-   gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
-
-   -- parameters for this basis are NULL
-
-   -- trinomial basis is identified by OID tpBasis and indicates
-   -- parameters of type Pentanomial
-
-   tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
-
-
-
-
-Polk, et al.                Standards Track                    [Page 21]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   -- Trinomial basis representation of F2^m
-   -- Integer k for reduction polynomial xm + xk + 1
-
-   Trinomial ::= INTEGER
-
-   -- for pentanomial basis is identified by OID ppBasis and indicates
-   -- parameters of type Pentanomial
-
-   ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
-
-   -- Pentanomial basis representation of F2^m
-   -- reduction polynomial integers k1, k2, k3
-   -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
-
-   Pentanomial ::= SEQUENCE {
-      k1  INTEGER,
-      k2  INTEGER,
-      k3  INTEGER }
-
-   -- The object identifiers gnBasis, tpBasis and ppBasis name
-   -- three kinds of basis for characteristic-two finite fields
-
-   FieldElement ::= OCTET STRING             -- Finite field element
-
-   ECPoint  ::= OCTET STRING                 -- Elliptic curve point
-
-   -- Elliptic Curve parameters may be specified explicitly,
-   -- specified implicitly through a "named curve", or
-   -- inherited from the CA
-
-   EcpkParameters ::= CHOICE {
-      ecParameters  ECParameters,
-      namedCurve    OBJECT IDENTIFIER,
-      implicitlyCA  NULL }
-
-   ECParameters  ::= SEQUENCE {         -- Elliptic curve parameters
-      version   ECPVer,
-      fieldID   FieldID,
-      curve     Curve,
-      base      ECPoint,                -- Base point G
-      order     INTEGER,                -- Order n of the base point
-      cofactor  INTEGER  OPTIONAL }     -- The integer h = #E(Fq)/n
-
-   ECPVer ::= INTEGER {ecpVer1(1)}
-
-
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 22]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   Curve  ::= SEQUENCE {
-      a     FieldElement,            -- Elliptic curve coefficient a
-      b     FieldElement,            -- Elliptic curve coefficient b
-      seed  BIT STRING  OPTIONAL }
-
-   id-publicKeyType OBJECT IDENTIFIER  ::= { ansi-X9-62 keyType(2) }
-
-   id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
-
-   -- Named Elliptic Curves in ANSI X9.62.
-
-   ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }
-
-   c-TwoCurve OBJECT IDENTIFIER ::= {
-        ellipticCurve characteristicTwo(0) }
-
-   c2pnb163v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  1 }
-   c2pnb163v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  2 }
-   c2pnb163v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  3 }
-   c2pnb176w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  4 }
-   c2tnb191v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  5 }
-   c2tnb191v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  6 }
-   c2tnb191v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  7 }
-   c2onb191v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve  8 }
-   c2onb191v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve  9 }
-   c2pnb208w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 10 }
-   c2tnb239v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 11 }
-   c2tnb239v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve 12 }
-   c2tnb239v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve 13 }
-   c2onb239v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve 14 }
-   c2onb239v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve 15 }
-   c2pnb272w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 16 }
-   c2pnb304w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 17 }
-   c2tnb359v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 18 }
-   c2pnb368w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 19 }
-   c2tnb431r1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 20 }
-
-   primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }
-
-   prime192v1  OBJECT IDENTIFIER  ::=  { primeCurve  1 }
-   prime192v2  OBJECT IDENTIFIER  ::=  { primeCurve  2 }
-   prime192v3  OBJECT IDENTIFIER  ::=  { primeCurve  3 }
-   prime239v1  OBJECT IDENTIFIER  ::=  { primeCurve  4 }
-   prime239v2  OBJECT IDENTIFIER  ::=  { primeCurve  5 }
-   prime239v3  OBJECT IDENTIFIER  ::=  { primeCurve  6 }
-   prime256v1  OBJECT IDENTIFIER  ::=  { primeCurve  7 }
-
-   END
-
-
-
-Polk, et al.                Standards Track                    [Page 23]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-4  References
-
-   [FIPS 180-1]   Federal Information Processing Standards Publication
-                  (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
-                  [Supersedes FIPS PUB 180 dated 11 May 1993.]
-
-   [FIPS 186-2]   Federal Information Processing Standards Publication
-                  (FIPS PUB) 186, Digital Signature Standard, 27 January
-                  2000. [Supersedes FIPS PUB 186-1 dated 15 December
-                  1998.]
-
-   [P1363]        IEEE P1363, "Standard Specifications for Public-Key
-                  Cryptography", 2001.
-
-   [RC95]         Rogier, N. and Chauvaud, P., "The compression function
-                  of MD2 is not collision free," Presented at Selected
-                  Areas in Cryptography '95, May 1995.
-
-   [RFC 1034]     Mockapetris, P., "Domain Names - Concepts and
-                  Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1319]     Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
-                  1319, April 1992.
-
-   [RFC 1321]     Rivest, R., "The MD5 Message-Digest Algorithm", RFC
-                  1321, April 1992.
-
-   [RFC 1422]     Kent, S., "Privacy Enhancement for Internet Electronic
-                  Mail: Part II: Certificate-Based Key Management", RFC
-                  1422, February 1993.
-
-   [RFC 1423]     Balenson, D., "Privacy Enhancement for Internet
-                  Electronic Mail: Part III: Algorithms, Modes, and
-                  Identifiers", RFC 1423, February 1993.
-
-   [RFC 2119]     Bradner, S., "Key Words for Use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2313]     Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
-                  RFC 2313, March 1998.
-
-   [RFC 2459]     Housley, R., Ford, W., Polk, W. and D. Solo "Internet
-                  X.509 Public Key Infrastructure: Certificate and CRL
-                  Profile", RFC 2459, January, 1999.
-
-   [RFC 3174]     Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
-                  (SHA1)", RFC 3174, September 2001.
-
-
-
-
-Polk, et al.                Standards Track                    [Page 24]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   [RFC 3280]     Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                  X.509 Public Key Infrastructure Certificate and
-                  Certificate Revocation List (CRL) Profile", RFC 3280,
-                  April 2002.
-
-   [SDN.701r]     SDN.701, "Message Security Protocol 4.0", Revision A
-                  1997-02-06.
-
-   [X.208]        CCITT Recommendation X.208: Specification of Abstract
-                  Syntax Notation One (ASN.1), 1988.
-
-   [X.660]        ITU-T Recommendation X.660 Information Technology -
-                  ASN.1 encoding rules: Specification of Basic Encoding
-                  Rules (BER), Canonical Encoding Rules (CER) and
-                  Distinguished Encoding Rules (DER), 1997.
-
-   [X9.42]        ANSI X9.42-2000, "Public Key Cryptography for The
-                  Financial Services Industry: Agreement of Symmetric
-                  Keys Using Discrete Logarithm Cryptography", December,
-                  1999.
-
-   [X9.62]        X9.62-1998, "Public Key Cryptography For The Financial
-                  Services Industry: The Elliptic Curve Digital
-                  Signature Algorithm (ECDSA)", January 7, 1999.
-
-   [X9.63]        ANSI X9.63-2001, "Public Key Cryptography For The
-                  Financial Services Industry: Key Agreement and Key
-                  Transport Using Elliptic Curve Cryptography", Work in
-                  Progress.
-
-5  Security Considerations
-
-   This specification does not constrain the size of public keys or
-   their parameters for use in the Internet PKI.  However, the key size
-   selected impacts the strength achieved when implementing
-   cryptographic services.  Selection of appropriate key sizes is
-   critical to implementing appropriate security.
-
-   This specification does not identify particular elliptic curves for
-   use in the Internet PKI.  However, the particular curve selected
-   impact the strength of the digital signatures.  Some curves are
-   cryptographically stronger than others!
-
-   In general, use of "well-known" curves, such as the "named curves"
-   from ANSI X9.62, is a sound strategy.  For additional information,
-   refer to X9.62 Appendix H.1.3, "Key Length Considerations" and
-   Appendix A.1, "Avoiding Cryptographically Weak Keys".
-
-
-
-
-Polk, et al.                Standards Track                    [Page 25]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-   This specification supplements RFC 3280.  The security considerations
-   section of that document applies to this specification as well.
-
-6  Intellectual Property Rights
-
-   The IETF has been notified of intellectual property rights claimed in
-   regard to some or all of the specification contained in this
-   document.  For more information consult the online list of claimed
-   rights.
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards- related documentation can be found in BCP-11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-7  Author Addresses:
-
-   Tim Polk
-   NIST
-   100 Bureau Drive, Stop 8930
-   Gaithersburg, MD 20899-8930
-   USA
-   EMail: tim.polk@nist.gov
-
-   Russell Housley
-   RSA Laboratories
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-   EMail: rhousley@rsasecurity.com
-
-   Larry Bassham
-   NIST
-   100 Bureau Drive, Stop 8930
-   Gaithersburg, MD 20899-8930
-   USA
-   EMail: lbassham@nist.gov
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 26]
-
-RFC 3279               Algorithms and Identifiers             April 2002
-
-
-8.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Polk, et al.                Standards Track                    [Page 27]
-
diff --git a/doc/protocol/rfc3280.txt b/doc/protocol/rfc3280.txt
deleted file mode 100644
index 433908bb75..0000000000
--- a/doc/protocol/rfc3280.txt
+++ /dev/null
@@ -1,7227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Housley
-Request for Comments: 3280                              RSA Laboratories
-Obsoletes: 2459                                                  W. Polk
-Category: Standards Track                                           NIST
-                                                                 W. Ford
-                                                                VeriSign
-                                                                 D. Solo
-                                                               Citigroup
-                                                              April 2002
-
-                Internet X.509 Public Key Infrastructure
-       Certificate and Certificate Revocation List (CRL) Profile
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo profiles the X.509 v3 certificate and X.509 v2 Certificate
-   Revocation List (CRL) for use in the Internet.  An overview of this
-   approach and model are provided as an introduction.  The X.509 v3
-   certificate format is described in detail, with additional
-   information regarding the format and semantics of Internet name
-   forms.  Standard certificate extensions are described and two
-   Internet-specific extensions are defined.  A set of required
-   certificate extensions is specified.  The X.509 v2 CRL format is
-   described in detail, and required extensions are defined.  An
-   algorithm for X.509 certification path validation is described.  An
-   ASN.1 module and examples are provided in the appendices.
-
-Table of Contents
-
-   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   4
-   2  Requirements and Assumptions  . . . . . . . . . . . . . .   5
-   2.1  Communication and Topology  . . . . . . . . . . . . . .   6
-   2.2  Acceptability Criteria  . . . . . . . . . . . . . . . .   6
-   2.3  User Expectations . . . . . . . . . . . . . . . . . . .   7
-   2.4  Administrator Expectations  . . . . . . . . . . . . . .   7
-   3  Overview of Approach  . . . . . . . . . . . . . . . . . .   7
-
-
-
-Housley, et. al.            Standards Track                     [Page 1]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   3.1  X.509 Version 3 Certificate . . . . . . . . . . . . . .   8
-   3.2  Certification Paths and Trust . . . . . . . . . . . . .   9
-   3.3  Revocation  . . . . . . . . . . . . . . . . . . . . . .  11
-   3.4  Operational Protocols . . . . . . . . . . . . . . . . .  13
-   3.5  Management Protocols  . . . . . . . . . . . . . . . . .  13
-   4  Certificate and Certificate Extensions Profile  . . . . .  14
-   4.1  Basic Certificate Fields  . . . . . . . . . . . . . . .  15
-   4.1.1  Certificate Fields  . . . . . . . . . . . . . . . . .  16
-   4.1.1.1  tbsCertificate  . . . . . . . . . . . . . . . . . .  16
-   4.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  16
-   4.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  16
-   4.1.2  TBSCertificate  . . . . . . . . . . . . . . . . . . .  17
-   4.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  17
-   4.1.2.2  Serial number . . . . . . . . . . . . . . . . . . .  17
-   4.1.2.3  Signature . . . . . . . . . . . . . . . . . . . . .  18
-   4.1.2.4  Issuer  . . . . . . . . . . . . . . . . . . . . . .  18
-   4.1.2.5  Validity  . . . . . . . . . . . . . . . . . . . . .  22
-   4.1.2.5.1  UTCTime . . . . . . . . . . . . . . . . . . . . .  22
-   4.1.2.5.2  GeneralizedTime . . . . . . . . . . . . . . . . .  22
-   4.1.2.6  Subject . . . . . . . . . . . . . . . . . . . . . .  23
-   4.1.2.7  Subject Public Key Info . . . . . . . . . . . . . .  24
-   4.1.2.8  Unique Identifiers  . . . . . . . . . . . . . . . .  24
-   4.1.2.9 Extensions . . . . . . . . . . . . . . . . . . . . .  24
-   4.2  Certificate Extensions  . . . . . . . . . . . . . . . .  24
-   4.2.1  Standard Extensions . . . . . . . . . . . . . . . . .  25
-   4.2.1.1  Authority Key Identifier  . . . . . . . . . . . . .  26
-   4.2.1.2  Subject Key Identifier  . . . . . . . . . . . . . .  27
-   4.2.1.3  Key Usage . . . . . . . . . . . . . . . . . . . . .  28
-   4.2.1.4  Private Key Usage Period  . . . . . . . . . . . . .  29
-   4.2.1.5  Certificate Policies  . . . . . . . . . . . . . . .  30
-   4.2.1.6  Policy Mappings . . . . . . . . . . . . . . . . . .  33
-   4.2.1.7  Subject Alternative Name  . . . . . . . . . . . . .  33
-   4.2.1.8  Issuer Alternative Name . . . . . . . . . . . . . .  36
-   4.2.1.9  Subject Directory Attributes  . . . . . . . . . . .  36
-   4.2.1.10  Basic Constraints  . . . . . . . . . . . . . . . .  36
-   4.2.1.11  Name Constraints . . . . . . . . . . . . . . . . .  37
-   4.2.1.12  Policy Constraints . . . . . . . . . . . . . . . .  40
-   4.2.1.13  Extended Key Usage . . . . . . . . . . . . . . . .  40
-   4.2.1.14  CRL Distribution Points  . . . . . . . . . . . . .  42
-   4.2.1.15  Inhibit Any-Policy . . . . . . . . . . . . . . . .  44
-   4.2.1.16  Freshest CRL . . . . . . . . . . . . . . . . . . .  44
-   4.2.2  Internet Certificate Extensions . . . . . . . . . . .  45
-   4.2.2.1  Authority Information Access  . . . . . . . . . . .  45
-   4.2.2.2  Subject Information Access  . . . . . . . . . . . .  46
-   5  CRL and CRL Extensions Profile  . . . . . . . . . . . . .  48
-   5.1  CRL Fields  . . . . . . . . . . . . . . . . . . . . . .  49
-   5.1.1  CertificateList Fields  . . . . . . . . . . . . . . .  50
-   5.1.1.1  tbsCertList . . . . . . . . . . . . . . . . . . . .  50
-
-
-
-Housley, et. al.            Standards Track                     [Page 2]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   5.1.1.2  signatureAlgorithm  . . . . . . . . . . . . . . . .  50
-   5.1.1.3  signatureValue  . . . . . . . . . . . . . . . . . .  51
-   5.1.2  Certificate List "To Be Signed" . . . . . . . . . . .  51
-   5.1.2.1  Version . . . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.2  Signature . . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.3  Issuer Name . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.4  This Update . . . . . . . . . . . . . . . . . . . .  52
-   5.1.2.5  Next Update . . . . . . . . . . . . . . . . . . . .  53
-   5.1.2.6  Revoked Certificates  . . . . . . . . . . . . . . .  53
-   5.1.2.7  Extensions  . . . . . . . . . . . . . . . . . . . .  53
-   5.2  CRL Extensions  . . . . . . . . . . . . . . . . . . . .  53
-   5.2.1  Authority Key Identifier  . . . . . . . . . . . . . .  54
-   5.2.2  Issuer Alternative Name . . . . . . . . . . . . . . .  54
-   5.2.3  CRL Number  . . . . . . . . . . . . . . . . . . . . .  55
-   5.2.4  Delta CRL Indicator . . . . . . . . . . . . . . . . .  55
-   5.2.5  Issuing Distribution Point  . . . . . . . . . . . . .  58
-   5.2.6  Freshest CRL  . . . . . . . . . . . . . . . . . . . .  59
-   5.3  CRL Entry Extensions  . . . . . . . . . . . . . . . . .  60
-   5.3.1  Reason Code . . . . . . . . . . . . . . . . . . . . .  60
-   5.3.2  Hold Instruction Code . . . . . . . . . . . . . . . .  61
-   5.3.3  Invalidity Date . . . . . . . . . . . . . . . . . . .  62
-   5.3.4  Certificate Issuer  . . . . . . . . . . . . . . . . .  62
-   6  Certificate Path Validation . . . . . . . . . . . . . . .  62
-   6.1  Basic Path Validation . . . . . . . . . . . . . . . . .  63
-   6.1.1  Inputs  . . . . . . . . . . . . . . . . . . . . . . .  66
-   6.1.2  Initialization  . . . . . . . . . . . . . . . . . . .  67
-   6.1.3  Basic Certificate Processing  . . . . . . . . . . . .  70
-   6.1.4  Preparation for Certificate i+1 . . . . . . . . . . .  75
-   6.1.5  Wrap-up procedure . . . . . . . . . . . . . . . . . .  78
-   6.1.6  Outputs . . . . . . . . . . . . . . . . . . . . . . .  80
-   6.2  Extending Path Validation . . . . . . . . . . . . . . .  80
-   6.3  CRL Validation  . . . . . . . . . . . . . . . . . . . .  81
-   6.3.1  Revocation Inputs . . . . . . . . . . . . . . . . . .  82
-   6.3.2  Initialization and Revocation State Variables . . . .  82
-   6.3.3  CRL Processing  . . . . . . . . . . . . . . . . . . .  83
-   7  References  . . . . . . . . . . . . . . . . . . . . . . .  86
-   8  Intellectual Property Rights  . . . . . . . . . . . . . .  88
-   9  Security Considerations . . . . . . . . . . . . . . . . .  89
-   Appendix A.  ASN.1 Structures and OIDs . . . . . . . . . . .  92
-   A.1 Explicitly Tagged Module, 1988 Syntax  . . . . . . . . .  92
-   A.2 Implicitly Tagged Module, 1988 Syntax  . . . . . . . . . 105
-   Appendix B.  ASN.1 Notes . . . . . . . . . . . . . . . . . . 112
-   Appendix C.  Examples  . . . . . . . . . . . . . . . . . . . 115
-   C.1  DSA Self-Signed Certificate . . . . . . . . . . . . . . 115
-   C.2  End Entity Certificate Using DSA  . . . . . . . . . . . 119
-   C.3  End Entity Certificate Using RSA  . . . . . . . . . . . 122
-   C.4  Certificate Revocation List . . . . . . . . . . . . . . 126
-   Author Addresses . . . . . . . . . . . . . . . . . . . . . . 128
-
-
-
-Housley, et. al.            Standards Track                     [Page 3]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . 129
-
-1  Introduction
-
-   This specification is one part of a family of standards for the X.509
-   Public Key Infrastructure (PKI) for the Internet.
-
-   This specification profiles the format and semantics of certificates
-   and certificate revocation lists (CRLs) for the Internet PKI.
-   Procedures are described for processing of certification paths in the
-   Internet environment.  Finally, ASN.1 modules are provided in the
-   appendices for all data structures defined or referenced.
-
-   Section 2 describes Internet PKI requirements, and the assumptions
-   which affect the scope of this document.  Section 3 presents an
-   architectural model and describes its relationship to previous IETF
-   and ISO/IEC/ITU-T standards.  In particular, this document's
-   relationship with the IETF PEM specifications and the ISO/IEC/ITU-T
-   X.509 documents are described.
-
-   Section 4 profiles the X.509 version 3 certificate, and section 5
-   profiles the X.509 version 2 CRL.  The profiles include the
-   identification of ISO/IEC/ITU-T and ANSI extensions which may be
-   useful in the Internet PKI.  The profiles are presented in the 1988
-   Abstract Syntax Notation One (ASN.1) rather than the 1997 ASN.1
-   syntax used in the most recent ISO/IEC/ITU-T standards.
-
-   Section 6 includes certification path validation procedures.  These
-   procedures are based upon the ISO/IEC/ITU-T definition.
-   Implementations are REQUIRED to derive the same results but are not
-   required to use the specified procedures.
-
-   Procedures for identification and encoding of public key materials
-   and digital signatures are defined in [PKIXALGS].  Implementations of
-   this specification are not required to use any particular
-   cryptographic algorithms.  However, conforming implementations which
-   use the algorithms identified in [PKIXALGS] MUST identify and encode
-   the public key materials and digital signatures as described in that
-   specification.
-
-   Finally, three appendices are provided to aid implementers.  Appendix
-   A contains all ASN.1 structures defined or referenced within this
-   specification.  As above, the material is presented in the 1988
-   ASN.1.  Appendix B contains notes on less familiar features of the
-   ASN.1 notation used within this specification.  Appendix C contains
-   examples of a conforming certificate and a conforming CRL.
-
-
-
-
-
-Housley, et. al.            Standards Track                     [Page 4]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   This specification obsoletes RFC 2459.  This specification differs
-   from RFC 2459 in five basic areas:
-
-      * To promote interoperable implementations, a detailed algorithm
-      for certification path validation is included in section 6.1 of
-      this specification; RFC 2459 provided only a high-level
-      description of path validation.
-
-      * An algorithm for determining the status of a certificate using
-      CRLs is provided in section 6.3 of this specification.  This
-      material was not present in RFC 2459.
-
-      * To accommodate new usage models, detailed information describing
-      the use of delta CRLs is provided in Section 5 of this
-      specification.
-
-      * Identification and encoding of public key materials and digital
-      signatures are not included in this specification, but are now
-      described in a companion specification [PKIXALGS].
-
-      * Four additional extensions are specified: three certificate
-      extensions and one CRL extension.  The certificate extensions are
-      subject info access, inhibit any-policy, and freshest CRL.  The
-      freshest CRL extension is also defined as a CRL extension.
-
-      * Throughout the specification, clarifications have been
-      introduced to enhance consistency with the ITU-T X.509
-      specification.  X.509 defines the certificate and CRL format as
-      well as many of the extensions that appear in this specification.
-      These changes were introduced to improve the likelihood of
-      interoperability between implementations based on this
-      specification with implementations based on the ITU-T
-      specification.
-
-   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.
-
-2  Requirements and Assumptions
-
-   The goal of this specification is to develop a profile to facilitate
-   the use of X.509 certificates within Internet applications for those
-   communities wishing to make use of X.509 technology.  Such
-   applications may include WWW, electronic mail, user authentication,
-   and IPsec.  In order to relieve some of the obstacles to using X.509
-
-
-
-
-
-
-Housley, et. al.            Standards Track                     [Page 5]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificates, this document defines a profile to promote the
-   development of certificate management systems; development of
-   application tools; and interoperability determined by policy.
-
-   Some communities will need to supplement, or possibly replace, this
-   profile in order to meet the requirements of specialized application
-   domains or environments with additional authorization, assurance, or
-   operational requirements.  However, for basic applications, common
-   representations of frequently used attributes are defined so that
-   application developers can obtain necessary information without
-   regard to the issuer of a particular certificate or certificate
-   revocation list (CRL).
-
-   A certificate user should review the certificate policy generated by
-   the certification authority (CA) before relying on the authentication
-   or non-repudiation services associated with the public key in a
-   particular certificate.  To this end, this standard does not
-   prescribe legally binding rules or duties.
-
-   As supplemental authorization and attribute management tools emerge,
-   such as attribute certificates, it may be appropriate to limit the
-   authenticated attributes that are included in a certificate.  These
-   other management tools may provide more appropriate methods of
-   conveying many authenticated attributes.
-
-2.1  Communication and Topology
-
-   The users of certificates will operate in a wide range of
-   environments with respect to their communication topology, especially
-   users of secure electronic mail.  This profile supports users without
-   high bandwidth, real-time IP connectivity, or high connection
-   availability.  In addition, the profile allows for the presence of
-   firewall or other filtered communication.
-
-   This profile does not assume the deployment of an X.500 Directory
-   system or a LDAP directory system.  The profile does not prohibit the
-   use of an X.500 Directory or a LDAP directory; however, any means of
-   distributing certificates and certificate revocation lists (CRLs) may
-   be used.
-
-2.2  Acceptability Criteria
-
-   The goal of the Internet Public Key Infrastructure (PKI) is to meet
-   the needs of deterministic, automated identification, authentication,
-   access control, and authorization functions.  Support for these
-   services determines the attributes contained in the certificate as
-   well as the ancillary control information in the certificate such as
-   policy data and certification path constraints.
-
-
-
-Housley, et. al.            Standards Track                     [Page 6]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-2.3  User Expectations
-
-   Users of the Internet PKI are people and processes who use client
-   software and are the subjects named in certificates.  These uses
-   include readers and writers of electronic mail, the clients for WWW
-   browsers, WWW servers, and the key manager for IPsec within a router.
-   This profile recognizes the limitations of the platforms these users
-   employ and the limitations in sophistication and attentiveness of the
-   users themselves.  This manifests itself in minimal user
-   configuration responsibility (e.g., trusted CA keys, rules), explicit
-   platform usage constraints within the certificate, certification path
-   constraints which shield the user from many malicious actions, and
-   applications which sensibly automate validation functions.
-
-2.4  Administrator Expectations
-
-   As with user expectations, the Internet PKI profile is structured to
-   support the individuals who generally operate CAs.  Providing
-   administrators with unbounded choices increases the chances that a
-   subtle CA administrator mistake will result in broad compromise.
-   Also, unbounded choices greatly complicate the software that process
-   and validate the certificates created by the CA.
-
-3  Overview of Approach
-
-   Following is a simplified view of the architectural model assumed by
-   the PKIX specifications.
-
-   The components in this model are:
-
-   end entity: user of PKI certificates and/or end user system that is
-               the subject of a certificate;
-   CA:         certification authority;
-   RA:         registration authority, i.e., an optional system to which
-               a CA delegates certain management functions;
-   CRL issuer: an optional system to which a CA delegates the
-               publication of certificate revocation lists;
-   repository: a system or collection of distributed systems that stores
-               certificates and CRLs and serves as a means of
-               distributing these certificates and CRLs to end entities.
-
-   Note that an Attribute Authority (AA) might also choose to delegate
-   the publication of CRLs to a CRL issuer.
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                     [Page 7]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   +---+
-   | C |                       +------------+
-   | e | <-------------------->| End entity |
-   | r |       Operational     +------------+
-   | t |       transactions          ^
-   | i |      and management         |  Management
-   | f |       transactions          |  transactions        PKI
-   | i |                             |                     users
-   | c |                             v
-   | a | =======================  +--+------------+  ==============
-   | t |                          ^               ^
-   | e |                          |               |         PKI
-   |   |                          v               |      management
-   | & |                       +------+           |       entities
-   |   | <---------------------|  RA  |<----+     |
-   | C |  Publish certificate  +------+     |     |
-   | R |                                    |     |
-   | L |                                    |     |
-   |   |                                    v     v
-   | R |                                +------------+
-   | e | <------------------------------|     CA     |
-   | p |   Publish certificate          +------------+
-   | o |   Publish CRL                     ^      ^
-   | s |                                   |      |  Management
-   | i |                +------------+     |      |  transactions
-   | t | <--------------| CRL Issuer |<----+      |
-   | o |   Publish CRL  +------------+            v
-   | r |                                      +------+
-   | y |                                      |  CA  |
-   +---+                                      +------+
-
-                      Figure 1 - PKI Entities
-
-3.1  X.509 Version 3 Certificate
-
-   Users of a public key require confidence that the associated private
-   key is owned by the correct remote subject (person or system) with
-   which an encryption or digital signature mechanism will be used.
-   This confidence is obtained through the use of public key
-   certificates, which are data structures that bind public key values
-   to subjects.  The binding is asserted by having a trusted CA
-   digitally sign each certificate.  The CA may base this assertion upon
-   technical means (a.k.a., proof of possession through a challenge-
-   response protocol), presentation of the private key, or on an
-   assertion by the subject.  A certificate has a limited valid lifetime
-   which is indicated in its signed contents.  Because a certificate's
-   signature and timeliness can be independently checked by a
-   certificate-using client, certificates can be distributed via
-
-
-
-Housley, et. al.            Standards Track                     [Page 8]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   untrusted communications and server systems, and can be cached in
-   unsecured storage in certificate-using systems.
-
-   ITU-T X.509 (formerly CCITT X.509) or ISO/IEC 9594-8, which was first
-   published in 1988 as part of the X.500 Directory recommendations,
-   defines a standard certificate format [X.509].  The certificate
-   format in the 1988 standard is called the version 1 (v1) format.
-   When X.500 was revised in 1993, two more fields were added, resulting
-   in the version 2 (v2) format.
-
-   The Internet Privacy Enhanced Mail (PEM) RFCs, published in 1993,
-   include specifications for a public key infrastructure based on X.509
-   v1 certificates [RFC 1422].  The experience gained in attempts to
-   deploy RFC 1422 made it clear that the v1 and v2 certificate formats
-   are deficient in several respects.  Most importantly, more fields
-   were needed to carry information which PEM design and implementation
-   experience had proven necessary.  In response to these new
-   requirements, ISO/IEC, ITU-T and ANSI X9 developed the X.509 version
-   3 (v3) certificate format.  The v3 format extends the v2 format by
-   adding provision for additional extension fields.  Particular
-   extension field types may be specified in standards or may be defined
-   and registered by any organization or community.  In June 1996,
-   standardization of the basic v3 format was completed [X.509].
-
-   ISO/IEC, ITU-T, and ANSI X9 have also developed standard extensions
-   for use in the v3 extensions field [X.509][X9.55].  These extensions
-   can convey such data as additional subject identification
-   information, key attribute information, policy information, and
-   certification path constraints.
-
-   However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very
-   broad in their applicability.  In order to develop interoperable
-   implementations of X.509 v3 systems for Internet use, it is necessary
-   to specify a profile for use of the X.509 v3 extensions tailored for
-   the Internet.  It is one goal of this document to specify a profile
-   for Internet WWW, electronic mail, and IPsec applications.
-   Environments with additional requirements may build on this profile
-   or may replace it.
-
-3.2  Certification Paths and Trust
-
-   A user of a security service requiring knowledge of a public key
-   generally needs to obtain and validate a certificate containing the
-   required public key.  If the public key user does not already hold an
-   assured copy of the public key of the CA that signed the certificate,
-   the CA's name, and related information (such as the validity period
-   or name constraints), then it might need an additional certificate to
-   obtain that public key.  In general, a chain of multiple certificates
-
-
-
-Housley, et. al.            Standards Track                     [Page 9]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   may be needed, comprising a certificate of the public key owner (the
-   end entity) signed by one CA, and zero or more additional
-   certificates of CAs signed by other CAs.  Such chains, called
-   certification paths, are required because a public key user is only
-   initialized with a limited number of assured CA public keys.
-
-   There are different ways in which CAs might be configured in order
-   for public key users to be able to find certification paths.  For
-   PEM, RFC 1422 defined a rigid hierarchical structure of CAs.  There
-   are three types of PEM certification authority:
-
-      (a)  Internet Policy Registration Authority (IPRA):  This
-      authority, operated under the auspices of the Internet Society,
-      acts as the root of the PEM certification hierarchy at level 1.
-      It issues certificates only for the next level of authorities,
-      PCAs.  All certification paths start with the IPRA.
-
-      (b)  Policy Certification Authorities (PCAs):  PCAs are at level 2
-      of the hierarchy, each PCA being certified by the IPRA.  A PCA
-      shall establish and publish a statement of its policy with respect
-      to certifying users or subordinate certification authorities.
-      Distinct PCAs aim to satisfy different user needs.  For example,
-      one PCA (an organizational PCA) might support the general
-      electronic mail needs of commercial organizations, and another PCA
-      (a high-assurance PCA) might have a more stringent policy designed
-      for satisfying legally binding digital signature requirements.
-
-      (c)  Certification Authorities (CAs):  CAs are at level 3 of the
-      hierarchy and can also be at lower levels.  Those at level 3 are
-      certified by PCAs.  CAs represent, for example, particular
-      organizations, particular organizational units (e.g., departments,
-      groups, sections), or particular geographical areas.
-
-   RFC 1422 furthermore has a name subordination rule which requires
-   that a CA can only issue certificates for entities whose names are
-   subordinate (in the X.500 naming tree) to the name of the CA itself.
-   The trust associated with a PEM certification path is implied by the
-   PCA name.  The name subordination rule ensures that CAs below the PCA
-   are sensibly constrained as to the set of subordinate entities they
-   can certify (e.g., a CA for an organization can only certify entities
-   in that organization's name tree).  Certificate user systems are able
-   to mechanically check that the name subordination rule has been
-   followed.
-
-   The RFC 1422 uses the X.509 v1 certificate formats.  The limitations
-   of X.509 v1 required imposition of several structural restrictions to
-   clearly associate policy information or restrict the utility of
-   certificates.  These restrictions included:
-
-
-
-Housley, et. al.            Standards Track                    [Page 10]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (a)  a pure top-down hierarchy, with all certification paths
-      starting from IPRA;
-
-      (b)  a naming subordination rule restricting the names of a CA's
-      subjects; and
-
-      (c)  use of the PCA concept, which requires knowledge of
-      individual PCAs to be built into certificate chain verification
-      logic.  Knowledge of individual PCAs was required to determine if
-      a chain could be accepted.
-
-   With X.509 v3, most of the requirements addressed by RFC 1422 can be
-   addressed using certificate extensions, without a need to restrict
-   the CA structures used.  In particular, the certificate extensions
-   relating to certificate policies obviate the need for PCAs and the
-   constraint extensions obviate the need for the name subordination
-   rule.  As a result, this document supports a more flexible
-   architecture, including:
-
-      (a)  Certification paths start with a public key of a CA in a
-      user's own domain, or with the public key of the top of a
-      hierarchy.  Starting with the public key of a CA in a user's own
-      domain has certain advantages.  In some environments, the local
-      domain is the most trusted.
-
-      (b)  Name constraints may be imposed through explicit inclusion of
-      a name constraints extension in a certificate, but are not
-      required.
-
-      (c)  Policy extensions and policy mappings replace the PCA
-      concept, which permits a greater degree of automation.  The
-      application can determine if the certification path is acceptable
-      based on the contents of the certificates instead of a priori
-      knowledge of PCAs.  This permits automation of certification path
-      processing.
-
-3.3  Revocation
-
-   When a certificate is issued, it is expected to be in use for its
-   entire validity period.  However, various circumstances may cause a
-   certificate to become invalid prior to the expiration of the validity
-   period.  Such circumstances include change of name, change of
-   association between subject and CA (e.g., an employee terminates
-   employment with an organization), and compromise or suspected
-   compromise of the corresponding private key.  Under such
-   circumstances, the CA needs to revoke the certificate.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 11]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   X.509 defines one method of certificate revocation.  This method
-   involves each CA periodically issuing a signed data structure called
-   a certificate revocation list (CRL).  A CRL is a time stamped list
-   identifying revoked certificates which is signed by a CA or CRL
-   issuer and made freely available in a public repository.  Each
-   revoked certificate is identified in a CRL by its certificate serial
-   number.  When a certificate-using system uses a certificate (e.g.,
-   for verifying a remote user's digital signature), that system not
-   only checks the certificate signature and validity but also acquires
-   a suitably-recent CRL and checks that the certificate serial number
-   is not on that CRL.  The meaning of "suitably-recent" may vary with
-   local policy, but it usually means the most recently-issued CRL.  A
-   new CRL is issued on a regular periodic basis (e.g., hourly, daily,
-   or weekly).  An entry is added to the CRL as part of the next update
-   following notification of revocation.  An entry MUST NOT be removed
-   from the CRL until it appears on one regularly scheduled CRL issued
-   beyond the revoked certificate's validity period.
-
-   An advantage of this revocation method is that CRLs may be
-   distributed by exactly the same means as certificates themselves,
-   namely, via untrusted servers and untrusted communications.
-
-   One limitation of the CRL revocation method, using untrusted
-   communications and servers, is that the time granularity of
-   revocation is limited to the CRL issue period.  For example, if a
-   revocation is reported now, that revocation will not be reliably
-   notified to certificate-using systems until all currently issued CRLs
-   are updated -- this may be up to one hour, one day, or one week
-   depending on the frequency that CRLs are issued.
-
-   As with the X.509 v3 certificate format, in order to facilitate
-   interoperable implementations from multiple vendors, the X.509 v2 CRL
-   format needs to be profiled for Internet use.  It is one goal of this
-   document to specify that profile.  However, this profile does not
-   require the issuance of CRLs.  Message formats and protocols
-   supporting on-line revocation notification are defined in other PKIX
-   specifications.  On-line methods of revocation notification may be
-   applicable in some environments as an alternative to the X.509 CRL.
-   On-line revocation checking may significantly reduce the latency
-   between a revocation report and the distribution of the information
-   to relying parties.  Once the CA accepts a revocation report as
-   authentic and valid, any query to the on-line service will correctly
-   reflect the certificate validation impacts of the revocation.
-   However, these methods impose new security requirements: the
-   certificate validator needs to trust the on-line validation service
-   while the repository does not need to be trusted.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 12]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-3.4  Operational Protocols
-
-   Operational protocols are required to deliver certificates and CRLs
-   (or status information) to certificate using client systems.
-   Provisions are needed for a variety of different means of certificate
-   and CRL delivery, including distribution procedures based on LDAP,
-   HTTP, FTP, and X.500.  Operational protocols supporting these
-   functions are defined in other PKIX specifications.  These
-   specifications may include definitions of message formats and
-   procedures for supporting all of the above operational environments,
-   including definitions of or references to appropriate MIME content
-   types.
-
-3.5  Management Protocols
-
-   Management protocols are required to support on-line interactions
-   between PKI user and management entities.  For example, a management
-   protocol might be used between a CA and a client system with which a
-   key pair is associated, or between two CAs which cross-certify each
-   other.  The set of functions which potentially need to be supported
-   by management protocols include:
-
-      (a)  registration:  This is the process whereby a user first makes
-      itself known to a CA (directly, or through an RA), prior to that
-      CA issuing  a certificate or certificates for that user.
-
-      (b)  initialization:  Before a client system can operate securely
-      it is necessary to install key materials which have the
-      appropriate relationship with keys stored elsewhere in the
-      infrastructure.  For example, the client needs to be securely
-      initialized with the public key and other assured information of
-      the trusted CA(s), to be used in validating certificate paths.
-
-      Furthermore, a client typically needs to be initialized with its
-      own key pair(s).
-
-      (c)  certification:  This is the process in which a CA issues a
-      certificate for a user's public key, and returns that certificate
-      to the user's client system and/or posts that certificate in a
-      repository.
-
-      (d)  key pair recovery:  As an option, user client key materials
-      (e.g., a user's private key used for encryption purposes) may be
-      backed up by a CA or a key backup system.  If a user needs to
-      recover these backed up key materials (e.g., as a result of a
-      forgotten password or a lost key chain file), an on-line protocol
-      exchange may be needed to support such recovery.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 13]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (e)  key pair update:  All key pairs need to be updated regularly,
-      i.e., replaced with a new key pair, and new certificates issued.
-
-      (f)  revocation request:  An authorized person advises a CA of an
-      abnormal situation requiring certificate revocation.
-
-      (g)  cross-certification:  Two CAs exchange information used in
-      establishing a cross-certificate.  A cross-certificate is a
-      certificate issued by one CA to another CA which contains a CA
-      signature key used for issuing certificates.
-
-   Note that on-line protocols are not the only way of implementing the
-   above functions.  For all functions there are off-line methods of
-   achieving the same result, and this specification does not mandate
-   use of on-line protocols.  For example, when hardware tokens are
-   used, many of the functions may be achieved as part of the physical
-   token delivery.  Furthermore, some of the above functions may be
-   combined into one protocol exchange.  In particular, two or more of
-   the registration, initialization, and certification functions can be
-   combined into one protocol exchange.
-
-   The PKIX series of specifications defines a set of standard message
-   formats supporting the above functions.  The protocols for conveying
-   these messages in different environments (e.g., e-mail, file
-   transfer, and WWW) are described in those specifications.
-
-4  Certificate and Certificate Extensions Profile
-
-   This section presents a profile for public key certificates that will
-   foster interoperability and a reusable PKI.  This section is based
-   upon the X.509 v3 certificate format and the standard certificate
-   extensions defined in [X.509].  The ISO/IEC and ITU-T documents use
-   the 1997 version of ASN.1; while this document uses the 1988 ASN.1
-   syntax, the encoded certificate and standard extensions are
-   equivalent.  This section also defines private extensions required to
-   support a PKI for the Internet community.
-
-   Certificates may be used in a wide range of applications and
-   environments covering a broad spectrum of interoperability goals and
-   a broader spectrum of operational and assurance requirements.  The
-   goal of this document is to establish a common baseline for generic
-   applications requiring broad interoperability and limited special
-   purpose requirements.  In particular, the emphasis will be on
-   supporting the use of X.509 v3 certificates for informal Internet
-   electronic mail, IPsec, and WWW applications.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 14]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.1  Basic Certificate Fields
-
-   The X.509 v3 certificate basic syntax is as follows.  For signature
-   calculation, the data that is to be signed is encoded using the ASN.1
-   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
-   tag, length, value encoding system for each element.
-
-   Certificate  ::=  SEQUENCE  {
-        tbsCertificate       TBSCertificate,
-        signatureAlgorithm   AlgorithmIdentifier,
-        signatureValue       BIT STRING  }
-
-   TBSCertificate  ::=  SEQUENCE  {
-        version         [0]  EXPLICIT Version DEFAULT v1,
-        serialNumber         CertificateSerialNumber,
-        signature            AlgorithmIdentifier,
-        issuer               Name,
-        validity             Validity,
-        subject              Name,
-        subjectPublicKeyInfo SubjectPublicKeyInfo,
-        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
-                             -- If present, version MUST be v2 or v3
-        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
-                             -- If present, version MUST be v2 or v3
-        extensions      [3]  EXPLICIT Extensions OPTIONAL
-                             -- If present, version MUST be v3
-        }
-
-   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
-
-   CertificateSerialNumber  ::=  INTEGER
-
-   Validity ::= SEQUENCE {
-        notBefore      Time,
-        notAfter       Time }
-
-   Time ::= CHOICE {
-        utcTime        UTCTime,
-        generalTime    GeneralizedTime }
-
-   UniqueIdentifier  ::=  BIT STRING
-
-   SubjectPublicKeyInfo  ::=  SEQUENCE  {
-        algorithm            AlgorithmIdentifier,
-        subjectPublicKey     BIT STRING  }
-
-   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 15]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Extension  ::=  SEQUENCE  {
-        extnID      OBJECT IDENTIFIER,
-        critical    BOOLEAN DEFAULT FALSE,
-        extnValue   OCTET STRING  }
-
-   The following items describe the X.509 v3 certificate for use in the
-   Internet.
-
-4.1.1  Certificate Fields
-
-   The Certificate is a SEQUENCE of three required fields.  The fields
-   are described in detail in the following subsections.
-
-4.1.1.1  tbsCertificate
-
-   The field contains the names of the subject and issuer, a public key
-   associated with the subject, a validity period, and other associated
-   information.  The fields are described in detail in section 4.1.2;
-   the tbsCertificate usually includes extensions which are described in
-   section 4.2.
-
-4.1.1.2  signatureAlgorithm
-
-   The signatureAlgorithm field contains the identifier for the
-   cryptographic algorithm used by the CA to sign this certificate.
-   [PKIXALGS] lists supported signature algorithms, but other signature
-   algorithms MAY also be supported.
-
-   An algorithm identifier is defined by the following ASN.1 structure:
-
-   AlgorithmIdentifier  ::=  SEQUENCE  {
-        algorithm               OBJECT IDENTIFIER,
-        parameters              ANY DEFINED BY algorithm OPTIONAL  }
-
-   The algorithm identifier is used to identify a cryptographic
-   algorithm.  The OBJECT IDENTIFIER component identifies the algorithm
-   (such as DSA with SHA-1).  The contents of the optional parameters
-   field will vary according to the algorithm identified.
-
-   This field MUST contain the same algorithm identifier as the
-   signature field in the sequence tbsCertificate (section 4.1.2.3).
-
-4.1.1.3  signatureValue
-
-   The signatureValue field contains a digital signature computed upon
-   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
-   tbsCertificate is used as the input to the signature function.  This
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 16]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   signature value is encoded as a BIT STRING and included in the
-   signature field.  The details of this process are specified for each
-   of algorithms listed in [PKIXALGS].
-
-   By generating this signature, a CA certifies the validity of the
-   information in the tbsCertificate field.  In particular, the CA
-   certifies the binding between the public key material and the subject
-   of the certificate.
-
-4.1.2  TBSCertificate
-
-   The sequence TBSCertificate contains information associated with the
-   subject of the certificate and the CA who issued it.  Every
-   TBSCertificate contains the names of the subject and issuer, a public
-   key associated with the subject, a validity period, a version number,
-   and a serial number; some MAY contain optional unique identifier
-   fields.  The remainder of this section describes the syntax and
-   semantics of these fields.  A TBSCertificate usually includes
-   extensions.  Extensions for the Internet PKI are described in Section
-   4.2.
-
-4.1.2.1  Version
-
-   This field describes the version of the encoded certificate.  When
-   extensions are used, as expected in this profile, version MUST be 3
-   (value is 2).  If no extensions are present, but a UniqueIdentifier
-   is present, the version SHOULD be 2 (value is 1); however version MAY
-   be 3.  If only basic fields are present, the version SHOULD be 1 (the
-   value is omitted from the certificate as the default value); however
-   the version MAY be 2 or 3.
-
-   Implementations SHOULD be prepared to accept any version certificate.
-   At a minimum, conforming implementations MUST recognize version 3
-   certificates.
-
-   Generation of version 2 certificates is not expected by
-   implementations based on this profile.
-
-4.1.2.2  Serial number
-
-   The serial number MUST be a positive integer assigned by the CA to
-   each certificate.  It MUST be unique for each certificate issued by a
-   given CA (i.e., the issuer name and serial number identify a unique
-   certificate).  CAs MUST force the serialNumber to be a non-negative
-   integer.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 17]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Given the uniqueness requirements above, serial numbers can be
-   expected to contain long integers.  Certificate users MUST be able to
-   handle serialNumber values up to 20 octets.  Conformant CAs MUST NOT
-   use serialNumber values longer than 20 octets.
-
-   Note: Non-conforming CAs may issue certificates with serial numbers
-   that are negative, or zero.  Certificate users SHOULD be prepared to
-   gracefully handle such certificates.
-
-4.1.2.3  Signature
-
-   This field contains the algorithm identifier for the algorithm used
-   by the CA to sign the certificate.
-
-   This field MUST contain the same algorithm identifier as the
-   signatureAlgorithm field in the sequence Certificate (section
-   4.1.1.2).  The contents of the optional parameters field will vary
-   according to the algorithm identified.  [PKIXALGS] lists the
-   supported signature algorithms, but other signature algorithms MAY
-   also be supported.
-
-4.1.2.4  Issuer
-
-   The issuer field identifies the entity who has signed and issued the
-   certificate.  The issuer field MUST contain a non-empty distinguished
-   name (DN).  The issuer field is defined as the X.501 type Name
-   [X.501].  Name is defined by the following ASN.1 structures:
-
-   Name ::= CHOICE {
-     RDNSequence }
-
-   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-   RelativeDistinguishedName ::=
-     SET OF AttributeTypeAndValue
-
-   AttributeTypeAndValue ::= SEQUENCE {
-     type     AttributeType,
-     value    AttributeValue }
-
-   AttributeType ::= OBJECT IDENTIFIER
-
-   AttributeValue ::= ANY DEFINED BY AttributeType
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 18]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   DirectoryString ::= CHOICE {
-         teletexString           TeletexString (SIZE (1..MAX)),
-         printableString         PrintableString (SIZE (1..MAX)),
-         universalString         UniversalString (SIZE (1..MAX)),
-         utf8String              UTF8String (SIZE (1..MAX)),
-         bmpString               BMPString (SIZE (1..MAX)) }
-
-   The Name describes a hierarchical name composed of attributes, such
-   as country name, and corresponding values, such as US.  The type of
-   the component AttributeValue is determined by the AttributeType; in
-   general it will be a DirectoryString.
-
-   The DirectoryString type is defined as a choice of PrintableString,
-   TeletexString, BMPString, UTF8String, and UniversalString.  The
-   UTF8String encoding [RFC 2279] is the preferred encoding, and all
-   certificates issued after December 31, 2003 MUST use the UTF8String
-   encoding of DirectoryString (except as noted below).  Until that
-   date, conforming CAs MUST choose from the following options when
-   creating a distinguished name, including their own:
-
-      (a)  if the character set is sufficient, the string MAY be
-      represented as a PrintableString;
-
-      (b)  failing (a), if the BMPString character set is sufficient the
-      string MAY be represented as a BMPString; and
-
-      (c)  failing (a) and (b), the string MUST be represented as a
-      UTF8String.  If (a) or (b) is satisfied, the CA MAY still choose
-      to represent the string as a UTF8String.
-
-   Exceptions to the December 31, 2003 UTF8 encoding requirements are as
-   follows:
-
-      (a)  CAs MAY issue "name rollover" certificates to support an
-      orderly migration to UTF8String encoding.  Such certificates would
-      include the CA's UTF8String encoded name as issuer and and the old
-      name encoding as subject, or vice-versa.
-
-      (b)  As stated in section 4.1.2.6, the subject field MUST be
-      populated with a non-empty distinguished name matching the
-      contents of the issuer field in all certificates issued by the
-      subject CA regardless of encoding.
-
-   The TeletexString and UniversalString are included for backward
-   compatibility, and SHOULD NOT be used for certificates for new
-   subjects.  However, these types MAY be used in certificates where the
-   name was previously established.  Certificate users SHOULD be
-   prepared to receive certificates with these types.
-
-
-
-Housley, et. al.            Standards Track                    [Page 19]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   In addition, many legacy implementations support names encoded in the
-   ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as
-   TeletexString.  TeletexString encodes a larger character set than ISO
-   8859-1, but it encodes some characters differently.  Implementations
-   SHOULD be prepared to handle both encodings.
-
-   As noted above, distinguished names are composed of attributes.  This
-   specification does not restrict the set of attribute types that may
-   appear in names.  However, conforming implementations MUST be
-   prepared to receive certificates with issuer names containing the set
-   of attribute types defined below.  This specification RECOMMENDS
-   support for additional attribute types.
-
-   Standard sets of attributes have been defined in the X.500 series of
-   specifications [X.520].  Implementations of this specification MUST
-   be prepared to receive the following standard attribute types in
-   issuer and subject (section 4.1.2.6) names:
-
-      * country,
-      * organization,
-      * organizational-unit,
-      * distinguished name qualifier,
-      * state or province name,
-      * common name (e.g., "Susan Housley"), and
-      * serial number.
-
-   In addition, implementations of this specification SHOULD be prepared
-   to receive the following standard attribute types in issuer and
-   subject names:
-
-      * locality,
-      * title,
-      * surname,
-      * given name,
-      * initials,
-      * pseudonym, and
-      * generation qualifier (e.g., "Jr.", "3rd", or "IV").
-
-   The syntax and associated object identifiers (OIDs) for these
-   attribute types are provided in the ASN.1 modules in Appendix A.
-
-   In addition, implementations of this specification MUST be prepared
-   to receive the domainComponent attribute, as defined in [RFC 2247].
-   The Domain Name System (DNS) provides a hierarchical resource
-   labeling system.  This attribute provides a convenient mechanism for
-   organizations that wish to use DNs that parallel their DNS names.
-   This is not a replacement for the dNSName component of the
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 20]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   alternative name field.  Implementations are not required to convert
-   such names into DNS names.  The syntax and associated OID for this
-   attribute type is provided in the ASN.1 modules in Appendix A.
-
-   Certificate users MUST be prepared to process the issuer
-   distinguished name and subject distinguished name (section 4.1.2.6)
-   fields to perform name chaining for certification path validation
-   (section 6).  Name chaining is performed by matching the issuer
-   distinguished name in one certificate with the subject name in a CA
-   certificate.
-
-   This specification requires only a subset of the name comparison
-   functionality specified in the X.500 series of specifications.
-   Conforming implementations are REQUIRED to implement the following
-   name comparison rules:
-
-      (a)  attribute values encoded in different types (e.g.,
-      PrintableString and BMPString) MAY be assumed to represent
-      different strings;
-
-      (b) attribute values in types other than PrintableString are case
-      sensitive (this permits matching of attribute values as binary
-      objects);
-
-      (c)  attribute values in PrintableString are not case sensitive
-      (e.g., "Marianne Swanson" is the same as "MARIANNE SWANSON"); and
-
-      (d)  attribute values in PrintableString are compared after
-      removing leading and trailing white space and converting internal
-      substrings of one or more consecutive white space characters to a
-      single space.
-
-   These name comparison rules permit a certificate user to validate
-   certificates issued using languages or encodings unfamiliar to the
-   certificate user.
-
-   In addition, implementations of this specification MAY use these
-   comparison rules to process unfamiliar attribute types for name
-   chaining.  This allows implementations to process certificates with
-   unfamiliar attributes in the issuer name.
-
-   Note that the comparison rules defined in the X.500 series of
-   specifications indicate that the character sets used to encode data
-   in distinguished names are irrelevant.  The characters themselves are
-   compared without regard to encoding.  Implementations of this profile
-   are permitted to use the comparison algorithm defined in the X.500
-   series.  Such an implementation will recognize a superset of name
-   matches recognized by the algorithm specified above.
-
-
-
-Housley, et. al.            Standards Track                    [Page 21]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.1.2.5  Validity
-
-   The certificate validity period is the time interval during which the
-   CA warrants that it will maintain information about the status of the
-   certificate.  The field is represented as a SEQUENCE of two dates:
-   the date on which the certificate validity period begins (notBefore)
-   and the date on which the certificate validity period ends
-   (notAfter).  Both notBefore and notAfter may be encoded as UTCTime or
-   GeneralizedTime.
-
-   CAs conforming to this profile MUST always encode certificate
-   validity dates through the year 2049 as UTCTime; certificate validity
-   dates in 2050 or later MUST be encoded as GeneralizedTime.
-
-   The validity period for a certificate is the period of time from
-   notBefore through notAfter, inclusive.
-
-4.1.2.5.1  UTCTime
-
-   The universal time type, UTCTime, is a standard ASN.1 type intended
-   for representation of dates and time.  UTCTime specifies the year
-   through the two low order digits and time is specified to the
-   precision of one minute or one second.  UTCTime includes either Z
-   (for Zulu, or Greenwich Mean Time) or a time differential.
-
-   For the purposes of this profile, UTCTime values MUST be expressed
-   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
-   YYMMDDHHMMSSZ), even where the number of seconds is zero.  Conforming
-   systems MUST interpret the year field (YY) as follows:
-
-      Where YY is greater than or equal to 50, the year SHALL be
-      interpreted as 19YY; and
-
-      Where YY is less than 50, the year SHALL be interpreted as 20YY.
-
-4.1.2.5.2  GeneralizedTime
-
-   The generalized time type, GeneralizedTime, is a standard ASN.1 type
-   for variable precision representation of time.  Optionally, the
-   GeneralizedTime field can include a representation of the time
-   differential between local and Greenwich Mean Time.
-
-   For the purposes of this profile, GeneralizedTime values MUST be
-   expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e.,
-   times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
-   GeneralizedTime values MUST NOT include fractional seconds.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 22]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.1.2.6  Subject
-
-   The subject field identifies the entity associated with the public
-   key stored in the subject public key field.  The subject name MAY be
-   carried in the subject field and/or the subjectAltName extension.  If
-   the subject is a CA (e.g., the basic constraints extension, as
-   discussed in 4.2.1.10, is present and the value of cA is TRUE), then
-   the subject field MUST be populated with a non-empty distinguished
-   name matching the contents of the issuer field (section 4.1.2.4) in
-   all certificates issued by the subject CA.  If the subject is a CRL
-   issuer (e.g., the key usage extension, as discussed in 4.2.1.3, is
-   present and the value of cRLSign is TRUE) then the subject field MUST
-   be populated with a non-empty distinguished name matching the
-   contents of the issuer field (section 4.1.2.4) in all CRLs issued by
-   the subject CRL issuer.  If subject naming information is present
-   only in the subjectAltName extension (e.g., a key bound only to an
-   email address or URI), then the subject name MUST be an empty
-   sequence and the subjectAltName extension MUST be critical.
-
-   Where it is non-empty, the subject field MUST contain an X.500
-   distinguished name (DN).  The DN MUST be unique for each subject
-   entity certified by the one CA as defined by the issuer name field.
-   A CA MAY issue more than one certificate with the same DN to the same
-   subject entity.
-
-   The subject name field is defined as the X.501 type Name.
-   Implementation requirements for this field are those defined for the
-   issuer field (section 4.1.2.4).  When encoding attribute values of
-   type DirectoryString, the encoding rules for the issuer field MUST be
-   implemented.  Implementations of this specification MUST be prepared
-   to receive subject names containing the attribute types required for
-   the issuer field.  Implementations of this specification SHOULD be
-   prepared to receive subject names containing the recommended
-   attribute types for the issuer field.  The syntax and associated
-   object identifiers (OIDs) for these attribute types are provided in
-   the ASN.1 modules in Appendix A.  Implementations of this
-   specification MAY use these comparison rules to process unfamiliar
-   attribute types (i.e., for name chaining).  This allows
-   implementations to process certificates with unfamiliar attributes in
-   the subject name.
-
-   In addition, legacy implementations exist where an RFC 822 name is
-   embedded in the subject distinguished name as an EmailAddress
-   attribute.  The attribute value for EmailAddress is of type IA5String
-   to permit inclusion of the character '@', which is not part of the
-   PrintableString character set.  EmailAddress attribute values are not
-   case sensitive (e.g., "fanfeedback@redsox.com" is the same as
-   "FANFEEDBACK@REDSOX.COM").
-
-
-
-Housley, et. al.            Standards Track                    [Page 23]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Conforming implementations generating new certificates with
-   electronic mail addresses MUST use the rfc822Name in the subject
-   alternative name field (section 4.2.1.7) to describe such identities.
-   Simultaneous inclusion of the EmailAddress attribute in the subject
-   distinguished name to support legacy implementations is deprecated
-   but permitted.
-
-4.1.2.7  Subject Public Key Info
-
-   This field is used to carry the public key and identify the algorithm
-   with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
-   algorithm is identified using the AlgorithmIdentifier structure
-   specified in section 4.1.1.2.  The object identifiers for the
-   supported algorithms and the methods for encoding the public key
-   materials (public key and parameters) are specified in [PKIXALGS].
-
-4.1.2.8  Unique Identifiers
-
-   These fields MUST only appear if the version is 2 or 3 (section
-   4.1.2.1).  These fields MUST NOT appear if the version is 1.  The
-   subject and issuer unique identifiers are present in the certificate
-   to handle the possibility of reuse of subject and/or issuer names
-   over time.  This profile RECOMMENDS that names not be reused for
-   different entities and that Internet certificates not make use of
-   unique identifiers.  CAs conforming to this profile SHOULD NOT
-   generate certificates with unique identifiers.  Applications
-   conforming to this profile SHOULD be capable of parsing unique
-   identifiers.
-
-4.1.2.9  Extensions
-
-   This field MUST only appear if the version is 3 (section 4.1.2.1).
-   If present, this field is a SEQUENCE of one or more certificate
-   extensions.  The format and content of certificate extensions in the
-   Internet PKI is defined in section 4.2.
-
-4.2  Certificate Extensions
-
-   The extensions defined for X.509 v3 certificates provide methods for
-   associating additional attributes with users or public keys and for
-   managing a certification hierarchy.  The X.509 v3 certificate format
-   also allows communities to define private extensions to carry
-   information unique to those communities.  Each extension in a
-   certificate is designated as either critical or non-critical.  A
-   certificate using system MUST reject the certificate if it encounters
-   a critical extension it does not recognize; however, a non-critical
-   extension MAY be ignored if it is not recognized.  The following
-   sections present recommended extensions used within Internet
-
-
-
-Housley, et. al.            Standards Track                    [Page 24]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificates and standard locations for information.  Communities may
-   elect to use additional extensions; however, caution ought to be
-   exercised in adopting any critical extensions in certificates which
-   might prevent use in a general context.
-
-   Each extension includes an OID and an ASN.1 structure.  When an
-   extension appears in a certificate, the OID appears as the field
-   extnID and the corresponding ASN.1 encoded structure is the value of
-   the octet string extnValue.  A certificate MUST NOT include more than
-   one instance of a particular extension.  For example, a certificate
-   may contain only one authority key identifier extension (section
-   4.2.1.1).  An extension includes the boolean critical, with a default
-   value of FALSE.  The text for each extension specifies the acceptable
-   values for the critical field.
-
-   Conforming CAs MUST support key identifiers (sections 4.2.1.1 and
-   4.2.1.2), basic constraints (section 4.2.1.10), key usage (section
-   4.2.1.3), and certificate policies (section 4.2.1.5) extensions.  If
-   the CA issues certificates with an empty sequence for the subject
-   field, the CA MUST support the subject alternative name extension
-   (section 4.2.1.7).  Support for the remaining extensions is OPTIONAL.
-   Conforming CAs MAY support extensions that are not identified within
-   this specification; certificate issuers are cautioned that marking
-   such extensions as critical may inhibit interoperability.
-
-   At a minimum, applications conforming to this profile MUST recognize
-   the following extensions: key usage (section 4.2.1.3), certificate
-   policies (section 4.2.1.5), the subject alternative name (section
-   4.2.1.7), basic constraints (section 4.2.1.10), name constraints
-   (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
-   key usage (section 4.2.1.13), and inhibit any-policy (section
-   4.2.1.15).
-
-   In addition, applications conforming to this profile SHOULD recognize
-   the authority and subject key identifier (sections 4.2.1.1 and
-   4.2.1.2), and policy mapping (section 4.2.1.6) extensions.
-
-4.2.1  Standard Extensions
-
-   This section identifies standard certificate extensions defined in
-   [X.509] for use in the Internet PKI.  Each extension is associated
-   with an OID defined in [X.509].  These OIDs are members of the id-ce
-   arc, which is defined by the following:
-
-   id-ce   OBJECT IDENTIFIER ::=  { joint-iso-ccitt(2) ds(5) 29 }
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 25]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.1  Authority Key Identifier
-
-   The authority key identifier extension provides a means of
-   identifying the public key corresponding to the private key used to
-   sign a certificate.  This extension is used where an issuer has
-   multiple signing keys (either due to multiple concurrent key pairs or
-   due to changeover).  The identification MAY be based on either the
-   key identifier (the subject key identifier in the issuer's
-   certificate) or on the issuer name and serial number.
-
-   The keyIdentifier field of the authorityKeyIdentifier extension MUST
-   be included in all certificates generated by conforming CAs to
-   facilitate certification path construction.  There is one exception;
-   where a CA distributes its public key in the form of a "self-signed"
-   certificate, the authority key identifier MAY be omitted.  The
-   signature on a self-signed certificate is generated with the private
-   key associated with the certificate's subject public key.  (This
-   proves that the issuer possesses both the public and private keys.)
-   In this case, the subject and authority key identifiers would be
-   identical, but only the subject key identifier is needed for
-   certification path building.
-
-   The value of the keyIdentifier field SHOULD be derived from the
-   public key used to verify the certificate's signature or a method
-   that generates unique values.  Two common methods for generating key
-   identifiers from the public key, and one common method for generating
-   unique values, are described in section 4.2.1.2.  Where a key
-   identifier has not been previously established, this specification
-   RECOMMENDS use of one of these methods for generating keyIdentifiers.
-   Where a key identifier has been previously established, the CA SHOULD
-   use the previously established identifier.
-
-   This profile RECOMMENDS support for the key identifier method by all
-   certificate users.
-
-   This extension MUST NOT be marked critical.
-
-   id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
-
-   AuthorityKeyIdentifier ::= SEQUENCE {
-      keyIdentifier             [0] KeyIdentifier           OPTIONAL,
-      authorityCertIssuer       [1] GeneralNames            OPTIONAL,
-      authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL  }
-
-   KeyIdentifier ::= OCTET STRING
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 26]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.2  Subject Key Identifier
-
-   The subject key identifier extension provides a means of identifying
-   certificates that contain a particular public key.
-
-   To facilitate certification path construction, this extension MUST
-   appear in all conforming CA certificates, that is, all certificates
-   including the basic constraints extension (section 4.2.1.10) where
-   the value of cA is TRUE.  The value of the subject key identifier
-   MUST be the value placed in the key identifier field of the Authority
-   Key Identifier extension (section 4.2.1.1) of certificates issued by
-   the subject of this certificate.
-
-   For CA certificates, subject key identifiers SHOULD be derived from
-   the public key or a method that generates unique values.  Two common
-   methods for generating key identifiers from the public key are:
-
-      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
-      value of the BIT STRING subjectPublicKey (excluding the tag,
-      length, and number of unused bits).
-
-      (2) The keyIdentifier is composed of a four bit type field with
-      the value 0100 followed by the least significant 60 bits of the
-      SHA-1 hash of the value of the BIT STRING subjectPublicKey
-      (excluding the tag, length, and number of unused bit string bits).
-
-   One common method for generating unique values is a monotonically
-   increasing sequence of integers.
-
-   For end entity certificates, the subject key identifier extension
-   provides a means for identifying certificates containing the
-   particular public key used in an application.  Where an end entity
-   has obtained multiple certificates, especially from multiple CAs, the
-   subject key identifier provides a means to quickly identify the set
-   of certificates containing a particular public key.  To assist
-   applications in identifying the appropriate end entity certificate,
-   this extension SHOULD be included in all end entity certificates.
-
-   For end entity certificates, subject key identifiers SHOULD be
-   derived from the public key.  Two common methods for generating key
-   identifiers from the public key are identified above.
-
-   Where a key identifier has not been previously established, this
-   specification RECOMMENDS use of one of these methods for generating
-   keyIdentifiers.  Where a key identifier has been previously
-   established, the CA SHOULD use the previously established identifier.
-
-   This extension MUST NOT be marked critical.
-
-
-
-Housley, et. al.            Standards Track                    [Page 27]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
-
-   SubjectKeyIdentifier ::= KeyIdentifier
-
-4.2.1.3  Key Usage
-
-   The key usage extension defines the purpose (e.g., encipherment,
-   signature, certificate signing) of the key contained in the
-   certificate.  The usage restriction might be employed when a key that
-   could be used for more than one operation is to be restricted.  For
-   example, when an RSA key should be used only to verify signatures on
-   objects other than public key certificates and CRLs, the
-   digitalSignature and/or nonRepudiation bits would be asserted.
-   Likewise, when an RSA key should be used only for key management, the
-   keyEncipherment bit would be asserted.
-
-   This extension MUST appear in certificates that contain public keys
-   that are used to validate digital signatures on other public key
-   certificates or CRLs.  When this extension appears, it SHOULD be
-   marked critical.
-
-      id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
-
-      KeyUsage ::= BIT STRING {
-           digitalSignature        (0),
-           nonRepudiation          (1),
-           keyEncipherment         (2),
-           dataEncipherment        (3),
-           keyAgreement            (4),
-           keyCertSign             (5),
-           cRLSign                 (6),
-           encipherOnly            (7),
-           decipherOnly            (8) }
-
-   Bits in the KeyUsage type are used as follows:
-
-      The digitalSignature bit is asserted when the subject public key
-      is used with a digital signature mechanism to support security
-      services other than certificate signing (bit 5), or CRL signing
-      (bit 6).  Digital signature mechanisms are often used for entity
-      authentication and data origin authentication with integrity.
-
-      The nonRepudiation bit is asserted when the subject public key is
-      used to verify digital signatures used to provide a non-
-      repudiation service which protects against the signing entity
-      falsely denying some action, excluding certificate or CRL signing.
-      In the case of later conflict, a reliable third party may
-      determine the authenticity of the signed data.
-
-
-
-Housley, et. al.            Standards Track                    [Page 28]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      Further distinctions between the digitalSignature and
-      nonRepudiation bits may be provided in specific certificate
-      policies.
-
-      The keyEncipherment bit is asserted when the subject public key is
-      used for key transport.  For example, when an RSA key is to be
-      used for key management, then this bit is set.
-
-      The dataEncipherment bit is asserted when the subject public key
-      is used for enciphering user data, other than cryptographic keys.
-
-      The keyAgreement bit is asserted when the subject public key is
-      used for key agreement.  For example, when a Diffie-Hellman key is
-      to be used for key management, then this bit is set.
-
-      The keyCertSign bit is asserted when the subject public key is
-      used for verifying a signature on public key certificates.  If the
-      keyCertSign bit is asserted, then the cA bit in the basic
-      constraints extension (section 4.2.1.10) MUST also be asserted.
-
-      The cRLSign bit is asserted when the subject public key is used
-      for verifying a signature on certificate revocation list (e.g., a
-      CRL, delta CRL, or an ARL).  This bit MUST be asserted in
-      certificates that are used to verify signatures on CRLs.
-
-      The meaning of the encipherOnly bit is undefined in the absence of
-      the keyAgreement bit.  When the encipherOnly bit is asserted and
-      the keyAgreement bit is also set, the subject public key may be
-      used only for enciphering data while performing key agreement.
-
-      The meaning of the decipherOnly bit is undefined in the absence of
-      the keyAgreement bit.  When the decipherOnly bit is asserted and
-      the keyAgreement bit is also set, the subject public key may be
-      used only for deciphering data while performing key agreement.
-
-   This profile does not restrict the combinations of bits that may be
-   set in an instantiation of the keyUsage extension.  However,
-   appropriate values for keyUsage extensions for particular algorithms
-   are specified in [PKIXALGS].
-
-4.2.1.4  Private Key Usage Period
-
-   This extension SHOULD NOT be used within the Internet PKI.  CAs
-   conforming to this profile MUST NOT generate certificates that
-   include a critical private key usage period extension.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 29]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The private key usage period extension allows the certificate issuer
-   to specify a different validity period for the private key than the
-   certificate.  This extension is intended for use with digital
-   signature keys.  This extension consists of two optional components,
-   notBefore and notAfter.  The private key associated with the
-   certificate SHOULD NOT be used to sign objects before or after the
-   times specified by the two components, respectively.  CAs conforming
-   to this profile MUST NOT generate certificates with private key usage
-   period extensions unless at least one of the two components is
-   present and the extension is non-critical.
-
-   Where used, notBefore and notAfter are represented as GeneralizedTime
-   and MUST be specified and interpreted as defined in section
-   4.1.2.5.2.
-
-   id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }
-
-   PrivateKeyUsagePeriod ::= SEQUENCE {
-        notBefore       [0]     GeneralizedTime OPTIONAL,
-        notAfter        [1]     GeneralizedTime OPTIONAL }
-
-4.2.1.5  Certificate Policies
-
-   The certificate policies extension contains a sequence of one or more
-   policy information terms, each of which consists of an object
-   identifier (OID) and optional qualifiers.  Optional qualifiers, which
-   MAY be present, are not expected to change the definition of the
-   policy.
-
-   In an end entity certificate, these policy information terms indicate
-   the policy under which the certificate has been issued and the
-   purposes for which the certificate may be used.  In a CA certificate,
-   these policy information terms limit the set of policies for
-   certification paths which include this certificate.  When a CA does
-   not wish to limit the set of policies for certification paths which
-   include this certificate, it MAY assert the special policy anyPolicy,
-   with a value of { 2 5 29 32 0 }.
-
-   Applications with specific policy requirements are expected to have a
-   list of those policies which they will accept and to compare the
-   policy OIDs in the certificate to that list.  If this extension is
-   critical, the path validation software MUST be able to interpret this
-   extension (including the optional qualifier), or MUST reject the
-   certificate.
-
-   To promote interoperability, this profile RECOMMENDS that policy
-   information terms consist of only an OID.  Where an OID alone is
-   insufficient, this profile strongly recommends that use of qualifiers
-
-
-
-Housley, et. al.            Standards Track                    [Page 30]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   be limited to those identified in this section.  When qualifiers are
-   used with the special policy anyPolicy, they MUST be limited to the
-   qualifiers identified in this section.
-
-   This specification defines two policy qualifier types for use by
-   certificate policy writers and certificate issuers.  The qualifier
-   types are the CPS Pointer and User Notice qualifiers.
-
-   The CPS Pointer qualifier contains a pointer to a Certification
-   Practice Statement (CPS) published by the CA.  The pointer is in the
-   form of a URI.  Processing requirements for this qualifier are a
-   local matter.  No action is mandated by this specification regardless
-   of the criticality value asserted for the extension.
-
-   User notice is intended for display to a relying party when a
-   certificate is used.  The application software SHOULD display all
-   user notices in all certificates of the certification path used,
-   except that if a notice is duplicated only one copy need be
-   displayed.  To prevent such duplication, this qualifier SHOULD only
-   be present in end entity certificates and CA certificates issued to
-   other organizations.
-
-   The user notice has two optional fields: the noticeRef field and the
-   explicitText field.
-
-      The noticeRef field, if used, names an organization and
-      identifies, by number, a particular textual statement prepared by
-      that organization.  For example, it might identify the
-      organization "CertsRUs" and notice number 1.  In a typical
-      implementation, the application software will have a notice file
-      containing the current set of notices for CertsRUs; the
-      application will extract the notice text from the file and display
-      it.  Messages MAY be multilingual, allowing the software to select
-      the particular language message for its own environment.
-
-      An explicitText field includes the textual statement directly in
-      the certificate.  The explicitText field is a string with a
-      maximum size of 200 characters.
-
-   If both the noticeRef and explicitText options are included in the
-   one qualifier and if the application software can locate the notice
-   text indicated by the noticeRef option, then that text SHOULD be
-   displayed; otherwise, the explicitText string SHOULD be displayed.
-
-   Note: While the explicitText has a maximum size of 200 characters,
-   some non-conforming CAs exceed this limit.  Therefore, certificate
-   users SHOULD gracefully handle explicitText with more than 200
-   characters.
-
-
-
-Housley, et. al.            Standards Track                    [Page 31]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
-
-   anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }
-
-   certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
-
-   PolicyInformation ::= SEQUENCE {
-        policyIdentifier   CertPolicyId,
-        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
-                                PolicyQualifierInfo OPTIONAL }
-
-   CertPolicyId ::= OBJECT IDENTIFIER
-
-   PolicyQualifierInfo ::= SEQUENCE {
-        policyQualifierId  PolicyQualifierId,
-        qualifier          ANY DEFINED BY policyQualifierId }
-
-   -- policyQualifierIds for Internet policy qualifiers
-
-   id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
-   id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
-   id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
-
-   PolicyQualifierId ::=
-        OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
-
-   Qualifier ::= CHOICE {
-        cPSuri           CPSuri,
-        userNotice       UserNotice }
-
-   CPSuri ::= IA5String
-
-   UserNotice ::= SEQUENCE {
-        noticeRef        NoticeReference OPTIONAL,
-        explicitText     DisplayText OPTIONAL}
-
-   NoticeReference ::= SEQUENCE {
-        organization     DisplayText,
-        noticeNumbers    SEQUENCE OF INTEGER }
-
-   DisplayText ::= CHOICE {
-        ia5String        IA5String      (SIZE (1..200)),
-        visibleString    VisibleString  (SIZE (1..200)),
-        bmpString        BMPString      (SIZE (1..200)),
-        utf8String       UTF8String     (SIZE (1..200)) }
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 32]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.6  Policy Mappings
-
-   This extension is used in CA certificates.  It lists one or more
-   pairs of OIDs; each pair includes an issuerDomainPolicy and a
-   subjectDomainPolicy.  The pairing indicates the issuing CA considers
-   its issuerDomainPolicy equivalent to the subject CA's
-   subjectDomainPolicy.
-
-   The issuing CA's users might accept an issuerDomainPolicy for certain
-   applications.  The policy mapping defines the list of policies
-   associated with the subject CA that may be accepted as comparable to
-   the issuerDomainPolicy.
-
-   Each issuerDomainPolicy named in the policy mapping extension SHOULD
-   also be asserted in a certificate policies extension in the same
-   certificate.  Policies SHOULD NOT be mapped either to or from the
-   special value anyPolicy (section 4.2.1.5).
-
-   This extension MAY be supported by CAs and/or applications, and it
-   MUST be non-critical.
-
-   id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
-
-   PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-        issuerDomainPolicy      CertPolicyId,
-        subjectDomainPolicy     CertPolicyId }
-
-4.2.1.7  Subject Alternative Name
-
-   The subject alternative names extension allows additional identities
-   to be bound to the subject of the certificate.  Defined options
-   include an Internet electronic mail address, a DNS name, an IP
-   address, and a uniform resource identifier (URI).  Other options
-   exist, including completely local definitions.  Multiple name forms,
-   and multiple instances of each name form, MAY be included.  Whenever
-   such identities are to be bound into a certificate, the subject
-   alternative name (or issuer alternative name) extension MUST be used;
-   however, a DNS name MAY be represented in the subject field using the
-   domainComponent attribute as described in section 4.1.2.4.
-
-   Because the subject alternative name is considered to be definitively
-   bound to the public key, all parts of the subject alternative name
-   MUST be verified by the CA.
-
-   Further, if the only subject identity included in the certificate is
-   an alternative name form (e.g., an electronic mail address), then the
-   subject distinguished name MUST be empty (an empty sequence), and the
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 33]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   subjectAltName extension MUST be present.  If the subject field
-   contains an empty sequence, the subjectAltName extension MUST be
-   marked critical.
-
-   When the subjectAltName extension contains an Internet mail address,
-   the address MUST be included as an rfc822Name.  The format of an
-   rfc822Name is an "addr-spec" as defined in RFC 822 [RFC 822].  An
-   addr-spec has the form "local-part@domain".  Note that an addr-spec
-   has no phrase (such as a common name) before it, has no comment (text
-   surrounded in parentheses) after it, and is not surrounded by "<" and
-   ">".  Note that while upper and lower case letters are allowed in an
-   RFC 822 addr-spec, no significance is attached to the case.
-
-   When the subjectAltName extension contains a iPAddress, the address
-   MUST be stored in the octet string in "network byte order," as
-   specified in RFC 791 [RFC 791].  The least significant bit (LSB) of
-   each octet is the LSB of the corresponding byte in the network
-   address.  For IP Version 4, as specified in RFC 791, the octet string
-   MUST contain exactly four octets.  For IP Version 6, as specified in
-   RFC 1883, the octet string MUST contain exactly sixteen octets [RFC
-   1883].
-
-   When the subjectAltName extension contains a domain name system
-   label, the domain name MUST be stored in the dNSName (an IA5String).
-   The name MUST be in the "preferred name syntax," as specified by RFC
-   1034 [RFC 1034].  Note that while upper and lower case letters are
-   allowed in domain names, no signifigance is attached to the case.  In
-   addition, while the string " " is a legal domain name, subjectAltName
-   extensions with a dNSName of " " MUST NOT be used.  Finally, the use
-   of the DNS representation for Internet mail addresses (wpolk.nist.gov
-   instead of wpolk@nist.gov) MUST NOT be used; such identities are to
-   be encoded as rfc822Name.
-
-   Note: work is currently underway to specify domain names in
-   international character sets.  Such names will likely not be
-   accommodated by IA5String.  Once this work is complete, this profile
-   will be revisited and the appropriate functionality will be added.
-
-   When the subjectAltName extension contains a URI, the name MUST be
-   stored in the uniformResourceIdentifier (an IA5String).  The name
-   MUST NOT be a relative URL, and it MUST follow the URL syntax and
-   encoding rules specified in [RFC 1738].  The name MUST include both a
-   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
-   scheme-specific-part MUST include a fully qualified domain name or IP
-   address as the host.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 34]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   As specified in [RFC 1738], the scheme name is not case-sensitive
-   (e.g., "http" is equivalent to "HTTP").  The host part is also not
-   case-sensitive, but other components of the scheme-specific-part may
-   be case-sensitive.  When comparing URIs, conforming implementations
-   MUST compare the scheme and host without regard to case, but assume
-   the remainder of the scheme-specific-part is case sensitive.
-
-   When the subjectAltName extension contains a DN in the directoryName,
-   the DN MUST be unique for each subject entity certified by the one CA
-   as defined by the issuer name field.  A CA MAY issue more than one
-   certificate with the same DN to the same subject entity.
-
-   The subjectAltName MAY carry additional name types through the use of
-   the otherName field.  The format and semantics of the name are
-   indicated through the OBJECT IDENTIFIER in the type-id field.  The
-   name itself is conveyed as value field in otherName.  For example,
-   Kerberos [RFC 1510] format names can be encoded into the otherName,
-   using using a Kerberos 5 principal name OID and a SEQUENCE of the
-   Realm and the PrincipalName.
-
-   Subject alternative names MAY be constrained in the same manner as
-   subject distinguished names using the name constraints extension as
-   described in section 4.2.1.11.
-
-   If the subjectAltName extension is present, the sequence MUST contain
-   at least one entry.  Unlike the subject field, conforming CAs MUST
-   NOT issue certificates with subjectAltNames containing empty
-   GeneralName fields.  For example, an rfc822Name is represented as an
-   IA5String.  While an empty string is a valid IA5String, such an
-   rfc822Name is not permitted by this profile.  The behavior of clients
-   that encounter such a certificate when processing a certificication
-   path is not defined by this profile.
-
-   Finally, the semantics of subject alternative names that include
-   wildcard characters (e.g., as a placeholder for a set of names) are
-   not addressed by this specification.  Applications with specific
-   requirements MAY use such names, but they must define the semantics.
-
-   id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
-
-   SubjectAltName ::= GeneralNames
-
-   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 35]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   GeneralName ::= CHOICE {
-        otherName                       [0]     OtherName,
-        rfc822Name                      [1]     IA5String,
-        dNSName                         [2]     IA5String,
-        x400Address                     [3]     ORAddress,
-        directoryName                   [4]     Name,
-        ediPartyName                    [5]     EDIPartyName,
-        uniformResourceIdentifier       [6]     IA5String,
-        iPAddress                       [7]     OCTET STRING,
-        registeredID                    [8]     OBJECT IDENTIFIER }
-
-   OtherName ::= SEQUENCE {
-        type-id    OBJECT IDENTIFIER,
-        value      [0] EXPLICIT ANY DEFINED BY type-id }
-
-   EDIPartyName ::= SEQUENCE {
-        nameAssigner            [0]     DirectoryString OPTIONAL,
-        partyName               [1]     DirectoryString }
-
-4.2.1.8  Issuer Alternative Names
-
-   As with 4.2.1.7, this extension is used to associate Internet style
-   identities with the certificate issuer.  Issuer alternative names
-   MUST be encoded as in 4.2.1.7.
-
-   Where present, this extension SHOULD NOT be marked critical.
-
-   id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
-
-   IssuerAltName ::= GeneralNames
-
-4.2.1.9  Subject Directory Attributes
-
-   The subject directory attributes extension is used to convey
-   identification attributes (e.g., nationality) of the subject.  The
-   extension is defined as a sequence of one or more attributes.  This
-   extension MUST be non-critical.
-
-   id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
-
-   SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
-
-4.2.1.10  Basic Constraints
-
-   The basic constraints extension identifies whether the subject of the
-   certificate is a CA and the maximum depth of valid certification
-   paths that include this certificate.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 36]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The cA boolean indicates whether the certified public key belongs to
-   a CA.  If the cA boolean is not asserted, then the keyCertSign bit in
-   the key usage extension MUST NOT be asserted.
-
-   The pathLenConstraint field is meaningful only if the cA boolean is
-   asserted and the key usage extension asserts the keyCertSign bit
-   (section 4.2.1.3).  In this case, it gives the maximum number of non-
-   self-issued intermediate certificates that may follow this
-   certificate in a valid certification path.  A certificate is self-
-   issued if the DNs that appear in the subject and issuer fields are
-   identical and are not empty.  (Note: The last certificate in the
-   certification path is not an intermediate certificate, and is not
-   included in this limit.  Usually, the last certificate is an end
-   entity certificate, but it can be a CA certificate.)  A
-   pathLenConstraint of zero indicates that only one more certificate
-   may follow in a valid certification path.  Where it appears, the
-   pathLenConstraint field MUST be greater than or equal to zero.  Where
-   pathLenConstraint does not appear, no limit is imposed.
-
-   This extension MUST appear as a critical extension in all CA
-   certificates that contain public keys used to validate digital
-   signatures on certificates.  This extension MAY appear as a critical
-   or non-critical extension in CA certificates that contain public keys
-   used exclusively for purposes other than validating digital
-   signatures on certificates.  Such CA certificates include ones that
-   contain public keys used exclusively for validating digital
-   signatures on CRLs and ones that contain key management public keys
-   used with certificate enrollment protocols.  This extension MAY
-   appear as a critical or non-critical extension in end entity
-   certificates.
-
-   CAs MUST NOT include the pathLenConstraint field unless the cA
-   boolean is asserted and the key usage extension asserts the
-   keyCertSign bit.
-
-   id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
-
-   BasicConstraints ::= SEQUENCE {
-        cA                      BOOLEAN DEFAULT FALSE,
-        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
-
-4.2.1.11  Name Constraints
-
-   The name constraints extension, which MUST be used only in a CA
-   certificate, indicates a name space within which all subject names in
-   subsequent certificates in a certification path MUST be located.
-   Restrictions apply to the subject distinguished name and apply to
-   subject alternative names.  Restrictions apply only when the
-
-
-
-Housley, et. al.            Standards Track                    [Page 37]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   specified name form is present.  If no name of the type is in the
-   certificate, the certificate is acceptable.
-
-   Name constraints are not applied to certificates whose issuer and
-   subject are identical (unless the certificate is the final
-   certificate in the path).  (This could prevent CAs that use name
-   constraints from employing self-issued certificates to implement key
-   rollover.)
-
-   Restrictions are defined in terms of permitted or excluded name
-   subtrees.  Any name matching a restriction in the excludedSubtrees
-   field is invalid regardless of information appearing in the
-   permittedSubtrees.  This extension MUST be critical.
-
-   Within this profile, the minimum and maximum fields are not used with
-   any name forms, thus minimum MUST be zero, and maximum MUST be
-   absent.
-
-   For URIs, the constraint applies to the host part of the name.  The
-   constraint MAY specify a host or a domain.  Examples would be
-   "foo.bar.com";  and ".xyz.com".  When the the constraint begins with
-   a period, it MAY be expanded with one or more subdomains.  That is,
-   the constraint ".xyz.com" is satisfied by both abc.xyz.com and
-   abc.def.xyz.com.  However, the constraint ".xyz.com" is not satisfied
-   by "xyz.com".  When the constraint does not begin with a period, it
-   specifies a host.
-
-   A name constraint for Internet mail addresses MAY specify a
-   particular mailbox, all addresses at a particular host, or all
-   mailboxes in a domain.  To indicate a particular mailbox, the
-   constraint is the complete mail address.  For example, "root@xyz.com"
-   indicates the root mailbox on the host "xyz.com".  To indicate all
-   Internet mail addresses on a particular host, the constraint is
-   specified as the host name.  For example, the constraint "xyz.com" is
-   satisfied by any mail address at the host "xyz.com".  To specify any
-   address within a domain, the constraint is specified with a leading
-   period (as with URIs).  For example, ".xyz.com" indicates all the
-   Internet mail addresses in the domain "xyz.com", but not Internet
-   mail addresses on the host "xyz.com".
-
-   DNS name restrictions are expressed as foo.bar.com.  Any DNS name
-   that can be constructed by simply adding to the left hand side of the
-   name satisfies the name constraint.  For example, www.foo.bar.com
-   would satisfy the constraint but foo1.bar.com would not.
-
-   Legacy implementations exist where an RFC 822 name is embedded in the
-   subject distinguished name in an attribute of type EmailAddress
-   (section 4.1.2.6).  When rfc822 names are constrained, but the
-
-
-
-Housley, et. al.            Standards Track                    [Page 38]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificate does not include a subject alternative name, the rfc822
-   name constraint MUST be applied to the attribute of type EmailAddress
-   in the subject distinguished name.  The ASN.1 syntax for EmailAddress
-   and the corresponding OID are supplied in Appendix A.
-
-   Restrictions of the form directoryName MUST be applied to the subject
-   field in the certificate and to the subjectAltName extensions of type
-   directoryName.  Restrictions of the form x400Address MUST be applied
-   to subjectAltName extensions of type x400Address.
-
-   When applying restrictions of the form directoryName, an
-   implementation MUST compare DN attributes.  At a minimum,
-   implementations MUST perform the DN comparison rules specified in
-   Section 4.1.2.4.  CAs issuing certificates with a restriction of the
-   form directoryName SHOULD NOT rely on implementation of the full ISO
-   DN name comparison algorithm.  This implies name restrictions MUST be
-   stated identically to the encoding used in the subject field or
-   subjectAltName extension.
-
-   The syntax of iPAddress MUST be as described in section 4.2.1.7 with
-   the following additions specifically for Name Constraints.  For IPv4
-   addresses, the ipAddress field of generalName MUST contain eight (8)
-   octets, encoded in the style of RFC 1519 (CIDR) to represent an
-   address range [RFC 1519].  For IPv6 addresses, the ipAddress field
-   MUST contain 32 octets similarly encoded.  For example, a name
-   constraint for "class C" subnet 10.9.8.0 is represented as the octets
-   0A 09 08 00 FF FF FF 00, representing the CIDR notation
-   10.9.8.0/255.255.255.0.
-
-   The syntax and semantics for name constraints for otherName,
-   ediPartyName, and registeredID are not defined by this specification.
-
-      id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
-
-      NameConstraints ::= SEQUENCE {
-           permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
-           excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
-
-      GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
-
-      GeneralSubtree ::= SEQUENCE {
-           base                    GeneralName,
-           minimum         [0]     BaseDistance DEFAULT 0,
-           maximum         [1]     BaseDistance OPTIONAL }
-
-      BaseDistance ::= INTEGER (0..MAX)
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 39]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.1.12  Policy Constraints
-
-   The policy constraints extension can be used in certificates issued
-   to CAs.  The policy constraints extension constrains path validation
-   in two ways.  It can be used to prohibit policy mapping or require
-   that each certificate in a path contain an acceptable policy
-   identifier.
-
-   If the inhibitPolicyMapping field is present, the value indicates the
-   number of additional certificates that may appear in the path before
-   policy mapping is no longer permitted.  For example, a value of one
-   indicates that policy mapping may be processed in certificates issued
-   by the subject of this certificate, but not in additional
-   certificates in the path.
-
-   If the requireExplicitPolicy field is present, the value of
-   requireExplicitPolicy indicates the number of additional certificates
-   that may appear in the path before an explicit policy is required for
-   the entire path.  When an explicit policy is required, it is
-   necessary for all certificates in the path to contain an acceptable
-   policy identifier in the certificate policies extension.  An
-   acceptable policy identifier is the identifier of a policy required
-   by the user of the certification path or the identifier of a policy
-   which has been declared equivalent through policy mapping.
-
-   Conforming CAs MUST NOT issue certificates where policy constraints
-   is a empty sequence.  That is, at least one of the
-   inhibitPolicyMapping field or the requireExplicitPolicy field MUST be
-   present.  The behavior of clients that encounter a empty policy
-   constraints field is not addressed in this profile.
-
-   This extension MAY be critical or non-critical.
-
-   id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
-
-   PolicyConstraints ::= SEQUENCE {
-        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
-        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }
-
-   SkipCerts ::= INTEGER (0..MAX)
-
-4.2.1.13  Extended Key Usage
-
-   This extension indicates one or more purposes for which the certified
-   public key may be used, in addition to or in place of the basic
-   purposes indicated in the key usage extension.  In general, this
-   extension will appear only in end entity certificates.  This
-   extension is defined as follows:
-
-
-
-Housley, et. al.            Standards Track                    [Page 40]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
-
-   ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
-
-   KeyPurposeId ::= OBJECT IDENTIFIER
-
-   Key purposes may be defined by any organization with a need.  Object
-   identifiers used to identify key purposes MUST be assigned in
-   accordance with IANA or ITU-T Recommendation X.660 [X.660].
-
-   This extension MAY, at the option of the certificate issuer, be
-   either critical or non-critical.
-
-   If the extension is present, then the certificate MUST only be used
-   for one of the purposes indicated.  If multiple purposes are
-   indicated the application need not recognize all purposes indicated,
-   as long as the intended purpose is present.  Certificate using
-   applications MAY require that a particular purpose be indicated in
-   order for the certificate to be acceptable to that application.
-
-   If a CA includes extended key usages to satisfy such applications,
-   but does not wish to restrict usages of the key, the CA can include
-   the special keyPurposeID anyExtendedKeyUsage.  If the
-   anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
-   be critical.
-
-   If a certificate contains both a key usage extension and an extended
-   key usage extension, then both extensions MUST be processed
-   independently and the certificate MUST only be used for a purpose
-   consistent with both extensions.  If there is no purpose consistent
-   with both extensions, then the certificate MUST NOT be used for any
-   purpose.
-
-   The following key usage purposes are defined:
-
-   anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
-
-   id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-
-   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
-   -- TLS WWW server authentication
-   -- Key usage bits that may be consistent: digitalSignature,
-   -- keyEncipherment or keyAgreement
-
-   id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
-   -- TLS WWW client authentication
-   -- Key usage bits that may be consistent: digitalSignature
-   -- and/or keyAgreement
-
-
-
-Housley, et. al.            Standards Track                    [Page 41]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-kp-codeSigning             OBJECT IDENTIFIER ::= { id-kp 3 }
-   -- Signing of downloadable executable code
-   -- Key usage bits that may be consistent: digitalSignature
-
-   id-kp-emailProtection         OBJECT IDENTIFIER ::= { id-kp 4 }
-   -- E-mail protection
-   -- Key usage bits that may be consistent: digitalSignature,
-   -- nonRepudiation, and/or (keyEncipherment or keyAgreement)
-
-   id-kp-timeStamping            OBJECT IDENTIFIER ::= { id-kp 8 }
-   -- Binding the hash of an object to a time
-   -- Key usage bits that may be consistent: digitalSignature
-   -- and/or nonRepudiation
-
-   id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
-   -- Signing OCSP responses
-   -- Key usage bits that may be consistent: digitalSignature
-   -- and/or nonRepudiation
-
-4.2.1.14  CRL Distribution Points
-
-   The CRL distribution points extension identifies how CRL information
-   is obtained.  The extension SHOULD be non-critical, but this profile
-   RECOMMENDS support for this extension by CAs and applications.
-   Further discussion of CRL management is contained in section 5.
-
-   The cRLDistributionPoints extension is a SEQUENCE of
-   DistributionPoint.  A DistributionPoint consists of three fields,
-   each of which is optional: distributionPoint, reasons, and cRLIssuer.
-   While each of these fields is optional, a DistributionPoint MUST NOT
-   consist of only the reasons field; either distributionPoint or
-   cRLIssuer MUST be present.  If the certificate issuer is not the CRL
-   issuer, then the cRLIssuer field MUST be present and contain the Name
-   of the CRL issuer.  If the certificate issuer is also the CRL issuer,
-   then the cRLIssuer field MUST be omitted and the distributionPoint
-   field MUST be present.  If the distributionPoint field is omitted,
-   cRLIssuer MUST be present and include a Name corresponding to an
-   X.500 or LDAP directory entry where the CRL is located.
-
-   When the distributionPoint field is present, it contains either a
-   SEQUENCE of general names or a single value, nameRelativeToCRLIssuer.
-   If the cRLDistributionPoints extension contains a general name of
-   type URI, the following semantics MUST be assumed: the URI is a
-   pointer to the current CRL for the associated reasons and will be
-   issued by the associated cRLIssuer.  The expected values for the URI
-   are those defined in 4.2.1.7.  Processing rules for other values are
-   not defined by this specification.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 42]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   If the DistributionPointName contains multiple values, each name
-   describes a different mechanism to obtain the same CRL.  For example,
-   the same CRL could be available for retrieval through both LDAP and
-   HTTP.
-
-   If the DistributionPointName contains the single value
-   nameRelativeToCRLIssuer, the value provides a distinguished name
-   fragment.  The fragment is appended to the X.500 distinguished name
-   of the CRL issuer to obtain the distribution point name.  If the
-   cRLIssuer field in the DistributionPoint is present, then the name
-   fragment is appended to the distinguished name that it contains;
-   otherwise, the name fragment is appended to the certificate issuer
-   distinguished name.  The DistributionPointName MUST NOT use the
-   nameRealtiveToCRLIssuer alternative when cRLIssuer contains more than
-   one distinguished name.
-
-   If the DistributionPoint omits the reasons field, the CRL MUST
-   include revocation information for all reasons.
-
-   The cRLIssuer identifies the entity who signs and issues the CRL.  If
-   present, the cRLIssuer MUST contain at least one an X.500
-   distinguished name (DN), and MAY also contain other name forms.
-   Since the cRLIssuer is compared to the CRL issuer name, the X.501
-   type Name MUST follow the encoding rules for the issuer name field in
-   the certificate (section 4.1.2.4).
-
-   id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::=  { id-ce 31 }
-
-   CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
-
-   DistributionPoint ::= SEQUENCE {
-        distributionPoint       [0]     DistributionPointName OPTIONAL,
-        reasons                 [1]     ReasonFlags OPTIONAL,
-        cRLIssuer               [2]     GeneralNames OPTIONAL }
-
-   DistributionPointName ::= CHOICE {
-        fullName                [0]     GeneralNames,
-        nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 43]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   ReasonFlags ::= BIT STRING {
-        unused                  (0),
-        keyCompromise           (1),
-        cACompromise            (2),
-        affiliationChanged      (3),
-        superseded              (4),
-        cessationOfOperation    (5),
-        certificateHold         (6),
-        privilegeWithdrawn      (7),
-        aACompromise            (8) }
-
-4.2.1.15  Inhibit Any-Policy
-
-   The inhibit any-policy extension can be used in certificates issued
-   to CAs.  The inhibit any-policy indicates that the special anyPolicy
-   OID, with the value { 2 5 29 32 0 }, is not considered an explicit
-   match for other certificate policies.  The value indicates the number
-   of additional certificates that may appear in the path before
-   anyPolicy is no longer permitted.  For example, a value of one
-   indicates that anyPolicy may be processed in certificates issued by
-   the subject of this certificate, but not in additional certificates
-   in the path.
-
-   This extension MUST be critical.
-
-   id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
-
-   InhibitAnyPolicy ::= SkipCerts
-
-   SkipCerts ::= INTEGER (0..MAX)
-
-4.2.1.16  Freshest CRL (a.k.a. Delta CRL Distribution Point)
-
-   The freshest CRL extension identifies how delta CRL information is
-   obtained.  The extension MUST be non-critical.  Further discussion of
-   CRL management is contained in section 5.
-
-   The same syntax is used for this extension and the
-   cRLDistributionPoints extension, and is described in section
-   4.2.1.14.  The same conventions apply to both extensions.
-
-   id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
-
-   FreshestCRL ::= CRLDistributionPoints
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 44]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-4.2.2  Private Internet Extensions
-
-   This section defines two extensions for use in the Internet Public
-   Key Infrastructure.  These extensions may be used to direct
-   applications to on-line information about the issuing CA or the
-   subject.  As the information may be available in multiple forms, each
-   extension is a sequence of IA5String values, each of which represents
-   a URI.  The URI implicitly specifies the location and format of the
-   information and the method for obtaining the information.
-
-   An object identifier is defined for the private extension.  The
-   object identifier associated with the private extension is defined
-   under the arc id-pe within the arc id-pkix.  Any future extensions
-   defined for the Internet PKI are also expected to be defined under
-   the arc id-pe.
-
-      id-pkix  OBJECT IDENTIFIER  ::=
-               { iso(1) identified-organization(3) dod(6) internet(1)
-                       security(5) mechanisms(5) pkix(7) }
-
-      id-pe  OBJECT IDENTIFIER  ::=  { id-pkix 1 }
-
-4.2.2.1  Authority Information Access
-
-   The authority information access extension indicates how to access CA
-   information and services for the issuer of the certificate in which
-   the extension appears.  Information and services may include on-line
-   validation services and CA policy data.  (The location of CRLs is not
-   specified in this extension; that information is provided by the
-   cRLDistributionPoints extension.)  This extension may be included in
-   end entity or CA certificates, and it MUST be non-critical.
-
-   id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
-
-   AuthorityInfoAccessSyntax  ::=
-           SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-   AccessDescription  ::=  SEQUENCE {
-           accessMethod          OBJECT IDENTIFIER,
-           accessLocation        GeneralName  }
-
-   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-
-   id-ad-caIssuers OBJECT IDENTIFIER ::= { id-ad 2 }
-
-   id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 45]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Each entry in the sequence AuthorityInfoAccessSyntax describes the
-   format and location of additional information provided by the CA that
-   issued the certificate in which this extension appears.  The type and
-   format of the information is specified by the accessMethod field; the
-   accessLocation field specifies the location of the information.  The
-   retrieval mechanism may be implied by the accessMethod or specified
-   by accessLocation.
-
-   This profile defines two accessMethod OIDs: id-ad-caIssuers and
-   id-ad-ocsp.
-
-   The id-ad-caIssuers OID is used when the additional information lists
-   CAs that have issued certificates superior to the CA that issued the
-   certificate containing this extension.  The referenced CA issuers
-   description is intended to aid certificate users in the selection of
-   a certification path that terminates at a point trusted by the
-   certificate user.
-
-   When id-ad-caIssuers appears as accessMethod, the accessLocation
-   field describes the referenced description server and the access
-   protocol to obtain the referenced description.  The accessLocation
-   field is defined as a GeneralName, which can take several forms.
-   Where the information is available via http, ftp, or ldap,
-   accessLocation MUST be a uniformResourceIdentifier.  Where the
-   information is available via the Directory Access Protocol (DAP),
-   accessLocation MUST be a directoryName.  The entry for that
-   directoryName contains CA certificates in the crossCertificatePair
-   attribute.  When the information is available via electronic mail,
-   accessLocation MUST be an rfc822Name.  The semantics of other
-   id-ad-caIssuers accessLocation name forms are not defined.
-
-   The id-ad-ocsp OID is used when revocation information for the
-   certificate containing this extension is available using the Online
-   Certificate Status Protocol (OCSP) [RFC 2560].
-
-   When id-ad-ocsp appears as accessMethod, the accessLocation field is
-   the location of the OCSP responder, using the conventions defined in
-   [RFC 2560].
-
-   Additional access descriptors may be defined in other PKIX
-   specifications.
-
-4.2.2.2  Subject Information Access
-
-   The subject information access extension indicates how to access
-   information and services for the subject of the certificate in which
-   the extension appears.  When the subject is a CA, information and
-   services may include certificate validation services and CA policy
-
-
-
-Housley, et. al.            Standards Track                    [Page 46]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   data.  When the subject is an end entity, the information describes
-   the type of services offered and how to access them.  In this case,
-   the contents of this extension are defined in the protocol
-   specifications for the suported services.  This extension may be
-   included in subject or CA certificates, and it MUST be non-critical.
-
-   id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
-
-   SubjectInfoAccessSyntax  ::=
-           SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-   AccessDescription  ::=  SEQUENCE {
-           accessMethod          OBJECT IDENTIFIER,
-           accessLocation        GeneralName  }
-
-   Each entry in the sequence SubjectInfoAccessSyntax describes the
-   format and location of additional information provided by the subject
-   of the certificate in which this extension appears.  The type and
-   format of the information is specified by the accessMethod field; the
-   accessLocation field specifies the location of the information.  The
-   retrieval mechanism may be implied by the accessMethod or specified
-   by accessLocation.
-
-   This profile defines one access method to be used when the subject is
-   a CA, and one access method to be used when the subject is an end
-   entity.  Additional access methods may be defined in the future in
-   the protocol specifications for other services.
-
-   The id-ad-caRepository OID is used when the subject is a CA, and
-   publishes its certificates and CRLs (if issued) in a repository.  The
-   accessLocation field is defined as a GeneralName, which can take
-   several forms.  Where the information is available via http, ftp, or
-   ldap, accessLocation MUST be a uniformResourceIdentifier.  Where the
-   information is available via the directory access protocol (dap),
-   accessLocation MUST be a directoryName.  When the information is
-   available via electronic mail, accessLocation MUST be an rfc822Name.
-   The semantics of other name forms of of accessLocation (when
-   accessMethod is id-ad-caRepository) are not defined by this
-   specification.
-
-   The id-ad-timeStamping OID is used when the subject offers
-   timestamping services using the Time Stamp Protocol defined in
-   [PKIXTSA].  Where the timestamping services are available via http or
-   ftp, accessLocation MUST be a uniformResourceIdentifier.  Where the
-   timestamping services are available via electronic mail,
-   accessLocation MUST be an rfc822Name.  Where timestamping services
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 47]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   are available using TCP/IP, the dNSName or ipAddress name forms may
-   be used.  The semantics of other name forms of accessLocation (when
-   accessMethod is id-ad-timeStamping) are not defined by this
-   specification.
-
-   Additional access descriptors may be defined in other PKIX
-   specifications.
-
-   id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-
-   id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
-
-   id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
-
-5  CRL and CRL Extensions Profile
-
-   As discussed above, one goal of this X.509 v2 CRL profile is to
-   foster the creation of an interoperable and reusable Internet PKI.
-   To achieve this goal, guidelines for the use of extensions are
-   specified, and some assumptions are made about the nature of
-   information included in the CRL.
-
-   CRLs may be used in a wide range of applications and environments
-   covering a broad spectrum of interoperability goals and an even
-   broader spectrum of operational and assurance requirements.  This
-   profile establishes a common baseline for generic applications
-   requiring broad interoperability.  The profile defines a set of
-   information that can be expected in every CRL.  Also, the profile
-   defines common locations within the CRL for frequently used
-   attributes as well as common representations for these attributes.
-
-   CRL issuers issue CRLs.  In general, the CRL issuer is the CA.  CAs
-   publish CRLs to provide status information about the certificates
-   they issued.  However, a CA may delegate this responsibility to
-   another trusted authority.  Whenever the CRL issuer is not the CA
-   that issued the certificates, the CRL is referred to as an indirect
-   CRL.
-
-   Each CRL has a particular scope.  The CRL scope is the set of
-   certificates that could appear on a given CRL.  For example, the
-   scope could be "all certificates issued by CA X", "all CA
-   certificates issued by CA X", "all certificates issued by CA X that
-   have been revoked for reasons of key compromise and CA compromise",
-   or could be a set of certificates based on arbitrary local
-   information, such as "all certificates issued to the NIST employees
-   located in Boulder".
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 48]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   A complete CRL lists all unexpired certificates, within its scope,
-   that have been revoked for one of the revocation reasons covered by
-   the CRL scope.  The CRL issuer MAY also generate delta CRLs.  A delta
-   CRL only lists those certificates, within its scope, whose revocation
-   status has changed since the issuance of a referenced complete CRL.
-   The referenced complete CRL is referred to as a base CRL.  The scope
-   of a delta CRL MUST be the same as the base CRL that it references.
-
-   This profile does not define any private Internet CRL extensions or
-   CRL entry extensions.
-
-   Environments with additional or special purpose requirements may
-   build on this profile or may replace it.
-
-   Conforming CAs are not required to issue CRLs if other revocation or
-   certificate status mechanisms are provided.  When CRLs are issued,
-   the CRLs MUST be version 2 CRLs, include the date by which the next
-   CRL will be issued in the nextUpdate field (section 5.1.2.5), include
-   the CRL number extension (section 5.2.3), and include the authority
-   key identifier extension (section 5.2.1).  Conforming applications
-   that support CRLs are REQUIRED to process both version 1 and version
-   2 complete CRLs that provide revocation information for all
-   certificates issued by one CA.  Conforming applications are NOT
-   REQUIRED to support processing of delta CRLs, indirect CRLs, or CRLs
-   with a scope other than all certificates issued by one CA.
-
-5.1  CRL Fields
-
-   The X.509 v2 CRL syntax is as follows.  For signature calculation,
-   the data that is to be signed is ASN.1 DER encoded.  ASN.1 DER
-   encoding is a tag, length, value encoding system for each element.
-
-   CertificateList  ::=  SEQUENCE  {
-        tbsCertList          TBSCertList,
-        signatureAlgorithm   AlgorithmIdentifier,
-        signatureValue       BIT STRING  }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 49]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   TBSCertList  ::=  SEQUENCE  {
-        version                 Version OPTIONAL,
-                                     -- if present, MUST be v2
-        signature               AlgorithmIdentifier,
-        issuer                  Name,
-        thisUpdate              Time,
-        nextUpdate              Time OPTIONAL,
-        revokedCertificates     SEQUENCE OF SEQUENCE  {
-             userCertificate         CertificateSerialNumber,
-             revocationDate          Time,
-             crlEntryExtensions      Extensions OPTIONAL
-                                           -- if present, MUST be v2
-                                  }  OPTIONAL,
-        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
-                                           -- if present, MUST be v2
-                                  }
-
-   -- Version, Time, CertificateSerialNumber, and Extensions
-   -- are all defined in the ASN.1 in section 4.1
-
-   -- AlgorithmIdentifier is defined in section 4.1.1.2
-
-   The following items describe the use of the X.509 v2 CRL in the
-   Internet PKI.
-
-5.1.1  CertificateList Fields
-
-   The CertificateList is a SEQUENCE of three required fields.  The
-   fields are described in detail in the following subsections.
-
-5.1.1.1  tbsCertList
-
-   The first field in the sequence is the tbsCertList.  This field is
-   itself a sequence containing the name of the issuer, issue date,
-   issue date of the next list, the optional list of revoked
-   certificates, and optional CRL extensions.  When there are no revoked
-   certificates, the revoked certificates list is absent.  When one or
-   more certificates are revoked, each entry on the revoked certificate
-   list is defined by a sequence of user certificate serial number,
-   revocation date, and optional CRL entry extensions.
-
-5.1.1.2  signatureAlgorithm
-
-   The signatureAlgorithm field contains the algorithm identifier for
-   the algorithm used by the CRL issuer to sign the CertificateList.
-   The field is of type AlgorithmIdentifier, which is defined in section
-   4.1.1.2.  [PKIXALGS] lists the supported algorithms for this
-   specification, but other signature algorithms MAY also be supported.
-
-
-
-Housley, et. al.            Standards Track                    [Page 50]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   This field MUST contain the same algorithm identifier as the
-   signature field in the sequence tbsCertList (section 5.1.2.2).
-
-5.1.1.3  signatureValue
-
-   The signatureValue field contains a digital signature computed upon
-   the ASN.1 DER encoded tbsCertList.  The ASN.1 DER encoded tbsCertList
-   is used as the input to the signature function.  This signature value
-   is encoded as a BIT STRING and included in the CRL signatureValue
-   field.  The details of this process are specified for each of the
-   supported algorithms in [PKIXALGS].
-
-   CAs that are also CRL issuers MAY use one private key to digitally
-   sign certificates and CRLs, or MAY use separate private keys to
-   digitally sign certificates and CRLs.  When separate private keys are
-   employed, each of the public keys associated with these private keys
-   is placed in a separate certificate, one with the keyCertSign bit set
-   in the key usage extension, and one with the cRLSign bit set in the
-   key usage extension (section 4.2.1.3).  When separate private keys
-   are employed, certificates issued by the CA contain one authority key
-   identifier, and the corresponding CRLs contain a different authority
-   key identifier.  The use of separate CA certificates for validation
-   of certificate signatures and CRL signatures can offer improved
-   security characteristics; however, it imposes a burden on
-   applications, and it might limit interoperability.  Many applications
-   construct a certification path, and then validate the certification
-   path (section 6).  CRL checking in turn requires a separate
-   certification path to be constructed and validated for the CA's CRL
-   signature validation certificate.  Applications that perform CRL
-   checking MUST support certification path validation when certificates
-   and CRLs are digitally signed with the same CA private key.  These
-   applications SHOULD support certification path validation when
-   certificates and CRLs are digitally signed with different CA private
-   keys.
-
-5.1.2  Certificate List "To Be Signed"
-
-   The certificate list to be signed, or TBSCertList, is a sequence of
-   required and optional fields.  The required fields identify the CRL
-   issuer, the algorithm used to sign the CRL, the date and time the CRL
-   was issued, and the date and time by which the CRL issuer will issue
-   the next CRL.
-
-   Optional fields include lists of revoked certificates and CRL
-   extensions.  The revoked certificate list is optional to support the
-   case where a CA has not revoked any unexpired certificates that it
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 51]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   has issued.  The profile requires conforming CRL issuers to use the
-   CRL number and authority key identifier CRL extensions in all CRLs
-   issued.
-
-5.1.2.1  Version
-
-   This optional field describes the version of the encoded CRL.  When
-   extensions are used, as required by this profile, this field MUST be
-   present and MUST specify version 2 (the integer value is 1).
-
-5.1.2.2  Signature
-
-   This field contains the algorithm identifier for the algorithm used
-   to sign the CRL.  [PKIXALGS] lists OIDs for the most popular
-   signature algorithms used in the Internet PKI.
-
-   This field MUST contain the same algorithm identifier as the
-   signatureAlgorithm field in the sequence CertificateList (section
-   5.1.1.2).
-
-5.1.2.3  Issuer Name
-
-   The issuer name identifies the entity who has signed and issued the
-   CRL.  The issuer identity is carried in the issuer name field.
-   Alternative name forms may also appear in the issuerAltName extension
-   (section 5.2.2).  The issuer name field MUST contain an X.500
-   distinguished name (DN).  The issuer name field is defined as the
-   X.501 type Name, and MUST follow the encoding rules for the issuer
-   name field in the certificate (section 4.1.2.4).
-
-5.1.2.4  This Update
-
-   This field indicates the issue date of this CRL.  ThisUpdate may be
-   encoded as UTCTime or GeneralizedTime.
-
-   CRL issuers conforming to this profile MUST encode thisUpdate as
-   UTCTime for dates through the year 2049.  CRL issuers conforming to
-   this profile MUST encode thisUpdate as GeneralizedTime for dates in
-   the year 2050 or later.
-
-   Where encoded as UTCTime, thisUpdate MUST be specified and
-   interpreted as defined in section 4.1.2.5.1.  Where encoded as
-   GeneralizedTime, thisUpdate MUST be specified and interpreted as
-   defined in section 4.1.2.5.2.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 52]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-5.1.2.5  Next Update
-
-   This field indicates the date by which the next CRL will be issued.
-   The next CRL could be issued before the indicated date, but it will
-   not be issued any later than the indicated date.  CRL issuers SHOULD
-   issue CRLs with a nextUpdate time equal to or later than all previous
-   CRLs.  nextUpdate may be encoded as UTCTime or GeneralizedTime.
-
-   This profile requires inclusion of nextUpdate in all CRLs issued by
-   conforming CRL issuers.  Note that the ASN.1 syntax of TBSCertList
-   describes this field as OPTIONAL, which is consistent with the ASN.1
-   structure defined in [X.509].  The behavior of clients processing
-   CRLs which omit nextUpdate is not specified by this profile.
-
-   CRL issuers conforming to this profile MUST encode nextUpdate as
-   UTCTime for dates through the year 2049.  CRL issuers conforming to
-   this profile MUST encode nextUpdate as GeneralizedTime for dates in
-   the year 2050 or later.
-
-   Where encoded as UTCTime, nextUpdate MUST be specified and
-   interpreted as defined in section 4.1.2.5.1.  Where encoded as
-   GeneralizedTime, nextUpdate MUST be specified and interpreted as
-   defined in section 4.1.2.5.2.
-
-5.1.2.6  Revoked Certificates
-
-   When there are no revoked certificates, the revoked certificates list
-   MUST be absent.  Otherwise, revoked certificates are listed by their
-   serial numbers.  Certificates revoked by the CA are uniquely
-   identified by the certificate serial number.  The date on which the
-   revocation occurred is specified.  The time for revocationDate MUST
-   be expressed as described in section 5.1.2.4. Additional information
-   may be supplied in CRL entry extensions; CRL entry extensions are
-   discussed in section 5.3.
-
-5.1.2.7  Extensions
-
-   This field may only appear if the version is 2 (section 5.1.2.1).  If
-   present, this field is a sequence of one or more CRL extensions.  CRL
-   extensions are discussed in section 5.2.
-
-5.2  CRL Extensions
-
-   The extensions defined by ANSI X9, ISO/IEC, and ITU-T for X.509 v2
-   CRLs [X.509] [X9.55] provide methods for associating additional
-   attributes with CRLs.  The X.509 v2 CRL format also allows
-   communities to define private extensions to carry information unique
-   to those communities.  Each extension in a CRL may be designated as
-
-
-
-Housley, et. al.            Standards Track                    [Page 53]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   critical or non-critical.  A CRL validation MUST fail if it
-   encounters a critical extension which it does not know how to
-   process.  However, an unrecognized non-critical extension may be
-   ignored.  The following subsections present those extensions used
-   within Internet CRLs.  Communities may elect to include extensions in
-   CRLs which are not defined in this specification.  However, caution
-   should be exercised in adopting any critical extensions in CRLs which
-   might be used in a general context.
-
-   Conforming CRL issuers are REQUIRED to include the authority key
-   identifier (section 5.2.1) and the CRL number (section 5.2.3)
-   extensions in all CRLs issued.
-
-5.2.1  Authority Key Identifier
-
-   The authority key identifier extension provides a means of
-   identifying the public key corresponding to the private key used to
-   sign a CRL.  The identification can be based on either the key
-   identifier (the subject key identifier in the CRL signer's
-   certificate) or on the issuer name and serial number.  This extension
-   is especially useful where an issuer has more than one signing key,
-   either due to multiple concurrent key pairs or due to changeover.
-
-   Conforming CRL issuers MUST use the key identifier method, and MUST
-   include this extension in all CRLs issued.
-
-   The syntax for this CRL extension is defined in section 4.2.1.1.
-
-5.2.2  Issuer Alternative Name
-
-   The issuer alternative names extension allows additional identities
-   to be associated with the issuer of the CRL.  Defined options include
-   an rfc822 name (electronic mail address), a DNS name, an IP address,
-   and a URI.  Multiple instances of a name and multiple name forms may
-   be included.  Whenever such identities are used, the issuer
-   alternative name extension MUST be used; however, a DNS name MAY be
-   represented in the issuer field using the domainComponent attribute
-   as described in section 4.1.2.4.
-
-   The issuerAltName extension SHOULD NOT be marked critical.
-
-   The OID and syntax for this CRL extension are defined in section
-   4.2.1.8.
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 54]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-5.2.3  CRL Number
-
-   The CRL number is a non-critical CRL extension which conveys a
-   monotonically increasing sequence number for a given CRL scope and
-   CRL issuer.  This extension allows users to easily determine when a
-   particular CRL supersedes another CRL.  CRL numbers also support the
-   identification of complementary complete CRLs and delta CRLs.  CRL
-   issuers conforming to this profile MUST include this extension in all
-   CRLs.
-
-   If a CRL issuer generates delta CRLs in addition to complete CRLs for
-   a given scope, the complete CRLs and delta CRLs MUST share one
-   numbering sequence.  If a delta CRL and a complete CRL that cover the
-   same scope are issued at the same time, they MUST have the same CRL
-   number and provide the same revocation information.  That is, the
-   combination of the delta CRL and an acceptable complete CRL MUST
-   provide the same revocation information as the simultaneously issued
-   complete CRL.
-
-   If a CRL issuer generates two CRLs (two complete CRLs, two delta
-   CRLs, or a complete CRL and a delta CRL) for the same scope at
-   different times, the two CRLs MUST NOT have the same CRL number.
-   That is, if the this update field (section 5.1.2.4) in the two CRLs
-   are not identical, the CRL numbers MUST be different.
-
-   Given the requirements above, CRL numbers can be expected to contain
-   long integers.  CRL verifiers MUST be able to handle CRLNumber values
-   up to 20 octets.  Conformant CRL issuers MUST NOT use CRLNumber
-   values longer than 20 octets.
-
-   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
-
-   CRLNumber ::= INTEGER (0..MAX)
-
-5.2.4  Delta CRL Indicator
-
-   The delta CRL indicator is a critical CRL extension that identifies a
-   CRL as being a delta CRL.  Delta CRLs contain updates to revocation
-   information previously distributed, rather than all the information
-   that would appear in a complete CRL.  The use of delta CRLs can
-   significantly reduce network load and processing time in some
-   environments.  Delta CRLs are generally smaller than the CRLs they
-   update, so applications that obtain delta CRLs consume less network
-   bandwidth than applications that obtain the corresponding complete
-   CRLs.  Applications which store revocation information in a format
-   other than the CRL structure can add new revocation information to
-   the local database without reprocessing information.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 55]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The delta CRL indicator extension contains the single value of type
-   BaseCRLNumber.  The CRL number identifies the CRL, complete for a
-   given scope, that was used as the starting point in the generation of
-   this delta CRL.  A conforming CRL issuer MUST publish the referenced
-   base CRL as a complete CRL.  The delta CRL contains all updates to
-   the revocation status for that same scope.  The combination of a
-   delta CRL plus the referenced base CRL is equivalent to a complete
-   CRL, for the applicable scope, at the time of publication of the
-   delta CRL.
-
-   When a conforming CRL issuer generates a delta CRL, the delta CRL
-   MUST include a critical delta CRL indicator extension.
-
-   When a delta CRL is issued, it MUST cover the same set of reasons and
-   the same set of certificates that were covered by the base CRL it
-   references.  That is, the scope of the delta CRL MUST be the same as
-   the scope of the complete CRL referenced as the base.  The referenced
-   base CRL and the delta CRL MUST omit the issuing distribution point
-   extension or contain identical issuing distribution point extensions.
-   Further, the CRL issuer MUST use the same private key to sign the
-   delta CRL and any complete CRL that it can be used to update.
-
-   An application that supports delta CRLs can construct a CRL that is
-   complete for a given scope by combining a delta CRL for that scope
-   with either an issued CRL that is complete for that scope or a
-   locally constructed CRL that is complete for that scope.
-
-   When a delta CRL is combined with a complete CRL or a locally
-   constructed CRL, the resulting locally constructed CRL has the CRL
-   number specified in the CRL number extension found in the delta CRL
-   used in its construction.  In addition, the resulting locally
-   constructed CRL has the thisUpdate and nextUpdate times specified in
-   the corresponding fields of the delta CRL used in its construction.
-   In addition, the locally constructed CRL inherits the issuing
-   distribution point from the delta CRL.
-
-   A complete CRL and a delta CRL MAY be combined if the following four
-   conditions are satisfied:
-
-      (a)  The complete CRL and delta CRL have the same issuer.
-
-      (b)  The complete CRL and delta CRL have the same scope.  The two
-      CRLs have the same scope if either of the following conditions are
-      met:
-
-         (1)  The issuingDistributionPoint extension is omitted from
-         both the complete CRL and the delta CRL.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 56]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-         (2)  The issuingDistributionPoint extension is present in both
-         the complete CRL and the delta CRL, and the values for each of
-         the fields in the extensions are the same in both CRLs.
-
-      (c)  The CRL number of the complete CRL is equal to or greater
-      than the BaseCRLNumber specified in the delta CRL.  That is, the
-      complete CRL contains (at a minimum) all the revocation
-      information held by the referenced base CRL.
-
-      (d)  The CRL number of the complete CRL is less than the CRL
-      number of the delta CRL.  That is, the delta CRL follows the
-      complete CRL in the numbering sequence.
-
-   CRL issuers MUST ensure that the combination of a delta CRL and any
-   appropriate complete CRL accurately reflects the current revocation
-   status.  The CRL issuer MUST include an entry in the delta CRL for
-   each certificate within the scope of the delta CRL whose status has
-   changed since the generation of the referenced base CRL:
-
-      (a)  If the certificate is revoked for a reason included in the
-      scope of the CRL, list the certificate as revoked.
-
-      (b)  If the certificate is valid and was listed on the referenced
-      base CRL or any subsequent CRL with reason code certificateHold,
-      and the reason code certificateHold is included in the scope of
-      the CRL, list the certificate with the reason code removeFromCRL.
-
-      (c)  If the certificate is revoked for a reason outside the scope
-      of the CRL, but the certificate was listed on the referenced base
-      CRL or any subsequent CRL with a reason code included in the scope
-      of this CRL, list the certificate as revoked but omit the reason
-      code.
-
-      (d)  If the certificate is revoked for a reason outside the scope
-      of the CRL and the certificate was neither listed on the
-      referenced base CRL nor any subsequent CRL with a reason code
-      included in the scope of this CRL, do not list the certificate on
-      this CRL.
-
-   The status of a certificate is considered to have changed if it is
-   revoked, placed on hold, released from hold, or if its revocation
-   reason changes.
-
-   It is appropriate to list a certificate with reason code
-   removeFromCRL on a delta CRL even if the certificate was not on hold
-   in the referenced base CRL.  If the certificate was placed on hold in
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 57]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   any CRL issued after the base but before this delta CRL and then
-   released from hold, it MUST be listed on the delta CRL with
-   revocation reason removeFromCRL.
-
-   A CRL issuer MAY optionally list a certificate on a delta CRL with
-   reason code removeFromCRL if the notAfter time specified in the
-   certificate precedes the thisUpdate time specified in the delta CRL
-   and the certificate was listed on the referenced base CRL or in any
-   CRL issued after the base but before this delta CRL.
-
-   If a certificate revocation notice first appears on a delta CRL, then
-   it is possible for the certificate validity period to expire before
-   the next complete CRL for the same scope is issued.  In this case,
-   the revocation notice MUST be included in all subsequent delta CRLs
-   until the revocation notice is included on at least one explicitly
-   issued complete CRL for this scope.
-
-   An application that supports delta CRLs MUST be able to construct a
-   current complete CRL by combining a previously issued complete CRL
-   and the most current delta CRL.  An application that supports delta
-   CRLs MAY also be able to construct a current complete CRL by
-   combining a previously locally constructed complete CRL and the
-   current delta CRL.  A delta CRL is considered to be the current one
-   if the current time is between the times contained in the thisUpdate
-   and nextUpdate fields.  Under some circumstances, the CRL issuer may
-   publish one or more delta CRLs before indicated by the nextUpdate
-   field.  If more than one current delta CRL for a given scope is
-   encountered, the application SHOULD consider the one with the latest
-   value in thisUpdate to be the most current one.
-
-   id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
-
-   BaseCRLNumber ::= CRLNumber
-
-5.2.5  Issuing Distribution Point
-
-   The issuing distribution point is a critical CRL extension that
-   identifies the CRL distribution point and scope for a particular CRL,
-   and it indicates whether the CRL covers revocation for end entity
-   certificates only, CA certificates only, attribute certificates only,
-
-   or a limited set of reason codes.  Although the extension is
-   critical, conforming implementations are not required to support this
-   extension.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 58]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The CRL is signed using the CRL issuer's private key.  CRL
-   Distribution Points do not have their own key pairs.  If the CRL is
-   stored in the X.500 Directory, it is stored in the Directory entry
-   corresponding to the CRL distribution point, which may be different
-   than the Directory entry of the CRL issuer.
-
-   The reason codes associated with a distribution point MUST be
-   specified in onlySomeReasons.  If onlySomeReasons does not appear,
-   the distribution point MUST contain revocations for all reason codes.
-   CAs may use CRL distribution points to partition the CRL on the basis
-   of compromise and routine revocation.  In this case, the revocations
-   with reason code keyCompromise (1), cACompromise (2), and
-   aACompromise (8) appear in one distribution point, and the
-   revocations with other reason codes appear in another distribution
-   point.
-
-   If the distributionPoint field is present and contains a URI, the
-   following semantics MUST be assumed: the object is a pointer to the
-   most current CRL issued by this CRL issuer.  The URI schemes ftp,
-   http, mailto [RFC1738] and ldap [RFC1778] are defined for this
-   purpose.  The URI MUST be an absolute pathname, not a relative
-   pathname, and MUST specify the host.
-
-   If the distributionPoint field is absent, the CRL MUST contain
-   entries for all revoked unexpired certificates issued by the CRL
-   issuer, if any, within the scope of the CRL.
-
-   The CRL issuer MUST assert the indirectCRL boolean, if the scope of
-   the CRL includes certificates issued by authorities other than the
-   CRL issuer.  The authority responsible for each entry is indicated by
-   the certificate issuer CRL entry extension (section 5.3.4).
-
-   id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
-
-   issuingDistributionPoint ::= SEQUENCE {
-        distributionPoint          [0] DistributionPointName OPTIONAL,
-        onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
-        onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
-        onlySomeReasons            [3] ReasonFlags OPTIONAL,
-        indirectCRL                [4] BOOLEAN DEFAULT FALSE,
-        onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
-
-5.2.6  Freshest CRL (a.k.a. Delta CRL Distribution Point)
-
-   The freshest CRL extension identifies how delta CRL information for
-   this complete CRL is obtained.  The extension MUST be non-critical.
-   This extension MUST NOT appear in delta CRLs.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 59]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The same syntax is used for this extension as the
-   cRLDistributionPoints certificate extension, and is described in
-   section 4.2.1.14.  However, only the distribution point field is
-   meaningful in this context.  The reasons and CRLIssuer fields MUST be
-   omitted from this CRL extension.
-
-   Each distribution point name provides the location at which a delta
-   CRL for this complete CRL can be found.  The scope of these delta
-   CRLs MUST be the same as the scope of this complete CRL.  The
-   contents of this CRL extension are only used to locate delta CRLs;
-   the contents are not used to validate the CRL or the referenced delta
-   CRLs.  The encoding conventions defined for distribution points in
-   section 4.2.1.14 apply to this extension.
-
-   id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
-
-   FreshestCRL ::= CRLDistributionPoints
-
-5.3  CRL Entry Extensions
-
-   The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9 for
-   X.509 v2 CRLs provide methods for associating additional attributes
-   with CRL entries [X.509] [X9.55].  The X.509 v2 CRL format also
-   allows communities to define private CRL entry extensions to carry
-   information unique to those communities.  Each extension in a CRL
-   entry may be designated as critical or non-critical.  A CRL
-   validation MUST fail if it encounters a critical CRL entry extension
-   which it does not know how to process.  However, an unrecognized non-
-   critical CRL entry extension may be ignored.  The following
-   subsections present recommended extensions used within Internet CRL
-   entries and standard locations for information.  Communities may
-   elect to use additional CRL entry extensions; however, caution should
-   be exercised in adopting any critical extensions in CRL entries which
-   might be used in a general context.
-
-   All CRL entry extensions used in this specification are non-critical.
-   Support for these extensions is optional for conforming CRL issuers
-   and applications.  However, CRL issuers SHOULD include reason codes
-   (section 5.3.1) and invalidity dates (section 5.3.3) whenever this
-   information is available.
-
-5.3.1  Reason Code
-
-   The reasonCode is a non-critical CRL entry extension that identifies
-   the reason for the certificate revocation.  CRL issuers are strongly
-   encouraged to include meaningful reason codes in CRL entries;
-   however, the reason code CRL entry extension SHOULD be absent instead
-   of using the unspecified (0) reasonCode value.
-
-
-
-Housley, et. al.            Standards Track                    [Page 60]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   id-ce-cRLReason OBJECT IDENTIFIER ::= { id-ce 21 }
-
-   -- reasonCode ::= { CRLReason }
-
-   CRLReason ::= ENUMERATED {
-        unspecified             (0),
-        keyCompromise           (1),
-        cACompromise            (2),
-        affiliationChanged      (3),
-        superseded              (4),
-        cessationOfOperation    (5),
-        certificateHold         (6),
-        removeFromCRL           (8),
-        privilegeWithdrawn      (9),
-        aACompromise           (10) }
-
-5.3.2  Hold Instruction Code
-
-   The hold instruction code is a non-critical CRL entry extension that
-   provides a registered instruction identifier which indicates the
-   action to be taken after encountering a certificate that has been
-   placed on hold.
-
-   id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
-
-   holdInstructionCode ::= OBJECT IDENTIFIER
-
-   The following instruction codes have been defined.  Conforming
-   applications that process this extension MUST recognize the following
-   instruction codes.
-
-   holdInstruction    OBJECT IDENTIFIER ::=
-                    { iso(1) member-body(2) us(840) x9-57(10040) 2 }
-
-   id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
-   id-holdinstruction-callissuer
-                             OBJECT IDENTIFIER ::= {holdInstruction 2}
-   id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
-
-   Conforming applications which encounter an id-holdinstruction-
-   callissuer MUST call the certificate issuer or reject the
-   certificate.  Conforming applications which encounter an id-
-   holdinstruction-reject MUST reject the certificate.  The hold
-   instruction id-holdinstruction-none is semantically equivalent to the
-   absence of a holdInstructionCode, and its use is strongly deprecated
-   for the Internet PKI.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 61]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-5.3.3  Invalidity Date
-
-   The invalidity date is a non-critical CRL entry extension that
-   provides the date on which it is known or suspected that the private
-   key was compromised or that the certificate otherwise became invalid.
-   This date may be earlier than the revocation date in the CRL entry,
-   which is the date at which the CA processed the revocation.  When a
-   revocation is first posted by a CRL issuer in a CRL, the invalidity
-   date may precede the date of issue of earlier CRLs, but the
-   revocation date SHOULD NOT precede the date of issue of earlier CRLs.
-   Whenever this information is available, CRL issuers are strongly
-   encouraged to share it with CRL users.
-
-   The GeneralizedTime values included in this field MUST be expressed
-   in Greenwich Mean Time (Zulu), and MUST be specified and interpreted
-   as defined in section 4.1.2.5.2.
-
-   id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
-
-   invalidityDate ::=  GeneralizedTime
-
-5.3.4  Certificate Issuer
-
-   This CRL entry extension identifies the certificate issuer associated
-   with an entry in an indirect CRL, that is, a CRL that has the
-   indirectCRL indicator set in its issuing distribution point
-   extension.  If this extension is not present on the first entry in an
-   indirect CRL, the certificate issuer defaults to the CRL issuer.  On
-   subsequent entries in an indirect CRL, if this extension is not
-   present, the certificate issuer for the entry is the same as that for
-   the preceding entry.  This field is defined as follows:
-
-   id-ce-certificateIssuer   OBJECT IDENTIFIER ::= { id-ce 29 }
-
-   certificateIssuer ::=     GeneralNames
-
-   If used by conforming CRL issuers, this extension MUST always be
-   critical.  If an implementation ignored this extension it could not
-   correctly attribute CRL entries to certificates.  This specification
-   RECOMMENDS that implementations recognize this extension.
-
-6  Certification Path Validation
-
-   Certification path validation procedures for the Internet PKI are
-   based on the algorithm supplied in [X.509].  Certification path
-   processing verifies the binding between the subject distinguished
-   name and/or subject alternative name and subject public key.  The
-   binding is limited by constraints which are specified in the
-
-
-
-Housley, et. al.            Standards Track                    [Page 62]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   certificates which comprise the path and inputs which are specified
-   by the relying party.  The basic constraints and policy constraints
-   extensions allow the certification path processing logic to automate
-   the decision making process.
-
-   This section describes an algorithm for validating certification
-   paths.  Conforming implementations of this specification are not
-   required to implement this algorithm, but MUST provide functionality
-   equivalent to the external behavior resulting from this procedure.
-   Any algorithm may be used by a particular implementation so long as
-   it derives the correct result.
-
-   In section 6.1, the text describes basic path validation.  Valid
-   paths begin with certificates issued by a trust anchor.  The
-   algorithm requires the public key of the CA, the CA's name, and any
-   constraints upon the set of paths which may be validated using this
-   key.
-
-   The selection of a trust anchor is a matter of policy: it could be
-   the top CA in a hierarchical PKI; the CA that issued the verifier's
-   own certificate(s); or any other CA in a network PKI.  The path
-   validation procedure is the same regardless of the choice of trust
-   anchor.  In addition, different applications may rely on different
-   trust anchor, or may accept paths that begin with any of a set of
-   trust anchor.
-
-   Section 6.2 describes methods for using the path validation algorithm
-   in specific implementations.  Two specific cases are discussed: the
-   case where paths may begin with one of several trusted CAs; and where
-   compatibility with the PEM architecture is required.
-
-   Section 6.3 describes the steps necessary to determine if a
-   certificate is revoked or on hold status when CRLs are the revocation
-   mechanism used by the certificate issuer.
-
-6.1  Basic Path Validation
-
-   This text describes an algorithm for X.509 path processing.  A
-   conformant implementation MUST include an X.509 path processing
-   procedure that is functionally equivalent to the external behavior of
-   this algorithm.  However, support for some of the certificate
-   extensions processed in this algorithm are OPTIONAL for compliant
-   implementations.  Clients that do not support these extensions MAY
-   omit the corresponding steps in the path validation algorithm.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 63]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   For example, clients are NOT REQUIRED to support the policy mapping
-   extension.  Clients that do not support this extension MAY omit the
-   path validation steps where policy mappings are processed.  Note that
-   clients MUST reject the certificate if it contains an unsupported
-   critical extension.
-
-   The algorithm presented in this section validates the certificate
-   with respect to the current date and time.  A conformant
-   implementation MAY also support validation with respect to some point
-   in the past.  Note that mechanisms are not available for validating a
-   certificate with respect to a time outside the certificate validity
-   period.
-
-   The trust anchor is an input to the algorithm.  There is no
-   requirement that the same trust anchor be used to validate all
-   certification paths.  Different trust anchors MAY be used to validate
-   different paths, as discussed further in Section 6.2.
-
-   The primary goal of path validation is to verify the binding between
-   a subject distinguished name or a subject alternative name and
-   subject public key, as represented in the end entity certificate,
-   based on the public key of the trust anchor.  This requires obtaining
-   a sequence of certificates that support that binding.  The procedure
-   performed to obtain this sequence of certificates is outside the
-   scope of this specification.
-
-   To meet this goal, the path validation process verifies, among other
-   things, that a prospective certification path (a sequence of n
-   certificates) satisfies the following conditions:
-
-      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
-      the issuer of certificate x+1;
-
-      (b)  certificate 1 is issued by the trust anchor;
-
-      (c)  certificate n is the certificate to be validated; and
-
-      (d)  for all x in {1, ..., n}, the certificate was valid at the
-      time in question.
-
-   When the trust anchor is provided in the form of a self-signed
-   certificate, this self-signed certificate is not included as part of
-   the prospective certification path.  Information about trust anchors
-   are provided as inputs to the certification path validation algorithm
-   (section 6.1.1).
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 64]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   A particular certification path may not, however, be appropriate for
-   all applications.  Therefore, an application MAY augment this
-   algorithm to further limit the set of valid paths.  The path
-   validation process also determines the set of certificate policies
-   that are valid for this path, based on the certificate policies
-   extension, policy mapping extension, policy constraints extension,
-   and inhibit any-policy extension.  To achieve this, the path
-   validation algorithm constructs a valid policy tree.  If the set of
-   certificate policies that are valid for this path is not empty, then
-   the result will be a valid policy tree of depth n, otherwise the
-   result will be a null valid policy tree.
-
-   A certificate is self-issued if the DNs that appear in the subject
-   and issuer fields are identical and are not empty.  In general, the
-   issuer and subject of the certificates that make up a path are
-   different for each certificate.  However, a CA may issue a
-   certificate to itself to support key rollover or changes in
-   certificate policies.  These self-issued certificates are not counted
-   when evaluating path length or name constraints.
-
-   This section presents the algorithm in four basic steps: (1)
-   initialization, (2) basic certificate processing, (3) preparation for
-   the next certificate, and (4) wrap-up.  Steps (1) and (4) are
-   performed exactly once.  Step (2) is performed for all certificates
-   in the path.  Step (3) is performed for all certificates in the path
-   except the final certificate.  Figure 2 provides a high-level
-   flowchart of this algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 65]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                           +-------+
-                           | START |
-                           +-------+
-                               |
-                               V
-                       +----------------+
-                       | Initialization |
-                       +----------------+
-                               |
-                               +<--------------------+
-                               |                     |
-                               V                     |
-                       +----------------+            |
-                       |  Process Cert  |            |
-                       +----------------+            |
-                               |                     |
-                               V                     |
-                       +================+            |
-                       |  IF Last Cert  |            |
-                       |    in Path     |            |
-                       +================+            |
-                         |            |              |
-                    THEN |            | ELSE         |
-                         V            V              |
-              +----------------+ +----------------+  |
-              |    Wrap up     | |  Prepare for   |  |
-              +----------------+ |   Next Cert    |  |
-                      |          +----------------+  |
-                      V               |              |
-                  +-------+           +--------------+
-                  | STOP  |
-                  +-------+
-
-
-         Figure 2.  Certification Path Processing Flowchart
-
-6.1.1  Inputs
-
-   This algorithm assumes the following seven inputs are provided to the
-   path processing logic:
-
-      (a)  a prospective certification path of length n.
-
-      (b)  the current date/time.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 66]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (c)  user-initial-policy-set:  A set of certificate policy
-      identifiers naming the policies that are acceptable to the
-      certificate user.  The user-initial-policy-set contains the
-      special value any-policy if the user is not concerned about
-      certificate policy.
-
-      (d)  trust anchor information, describing a CA that serves as a
-      trust anchor for the certification path.  The trust anchor
-      information includes:
-
-         (1)  the trusted issuer name,
-
-         (2)  the trusted public key algorithm,
-
-         (3)  the trusted public key, and
-
-         (4)  optionally, the trusted public key parameters associated
-         with the public key.
-
-      The trust anchor information may be provided to the path
-      processing procedure in the form of a self-signed certificate.
-      The trusted anchor information is trusted because it was delivered
-      to the path processing procedure by some trustworthy out-of-band
-      procedure.  If the trusted public key algorithm requires
-      parameters, then the parameters are provided along with the
-      trusted public key.
-
-      (e) initial-policy-mapping-inhibit, which indicates if policy
-      mapping is allowed in the certification path.
-
-      (f) initial-explicit-policy, which indicates if the path must be
-      valid for at least one of the certificate policies in the user-
-      initial-policy-set.
-
-      (g) initial-any-policy-inhibit, which indicates whether the
-      anyPolicy OID should be processed if it is included in a
-      certificate.
-
-6.1.2  Initialization
-
-   This initialization phase establishes eleven state variables based
-   upon the seven inputs:
-
-      (a)  valid_policy_tree:  A tree of certificate policies with their
-      optional qualifiers; each of the leaves of the tree represents a
-      valid policy at this stage in the certification path validation.
-      If valid policies exist at this stage in the certification path
-      validation, the depth of the tree is equal to the number of
-
-
-
-Housley, et. al.            Standards Track                    [Page 67]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      certificates in the chain that have been processed.  If valid
-      policies do not exist at this stage in the certification path
-      validation, the tree is set to NULL.  Once the tree is set to
-      NULL, policy processing ceases.
-
-      Each node in the valid_policy_tree includes four data objects: the
-      valid policy, a set of associated policy qualifiers, a set of one
-      or more expected policy values, and a criticality indicator.  If
-      the node is at depth x, the components of the node have the
-      following semantics:
-
-         (1)  The valid_policy is a single policy OID representing a
-         valid policy for the path of length x.
-
-         (2)  The qualifier_set is a set of policy qualifiers associated
-         with the valid policy in certificate x.
-
-         (3)  The criticality_indicator indicates whether the
-         certificate policy extension in certificate x was marked as
-         critical.
-
-         (4)  The expected_policy_set contains one or more policy OIDs
-         that would satisfy this policy in the certificate x+1.
-
-      The initial value of the valid_policy_tree is a single node with
-      valid_policy anyPolicy, an empty qualifier_set, an
-      expected_policy_set with the single value anyPolicy, and a
-      criticality_indicator of FALSE.  This node is considered to be at
-      depth zero.
-
-      Figure 3 is a graphic representation of the initial state of the
-      valid_policy_tree.  Additional figures will use this format to
-      describe changes in the valid_policy_tree during path processing.
-
-              +----------------+
-              |   anyPolicy    |   <---- valid_policy
-              +----------------+
-              |       {}       |   <---- qualifier_set
-              +----------------+
-              |     FALSE      |   <---- criticality_indicator
-              +----------------+
-              |  {anyPolicy}   |   <---- expected_policy_set
-              +----------------+
-
-      Figure 3.  Initial value of the valid_policy_tree state variable
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 68]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b) permitted_subtrees:  A set of root names for each name type
-      (e.g., X.500 distinguished names, email addresses, or ip
-      addresses) defining a set of subtrees within which all subject
-      names in subsequent certificates in the certification path MUST
-      fall.  This variable includes a set for each name type: the
-      initial value for the set for Distinguished Names is the set of
-      all Distinguished names; the initial value for the set of RFC822
-      names is the set of all RFC822 names, etc.
-
-      (c) excluded_subtrees:  A set of root names for each name type
-      (e.g., X.500 distinguished names, email addresses, or ip
-      addresses) defining a set of subtrees within which no subject name
-      in subsequent certificates in the certification path may fall.
-      This variable includes a set for each name type, and the initial
-      value for each set is empty.
-
-      (d) explicit_policy: an integer which indicates if a non-NULL
-      valid_policy_tree is required. The integer indicates the number of
-      non-self-issued certificates to be processed before this
-      requirement is imposed.  Once set, this variable may be decreased,
-      but may not be increased. That is, if a certificate in the path
-      requires a non-NULL valid_policy_tree, a later certificate can not
-      remove this requirement. If initial-explicit-policy is set, then
-      the initial value is 0, otherwise the initial value is n+1.
-
-      (e) inhibit_any-policy: an integer which indicates whether the
-      anyPolicy policy identifier is considered a match. The integer
-      indicates the number of non-self-issued certificates to be
-      processed before the anyPolicy OID, if asserted in a certificate,
-      is ignored. Once set, this variable may be decreased, but may not
-      be increased. That is, if a certificate in the path inhibits
-      processing of anyPolicy, a later certificate can not permit it.
-      If initial-any-policy-inhibit is set, then the initial value is 0,
-      otherwise the initial value is n+1.
-
-      (f) policy_mapping: an integer which indicates if policy mapping
-      is permitted.  The integer indicates the number of non-self-issued
-      certificates to be processed before policy mapping is inhibited.
-      Once set, this variable may be decreased, but may not be
-      increased. That is, if a certificate in the path specifies policy
-      mapping is not permitted, it can not be overridden by a later
-      certificate. If initial-policy-mapping-inhibit is set, then the
-      initial value is 0, otherwise the initial value is n+1.
-
-      (g) working_public_key_algorithm: the digital signature algorithm
-      used to verify the signature of a certificate.  The
-      working_public_key_algorithm is initialized from the trusted
-      public key algorithm provided in the trust anchor information.
-
-
-
-Housley, et. al.            Standards Track                    [Page 69]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (h) working_public_key: the public key used to verify the
-      signature of a certificate.  The working_public_key is initialized
-      from the trusted public key provided in the trust anchor
-      information.
-
-      (i) working_public_key_parameters:  parameters associated with the
-      current public key, that may be required to verify a signature
-      (depending upon the algorithm).  The working_public_key_parameters
-      variable is initialized from the trusted public key parameters
-      provided in the trust anchor information.
-
-      (j) working_issuer_name:  the issuer distinguished name expected
-      in the next certificate in the chain.  The working_issuer_name is
-      initialized to the trusted issuer provided in the trust anchor
-      information.
-
-      (k) max_path_length:  this integer is initialized to n, is
-      decremented for each non-self-issued certificate in the path, and
-      may be reduced to the value in the path length constraint field
-      within the basic constraints extension of a CA certificate.
-
-   Upon completion of the initialization steps, perform the basic
-   certificate processing steps specified in 6.1.3.
-
-6.1.3  Basic Certificate Processing
-
-   The basic path processing actions to be performed for certificate i
-   (for all i in [1..n]) are listed below.
-
-      (a)  Verify the basic certificate information.  The certificate
-      MUST satisfy each of the following:
-
-         (1)  The certificate was signed with the
-         working_public_key_algorithm using the working_public_key and
-         the working_public_key_parameters.
-
-         (2)  The certificate validity period includes the current time.
-
-         (3)  At the current time, the certificate is not revoked and is
-         not on hold status.  This may be determined by obtaining the
-         appropriate CRL (section 6.3), status information, or by out-
-         of-band mechanisms.
-
-         (4)  The certificate issuer name is the working_issuer_name.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 70]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b)  If certificate i is self-issued and it is not the final
-      certificate in the path, skip this step for certificate i.
-      Otherwise, verify that the subject name is within one of the
-      permitted_subtrees for X.500 distinguished names, and verify that
-      each of the alternative names in the subjectAltName extension
-      (critical or non-critical) is within one of the permitted_subtrees
-      for that name type.
-
-      (c)  If certificate i is self-issued and it is not the final
-      certificate in the path, skip this step for certificate i.
-      Otherwise, verify that the subject name is not within one of the
-      excluded_subtrees for X.500 distinguished names, and verify that
-      each of the alternative names in the subjectAltName extension
-      (critical or non-critical) is not within one of the
-      excluded_subtrees for that name type.
-
-      (d)  If the certificate policies extension is present in the
-      certificate and the valid_policy_tree is not NULL, process the
-      policy information by performing the following steps in order:
-
-         (1)  For each policy P not equal to anyPolicy in the
-         certificate policies extension, let P-OID denote the OID in
-         policy P and P-Q denote the qualifier set for policy P.
-         Perform the following steps in order:
-
-            (i)  If the valid_policy_tree includes a node of depth i-1
-            where P-OID is in the expected_policy_set, create a child
-            node as follows: set the valid_policy to OID-P; set the
-            qualifier_set to P-Q, and set the expected_policy_set to
-            {P-OID}.
-
-            For example, consider a valid_policy_tree with a node of
-            depth i-1 where the expected_policy_set is {Gold, White}.
-            Assume the certificate policies Gold and Silver appear in
-            the certificate policies extension of certificate i.  The
-            Gold policy is matched but the Silver policy is not.  This
-            rule will generate a child node of depth i for the Gold
-            policy. The result is shown as Figure 4.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 71]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                             +-----------------+
-                             |       Red       |
-                             +-----------------+
-                             |       {}        |
-                             +-----------------+   node of depth i-1
-                             |      FALSE      |
-                             +-----------------+
-                             |  {Gold, White}  |
-                             +-----------------+
-                                      |
-                                      |
-                                      |
-                                      V
-                             +-----------------+
-                             |      Gold       |
-                             +-----------------+
-                             |       {}        |
-                             +-----------------+ node of depth i
-                             |  uninitialized  |
-                             +-----------------+
-                             |     {Gold}      |
-                             +-----------------+
-
-                    Figure 4.  Processing an exact match
-
-            (ii)  If there was no match in step (i) and the
-            valid_policy_tree includes a node of depth i-1 with the
-            valid policy anyPolicy, generate a child node with the
-            following values: set the valid_policy to P-OID; set the
-            qualifier_set to P-Q, and set the expected_policy_set to
-            {P-OID}.
-
-            For example, consider a valid_policy_tree with a node of
-            depth i-1 where the valid_policy is anyPolicy.  Assume the
-            certificate policies Gold and Silver appear in the
-            certificate policies extension of certificate i.  The Gold
-            policy does not have a qualifier, but the Silver policy has
-            the qualifier Q-Silver.  If Gold and Silver were not matched
-            in (i) above, this rule will generate two child nodes of
-            depth i, one for each policy.  The result is shown as Figure
-            5.
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 72]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                             +-----------------+
-                             |    anyPolicy    |
-                             +-----------------+
-                             |       {}        |
-                             +-----------------+ node of depth i-1
-                             |      FALSE      |
-                             +-----------------+
-                             |   {anyPolicy}   |
-                             +-----------------+
-                                /           \
-                               /             \
-                              /               \
-                             /                 \
-               +-----------------+          +-----------------+
-               |      Gold       |          |     Silver      |
-               +-----------------+          +-----------------+
-               |       {}        |          |   {Q-Silver}    |
-               +-----------------+ nodes of +-----------------+
-               | uninitialized   | depth i  | uninitialized   |
-               +-----------------+          +-----------------+
-               |     {Gold}      |          |    {Silver}     |
-               +-----------------+          +-----------------+
-
-               Figure 5.  Processing unmatched policies when a leaf node
-               specifies anyPolicy
-
-         (2)  If the certificate policies extension includes the policy
-         anyPolicy with the qualifier set AP-Q and either (a)
-         inhibit_any-policy is greater than 0 or (b) i<n and the
-         certificate is self-issued, then:
-
-         For each node in the valid_policy_tree of depth i-1, for each
-         value in the expected_policy_set (including anyPolicy) that
-         does not appear in a child node, create a child node with the
-         following values: set the valid_policy to the value from the
-         expected_policy_set in the parent node; set the qualifier_set
-         to AP-Q, and set the expected_policy_set to the value in the
-         valid_policy from this node.
-
-         For example, consider a valid_policy_tree with a node of depth
-         i-1 where the expected_policy_set is {Gold, Silver}.  Assume
-         anyPolicy appears in the certificate policies extension of
-         certificate i, but Gold and Silver do not.  This rule will
-         generate two child nodes of depth i, one for each policy.  The
-         result is shown below as Figure 6.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 73]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                          +-----------------+
-                          |      Red        |
-                          +-----------------+
-                          |       {}        |
-                          +-----------------+ node of depth i-1
-                          |      FALSE      |
-                          +-----------------+
-                          |  {Gold, Silver} |
-                          +-----------------+
-                             /           \
-                            /             \
-                           /               \
-                          /                 \
-            +-----------------+          +-----------------+
-            |      Gold       |          |     Silver      |
-            +-----------------+          +-----------------+
-            |       {}        |          |       {}        |
-            +-----------------+ nodes of +-----------------+
-            |  uninitialized  | depth i  |  uninitialized  |
-            +-----------------+          +-----------------+
-            |     {Gold}      |          |    {Silver}     |
-            +-----------------+          +-----------------+
-
-         Figure 6.  Processing unmatched policies when the certificate
-         policies extension specifies anyPolicy
-
-         (3)  If there is a node in the valid_policy_tree of depth i-1
-         or less without any child nodes, delete that node.  Repeat this
-         step until there are no nodes of depth i-1 or less without
-         children.
-
-         For example, consider the valid_policy_tree shown in Figure 7
-         below.  The two nodes at depth i-1 that are marked with an 'X'
-         have no children, and are deleted.  Applying this rule to the
-         resulting tree will cause the node at depth i-2 that is marked
-         with an 'Y' to be deleted.  The following application of the
-         rule does not cause any nodes to be deleted, and this step is
-         complete.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 74]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-                              +-----------+
-                              |           | node of depth i-3
-                              +-----------+
-                              /     |     \
-                             /      |      \
-                            /       |       \
-                +-----------+ +-----------+ +-----------+
-                |           | |           | |     Y     | nodes of
-                +-----------+ +-----------+ +-----------+ depth i-2
-                /   \               |             |
-               /     \              |             |
-              /       \             |             |
-   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
-   |           | |     X     | |           | |    X      |  depth
-   +-----------+ +-----------+ +-----------+ +-----------+   i-1
-         |                      /    |    \
-         |                     /     |     \
-         |                    /      |      \
-   +-----------+ +-----------+ +-----------+ +-----------+ nodes of
-   |           | |           | |           | |           |  depth
-   +-----------+ +-----------+ +-----------+ +-----------+   i
-
-          Figure 7.  Pruning the valid_policy_tree
-
-         (4)  If the certificate policies extension was marked as
-         critical, set the criticality_indicator in all nodes of depth i
-         to TRUE.  If the certificate policies extension was not marked
-         critical, set the criticality_indicator in all nodes of depth i
-         to FALSE.
-
-      (e)  If the certificate policies extension is not present, set the
-      valid_policy_tree to NULL.
-
-      (f)  Verify that either explicit_policy is greater than 0 or the
-      valid_policy_tree is not equal to NULL;
-
-   If any of steps (a), (b), (c), or (f) fails, the procedure
-   terminates, returning a failure indication and an appropriate reason.
-
-   If i is not equal to n, continue by performing the preparatory steps
-   listed in 6.1.4.  If i is equal to n, perform the wrap-up steps
-   listed in 6.1.5.
-
-6.1.4  Preparation for Certificate i+1
-
-   To prepare for processing of certificate i+1, perform the following
-   steps for certificate i:
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 75]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (a)  If a policy mapping extension is present, verify that the
-      special value anyPolicy does not appear as an issuerDomainPolicy
-      or a subjectDomainPolicy.
-
-      (b)  If a policy mapping extension is present, then for each
-      issuerDomainPolicy ID-P in the policy mapping extension:
-
-         (1)  If the policy_mapping variable is greater than 0, for each
-         node in the valid_policy_tree of depth i where ID-P is the
-         valid_policy, set expected_policy_set to the set of
-         subjectDomainPolicy values that are specified as equivalent to
-         ID-P by the policy mapping extension.
-
-         If no node of depth i in the valid_policy_tree has a
-         valid_policy of ID-P but there is a node of depth i with a
-         valid_policy of anyPolicy, then generate a child node of the
-         node of depth i-1 that has a valid_policy of anyPolicy as
-         follows:
-
-            (i)  set the valid_policy to ID-P;
-
-            (ii)  set the qualifier_set to the qualifier set of the
-            policy anyPolicy in the certificate policies extension of
-            certificate i;
-
-            (iii)  set the criticality_indicator to the criticality of
-            the certificate policies extension of certificate i;
-
-            (iv)  and set the expected_policy_set to the set of
-            subjectDomainPolicy values that are specified as equivalent
-            to ID-P by the policy mappings extension.
-
-         (2)  If the policy_mapping variable is equal to 0:
-
-            (i)  delete each node of depth i in the valid_policy_tree
-            where ID-P is the valid_policy.
-
-            (ii)  If there is a node in the valid_policy_tree of depth
-            i-1 or less without any child nodes, delete that node.
-            Repeat this step until there are no nodes of depth i-1 or
-            less without children.
-
-      (c)  Assign the certificate subject name to working_issuer_name.
-
-      (d)  Assign the certificate subjectPublicKey to
-      working_public_key.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 76]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (e)  If the subjectPublicKeyInfo field of the certificate contains
-      an algorithm field with non-null parameters, assign the parameters
-      to the working_public_key_parameters variable.
-
-      If the subjectPublicKeyInfo field of the certificate contains an
-      algorithm field with null parameters or parameters are omitted,
-      compare the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm.  If the certificate subjectPublicKey
-      algorithm and the working_public_key_algorithm are different, set
-      the working_public_key_parameters to null.
-
-      (f)  Assign the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm variable.
-
-      (g)  If a name constraints extension is included in the
-      certificate, modify the permitted_subtrees and excluded_subtrees
-      state variables as follows:
-
-         (1)  If permittedSubtrees is present in the certificate, set
-         the permitted_subtrees state variable to the intersection of
-         its previous value and the value indicated in the extension
-         field.  If permittedSubtrees does not include a particular name
-         type, the permitted_subtrees state variable is unchanged for
-         that name type.  For example, the intersection of nist.gov and
-         csrc.nist.gov is csrc.nist.gov.  And, the intersection of
-         nist.gov and rsasecurity.com is the empty set.
-
-         (2)  If excludedSubtrees is present in the certificate, set the
-         excluded_subtrees state variable to the union of its previous
-         value and the value indicated in the extension field.  If
-         excludedSubtrees does not include a particular name type, the
-         excluded_subtrees state variable is unchanged for that name
-         type.  For example, the union of the name spaces nist.gov and
-         csrc.nist.gov is nist.gov.  And, the union of nist.gov and
-         rsasecurity.com is both name spaces.
-
-      (h)  If the issuer and subject names are not identical:
-
-         (1)  If explicit_policy is not 0, decrement explicit_policy by
-         1.
-
-         (2)  If policy_mapping is not 0, decrement policy_mapping by 1.
-
-         (3)  If inhibit_any-policy is not 0, decrement inhibit_any-
-         policy by 1.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 77]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (i)  If a policy constraints extension is included in the
-      certificate, modify the explicit_policy and policy_mapping state
-      variables as follows:
-
-         (1)  If requireExplicitPolicy is present and is less than
-         explicit_policy, set explicit_policy to the value of
-         requireExplicitPolicy.
-
-         (2)  If inhibitPolicyMapping is present and is less than
-         policy_mapping, set policy_mapping to the value of
-         inhibitPolicyMapping.
-
-      (j)  If the inhibitAnyPolicy extension is included in the
-      certificate and is less than inhibit_any-policy, set inhibit_any-
-      policy to the value of inhibitAnyPolicy.
-
-      (k)  Verify that the certificate is a CA certificate (as specified
-      in a basicConstraints extension or as verified out-of-band).
-
-      (l)  If the certificate was not self-issued, verify that
-      max_path_length is greater than zero and decrement max_path_length
-      by 1.
-
-      (m)  If pathLengthConstraint is present in the certificate and is
-      less than max_path_length, set max_path_length to the value of
-      pathLengthConstraint.
-
-      (n)  If a key usage extension is present, verify that the
-      keyCertSign bit is set.
-
-      (o)  Recognize and process any other critical extension present in
-      the certificate.  Process any other recognized non-critical
-      extension present in the certificate.
-
-   If check (a), (k), (l), (n) or (o) fails, the procedure terminates,
-   returning a failure indication and an appropriate reason.
-
-   If (a), (k), (l), (n) and (o) have completed successfully, increment
-   i and perform the basic certificate processing specified in 6.1.3.
-
-6.1.5  Wrap-up procedure
-
-   To complete the processing of the end entity certificate, perform the
-   following steps for certificate n:
-
-      (a)  If certificate n was not self-issued and explicit_policy is
-      not 0, decrement explicit_policy by 1.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 78]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b)  If a policy constraints extension is included in the
-      certificate and requireExplicitPolicy is present and has a value
-      of 0, set the explicit_policy state variable to 0.
-
-      (c)  Assign the certificate subjectPublicKey to
-      working_public_key.
-
-      (d)  If the subjectPublicKeyInfo field of the certificate contains
-      an algorithm field with non-null parameters, assign the parameters
-      to the working_public_key_parameters variable.
-
-      If the subjectPublicKeyInfo field of the certificate contains an
-      algorithm field with null parameters or parameters are omitted,
-      compare the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm.  If the certificate subjectPublicKey
-      algorithm and the working_public_key_algorithm are different, set
-      the working_public_key_parameters to null.
-
-      (e)  Assign the certificate subjectPublicKey algorithm to the
-      working_public_key_algorithm variable.
-
-      (f)  Recognize and process any other critical extension present in
-      the certificate n.  Process any other recognized non-critical
-      extension present in certificate n.
-
-      (g)  Calculate the intersection of the valid_policy_tree and the
-      user-initial-policy-set, as follows:
-
-         (i)  If the valid_policy_tree is NULL, the intersection is
-         NULL.
-
-         (ii)  If the valid_policy_tree is not NULL and the user-
-         initial-policy-set is any-policy, the intersection is the
-         entire valid_policy_tree.
-
-         (iii)  If the valid_policy_tree is not NULL and the user-
-         initial-policy-set is not any-policy, calculate the
-         intersection of the valid_policy_tree and the user-initial-
-         policy-set as follows:
-
-            1.  Determine the set of policy nodes whose parent nodes
-            have a valid_policy of anyPolicy.  This is the
-            valid_policy_node_set.
-
-            2.  If the valid_policy of any node in the
-            valid_policy_node_set is not in the user-initial-policy-set
-            and is not anyPolicy, delete this node and all its children.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 79]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-            3.  If the valid_policy_tree includes a node of depth n with
-            the valid_policy anyPolicy and the user-initial-policy-set
-            is not any-policy perform the following steps:
-
-               a. Set P-Q to the qualifier_set in the node of depth n
-               with valid_policy anyPolicy.
-
-               b. For each P-OID in the user-initial-policy-set that is
-               not the valid_policy of a node in the
-               valid_policy_node_set, create a child node whose parent
-               is the node of depth n-1 with the valid_policy anyPolicy.
-               Set the values in the child node as follows: set the
-               valid_policy to P-OID; set the qualifier_set to P-Q; copy
-               the criticality_indicator from the node of depth n with
-               the valid_policy anyPolicy; and set the
-               expected_policy_set to {P-OID}.
-
-               c.  Delete the node of depth n with the valid_policy
-               anyPolicy.
-
-            4.  If there is a node in the valid_policy_tree of depth n-1
-            or less without any child nodes, delete that node.  Repeat
-            this step until there are no nodes of depth n-1 or less
-            without children.
-
-   If either (1) the value of explicit_policy variable is greater than
-   zero, or (2) the valid_policy_tree is not NULL, then path processing
-   has succeeded.
-
-6.1.6  Outputs
-
-   If path processing succeeds, the procedure terminates, returning a
-   success indication together with final value of the
-   valid_policy_tree, the working_public_key, the
-   working_public_key_algorithm, and the working_public_key_parameters.
-
-6.2  Using the Path Validation Algorithm
-
-   The path validation algorithm describes the process of validating a
-   single certification path.  While each certification path begins with
-   a specific trust anchor, there is no requirement that all
-   certification paths validated by a particular system share a single
-   trust anchor.  An implementation that supports multiple trust anchors
-   MAY augment the algorithm presented in section 6.1 to further limit
-   the set of valid certification paths which begin with a particular
-   trust anchor.  For example, an implementation MAY modify the
-   algorithm to apply name constraints to a specific trust anchor during
-   the initialization phase, or the application MAY require the presence
-
-
-
-Housley, et. al.            Standards Track                    [Page 80]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   of a particular alternative name form in the end entity certificate,
-   or the application MAY impose requirements on application-specific
-   extensions.  Thus, the path validation algorithm presented in section
-   6.1 defines the minimum conditions for a path to be considered valid.
-
-   The selection of one or more trusted CAs is a local decision.  A
-   system may provide any one of its trusted CAs as the trust anchor for
-   a particular path.  The inputs to the path validation algorithm may
-   be different for each path.  The inputs used to process a path may
-   reflect application-specific requirements or limitations in the trust
-   accorded a particular trust anchor.  For example, a trusted CA may
-   only be trusted for a particular certificate policy.  This
-   restriction can be expressed through the inputs to the path
-   validation procedure.
-
-   It is also possible to specify an extended version of the above
-   certification path processing procedure which results in default
-   behavior identical to the rules of PEM [RFC 1422].  In this extended
-   version, additional inputs to the procedure are a list of one or more
-   Policy Certification Authority (PCA) names and an indicator of the
-   position in the certification path where the PCA is expected.  At the
-   nominated PCA position, the CA name is compared against this list.
-   If a recognized PCA name is found, then a constraint of
-   SubordinateToCA is implicitly assumed for the remainder of the
-   certification path and processing continues.  If no valid PCA name is
-   found, and if the certification path cannot be validated on the basis
-   of identified policies, then the certification path is considered
-   invalid.
-
-6.3  CRL Validation
-
-   This section describes the steps necessary to determine if a
-   certificate is revoked or on hold status when CRLs are the revocation
-   mechanism used by the certificate issuer.  Conforming implementations
-   that support CRLs are not required to implement this algorithm, but
-   they MUST be functionally equivalent to the external behavior
-   resulting from this procedure.  Any algorithm may be used by a
-   particular implementation so long as it derives the correct result.
-
-   This algorithm assumes that all of the needed CRLs are available in a
-   local cache.  Further, if the next update time of a CRL has passed,
-   the algorithm assumes a mechanism to fetch a current CRL and place it
-   in the local CRL cache.
-
-   This algorithm defines a set of inputs, a set of state variables, and
-   processing steps that are performed for each certificate in the path.
-   The algorithm output is the revocation status of the certificate.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 81]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-6.3.1  Revocation Inputs
-
-   To support revocation processing, the algorithm requires two inputs:
-
-      (a)  certificate:  The algorithm requires the certificate serial
-      number and issuer name to determine whether a certificate is on a
-      particular CRL.  The basicConstraints extension is used to
-      determine whether the supplied certificate is associated with a CA
-      or an end entity.  If present, the algorithm uses the
-      cRLDistributionsPoint and freshestCRL extensions to determine
-      revocation status.
-
-      (b)  use-deltas:  This boolean input determines whether delta CRLs
-      are applied to CRLs.
-
-      Note that implementations supporting legacy PKIs, such as RFC 1422
-      and X.509 version 1, will need an additional input indicating
-      whether the supplied certificate is associated with a CA or an end
-      entity.
-
-6.3.2  Initialization and Revocation State Variables
-
-   To support CRL processing, the algorithm requires the following state
-   variables:
-
-      (a)  reasons_mask:  This variable contains the set of revocation
-      reasons supported by the CRLs and delta CRLs processed so far.
-      The legal members of the set are the possible revocation reason
-      values: unspecified, keyCompromise, caCompromise,
-      affiliationChanged, superseded, cessationOfOperation,
-      certificateHold, privilegeWithdrawn, and aACompromise.  The
-      special value all-reasons is used to denote the set of all legal
-      members.  This variable is initialized to the empty set.
-
-      (b)  cert_status:  This variable contains the status of the
-      certificate.  This variable may be assigned one of the following
-      values: unspecified, keyCompromise, caCompromise,
-      affiliationChanged, superseded, cessationOfOperation,
-      certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise,
-      the special value UNREVOKED, or the special value UNDETERMINED.
-      This variable is initialized to the special value UNREVOKED.
-
-      (c)  interim_reasons_mask:  This contains the set of revocation
-      reasons supported by the CRL or delta CRL currently being
-      processed.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 82]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   Note: In some environments, it is not necessary to check all reason
-   codes.  For example, some environments are only concerned with
-   caCompromise and keyCompromise for CA certificates.  This algorithm
-   checks all reason codes.  Additional processing and state variables
-   may be necessary to limit the checking to a subset of the reason
-   codes.
-
-6.3.3  CRL Processing
-
-   This algorithm begins by assuming the certificate is not revoked.
-   The algorithm checks one or more CRLs until either the certificate
-   status is determined to be revoked or sufficient CRLs have been
-   checked to cover all reason codes.
-
-   For each distribution point (DP) in the certificate CRL distribution
-   points extension, for each corresponding CRL in the local CRL cache,
-   while ((reasons_mask is not all-reasons) and (cert_status is
-   UNREVOKED)) perform the following:
-
-      (a)  Update the local CRL cache by obtaining a complete CRL, a
-      delta CRL, or both, as required:
-
-         (1)  If the current time is after the value of the CRL next
-         update field, then do one of the following:
-
-            (i)  If use-deltas is set and either the certificate or the
-            CRL contains the freshest CRL extension, obtain a delta CRL
-            with the a next update value that is after the current time
-            and can be used to update the locally cached CRL as
-            specified in section 5.2.4.
-
-            (ii)  Update the local CRL cache with a current complete
-            CRL, verify that the current time is before the next update
-            value in the new CRL, and continue processing with the new
-            CRL.  If use-deltas is set, then obtain the current delta
-            CRL that can be used to update the new locally cached
-            complete CRL as specified in section 5.2.4.
-
-         (2)  If the current time is before the value of the next update
-         field and use-deltas is set, then obtain the current delta CRL
-         that can be used to update the locally cached complete CRL as
-         specified in section 5.2.4.
-
-      (b)  Verify the issuer and scope of the complete CRL as follows:
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 83]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-         (1)  If the DP includes cRLIssuer, then verify that the issuer
-         field in the complete CRL matches cRLIssuer in the DP and that
-         the complete CRL contains an issuing distribution point
-         extension with the indrectCRL boolean asserted.  Otherwise,
-         verify that the CRL issuer matches the certificate issuer.
-
-         (2)  If the complete CRL includes an issuing distribution point
-         (IDP) CRL extension check the following:
-
-            (i)  If the distribution point name is present in the IDP
-            CRL extension and the distribution field is present in the
-            DP, then verify that one of the names in the IDP matches one
-            of the names in the DP.  If the distribution point name is
-            present in the IDP CRL extension and the distribution field
-            is omitted from the DP, then verify that one of the names in
-            the IDP matches one of the names in the cRLIssuer field of
-            the DP.
-
-            (ii)  If the onlyContainsUserCerts boolean is asserted in
-            the IDP CRL extension, verify that the certificate does not
-            include the basic constraints extension with the cA boolean
-            asserted.
-
-            (iii)  If the onlyContainsCACerts boolean is asserted in the
-            IDP CRL extension, verify that the certificate includes the
-            basic constraints extension with the cA boolean asserted.
-
-            (iv)  Verify that the onlyContainsAttributeCerts boolean is
-            not asserted.
-
-      (c)  If use-deltas is set, verify the issuer and scope of the
-      delta CRL as follows:
-
-         (1)  Verify that the delta CRL issuer matches complete CRL
-         issuer.
-
-         (2)  If the complete CRL includes an issuing distribution point
-         (IDP) CRL extension, verify that the delta CRL contains a
-         matching IDP CRL extension.  If the complete CRL omits an IDP
-         CRL extension, verify that the delta CRL also omits an IDP CRL
-         extension.
-
-         (3)  Verify that the delta CRL authority key identifier
-         extension matches complete CRL authority key identifier
-         extension.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 84]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   (d)  Compute the interim_reasons_mask for this CRL as follows:
-
-         (1)  If the issuing distribution point (IDP) CRL extension is
-         present and includes onlySomeReasons and the DP includes
-         reasons, then set interim_reasons_mask to the intersection of
-         reasons in the DP and onlySomeReasons in IDP CRL extension.
-
-         (2)  If the IDP CRL extension includes onlySomeReasons but the
-         DP omits reasons, then set interim_reasons_mask to the value of
-         onlySomeReasons in IDP CRL extension.
-
-         (3)  If the IDP CRL extension is not present or omits
-         onlySomeReasons but the DP includes reasons, then set
-         interim_reasons_mask to the value of DP reasons.
-
-         (4)  If the IDP CRL extension is not present or omits
-         onlySomeReasons and the DP omits reasons, then set
-         interim_reasons_mask to the special value all-reasons.
-
-   (e)  Verify that interim_reasons_mask includes one or more reasons
-   that is not included in the reasons_mask.
-
-   (f)  Obtain and validate the certification path for the complete CRL
-   issuer.  If a key usage extension is present in the CRL issuer's
-   certificate, verify that the cRLSign bit is set.
-
-   (g)  Validate the signature on the complete CRL using the public key
-   validated in step (f).
-
-   (h)  If use-deltas is set, then validate the signature on the delta
-   CRL using the public key validated in step (f).
-
-   (i)  If use-deltas is set, then search for the certificate on the
-   delta CRL.  If an entry is found that matches the certificate issuer
-   and serial number as described in section 5.3.4, then set the
-   cert_status variable to the indicated reason as follows:
-
-         (1)  If the reason code CRL entry extension is present, set the
-         cert_status variable to the value of the reason code CRL entry
-         extension.
-
-         (2)  If the reason code CRL entry extension is not present, set
-         the cert_status variable to the value unspecified.
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 85]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (j)  If (cert_status is UNREVOKED), then search for the
-      certificate on the complete CRL.  If an entry is found that
-      matches the certificate issuer and serial number as described in
-      section 5.3.4, then set the cert_status variable to the indicated
-      reason as described in step (i).
-
-      (k)  If (cert_status is removeFromCRL), then set cert_status to
-      UNREVOKED.
-
-   If ((reasons_mask is all-reasons) OR (cert_status is not UNREVOKED)),
-   then the revocation status has been determined, so return
-   cert_status.
-
-   If the revocation status has not been determined, repeat the process
-   above with any available CRLs not specified in a distribution point
-   but issued by the certificate issuer.  For the processing of such a
-   CRL, assume a DP with both the reasons and the cRLIssuer fields
-   omitted and a distribution point name of the certificate issuer.
-   That is, the sequence of names in fullName is generated from the
-   certificate issuer field as well as the certificate issuerAltName
-   extension.  If the revocation status remains undetermined, then
-   return the cert_status UNDETERMINED.
-
-7  References
-
-   [ISO 10646] ISO/IEC 10646-1:1993.  International Standard --
-               Information technology -- Universal Multiple-Octet Coded
-               Character Set (UCS) -- Part 1: Architecture and Basic
-               Multilingual Plane.
-
-   [RFC 791]   Postel, J.,  "Internet Protocol", STD 5, RFC 791,
-               September 1981.
-
-   [RFC 822]   Crocker, D., "Standard for the format of ARPA Internet
-               text messages", STD 11, RFC 822, August 1982.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1422]  Kent, S., "Privacy Enhancement for Internet Electronic
-               Mail: Part II: Certificate-Based Key Management," RFC
-               1422, February 1993.
-
-   [RFC 1423]  Balenson, D., "Privacy Enhancement for Internet
-               Electronic Mail: Part III: Algorithms, Modes, and
-               Identifiers," RFC 1423, February 1993.
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 86]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   [RFC 1510]  Kohl, J. and C. Neuman, "The Kerberos Network
-               Authentication Service (V5)," RFC 1510, September 1993.
-
-   [RFC 1519]  Fuller, V., T. Li, J. Yu and K. Varadhan, "Classless
-               Inter-Domain Routing (CIDR): An Address Assignment and
-               Aggregation Strategy", RFC 1519, September 1993.
-
-   [RFC 1738]  Berners-Lee, T., L. Masinter and M. McCahill, "Uniform
-               Resource Locators (URL)", RFC 1738, December 1994.
-
-   [RFC 1778]  Howes, T., S. Kille, W. Yeong and C. Robbins, "The String
-               Representation of Standard Attribute Syntaxes," RFC 1778,
-               March 1995.
-
-   [RFC 1883]  Deering, S. and R. Hinden.  "Internet Protocol, Version 6
-               (IPv6) Specification", RFC 1883, December 1995.
-
-   [RFC 2044]  F. Yergeau, F., "UTF-8, a transformation format of
-               Unicode and ISO 10646", RFC 2044, October 1996.
-
-   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2247]  Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
-               Sataluri, "Using Domains in LDAP/X.500 Distinguished
-               Names", RFC 2247, January 1998.
-
-   [RFC 2252]  Wahl, M., A. Coulbeck, T. Howes and S. Kille,
-               "Lightweight Directory Access Protocol (v3):  Attribute
-               Syntax Definitions", RFC 2252, December 1997.
-
-   [RFC 2277]  Alvestrand, H., "IETF Policy on Character Sets and
-               Languages", BCP 18, RFC 2277, January 1998.
-
-   [RFC 2279]  Yergeau, F., "UTF-8, a transformation format of ISO
-               10646", RFC 2279, January 1998.
-
-   [RFC 2459]  Housley, R., W. Ford, W. Polk and D. Solo, "Internet
-               X.509 Public Key Infrastructure: Certificate and CRL
-               Profile", RFC 2459, January 1999.
-
-   [RFC 2560]  Myers, M., R. Ankney, A. Malpani, S. Galperin and C.
-               Adams, "Online Certificate Status Protocal - OCSP", June
-               1999.
-
-   [SDN.701]   SDN.701, "Message Security Protocol 4.0", Revision A,
-               1997-02-06.
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 87]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   [X.501]     ITU-T Recommendation X.501: Information Technology - Open
-               Systems Interconnection - The Directory: Models, 1993.
-
-   [X.509]     ITU-T Recommendation X.509 (1997 E): Information
-               Technology - Open Systems Interconnection - The
-               Directory: Authentication Framework, June 1997.
-
-   [X.520]     ITU-T Recommendation X.520: Information Technology - Open
-               Systems Interconnection - The Directory: Selected
-               Attribute Types, 1993.
-
-   [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
-               encoding rules: Specification of Basic Encoding Rules
-               (BER), Canonical Encoding Rules (CER) and Distinguished
-               Encoding Rules (DER), 1997.
-
-   [X.690]     ITU-T Recommendation X.690 Information Technology - Open
-               Systems Interconnection - Procedures for the operation of
-               OSI Registration Authorities: General procedures, 1992.
-
-   [X9.55]     ANSI X9.55-1995, Public Key Cryptography For The
-               Financial Services Industry: Extensions To Public Key
-               Certificates And Certificate Revocation Lists, 8
-               December, 1995.
-
-   [PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
-               Identifiers for the Internet X.509 Public Key
-               Infrastructure Certificate and Certificate Revocation
-               Lists (CRL) Profile", RFC 3279, April 2002.
-
-   [PKIXTSA]   Adams, C., Cain, P., Pinkas, D. and R. Zuccherato,
-               "Internet X.509 Public Key Infrastructure Time-Stamp
-               Protocol (TSP)", RFC 3161, August 2001.
-
-8  Intellectual Property Rights
-
-   The IETF has been notified of intellectual property rights claimed in
-   regard to some or all of the specification contained in this
-   document.  For more information consult the online list of claimed
-   rights (see http://www.ietf.org/ipr.html).
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-
-
-
-Housley, et. al.            Standards Track                    [Page 88]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   standards-related documentation can be found in BCP 11.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-9  Security Considerations
-
-   The majority of this specification is devoted to the format and
-   content of certificates and CRLs.  Since certificates and CRLs are
-   digitally signed, no additional integrity service is necessary.
-   Neither certificates nor CRLs need be kept secret, and unrestricted
-   and anonymous access to certificates and CRLs has no security
-   implications.
-
-   However, security factors outside the scope of this specification
-   will affect the assurance provided to certificate users.  This
-   section highlights critical issues to be considered by implementers,
-   administrators, and users.
-
-   The procedures performed by CAs and RAs to validate the binding of
-   the subject's identity to their public key greatly affect the
-   assurance that ought to be placed in the certificate.  Relying
-   parties might wish to review the CA's certificate practice statement.
-   This is particularly important when issuing certificates to other
-   CAs.
-
-   The use of a single key pair for both signature and other purposes is
-   strongly discouraged.  Use of separate key pairs for signature and
-   key management provides several benefits to the users.  The
-   ramifications associated with loss or disclosure of a signature key
-   are different from loss or disclosure of a key management key.  Using
-   separate key pairs permits a balanced and flexible response.
-   Similarly, different validity periods or key lengths for each key
-   pair may be appropriate in some application environments.
-   Unfortunately, some legacy applications (e.g., SSL) use a single key
-   pair for signature and key management.
-
-   The protection afforded private keys is a critical security factor.
-   On a small scale, failure of users to protect their private keys will
-   permit an attacker to masquerade as them, or decrypt their personal
-   information.  On a larger scale, compromise of a CA's private signing
-   key may have a catastrophic effect.  If an attacker obtains the
-   private key unnoticed, the attacker may issue bogus certificates and
-   CRLs.  Existence of bogus certificates and CRLs will undermine
-   confidence in the system.  If such a compromise is detected, all
-   certificates issued to the compromised CA MUST be revoked, preventing
-
-
-
-Housley, et. al.            Standards Track                    [Page 89]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   services between its users and users of other CAs.  Rebuilding after
-   such a compromise will be problematic, so CAs are advised to
-   implement a combination of strong technical measures (e.g., tamper-
-   resistant cryptographic modules) and appropriate management
-   procedures (e.g., separation of duties) to avoid such an incident.
-
-   Loss of a CA's private signing key may also be problematic.  The CA
-   would not be able to produce CRLs or perform normal key rollover.
-   CAs SHOULD maintain secure backup for signing keys.  The security of
-   the key backup procedures is a critical factor in avoiding key
-   compromise.
-
-   The availability and freshness of revocation information affects the
-   degree of assurance that ought to be placed in a certificate.  While
-   certificates expire naturally, events may occur during its natural
-   lifetime which negate the binding between the subject and public key.
-   If revocation information is untimely or unavailable, the assurance
-   associated with the binding is clearly reduced.  Relying parties
-   might not be able to process every critical extension that can appear
-   in a CRL.  CAs SHOULD take extra care when making revocation
-   information available only through CRLs that contain critical
-   extensions, particularly if support for those extensions is not
-   mandated by this profile.  For example, if revocation information is
-   supplied using a combination of delta CRLs and full CRLs, and the
-   delta CRLs are issued more frequently than the full CRLs, then
-   relying parties that cannot handle the critical extensions related to
-   delta CRL processing will not be able to obtain the most recent
-   revocation information.  Alternatively, if a full CRL is issued
-   whenever a delta CRL is issued, then timely revocation information
-   will be available to all relying parties.  Similarly, implementations
-   of the certification path validation mechanism described in section 6
-   that omit revocation checking provide less assurance than those that
-   support it.
-
-   The certification path validation algorithm depends on the certain
-   knowledge of the public keys (and other information) about one or
-   more trusted CAs.  The decision to trust a CA is an important
-   decision as it ultimately determines the trust afforded a
-   certificate.  The authenticated distribution of trusted CA public
-   keys (usually in the form of a "self-signed" certificate) is a
-   security critical out-of-band process that is beyond the scope of
-   this specification.
-
-   In addition, where a key compromise or CA failure occurs for a
-   trusted CA, the user will need to modify the information provided to
-   the path validation routine.  Selection of too many trusted CAs makes
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 90]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   the trusted CA information difficult to maintain.  On the other hand,
-   selection of only one trusted CA could limit users to a closed
-   community of users.
-
-   The quality of implementations that process certificates also affects
-   the degree of assurance provided.  The path validation algorithm
-   described in section 6 relies upon the integrity of the trusted CA
-   information, and especially the integrity of the public keys
-   associated with the trusted CAs.  By substituting public keys for
-   which an attacker has the private key, an attacker could trick the
-   user into accepting false certificates.
-
-   The binding between a key and certificate subject cannot be stronger
-   than the cryptographic module implementation and algorithms used to
-   generate the signature.  Short key lengths or weak hash algorithms
-   will limit the utility of a certificate.  CAs are encouraged to note
-   advances in cryptology so they can employ strong cryptographic
-   techniques.  In addition, CAs SHOULD decline to issue certificates to
-   CAs or end entities that generate weak signatures.
-
-   Inconsistent application of name comparison rules can result in
-   acceptance of invalid X.509 certification paths, or rejection of
-   valid ones.  The X.500 series of specifications defines rules for
-   comparing distinguished names that require comparison of strings
-   without regard to case, character set, multi-character white space
-   substring, or leading and trailing white space.  This specification
-   relaxes these requirements, requiring support for binary comparison
-   at a minimum.
-
-   CAs MUST encode the distinguished name in the subject field of a CA
-   certificate identically to the distinguished name in the issuer field
-   in certificates issued by that CA.  If CAs use different encodings,
-   implementations might fail to recognize name chains for paths that
-   include this certificate.  As a consequence, valid paths could be
-   rejected.
-
-   In addition, name constraints for distinguished names MUST be stated
-   identically to the encoding used in the subject field or
-   subjectAltName extension.  If not, then name constraints stated as
-   excludedSubTrees will not match and invalid paths will be accepted
-   and name constraints expressed as permittedSubtrees will not match
-   and valid paths will be rejected.  To avoid acceptance of invalid
-   paths, CAs SHOULD state name constraints for distinguished names as
-   permittedSubtrees wherever possible.
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 91]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-Appendix A.  Psuedo-ASN.1 Structures and OIDs
-
-   This section describes data objects used by conforming PKI components
-   in an "ASN.1-like" syntax.  This syntax is a hybrid of the 1988 and
-   1993 ASN.1 syntaxes.  The 1988 ASN.1 syntax is augmented with 1993
-   UNIVERSAL Types UniversalString, BMPString and UTF8String.
-
-   The ASN.1 syntax does not permit the inclusion of type statements in
-   the ASN.1 module, and the 1993 ASN.1 standard does not permit use of
-   the new UNIVERSAL types in modules using the 1988 syntax.  As a
-   result, this module does not conform to either version of the ASN.1
-   standard.
-
-   This appendix may be converted into 1988 ASN.1 by replacing the
-   definitions for the UNIVERSAL Types with the 1988 catch-all "ANY".
-
-A.1 Explicitly Tagged Module, 1988 Syntax
-
-PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1)
-  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) }
-
-DEFINITIONS EXPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
--- IMPORTS NONE --
-
--- UNIVERSAL Types defined in 1993 and 1998 ASN.1
--- and required by this specification
-
-UniversalString ::= [UNIVERSAL 28] IMPLICIT OCTET STRING
-        -- UniversalString is defined in ASN.1:1993
-
-BMPString ::= [UNIVERSAL 30] IMPLICIT OCTET STRING
-      -- BMPString is the subtype of UniversalString and models
-      -- the Basic Multilingual Plane of ISO/IEC/ITU 10646-1
-
-UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-      -- The content of this type conforms to RFC 2279.
-
--- PKIX specific OIDs
-
-id-pkix  OBJECT IDENTIFIER  ::=
-         { iso(1) identified-organization(3) dod(6) internet(1)
-                    security(5) mechanisms(5) pkix(7) }
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 92]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- PKIX arcs
-
-id-pe OBJECT IDENTIFIER  ::=  { id-pkix 1 }
-        -- arc for private certificate extensions
-id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }
-        -- arc for policy qualifier types
-id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
-        -- arc for extended key purpose OIDS
-id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
-        -- arc for access descriptors
-
--- policyQualifierIds for Internet policy qualifiers
-
-id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
-      -- OID for CPS qualifier
-id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }
-      -- OID for user notice qualifier
-
--- access descriptor definitions
-
-id-ad-ocsp         OBJECT IDENTIFIER ::= { id-ad 1 }
-id-ad-caIssuers    OBJECT IDENTIFIER ::= { id-ad 2 }
-id-ad-timeStamping OBJECT IDENTIFIER ::= { id-ad 3 }
-id-ad-caRepository OBJECT IDENTIFIER ::= { id-ad 5 }
-
--- attribute data types
-
-Attribute       ::=     SEQUENCE {
-      type              AttributeType,
-      values    SET OF AttributeValue }
-            -- at least one value is required
-
-AttributeType           ::=  OBJECT IDENTIFIER
-
-AttributeValue          ::=  ANY
-
-AttributeTypeAndValue           ::=     SEQUENCE {
-        type    AttributeType,
-        value   AttributeValue }
-
--- suggested naming attributes: Definition of the following
---   information object set may be augmented to meet local
---   requirements.  Note that deleting members of the set may
---   prevent interoperability with conforming implementations.
--- presented in pairs: the AttributeType followed by the
---   type definition for the corresponding AttributeValue
---Arc for standard naming attributes
-id-at OBJECT IDENTIFIER ::= { joint-iso-ccitt(2) ds(5) 4 }
-
-
-
-Housley, et. al.            Standards Track                    [Page 93]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Naming attributes of type X520name
-
-id-at-name              AttributeType ::= { id-at 41 }
-id-at-surname           AttributeType ::= { id-at 4 }
-id-at-givenName         AttributeType ::= { id-at 42 }
-id-at-initials          AttributeType ::= { id-at 43 }
-id-at-generationQualifier AttributeType ::= { id-at 44 }
-
-X520name ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-name)),
-      printableString   PrintableString (SIZE (1..ub-name)),
-      universalString   UniversalString (SIZE (1..ub-name)),
-      utf8String        UTF8String      (SIZE (1..ub-name)),
-      bmpString         BMPString       (SIZE (1..ub-name)) }
-
--- Naming attributes of type X520CommonName
-
-id-at-commonName        AttributeType ::= { id-at 3 }
-
-X520CommonName ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-common-name)),
-      printableString   PrintableString (SIZE (1..ub-common-name)),
-      universalString   UniversalString (SIZE (1..ub-common-name)),
-      utf8String        UTF8String      (SIZE (1..ub-common-name)),
-      bmpString         BMPString       (SIZE (1..ub-common-name)) }
-
--- Naming attributes of type X520LocalityName
-
-id-at-localityName      AttributeType ::= { id-at 7 }
-
-X520LocalityName ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-locality-name)),
-      printableString   PrintableString (SIZE (1..ub-locality-name)),
-      universalString   UniversalString (SIZE (1..ub-locality-name)),
-      utf8String        UTF8String      (SIZE (1..ub-locality-name)),
-      bmpString         BMPString       (SIZE (1..ub-locality-name)) }
-
--- Naming attributes of type X520StateOrProvinceName
-
-id-at-stateOrProvinceName AttributeType ::= { id-at 8 }
-
-X520StateOrProvinceName ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-state-name)),
-      printableString   PrintableString (SIZE (1..ub-state-name)),
-      universalString   UniversalString (SIZE (1..ub-state-name)),
-      utf8String        UTF8String      (SIZE (1..ub-state-name)),
-      bmpString         BMPString       (SIZE(1..ub-state-name)) }
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 94]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Naming attributes of type X520OrganizationName
-
-id-at-organizationName  AttributeType ::= { id-at 10 }
-
-X520OrganizationName ::= CHOICE {
-      teletexString     TeletexString
-                          (SIZE (1..ub-organization-name)),
-      printableString   PrintableString
-                          (SIZE (1..ub-organization-name)),
-      universalString   UniversalString
-                          (SIZE (1..ub-organization-name)),
-      utf8String        UTF8String
-                          (SIZE (1..ub-organization-name)),
-      bmpString         BMPString
-                          (SIZE (1..ub-organization-name))  }
-
--- Naming attributes of type X520OrganizationalUnitName
-
-id-at-organizationalUnitName AttributeType ::= { id-at 11 }
-
-X520OrganizationalUnitName ::= CHOICE {
-      teletexString     TeletexString
-                          (SIZE (1..ub-organizational-unit-name)),
-      printableString   PrintableString
-                          (SIZE (1..ub-organizational-unit-name)),
-      universalString   UniversalString
-                          (SIZE (1..ub-organizational-unit-name)),
-      utf8String        UTF8String
-                          (SIZE (1..ub-organizational-unit-name)),
-      bmpString         BMPString
-                          (SIZE (1..ub-organizational-unit-name)) }
-
--- Naming attributes of type X520Title
-
-id-at-title             AttributeType ::= { id-at 12 }
-
-X520Title ::= CHOICE {
-      teletexString     TeletexString   (SIZE (1..ub-title)),
-      printableString   PrintableString (SIZE (1..ub-title)),
-      universalString   UniversalString (SIZE (1..ub-title)),
-      utf8String        UTF8String      (SIZE (1..ub-title)),
-      bmpString         BMPString       (SIZE (1..ub-title)) }
-
--- Naming attributes of type X520dnQualifier
-
-id-at-dnQualifier       AttributeType ::= { id-at 46 }
-
-X520dnQualifier ::=     PrintableString
-
-
-
-Housley, et. al.            Standards Track                    [Page 95]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Naming attributes of type X520countryName (digraph from IS 3166)
-
-id-at-countryName       AttributeType ::= { id-at 6 }
-
-X520countryName ::=     PrintableString (SIZE (2))
-
--- Naming attributes of type X520SerialNumber
-
-id-at-serialNumber      AttributeType ::= { id-at 5 }
-
-X520SerialNumber ::=    PrintableString (SIZE (1..ub-serial-number))
-
--- Naming attributes of type X520Pseudonym
-
-id-at-pseudonym         AttributeType ::= { id-at 65 }
-
-X520Pseudonym ::= CHOICE {
-   teletexString     TeletexString   (SIZE (1..ub-pseudonym)),
-   printableString   PrintableString (SIZE (1..ub-pseudonym)),
-   universalString   UniversalString (SIZE (1..ub-pseudonym)),
-   utf8String        UTF8String      (SIZE (1..ub-pseudonym)),
-   bmpString         BMPString       (SIZE (1..ub-pseudonym)) }
-
--- Naming attributes of type DomainComponent (from RFC 2247)
-
-id-domainComponent      AttributeType ::=
-                          { 0 9 2342 19200300 100 1 25 }
-
-DomainComponent ::=     IA5String
-
--- Legacy attributes
-
-pkcs-9 OBJECT IDENTIFIER ::=
-       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 9 }
-
-id-emailAddress          AttributeType ::= { pkcs-9 1 }
-
-EmailAddress ::=         IA5String (SIZE (1..ub-emailaddress-length))
-
--- naming data types --
-
-Name ::= CHOICE { -- only one possibility for now --
-      rdnSequence  RDNSequence }
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-DistinguishedName ::=   RDNSequence
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 96]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-RelativeDistinguishedName  ::=
-                    SET SIZE (1 .. MAX) OF AttributeTypeAndValue
-
--- Directory string type --
-
-DirectoryString ::= CHOICE {
-      teletexString             TeletexString   (SIZE (1..MAX)),
-      printableString           PrintableString (SIZE (1..MAX)),
-      universalString           UniversalString (SIZE (1..MAX)),
-      utf8String              UTF8String      (SIZE (1..MAX)),
-      bmpString               BMPString       (SIZE (1..MAX)) }
-
--- certificate and CRL specific structures begin here
-
-Certificate  ::=  SEQUENCE  {
-     tbsCertificate       TBSCertificate,
-     signatureAlgorithm   AlgorithmIdentifier,
-     signature            BIT STRING  }
-
-TBSCertificate  ::=  SEQUENCE  {
-     version         [0]  Version DEFAULT v1,
-     serialNumber         CertificateSerialNumber,
-     signature            AlgorithmIdentifier,
-     issuer               Name,
-     validity             Validity,
-     subject              Name,
-     subjectPublicKeyInfo SubjectPublicKeyInfo,
-     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
-                          -- If present, version MUST be v2 or v3
-     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
-                          -- If present, version MUST be v2 or v3
-     extensions      [3]  Extensions OPTIONAL
-                          -- If present, version MUST be v3 --  }
-
-Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }
-
-CertificateSerialNumber  ::=  INTEGER
-
-Validity ::= SEQUENCE {
-     notBefore      Time,
-     notAfter       Time  }
-
-Time ::= CHOICE {
-     utcTime        UTCTime,
-     generalTime    GeneralizedTime }
-
-UniqueIdentifier  ::=  BIT STRING
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 97]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-SubjectPublicKeyInfo  ::=  SEQUENCE  {
-     algorithm            AlgorithmIdentifier,
-     subjectPublicKey     BIT STRING  }
-
-Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
-
-Extension  ::=  SEQUENCE  {
-     extnID      OBJECT IDENTIFIER,
-     critical    BOOLEAN DEFAULT FALSE,
-     extnValue   OCTET STRING  }
-
--- CRL structures
-
-CertificateList  ::=  SEQUENCE  {
-     tbsCertList          TBSCertList,
-     signatureAlgorithm   AlgorithmIdentifier,
-     signature            BIT STRING  }
-
-TBSCertList  ::=  SEQUENCE  {
-     version                 Version OPTIONAL,
-                                  -- if present, MUST be v2
-     signature               AlgorithmIdentifier,
-     issuer                  Name,
-     thisUpdate              Time,
-     nextUpdate              Time OPTIONAL,
-     revokedCertificates     SEQUENCE OF SEQUENCE  {
-          userCertificate         CertificateSerialNumber,
-          revocationDate          Time,
-          crlEntryExtensions      Extensions OPTIONAL
-                                         -- if present, MUST be v2
-                               }  OPTIONAL,
-     crlExtensions           [0] Extensions OPTIONAL }
-                                         -- if present, MUST be v2
-
--- Version, Time, CertificateSerialNumber, and Extensions were
--- defined earlier for use in the certificate structure
-
-AlgorithmIdentifier  ::=  SEQUENCE  {
-     algorithm               OBJECT IDENTIFIER,
-     parameters              ANY DEFINED BY algorithm OPTIONAL  }
-                                -- contains a value of the type
-                                -- registered for use with the
-                                -- algorithm object identifier value
-
--- X.400 address syntax starts here
-
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 98]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-ORAddress ::= SEQUENCE {
-   built-in-standard-attributes BuiltInStandardAttributes,
-   built-in-domain-defined-attributes
-                   BuiltInDomainDefinedAttributes OPTIONAL,
-   -- see also teletex-domain-defined-attributes
-   extension-attributes ExtensionAttributes OPTIONAL }
-
--- Built-in Standard Attributes
-
-BuiltInStandardAttributes ::= SEQUENCE {
-   country-name                  CountryName OPTIONAL,
-   administration-domain-name    AdministrationDomainName OPTIONAL,
-   network-address           [0] IMPLICIT NetworkAddress OPTIONAL,
-     -- see also extended-network-address
-   terminal-identifier       [1] IMPLICIT TerminalIdentifier OPTIONAL,
-   private-domain-name       [2] PrivateDomainName OPTIONAL,
-   organization-name         [3] IMPLICIT OrganizationName OPTIONAL,
-     -- see also teletex-organization-name
-   numeric-user-identifier   [4] IMPLICIT NumericUserIdentifier
-                                 OPTIONAL,
-   personal-name             [5] IMPLICIT PersonalName OPTIONAL,
-     -- see also teletex-personal-name
-   organizational-unit-names [6] IMPLICIT OrganizationalUnitNames
-                                 OPTIONAL }
-     -- see also teletex-organizational-unit-names
-
-CountryName ::= [APPLICATION 1] CHOICE {
-   x121-dcc-code         NumericString
-                           (SIZE (ub-country-name-numeric-length)),
-   iso-3166-alpha2-code  PrintableString
-                           (SIZE (ub-country-name-alpha-length)) }
-
-AdministrationDomainName ::= [APPLICATION 2] CHOICE {
-   numeric   NumericString   (SIZE (0..ub-domain-name-length)),
-   printable PrintableString (SIZE (0..ub-domain-name-length)) }
-
-NetworkAddress ::= X121Address  -- see also extended-network-address
-
-X121Address ::= NumericString (SIZE (1..ub-x121-address-length))
-
-TerminalIdentifier ::= PrintableString (SIZE
-(1..ub-terminal-id-length))
-
-PrivateDomainName ::= CHOICE {
-   numeric   NumericString   (SIZE (1..ub-domain-name-length)),
-   printable PrintableString (SIZE (1..ub-domain-name-length)) }
-
-
-
-
-
-Housley, et. al.            Standards Track                    [Page 99]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-OrganizationName ::= PrintableString
-                            (SIZE (1..ub-organization-name-length))
-  -- see also teletex-organization-name
-
-NumericUserIdentifier ::= NumericString
-                            (SIZE (1..ub-numeric-user-id-length))
-
-PersonalName ::= SET {
-   surname     [0] IMPLICIT PrintableString
-                    (SIZE (1..ub-surname-length)),
-   given-name  [1] IMPLICIT PrintableString
-                    (SIZE (1..ub-given-name-length)) OPTIONAL,
-   initials    [2] IMPLICIT PrintableString
-                    (SIZE (1..ub-initials-length)) OPTIONAL,
-   generation-qualifier [3] IMPLICIT PrintableString
-                    (SIZE (1..ub-generation-qualifier-length))
-                    OPTIONAL }
-  -- see also teletex-personal-name
-
-OrganizationalUnitNames ::= SEQUENCE SIZE (1..ub-organizational-units)
-                             OF OrganizationalUnitName
-  -- see also teletex-organizational-unit-names
-
-OrganizationalUnitName ::= PrintableString (SIZE
-                    (1..ub-organizational-unit-name-length))
-
--- Built-in Domain-defined Attributes
-
-BuiltInDomainDefinedAttributes ::= SEQUENCE SIZE
-                    (1..ub-domain-defined-attributes) OF
-                    BuiltInDomainDefinedAttribute
-
-BuiltInDomainDefinedAttribute ::= SEQUENCE {
-   type PrintableString (SIZE
-                   (1..ub-domain-defined-attribute-type-length)),
-   value PrintableString (SIZE
-                   (1..ub-domain-defined-attribute-value-length)) }
-
--- Extension Attributes
-
-ExtensionAttributes ::= SET SIZE (1..ub-extension-attributes) OF
-               ExtensionAttribute
-
-ExtensionAttribute ::=  SEQUENCE {
-   extension-attribute-type [0] IMPLICIT INTEGER
-                   (0..ub-extension-attributes),
-   extension-attribute-value [1]
-                   ANY DEFINED BY extension-attribute-type }
-
-
-
-Housley, et. al.            Standards Track                   [Page 100]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- Extension types and attribute values
-
-common-name INTEGER ::= 1
-
-CommonName ::= PrintableString (SIZE (1..ub-common-name-length))
-
-teletex-common-name INTEGER ::= 2
-
-TeletexCommonName ::= TeletexString (SIZE (1..ub-common-name-length))
-
-teletex-organization-name INTEGER ::= 3
-
-TeletexOrganizationName ::=
-                TeletexString (SIZE (1..ub-organization-name-length))
-
-teletex-personal-name INTEGER ::= 4
-
-TeletexPersonalName ::= SET {
-   surname     [0] IMPLICIT TeletexString
-                    (SIZE (1..ub-surname-length)),
-   given-name  [1] IMPLICIT TeletexString
-                    (SIZE (1..ub-given-name-length)) OPTIONAL,
-   initials    [2] IMPLICIT TeletexString
-                    (SIZE (1..ub-initials-length)) OPTIONAL,
-   generation-qualifier [3] IMPLICIT TeletexString
-                    (SIZE (1..ub-generation-qualifier-length))
-                    OPTIONAL }
-
-teletex-organizational-unit-names INTEGER ::= 5
-
-TeletexOrganizationalUnitNames ::= SEQUENCE SIZE
-      (1..ub-organizational-units) OF TeletexOrganizationalUnitName
-
-TeletexOrganizationalUnitName ::= TeletexString
-                  (SIZE (1..ub-organizational-unit-name-length))
-
-pds-name INTEGER ::= 7
-
-PDSName ::= PrintableString (SIZE (1..ub-pds-name-length))
-
-physical-delivery-country-name INTEGER ::= 8
-
-PhysicalDeliveryCountryName ::= CHOICE {
-   x121-dcc-code NumericString (SIZE
-(ub-country-name-numeric-length)),
-   iso-3166-alpha2-code PrintableString
-                  (SIZE (ub-country-name-alpha-length)) }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 101]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-postal-code INTEGER ::= 9
-
-PostalCode ::= CHOICE {
-   numeric-code NumericString (SIZE (1..ub-postal-code-length)),
-   printable-code PrintableString (SIZE (1..ub-postal-code-length)) }
-
-physical-delivery-office-name INTEGER ::= 10
-
-PhysicalDeliveryOfficeName ::= PDSParameter
-
-physical-delivery-office-number INTEGER ::= 11
-
-PhysicalDeliveryOfficeNumber ::= PDSParameter
-
-extension-OR-address-components INTEGER ::= 12
-
-ExtensionORAddressComponents ::= PDSParameter
-
-physical-delivery-personal-name INTEGER ::= 13
-
-PhysicalDeliveryPersonalName ::= PDSParameter
-
-physical-delivery-organization-name INTEGER ::= 14
-
-PhysicalDeliveryOrganizationName ::= PDSParameter
-
-extension-physical-delivery-address-components INTEGER ::= 15
-
-ExtensionPhysicalDeliveryAddressComponents ::= PDSParameter
-
-unformatted-postal-address INTEGER ::= 16
-
-UnformattedPostalAddress ::= SET {
-   printable-address SEQUENCE SIZE (1..ub-pds-physical-address-lines)
-         OF PrintableString (SIZE (1..ub-pds-parameter-length))
-         OPTIONAL,
-   teletex-string TeletexString
-         (SIZE (1..ub-unformatted-address-length)) OPTIONAL }
-
-street-address INTEGER ::= 17
-
-StreetAddress ::= PDSParameter
-
-post-office-box-address INTEGER ::= 18
-
-PostOfficeBoxAddress ::= PDSParameter
-
-poste-restante-address INTEGER ::= 19
-
-
-
-Housley, et. al.            Standards Track                   [Page 102]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-PosteRestanteAddress ::= PDSParameter
-
-unique-postal-name INTEGER ::= 20
-
-UniquePostalName ::= PDSParameter
-
-local-postal-attributes INTEGER ::= 21
-
-LocalPostalAttributes ::= PDSParameter
-
-PDSParameter ::= SET {
-   printable-string PrintableString
-                (SIZE(1..ub-pds-parameter-length)) OPTIONAL,
-   teletex-string TeletexString
-                (SIZE(1..ub-pds-parameter-length)) OPTIONAL }
-
-extended-network-address INTEGER ::= 22
-
-ExtendedNetworkAddress ::= CHOICE {
-   e163-4-address SEQUENCE {
-      number      [0] IMPLICIT NumericString
-                       (SIZE (1..ub-e163-4-number-length)),
-      sub-address [1] IMPLICIT NumericString
-                       (SIZE (1..ub-e163-4-sub-address-length))
-                       OPTIONAL },
-   psap-address [0] IMPLICIT PresentationAddress }
-
-PresentationAddress ::= SEQUENCE {
-    pSelector     [0] EXPLICIT OCTET STRING OPTIONAL,
-    sSelector     [1] EXPLICIT OCTET STRING OPTIONAL,
-    tSelector     [2] EXPLICIT OCTET STRING OPTIONAL,
-    nAddresses    [3] EXPLICIT SET SIZE (1..MAX) OF OCTET STRING }
-
-terminal-type  INTEGER ::= 23
-
-TerminalType ::= INTEGER {
-   telex (3),
-   teletex (4),
-   g3-facsimile (5),
-   g4-facsimile (6),
-   ia5-terminal (7),
-   videotex (8) } (0..ub-integer-options)
-
--- Extension Domain-defined Attributes
-
-teletex-domain-defined-attributes INTEGER ::= 6
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 103]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-TeletexDomainDefinedAttributes ::= SEQUENCE SIZE
-   (1..ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
-
-TeletexDomainDefinedAttribute ::= SEQUENCE {
-        type TeletexString
-               (SIZE (1..ub-domain-defined-attribute-type-length)),
-        value TeletexString
-               (SIZE (1..ub-domain-defined-attribute-value-length)) }
-
---  specifications of Upper Bounds MUST be regarded as mandatory
---  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
---  Upper Bounds
-
--- Upper Bounds
-ub-name INTEGER ::= 32768
-ub-common-name INTEGER ::= 64
-ub-locality-name INTEGER ::= 128
-ub-state-name INTEGER ::= 128
-ub-organization-name INTEGER ::= 64
-ub-organizational-unit-name INTEGER ::= 64
-ub-title INTEGER ::= 64
-ub-serial-number INTEGER ::= 64
-ub-match INTEGER ::= 128
-ub-emailaddress-length INTEGER ::= 128
-ub-common-name-length INTEGER ::= 64
-ub-country-name-alpha-length INTEGER ::= 2
-ub-country-name-numeric-length INTEGER ::= 3
-ub-domain-defined-attributes INTEGER ::= 4
-ub-domain-defined-attribute-type-length INTEGER ::= 8
-ub-domain-defined-attribute-value-length INTEGER ::= 128
-ub-domain-name-length INTEGER ::= 16
-ub-extension-attributes INTEGER ::= 256
-ub-e163-4-number-length INTEGER ::= 15
-ub-e163-4-sub-address-length INTEGER ::= 40
-ub-generation-qualifier-length INTEGER ::= 3
-ub-given-name-length INTEGER ::= 16
-ub-initials-length INTEGER ::= 5
-ub-integer-options INTEGER ::= 256
-ub-numeric-user-id-length INTEGER ::= 32
-ub-organization-name-length INTEGER ::= 64
-ub-organizational-unit-name-length INTEGER ::= 32
-ub-organizational-units INTEGER ::= 4
-ub-pds-name-length INTEGER ::= 16
-ub-pds-parameter-length INTEGER ::= 30
-ub-pds-physical-address-lines INTEGER ::= 6
-ub-postal-code-length INTEGER ::= 16
-ub-pseudonym INTEGER ::= 128
-ub-surname-length INTEGER ::= 40
-
-
-
-Housley, et. al.            Standards Track                   [Page 104]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-ub-terminal-id-length INTEGER ::= 24
-ub-unformatted-address-length INTEGER ::= 180
-ub-x121-address-length INTEGER ::= 16
-
--- Note - upper bounds on string types, such as TeletexString, are
--- measured in characters.  Excepting PrintableString or IA5String, a
--- significantly greater number of octets will be required to hold
--- such a value.  As a minimum, 16 octets, or twice the specified
--- upper bound, whichever is the larger, should be allowed for
--- TeletexString.  For UTF8String or UniversalString at least four
--- times the upper bound should be allowed.
-
-END
-
-A.2 Implicitly Tagged Module, 1988 Syntax
-
-PKIX1Implicit88 { iso(1) identified-organization(3) dod(6) internet(1)
-  security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19) }
-
-DEFINITIONS IMPLICIT TAGS ::=
-
-BEGIN
-
--- EXPORTS ALL --
-
-IMPORTS
-      id-pe, id-kp, id-qt-unotice, id-qt-cps,
-      -- delete following line if "new" types are supported --
-      BMPString, UTF8String,  -- end "new" types --
-      ORAddress, Name, RelativeDistinguishedName,
-      CertificateSerialNumber, Attribute, DirectoryString
-      FROM PKIX1Explicit88 { iso(1) identified-organization(3)
-            dod(6) internet(1) security(5) mechanisms(5) pkix(7)
-            id-mod(0) id-pkix1-explicit(18) };
-
-
--- ISO arc for standard certificate and CRL extensions
-
-id-ce OBJECT IDENTIFIER  ::=  {joint-iso-ccitt(2) ds(5) 29}
-
--- authority key identifier OID and syntax
-
-id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 35 }
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 105]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-AuthorityKeyIdentifier ::= SEQUENCE {
-    keyIdentifier             [0] KeyIdentifier            OPTIONAL,
-    authorityCertIssuer       [1] GeneralNames             OPTIONAL,
-    authorityCertSerialNumber [2] CertificateSerialNumber  OPTIONAL }
-    -- authorityCertIssuer and authorityCertSerialNumber MUST both
-    -- be present or both be absent
-
-KeyIdentifier ::= OCTET STRING
-
--- subject key identifier OID and syntax
-
-id-ce-subjectKeyIdentifier OBJECT IDENTIFIER ::=  { id-ce 14 }
-
-SubjectKeyIdentifier ::= KeyIdentifier
-
--- key usage extension OID and syntax
-
-id-ce-keyUsage OBJECT IDENTIFIER ::=  { id-ce 15 }
-
-KeyUsage ::= BIT STRING {
-     digitalSignature        (0),
-     nonRepudiation          (1),
-     keyEncipherment         (2),
-     dataEncipherment        (3),
-     keyAgreement            (4),
-     keyCertSign             (5),
-     cRLSign                 (6),
-     encipherOnly            (7),
-     decipherOnly            (8) }
-
--- private key usage period extension OID and syntax
-
-id-ce-privateKeyUsagePeriod OBJECT IDENTIFIER ::=  { id-ce 16 }
-
-PrivateKeyUsagePeriod ::= SEQUENCE {
-     notBefore       [0]     GeneralizedTime OPTIONAL,
-     notAfter        [1]     GeneralizedTime OPTIONAL }
-     -- either notBefore or notAfter MUST be present
-
--- certificate policies extension OID and syntax
-
-id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }
-
-anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 }
-
-CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
-
-PolicyInformation ::= SEQUENCE {
-
-
-
-Housley, et. al.            Standards Track                   [Page 106]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-     policyIdentifier   CertPolicyId,
-     policyQualifiers   SEQUENCE SIZE (1..MAX) OF
-             PolicyQualifierInfo OPTIONAL }
-
-CertPolicyId ::= OBJECT IDENTIFIER
-
-PolicyQualifierInfo ::= SEQUENCE {
-       policyQualifierId  PolicyQualifierId,
-       qualifier        ANY DEFINED BY policyQualifierId }
-
--- Implementations that recognize additional policy qualifiers MUST
--- augment the following definition for PolicyQualifierId
-
-PolicyQualifierId ::=
-    OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )
-
--- CPS pointer qualifier
-
-CPSuri ::= IA5String
-
--- user notice qualifier
-
-UserNotice ::= SEQUENCE {
-     noticeRef        NoticeReference OPTIONAL,
-     explicitText     DisplayText OPTIONAL}
-
-NoticeReference ::= SEQUENCE {
-     organization     DisplayText,
-     noticeNumbers    SEQUENCE OF INTEGER }
-
-DisplayText ::= CHOICE {
-     ia5String        IA5String      (SIZE (1..200)),
-     visibleString    VisibleString  (SIZE (1..200)),
-     bmpString        BMPString      (SIZE (1..200)),
-     utf8String       UTF8String     (SIZE (1..200)) }
-
--- policy mapping extension OID and syntax
-
-id-ce-policyMappings OBJECT IDENTIFIER ::=  { id-ce 33 }
-
-PolicyMappings ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE {
-     issuerDomainPolicy      CertPolicyId,
-     subjectDomainPolicy     CertPolicyId }
-
--- subject alternative name extension OID and syntax
-
-id-ce-subjectAltName OBJECT IDENTIFIER ::=  { id-ce 17 }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 107]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-SubjectAltName ::= GeneralNames
-
-GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
-
-GeneralName ::= CHOICE {
-     otherName                       [0]     AnotherName,
-     rfc822Name                      [1]     IA5String,
-     dNSName                         [2]     IA5String,
-     x400Address                     [3]     ORAddress,
-     directoryName                   [4]     Name,
-     ediPartyName                    [5]     EDIPartyName,
-     uniformResourceIdentifier       [6]     IA5String,
-     iPAddress                       [7]     OCTET STRING,
-     registeredID                    [8]     OBJECT IDENTIFIER }
-
--- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
--- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax
-
-AnotherName ::= SEQUENCE {
-     type-id    OBJECT IDENTIFIER,
-     value      [0] EXPLICIT ANY DEFINED BY type-id }
-
-EDIPartyName ::= SEQUENCE {
-     nameAssigner            [0]     DirectoryString OPTIONAL,
-     partyName               [1]     DirectoryString }
-
--- issuer alternative name extension OID and syntax
-
-id-ce-issuerAltName OBJECT IDENTIFIER ::=  { id-ce 18 }
-
-IssuerAltName ::= GeneralNames
-
-id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::=  { id-ce 9 }
-
-SubjectDirectoryAttributes ::= SEQUENCE SIZE (1..MAX) OF Attribute
-
--- basic constraints extension OID and syntax
-
-id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }
-
-BasicConstraints ::= SEQUENCE {
-     cA                      BOOLEAN DEFAULT FALSE,
-     pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
-
--- name constraints extension OID and syntax
-
-id-ce-nameConstraints OBJECT IDENTIFIER ::=  { id-ce 30 }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 108]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-NameConstraints ::= SEQUENCE {
-     permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
-     excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }
-
-GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
-
-GeneralSubtree ::= SEQUENCE {
-     base                    GeneralName,
-     minimum         [0]     BaseDistance DEFAULT 0,
-     maximum         [1]     BaseDistance OPTIONAL }
-
-BaseDistance ::= INTEGER (0..MAX)
-
--- policy constraints extension OID and syntax
-
-id-ce-policyConstraints OBJECT IDENTIFIER ::=  { id-ce 36 }
-
-PolicyConstraints ::= SEQUENCE {
-     requireExplicitPolicy           [0] SkipCerts OPTIONAL,
-     inhibitPolicyMapping            [1] SkipCerts OPTIONAL }
-
-SkipCerts ::= INTEGER (0..MAX)
-
--- CRL distribution points extension OID and syntax
-
-id-ce-cRLDistributionPoints     OBJECT IDENTIFIER  ::=  {id-ce 31}
-
-CRLDistributionPoints ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint
-
-DistributionPoint ::= SEQUENCE {
-     distributionPoint       [0]     DistributionPointName OPTIONAL,
-     reasons                 [1]     ReasonFlags OPTIONAL,
-     cRLIssuer               [2]     GeneralNames OPTIONAL }
-
-DistributionPointName ::= CHOICE {
-     fullName                [0]     GeneralNames,
-     nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
-
-ReasonFlags ::= BIT STRING {
-     unused                  (0),
-     keyCompromise           (1),
-     cACompromise            (2),
-     affiliationChanged      (3),
-     superseded              (4),
-     cessationOfOperation    (5),
-     certificateHold         (6),
-     privilegeWithdrawn      (7),
-     aACompromise            (8) }
-
-
-
-Housley, et. al.            Standards Track                   [Page 109]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
--- extended key usage extension OID and syntax
-
-id-ce-extKeyUsage OBJECT IDENTIFIER ::= {id-ce 37}
-
-ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
-
-
-KeyPurposeId ::= OBJECT IDENTIFIER
-
--- permit unspecified key uses
-
-anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
-
--- extended key purpose OIDs
-
-id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
-id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
-id-kp-codeSigning            OBJECT IDENTIFIER ::= { id-kp 3 }
-id-kp-emailProtection        OBJECT IDENTIFIER ::= { id-kp 4 }
-id-kp-timeStamping           OBJECT IDENTIFIER ::= { id-kp 8 }
-id-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }
-
--- inhibit any policy OID and syntax
-
-id-ce-inhibitAnyPolicy OBJECT IDENTIFIER ::=  { id-ce 54 }
-
-InhibitAnyPolicy ::= SkipCerts
-
--- freshest (delta)CRL extension OID and syntax
-
-id-ce-freshestCRL OBJECT IDENTIFIER ::=  { id-ce 46 }
-
-FreshestCRL ::= CRLDistributionPoints
-
--- authority info access
-
-id-pe-authorityInfoAccess OBJECT IDENTIFIER ::= { id-pe 1 }
-
-AuthorityInfoAccessSyntax  ::=
-        SEQUENCE SIZE (1..MAX) OF AccessDescription
-
-AccessDescription  ::=  SEQUENCE {
-        accessMethod          OBJECT IDENTIFIER,
-        accessLocation        GeneralName  }
-
--- subject info access
-
-id-pe-subjectInfoAccess OBJECT IDENTIFIER ::= { id-pe 11 }
-
-
-
-Housley, et. al.            Standards Track                   [Page 110]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-SubjectInfoAccessSyntax  ::=
-        SEQUENCE SIZE (1..MAX) OF AccessDescription
-
--- CRL number extension OID and syntax
-
-id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
-
-CRLNumber ::= INTEGER (0..MAX)
-
--- issuing distribution point extension OID and syntax
-
-id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= { id-ce 28 }
-
-IssuingDistributionPoint ::= SEQUENCE {
-     distributionPoint          [0] DistributionPointName OPTIONAL,
-     onlyContainsUserCerts      [1] BOOLEAN DEFAULT FALSE,
-     onlyContainsCACerts        [2] BOOLEAN DEFAULT FALSE,
-     onlySomeReasons            [3] ReasonFlags OPTIONAL,
-     indirectCRL                [4] BOOLEAN DEFAULT FALSE,
-     onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
-
-id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= { id-ce 27 }
-
-BaseCRLNumber ::= CRLNumber
-
--- CRL reasons extension OID and syntax
-
-id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
-
-CRLReason ::= ENUMERATED {
-     unspecified             (0),
-     keyCompromise           (1),
-     cACompromise            (2),
-     affiliationChanged      (3),
-     superseded              (4),
-     cessationOfOperation    (5),
-     certificateHold         (6),
-     removeFromCRL           (8),
-     privilegeWithdrawn      (9),
-     aACompromise           (10) }
-
--- certificate issuer CRL entry extension OID and syntax
-
-id-ce-certificateIssuer OBJECT IDENTIFIER ::= { id-ce 29 }
-
-CertificateIssuer ::= GeneralNames
-
--- hold instruction extension OID and syntax
-
-
-
-Housley, et. al.            Standards Track                   [Page 111]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-id-ce-holdInstructionCode OBJECT IDENTIFIER ::= { id-ce 23 }
-
-HoldInstructionCode ::= OBJECT IDENTIFIER
-
--- ANSI x9 holdinstructions
-
--- ANSI x9 arc holdinstruction arc
-
-holdInstruction OBJECT IDENTIFIER ::=
-          {joint-iso-itu-t(2) member-body(2) us(840) x9cm(10040) 2}
-
--- ANSI X9 holdinstructions referenced by this standard
-
-id-holdinstruction-none OBJECT IDENTIFIER  ::=
-                {holdInstruction 1} -- deprecated
-
-id-holdinstruction-callissuer OBJECT IDENTIFIER ::=
-                {holdInstruction 2}
-
-id-holdinstruction-reject OBJECT IDENTIFIER ::=
-                {holdInstruction 3}
-
--- invalidity date CRL entry extension OID and syntax
-
-id-ce-invalidityDate OBJECT IDENTIFIER ::= { id-ce 24 }
-
-InvalidityDate ::=  GeneralizedTime
-
-END
-
-Appendix B.  ASN.1 Notes
-
-   CAs MUST force the serialNumber to be a non-negative integer, that
-   is, the sign bit in the DER encoding of the INTEGER value MUST be
-   zero - this can be done by adding a leading (leftmost) `00'H octet if
-   necessary.  This removes a potential ambiguity in mapping between a
-   string of octets and an integer value.
-
-   As noted in section 4.1.2.2, serial numbers can be expected to
-   contain long integers.  Certificate users MUST be able to handle
-   serialNumber values up to 20 octets in length.  Conformant CAs MUST
-   NOT use serialNumber values longer than 20 octets.
-
-   As noted in section 5.2.3, CRL numbers can be expected to contain
-   long integers.  CRL validators MUST be able to handle cRLNumber
-   values up to 20 octets in length.  Conformant CRL issuers MUST NOT
-   use cRLNumber values longer than 20 octets.
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 112]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-   constructs.  A valid ASN.1 sequence will have zero or more entries.
-   The SIZE (1..MAX) construct constrains the sequence to have at least
-   one entry.  MAX indicates the upper bound is unspecified.
-   Implementations are free to choose an upper bound that suits their
-   environment.
-
-   The construct "positiveInt ::= INTEGER (0..MAX)" defines positiveInt
-   as a subtype of INTEGER containing integers greater than or equal to
-   zero.  The upper bound is unspecified.  Implementations are free to
-   select an upper bound that suits their environment.
-
-   The character string type PrintableString supports a very basic Latin
-   character set: the lower case letters 'a' through 'z', upper case
-   letters 'A' through 'Z', the digits '0' through '9', eleven special
-   characters ' = ( ) + , - . / : ? and space.
-
-   Implementers should note that the at sign ('@') and underscore ('_')
-   characters are not supported by the ASN.1 type PrintableString.
-   These characters often appear in internet addresses.  Such addresses
-   MUST be encoded using an ASN.1 type that supports them.  They are
-   usually encoded as IA5String in either the emailAddress attribute
-   within a distinguished name or the rfc822Name field of GeneralName.
-   Conforming implementations MUST NOT encode strings which include
-   either the at sign or underscore character as PrintableString.
-
-   The character string type TeletexString is a superset of
-   PrintableString.  TeletexString supports a fairly standard (ASCII-
-   like) Latin character set, Latin characters with non-spacing accents
-   and Japanese characters.
-
-   Named bit lists are BIT STRINGs where the values have been assigned
-   names.  This specification makes use of named bit lists in the
-   definitions for the key usage, CRL distribution points and freshest
-   CRL certificate extensions, as well as the freshest CRL and issuing
-   distribution point CRL extensions.  When DER encoding a named bit
-   list, trailing zeroes MUST be omitted.  That is, the encoded value
-   ends with the last named bit that is set to one.
-
-   The character string type UniversalString supports any of the
-   characters allowed by ISO 10646-1 [ISO 10646].  ISO 10646-1 is the
-   Universal multiple-octet coded Character Set (UCS).  ISO 10646-1
-   specifies the architecture and the "basic multilingual plane" -- a
-   large standard character set which includes all major world character
-   standards.
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 113]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   The character string type UTF8String was introduced in the 1997
-   version of ASN.1, and UTF8String was added to the list of choices for
-   DirectoryString in the 2001 version of X.520 [X.520].  UTF8String is
-   a universal type and has been assigned tag number 12.  The content of
-   UTF8String was defined by RFC 2044 [RFC 2044] and updated in RFC 2279
-   [RFC 2279].
-
-   In anticipation of these changes, and in conformance with IETF Best
-   Practices codified in RFC 2277 [RFC 2277], IETF Policy on Character
-   Sets and Languages, this document includes UTF8String as a choice in
-   DirectoryString and the CPS qualifier extensions.
-
-   Implementers should note that the DER encoding of the SET OF values
-   requires ordering of the encodings of the values.  In particular,
-   this issue arises with respect to distinguished names.
-
-   Implementers should note that the DER encoding of SET or SEQUENCE
-   components whose value is the DEFAULT omit the component from the
-   encoded certificate or CRL.  For example, a BasicConstraints
-   extension whose cA value is FALSE would omit the cA boolean from the
-   encoded certificate.
-
-   Object Identifiers (OIDs) are used throughout this specification to
-   identify certificate policies, public key and signature algorithms,
-   certificate extensions, etc.  There is no maximum size for OIDs.
-   This specification mandates support for OIDs which have arc elements
-   with values that are less than 2^28, that is, they MUST be between 0
-   and 268,435,455, inclusive.  This allows each arc element to be
-   represented within a single 32 bit word.  Implementations MUST also
-   support OIDs where the length of the dotted decimal (see [RFC 2252],
-   section 4.1) string representation can be up to 100 bytes
-   (inclusive).  Implementations MUST be able to handle OIDs with up to
-   20 elements (inclusive).  CAs SHOULD NOT issue certificates which
-   contain OIDs that exceed these requirements.  Likewise, CRL issuers
-   SHOULD NOT issue CRLs which contain OIDs that exceed these
-   requirements.
-
-   Implementors are warned that the X.500 standards community has
-   developed a series of extensibility rules.  These rules determine
-   when an ASN.1 definition can be changed without assigning a new
-   object identifier (OID).  For example, at least two extension
-   definitions included in RFC 2459 [RFC 2459], the predecessor to this
-   profile document, have different ASN.1 definitions in this
-   specification, but the same OID is used.  If unknown elements appear
-   within an extension, and the extension is not marked critical, those
-   unknown elements ought to be ignored, as follows:
-
-      (a)  ignore all unknown bit name assignments within a bit string;
-
-
-
-Housley, et. al.            Standards Track                   [Page 114]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-      (b)  ignore all unknown named numbers in an ENUMERATED type or
-      INTEGER type that is being used in the enumerated style, provided
-      the number occurs as an optional element of a SET or SEQUENCE; and
-
-      (c)  ignore all unknown elements in SETs, at the end of SEQUENCEs,
-      or in CHOICEs where the CHOICE is itself an optional element of a
-      SET or SEQUENCE.
-
-   If an extension containing unexpected values is marked critical, the
-   implementation MUST reject the certificate or CRL containing the
-   unrecognized extension.
-
-Appendix C.  Examples
-
-   This section contains four examples: three certificates and a CRL.
-   The first two certificates and the CRL comprise a minimal
-   certification path.
-
-   Section C.1 contains an annotated hex dump of a "self-signed"
-   certificate issued by a CA whose distinguished name is
-   cn=us,o=gov,ou=nist.  The certificate contains a DSA public key with
-   parameters, and is signed by the corresponding DSA private key.
-
-   Section C.2 contains an annotated hex dump of an end entity
-   certificate.  The end entity certificate contains a DSA public key,
-   and is signed by the private key corresponding to the "self-signed"
-   certificate in section C.1.
-
-   Section C.3 contains a dump of an end entity certificate which
-   contains an RSA public key and is signed with RSA and MD5.  This
-   certificate is not part of the minimal certification path.
-
-   Section C.4 contains an annotated hex dump of a CRL.  The CRL is
-   issued by the CA whose distinguished name is cn=us,o=gov,ou=nist and
-   the list of revoked certificates includes the end entity certificate
-   presented in C.2.
-
-   The certificates were processed using Peter Gutman's dumpasn1 utility
-   to generate the output.  The source for the dumpasn1 utility is
-   available at <http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c>.  The
-   binaries for the certificates and CRLs are available at
-   <http://csrc.nist.gov/pki/pkixtools>.
-
-C.1  Certificate
-
-   This section contains an annotated hex dump of a 699 byte version 3
-   certificate.  The certificate contains the following information:
-   (a)  the serial number is 23 (17 hex);
-
-
-
-Housley, et. al.            Standards Track                   [Page 115]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   (b)  the certificate is signed with DSA and the SHA-1 hash algorithm;
-   (c)  the issuer's distinguished name is OU=NIST; O=gov; C=US
-   (d)  and the subject's distinguished name is OU=NIST; O=gov; C=US
-   (e)  the certificate was issued on June 30, 1997 and will expire on
-   December 31, 1997;
-   (f)  the certificate contains a 1024 bit DSA public key with
-   parameters;
-   (g)  the certificate contains a subject key identifier extension
-   generated using method (1) of section 4.2.1.2; and
-   (h)  the certificate is a CA certificate (as indicated through the
-   basic constraints extension.)
-
-  0 30  699: SEQUENCE {
-  4 30  635:   SEQUENCE {
-  8 A0    3:     [0] {
- 10 02    1:       INTEGER 2
-          :       }
- 13 02    1:     INTEGER 17
- 16 30    9:     SEQUENCE {
- 18 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-          :       }
- 27 30   42:     SEQUENCE {
- 29 31   11:       SET {
- 31 30    9:         SEQUENCE {
- 33 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
- 38 13    2:           PrintableString 'US'
-          :           }
-          :         }
- 42 31   12:       SET {
- 44 30   10:         SEQUENCE {
- 46 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
- 51 13    3:           PrintableString 'gov'
-          :           }
-          :         }
- 56 31   13:       SET {
- 58 30   11:         SEQUENCE {
- 60 06    3:           OBJECT IDENTIFIER
-          :             organizationalUnitName (2 5 4 11)
- 65 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
- 71 30   30:     SEQUENCE {
- 73 17   13:       UTCTime '970630000000Z'
- 88 17   13:       UTCTime '971231000000Z'
-           :       }
-103 30   42:     SEQUENCE {
-105 31   11:       SET {
-
-
-
-Housley, et. al.            Standards Track                   [Page 116]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-107 30    9:         SEQUENCE {
-109 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-114 13    2:           PrintableString 'US'
-           :           }
-           :         }
-118 31   12:       SET {
-120 30   10:         SEQUENCE {
-122 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-127 13    3:           PrintableString 'gov'
-           :           }
-           :         }
-132 31   13:       SET {
-134 30   11:         SEQUENCE {
-136 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
-141 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
-147 30  440:     SEQUENCE {
-151 30  300:       SEQUENCE {
-155 06    7:         OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
-164 30  287:         SEQUENCE {
-168 02  129:           INTEGER
-           :             00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
-           :             FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
-           :             48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
-           :             22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
-           :             3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
-           :             C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
-           :             35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
-           :             5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
-           :             FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
-           :             63 FE 43
-300 02   21:           INTEGER
-           :             00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
-           :             55 F7 7D 57 74 81 E5
-323 02  129:           INTEGER
-           :             00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
-           :             C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
-           :             81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
-           :             A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
-           :             46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
-           :             5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
-           :             92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
-           :             62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
-           :             F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
-           :             1E 57 18
-
-
-
-Housley, et. al.            Standards Track                   [Page 117]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-           :           }
-           :         }
-455 03  133:       BIT STRING 0 unused bits, encapsulates {
-459 02  129:           INTEGER
-           :             00 B5 9E 1F 49 04 47 D1 DB F5 3A DD CA 04
-           :             75 E8 DD 75 F6 9B 8A B1 97 D6 59 69 82 D3
-           :             03 4D FD 3B 36 5F 4A F2 D1 4E C1 07 F5 D1
-           :             2A D3 78 77 63 56 EA 96 61 4D 42 0B 7A 1D
-           :             FB AB 91 A4 CE DE EF 77 C8 E5 EF 20 AE A6
-           :             28 48 AF BE 69 C3 6A A5 30 F2 C2 B9 D9 82
-           :             2B 7D D9 C4 84 1F DE 0D E8 54 D7 1B 99 2E
-           :             B3 D0 88 F6 D6 63 9B A7 E2 0E 82 D4 3B 8A
-           :             68 1B 06 56 31 59 0B 49 EB 99 A5 D5 81 41
-           :             7B C9 55
-           :           }
-           :       }
-591 A3   50:     [3] {
-593 30   48:       SEQUENCE {
-595 30   29:         SEQUENCE {
-597 06    3:           OBJECT IDENTIFIER
-           :             subjectKeyIdentifier (2 5 29 14)
-602 04   22:           OCTET STRING, encapsulates {
-604 04   20:               OCTET STRING
-           :                 86 CA A5 22 81 62 EF AD 0A 89 BC AD 72 41
-           :                 2C 29 49 F4 86 56
-           :               }
-           :           }
-626 30   15:         SEQUENCE {
-628 06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
-633 01    1:           BOOLEAN TRUE
-636 04    5:           OCTET STRING, encapsulates {
-638 30    3:               SEQUENCE {
-640 01    1:                 BOOLEAN TRUE
-           :                 }
-           :               }
-           :           }
-           :         }
-           :       }
-           :     }
-643 30    9:   SEQUENCE {
-645 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-           :     }
-654 03   47:   BIT STRING 0 unused bits, encapsulates {
-657 30   44:       SEQUENCE {
-659 02   20:         INTEGER
-           :           43 1B CF 29 25 45 C0 4E 52 E7 7D D6 FC B1
-           :           66 4C 83 CF 2D 77
-681 02   20:         INTEGER
-
-
-
-Housley, et. al.            Standards Track                   [Page 118]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-           :           0B 5B 9A 24 11 98 E8 F3 86 90 04 F6 08 A9
-           :           E1 8D A5 CC 3A D4
-           :         }
-           :       }
-           :   }
-
-C.2  Certificate
-
-   This section contains an annotated hex dump of a 730 byte version 3
-   certificate.  The certificate contains the following information:
-   (a)  the serial number is 18 (12 hex);
-   (b)  the certificate is signed with DSA and the SHA-1 hash algorithm;
-   (c)  the issuer's distinguished name is OU=nist; O=gov; C=US
-   (d)  and the subject's distinguished name is CN=Tim Polk; OU=nist;
-   O=gov; C=US
-   (e)  the certificate was valid from July 30, 1997 through December 1,
-   1997;
-   (f)  the certificate contains a 1024 bit DSA public key;
-   (g)  the certificate is an end entity certificate, as the basic
-   constraints extension is not present;
-   (h)  the certificate contains an authority key identifier extension
-   matching the subject key identifier of the certificate in Appendix
-   C.1; and
-   (i)  the certificate includes one alternative name - an RFC 822
-   address of "wpolk@nist.gov".
-
-     0 30  730: SEQUENCE {
-     4 30  665:   SEQUENCE {
-     8 A0    3:     [0] {
-    10 02    1:       INTEGER 2
-              :       }
-    13 02    1:     INTEGER 18
-    16 30    9:     SEQUENCE {
-    18 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-              :       }
-    27 30   42:     SEQUENCE {
-    29 31   11:       SET {
-    31 30    9:         SEQUENCE {
-    33 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-    38 13    2:           PrintableString 'US'
-              :           }
-              :         }
-    42 31   12:       SET {
-    44 30   10:         SEQUENCE {
-    46 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-    51 13    3:           PrintableString 'gov'
-              :           }
-              :         }
-
-
-
-Housley, et. al.            Standards Track                   [Page 119]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-    56 31   13:       SET {
-    58 30   11:         SEQUENCE {
-    60 06    3:           OBJECT IDENTIFIER
-              :             organizationalUnitName (2 5 4 11)
-    65 13    4:           PrintableString 'NIST'
-              :           }
-              :         }
-              :       }
-    71 30   30:     SEQUENCE {
-    73 17   13:       UTCTime '970730000000Z'
-    88 17   13:       UTCTime '971201000000Z'
-              :       }
-   103 30   61:     SEQUENCE {
-   105 31   11:       SET {
-   107 30    9:         SEQUENCE {
-   109 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-   114 13    2:           PrintableString 'US'
-              :           }
-              :         }
-   118 31   12:       SET {
-   120 30   10:         SEQUENCE {
-   122 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-   127 13    3:           PrintableString 'gov'
-              :           }
-              :         }
-   132 31   13:       SET {
-   134 30   11:         SEQUENCE {
-   136 06    3:           OBJECT IDENTIFIER
-              :             organizationalUnitName (2 5 4 11)
-   141 13    4:           PrintableString 'NIST'
-              :           }
-              :         }
-   147 31   17:       SET {
-   149 30   15:         SEQUENCE {
-   151 06    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
-   156 13    8:           PrintableString 'Tim Polk'
-              :           }
-              :         }
-              :       }
-   166 30  439:     SEQUENCE {
-   170 30  300:       SEQUENCE {
-   174 06    7:         OBJECT IDENTIFIER dsa (1 2 840 10040 4 1)
-   183 30  287:         SEQUENCE {
-   187 02  129:           INTEGER
-              :             00 B6 8B 0F 94 2B 9A CE A5 25 C6 F2 ED FC
-              :             FB 95 32 AC 01 12 33 B9 E0 1C AD 90 9B BC
-              :             48 54 9E F3 94 77 3C 2C 71 35 55 E6 FE 4F
-              :             22 CB D5 D8 3E 89 93 33 4D FC BD 4F 41 64
-
-
-
-Housley, et. al.            Standards Track                   [Page 120]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-              :             3E A2 98 70 EC 31 B4 50 DE EB F1 98 28 0A
-              :             C9 3E 44 B3 FD 22 97 96 83 D0 18 A3 E3 BD
-              :             35 5B FF EE A3 21 72 6A 7B 96 DA B9 3F 1E
-              :             5A 90 AF 24 D6 20 F0 0D 21 A7 D4 02 B9 1A
-              :             FC AC 21 FB 9E 94 9E 4B 42 45 9E 6A B2 48
-              :             63 FE 43
-   319 02   21:           INTEGER
-              :             00 B2 0D B0 B1 01 DF 0C 66 24 FC 13 92 BA
-              :             55 F7 7D 57 74 81 E5
-   342 02  129:           INTEGER
-              :             00 9A BF 46 B1 F5 3F 44 3D C9 A5 65 FB 91
-              :             C0 8E 47 F1 0A C3 01 47 C2 44 42 36 A9 92
-              :             81 DE 57 C5 E0 68 86 58 00 7B 1F F9 9B 77
-              :             A1 C5 10 A5 80 91 78 51 51 3C F6 FC FC CC
-              :             46 C6 81 78 92 84 3D F4 93 3D 0C 38 7E 1A
-              :             5B 99 4E AB 14 64 F6 0C 21 22 4E 28 08 9C
-              :             92 B9 66 9F 40 E8 95 F6 D5 31 2A EF 39 A2
-              :             62 C7 B2 6D 9E 58 C4 3A A8 11 81 84 6D AF
-              :             F8 B4 19 B4 C2 11 AE D0 22 3B AA 20 7F EE
-              :             1E 57 18
-              :           }
-              :         }
-   474 03  132:       BIT STRING 0 unused bits, encapsulates {
-   478 02  128:           INTEGER
-              :             30 B6 75 F7 7C 20 31 AE 38 BB 7E 0D 2B AB
-              :             A0 9C 4B DF 20 D5 24 13 3C CD 98 E5 5F 6C
-              :             B7 C1 BA 4A BA A9 95 80 53 F0 0D 72 DC 33
-              :             37 F4 01 0B F5 04 1F 9D 2E 1F 62 D8 84 3A
-              :             9B 25 09 5A 2D C8 46 8E 2B D4 F5 0D 3B C7
-              :             2D C6 6C B9 98 C1 25 3A 44 4E 8E CA 95 61
-              :             35 7C CE 15 31 5C 23 13 1E A2 05 D1 7A 24
-              :             1C CB D3 72 09 90 FF 9B 9D 28 C0 A1 0A EC
-              :             46 9F 0D B8 D0 DC D0 18 A6 2B 5E F9 8F B5
-              :             95 BE
-              :           }
-              :       }
-   609 A3   62:     [3] {
-   611 30   60:       SEQUENCE {
-   613 30   25:         SEQUENCE {
-   615 06    3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
-   620 04   18:           OCTET STRING, encapsulates {
-   622 30   16:               SEQUENCE {
-   624 81   14:                 [1] 'wpolk@nist.gov'
-              :                 }
-              :               }
-              :           }
-   640 30   31:         SEQUENCE {
-   642 06    3:           OBJECT IDENTIFIER
-
-
-
-Housley, et. al.            Standards Track                   [Page 121]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-              :             authorityKeyIdentifier (2 5 29 35)
-   647 04   24:           OCTET STRING, encapsulates {
-   649 30   22:               SEQUENCE {
-   651 80   20:                 [0]
-              :                   86 CA A5 22 81 62 EF AD 0A 89 BC AD 72
-              :                   41 2C 29 49 F4 86 56
-              :                 }
-              :               }
-              :           }
-              :         }
-              :       }
-              :     }
-   673 30    9:   SEQUENCE {
-   675 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-              :     }
-   684 03   48:   BIT STRING 0 unused bits, encapsulates {
-   687 30   45:       SEQUENCE {
-   689 02   20:         INTEGER
-              :           36 97 CB E3 B4 2C E1 BB 61 A9 D3 CC 24 CC
-              :           22 92 9F F4 F5 87
-   711 02   21:         INTEGER
-              :           00 AB C9 79 AF D2 16 1C A9 E3 68 A9 14 10
-              :           B4 A0 2E FF 22 5A 73
-              :         }
-              :       }
-              :   }
-
-C.3  End Entity Certificate Using RSA
-
-   This section contains an annotated hex dump of a 654 byte version 3
-   certificate.  The certificate contains the following information:
-   (a)  the serial number is 256;
-   (b)  the certificate is signed with RSA and the SHA-1 hash algorithm;
-   (c)  the issuer's distinguished name is OU=NIST; O=gov; C=US
-   (d)  and the subject's distinguished name is CN=Tim Polk; OU=NIST;
-   O=gov; C=US
-   (e)  the certificate was issued on May 21, 1996 at 09:58:26 and
-   expired on May 21, 1997 at 09:58:26;
-   (f)  the certificate contains a 1024 bit RSA public key;
-   (g)  the certificate is an end entity certificate (not a CA
-   certificate);
-   (h)  the certificate includes an alternative subject name of
-   "<http://www.itl.nist.gov/div893/staff/polk/index.html>" and an
-   alternative issuer name of "<http://www.nist.gov/>" - both are URLs;
-   (i)  the certificate include an authority key identifier extension
-   and a certificate policies extension specifying the policy OID
-   2.16.840.1.101.3.2.1.48.9; and
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 122]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-   (j)  the certificate includes a critical key usage extension
-   specifying that the public key is intended for verification of
-   digital signatures.
-
-  0 30  654: SEQUENCE {
-  4 30  503:   SEQUENCE {
-  8 A0    3:     [0] {
- 10 02    1:       INTEGER 2
-           :       }
- 13 02    2:     INTEGER 256
- 17 30   13:     SEQUENCE {
- 19 06    9:       OBJECT IDENTIFIER
-           :         sha1withRSAEncryption (1 2 840 113549 1 1 5)
- 30 05    0:       NULL
-           :       }
- 32 30   42:     SEQUENCE {
- 34 31   11:       SET {
- 36 30    9:         SEQUENCE {
- 38 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
- 43 13    2:           PrintableString 'US'
-           :           }
-           :         }
- 47 31   12:       SET {
- 49 30   10:         SEQUENCE {
- 51 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
- 56 13    3:           PrintableString 'gov'
-           :           }
-           :         }
- 61 31   13:       SET {
- 63 30   11:         SEQUENCE {
- 65 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
- 70 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
- 76 30   30:     SEQUENCE {
- 78 17   13:       UTCTime '960521095826Z'
- 93 17   13:       UTCTime '970521095826Z'
-           :       }
-108 30   61:     SEQUENCE {
-110 31   11:       SET {
-112 30    9:         SEQUENCE {
-114 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
-119 13    2:           PrintableString 'US'
-           :           }
-           :         }
-123 31   12:       SET {
-
-
-
-Housley, et. al.            Standards Track                   [Page 123]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-125 30   10:         SEQUENCE {
-127 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
-132 13    3:           PrintableString 'gov'
-           :           }
-           :         }
-137 31   13:       SET {
-139 30   11:         SEQUENCE {
-141 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
-146 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-152 31   17:       SET {
-154 30   15:         SEQUENCE {
-156 06    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
-161 13    8:           PrintableString 'Tim Polk'
-           :           }
-           :         }
-           :       }
-171 30  159:     SEQUENCE {
-174 30   13:       SEQUENCE {
-176 06    9:         OBJECT IDENTIFIER
-           :           rsaEncryption (1 2 840 113549 1 1 1)
-187 05    0:         NULL
-           :         }
-189 03  141:       BIT STRING 0 unused bits, encapsulates {
-193 30  137:           SEQUENCE {
-196 02  129:             INTEGER
-           :               00 E1 6A E4 03 30 97 02 3C F4 10 F3 B5 1E
-           :               4D 7F 14 7B F6 F5 D0 78 E9 A4 8A F0 A3 75
-           :               EC ED B6 56 96 7F 88 99 85 9A F2 3E 68 77
-           :               87 EB 9E D1 9F C0 B4 17 DC AB 89 23 A4 1D
-           :               7E 16 23 4C 4F A8 4D F5 31 B8 7C AA E3 1A
-           :               49 09 F4 4B 26 DB 27 67 30 82 12 01 4A E9
-           :               1A B6 C1 0C 53 8B 6C FC 2F 7A 43 EC 33 36
-           :               7E 32 B2 7B D5 AA CF 01 14 C6 12 EC 13 F2
-           :               2D 14 7A 8B 21 58 14 13 4C 46 A3 9A F2 16
-           :               95 FF 23
-328 02    3:             INTEGER 65537
-           :             }
-           :           }
-           :       }
-333 A3  175:     [3] {
-336 30  172:       SEQUENCE {
-339 30   63:         SEQUENCE {
-341 06    3:           OBJECT IDENTIFIER subjectAltName (2 5 29 17)
-346 04   56:           OCTET STRING, encapsulates {
-348 30   54:               SEQUENCE {
-
-
-
-Housley, et. al.            Standards Track                   [Page 124]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-350 86   52:                 [6]
-           :                   'http://www.itl.nist.gov/div893/staff/'
-           :                   'polk/index.html'
-           :                 }
-           :               }
-           :           }
-404 30   31:         SEQUENCE {
-406 06    3:           OBJECT IDENTIFIER issuerAltName (2 5 29 18)
-411 04   24:           OCTET STRING, encapsulates {
-413 30   22:               SEQUENCE {
-415 86   20:                 [6] 'http://www.nist.gov/'
-           :                 }
-           :               }
-           :           }
-437 30   31:         SEQUENCE {
-439 06    3:           OBJECT IDENTIFIER
-           :             authorityKeyIdentifier (2 5 29 35)
-444 04   24:           OCTET STRING, encapsulates {
-446 30   22:               SEQUENCE {
-448 80   20:                 [0]
-           :                   08 68 AF 85 33 C8 39 4A 7A F8 82 93 8E
-           :                   70 6A 4A 20 84 2C 32
-           :                 }
-           :               }
-           :           }
-470 30   23:         SEQUENCE {
-472 06    3:           OBJECT IDENTIFIER
-           :             certificatePolicies (2 5 29 32)
-477 04   16:           OCTET STRING, encapsulates {
-479 30   14:               SEQUENCE {
-481 30   12:                 SEQUENCE {
-483 06   10:                   OBJECT IDENTIFIER
-           :                            '2 16 840 1 101 3 2 1 48 9'
-           :                   }
-           :                 }
-           :               }
-           :           }
-495 30   14:         SEQUENCE {
-497 06    3:           OBJECT IDENTIFIER keyUsage (2 5 29 15)
-502 01    1:           BOOLEAN TRUE
-505 04    4:           OCTET STRING, encapsulates {
-507 03    2:               BIT STRING 7 unused bits
-           :                 '1'B (bit 0)
-           :               }
-           :           }
-           :         }
-           :       }
-           :     }
-
-
-
-Housley, et. al.            Standards Track                   [Page 125]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-511 30   13:   SEQUENCE {
-513 06    9:     OBJECT IDENTIFIER
-           :       sha1withRSAEncryption (1 2 840 113549 1 1 5)
-524 05    0:     NULL
-           :     }
-526 03  129:   BIT STRING 0 unused bits
-           :     1E 07 77 6E 66 B5 B6 B8 57 F0 03 DC 6F 77
-           :     6D AF 55 1D 74 E5 CE 36 81 FC 4B C5 F4 47
-           :     82 C4 0A 25 AA 8D D6 7D 3A 89 AB 44 34 39
-           :     F6 BD 61 1A 78 85 7A B8 1E 92 A2 22 2F CE
-           :     07 1A 08 8E F1 46 03 59 36 4A CB 60 E6 03
-           :     40 01 5B 2A 44 D6 E4 7F EB 43 5E 74 0A E6
-           :     E4 F9 3E E1 44 BE 1F E7 5F 5B 2C 41 8D 08
-           :     BD 26 FE 6A A6 C3 2F B2 3B 41 12 6B C1 06
-           :     8A B8 4C 91 59 EB 2F 38 20 2A 67 74 20 0B
-           :     77 F3
-           :   }
-
-C.4  Certificate Revocation List
-
-   This section contains an annotated hex dump of a version 2 CRL with
-   one extension (cRLNumber).  The CRL was issued by OU=NIST; O=gov;
-   C=US on August 7, 1997; the next scheduled issuance was September 7,
-   1997.  The CRL includes one revoked certificates: serial number 18
-   (12 hex), which was revoked on July 31, 1997 due to keyCompromise.
-   The CRL itself is number 18, and it was signed with DSA and SHA-1.
-
-  0 30  203: SEQUENCE {
-  3 30  140:   SEQUENCE {
-  6 02    1:     INTEGER 1
-  9 30    9:     SEQUENCE {
- 11 06    7:       OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-           :       }
- 20 30   42:     SEQUENCE {
- 22 31   11:       SET {
- 24 30    9:         SEQUENCE {
- 26 06    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
- 31 13    2:           PrintableString 'US'
-           :           }
-           :         }
- 35 31   12:       SET {
- 37 30   10:         SEQUENCE {
- 39 06    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
- 44 13    3:           PrintableString 'gov'
-           :           }
-           :         }
- 49 31   13:       SET {
- 51 30   11:         SEQUENCE {
-
-
-
-Housley, et. al.            Standards Track                   [Page 126]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
- 53 06    3:           OBJECT IDENTIFIER
-           :             organizationalUnitName (2 5 4 11)
- 58 13    4:           PrintableString 'NIST'
-           :           }
-           :         }
-           :       }
- 64 17   13:     UTCTime '970807000000Z'
- 79 17   13:     UTCTime '970907000000Z'
- 94 30   34:     SEQUENCE {
- 96 30   32:       SEQUENCE {
- 98 02    1:         INTEGER 18
-101 17   13:         UTCTime '970731000000Z'
-116 30   12:         SEQUENCE {
-118 30   10:           SEQUENCE {
-120 06    3:             OBJECT IDENTIFIER cRLReason (2 5 29 21)
-125 04    3:             OCTET STRING, encapsulates {
-127 0A    1:                 ENUMERATED 1
-           :                 }
-           :             }
-           :           }
-           :         }
-           :       }
-130 A0   14:     [0] {
-132 30   12:       SEQUENCE {
-134 30   10:         SEQUENCE {
-136 06    3:           OBJECT IDENTIFIER cRLNumber (2 5 29 20)
-141 04    3:           OCTET STRING, encapsulates {
-143 02    1:               INTEGER 12
-           :               }
-           :           }
-           :         }
-           :       }
-           :     }
-146 30    9:   SEQUENCE {
-148 06    7:     OBJECT IDENTIFIER dsaWithSha1 (1 2 840 10040 4 3)
-           :     }
-157 03   47:   BIT STRING 0 unused bits, encapsulates {
-160 30   44:       SEQUENCE {
-162 02   20:         INTEGER
-           :           22 4E 9F 43 BA 95 06 34 F2 BB 5E 65 DB A6
-           :           80 05 C0 3A 29 47
-184 02   20:         INTEGER
-           :           59 1A 57 C9 82 D7 02 21 14 C3 D4 0B 32 1B
-           :           96 16 B1 1F 46 5A
-           :         }
-           :       }
-           :   }
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 127]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-Author Addresses
-
-   Russell Housley
-   RSA Laboratories
-   918 Spring Knoll Drive
-   Herndon, VA 20170
-   USA
-
-   EMail:  rhousley@rsasecurity.com
-
-   Warwick Ford
-   VeriSign, Inc.
-   401 Edgewater Place
-   Wakefield, MA 01880
-   USA
-
-   EMail:  wford@verisign.com
-
-   Tim Polk
-   NIST
-   Building 820, Room 426
-   Gaithersburg, MD 20899
-   USA
-
-   EMail:  wpolk@nist.gov
-
-   David Solo
-   Citigroup
-   909 Third Ave, 16th Floor
-   New York, NY 10043
-   USA
-
-   EMail:  dsolo@alum.mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 128]
-
-RFC 3280        Internet X.509 Public Key Infrastructure      April 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Housley, et. al.            Standards Track                   [Page 129]
-
diff --git a/doc/protocol/rfc3546.txt b/doc/protocol/rfc3546.txt
deleted file mode 100644
index 4392449068..0000000000
--- a/doc/protocol/rfc3546.txt
+++ /dev/null
@@ -1,1627 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    S. Blake-Wilson
-Request for Comments: 3546                                           BCI
-Updates: 2246                                                 M. Nystrom
-Category: Standards Track                                   RSA Security
-                                                              D. Hopwood
-                                                  Independent Consultant
-                                                            J. Mikkelsen
-                                                         Transactionware
-                                                               T. Wright
-                                                                Vodafone
-                                                               June 2003
-
-
-               Transport Layer Security (TLS) Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   The extensions may be used by TLS clients and servers.  The
-   extensions are backwards compatible - communication is possible
-   between TLS 1.0 clients that support the extensions and TLS 1.0
-   servers that do not support the extensions, and vice versa.
-
-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 BCP 14, RFC 2119
-   [KEYWORDS].
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 1]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-Table of Contents
-
-   1.  Introduction .............................................  2
-   2.  General Extension Mechanisms .............................  4
-       2.1. Extended Client Hello ...............................  5
-       2.2. Extended Server Hello ...............................  5
-       2.3. Hello Extensions ....................................  6
-       2.4. Extensions to the handshake protocol ................  7
-   3.  Specific Extensions ......................................  8
-       3.1. Server Name Indication ..............................  8
-       3.2. Maximum Fragment Length Negotiation ................. 10
-       3.3. Client Certificate URLs ............................. 11
-       3.4. Trusted CA Indication ............................... 14
-       3.5. Truncated HMAC ...................................... 15
-       3.6. Certificate Status Request........................... 16
-   4. Error alerts .............................................. 18
-   5. Procedure for Defining New Extensions...................... 20
-   6.  Security Considerations .................................. 21
-       6.1. Security of server_name ............................. 21
-       6.2. Security of max_fragment_length ..................... 21
-       6.3. Security of client_certificate_url .................. 22
-       6.4. Security of trusted_ca_keys ......................... 23
-       6.5. Security of truncated_hmac .......................... 23
-       6.6. Security of status_request .......................... 24
-   7.  Internationalization Considerations ...................... 24
-   8.  IANA Considerations ...................................... 24
-   9.  Intellectual Property Rights ............................. 26
-   10. Acknowledgments .......................................... 26
-   11. Normative References ..................................... 27
-   12. Informative References ................................... 28
-   13. Authors' Addresses ....................................... 28
-   14. Full Copyright Statement ................................. 29
-
-1. Introduction
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   TLS is now used in an increasing variety of operational environments
-   - many of which were not envisioned when the original design criteria
-   for TLS were determined.  The extensions introduced in this document
-   are designed to enable TLS to operate as effectively as possible in
-   new environments like wireless networks.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 2]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Wireless environments often suffer from a number of constraints not
-   commonly present in wired environments.  These constraints may
-   include bandwidth limitations, computational power limitations,
-   memory limitations, and battery life limitations.
-
-   The extensions described here focus on extending the functionality
-   provided by the TLS protocol message formats.  Other issues, such as
-   the addition of new cipher suites, are deferred.
-
-   Specifically, the extensions described in this document are designed
-   to:
-
-   -  Allow TLS clients to provide to the TLS server the name of the
-      server they are contacting.  This functionality is desirable to
-      facilitate secure connections to servers that host multiple
-      'virtual' servers at a single underlying network address.
-
-   -  Allow TLS clients and servers to negotiate the maximum fragment
-      length to be sent.  This functionality is desirable as a result of
-      memory constraints among some clients, and bandwidth constraints
-      among some access networks.
-
-   -  Allow TLS clients and servers to negotiate the use of client
-      certificate URLs.  This functionality is desirable in order to
-      conserve memory on constrained clients.
-
-   -  Allow TLS clients to indicate to TLS servers which CA root keys
-      they possess.  This functionality is desirable in order to prevent
-      multiple handshake failures involving TLS clients that are only
-      able to store a small number of CA root keys due to memory
-      limitations.
-
-   -  Allow TLS clients and servers to negotiate the use of truncated
-      MACs.  This functionality is desirable in order to conserve
-      bandwidth in constrained access networks.
-
-   -  Allow TLS clients and servers to negotiate that the server sends
-      the client certificate status information (e.g., an Online
-      Certificate Status Protocol (OCSP) [OCSP] response) during a TLS
-      handshake.  This functionality is desirable in order to avoid
-      sending a Certificate Revocation List (CRL) over a constrained
-      access network and therefore save bandwidth.
-
-   In order to support the extensions above, general extension
-   mechanisms for the client hello message and the server hello message
-   are introduced.
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 3]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   The extensions described in this document may be used by TLS 1.0
-   clients and TLS 1.0 servers.  The extensions are designed to be
-   backwards compatible - meaning that TLS 1.0 clients that support the
-   extensions can talk to TLS 1.0 servers that do not support the
-   extensions, and vice versa.
-
-   Backwards compatibility is primarily achieved via two considerations:
-
-   -  Clients typically request the use of extensions via the extended
-      client hello message described in Section 2.1. TLS 1.0 [TLS]
-      requires servers to accept extended client hello messages, even if
-      the server does not "understand" the extension.
-
-   -  For the specific extensions described here, no mandatory server
-      response is required when clients request extended functionality.
-
-   Note however, that although backwards compatibility is supported,
-   some constrained clients may be forced to reject communications with
-   servers that do not support the extensions as a result of the limited
-   capabilities of such clients.
-
-   The remainder of this document is organized as follows.  Section 2
-   describes general extension mechanisms for the client hello and
-   server hello handshake messages.  Section 3 describes specific
-   extensions to TLS 1.0.  Section 4 describes new error alerts for use
-   with the TLS extensions.  The final sections of the document address
-   IPR, security considerations, registration of the application/pkix-
-   pkipath MIME type, acknowledgements, and references.
-
-2. General Extension Mechanisms
-
-   This section presents general extension mechanisms for the TLS
-   handshake client hello and server hello messages.
-
-   These general extension mechanisms are necessary in order to enable
-   clients and servers to negotiate whether to use specific extensions,
-   and how to use specific extensions.  The extension formats described
-   are based on [MAILING LIST].
-
-   Section 2.1 specifies the extended client hello message format,
-   Section 2.2 specifies the extended server hello message format, and
-   Section 2.3 describes the actual extension format used with the
-   extended client and server hellos.
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 4]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-2.1. Extended Client Hello
-
-   Clients MAY request extended functionality from servers by sending
-   the extended client hello message format in place of the client hello
-   message format.  The extended client hello message format is:
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-1>;
-          CompressionMethod compression_methods<1..2^8-1>;
-          Extension client_hello_extension_list<0..2^16-1>;
-      } ClientHello;
-
-   Here the new "client_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   In the event that a client requests additional functionality using
-   the extended client hello, and this functionality is not supplied by
-   the server, the client MAY abort the handshake.
-
-   Note that [TLS], Section 7.4.1.2, allows additional information to be
-   added to the client hello message.  Thus the use of the extended
-   client hello defined above should not "break" existing TLS 1.0
-   servers.
-
-   A server that supports the extensions mechanism MUST accept only
-   client hello messages in either the original or extended ClientHello
-   format, and (as for all other messages) MUST check that the amount of
-   data in the message precisely matches one of these formats; if not
-   then it MUST send a fatal "decode_error" alert.  This overrides the
-   "Forward compatibility note" in [TLS].
-
-2.2. Extended Server Hello
-
-   The extended server hello message format MAY be sent in place of the
-   server hello message when the client has requested extended
-   functionality via the extended client hello message specified in
-   Section 2.1.  The extended server hello message format is:
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 5]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          Extension server_hello_extension_list<0..2^16-1>;
-      } ServerHello;
-
-   Here the new "server_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   Note that the extended server hello message is only sent in response
-   to an extended client hello message.  This prevents the possibility
-   that the extended server hello message could "break" existing TLS 1.0
-   clients.
-
-2.3. Hello Extensions
-
-   The extension format for extended client hellos and extended server
-   hellos is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-   Here:
-
-   - "extension_type" identifies the particular extension type.
-
-   - "extension_data" contains information specific to the particular
-   extension type.
-
-   The extension types defined in this document are:
-
-      enum {
-          server_name(0), max_fragment_length(1),
-          client_certificate_url(2), trusted_ca_keys(3),
-          truncated_hmac(4), status_request(5), (65535)
-      } ExtensionType;
-
-   Note that for all extension types (including those defined in
-   future), the extension type MUST NOT appear in the extended server
-   hello unless the same extension type appeared in the corresponding
-   client hello.  Thus clients MUST abort the handshake if they receive
-   an extension type in the extended server hello that they did not
-   request in the associated (extended) client hello.
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 6]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Nonetheless "server initiated" extensions may be provided in the
-   future within this framework by requiring the client to first send an
-   empty extension to indicate that it supports a particular extension.
-
-   Also note that when multiple extensions of different types are
-   present in the extended client hello or the extended server hello,
-   the extensions may appear in any order.  There MUST NOT be more than
-   one extension of the same type.
-
-   Finally note that all the extensions defined in this document are
-   relevant only when a session is initiated.  However, a client that
-   requests resumption of a session does not in general know whether the
-   server will accept this request, and therefore it SHOULD send an
-   extended client hello if it would normally do so for a new session.
-   If the resumption request is denied, then a new set of extensions
-   will be negotiated as normal.  If, on the other hand, the older
-   session is resumed, then the server MUST ignore extensions appearing
-   in the client hello, and send a server hello containing no
-   extensions; in this case the extension functionality negotiated
-   during the original session initiation is applied to the resumed
-   session.
-
-2.4. Extensions to the handshake protocol
-
-   This document suggests the use of two new handshake messages,
-   "CertificateURL" and "CertificateStatus".  These messages are
-   described in Section 3.3 and Section 3.6, respectively. The new
-   handshake message structure therefore becomes:
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), certificate_url(21), certificate_status(22),
-          (255)
-      } HandshakeType;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 7]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case certificate_url:     CertificateURL;
-              case certificate_status:  CertificateStatus;
-          } body;
-      } Handshake;
-
-3. Specific Extensions
-
-   This section describes the specific TLS extensions specified in this
-   document.
-
-   Note that any messages associated with these extensions that are sent
-   during the TLS handshake MUST be included in the hash calculations
-   involved in "Finished" messages.
-
-   Section 3.1 describes the extension of TLS to allow a client to
-   indicate which server it is contacting.  Section 3.2 describes the
-   extension to provide maximum fragment length negotiation.  Section
-   3.3 describes the extension to allow client certificate URLs.
-   Section 3.4 describes the extension to allow a client to indicate
-   which CA root keys it possesses.  Section 3.5 describes the extension
-   to allow the use of truncated HMAC.  Section 3.6 describes the
-   extension to support integration of certificate status information
-   messages into TLS handshakes.
-
-3.1. Server Name Indication
-
-   [TLS] does not provide a mechanism for a client to tell a server the
-   name of the server it is contacting.  It may be desirable for clients
-   to provide this information to facilitate secure connections to
-   servers that host multiple 'virtual' servers at a single underlying
-   network address.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 8]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-      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;
-
-   Currently the only server names supported are DNS hostnames, however
-   this does not imply any dependency of TLS on DNS, and other name
-   types may be added in the future (by an RFC that Updates this
-   document).  TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client. The hostname is represented as a byte
-   string using UTF-8 encoding [UTF8], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in section 3.1
-   of [IDNA] notwithstanding). If the server needs to match the HostName
-   against names that contain non-US-ASCII characters, it MUST perform
-   the conversion operation described in section 4 of [IDNA], treating
-   the HostName as a "query string" (i.e. the AllowUnassigned flag MUST
-   be set). Note that IDNA allows labels to be separated by any of the
-   Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore
-   servers MUST accept any of these characters as a label separator.  If
-   the server only needs to match the HostName against names containing
-   exclusively ASCII characters, it MUST compare ASCII names case-
-   insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                     [Page 9]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   It is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension, MAY use the information contained in the extension to
-   guide its selection of an appropriate certificate to return to the
-   client, and/or other aspects of security policy.  In this event, the
-   server SHALL include an extension of type "server_name" in the
-   (extended) server hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol, then upgrades to TLS, and a server_name extension is sent,
-   then the extension SHOULD contain the same name that was negotiated
-   in the application protocol.  If the server_name is established in
-   the TLS session handshake, the client SHOULD NOT attempt to request a
-   different server name at the application layer.
-
-3.2. Maximum Fragment Length Negotiation
-
-   [TLS] specifies a fixed maximum plaintext fragment length of 2^14
-   bytes.  It may be desirable for constrained clients to negotiate a
-   smaller maximum fragment length due to memory limitations or
-   bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain:
-
-      enum{
-          2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-      } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length.  The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 10]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension, MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL contain
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert.  Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent.  Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [TLS] section 6.2.1).  Note that the output
-   of the record layer may be larger.  For example, if the negotiated
-   length is 2^9=512, then for currently defined cipher suites (those
-   defined in [TLS], [KERB], and [AESSUITES]), and when null compression
-   is used, the record layer output can be at most 793 bytes: 5 bytes of
-   headers, 512 bytes of application data, 256 bytes of padding, and 20
-   bytes of MAC.  That means that in this event a TLS record layer peer
-   receiving a TLS record layer message larger than 793 bytes may
-   discard the message and send a "record_overflow" alert, without
-   decrypting the message.
-
-3.3. Client Certificate URLs
-
-   [TLS] specifies that when client authentication is performed, client
-   certificates are sent by clients to servers during the TLS handshake.
-   It may be desirable for constrained clients to send certificate URLs
-   in place of certificates, so that they do not need to store their
-   certificates and can therefore save memory.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 11]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   In order to negotiate to send certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-   (extended) client hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS 1.0 servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension, MAY indicate that they are
-   willing to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message:
-
-      enum {
-          individual_certs(0), pkipath(1), (255)
-      } CertChainType;
-
-      enum {
-          false(0), true(1)
-      } Boolean;
-
-      struct {
-          CertChainType type;
-          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-      } CertificateURL;
-
-      struct {
-          opaque url<1..2^16-1>;
-          Boolean hash_present;
-          select (hash_present) {
-              case false: struct {};
-              case true: SHA1Hash;
-          } hash;
-      } URLAndOptionalHash;
-
-      opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 12]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   When X.509 certificates are used, there are two possibilities:
-
-   -  if CertificateURL.type is "individual_certs", each URL refers to a
-      single DER-encoded X.509v3 certificate, with the URL for the
-      client's certificate first, or
-
-   -  if CertificateURL.type is "pkipath", the list contains a single
-      URL referring to a DER-encoded certificate chain, using the type
-      PkiPath described in Section 8.
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion is
-   either not present or is the SHA-1 hash of the certificate or
-   certificate chain (in the case of X.509 certificates, the DER-encoded
-   certificate or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [TLS] Section 7.4.2), but opposite to the order in which
-   certificates are encoded in PkiPath.  In either case, the self-signed
-   root certificate MAY be omitted from the chain, under the assumption
-   that the server must already possess it in order to validate it.
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs, and then process the
-   certificate chain as usual.  A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-   for certificate URLs, and MAY support other schemes.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
-   when a chain of X.509v3 certificates is returned, the Content-Type is
-   "application/pkix-pkipath" (see Section 8).
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 13]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash.  If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs. The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-3.4. Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys, may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-      struct {
-          TrustedAuthority trusted_authorities_list<0..2^16-1>;
-      } TrustedAuthorities;
-
-      struct {
-          IdentifierType identifier_type;
-          select (identifier_type) {
-              case pre_agreed: struct {};
-              case key_sha1_hash: SHA1Hash;
-              case x509_name: DistinguishedName;
-              case cert_sha1_hash: SHA1Hash;
-          } identifier;
-      } TrustedAuthority;
-
-      enum {
-          pre_agreed(0), key_sha1_hash(1), x509_name(2),
-          cert_sha1_hash(3), (255)
-      } IdentifierType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 14]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses.  Each CA root key is identified via
-   either:
-
-   -  "pre_agreed" - no CA root key identity supplied.
-
-   -  "key_sha1_hash" - contains the SHA-1 hash of the CA root key.  For
-      DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
-      value.  For RSA keys, the hash is of the big-endian byte string
-      representation of the modulus without any initial 0-valued bytes.
-      (This copies the key hash formats deployed in other environments.)
-
-   -  "x509_name" - contains the DER-encoded X.509 DistinguishedName of
-      the CA.
-
-   -  "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded
-      Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer - for example if
-   a particular CA has multiple key pairs - however here we assume this
-   is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension, MAY use the information contained in the extension to
-   guide their selection of an appropriate certificate chain to return
-   to the client.  In this event, the server SHALL include an extension
-   of type "trusted_ca_keys" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-3.5. Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [HMAC] to authenticate record layer
-   communications.  In TLS the entire output of the hash function is
-   used as the MAC tag.  However it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 15]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-   include an extension of type "truncated_hmac" in the extended client
-   hello.  The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension, MAY agree to use a truncated HMAC by including an
-   extension of type "truncated_hmac", with empty "extension_data", in
-   the extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect.  It is strongly recommended that any new cipher
-   suites using other MACs consider the MAC size as an integral part of
-   the cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters.  Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [HMAC].  That is, CipherSpec.hash_size is 10 bytes, and
-   only the first 10 bytes of the HMAC output are transmitted and
-   checked.  Note that this extension does not affect the calculation of
-   the PRF as part of handshaking or key derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-3.6. Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [OCSP] to check the validity of server certificates, in
-   order to avoid transmission of CRLs and therefore save bandwidth on
-   constrained networks.  This extension allows for such information to
-   be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "CertificateStatusRequest" where:
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 16]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPStatusRequest;
-          } request;
-      } CertificateStatusRequest;
-
-      enum { ocsp(1), (255) } CertificateStatusType;
-
-      struct {
-          ResponderID responder_id_list<0..2^16-1>;
-          Extensions  request_extensions;
-      } OCSPStatusRequest;
-
-      opaque ResponderID<1..2^16-1>;
-      opaque Extensions<0..2^16-1>;
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts.  A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server - e.g., by prior arrangement.  "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [OCSP].  "Extensions" is imported from [PKIX].  A zero-
-   length "request_extensions" value means that there are no extensions
-   (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
-   the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-   Servers that receive a client hello containing the "status_request"
-   extension, MAY return a suitable certificate status response to the
-   client along with their certificate.  If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder, and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages).  If a server returns a
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 17]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPResponse;
-          } response;
-      } CertificateStatus;
-
-      opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [OCSP]).  Note that
-   only one OCSP response may be sent.
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response, and receiving an OCSP response
-   in a "CertificateStatus" message MUST check the OCSP response and
-   abort the handshake if the response is not satisfactory.
-
-4. Error Alerts
-
-   This section defines new error alerts for use with the TLS extensions
-   defined in this document.
-
-   The following new error alerts are defined.  To avoid "breaking"
-   existing clients and servers, these alerts MUST NOT be sent unless
-   the sending party has received an extended hello message from the
-   party they are communicating with.
-
-   -  "unsupported_extension" - this alert is sent by clients that
-      receive an extended server hello containing an extension that they
-      did not put in the corresponding client hello (see Section 2.3).
-      This message is always fatal.
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 18]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   -  "unrecognized_name" - this alert is sent by servers that receive a
-      server_name extension request, but do not recognize the server
-      name.  This message MAY be fatal.
-
-   -  "certificate_unobtainable" - this alert is sent by servers who are
-      unable to retrieve a certificate chain from the URL supplied by
-      the client (see Section 3.3).  This message MAY be fatal - for
-      example if client authentication is required by the server for the
-      handshake to continue and the server is unable to retrieve the
-      certificate chain, it may send a fatal alert.
-
-   -  "bad_certificate_status_response" - this alert is sent by clients
-      that receive an invalid certificate status response (see Section
-      3.6).  This message is always fatal.
-
-   -  "bad_certificate_hash_value" - this alert is sent by servers when
-      a certificate hash does not match a client provided
-      certificate_hash.  This message is always fatal.
-
-   These error alerts are conveyed using the following syntax:
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          /* 41 is not defined, for historical reasons */
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-          export_restriction(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-          no_renegotiation(100),
-          unsupported_extension(110),           /* new */
-          certificate_unobtainable(111),        /* new */
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 19]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-          unrecognized_name(112),               /* new */
-          bad_certificate_status_response(113), /* new */
-          bad_certificate_hash_value(114),      /* new */
-          (255)
-      } AlertDescription;
-
-5. Procedure for Defining New Extensions
-
-   Traditionally for Internet protocols, the Internet Assigned Numbers
-   Authority (IANA) handles the allocation of new values for future
-   expansion, and RFCs usually define the procedure to be used by the
-   IANA.  However, there are subtle (and not so subtle) interactions
-   that may occur in this protocol between new features and existing
-   features which may result in a significant reduction in overall
-   security.
-
-   Therefore, requests to define new extensions (including assigning
-   extension and error alert numbers) must be approved by IETF Standards
-   Action.
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-   -  All of the extensions defined in this document follow the
-      convention that for each extension that a client requests and that
-      the server understands, the server replies with an extension of
-      the same type.
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some simply a refusal to support a particular
-      feature.  In general error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should as far as possible be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase. Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 20]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS - particularly since
-      the TLS handshake algorithms have specific protection against
-      version rollback attacks based on the version number, and the
-      possibility of version rollback should be a significant
-      consideration in any major design change.
-
-6. Security Considerations
-
-   Security considerations for the extension mechanism in general, and
-   the design of new extensions, are described in the previous section.
-   A security analysis of each of the extensions defined in this
-   document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art, and address any weaknesses identified.
-
-   Additional security considerations are described in the TLS 1.0 RFC
-   [TLS].
-
-6.1. Security of server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs.  Apart from this, server_name does not appear
-   to introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS - in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed.  It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-6.2. Security of max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages.  However, that does not introduce any security
-   complications that are not already present in TLS, since [TLS]
-   requires implementations to be able to handle fragmented handshake
-   messages.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 21]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Note that as described in section 3.2, once a non-null cipher suite
-   has been activated, the effective maximum fragment length depends on
-   the cipher suite and compression method, as well as on the negotiated
-   max_fragment_length.  This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-6.3. Security of client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes.  The purpose of including
-   hashes and checking them against the retrieved certificate chain, is
-   to ensure that the same property holds when this extension is used -
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances - for example clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client.  Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here.  The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server acting as a client in another URL protocol.  The
-   server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some, possibly weird-looking URL.
-
-   In general this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw.  It also introduces the possibility of denial of service
-   attacks in which an attacker makes many connections to the server,
-   each of which results in the server attempting a connection to the
-   target of the attack.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 22]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet; this could exacerbate the potential security and denial of
-   service problems described above, as well as allowing the existence
-   of internal hosts to be confirmed when they would otherwise be
-   hidden.
-
-   The detailed security concerns involved will depend on the URL
-   schemes supported by the server.  In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server.  In the case of HTTPS, the possibility for loops and
-   deadlocks to be created exists and should be addressed.  In the case
-   of FTP, attacks similar to FTP bounce attacks arise.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than being enabled by
-   default.  It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled, with unusual protocols offering limited security or whose
-   security is not well-understood being avoided.
-
-   As discussed in [URI], URLs that specify ports other than the default
-   may cause problems, as may very long URLs (which are more likely to
-   be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly.  If a request using HTTP (or another caching protocol)
-   goes through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-6.4. Security of trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information.  As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously.  As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-6.5. Security of truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs.  However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 23]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Note that the output length of a MAC need not be as long as the
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after the handshake
-   messages have been authenticated by the hashes in the Finished
-   messages, it is not possible for an active attacker to force
-   negotiation of the truncated HMAC extension where it would not
-   otherwise be used (to the extent that the handshake authentication is
-   secure).  Therefore, in the event that any security problem were
-   found with truncated HMAC in future, if either the client or the
-   server for a given session were updated to take into account the
-   problem, they would be able to veto use of this extension.
-
-6.6. Security of status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension.  A client that requires
-   OCSP validation of certificates SHOULD either contact the OCSP server
-   directly in this case, or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see section 4.4.1 of [OCSP] for further details.
-
-7. Internationalization Considerations
-
-   None of the extensions defined here directly use strings subject to
-   localization.  Domain Name System (DNS) hostnames are encoded using
-   UTF-8.  If future extensions use text strings, then
-   internationalization should be considered in their design.
-
-8. IANA Considerations
-
-   The MIME type "application/pkix-pkipath" has been registered by the
-   IANA with the following template:
-
-   To: ietf-types@iana.org Subject: Registration of MIME media type
-   application/pkix-pkipath
-
-   MIME media type name: application
-
-   MIME subtype name: pkix-pkipath
-
-   Required parameters: none
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 24]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Optional parameters: version (default value is "1")
-
-   Encoding considerations:
-      This MIME type is a DER encoding of the ASN.1 type PkiPath,
-      defined as follows:
-        PkiPath ::= SEQUENCE OF Certificate
-        PkiPath is used to represent a certification path.  Within the
-        sequence, the order of certificates is such that the subject of
-        the first certificate is the issuer of the second certificate,
-        etc.
-
-      This is identical to the definition that will be published in
-      [X509-4th-TC1]; note that it is different from that in [X509-4th].
-
-      All Certificates MUST conform to [PKIX].  (This should be
-      interpreted as a requirement to encode only PKIX-conformant
-      certificates using this type.  It does not necessarily require
-      that all certificates that are not strictly PKIX-conformant must
-      be rejected by relying parties, although the security consequences
-      of accepting any such certificates should be considered
-      carefully.)
-
-      DER (as opposed to BER) encoding MUST be used.  If this type is
-      sent over a 7-bit transport, base64 encoding SHOULD be used.
-
-   Security considerations:
-      The security considerations of [X509-4th] and [PKIX] (or any
-      updates to them) apply, as well as those of any protocol that uses
-      this type (e.g., TLS).
-
-      Note that this type only specifies a certificate chain that can be
-      assessed for validity according to the relying party's existing
-      configuration of trusted CAs; it is not intended to be used to
-      specify any change to that configuration.
-
-   Interoperability considerations:
-      No specific interoperability problems are known with this type,
-      but for recommendations relating to X.509 certificates in general,
-      see [PKIX].
-
-   Published specification: this memo, and [PKIX].
-
-   Applications which use this media type: TLS.  It may also be used by
-      other protocols, or for general interchange of PKIX certificate
-      chains.
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 25]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   Additional information:
-      Magic number(s): DER-encoded ASN.1 can be easily recognized.
-        Further parsing is required to distinguish from other ASN.1
-        types.
-      File extension(s): .pkipath
-      Macintosh File Type Code(s): not specified
-
-   Person & email address to contact for further information:
-      Magnus Nystrom <magnus@rsasecurity.com>
-
-   Intended usage: COMMON
-
-   Author/Change controller:
-      Magnus Nystrom <magnus@rsasecurity.com>
-
-9. Intellectual Property Rights
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; neither does it represent that it
-   has made any effort to identify any such rights.  Information on the
-   IETF's procedures with respect to rights in standards-track and
-   standards-related documentation can be found in RFC 2028.  Copies of
-   claims of rights made available for publication and any assurances of
-   licenses to be made available, or the result of an attempt made to
-   obtain a general license or permission for the use of such
-   proprietary rights by implementors or users of this specification can
-   be obtained from the IETF Secretariat.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights which may cover technology that may be required to practice
-   this document.  Please address the information to the IETF Executive
-   Director.
-
-10. Acknowledgments
-
-   The authors wish to thank the TLS Working Group and the WAP Security
-   Group.  This document is based on discussion within these groups.
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 26]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-11. Normative References
-
-   [HMAC]         Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
-                  Keyed-hashing for message authentication", RFC 2104,
-                  February 1997.
-
-   [HTTP]         Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
-                  Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
-                  Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
-   [IDNA]         Faltstrom, P., Hoffman, P. and A. Costello,
-                  "Internationalizing Domain Names in Applications
-                  (IDNA)", RFC 3490, March 2003.
-
-   [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [OCSP]         Myers, M., Ankney, R., Malpani, A., Galperin, S. and
-                  C. Adams, "Internet X.509 Public Key Infrastructure:
-                  Online Certificate Status Protocol - OCSP", RFC 2560,
-                  June 1999.
-
-   [PKIOP]        Housley, R. and P. Hoffman, "Internet X.509 Public Key
-                  Infrastructure - Operation Protocols: FTP and HTTP",
-                  RFC 2585, May 1999.
-
-   [PKIX]         Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
-                  Public Key Infrastructure - Certificate and
-                  Certificate Revocation List (CRL) Profile", RFC 3280,
-                  April 2002.
-
-   [TLS]          Dierks, T. and C. Allen, "The TLS Protocol Version
-                  1.0", RFC 2246, January 1999.
-
-   [URI]          Berners-Lee, T., Fielding, R. and L. Masinter,
-                  "Uniform Resource Identifiers (URI): Generic Syntax",
-                  RFC 2396, August 1998.
-
-   [UTF8]         Yergeau, F., "UTF-8, a transformation format of ISO
-                  10646", RFC 2279, January 1998.
-
-   [X509-4th]     ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-
-                  8:2001, "Information Systems - Open Systems
-                  Interconnection - The Directory:  Public key and
-                  attribute certificate frameworks."
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 27]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-                  ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
-                  1 to ISO/IEC 9594:8:2001.
-
-12. Informative References
-
-   [KERB]         Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-                  Suites to Transport Layer Security (TLS)", RFC 2712,
-                  October 1999.
-
-   [MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
-                  ClientHello extension mechanism and virtual hosting,"
-                  ietf-tls mailing list posting, August 14, 2000.
-
-   [AESSUITES]    Chown, P., "Advanced Encryption Standard (AES)
-                  Ciphersuites for Transport Layer Security (TLS)", RFC
-                  3268, June 2002.
-
-13. Authors' Addresses
-
-   Simon Blake-Wilson
-   BCI
-   EMail: sblakewilson@bcisse.com
-
-   Magnus Nystrom
-   RSA Security
-   EMail: magnus@rsasecurity.com
-
-   David Hopwood
-   Independent Consultant
-   EMail: david.hopwood@zetnet.co.uk
-
-   Jan Mikkelsen
-   Transactionware
-   EMail: janm@transactionware.com
-
-   Tim Wright
-   Vodafone
-   EMail: timothy.wright@vodafone.com
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 28]
-
-RFC 3546                     TLS Extensions                    June 2003
-
-
-14.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et. al.       Standards Track                    [Page 29]
-
diff --git a/doc/protocol/rfc3749.txt b/doc/protocol/rfc3749.txt
deleted file mode 100644
index f0cda3c5fb..0000000000
--- a/doc/protocol/rfc3749.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      S. Hollenbeck
-Request for Comments: 3749                                VeriSign, Inc.
-Category: Standards Track                                       May 2004
-
-
-
-         Transport Layer Security Protocol Compression Methods
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   The Transport Layer Security (TLS) protocol (RFC 2246) includes
-   features to negotiate selection of a lossless data compression method
-   as part of the TLS Handshake Protocol and to then apply the algorithm
-   associated with the selected method as part of the TLS Record
-   Protocol.  TLS defines one standard compression method which
-   specifies that data exchanged via the record protocol will not be
-   compressed.  This document describes an additional compression method
-   associated with a lossless data compression algorithm for use with
-   TLS, and it describes a method for the specification of additional
-   TLS compression methods.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  Compression Methods  . . . . . . . . . . . . . . . . . . . . .  2
-       2.1.  DEFLATE Compression. . . . . . . . . . . . . . . . . . .  3
-   3.  Compression History and Packet Processing  . . . . . . . . . .  4
-   4.  Internationalization Considerations  . . . . . . . . . . . . .  4
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       8.1.  Normative References . . . . . . . . . . . . . . . . . .  6
-       8.2.  Informative References . . . . . . . . . . . . . . . . .  6
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
-       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
-
-
-
-Hollenbeck                  Standards Track                     [Page 1]
-
-RFC 3749                TLS Compression Methods                 May 2004
-
-
-1.  Introduction
-
-   The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes
-   features to negotiate selection of a lossless data compression method
-   as part of the TLS Handshake Protocol and to then apply the algorithm
-   associated with the selected method as part of the TLS Record
-   Protocol.  TLS defines one standard compression method,
-   CompressionMethod.null, which specifies that data exchanged via the
-   record protocol will not be compressed.  While this single
-   compression method helps ensure that TLS implementations are
-   interoperable, the lack of additional standard compression methods
-   has limited the ability of implementers to develop interoperable
-   implementations that include data compression.
-
-   TLS is used extensively to secure client-server connections on the
-   World Wide Web.  While these connections can often be characterized
-   as short-lived and exchanging relatively small amounts of data, TLS
-   is also being used in environments where connections can be long-
-   lived and the amount of data exchanged can extend into thousands or
-   millions of octets.  XML [4], for example, is increasingly being used
-   as a data representation method on the Internet, and XML tends to be
-   verbose.  Compression within TLS is one way to help reduce the
-   bandwidth and latency requirements associated with exchanging large
-   amounts of data while preserving the security services provided by
-   TLS.
-
-   This document describes an additional compression method associated
-   with a lossless data compression algorithm for use with TLS.
-   Standardization of the compressed data formats and compression
-   algorithms associated with this compression method is beyond the
-   scope of 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 [1].
-
-2.  Compression Methods
-
-   TLS [2] includes the following compression method structure in
-   sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:
-
-   enum { null(0), (255) } CompressionMethod;
-
-
-
-
-
-
-
-
-
-Hollenbeck                  Standards Track                     [Page 2]
-
-RFC 3749                TLS Compression Methods                 May 2004
-
-
-   which allows for later specification of up to 256 different
-   compression methods.  This definition is updated to segregate the
-   range of allowable values into three zones:
-
-   1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-      reserved for IETF Standards Track protocols.
-
-   2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
-      are reserved for assignment for non-Standards Track methods.
-
-   3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-      inclusive are reserved for private use.
-
-   Additional information describing the role of the IANA in the
-   allocation of compression method identifiers is described in Section
-   5.
-
-   In addition, this definition is updated to include assignment of an
-   identifier for the DEFLATE compression method:
-
-   enum { null(0), DEFLATE(1), (255) } CompressionMethod;
-
-   As described in section 6 of RFC 2246 [2], TLS is a stateful
-   protocol.  Compression methods used with TLS can be either stateful
-   (the compressor maintains its state through all compressed records)
-   or stateless (the compressor compresses each record independently),
-   but there seems to be little known benefit in using a stateless
-   compression method within TLS.
-
-   The DEFLATE compression method described in this document is
-   stateful.  It is RECOMMENDED that other compression methods that
-   might be standardized in the future be stateful as well.
-
-   Compression algorithms can occasionally expand, rather than compress,
-   input data.  A compression method that exceeds the expansion limits
-   described in section 6.2.2 of RFC 2246 [2] MUST NOT be used with TLS.
-
-2.1.  DEFLATE Compression
-
-   The DEFLATE compression method and encoding format is described in
-   RFC 1951 [5].  Examples of DEFLATE use in IETF protocols can be found
-   in RFC 1979 [6], RFC 2394 [7], and RFC 3274 [8].
-
-   DEFLATE allows the sending compressor to select from among several
-   options to provide varying compression ratios, processing speeds, and
-   memory requirements.  The receiving decompressor MUST automatically
-   adjust to the parameters selected by the sender.  All data that was
-   submitted for compression MUST be included in the compressed output,
-
-
-
-Hollenbeck                  Standards Track                     [Page 3]
-
-RFC 3749                TLS Compression Methods                 May 2004
-
-
-   with no data retained to be included in a later output payload.
-   Flushing ensures that each compressed packet payload can be
-   decompressed completely.
-
-3.  Compression History and Packet Processing
-
-   Some compression methods have the ability to maintain state/history
-   information when compressing and decompressing packet payloads.  The
-   compression history allows a higher compression ratio to be achieved
-   on a stream as compared to per-packet compression, but maintaining a
-   history across packets implies that a packet might contain data
-   needed to completely decompress data contained in a different packet.
-   History maintenance thus requires both a reliable link and sequenced
-   packet delivery.  Since TLS and lower-layer protocols provide
-   reliable, sequenced packet delivery, compression history information
-   MAY be maintained and exploited if supported by the compression
-   method.
-
-   As described in section 7 of RFC 2246 [2], TLS allows multiple
-   connections to be instantiated using the same session through the
-   resumption feature of the TLS Handshake Protocol.  Session resumption
-   has operational implications when multiple compression methods are
-   available for use within the session.  For example, load balancers
-   will need to maintain additional state information if the compression
-   state is not cleared when a session is resumed.  As a result, the
-   following restrictions MUST be observed when resuming a session:
-
-   1.  The compression algorithm MUST be retained when resuming a
-       session.
-
-   2.  The compression state/history MUST be cleared when resuming a
-       session.
-
-4.  Internationalization Considerations
-
-   The compression method identifiers specified in this document are
-   machine-readable numbers.  As such, issues of human
-   internationalization and localization are not introduced.
-
-5.  IANA Considerations
-
-   Section 2 of this document describes a registry of compression method
-   identifiers to be maintained by the IANA, including assignment of an
-   identifier for the DEFLATE compression method.  Identifier values
-   from the range 0-63 (decimal) inclusive are assigned via RFC 2434
-   Standards Action [3].  Values from the range 64-223 (decimal)
-
-
-
-
-
-Hollenbeck                  Standards Track                     [Page 4]
-
-RFC 3749                TLS Compression Methods                 May 2004
-
-
-   inclusive are assigned via RFC 2434 Specification Required [3].
-   Identifier values from 224-255 (decimal) inclusive are reserved for
-   RFC 2434 Private Use [3].
-
-6.  Security Considerations
-
-   This document does not introduce any topics that alter the threat
-   model addressed by TLS.  The security considerations described
-   throughout RFC 2246 [2] apply here as well.
-
-   However, combining compression with encryption can sometimes reveal
-   information that would not have been revealed without compression:
-   data that is the same length before compression might be a different
-   length after compression, so adversaries that observe the length of
-   the compressed data might be able to derive information about the
-   corresponding uncompressed data.  Some symmetric encryption
-   ciphersuites do not hide the length of symmetrically encrypted data
-   at all.  Others hide it to some extent, but still do not hide it
-   fully.  For example, ciphersuites that use stream cipher encryption
-   without padding do not hide length at all; ciphersuites that use
-   Cipher Block Chaining (CBC) encryption with padding provide some
-   length hiding, depending on how the amount of padding is chosen.  Use
-   of TLS compression SHOULD take into account that the length of
-   compressed data may leak more information than the length of the
-   original uncompressed data.
-
-   Compression algorithms tend to be mathematically complex and prone to
-   implementation errors.  An implementation error that can produce a
-   buffer overrun introduces a potential security risk for programming
-   languages and operating systems that do not provide buffer overrun
-   protections.  Careful consideration should thus be given to
-   protections against implementation errors that introduce security
-   risks.
-
-   As described in Section 2, compression algorithms can occasionally
-   expand, rather than compress, input data.  This feature introduces
-   the ability to construct rogue data that expands to some enormous
-   size when compressed or decompressed.  RFC 2246 describes several
-   methods to ameliorate this kind of attack.  First, compression has to
-   be lossless.  Second, a limit (1,024 bytes) is placed on the amount
-   of allowable compression content length increase.  Finally, a limit
-   (2^14 bytes) is placed on the total content length.  See section
-   6.2.2 of RFC 2246 [2] for complete details.
-
-
-
-
-
-
-
-
-Hollenbeck                  Standards Track                     [Page 5]
-
-RFC 3749                TLS Compression Methods                 May 2004
-
-
-7.  Acknowledgements
-
-   The concepts described in this document were originally discussed on
-   the IETF TLS working group mailing list in December, 2000.  The
-   author acknowledges the contributions to that discussion provided by
-   Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen.  Later
-   suggestions that have been incorporated into this document were
-   provided by Tim Dierks, Pasi Eronen, Peter Gutmann, Elgin Lee, Nikos
-   Mavroyanopoulos, Alexey Melnikov, Bodo Moeller, Win Treese, and the
-   IESG.
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-        2246, January 1999.
-
-   [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-8.2.  Informative References
-
-   [4]  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
-        "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
-        October 2000, <http://www.w3.org/TR/REC-xml>.
-
-   [5]  Deutsch, P., "DEFLATE Compressed Data Format Specification
-        version 1.3", RFC 1951, May 1996.
-
-   [6]  Woods, J., "PPP Deflate Protocol", RFC 1979, August 1996.
-
-   [7]  Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394,
-        December 1998.
-
-   [8]  Gutmann, P., "Compressed Data Content Type for Cryptographic
-        Message Syntax (CMS)", RFC 3274, June 2002.
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck                  Standards Track                     [Page 6]
-
-RFC 3749                TLS Compression Methods                 May 2004
-
-
-Author's Address
-
-   Scott Hollenbeck
-   VeriSign, Inc.
-   21345 Ridgetop Circle
-   Dulles, VA  20166-6503
-   US
-
-   EMail: shollenbeck@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hollenbeck                  Standards Track                     [Page 7]
-
-RFC 3749                TLS Compression Methods                 May 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).  This document is subject
-   to the rights, licenses and restrictions contained in BCP 78, and
-   except as set forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Hollenbeck                  Standards Track                     [Page 8]
-
diff --git a/doc/protocol/rfc3943.txt b/doc/protocol/rfc3943.txt
deleted file mode 100644
index 5ccf275152..0000000000
--- a/doc/protocol/rfc3943.txt
+++ /dev/null
@@ -1,731 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Friend
-Request for Comments: 3943                                          Hifn
-Category: Informational                                    November 2004
-
-
-       Transport Layer Security (TLS) Protocol Compression Using
-                         Lempel-Ziv-Stac (LZS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   The Transport Layer Security (TLS) protocol (RFC 2246) includes
-   features to negotiate selection of a lossless data compression method
-   as part of the TLS Handshake Protocol and then to apply the algorithm
-   associated with the selected method as part of the TLS Record
-   Protocol.  TLS defines one standard compression method, which
-   specifies that data exchanged via the record protocol will not be
-   compressed.  This document describes an additional compression method
-   associated with the Lempel-Ziv-Stac (LZS) lossless data compression
-   algorithm for use with TLS.  This document also defines the
-   application of the LZS algorithm to the TLS Record Protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Friend                       Informational                      [Page 1]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.1.  General. . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.2.  Specification of Requirements. . . . . . . . . . . . . .  3
-   2.  Compression Methods. . . . . . . . . . . . . . . . . . . . . .  3
-       2.1.  LZS CompresionMethod . . . . . . . . . . . . . . . . . .  4
-       2.2.  Security Issues with Single History Compression. . . . .  4
-   3.  LZS Compression. . . . . . . . . . . . . . . . . . . . . . . .  4
-       3.1.  Background of LZS Compression  . . . . . . . . . . . . .  4
-       3.2.  LZS Compression History and Record Processing  . . . . .  5
-       3.3.  LZS Compressed Record Format . . . . . . . . . . . . . .  6
-       3.4.  TLSComp Header Format  . . . . . . . . . . . . . . . . .  6
-             3.4.1.  Flags. . . . . . . . . . . . . . . . . . . . . .  6
-       3.5.  LZS Compression Encoding Format  . . . . . . . . . . . .  7
-       3.6.  Padding  . . . . . . . . . . . . . . . . . . . . . . . .  8
-   4.  Sending Compressed Records . . . . . . . . . . . . . . . . . .  8
-       4.1.  Transmitter Process. . . . . . . . . . . . . . . . . . .  9
-       4.2.  Receiver Process . . . . . . . . . . . . . . . . . . . .  9
-       4.3.  Anti-expansion Mechanism . . . . . . . . . . . . . . . . 10
-   5.  Internationalization Considerations .  . . . . . . . . . . . . 10
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 11
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-       9.1.  Normative References . . . . . . . . . . . . . . . . . . 12
-       9.2.  Informative References . . . . . . . . . . . . . . . . . 12
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
-
-1. Introduction
-
-1.1.  General
-
-   The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes
-   features to negotiate selection of a lossless data compression method
-   as part of the TLS Handshake Protocol and then to apply the algorithm
-   associated with the selected method as part of the TLS Record
-   Protocol.  TLS defines one standard compression method,
-   CompressionMethod.null, which specifies that data exchanged via the
-   record protocol will not be compressed.  Although this single
-   compression method helps ensure that TLS implementations are
-   interoperable, the lack of additional standard compression methods
-   has limited the ability to develop interoperative implementations
-   that include data compression.
-
-
-
-
-
-
-Friend                       Informational                      [Page 2]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-   TLS is used extensively to secure client-server connections on the
-   World Wide Web.  Although these connections can often be
-   characterized as short-lived and exchanging relatively small amounts
-   of data, TLS is also being used in environments where connections can
-   be long-lived and the amount of data exchanged can extend into
-   thousands or millions of octets.  For example, TLS is now
-   increasingly being used as an alternative Virtual Private Network
-   (VPN) connection.  Compression services have long been associated
-   with IPSec and PPTP VPN connections, so extending compression
-   services to TLS VPN connections preserves the user experience for any
-   VPN connection.  Compression within TLS is one way to help reduce the
-   bandwidth and latency requirements associated with exchanging large
-   amounts of data while preserving the security services provided by
-   TLS.
-
-   This document describes an additional compression method associated
-   with a lossless data compression algorithm for use with TLS.  This
-   document specifies the application of Lempel-Ziv-Stac (LZS)
-   compression, a lossless compression algorithm, to TLS record
-   payloads.  This specification also assumes a thorough understanding
-   of the TLS protocol [2].
-
-1.2.  Specification of Requirements
-
-   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 BCP 14, RFC 2119 [1].
-
-2.  Compression Methods
-
-   As described in section 6 of RFC 2246 [2], TLS is a stateful
-   protocol.  Compression methods used with TLS can be either stateful
-   (the compressor maintains its state through all compressed records)
-   or stateless (the compressor compresses each record independently),
-   but there seems to be little known benefit in using a stateless
-   compression method within TLS.  The LZS compression method described
-   in this document is stateful.
-
-   Compression algorithms can occasionally expand, rather than compress,
-   input data.  The worst-case expansion factor of the LZS compression
-   method is only 12.5%.  Thus, TLS records of 15K bytes can never
-   exceed the expansion limits described in section 6.2.2 of RFC 2246
-   [2].  If TLS records of 16K bytes expand to an amount greater than
-   17K bytes, then the uncompressed version of the TLS record must be
-   transmitted, as described below.
-
-
-
-
-
-
-Friend                       Informational                      [Page 3]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-2.1.  LZS CompressionMethod
-
-   The LZS CompressionMethod is a 16-bit index and is negotiated as
-   described in RFC 2246 [2] and RFC 3749 [3].  The LZS
-   CompressionMethod is stored in the TLS Record Layer connection state
-   as described in RFC 2246 [2].
-
-   IANA has assigned 64 as compression method identifier for applying
-   LZS compression to TLS record payloads.
-
-2.2.  Security Issues with Compression Histories
-
-   Sharing compression histories between or among more than one TLS
-   session may potentially cause information leakage between the TLS
-   sessions, as pathological compressed data can potentially reference
-   data prior to the beginning of the current record.  LZS
-   implementations guard against this situation.  However, to avoid this
-   potential threat, implementations supporting TLS compression MUST use
-   separate compression histories for each TLS session.  This is not a
-   limitation of LZS compression but is an artifact for any compression
-   algorithm.
-
-   Furthermore, the LZS compression history (as well as any compression
-   history) contains plaintext.  Specifically, the LZS history contains
-   the last 2K bytes of plaintext of the TLS session.  Thus, when the
-   TLS session terminates, the implementation SHOULD treat the history
-   as it does any plaintext (e.g., free memory, overwrite contents).
-
-3.  LZS Compression
-
-3.1.  Background of LZS Compression
-
-   Starting with a sliding window compression history, similar to LZ1
-   [8], a new, enhanced compression algorithm identified as LZS was
-   developed.  The LZS algorithm is a general-purpose lossless
-   compression algorithm for use with a wide variety of data types. Its
-   encoding method is very efficient, providing compression for strings
-   as short as two octets in length.
-
-   The LZS algorithm uses a sliding window of 2,048 bytes.  During
-   compression, redundant sequences of data are replaced with tokens
-   that represent those sequences.  During decompression, the original
-   sequences are substituted for the tokens in such a way that the
-   original data is exactly recovered.  LZS differs from lossy
-   compression algorithms, such as those often used for video
-   compression, that do not exactly reproduce the original data.  The
-   details of LZS compression can be found in section 3.5 below.
-
-
-
-
-Friend                       Informational                      [Page 4]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-3.2.  LZS Compression History and Record Processing
-
-   This standard specifies "stateful" compression -- that is,
-   maintaining the compression history between records within a
-   particular TLS compression session.  Within each separate compression
-   history, the LZS CompressionMethod can maintain compression history
-   information when compressing and decompressing record payloads.
-   Stateful compression provides a higher compression ratio to be
-   achieved on the data stream, as compared to stateless compression
-   (resetting the compression history between every record),
-   particularly for small records.
-
-   Stateful compression requires both a reliable link and sequenced
-   record delivery to ensure that all records can be decompressed in the
-   same order they were compressed.  Since TLS and lower-layer protocols
-   provide reliable, sequenced record delivery, compression history
-   information MAY be maintained and exploited when the LZS
-   CompressionMethod is used.
-
-   Furthermore, there MUST be a separate LZS compression history
-   associated with each open TLS session.  This not only provides
-   enhanced security (no potential information leakage between sessions
-   via a shared compression history), but also enables superior
-   compression ratio (bit bandwidth on the connection) across all open
-   TLS sessions with compression.  A shared history would require
-   resetting the compression (and decompression) history when switching
-   between TLS sessions, and a single history implementation would
-   require resetting the compression (and decompression) history between
-   each record.
-
-   The sender MUST reset the compression history prior to compressing
-   the first TLS record of a TLS session after TLS handshake completes.
-   It is advantageous for the sender to maintain the compression history
-   for all subsequent records processed during the TLS session.  This
-   results in the greatest compression ratio for a given data set.  In
-   either case, this compression history MUST NOT be used for any other
-   open TLS session, to ensure privacy between TLS sessions.
-
-   The sender MUST "flush" the compressor each time it transmits a
-   compressed record.  Flushing means that all data going into the
-   compressor is included in the output, i.e., no data is retained in
-   the hope of achieving better compression.  Flushing ensures that each
-   compressed record payload can be decompressed completely. Flushing is
-   necessary to prevent a record's data from spilling over into a later
-   record.  This is important for synchronizing compressed data with the
-   authenticated and encrypted data in a TLS record.  Flushing is
-   handled automatically in most LZS implementations.
-
-
-
-
-Friend                       Informational                      [Page 5]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-   When the TLS session terminates, the implementation SHOULD dispose of
-   the memory resources associated with the related TLS compression
-   history.  That is, the compression history SHOULD be handled as the
-   TLS key material is handled.
-
-   The LZS CompressionMethod also features "decompressing" uncompressed
-   data in order to maintain the history if the "compressed" data
-   actually expanded.  The LZS CompressionMethod record format
-   facilitates identifying whether records contain compressed or
-   uncompressed data.  The LZS decoding process accommodates
-   decompressing either compressed or uncompressed data.
-
-3.3.  LZS Compressed Record Format
-
-   Prior to compression, the uncompressed data (TLSPlaintext.fragment)
-   is composed of a plaintext TLS record.  After compression, the
-   compressed data (TLSCompressed.fragment) is composed of an 8-bit
-   TLSComp header followed by the compressed (or uncompressed) data.
-
-3.4.  TLSComp Header Format
-
-   The one-octet header has the following structure:
-
-      0
-      0 1 2 3 4 5 6 7
-      +-+-+-+-+-+-+-+-+
-      |     Flags     |
-      |               |
-      +-+-+-+-+-+-+-+-+
-
-3.4.1.  Flags
-
-   The format of the 8-bit Flags TLSComp field is as follows:
-
-         0     1     2     3     4     5     6     7
-      +-----+-----+-----+-----+-----+-----+-----+-----+
-      | Res | Res | Res | Res | Res | Res | RST | C/U |
-      +-----+-----+-----+-----+-----+-----+-----+-----+
-
-   Res-Reserved
-
-      Reserved for future use.  MUST be set to zero.  MUST be ignored by
-      the receiving node.
-
-
-
-
-
-
-
-
-Friend                       Informational                      [Page 6]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-   RST-Reset Compression History
-
-      The RST bit is used to inform the decompressing peer that the
-      compression history in this TLS session was reset prior to the
-      data contained in this TLS record being compressed.  When the RST
-      bit is set to "1", a compression history reset is performed; when
-      RST is set to "0", a compression history reset is not performed.
-
-      This bit MUST be set to a value of "1" for the first compressed
-      TLS transmitted record of a TLS session.  This bit may also be
-      used by the transmitter for other exception cases when the
-      compression history must be reset.
-
-   C/U-Compressed/Uncompressed Bit
-
-      The C/U indicates whether the data field contains compressed or
-      uncompressed data.  A value of 1 indicates compressed data (often
-      referred to as a compressed record), and a value of 0 indicates
-      uncompressed data (or an uncompressed record).
-
-3.5.  LZS Compression Encoding Format
-
-   The LZS compression method, encoding format, and application examples
-   are described in RFC 1967 [6], RFC 1974 [5], and RFC 2395 [4].
-
-   Some implementations of LZS allow the sending compressor to select
-   from among several options to provide varying compression ratios,
-   processing speeds, and memory requirements.  Other implementations of
-   LZS provide optimal compression ratio at byte-per-clock speeds.
-
-   The receiving LZS decompressor automatically adjusts to the settings
-   selected by the sender.  Also, receiving LZS decompressors will
-   update the decompression history with uncompressed data.  This
-   facilitates never obtaining less than a 1:1 compression ratio in the
-   session and never transmitting with expanded data.
-
-   The input to the payload compression algorithm is TLSPlaintext data
-   destined to an active TLS session with compression negotiated.  The
-   output of the algorithm is a new (and hopefully smaller)
-   TLSCompressed record.  The output payload contains the input
-   payload's data in either compressed or uncompressed format.  The
-   input and output payloads are each an integral number of bytes in
-   length.
-
-   The output payload is always prepended with the TLSComp header.  If
-   the uncompressed form is used, the output payload is identical to the
-   input payload, and the TLSComp header reflects uncompressed data.
-
-
-
-
-Friend                       Informational                      [Page 7]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-   If the compressed form is used, encoded as defined in ANSI X3.241
-   [7], and the TLSComp header reflects compressed data.  The LZS
-   encoded format is repeated here for informational purposes ONLY.
-
-   <Compressed Stream> := [<Compressed String>*] <End Marker>
-   <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
-
-   <Raw Byte> := <b><b><b><b><b><b><b><b>          (8-bit byte)
-   <Compressed Bytes> := <Offset> <Length>
-
-   <Offset> := 1 <b><b><b><b><b><b><b> |           (7-bit offset)
-               0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
-   <End Marker> := 110000000
-   <b> := 1 | 0
-
-   <Length> :=
-   00        = 2     1111 0110      = 14
-   01        = 3     1111 0111      = 15
-   10        = 4     1111 1000      = 16
-   1100      = 5     1111 1001      = 17
-   1101      = 6     1111 1010      = 18
-   1110      = 7     1111 1011      = 19
-   1111 0000 = 8     1111 1100      = 20
-   1111 0001 = 9     1111 1101      = 21
-   1111 0010 = 10    1111 1110      = 22
-   1111 0011 = 11    1111 1111 0000 = 23
-   1111 0100 = 12    1111 1111 0001 = 24
-   1111 0101 = 13     ...
-
-3.6.  Padding
-
-   A datagram payload compressed with LZS always ends with the last
-   compressed data byte (also known as the <end marker>), which is used
-   to disambiguate padding.  This allows trailing bits, as well as
-   bytes, to be considered padding.
-
-   The size of a compressed payload MUST be in whole octet units.
-
-4.  Sending Compressed Datagrams
-
-   All TLS records processed with a TLS session state that includes LZS
-   compression are processed as follows.  The reliable and efficient
-   transport of LZS compressed records in the TLS session depends on the
-   following processes.
-
-
-
-
-
-
-
-Friend                       Informational                      [Page 8]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-4.1.  Transmitter Process
-
-   The compression operation results in either compressed or
-   uncompressed data.  When a TLS record is received, it is assigned to
-   a particular TLS context that includes the LZS compression history
-   buffer.  It is processed according to ANSI X3.241-1994 to form
-   compressed data or used as is to form uncompressed data.  For the
-   first record of the session, or for exception conditions, the
-   compression history MUST be cleared.  In performing the compression
-   operation, the compression history MUST be updated when either a
-   compressed record or an uncompressed record is produced.
-   Uncompressed TLS records MAY be sent at any time. Uncompressed TLS
-   records MUST be sent if compression causes enough expansion to make
-   the data compression TLS record size exceed the MTU defined in
-   section 6.2.2 in RFC 2246.  The output of the compression operation
-   is placed in the fragment field of the TLSCompressed structure
-   (TLSCompressed.fragment).
-
-   The TLSComp header byte is located just prior to the first byte of
-   the compressed TLS record in TLSCompressed.fragment.  The C/U bit in
-   the TLSComp header is set according to whether the data field
-   contains compressed or uncompressed data.  The RST bit in the TLSComp
-   header is set to "1" if the compression history was reset prior to
-   compressing the TLSplaintext.fragment that is composed of a
-   TLSCompressed.fragment.  Uncompressed data MUST be transmitted (and
-   the C/U bit set to 0) if the "compressed" (expanded) data exceeded
-   17K bytes.
-
-4.2.  Receiver Process
-
-   Prior to decompressing the first compressed TLS record in the TLS
-   session, the receiver MUST reset the decompression history.
-   Subsequent records are decompressed in the order received.  The
-   receiver decompresses the Payload Data field according to the
-   encoding specified in section 3.5 above.
-
-   If the received datagram is not compressed, the receiver does not
-   need to perform decompression processing, and the Payload Data field
-   of the datagram is ready for processing by the next protocol layer.
-
-   After a TLS record is received from the peer and decrypted, the RST
-   and C/U bits MUST be checked.
-
-   If the C/U bit is set to "1", the resulting compressed data block
-   MUST be decompressed according to section 3.5 above.
-
-   If the C/U bit is set to "0", the specified decompression history
-   MUST be updated with the received uncompressed data.
-
-
-
-Friend                       Informational                      [Page 9]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-   If the RST bit is set to "1", the receiving decompression history MAY
-   be reset to an initial state prior to decompressing the TLS record.
-   (However, due to the characteristics of the Hifn LZS algorithm, a
-   decompression history reset is not required).  After reset, any
-   compressed or uncompressed data contained in the record is processed.
-
-4.3.  Anti-expansion Mechanism
-
-   During compression, there are two workable options for handling
-   records that expand:
-
-   1) Send the expanded data (as long as TLSCompressed.length is 17K or
-      less) and maintain the history, thus allowing loss of current
-      bandwidth but preserving future bandwidth on the link.
-
-   2) Send the uncompressed data and do not clear the compression
-      history; the decompressor will update its history, thus conserving
-      the current bandwidth and future bandwidth on the link.
-
-   The second option is the preferred option and SHOULD be implemented.
-
-   There is a third option:
-
-   3) Send the uncompressed data and clear the history, thus conserving
-      current bandwidth but allowing possible loss of future bandwidth
-      on the link.
-
-   This option SHOULD NOT be implemented.
-
-5.  Internationalization Considerations
-
-   The compression method identifiers specified in this document are
-   machine-readable numbers.  As such, issues of human
-   internationalization and localization are not introduced.
-
-6.  IANA Considerations
-
-   Section 2 of RFC 3749 [3] describes a registry of compression method
-   identifiers to be maintained by the IANA and to be assigned within
-   three zones.
-
-   IANA has assigned an identifier for the LZS compression method from
-   the RFC 2434 Specification Required IANA pool, as described in
-   sections 2 and 5 of RFC 3749 [3].
-
-   The IANA-assigned compression method identifier for LZS is 64 decimal
-   (0x40).
-
-
-
-
-Friend                       Informational                     [Page 10]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-7.  Security Considerations
-
-   This document does not introduce any topics that alter the threat
-   model addressed by TLS.  The security considerations described
-   throughout RFC 2246 [2] apply here as well.
-
-   However, combining compression with encryption can sometimes reveal
-   information that would not have been revealed without compression.
-   Data that is the same length before compression might be a different
-   length after compression, so adversaries that observe the length of
-   the compressed data might be able to derive information about the
-   corresponding uncompressed data.  Some symmetric encryption
-   ciphersuites do not hide the length of symmetrically encrypted data
-   at all.  Others hide it to some extent but not fully.  For example,
-   ciphersuites that use stream cipher encryption without padding do not
-   hide length at all; ciphersuites that use Cipher Block Chaining (CBC)
-   encryption with padding provide some length hiding, depending on how
-   the amount of padding is chosen.  Use of TLS compression SHOULD take
-   into account that the length of compressed data may leak more
-   information than the length of the original uncompressed data.
-
-   Another security issue to be aware of is that the LZS compression
-   history contains plaintext.  In order to prevent any kind of
-   information leakage outside the system, when a TLS session with
-   compression terminates, the implementation SHOULD treat the
-   compression history as it does plaintext -- that is, care should be
-   taken not to reveal the compression history in any form or to use it
-   again.  This is described in sections 2.2 and 3.2 above.
-
-   This information leakage concept can be extended to the situation of
-   sharing a single compression history across more than one TLS
-   session, as addressed in section 2.2 above.
-
-   Other security issues are discussed in RFC 3749 [3].
-
-8.  Acknowledgements
-
-   The concepts described in this document were derived from RFC 1967
-   [6], RFC 1974 [5], RFC 2395 [4], and RFC 3749 [3].  The author
-   acknowledges the contributions of Scott Hollenbeck, Douglas Whiting,
-   and Russell Dietz, and help from Steve Bellovin, Russ Housley, and
-   Eric Rescorla.
-
-
-
-
-
-
-
-
-
-Friend                       Informational                     [Page 11]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-        2246, January 1999.
-
-   [3]  Hollenbeck, S. "Transport Layer Security Protocol Compression
-        Methods", RFC 3749, May 2004.
-
-9.2.  Informative References
-
-   [4]  Friend, R. and R. Monsour, "IP Payload Compression Using LZS",
-        RFC 2395, December 1998.
-
-   [5]  Friend, R. and W. Simpson, "PPP Stac LZS Compression Protocol",
-        RFC 1974, August 1996.
-
-   [6]  Schneider, K. and R. Friend, "PPP LZS-DCP Compression Protocol
-        (LZS-DCP)", RFC 1967, August 1996.
-
-   [7]  American National Standards Institute, Inc., "Data Compression
-        Method for Information Systems," ANSI X3.241-1994, August 1994.
-
-   [8]  Lempel, A. and J. Ziv, "A Universal Algorithm for Sequential
-        Data Compression", IEEE Transactions On Information Theory, Vol.
-        IT-23, No. 3, September 1977.
-
-Author's Address
-
-   Robert Friend
-   Hifn
-   5973 Avenida Encinas
-   Carlsbad, CA 92008
-   US
-
-   EMail: rfriend@hifn.com
-
-
-
-
-
-
-
-
-
-
-
-Friend                       Informational                     [Page 12]
-
-RFC 3943               TLS Compression Using LZS           November 2004
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2004).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and at www.rfc-editor.org, and except as set
-   forth therein, the authors retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the ISOC's procedures with respect to rights in ISOC Documents can
-   be found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Friend                       Informational                     [Page 13]
-
diff --git a/doc/protocol/rfc4132.txt b/doc/protocol/rfc4132.txt
deleted file mode 100644
index dd86a44c11..0000000000
--- a/doc/protocol/rfc4132.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          S. Moriai
-Request for Comments: 4132              Sony Computer Entertainment Inc.
-Category: Standards Track                                        A. Kato
-                                                NTT Software Corporation
-                                                                M. Kanda
-                              Nippon Telegraph and Telephone Corporation
-                                                               July 2005
-
-
-  Addition of Camellia Cipher Suites to Transport Layer Security (TLS)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document proposes the addition of new cipher suites to the
-   Transport Layer Security (TLS) protocol to support the Camellia
-   encryption algorithm as a bulk cipher algorithm.
-
-1.  Introduction
-
-   This document proposes the addition of new cipher suites to the TLS
-   protocol [TLS] to support the Camellia encryption algorithm as a bulk
-   cipher algorithm.  This proposal provides a new option for fast and
-   efficient bulk cipher algorithms.
-
-   Note: This work was done when the first author worked for NTT.
-
-1.1.  Camellia
-
-   Camellia was selected as a recommended cryptographic primitive by the
-   EU NESSIE (New European Schemes for Signatures, Integrity and
-   Encryption) project [NESSIE] and included in the list of
-   cryptographic techniques for Japanese e-Government systems, which
-   were selected by the Japan CRYPTREC (Cryptography Research and
-   Evaluation Committees) [CRYPTREC].  Camellia is also included in
-   specification of the TV-Anytime Forum [TV-ANYTIME].  The TV-Anytime
-   Forum is an association of organizations that seeks to develop
-
-
-
-Moriai, et al.              Standards Track                     [Page 1]
-
-RFC 4132             Camellia Cipher Suites for TLS            July 2005
-
-
-   specifications to enable audio-visual and other services based on
-   mass-market high-volume digital storage in consumer platforms.
-   Camellia is specified as Cipher Suite in TLS used by Phase 1 S-7
-   (Bi-directional Metadata Delivery Protection) specification and S-5
-   (TV-Anytime Rights Management and Protection Information for
-   Broadcast Applications) specification.  Camellia has been submitted
-   to other several standardization bodies such as ISO (ISO/IEC 18033)
-   and IETF S/MIME Mail Security Working Group [Camellia-CMS].
-
-   Camellia supports 128-bit block size and 128-, 192-, and 256-bit key
-   sizes; i.e., the same interface specifications as the Advanced
-   Encryption Standard (AES) [AES].
-
-   Camellia was jointly developed by NTT and Mitsubishi Electric
-   Corporation in 2000 [CamelliaTech].  It was carefully designed to
-   withstand all known cryptanalytic attacks and even to have a
-   sufficiently large security leeway.  It has been scrutinized by
-   worldwide cryptographic experts.
-
-   Camellia was also designed to be suitable for both software and
-   hardware implementations and to cover all possible encryption
-   applications, from low-cost smart cards to high-speed network
-   systems.  Compared to the AES, Camellia offers at least comparable
-   encryption speed in software and hardware.  In addition, a
-   distinguishing feature is its small hardware design.  Camellia
-   perfectly meets one of the current TLS market requirements, for which
-   low power consumption is mandatory.
-
-   The algorithm specification and object identifiers are described in
-   [Camellia-Desc].  The Camellia homepage,
-   http://info.isl.ntt.co.jp/camellia/, contains a wealth of information
-   about camellia, including detailed specification, security analysis,
-   performance figures, reference implementation, and test vectors.
-
-1.2.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
-   as shown) are to be interpreted as described in [RFC2119].
-
-2.  Proposed Cipher Suites
-
-   The new cipher suites proposed here have the following definitions:
-
-   CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA      = { 0x00,0x41 };
-   CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA   = { 0x00,0x42 };
-   CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA   = { 0x00,0x43 };
-   CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA  = { 0x00,0x44 };
-
-
-
-Moriai, et al.              Standards Track                     [Page 2]
-
-RFC 4132             Camellia Cipher Suites for TLS            July 2005
-
-
-   CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA  = { 0x00,0x45 };
-   CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA  = { 0x00,0x46 };
-
-   CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA      = { 0x00,0x84 };
-   CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA   = { 0x00,0x85 };
-   CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA   = { 0x00,0x86 };
-   CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA  = { 0x00,0x87 };
-   CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA  = { 0x00,0x88 };
-   CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA  = { 0x00,0x89 };
-
-3.  Cipher Suite Definitions
-
-3.1.  Cipher
-
-   All the cipher suites described here use Camellia in cipher block
-   chaining (CBC) mode as a bulk cipher algorithm.  Camellia is a 128-
-   bit block cipher with 128-, 192-, and 256-bit key sizes; i.e., it
-   supports the same block and key sizes as the Advanced Encryption
-   Standard (AES).  However, this document only defines cipher suites
-   for 128- and 256-bit keys as well as AES cipher suites for TLS
-   [AES-TLS].  These cipher suites are efficient and practical enough
-   for most uses, including high-security applications.
-
-                            Key       Expanded    Effective   IV   Block
-   Cipher           Type  Material  Key Material  Key Bits   Size  Size
-
-   CAMELLIA_128_CBC Block   16          16          128       16    16
-   CAMELLIA_256_CBC Block   32          32          256       16    16
-
-3.2.  Hash
-
-   All the cipher suites described here use SHA-1 [SHA-1] in a Hashed
-   Message Authentication Code (HMAC) construction, as described in
-   section 5 of [TLS].
-
-3.3.  Key Exchange
-
-   The cipher suites defined here differ in the type of certificate and
-   key exchange method.  They use the following options:
-
-   Cipher Suite                              Key Exchange Algorithm
-
-   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA         RSA
-   TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA      DH_DSS
-   TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA      DH_RSA
-   TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA     DHE_DSS
-   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA     DHE_RSA
-   TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA     DH_anon
-
-
-
-Moriai, et al.              Standards Track                     [Page 3]
-
-RFC 4132             Camellia Cipher Suites for TLS            July 2005
-
-
-   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA         RSA
-   TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA      DH_DSS
-   TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA      DH_RSA
-   TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA     DHE_DSS
-   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA     DHE_RSA
-   TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA     DH_anon
-
-   For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA,
-   and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS].
-
-4.  Security Considerations
-
-   It is not believed that the new cipher suites are ever less secure
-   than the corresponding older ones.  Camellia is considered secure,
-   and it has withstood extensive cryptanalytic efforts in several open,
-   worldwide cryptographic evaluation projects [CRYPTREC][NESSIE].
-
-   At the time of writing this document, there are no known weak keys
-   for Camellia.
-
-   For other security considerations, please refer to the security
-   considerations of the corresponding older cipher suites described in
-   [TLS] and [AES-TLS].
-
-5.  References
-
-5.1.  Normative References
-
-   [Camellia-Desc] Matsui, M., Nakajima, J., and S. Moriai, "A
-                   Description of the Camellia Encryption Algorithm",
-                   RFC 3713, April 2004.
-
-   [TLS]           Dierks, T. and C. Allen, "The TLS Protocol Version
-                   1.0", RFC 2246, January 1999.
-
-   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
-                   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-5.2.  Informative References
-
-   [CamelliaTech]  Aoki, K., Ichikawa, T., Kanda, M., Matsui, M.,
-                   Moriai, S., Nakajima, J., and Tokita, T., "Camellia:
-                   A 128-Bit Block Cipher Suitable for Multiple
-                   Platforms - Design and Analysis -", In Selected Areas
-                   in Cryptography, 7th Annual International Workshop,
-                   SAC 2000, August 2000, Proceedings, Lecture Notes in
-                   Computer Science 2012, pp.39-56, Springer-Verlag,
-                   2001.
-
-
-
-Moriai, et al.              Standards Track                     [Page 4]
-
-RFC 4132             Camellia Cipher Suites for TLS            July 2005
-
-
-   [Camellia-CMS]  Moriai, S. and A. Kato, "Use of the Camellia
-                   Encryption Algorithm in Cryptographic Message Syntax
-                   (CMS)", RFC 3657, January 2004.
-
-   [AES]           NIST, FIPS PUB 197, "Advanced Encryption Standard
-                   (AES)", November 2001.
-                   http://csrc.nist.gov/publications/fips/fips197/fips-
-                   197.{ps,pdf}.
-
-   [AES-TLS]       Chown, P., "Advanced Encryption Standard (AES)
-                   Ciphersuites for Transport Layer Security (TLS)", RFC
-                   3268, June 2002.
-
-
-   [SHA-1]         FIPS PUB 180-1, "Secure Hash Standard", National
-                   Institute of Standards and Technology, U.S.
-                   Department of Commerce, April 17, 1995.
-
-   [CRYPTREC]      Information-technology Promotion Agency (IPA), Japan,
-                   CRYPTREC,
-                   http://www.ipa.go.jp/security/enc/CRYPTREC/index-
-                   e.html.
-
-   [NESSIE]        The NESSIE project (New European Schemes for
-                   Signatures, Integrity and Encryption),
-                   http://www.cosic.esat.kuleuven.ac.be/nessie/.
-
-   [TV-ANYTIME]    TV-Anytime Forum, http://www.tv-anytime.org/.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moriai, et al.              Standards Track                     [Page 5]
-
-RFC 4132             Camellia Cipher Suites for TLS            July 2005
-
-
-Authors' Addresses
-
-   Shiho Moriai
-   Sony Computer Entertainment Inc.
-
-   Phone: +81-3-6438-7523
-   Fax:   +81-3-6438-8629
-   EMail: shiho@rd.scei.sony.co.jp
-
-
-   Akihiro Kato
-   NTT Software Corporation
-
-   Phone: +81-45-212-7094
-   Fax:   +81-45-212-7506
-   EMail: akato@po.ntts.co.jp
-
-
-   Masayuki Kanda
-   Nippon Telegraph and Telephone Corporation
-
-   Phone: +81-46-859-2437
-   Fax:   +81-46-859-3365
-   EMail: kanda.masayuki@lab.ntt.co.jp
-          camellia@lab.ntt.co.jp (Camellia team)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moriai, et al.              Standards Track                     [Page 6]
-
-RFC 4132             Camellia Cipher Suites for TLS            July 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Moriai, et al.              Standards Track                     [Page 7]
-
diff --git a/doc/protocol/rfc4158.txt b/doc/protocol/rfc4158.txt
deleted file mode 100644
index 52716e1063..0000000000
--- a/doc/protocol/rfc4158.txt
+++ /dev/null
@@ -1,4539 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Cooper
-Request for Comments: 4158                      Orion Security Solutions
-Category: Informational                                     Y. Dzambasow
-                                                          A&N Associates
-                                                                P. Hesse
-                                               Gemini Security Solutions
-                                                               S. Joseph
-                                                   Van Dyke Technologies
-                                                             R. Nicholas
-                                                             BAE Systems
-                                                          September 2005
-
-
-               Internet X.509 Public Key Infrastructure:
-                      Certification Path Building
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document provides guidance and recommendations to developers
-   building X.509 public-key certification paths within their
-   applications.  By following the guidance and recommendations defined
-   in this document, an application developer is more likely to develop
-   a robust X.509 certificate-enabled application that can build valid
-   certification paths across a wide range of PKI environments.
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. Motivation .................................................4
-      1.2. Purpose ....................................................4
-      1.3. Terminology ................................................5
-      1.4. Notation ...................................................8
-      1.5. Overview of PKI Structures .................................8
-           1.5.1. Hierarchical Structures .............................8
-           1.5.2. Mesh Structures ....................................10
-           1.5.3. Bi-Lateral Cross-Certified Structures ..............11
-           1.5.4. Bridge Structures ..................................13
-      1.6. Bridge Structures and Certification Path Processing .......14
-
-
-
-Cooper, et al.               Informational                      [Page 1]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   2. Certification Path Building ....................................15
-      2.1. Introduction to Certification Path Building ...............15
-      2.2. Criteria for Path Building ................................16
-      2.3. Path-Building Algorithms ..................................17
-      2.4. How to Build a Certification Path .........................21
-           2.4.1. Certificate Repetition .............................23
-           2.4.2. Introduction to Path-Building Optimization .........24
-      2.5. Building Certification Paths for Revocation Signer
-           Certificates ..............................................30
-      2.6. Suggested Path-Building Software Components ...............31
-      2.7. Inputs to the Path-Building Module ........................33
-           2.7.1. Required Inputs ....................................33
-           2.7.2. Optional Inputs ....................................34
-   3. Optimizing Path Building .......................................35
-      3.1. Optimized Path Building ...................................35
-      3.2. Sorting vs. Elimination ...................................38
-      3.3. Representing the Decision Tree ............................41
-           3.3.1. Node Representation for CA Entities ................41
-           3.3.2. Using Nodes to Iterate Over All Paths ..............42
-      3.4. Implementing Path-Building Optimization ...................45
-      3.5. Selected Methods for Sorting Certificates .................46
-           3.5.1. basicConstraints Is Present and cA Equals True .....47
-           3.5.2. Recognized Signature Algorithms ....................48
-           3.5.3. keyUsage Is Correct ................................48
-           3.5.4. Time (T) Falls within the Certificate Validity .....48
-           3.5.5. Certificate Was Previously Validated ...............49
-           3.5.6. Previously Verified Signatures .....................49
-           3.5.7. Path Length Constraints ............................50
-           3.5.8. Name Constraints ...................................50
-           3.5.9. Certificate Is Not Revoked .........................51
-           3.5.10. Issuer Found in the Path Cache ....................52
-           3.5.11. Issuer Found in the Application Protocol ..........52
-           3.5.12. Matching Key Identifiers (KIDs) ...................52
-           3.5.13. Policy Processing .................................53
-           3.5.14. Policies Intersect the Sought Policy Set ..........54
-           3.5.15. Endpoint Distinguished Name (DN) Matching .........55
-           3.5.16. Relative Distinguished Name (RDN) Matching ........55
-           3.5.17. Certificates are Retrieved from
-                   cACertificate Directory Attribute .................56
-           3.5.18. Consistent Public Key and Signature Algorithms ....56
-           3.5.19. Similar Issuer and Subject Names ..................57
-           3.5.20. Certificates in the Certification Cache ...........57
-           3.5.21. Current CRL Found in Local Cache ..................58
-      3.6. Certificate Sorting Methods for Revocation Signer
-           Certification Paths .......................................58
-           3.6.1. Identical Trust Anchors ............................58
-           3.6.2. Endpoint Distinguished Name (DN) Matching ..........59
-           3.6.3. Relative Distinguished Name (RDN) Matching .........59
-
-
-
-Cooper, et al.               Informational                      [Page 2]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-           3.6.4. Identical Intermediate Names .......................60
-   4. Forward Policy Chaining ........................................60
-      4.1. Simple Intersection .......................................61
-      4.2. Policy Mapping ............................................62
-      4.3. Assigning Scores for Forward Policy Chaining ..............63
-   5. Avoiding Path-Building Errors ..................................64
-      5.1. Dead Ends .................................................64
-      5.2. Loop Detection ............................................65
-      5.3. Use of Key Identifiers ....................................66
-      5.4. Distinguished Name Encoding ...............................66
-   6. Retrieval Methods ..............................................67
-      6.1. Directories Using LDAP ....................................67
-      6.2. Certificate Store Access via HTTP .........................69
-      6.3. Authority Information Access ..............................69
-      6.4. Subject Information Access ................................70
-      6.5. CRL Distribution Points ...................................70
-      6.6. Data Obtained via Application Protocol ....................71
-      6.7. Proprietary Mechanisms ....................................71
-   7. Improving Retrieval Performance ................................71
-      7.1. Caching ...................................................72
-      7.2. Retrieval Order ...........................................73
-      7.3. Parallel Fetching and Prefetching .........................73
-   8. Security Considerations ........................................74
-      8.1. General Considerations for Building a Certification Path ..74
-      8.2. Specific Considerations for Building Revocation
-           Signer Paths ..............................................75
-   9. Acknowledgements ...............................................78
-   10. Normative References ..........................................78
-   11. Informative References ........................................78
-
-1.  Introduction
-
-   [X.509] public key certificates have become an accepted method for
-   securely binding the identity of an individual or device to a public
-   key, in order to support public key cryptographic operations such as
-   digital signature verification and public key-based encryption.
-   However, prior to using the public key contained in a certificate, an
-   application first has to determine the authenticity of that
-   certificate, and specifically, the validity of all the certificates
-   leading to a trusted public key, called a trust anchor.  Through
-   validating this certification path, the assertion of the binding made
-   between the identity and the public key in each of the certificates
-   can be traced back to a single trust anchor.
-
-   The process by which an application determines this authenticity of a
-   certificate is called certification path processing.  Certification
-   path processing establishes a chain of trust between a trust anchor
-   and a certificate.  This chain of trust is composed of a series of
-
-
-
-Cooper, et al.               Informational                      [Page 3]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   certificates known as a certification path.  A certification path
-   begins with a certificate whose signature can be verified using a
-   trust anchor and ends with the target certificate.  Path processing
-   entails building and validating the certification path to determine
-   whether a target certificate is appropriate for use in a particular
-   application context.  See Section 3.2 of [RFC3280] for more
-   information on certification paths and trust.
-
-1.1.  Motivation
-
-   Many other documents (such as [RFC3280]) cover certification path
-   validation requirements and procedures in detail but do not discuss
-   certification path building because the means used to find the path
-   does not affect its validation.  This document therefore is an effort
-   to provide useful guidance for developers of certification path-
-   building implementations.
-
-   Additionally, the need to develop complex certification paths is
-   increasing.  Many PKIs are now using complex structures (see Section
-   1.5) rather than simple hierarchies.  Additionally, some enterprises
-   are gradually moving away from trust lists filled with many trust
-   anchors, and toward an infrastructure with one trust anchor and many
-   cross-certified relationships.  This document provides helpful
-   information for developing certification paths in these more
-   complicated situations.
-
-1.2.  Purpose
-
-   This document provides information and guidance for certification
-   path building.  There are no requirements or protocol specifications
-   in this document.  This document provides many options for performing
-   certification path building, as opposed to just one particular way.
-   This document draws upon the authors' experiences with existing
-   complex certification paths to offer insights and recommendations to
-   developers who are integrating support for [X.509] certificates into
-   their applications.
-
-   In addition, this document suggests using an effective general
-   approach to path building that involves a depth first tree traversal.
-   While the authors believe this approach offers the balance of
-   simplicity in design with very effective and infrastructure-neutral
-   path-building capabilities, the algorithm is no more than a suggested
-   approach.  Other approaches (e.g., breadth first tree traversals)
-   exist and may be shown to be more effective under certain conditions.
-   Certification path validation is described in detail in both [X.509]
-   and [RFC3280] and is not repeated in this document.
-
-
-
-
-
-Cooper, et al.               Informational                      [Page 4]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   This document does not provide guidance for building the
-   certification path from an end entity certificate to a proxy
-   certificate as described in [RFC3820].
-
-1.3.  Terminology
-
-   Terms used throughout this document will be used in the following
-   ways:
-
-   Building in the Forward direction: The process of building a
-      certification path from the target certificate to a trust anchor.
-      'Forward' is the former name of the crossCertificatePair element
-      'issuedToThisCA'.
-
-   Building in the Reverse direction: The process of building a
-      certification path from a trust anchor to the target certificate.
-      'Reverse' is the former name of the crossCertificatePair element
-      'issuedByThisCA'.
-
-   Certificate:  A digital binding that cannot be counterfeited between
-      a named entity and a public key.
-
-   Certificate Graph:  A graph that represents the entire PKI (or all
-      cross-certified PKIs) in which all named entities are viewed as
-      nodes and all certificates are viewed as arcs between nodes.
-
-   Certificate Processing System:  An application or device that
-      performs the functions of certification path building and
-      certification path validation.
-
-   Certification Authority (CA):  An entity that issues and manages
-      certificates.
-
-   Certification Path:  An ordered list of certificates starting with a
-      certificate signed by a trust anchor and ending with the target
-      certificate.
-
-   Certification Path Building:  The process used to assemble the
-      certification path between the trust anchor and the target
-      certificate.
-
-   Certification Path Validation:  The process that verifies the binding
-      between the subject and the subject-public-key defined in the
-      target certificate, using a trust anchor and set of known
-      constraints.
-
-
-
-
-
-
-Cooper, et al.               Informational                      [Page 5]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Certificate Revocation List (CRL):  A signed, time stamped list
-      identifying a set of certificates that are no longer considered
-      valid by the certificate issuer.
-
-   CRL Signer Certificate: The specific certificate that may be used for
-      verifying the signature on a CRL issued by, or on behalf of, a
-      specific CA.
-
-   Cross-Certificate:  A certificate issued by one CA to another CA for
-      the purpose of establishing a trust relationship between the two
-      CAs.
-
-   Cross-Certification:  The act of issuing cross-certificates.
-
-   Decision Tree:  When the path-building software has multiple
-      certificates to choose from, and must make a decision, the
-      collection of possible choices is called a decision tree.
-
-   Directory:  Generally used to refer an LDAP accessible repository for
-      certificates and PKI information.  The term may also be used
-      generically to refer to any certificate storing repository.
-
-   End Entity:  The holder of a private key and corresponding
-      certificate, whose identity is defined as the Subject of the
-      certificate.  Human end entities are often called "subscribers".
-
-   Is-revocation-signer indicator:  A boolean flag furnished to the
-      path-building software.  If set, this indicates that the target
-      certificate is a Revocation Signer certificate for a specific CA.
-      For example, if building a certification path for an indirect CRL
-      Signer certificate, this flag would be set.
-
-   Local PKI:  The set of PKI components and data (certificates,
-      directories, CRLs, etc.) that are created and used by the
-      certificate using organization.  In general, this concept refers
-      to the components that are in close proximity to the certificate
-      using application.  The assumption is that the local data is more
-      easily accessible and/or inexpensive to retrieve than non-local
-      PKI data.
-
-   Local Realm: See Local PKI.
-
-   Node (in a certificate graph): The collection of certificates having
-      identical subject distinguished names.
-
-   Online Certificate Status Protocol (OCSP): An Internet protocol used
-      by a client to obtain the revocation status of a certificate from
-      a server.
-
-
-
-Cooper, et al.               Informational                      [Page 6]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   OCSP Response Signer Certificate:  The specific certificate that may
-      be used for verifying the signature on an OCSP response.  This
-      response may be provided by the CA, on behalf of the CA, or by a
-      different signer as determined by the Relying Party's local
-      policy.
-
-   Public Key Infrastructure (PKI):  The set of hardware, software,
-      personnel, policy, and procedures used by a CA to issue and manage
-      certificates.
-
-   Relying Party (RP):  An application or entity that processes
-      certificates for the purpose of 1) verifying a digital signature,
-      2) authenticating another entity, or 3) establishing confidential
-      communications.
-
-   Revocation Signer Certificate:  Refers collectively to either a CRL
-      Signer Certificate or OCSP Response Signer Certificate.
-
-   Target Certificate:  The certificate that is to be validated by a
-      Relying Party.  It is the "Certificate targeted for validation".
-      Although frequently this is the End Entity or a leaf node in the
-      PKI structure, this could also be a CA certificate if a CA
-      certificate is being validated. (e.g., This could be for the
-      purpose of building and validating a certification path for the
-      signer of a CRL.)
-
-   Trust (of public keys): In the scope of this document, a public key
-      is considered trustworthy if the certificate containing the public
-      key can be validated according to the procedures in [RFC3280].
-
-   Trust List: A list of trust anchors.
-
-   Trust Anchor: The combination of a trusted public key and the name of
-      the entity to which the corresponding private key belongs.
-
-   Trust Anchor Certificate:  A self-signed certificate for a trust
-      anchor that is used in certification path processing.
-
-   User:  An individual that is using a certificate processing system.
-      This document refers to some cases in which users may or may not
-      be prompted with information or requests, depending upon the
-      implementation of the certificate processing system.
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                      [Page 7]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-1.4.  Notation
-
-   This document makes use of a few common notations that are used in
-   the diagrams and examples.
-
-   The first is the arrow symbol (->) which represents the issuance of a
-   certificate from one entity to another.  For example, if entity H
-   were to issue a certificate to entity K, this is denoted as H->K.
-
-   Sometimes it is necessary to specify the subject and issuer of a
-   given certificate.  If entity H were to issue a certificate to entity
-   K this can be denoted as K(H).
-
-   These notations can be combined to denote complicated certification
-   paths such as C(D)->B(C)->A(B).
-
-1.5.  Overview of PKI Structures
-
-   When verifying [X.509] public key certificates, often the application
-   performing the verification has no knowledge of the underlying Public
-   Key Infrastructure (PKI) that issued the certificate.  PKI structures
-   can range from very simple, hierarchical structures to complex
-   structures such as mesh architectures involving multiple bridges (see
-   Section 1.5.4).  These structures define the types of certification
-   paths that might be built and validated by an application [MINHPKIS].
-   This section describes four common PKI structures.
-
-1.5.1.  Hierarchical Structures
-
-   A hierarchical PKI, depicted in Figure 1, is one in which all of the
-   end entities and relying parties use a single "Root CA" as their
-   trust anchor.  If the hierarchy has multiple levels, the Root CA
-   certifies the public keys of intermediate CAs (also known as
-   subordinate CAs).  These CAs then certify end entities'
-   (subscribers') public keys or may, in a large PKI, certify other CAs.
-   In this architecture, certificates are issued in only one direction,
-   and a CA never certifies another CA "superior" to itself.  Typically,
-   only one superior CA certifies each CA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                      [Page 8]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-                               +---------+
-                           +---| Root CA |---+
-                           |   +---------+   |
-                           |                 |
-                           |                 |
-                           v                 v
-                        +----+            +----+
-                  +-----| CA |      +-----| CA |------+
-                  |     +----+      |     +----+      |
-                  |                 |                 |
-                  v                 v                 v
-               +----+            +----+            +----+
-            +--| CA |-----+      | CA |-+      +---| CA |---+
-            |  +----+     |      +----+ |      |   +----+   |
-            |     |       |       |     |      |    |       |
-            |     |       |       |     |      |    |       |
-            v     v       v       v     v      v    v       v
-         +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
-         | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
-         +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
-
-                    Figure 1 - Sample Hierarchical PKI
-
-   Certification path building in a hierarchical PKI is a
-   straightforward process that simply requires the relying party to
-   successively retrieve issuer certificates until a certificate that
-   was issued by the trust anchor (the "Root CA" in Figure 1) is
-   located.
-
-   A widely used variation on the single-rooted hierarchical PKI is the
-   inclusion of multiple CAs as trust anchors.  (See Figure 2.)  Here,
-   end entity certificates are validated using the same approach as with
-   any hierarchical PKI.  The difference is that a certificate will be
-   accepted if it can be verified back to any of the set of trust
-   anchors.  Popular web browsers use this approach, and are shipped
-   with trust lists containing dozens to more than one hundred CAs.
-   While this approach simplifies the implementation of a limited form
-   of certificate verification, it also may introduce certain security
-   vulnerabilities.  For example, the user may have little or no idea of
-   the policies or operating practices of the various trust anchors, and
-   may not be aware of which root was used to verify a given
-   certificate.  Additionally, the compromise of any trusted CA private
-   key or the insertion of a rogue CA certificate to the trust list may
-   compromise the entire system.  Conversely, if the trust list is
-   properly managed and kept to a reasonable size, it can be an
-   efficient solution to building and validating certification paths.
-
-
-
-
-
-Cooper, et al.               Informational                      [Page 9]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-            +-------------------------------------------------------+
-            |                      Trust List                       |
-            |                                                       |
-            |     +---------+     +---------+      +---------+      |
-            |  +--| Root CA |     | Root CA |      | Root CA |      |
-            |  |  +---------+     +---------+      +---------+      |
-            |  |      |                |                 |          |
-            +--|------|----------------|---------------- |----------+
-               |      |                |                 |
-               |      |                |                 |
-               |      |                v                 |
-               |      |             +----+               |
-               |      |        +----| CA |---+           |
-               |      |        |    +----+   |           |
-               |      |        |             |           |
-               |      |        v             v           v
-               |      |     +----+        +----+      +----+
-               |      |     | CA |---+    | CA |-+    | CA |---+
-               |      |     +----+   |    +----+ |    +----+   |
-               |      |       |      |    |      |       |     |
-               |      |       |      |    |      |       |     |
-               v      v       v      v    v      v       v     v
-            +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
-            | EE | | EE | | EE | | EE | | EE | | EE | | EE | | EE |
-            +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
-
-                 Figure 2 - Multi-Rooted Hierarchical PKI
-
-1.5.2.  Mesh Structures
-
-   In a typical mesh style PKI (depicted in Figure 3), each end entity
-   trusts the CA that issued their own certificate(s).  Thus, there is
-   no 'Root CA' for the entire PKI.  The CAs in this environment have
-   peer relationships; they are neither superior nor subordinate to one
-   another.  In a mesh, CAs in the PKI cross-certify.  That is, each CA
-   issues a certificate to, and is issued a certificate by, peer CAs in
-   the PKI.  The figure depicts a mesh PKI that is fully cross-certified
-   (sometimes called a full mesh).  However, it is possible to architect
-   and deploy a mesh PKI with a mixture of uni-directional and bi-
-   directional cross-certifications (called a partial mesh).  Partial
-   meshes may also include CAs that are not cross-certified with other
-   CAs in the mesh.
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 10]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-                          +---------------------------------+
-                          |                                 |
-              +-----------+----------------------+          |
-              |           v                      v          |
-              |       +-------+               +------+      |
-              |  +--->| CA B  |<------------->| CA C |<--+  |
-              |  |    +-------+               +------+   |  |
-              |  |      |    ^                  ^  |     |  |
-              |  |      v    |                  |  |     |  |
-              |  |   +----+  |                  |  |     |  |
-              |  |   | EE |  +----+    +--------+  v     |  |
-              |  |   +----+       |    |         +----+  |  |
-              |  |                |    |         | EE |  |  |
-              v  v                v    v         +----+  v  v
-            +------+             +------+             +------+
-            | CA E |<----------->| CA A |<----------->| CA D |
-            +------+             +------+             +------+
-             |  ^  ^                                    ^ ^  |
-             |  |  |                                    | |  |
-             v  |  +------------------------------------+ |  v
-         +----+ |                                         | +----+
-         | EE | |                +------+                 | | EE |
-         +----+ +----------------| CA F |-----------------+ +----+
-                                 +------+
-
-                           Figure 3 - Mesh PKI
-
-   Certification path building in a mesh PKI is more complex than in a
-   hierarchical PKI due to the likely existence of multiple paths
-   between a relying party's trust anchor and the certificate to be
-   verified.  These multiple paths increase the potential for creating
-   "loops", "dead ends", or invalid paths while building the
-   certification path between a trust anchor and a target certificate.
-   In addition, in cases where no valid path exists, the total number of
-   paths traversed by the path-building software in order to conclude
-   "no path exists" can grow exceedingly large.  For example, if
-   ignoring everything except the structure of the graph, the Mesh PKI
-   figure above has 22 non-self issued CA certificates and a total of
-   5,092,429 certification paths between CA F and the EE issued by CA D
-   without repeating any certificates.
-
-1.5.3.  Bi-Lateral Cross-Certified Structures
-
-   PKIs can be connected via cross-certification to enable the relying
-   parties of each to verify and accept certificates issued by the other
-   PKI.  If the PKIs are hierarchical, cross-certification will
-   typically be accomplished by each Root CA issuing a certificate for
-   the other PKI's Root CA.  This results in a slightly more complex,
-
-
-
-Cooper, et al.               Informational                     [Page 11]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   but still essentially hierarchical environment.  If the PKIs are mesh
-   style, then a CA within each PKI is selected, more or less
-   arbitrarily, to establish the cross-certification, effectively
-   creating a larger mesh PKI.  Figure 4 depicts a hybrid situation
-   resulting from a hierarchical PKI cross-certifying with a mesh PKI.
-
-                       PKI 1 and 2 cross-certificates
-                      +-------------------------------+
-                      |                               |
-                      |                               v
-                      |                           +---------+
-                      |                      +----| Root CA |---+
-                      |                      |    +---------+   |
-                      |                      |       PKI 1      |
-                      |                      v                  v
-                      |                     +------+         +------+
-                      v PKI 2             +-|  CA  |-+       |  CA  |
-                     +------+             | +------+ |       +------+
-            +------->|  CA  |<-----+      |     |    |         |   |
-            |        +------+      |      |     |    |         |   |
-            |         |    |       |      v     v    v         v   v
-            |         |    |       |  +----+ +----+ +----+ +----+ +----+
-            |         v    v       |  | EE | | EE | | EE | | EE | | EE |
-            |      +----+ +----+   |  +----+ +----+ +----+ +----+ +----+
-            |      | EE | | EE |   |
-            |      +----+ +----+   |
-            v                      v
-         +------+                +------+
-         |  CA  |<-------------->|  CA  |------+
-         +------+                +------+      |
-          |    |                  |    |       |
-          |    |                  |    |       |
-          v    v                  v    v       v
-      +----+ +----+            +----+ +----+ +----+
-      | EE | | EE |            | EE | | EE | | EE |
-      +----+ +----+            +----+ +----+ +----+
-
-                          Figure 4 - Hybrid PKI
-
-   In current implementations, this situation creates a concern that the
-   applications used under the hierarchical PKIs will not have path
-   building capabilities robust enough to handle this more complex
-   certificate graph.  As the number of cross-certified PKIs grows, the
-   number of the relationships between them grows exponentially.  Two
-   principal concerns about cross-certification are the creation of
-   unintended certification paths through transitive trust, and the
-   dilution of assurance when a high-assurance PKI with restrictive
-   operating policies is cross-certified with a PKI with less
-
-
-
-Cooper, et al.               Informational                     [Page 12]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   restrictive policies.  (Proper name constraints and certificate
-   policies processing can help mitigate the problem of assurance
-   dilution.)
-
-1.5.4.  Bridge Structures
-
-   Another approach to the interconnection of PKIs is the use of a
-   "bridge" certification authority (BCA).  A BCA is a nexus to
-   establish trust paths among multiple PKIs.  The BCA cross-certifies
-   with one CA in each participating PKI.  Each PKI only cross-certifies
-   with one other CA (i.e., the BCA), and the BCA cross-certifies only
-   once with each participating PKI.  As a result, the number of cross
-   certified relationships in the bridged environment grows linearly
-   with the number of PKIs whereas the number of cross-certified
-   relationships in mesh architectures grows exponentially.  However,
-   when connecting PKIs in this way, the number and variety of PKIs
-   involved results in a non-hierarchical environment, such as the one
-   as depicted in Figure 5.  (Note: as discussed in Section 2.3, non-
-   hierarchical PKIs can be considered hierarchical, depending upon
-   perspective.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 13]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-                      PKI 1 cross-certified with Bridge
-                      +-------------------------------+
-                      |                               |
-                      v                               v
-                +-----------+                    +---------+
-                | Bridge CA |                +---| Root CA |-----+
-                +-----------+                |   +---------+     |
-                      ^                      |      PKI 1        |
-           PKI 2 cross|cert with Bridge      v                   v
-                      |                     +------+         +------+
-                      v PKI 2             +-|  CA  |-+       |  CA  |
-                     +------+             | +------+ |       +------+
-            +------->|  CA  |<-----+      |     |    |         |   |
-            |        +------+      |      |     |    |         |   |
-            |         |    |       |      v     v    v         v   v
-            |         |    |       |  +----+ +----+ +----+ +----+ +----+
-            |         v    v       |  | EE | | EE | | EE | | EE | | EE |
-            |      +----+ +----+   |  +----+ +----+ +----+ +----+ +----+
-            |      | EE | | EE |   |
-            |      +----+ +----+   |
-            v                      v
-         +------+                +------+
-         |  CA  |<-------------->|  CA  |------+
-         +------+                +------+      |
-          |    |                  |    |       |
-          |    |                  |    |       |
-          v    v                  v    v       v
-      +----+ +----+            +----+ +----+ +----+
-      | EE | | EE |            | EE | | EE | | EE |
-      +----+ +----+            +----+ +----+ +----+
-
-             Figure 5 - Cross-Certification with a Bridge CA
-
-1.6.  Bridge Structures and Certification Path Processing
-
-   Developers building certificate-enabled applications intended for
-   widespread use throughout various sectors are encouraged to consider
-   supporting a Bridge PKI structure because implementation of
-   certification path processing functions to support a Bridge PKI
-   structure requires support of all the PKI structures (e.g.,
-   hierarchical, mesh, hybrid) which the Bridge may connect.  An
-   application that can successfully build valid certification paths in
-   all Bridge PKIs will therefore have implemented all of the processing
-   logic required to support the less complicated PKI structures.  Thus,
-   if an application fully supports the Bridge PKI structure, it can be
-   deployed in any standards-compliant PKI environment and will perform
-   the required certification path processing properly.
-
-
-
-
-Cooper, et al.               Informational                     [Page 14]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-2.  Certification Path Building
-
-   Certification path building is the process by which the certificate
-   processing system obtains the certification path between a trust
-   anchor and the target certificate.  Different implementations can
-   build the certification path in different ways; therefore, it is not
-   the intent of this document to recommend a single "best" way to
-   perform this function.  Rather, guidance is provided on the technical
-   issues that surround the path-building process, and on the
-   capabilities path-building implementations need in order to build
-   certification paths successfully, irrespective of PKI structures.
-
-2.1.  Introduction to Certification Path Building
-
-   A certification path is an ordered list of certificates starting with
-   a certificate that can be validated by one of the relying party's
-   trust anchors, and ending with the certificate to be validated.  (The
-   certificate to be validated is referred to as the "target
-   certificate" throughout this document.)  Though not required, as a
-   matter of convenience these trust anchors are typically stored in
-   trust anchor certificates.  The intermediate certificates that
-   comprise the certification path may be retrieved by any means
-   available to the validating application.  These sources may include
-   LDAP, HTTP, SQL, a local cache or certificate store, or as part of
-   the security protocol itself as is common practice with signed S/MIME
-   messages and SSL/TLS sessions.
-
-   Figure 6 shows an example of a certification path.  In this figure,
-   the horizontal arrows represent certificates, and the notation B(A)
-   signifies a certificate issued to B, signed by A.
-
-      +---------+      +-----+     +-----+     +-----+     +--------+
-      |  Trust  |----->| CA  |---->| CA  |---->| CA  |---->| Target |
-      | Anchor  |  :   |  A  |  :  |  B  |  :  |  C  |  :  |   EE   |
-      +---------+  :   +-----+  :  +-----+  :  +-----+  :  +--------+
-                   :            :           :           :
-                   :            :           :           :
-                 Cert 1       Cert 2      Cert 3      Cert 4
-            A(Trust Anchor)    B(A)        C(B)      Target(C)
-
-                  Figure 6 - Example Certification Path
-
-   Unlike certification path validation, certification path building is
-   not addressed by the standards that define the semantics and
-   structure of a PKI.  This is because the validation of a
-   certification path is unaffected by the method in which the
-   certification path was built.  However, the ability to build a valid
-   certification path is of paramount importance for applications that
-
-
-
-Cooper, et al.               Informational                     [Page 15]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   rely on a PKI.  Without valid certification paths, certificates
-   cannot be validated according to [RFC3280] and therefore cannot be
-   trusted.  Thus, the ability to build a path is every bit as important
-   as the ability to validate it properly.
-
-   There are many issues that can complicate the path-building process.
-   For example, building a path through a cross-certified environment
-   could require the path-building module to traverse multiple PKI
-   domains spanning multiple directories, using multiple algorithms, and
-   employing varying key lengths.  A path-building client may also need
-   to manage a number of trust anchors, partially populated directory
-   entries (e.g., missing issuedToThisCA entries in the
-   crossCertificatePair attribute), parsing of certain certificate
-   extensions (e.g., authorityInformationAccess) and directory
-   attributes (e.g., crossCertificatePair), and error handling such as
-   loop detection.
-
-   In addition, a developer has to decide whether to build paths from a
-   trust anchor (the reverse direction) to the target certificate or
-   from the target certificate (the forward direction) to a trust
-   anchor.  Some implementations may even decide to use both.  The
-   choice a developer makes should be dependent on the environment and
-   the underlying PKI for that environment.  More information on making
-   this choice can be found in Section 2.3.
-
-2.2.  Criteria for Path Building
-
-   From this point forward, this document will be discussing specific
-   algorithms and mechanisms to assist developers of certification
-   path-building implementations.  To provide justification for these
-   mechanisms, it is important to denote what the authors considered the
-   criteria for a path-building implementation.
-
-   Criterion 1: The implementation is able to find all possible paths,
-   excepting paths containing repeated subject name/public key pairs.
-   This means that all potentially valid certification paths between the
-   trust anchor and the target certificate which may be valid paths can
-   be built by the algorithm.  As discussed in Section 2.4.2, we
-   recommend that subject names and public key pairs are not repeated in
-   paths.
-
-   Criterion 2: The implementation is as efficient as possible.  An
-   efficient certification path-building implementation is defined to be
-   one that builds paths that are more likely to validate following
-   [RFC3280], before building paths that are not likely to validate,
-   with the understanding that there is no way to account for all
-   possible configurations and infrastructures.  This criterion is
-   intended to ensure implementations that can produce useful error
-
-
-
-Cooper, et al.               Informational                     [Page 16]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   information.  If a particular path is entirely valid except for a
-   single expired certificate, this is most likely the 'right' path.  If
-   other paths are developed that are invalid for multiple obscure
-   reasons, this provides little useful information.
-
-   The algorithms and mechanisms discussed henceforth are chosen because
-   the authors consider them to be good methods for meeting the above
-   criteria.
-
-2.3.  Path-Building Algorithms
-
-   It is intuitive for people familiar with the Bridge CA concept or
-   mesh type PKIs to view path building as traversing a complex graph.
-   However, from the simplest viewpoint, writing a path-building module
-   can be nothing more than traversal of a spanning tree, even in a very
-   complex cross-certified environment.  Complex environments as well as
-   hierarchical PKIs can be represented as trees because certificates
-   are not permitted to repeat in a path.  If certificates could be
-   repeated, loops can be formed such that the number of paths and
-   number of certificates in a path both increase without bound (e.g., A
-   issues to B, B issues to C, and C issues to A).  Figure 7 below
-   illustrates this concept from the trust anchor's perspective.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 17]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-            +---------+                        +---------+
-            |  Trust  |                        |  Trust  |
-            | Anchor  |                        |  Anchor |
-            +---------+                        +---------+
-             |       |                         |         |
-             v       v                         v         v
-          +---+    +---+                     +---+      +---+
-          | A |<-->| C |                  +--| A |      | C |--+
-          +---+    +---+                  |  +---+      +---+  |
-           |         |                    |     |       |      |
-           |  +---+  |                    v     v       v      v
-           +->| B |<-+                  +---+  +---+  +---+  +---+
-              +---+                     | B |  | C |  | A |  | B |
-                |                       +---+  +---+  +---+  +---+
-                v                         |      |      |       |
-              +----+                      v      v      v       v
-              | EE |                  +----+   +---+  +---+  +----+
-              +----+                  | EE |   | B |  | B |  | EE |
-                                      +----+   +---+  +---+  +----+
-         A certificate graph with               |        |
-         bi-directional cross-cert.             v        v
-         between CAs A and C.                 +----+  +----+
-                                              | EE |  | EE |
-                                              +----+  +----+
-
-                                         The same certificate graph
-                                         rendered as a tree - the
-                                         way path-building software
-                                         could see it.
-
-     Figure 7 - Simple Certificate Graph - From Anchor Tree Depiction
-
-   When viewed from this perspective, all PKIs look like hierarchies
-   emanating from the trust anchor.  An infrastructure can be depicted
-   in this way regardless of its complexity.  In Figure 8, the same
-   graph is depicted from the end entity (EE) (the target certificate in
-   this example).  It would appear this way if building in the forward
-   (from EE or from target) direction.  In this example, without knowing
-   any particulars of the certificates, it appears at first that
-   building from EE has a smaller decision tree than building from the
-   trust anchor.  While it is true that there are fewer nodes in the
-   tree, it is not necessarily more efficient in this example.
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 18]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-                      +---------+         +---------+
-                      |  Trust  |         |  Trust  |
-                      | Anchor  |         |  Anchor |
-                      +---------+         +---------+
-                           ^                   ^
-                           |                   |
-                           |                   |
-                         +---+               +---+
-                         | A |               | C |
-                         +---+               +---+
-            +---------+    ^                   ^      +---------+
-            |  Trust  |    |                   |      |  Trust  |
-            | Anchor  |    |                   |      |  Anchor |
-            +---------+    |                   |      +---------+
-                 ^         |                   |           ^
-                 |       +---+               +---+         |
-                 +-------| C |               | A |---------+
-                         +---+               +---+
-                          ^                    ^
-                          |                    |
-                          |         +---+      |
-                          +---------| B |------+
-                                    +---+
-                                      ^
-                                      |
-                                      |
-                                   +----+
-                                   | EE |
-                                   +----+
-
-                   The same certificate graph rendered
-                    as a tree but from the end entity
-                      rather than the trust anchor.
-
-     Figure 8 - Certificate Graph - From Target Certificate Depiction
-
-   Suppose a path-building algorithm performed no optimizations.  That
-   is, the algorithm is only capable of detecting that the current
-   certificate in the tree was issued by the trust anchor, or that it
-   issued the target certificate (EE).  From the tree above, building
-   from the target certificate will require going through two
-   intermediate certificates before encountering a certificate issued by
-   the trust anchor 100% of the time (e.g., EE chains to B, which then
-   chains to C, which is issued by the Trust Anchor).  The path-building
-   module would not chain C to A because it can recognize that C has a
-   certificate issued by the Trust Anchor (TA).
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 19]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   On the other hand, in the first tree (Figure 7: from anchor
-   depiction), there is a 50% probability of building a path longer than
-   needed (e.g., TA to A to C to B to EE rather than the shorter TA to A
-   to B to EE).  However, even given our simplistic example, the path-
-   building software, when at A, could be designed to recognize that B's
-   subject distinguished name (DN) matches the issuer DN of the EE.
-   Given this one optimization, the builder could prefer B to C.  (B's
-   subject DN matches that of the EE's issuer whereas C's subject DN
-   does not.)  So, for this example, assuming the issuedByThisCA
-   (reverse) and issuedToThisCA (forward) elements were fully populated
-   in the directory and our path-building module implemented the
-   aforementioned DN matching optimization method, path building from
-   either the trust anchor or the target certificate could be made
-   roughly equivalent.  A list of possible optimization methods is
-   provided later in this document.
-
-   A more complicated example is created when the path-building software
-   encounters a situation when there are multiple certificates from
-   which to choose while building a path.  We refer to this as a large
-   decision tree, or a situation with high fan-out.  This might occur if
-   an implementation has multiple trust anchors to choose from, and is
-   building in the reverse (from trust anchor) direction.  Or, it may
-   occur in either direction if a Bridge CA is encountered.  Large
-   decision trees are the enemy of efficient path-building software.  To
-   combat this problem, implementations should make careful decisions
-   about the path-building direction, and should utilize optimizations
-   such as those discussed in Section 3.1 when confronted with a large
-   decision tree.
-
-   Irrespective of the path-building approach for any path-building
-   algorithm, cases can be constructed that make the algorithm perform
-   poorly.  The following questions should help a developer decide from
-   which direction to build certification paths for their application:
-
-   1) What is required to accommodate the local PKI environment and the
-      PKI environments with which interoperability will be required?
-
-      a. If using a directory, is the directory [RFC2587] compliant
-         (specifically, are the issuedToThisCA [forward] cross-
-         certificates and/or the cACertificate attributes fully
-         populated in the directory)?  If yes, you are able to build in
-         the forward direction.
-
-      b. If using a directory, does the directory contain all the
-         issuedByThisCA (reverse) cross-certificates in the
-         crossCertificatePair attribute, or, alternately, are all
-         certificates issued from each CA available via some other
-         means?  If yes, it is possible to build in the reverse
-
-
-
-Cooper, et al.               Informational                     [Page 20]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-         direction.  Note: [RFC2587] does not require the issuedByThisCA
-         (reverse) cross-certificates to be populated; if they are
-         absent it will not be possible to build solely in the reverse
-         direction.
-
-      c. Are all issuer certificates available via some means other than
-         a directory (e.g., the authorityInformationAccess extension is
-         present and populated in all certificates)?  If yes, you are
-         able to build in the forward direction.
-
-   2) How many trust anchors will the path-building and validation
-      software be using?
-
-      a. Are there (or will there be) multiple trust anchors in the
-         local PKI?  If yes, forward path building may offer better
-         performance.
-
-      b. Will the path-building and validation software need to place
-         trust in trust anchors from PKIs that do not populate reverse
-         cross-certificates for all intermediate CAs?  If no, and the
-         local PKI populates reverse cross-certificates, reverse path
-         building is an option.
-
-2.4.  How to Build a Certification Path
-
-   As was discussed in the prior section, path building is essentially a
-   tree traversal.  It was easy to see how this is true in a simple
-   example, but how about a more complicated one? Before taking a look
-   at more a complicated scenario, it is worthwhile to address loops and
-   what constitutes a loop in a certification path.  [X.509] specifies
-   that the same certificate may not repeat in a path.  In a strict
-   sense, this works well as it is not possible to create an endless
-   loop without repeating one or more certificates in the path.
-   However, this requirement fails to adequately address Bridged PKI
-   environments.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 21]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-            +---+    +---+
-            | F |--->| H |
-            +---+    +---+
-             ^ ^       ^
-             |  \       \
-             |   \       \
-             |    v       v
-             |  +---+    +---+
-             |  | G |--->| I |
-             |  +---+    +---+
-             |   ^
-             |  /
-             | /
-         +------+       +-----------+        +------+   +---+   +---+
-         | TA W |<----->| Bridge CA |<------>| TA X |-->| L |-->| M |
-         +------+       +-----------+        +------+   +---+   +---+
-                           ^      ^               \        \
-                          /        \               \        \
-                         /          \               \        \
-                        v            v               v        v
-                  +------+         +------+        +---+    +---+
-                  | TA Y |         | TA Z |        | J |    | N |
-                  +------+         +------+        +---+    +---+
-                   /   \              / \            |        |
-                  /     \            /   \           |        |
-                 /       \          /     \          v        v
-                v         v        v       v       +---+    +----+
-              +---+     +---+    +---+   +---+     | K |    | EE |
-              | A |<--->| C |    | O |   | P |     +---+    +----+
-              +---+     +---+    +---+   +---+
-                 \         /      /  \       \
-                  \       /      /    \       \
-                   \     /      v      v       v
-                    v   v    +---+    +---+   +---+
-                    +---+    | Q |    | R |   | S |
-                    | B |    +---+    +---+   +---+
-                    +---+               |
-                      /\                |
-                     /  \               |
-                    v    v              v
-                 +---+  +---+         +---+
-                 | E |  | D |         | T |
-                 +---+  +---+         +---+
-
-                       Figure 9 - Four Bridged PKIs
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 22]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Figure 9 depicts four root certification authorities cross-certified
-   with a Bridge CA (BCA).  While multiple trust anchors are shown in
-   the Figure, our examples all consider TA Z as the trust anchor.  The
-   other trust anchors serve different relying parties.  By building
-   certification paths through the BCA, trust can be extended across the
-   four infrastructures.  In Figure 9, the BCA has four certificates
-   issued to it; one issued from each of the trust anchors in the graph.
-   If stored in the BCA directory system, the four certificates issued
-   to the BCA would be stored in the issuedToThisCA (forward) entry of
-   four different crossCertificatePair structures.  The BCA also has
-   issued four certificates, one to each of the trust anchors.  If
-   stored in the BCA directory system, those certificates would be
-   stored in the issuedByThisCA (reverse) entry of the same four
-   crossCertificatePair structures.  (Note that the cross-certificates
-   are stored as matched pairs in the crossCertificatePair attribute.
-   For example, a crossCertificatePair structure might contain both A(B)
-   and B(A), but not contain A(C) and B(A).)  The four
-   crossCertificatePair structures would then be stored in the BCA's
-   directory entry in the crossCertificatePair attribute.
-
-2.4.1.  Certificate Repetition
-
-   [X.509] requires that certificates are not repeated when building
-   paths.  For instance, from the figure above, do not build the path TA
-   Z->BCA->Y->A->C->A->C->B->D.  Not only is the repetition unnecessary
-   to build the path from Z to D, but it also requires the reuse of a
-   certificate (the one issued from C to A), which makes the path non-
-   compliant with [X.509].
-
-   What about the following path from TA Z to EE?
-
-               TA Z->BCA->Y->BCA->W->BCA->X->L->N->EE
-
-   Unlike the first example, this path does not require a developer to
-   repeat any certificates; therefore, it is compliant with [X.509].
-   Each of the BCA certificates is issued from a different source and is
-   therefore a different certificate.  Suppose now that the bottom left
-   PKI (in Figure 9) had double arrows between Y and C, as well as
-   between Y and A.  The following path could then be built:
-
-               TA Z->BCA->Y->A->C->Y->BCA->W->BCA->X->L->N->EE
-
-   A path such as this could become arbitrarily complex and traverse
-   every cross-certified CA in every PKI in a cross-certified
-   environment while still remaining compliant with [X.509].  As a
-   practical matter, the path above is not something an application
-   would typically want or need to build for a variety of reasons:
-
-
-
-
-Cooper, et al.               Informational                     [Page 23]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-      - First, certification paths like the example above are generally
-        not intended by the PKI designers and should not be necessary in
-        order to validate any given certificate.  If a convoluted path
-        such as the example above is required (there is no corresponding
-        simple path) in order to validate a given certificate, this is
-        most likely indicative of a flaw in the PKI design.
-
-      - Second, the longer a path becomes, the greater the potential
-        dilution of trust in the certification path.  That is, with each
-        successive link in the infrastructure (i.e., certification by
-        CAs and cross-certification between CAs) some amount of
-        assurance may be considered lost.
-
-      - Third, the longer and more complicated a path, the less likely
-        it is to validate because of basic constraints, policies or
-        policy constraints, name constraints, CRL availability, or even
-        revocation.
-
-      - Lastly, and certainly not least important from a developer's or
-        user's perspective, is performance.  Allowing paths like the one
-        above dramatically increases the number of possible paths for
-        every certificate in a mesh or cross-certified environment.
-        Every path built may require one or more of the following:
-        validation of certificate properties, CPU intensive signature
-        validations, CRL retrievals, increased network load, and local
-        memory caching.  Eliminating the superfluous paths can greatly
-        improve performance, especially in the case where no path
-        exists.
-
-   There is a special case involving certificates with the same
-   distinguished names but differing encodings required by [RFC3280].
-   This case should not be considered a repeated certificate.  See
-   Section 5.4 for more information.
-
-2.4.2.  Introduction to Path-Building Optimization
-
-   How can these superfluous paths be eliminated?  Rather than only
-   disallowing identical certificates from repeating, it is recommended
-   that a developer disallow the same public key and subject name pair
-   from being repeated.  For maximum flexibility, the subject name
-   should collectively include any subject alternative names.  Using
-   this approach, all of the intended and needed paths should be
-   available, and the excess and diluted paths should be eliminated.
-   For example, using this approach, only one path exists from the TA Z
-   to EE in the diagram above: TA Z->BCA->X->L->N->EE.
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 24]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Given the simplifying rule of not repeating pairs of subject names
-   (including subject alternative names) and public keys, and only using
-   certificates found in the cACertificate and forward (issuedToThisCA)
-   element of the crossCertificatePair attributes, Figure 10 depicts the
-   forward path-building decision tree from the EE to all reachable
-   nodes in the graph.  This is the ideal graph for a path builder
-   attempting to build a path from TA Z to EE.
-
-        +------+       +-----------+        +------+   +---+
-        | TA W |<------| Bridge CA |<-------| TA X |<--| L |
-        +------+       +-----------+        +------+   +---+
-                          /     \                        ^
-                         /       \                        \
-                        /         \                        \
-                       v           v                        \
-                 +------+         +------+                 +---+
-                 | TA Y |         | TA Z |                 | N |
-                 +------+         +------+                 +---+
-                                                             ^
-                                                              \
-                                                               \
-                                                             +----+
-                                                             | EE |
-                                                             +----+
-
-             Figure 10 - Forward (From Entity) Decision Tree
-
-   It is not possible to build forward direction paths into the
-   infrastructures behind CAs W, Y, and Z, because W, Y, and Z have not
-   been issued certificates by their subordinate CAs.  (The subordinate
-   CAs are F and G, A and C, and O and P, respectively.)  If simplicity
-   and speed are desirable, the graph in Figure 10 is a very appealing
-   way to structure the path-building algorithm.  Finding a path from
-   the EE to one of the four trust anchors is reasonably simple.
-   Alternately, a developer could choose to build in the opposite
-   direction, using the reverse cross-certificates from any one of the
-   four trust anchors around the BCA.  The graph in Figure 11 depicts
-   all possible paths as a tree emanating from TA Z.  (Note: it is not
-   recommended that implementations attempt to determine all possible
-   paths, this would require retrieval and storage of all PKI data
-   including certificates and CRLs!  This example is provided to
-   demonstrate the complexity which might be encountered.)
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 25]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-     +---+    +---+
-     | I |--->| H |
-     +---+    +---+
-       ^
-       |      +---+    +---+
-       |      | H |--->| I |
-       |      +---+    +---+
-     +---+     ^
-     | G |    /      +---+    +---+    +---+
-     +---+   /       | F |--->| H |--->| I |
-       ^    /        +---+    +---+    +---+
-        \  /          ^
-         \/          /
-        +---+    +---+    +---+    +---+                +---+
-        | F |    | G |--->| I |--->| H |                | M |
-        +---+    +---+    +---+    +---+                +---+
-          ^      ^                                        ^
-          |     /                                         |
-        +------+       +-----------+         +------+   +---+
-        | TA W |<------| Bridge CA |-------->| TA X |-->| L |
-        +------+       +-----------+         +------+   +---+
-                        /          ^              \         \
-                       v            \              v         v
-                 +------+            +------+     +---+     +---+
-                 | TA Y |            | TA Z |     | J |     | N |
-                 +------+            +------+     +---+     +---+
-                /       \              /     \        \       \
-               v         v            v       v        v       v
-            +---+      +---+        +---+   +---+    +---+  +----+
-            | A |      | C |        | O |   | P |    | K |  | EE |
-            +---+      +---+        +---+   +---+    +---+  +----+
-            /   \       /   \       /   \        \
-           v     v     v     v     v     v        v
-        +---+ +---+ +---+ +---+ +---+ +---+     +---+
-        | B | | C | | A | | B | | Q | | R |     | S |
-        +---+ +---+ +---+ +---+ +---+ +---+     +---+
-        /    \     \    \    \      \     \
-       v      v     v    v    v      v     v
-     +---+ +---+ +---+ +---+ +---+  +---+  +---+
-     | E | | D | | B | | B | | E |  | D |  | T |
-     +---+ +---+ +---+ +---+ +---+  +---+  +---+
-                 /  |    |  \
-               v    v    v   v
-           +---+ +---+ +---+ +---+
-           | E | | D | | E | | D |
-           +---+ +---+ +---+ +---+
-
-             Figure 11 - Reverse (From Anchor) Decision Tree
-
-
-
-Cooper, et al.               Informational                     [Page 26]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Given the relative complexity of this decision tree, it becomes clear
-   that making the right choices while navigating the tree can make a
-   large difference in how quickly a valid path is returned.  The path-
-   building software could potentially traverse the entire graph before
-   choosing the shortest path:  TA Z->BCA->X->L->N->EE.  With a decision
-   tree like the one above, the basic depth first traversal approach
-   introduces obvious inefficiencies in the path-building process.  To
-   compensate for this, a path-building module needs to decide not only
-   in which direction to traverse the tree, but also which branches of
-   the tree are more likely to yield a valid path.
-
-   The path-building algorithm then ideally becomes a tree traversal
-   algorithm with weights or priorities assigned to each branch point to
-   guide the decision making.  If properly designed, such an approach
-   would effectively yield the "best path first" more often than not.
-   (The terminology "best path first" is quoted because the definition
-   of the "best" path may differ from PKI to PKI.  That is ultimately to
-   be determined by the developer, not by this document.)  Finding the
-   "best path first" is an effort to make the implementation efficient,
-   which is one of our criteria as stated in Section 2.2.
-
-   So how would a developer go about finding the best path first?  Given
-   the simplifying idea of addressing path building as a tree traversal,
-   path building could be structured as a depth first search.  A simple
-   example of depth first tree traversal path building is depicted in
-   Figure 12, with no preference given to sort order.
-
-   Note: The arrows in the lower portion of the figure do not indicate
-   the direction of certificate issuance; they indicate the direction of
-   the tree traversal from the target certificate (EE).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 27]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-               +----+                        +----+  +----+
-               | TA |                        | TA |  | TA |
-               +----+                        +----+  +----+
-                /  \                           ^     ^
-               /    \                           |     |
-              v      v                        +---+ +---+
-            +---+   +---+                     | A | | C |
-            | A |<->| C |                     +---+ +---+
-            +---+   +---+                        ^   ^
-              ^      ^                   +----+  |   |  +----+
-               \    /                    | TA |  |   |  | TA |
-                v  v                     +----+  |   |  +----+
-               +---+                         ^   |   |   ^
-               | B |                          \  |   |  /
-               +---+                           \ |   | /
-                / \                           +---+ +---+
-               /   \                          | C | | A |
-              v     v                         +---+ +---+
-            +---+ +---+                          ^    ^
-            | E | | D |                          |   /
-            +---+ +---+                          |  /
-                                                +---+
-          Infrastructure                        | B |
-                                                +---+
-                                                  ^
-                                                  |
-                                               +----+
-                                               | EE |
-                                               +----+
-
-                                      The Same Infrastructure
-                                       Represented as a Tree
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 28]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-                    +----+               +----+
-                    | TA |               | TA |
-                    +----+               +----+
-                       ^                    ^
-                       |                    |
-                      +---+               +---+
-                      | A |               | C |
-                      +---+               +---+
-   +----+                ^                 ^                 +----+
-   | TA |                |                 |                 | TA |
-   +----+                |                 |                 +----+
-      ^                  |                 |                   ^
-       \                 |                 |                  /
-      +---+           +---+                +---+           +---+
-      | C |           | C |                | A |           | A |
-      +---+           +---+                +---+           +---+
-         ^               ^                    ^               ^
-         |               |                   /               /
-         |               |                  /               /
-        +---+           +---+          +---+           +---+
-        | B |           | B |          | B |           | B |
-        +---+           +---+          +---+           +---+
-          ^               ^              ^               ^
-          |               |              |               |
-          |               |              |               |
-        +----+          +----+         +----+          +----+
-        | EE |          | EE |         | EE |          | EE |
-        +----+          +----+         +----+          +----+
-
-                     All possible paths from EE to TA
-                using a depth first decision tree traversal
-
-       Figure 12 - Path Building Using a Depth First Tree Traversal
-
-   Figure 12 illustrates that four possible paths exist for this
-   example.  Suppose that the last path (TA->A->B->EE) is the only path
-   that will validate.  This could be for any combination of reasons
-   such as name constraints, policy processing, validity periods, or
-   path length constraints.  The goal of an efficient path-building
-   component is to select the fourth path first by testing properties of
-   the certificates as the tree is traversed.  For example, when the
-   path-building software is at entity B in the graph, it should examine
-   both choices A and C to determine which certificate is the most
-   likely best choice.  An efficient module would conclude that A is the
-   more likely correct path.  Then, at A, the module compares
-   terminating the path at TA, or moving to C.  Again, an efficient
-   module will make the better choice (TA) and thereby find the "best
-   path first".
-
-
-
-Cooper, et al.               Informational                     [Page 29]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   What if the choice between CA certificates is not binary as it was in
-   the previous example?  What if the path-building software encounters
-   a branch point with some arbitrary number of CA certificates thereby
-   creating the same arbitrary number of tree branches?  (This would be
-   typical in a mesh style PKI CA, or at a Bridge CA directory entry, as
-   each will have multiple certificates issued to itself from other
-   CAs.)  This situation actually does not change the algorithm at all,
-   if it is structured properly.  In our example, rather than treating
-   each decision as binary (i.e., choosing A or C), the path-building
-   software should sort all the available possibilities at any given
-   branch point, and then select the best choice from the list.  In the
-   event the path could not be built through the first choice, then the
-   second choice should be tried next upon traversing back to that point
-   in the tree.  Continue following this pattern until a path is found
-   or all CA nodes in the tree have been traversed.  Note that the
-   certificates at any given point in the tree should only be sorted at
-   the time a decision is first made.  Specifically, in the example, the
-   sorting of A and C is done when the algorithm reached B.  There is no
-   memory resident representation of the entire tree.  Just like any
-   other recursive depth first search algorithm, the only information
-   the algorithm needs to keep track of is what nodes (entities) in the
-   tree lie behind it on the current path, and for each of those nodes,
-   which arcs (certificates) have already been tried.
-
-2.5.  Building Certification Paths for Revocation Signer Certificates
-
-   Special consideration is given to building a certification path for
-   the Revocation Signer certificate because it may or may not be the
-   same as the Certification Authority certificate.  For example, after
-   a CA performs a key rollover, the new CA certificate will be the CRL
-   Signer certificate, whereas the old CA certificate is the
-   Certification Authority certificate for previously issued
-   certificates.  In the case of indirect CRLs, the CRL Signer
-   certificate will contain a different name and key than the
-   Certification Authority certificate.  In the case of OCSP, the
-   Revocation Signer certificate may represent an OCSP Responder that is
-   not the same entity as the Certification Authority.
-
-   When the Revocation Signer certificate and the Certification
-   Authority certificate are identical, no additional consideration is
-   required from a certification path-building standpoint.  That is, the
-   certification path built (and validated) for the Certification
-   Authority certificate can also be used as the certification path for
-   the Revocation Signer certificate.  In this case, the signature on
-   the revocation data (e.g., CRL or OCSP response) is verified using
-   the same certificate, and no other certification path building is
-   required.  An efficient certification path validation algorithm
-   should first try all possible CRLs issued by the Certification
-
-
-
-Cooper, et al.               Informational                     [Page 30]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Authority to determine if any of the CRLs (a) cover the certificate
-   in question, (b) are current, and (c) are signed using the same key
-   used to sign the certificate.
-
-   When the Revocation Signer certificate is not identical to the
-   Certification Authority certificate, a certification path must be
-   built (and validated) for the Revocation Signer certificate.  In
-   general, the certification path-building software may build the path
-   as it would for any other certificate.  However, this document also
-   outlines methods in later sections for greatly improving path
-   building efficiency for Revocation Signer certificate case.
-
-2.6.  Suggested Path-Building Software Components
-
-   There is no single way to define an interface to a path-building
-   module.  It is not the intent of this document to prescribe a
-   particular method or semantic; rather, it is up to the implementer to
-   decide.  There are many ways this could be done.  For example, a
-   path-building module could build every conceivable path and return
-   the entire list to the caller.  Or, the module could build until it
-   finds just one that validates and then terminate the procedure.  Or,
-   it could build paths in an iterative fashion, depending on validation
-   outside of the builder and successive calls to the builder to get
-   more paths until one valid path is found or all possible paths have
-   been found.  All of these are possible approaches, and each of these
-   may offer different benefits to a particular environment or
-   application.
-
-   Regardless of semantics, a path-building module needs to contain the
-   following components:
-
-   1) The logic for building and traversing the certificate graph.
-
-   2) Logic for retrieving the necessary certificates (and CRLs and/or
-      other revocation status information if the path is to be
-      validated) from the available source(s).
-
-   Assuming a more efficient and agile path-building module is desired,
-   the following is a good starting point and will tie into the
-   remainder of this document.  For a path-building module to take full
-   advantage of all the suggested optimizations listed in this document,
-   it will need all of the components listed below.
-
-   1) A local certificate and CRL cache.
-
-      a. This may be used by all certificate-using components; it does
-         not need to be specific to the path-building software.  A local
-         cache could be memory resident, stored in an operating system
-
-
-
-Cooper, et al.               Informational                     [Page 31]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-         or application certificate store, stored in a database, or even
-         stored in individual files on the hard disk.  While the
-         implementation of this cache is beyond the scope of this
-         document, some design considerations are listed below.
-
-   2) The logic for building and traversing the certificate graph/tree.
-
-      a. This performs sorting functionality for prioritizing
-         certificates (thereby optimizing path building) while
-         traversing the tree.
-
-      b. There is no need to build a complete graph prior to commencing
-         path building.  Since path building can be implemented as a
-         depth first tree traversal, the path builder only needs to
-         store the current location in the tree along with the points
-         traversed to the current location.  All completed branches can
-         be discarded from memory and future branches are discovered as
-         the tree is traversed.
-
-   3) Logic for retrieving the necessary certificates from the available
-      certificate source(s):
-
-      a. Local cache.
-
-            i. Be able to retrieve all certificates for an entity by
-               subject name, as well as individual certificates by
-               issuer and serial number tuple.
-
-           ii. Tracking which directory attribute (including
-               issuedToThisCA <forward> and issuedByThisCA <reverse>
-               for split crossCertificatePair attributes) each
-               certificate was found in may be useful.  This allows for
-               functionality such as retrieving only forward cross-
-               certificates, etc.
-
-          iii. A "freshness" timestamp (cache expiry time) can be used
-               to determine when the directory should be searched
-               again.
-
-      b. LDAPv3 directory for certificates and CRLs.
-
-            i. Consider supporting multiple directories for general
-               queries.
-
-           ii. Consider supporting dynamic LDAP connections for
-               retrieving CRLs using an LDAP URI [RFC3986] in the CRL
-               distribution point certificate extension.
-
-
-
-
-Cooper, et al.               Informational                     [Page 32]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-          iii. Support LDAP referrals.  This is typically only a matter
-               of activating the appropriate flag in the LDAP API.
-
-      c. HTTP support for CRL distribution points and authority
-         information access (AIA) support.
-
-          i. Consider HTTPS support, but be aware that this may create
-             an unbounded recursion when the implementation tries to
-             build a certification path for the server's certificate if
-             this in turn requires an additional HTTPS lookup.
-
-   4) A certification path cache that stores previously validated
-      relationships between certificates.  This cache should include:
-
-      a. A configurable expiration date for each entry.  This date can
-         be configured based upon factors such as the expiry of the
-         information used to determine the validity of an entry,
-         bandwidth, assurance level, storage space, etc.
-
-      b. Support to store previously verified issuer certificate to
-         subject certificate relationships.
-
-          i. Since the issuer DN and serial number tuple uniquely
-             identifies a certificate, a pair of these tuples (one for
-             both the issuer and subject) is an effective method of
-             storing this relationship.
-
-      c. Support for storing "known bad" paths and certificates.  Once a
-         certificate is determined to be invalid, implementations can
-         decide not to retry path development and validation.
-
-2.7.  Inputs to the Path-Building Module
-
-   [X.509] specifically addresses the list of inputs required for path
-   validation but makes no specific suggestions concerning useful inputs
-   to path building.  However, given that the goal of path building is
-   to find certification paths that will validate, it follows that the
-   same inputs used for validation could be used to optimize path
-   building.
-
-2.7.1.  Required Inputs
-
-   Setting aside configuration information such as repository or cache
-   locations, the following are required inputs to the certification
-   path-building process:
-
-   1) The Target Certificate: The certificate that is to be validated.
-      This is one endpoint for the path.  (It is also possible to
-
-
-
-Cooper, et al.               Informational                     [Page 33]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-      provide information used to retrieve a certificate for a target,
-      rather than the certificate itself.)
-
-   2) Trust List: This is the other endpoint of the path, and can
-      consist of either:
-
-      a. Trusted CA certificates
-
-      b. Trusted keys and DNs; a certificate is not necessarily required
-
-2.7.2.  Optional Inputs
-
-   In addition to the inputs listed in Section 2.7.1, the following
-   optional inputs can also be useful for optimizing path building.
-   However, if the path-building software takes advantage of all of the
-   optimization methods described later in this document, all of the
-   following optional inputs will be required.
-
-   1) Time (T): The time for which the certificate is to be validated
-      (e.g., if validating a historical signature from one year ago, T
-      is needed to build a valid path)
-
-      a. If not included as an input, the path-building software should
-         always build for T equal to the current system time.
-
-   2) Initial-inhibit-policy-mapping indicator
-
-   3) Initial-require-explicit-policy indicator
-
-   4) Initial-any-policy-inhibit indicator
-
-   5) Initial user acceptable policy set
-
-   6) Error handlers (call backs or virtual classes)
-
-   7) Handlers for custom certificate extensions
-
-   8) Is-revocation-provider indicator
-
-      a. IMPORTANT:  When building a certification path for an OCSP
-         Responder certificate specified as part of the local
-         configuration, this flag should not be set.  It is set when
-         building a certification path for a CRL Signer certificate or
-         for an OCSP Responder Signer certificate discovered using the
-         information asserted in an authorityInformationAccess
-         certificate extension.
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 34]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   9) The complete certification path for the Certification Authority
-      (if Is-revocation-provider is set)
-
-   10) Collection of certificates that may be useful in building the
-       path
-
-   11) Collection of certificate revocation lists and/or other
-       revocation data
-
-   The last two items are a matter of convenience.  Alternately,
-   certificates and revocation information could be placed in a local
-   cache accessible to the path-building module prior to attempting to
-   build a path.
-
-3.  Optimizing Path Building
-
-   This section recommends methods for optimizing path-building
-   processes.
-
-3.1.  Optimized Path Building
-
-   Path building can be optimized by sorting the certificates at every
-   decision point (at every node in the tree) and then selecting the
-   most promising certificate not yet selected as described in Section
-   2.4.2.  This process continues until the path terminates.  This is
-   roughly equivalent to the concept of creating a weighted edge tree,
-   where the edges are represented by certificates and nodes represent
-   subject DNs.  However, unlike the weighted edge graph concept, a
-   certification path builder need not have the entire graph available
-   in order to function efficiently.  In addition, the path builder can
-   be stateless with respect to nodes of the graph not present in the
-   current path, so the working data set can be relatively small.
-
-   The concept of statelessness with respect to nodes not in the current
-   path is instrumental to using the sorting optimizations listed in
-   this document.  Initially, it may seem that sorting a given group of
-   certificates for a CA once and then preserving that sorted order for
-   later use would be an efficient way to write the path builder.
-   However, maintaining this state can quickly eliminate the efficiency
-   that sorting provides.  Consider the following diagram:
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 35]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-            +---+
-            | R |
-            +---+
-             ^
-            /
-           v
-         +---+       +---+      +---+    +---+    +----+
-         | A |<----->| E |<---->| D |--->| Z |--->| EE |
-         +---+       +---+      +---+    +---+    +----+
-            ^         ^ ^        ^
-             \       /   \      /
-              \     /     \    /
-               v   v       v  v
-               +---+       +---+
-               | B |<----->| C |
-               +---+       +---+
-
-            Figure 13 - Example of Path-Building Optimization
-
-   In this example, the path builder is building in the forward (from
-   target) direction for a path between R and EE.  The path builder has
-   also opted to allow subject name and key to repeat.  (This will allow
-   multiple traversals through any of the cross-certified CAs, creating
-   enough complexity in this small example to illustrate proper state
-   maintenance.  Note that a similarly complex example could be designed
-   by using multiple keys for each entity and prohibiting repetition.)
-
-   The first step is simple; the builder builds the path Z(D)->EE(Z).
-   Next the builder adds D and faces a decision between two
-   certificates. (Choose between D(C) or D(E)).  The builder now sorts
-   the two choices in order of priority.  The sorting is partially based
-   upon what is currently in the path.
-
-   Suppose the order the builder selects is [D(E), D(C)].  The current
-   path is now D(E)->Z(D)->EE(Z).  Currently the builder has three nodes
-   in the graph (EE, Z, and D) and should maintain the state, including
-   sort order of the certificates at D, when adding the next node, E.
-   When E is added, the builder now has four certificates to sort: E(A),
-   E(B), E(C), and E(D).  In this case, the example builder opts for the
-   order [E(C), E(B), E(A), E(D)].  The current path is now E(C)->D(E)->
-   Z(D)->EE(Z) and the path has four nodes; EE, Z, D, and E.
-
-   Upon adding the fifth node, C, the builder sorts the certificates
-   (C(B), C(D), and C(E)) at C, and selects C(E).  The path is now
-   C(E)->E(C)->D(E)->Z(D)->EE(Z) and the path has five nodes: EE, Z, D,
-   E, and C.
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 36]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Now the builder finds itself back at node E with four certificates.
-   If the builder were to use the prior sort order from the first
-   encounter with E, it would have [E(C), E(B), E(A), E(D)].  In the
-   current path's context, this ordering may be inappropriate.  To begin
-   with, the certificate E(C) is already in the path so it certainly
-   does not deserve first place.
-
-   The best way to handle this situation is for the path builder to
-   handle this instance of E as a new (sixth) node in the tree.  In
-   other words, there is no state information for this new instance of E
-   - it is treated just as any other new node.  The certificates at the
-   new node are sorted based upon the current path content and the first
-   certificate is then selected.  For example, the builder may examine
-   E(B) and note that it contains a name constraint prohibiting "C".  At
-   this point in the decision tree, E(B) could not be added to the path
-   and produce a valid result since "C" is already in the path.  As a
-   result, the certificate E(B) should placed at the bottom of the
-   prioritized list.
-
-   Alternatively, E(B) could be eliminated from this new node in the
-   tree.  It is very important to see that this certificate is
-   eliminated only at this node and only for the current path.  If path
-   building fails through C and traverses back up the tree to the first
-   instance of E, E(B) could still produce a valid path that does not
-   include C; specifically R->A->B->E->D->Z->EE.  Thus the state at any
-   node should not alter the state of previous or subsequent nodes.
-   (Except for prioritizing certificates in the subsequent nodes.)
-
-   In this example, the builder should also note that E(C) is already in
-   the path and should make it last or eliminate it from this node since
-   certificates cannot be repeated in a path.
-
-   If the builder eliminates both certificates E(B) and E(C) at this
-   node, it is now only left to select between E(A) and E(D).  Now the
-   path has six nodes: EE, Z, D, E(1), C, and E(2).  E(1) has four
-   certificates, and E(2) has two, which the builder sorts to yield
-   [E(A), E(D)].  The current path is now E(A)->C(E)->E(C)->D(E)->
-   Z(D)->EE(Z).  A(R) will be found when the seventh node is added to
-   the path and the path terminated because one of the trust anchors has
-   been found.
-
-   In the event the first path fails to validate, the path builder will
-   still have the seven nodes and associated state information to work
-   with.  On the next iteration, the path builder is able to traverse
-   back up the tree to a working decision point, such as A, and select
-   the next certificate in the sorted list at A.  In this example, that
-   would be A(B).  (A(R) has already been tested.)  This would dead end,
-   and the builder traverse back up to the next decision point, E(2)
-
-
-
-Cooper, et al.               Informational                     [Page 37]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   where it would try D(E).  This process repeats until the traversal
-   backs all the way up to EE or a valid path is found.  If the tree
-   traversal returns to EE, all possible paths have been exhausted and
-   the builder can conclude no valid path exists.
-
-   This approach of sorting certificates in order to optimize path
-   building will yield better results than not optimizing the tree
-   traversal.  However, the path-building process can be further
-   streamlined by eliminating certificates, and entire branches of the
-   tree as a result, as paths are built.
-
-3.2.  Sorting vs. Elimination
-
-   Consider a situation when building a path in which three CA
-   certificates are found for a given target certificate and must be
-   prioritized.  When the certificates are examined, as in the previous
-   example, one of the three has a name constraint present that will
-   invalidate the path built thus far.  When sorting the three
-   certificates, that one would certainly go to the back of the line.
-   However, the path-building software could decide that this condition
-   eliminates the certificate from consideration at this point in the
-   graph, thereby reducing the number of certificate choices by 33% at
-   this point.
-
-   NOTE: It is important to understand that the elimination of a
-   certificate only applies to a single decision point during the tree
-   traversal.  The same certificate may appear again at another point in
-   the tree; at that point it may or may not be eliminated.  The
-   previous section details an example of this behavior.
-
-   Elimination of certificates could potentially eliminate the traversal
-   of a large, time-consuming infrastructure that will never lead to a
-   valid path.  The question of whether to sort or eliminate is one that
-   pits the flexibility of the software interface against efficiency.
-
-   To be clear, if one eliminates invalid paths as they are built,
-   returning only likely valid paths, the end result will be an
-   efficient path-building module.  The drawback to this is that unless
-   the software makes allowances for it, the calling application will
-   not be able to see what went wrong.  The user may only see the
-   unrevealing error message: "No certification path found."
-
-   On the other hand, the path-building module could opt to not rule out
-   any certification paths.  The path-building software could then
-   return any and all paths it can build from the certificate graph.  It
-   is then up to the validation engine to determine which are valid and
-   which are invalid.  The user or calling application can then have
-   complete details on why each and every path fails to validate.  The
-
-
-
-Cooper, et al.               Informational                     [Page 38]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   drawback is obviously one of performance, as an application or end
-   user may wait for an extended period of time while cross-certified
-   PKIs are navigated in order to build paths that will never validate.
-
-   Neither option is a very desirable approach.  One option provides
-   good performance for users, which is beneficial.  The other option
-   though allows administrators to diagnose problems with the PKI,
-   directory, or software.  Below are some recommendations to reach a
-   middle ground on this issue.
-
-   First, developers are strongly encouraged to output detailed log
-   information from the path-building software.  The log should
-   explicitly indicate every choice the builder makes and why.  It
-   should clearly identify which certificates are found and used at each
-   step in building the path.  If care is taken to produce a useful log,
-   PKI administrators and help desk personnel will have ample
-   information to diagnose a problem with the PKI.  Ideally, there would
-   be a mechanism for turning this logging on and off, so that it is not
-   running all the time.  Additionally, it is recommended that the log
-   contain information so that a developer or tester can recreate the
-   paths tried by the path-building software, to assist with diagnostics
-   and testing.
-
-   Secondly, it is desirable to return something useful to the user.
-   The easiest approach is probably to implement a "dual mode" path-
-   building module.  In the first mode [mode 1], the software eliminates
-   any and all paths that will not validate, making it very efficient.
-   In the second mode [mode 2], all the sorting methods are still
-   applied, but no paths are eliminated based upon the sorting methods.
-   Having this dual mode allows the module to first fail to find a valid
-   path, but still return one invalid path (assuming one exists) by
-   switching over to the second mode long enough to generate a single
-   path.  This provides a middle ground -- the software is very fast,
-   but still returns something that gives the user a more specific error
-   than "no path found".
-
-   Third, it may be useful to not rule out any paths, but instead limit
-   the number of paths that may be built given a particular input.
-   Assuming the path-building module is designed to return the "best
-   path first", the paths most likely to validate would be returned
-   before this limit is reached.  Once the limit is reached the module
-   can stop building paths, providing a more rapid response to the
-   caller than one which builds all possible paths.
-
-   Ultimately, the developer determines how to handle the trade-off
-   between efficiency and provision of information.  A developer could
-   choose the middle ground by opting to implement some optimizations as
-   elimination rules and others as not.  A developer could validate
-
-
-
-Cooper, et al.               Informational                     [Page 39]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   certificate signatures, or even check revocation status while
-   building the path, and then make decisions based upon the outcome of
-   those checks as to whether to eliminate the certificate in question.
-
-   This document suggests the following approach:
-
-   1) While building paths, eliminate any and all certificates that do
-      not satisfy all path validation requirements with the following
-      exceptions:
-
-      a. Do not check revocation status if it requires a directory
-         lookup or network access
-
-      b. Do not check digital signatures (see Section 8.1, General
-         Considerations for Building A Certification Path, for
-         additional considerations).
-
-      c. Do not check anything that cannot be checked as part of the
-         iterative process of traversing the tree.
-
-      d. Create a detailed log, if this feature is enabled.
-
-      e. If a path cannot be found, the path builder shifts to "mode 2"
-         and allows the building of a single bad path.
-
-            i. Return the path with a failure indicator, as well as
-               error information detailing why the path is bad.
-
-   2) If path building succeeds, validate the path in accordance with
-      [X.509] and [RFC3280] with the following recommendations:
-
-      a. For a performance boost, do not re-check items already checked
-         by the path builder. (Note: if pre-populated paths are supplied
-         to the path-building system, the entire path has to be fully
-         re-validated.)
-
-      b. If the path validation failed, call the path builder again to
-         build another path.
-
-            i. Always store the error information and path from the
-               first iteration and return this to the user in the event
-               that no valid path is found.  Since the path-building
-               software was designed to return the "best path first",
-               this path should be shown to the user.
-
-   As stated above, this document recommends that developers do not
-   validate digital signatures or check revocation status as part of the
-   path-building process.  This recommendation is based on two
-
-
-
-Cooper, et al.               Informational                     [Page 40]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   assumptions about PKI and its usage.  First, signatures in a working
-   PKI are usually good.  Since signature validation is costly in terms
-   of processor time, it is better to delay signature checking until a
-   complete path is found and then check the signatures on each
-   certificate in the certification path starting with the trust anchor
-   (see Section 8.1).  Second, it is fairly uncommon in typical
-   application environments to encounter a revoked certificate;
-   therefore, most certificates validated will not be revoked.  As a
-   result, it is better to delay retrieving CRLs or other revocation
-   status information until a complete path has been found.  This
-   reduces the probability of retrieving unneeded revocation status
-   information while building paths.
-
-3.3.  Representing the Decision Tree
-
-   There are a multitude of ways to implement certification path
-   building and as many ways to represent the decision tree in memory.
-
-   The method described below is an approach that will work well with
-   the optimization methods listed later in this document.  Although
-   this approach is the best the authors of this document have
-   implemented, it is by no means the only way to implement it.
-   Developers should tailor this approach to their own requirements or
-   may find that another approach suits their environment, programming
-   language, or programming style.
-
-3.3.1.  Node Representation for CA Entities
-
-   A "node" in the certification graph is a collection of CA
-   certificates with identical subject DNs.  Minimally, for each node,
-   in order to fully implement the optimizations to follow, the path-
-   building module will need to be able to keep track of the following
-   information:
-
-   1. Certificates contained in the node
-
-   2. Sorted order of the certificates
-
-   3. "Current" certificate indicator
-
-   4. The current policy set (It may be split into authority and user
-      constrained sets, if desired.)
-
-      - It is suggested that encapsulating the policy set in an object
-        with logic for manipulating the set such as performing
-        intersections, mappings, etc., will simplify implementation.
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 41]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   5. Indicators (requireExplicitPolicy, inhibitPolicyMapping,
-      anyPolicyInhibit) and corresponding skipCert values
-
-   6. A method for indicating which certificates are eliminated or
-      removing them from the node.
-
-      - If nodes are recreated from the cache on demand, it may be
-        simpler to remove eliminated certificates from the node.
-
-   7. A "next" indicator that points to the next node in the current
-      path
-
-   8. A "previous" indicator that points to the previous node in the
-      current path
-
-3.3.2.  Using Nodes to Iterate Over All Paths
-
-   In simplest form, a node is created, the certificates are sorted, the
-   next subject DN required is determined from the first certificate,
-   and a new node is attached to the certification path via the next
-   indicator (Number 7 above).  This process continues until the path
-   terminates.  (Note: end entity certificates may not contain subject
-   DNs as allowed by [RFC3280].  Since end entity certificates by
-   definition do not issue certificates, this has no impact on the
-   process.)
-
-   Keeping in mind that the following algorithm is designed to be
-   implemented using recursion, consider the example in Figure 12 and
-   assume that the only path in the diagram is valid for E is TA->A->
-   B->E:
-
-   If our path-building module is building a path in the forward
-   direction for E, a node is first created for E.  There are no
-   certificates to sort because only one certificate exists, so all
-   initial values are loaded into the node from E.  For example, the
-   policy set is extracted from the certificate and stored in the node.
-
-   Next, the issuer DN (B) is read from E, and new node is created for B
-   containing both certificates issued to B -- B(A) and B(C).  The
-   sorting rules are applied to these two certificates and the sorting
-   algorithm returns B(C);B(A).  This sorted order is stored and the
-   current indicator is set to B(C).  Indicators are set and the policy
-   sets are calculated to the extent possible with respect to B(C).  The
-   following diagram illustrates the current state with the current
-   certificate indicated with a "*".
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 42]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   +-------------+    +---------------+
-   | Node 1      |    | Node 2        |
-   | Subject: E  |--->| Subject: B    |
-   | Issuers: B* |    | Issuers: C*,A |
-   +-------------+    +---------------+
-
-   Next, a node is created for C and all three certificates are added to
-   it.  The sorting algorithm happens to return the certificates sorted
-   in the following order: C(TA);C(A);C(B)
-
-   +-------------+    +---------------+    +------------------+
-   | Node 1      |    | Node 2        |    | Node 3           |
-   | Subject: E  |--->| Subject: B    |--->| Subject: C       |
-   | Issuers: B  |    | Issuers: C*,A |    | Issuers: TA*,A,B |
-   +-------------+    +---------------+    +------------------+
-
-   Recognizing that the trust anchor has been found, the path
-   (TA->C->B->E) is validated but fails. (Remember that the only valid
-   path happens to be TA->A->B->E.)  The path-building module now moves
-   the current certificate indicator in node 3 to C(A), and adds the
-   node for A.
-
-      +-------------+    +---------------+    +------------------+
-      | Node 1      |    | Node 2        |    | Node 3           |
-      | Subject: E  |--->| Subject: B    |--->| Subject: C       |
-      | Issuers: B  |    | Issuers: C*,A |    | Issuers: TA,A*,B |
-      +-------------+    +---------------+    +------------------+
-                                                        |
-                                                        v
-                                              +------------------+
-                                              | Node 4           |
-                                              | Subject: A       |
-                                              | Issuers: TA*,C,B |
-                                              +------------------+
-
-   The path TA->A->C->B->E is validated and it fails.  The path-building
-   module now moves the current indicator in node 4 to A(C) and adds a
-   node for C.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 43]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   +-------------+    +---------------+    +------------------+
-   | Node 1      |    | Node 2        |    | Node 3           |
-   | Subject: E  |--->| Subject: B    |--->| Subject: C       |
-   | Issuers: B  |    | Issuers: C*,A |    | Issuers: TA,A*,B |
-   +-------------+    +---------------+    +------------------+
-                                                     |
-                                                     v
-                   +------------------+    +------------------+
-                   | Node 5           |    | Node 4           |
-                   | Subject: C       |<---| Subject: A       |
-                   | Issuers: TA*,A,B |    | Issuers: TA,C*,B |
-                   +------------------+    +------------------+
-
-   At this juncture, the decision of whether to allow repetition of name
-   and key comes to the forefront.  If the certification path-building
-   module will NOT allow repetition of name and key, there are no
-   certificates in node 5 that can be used. (C and the corresponding
-   public key is already in the path at node 3.)  At this point, node 5
-   is removed from the current path and the current certificate
-   indicator on node 4 is moved to A(B).
-
-   If instead, the module is only disallowing repetition of
-   certificates, C(A) is eliminated from node 5 since it is in use in
-   node 3, and path building continues by first validating TA->C->A->
-   C->B->E, and then continuing to try to build paths through C(B).
-   After this also fails to provide a valid path, node 5 is removed from
-   the current path and the current certificate indicator on node 4 is
-   moved to A(B).
-
-      +-------------+    +---------------+    +------------------+
-      | Node 1      |    | Node 2        |    | Node 3           |
-      | Subject: E  |--->| Subject: B    |--->| Subject: C       |
-      | Issuers: B  |    | Issuers: C*,A |    | Issuers: TA,A*,B |
-      +-------------+    +---------------+    +------------------+
-                                                        |
-                                                        v
-                                              +------------------+
-                                              | Node 4           |
-                                              | Subject: A       |
-                                              | Issuers: TA,C,B* |
-                                              +------------------+
-
-   Now a new node 5 is created for B.  Just as with the prior node 5, if
-   not repeating name and key, B also offers no certificates that can be
-   used (B and B's public key is in use in node 2) so the new node 5 is
-   also removed from the path.  At this point all certificates in node 4
-   have now been tried, so node 4 is removed from the path, and the
-   current indicator on node 3 is moved to C(B).
-
-
-
-Cooper, et al.               Informational                     [Page 44]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Also as above, if allowing repetition of name and key, B(C) is
-   removed from the new node 5 (B(C) is already in use in node 3) and
-   paths attempted through the remaining certificate B(A).  After this
-   fails, it will lead back to removing node 5 from the path.  At this
-   point all certificates in node 4 have now been tried, so node 4 is
-   removed from the path, and the current indicator on node 3 is moved
-   to C(B).
-
-   This process continues until all certificates in node 1 (if there
-   happened to be more than one) have been tried, or until a valid path
-   has been found.  Once the process ends and in the event no valid path
-   was found, it may be concluded that no path can be found from E to
-   TA.
-
-3.4.  Implementing Path-Building Optimization
-
-   The following section describes methods that may be used for
-   optimizing the certification path-building process by sorting
-   certificates.  Optimization as described earlier seeks to prioritize
-   a list of certificates, effectively prioritizing (weighting) branches
-   of the graph/tree.  The optimization methods can be used to assign a
-   cumulative score to each certificate.  The process of scoring the
-   certificates amounts to testing each certificate against the
-   optimization methods a developer chooses to implement, and then
-   adding the score for each test to a cumulative score for each
-   certificate.  After this is completed for each certificate at a given
-   branch point in the builder's decision tree, the certificates can be
-   sorted so that the highest scoring certificate is selected first, the
-   second highest is selected second, etc.
-
-   For example, suppose the path builder has only these two simple
-   sorting methods:
-
-   1) If the certificate has a subject key ID, +5 to score.
-   2) If the certificate has an authority key ID, +10 to score.
-
-   And it then examined three certificates:
-
-   1) Issued by CA 1; has authority key ID; score is 10.
-   2) Issued by CA 2; has subject key ID; score is 5.
-   3) Issued by CA 1; has subject key ID and authority key ID; score is
-      15.
-
-   The three certificates are sorted in descending order starting with
-   the highest score: 3, 1, and 2.  The path-building software should
-   first try building the path through certificate 3.  Failing that, it
-   should try certificate 1.  Lastly, it should try building a path
-   through certificate 2.
-
-
-
-Cooper, et al.               Informational                     [Page 45]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   The following optimization methods specify tests developers may
-   choose to perform, but does not suggest scores for any of the
-   methods.  Rather, developers should evaluate each method with respect
-   to the environment in which the application will operate, and assign
-   weights to each accordingly in the path-building software.
-   Additionally, many of the optimization methods are not binary in
-   nature.  Some are tri-valued, and some may be well suited to sliding
-   or exponential scales.  Ultimately, the implementer decides the
-   relative merits of each optimization with respect to his or her own
-   software or infrastructure.
-
-   Over and above the scores for each method, many methods can be used
-   to eliminate branches during the tree traversal rather than simply
-   scoring and weighting them.  All cases where certificates could be
-   eliminated based upon an optimization method are noted with the
-   method descriptions.
-
-   Many of the sorting methods described below are based upon what has
-   been perceived by the authors as common in PKIs.  Many of the methods
-   are aimed at making path building for the common PKI fast, but there
-   are cases where most any sorting method could lead to inefficient
-   path building.  The desired behavior is that although one method may
-   lead the algorithm in the wrong direction for a given situation or
-   configuration, the remaining methods will overcome the errant
-   method(s) and send the path traversal down the correct branch of the
-   tree more often than not.  This certainly will not be true for every
-   environment and configuration, and these methods may need to be
-   tweaked for further optimization in the application's target
-   operating environment.
-
-   As a final note, the list contained in this document is not intended
-   to be exhaustive.  A developer may desire to define additional
-   sorting methods if the operating environment dictates the need.
-
-3.5.  Selected Methods for Sorting Certificates
-
-   The reader should draw no specific conclusions as to the relative
-   merits or scores for each of the following methods based upon the
-   order in which they appear.  The relative merit of any sorting
-   criteria is completely dependent on the specifics of the operating
-   environment.  For most any method, an example can be created to
-   demonstrate the method is effective and a counter-example could be
-   designed to demonstrate that it is ineffective.
-
-   Each sorting method is independent and may (or may not) be used to
-   assign additional scores to each certificate tested.  The implementer
-   decides which methods to use and what weights to assign them.  As
-   noted previously, this list is also not exhaustive.
-
-
-
-Cooper, et al.               Informational                     [Page 46]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   In addition, name chaining (meaning the subject name of the issuer
-   certificate matches the issuer name of the issued certificate) is not
-   addressed as a sorting method since adherence to this is required in
-   order to build the decision tree to which these methods will be
-   applied.  Also, unaddressed in the sorting methods is the prevention
-   of repeating certificates.  Path builders should handle name chaining
-   and certificate repetition irrespective of the optimization approach.
-
-   Each sorting method description specifies whether the method may be
-   used to eliminate certificates, the number of possible numeric values
-   (sorting weights) for the method, components from Section 2.6 that
-   are required for implementing the method, forward and reverse methods
-   descriptions, and finally a justification for inclusion of the
-   method.
-
-   With regard to elimination of certificates, it is important to
-   understand that certificates are eliminated only at a given decision
-   point for many methods.  For example, the path built up to
-   certificate X may be invalidated due to name constraints by the
-   addition of certificate Y.  At this decision point only, Y could be
-   eliminated from further consideration.  At some future decision
-   point, while building this same path, the addition of Y may not
-   invalidate the path.
-
-   For some other sorting methods, certificates could be eliminated from
-   the process entirely.  For example, certificates with unsupported
-   signature algorithms could not be included in any path and validated.
-   Although the path builder may certainly be designed to operate in
-   this fashion, it is sufficient to always discard certificates only
-   for a given decision point regardless of cause.
-
-3.5.1.  basicConstraints Is Present and cA Equals True
-
-   May be used to eliminate certificates: Yes
-   Number of possible values: Binary
-   Components required: None
-
-   Forward Method:  Certificates with basicConstraints present and
-   cA=TRUE, or those designated as CA certificates out-of-band have
-   priority.  Certificates without basicConstraints, with
-   basicConstraints and cA=FALSE, or those that are not designated as CA
-   certificates out-of-band may be eliminated or have zero priority.
-
-   Reverse Method:  Same as forward except with regard to end entity
-   certificates at the terminus of the path.
-
-   Justification:  According to [RFC3280], basicConstraints is required
-   to be present with cA=TRUE in all CA certificates, or must be
-
-
-
-Cooper, et al.               Informational                     [Page 47]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   verified via an out-of-band mechanism.  A valid path cannot be built
-   if this condition is not met.
-
-3.5.2.  Recognized Signature Algorithms
-
-   May be used to eliminate certificates: Yes
-   Number of possible values: Binary
-   Components required: None
-
-   Forward Method:  Certificates containing recognized signature and
-   public key algorithms [PKIXALGS] have priority.
-
-   Reverse Method:  Same as forward.
-
-   Justification:  If the path-building software is not capable of
-   processing the signatures associated with the certificate, the
-   certification path cannot be validated.
-
-3.5.3.  keyUsage Is Correct
-
-   May be used to eliminate certificates:  Yes
-   Number of possible values:  Binary
-   Components required:  None
-
-   Forward Method:  If keyUsage is present, certificates with
-   keyCertSign set have 100% priority.  If keyUsage is present and
-   keyCertSign is not set, the certificate may be eliminated or have
-   zero priority.  All others have zero priority.
-
-   Reverse Method:  Same as forward except with regard to end entity
-   certificates at the terminus of the path.
-
-   Justification:  A valid certification path cannot be built through a
-   CA certificate with inappropriate keyUsage.  Note that
-   digitalSignature is not required to be set in a CA certificate.
-
-3.5.4.  Time (T) Falls within the Certificate Validity
-
-   May be used to eliminate certificates:  Yes
-   Number of possible values:  Binary
-   Components required:  None
-
-   Forward Method:  Certificates that contain the required time (T)
-   within their validity period have 100% priority.  Otherwise, the
-   certificate is eliminated or has priority zero.
-
-   Reverse Method:  Same as forward.
-
-
-
-
-Cooper, et al.               Informational                     [Page 48]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Justification:  A valid certification path cannot be built if T falls
-   outside of the certificate validity period.
-
-   NOTE: Special care should be taken to return a meaningful error to
-   the caller, especially in the event the target certificate does not
-   meet this criterion, if this sorting method is used for elimination.
-   (e.g., the certificate is expired or is not yet valid).
-
-3.5.5.  Certificate Was Previously Validated
-
-   May be used to eliminate certificates:  No
-   Number of possible values:  Binary
-   Components required:  Certification Path Cache
-
-   Forward Method:  A certificate that is present in the certification
-   path cache has priority.
-
-   Reverse Method:  Does not apply. (The validity of a certificate vs.
-   unknown validity does not infer anything about the correct direction
-   in the decision tree.  In other words, knowing the validity of a CA
-   certificate does not indicate that the target is more likely found
-   through that path than another.)
-
-   Justification:  Certificates in the path cache have been validated
-   previously.  Assuming the initial constraints have not changed, it is
-   highly likely that the path from that certificate to a trust anchor
-   is still valid.  (Changes to the initial constraints may cause a
-   certificate previously considered valid to no longer be considered
-   valid.)
-
-   Note:  It is important that items in the path cache have appropriate
-   life times.  For example, it could be inappropriate to cache a
-   relationship beyond the period the related CRL will be trusted by the
-   application.  It is also critical to consider certificates and CRLs
-   farther up the path when setting cache lifetimes.  For example, if
-   the issuer certificate expires in ten days, but the issued
-   certificate is valid for 20 days, caching the relationship beyond 10
-   days would be inappropriate.
-
-3.5.6.  Previously Verified Signatures
-
-   May be used to eliminate certificates:  Yes
-   Number of possible values:  Binary
-   Components required:  Path Cache
-
-   Forward Method:   If a previously verified relationship exists in the
-   path cache between the subject certificate and a public key present
-   in one or more issuer certificates, all the certificates containing
-
-
-
-Cooper, et al.               Informational                     [Page 49]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   said public key have higher priority.  Other certificates may be
-   eliminated or set to zero priority.
-
-   Reverse Method:  If known bad signature relationships exist between
-   certificates, these relationships can be used to eliminate potential
-   certificates from the decision tree.  Nothing can be concluded about
-   the likelihood of finding a given target certificate down one branch
-   versus another using known good signature relationships.
-
-   Justification: If the public key in a certificate (A) was previously
-   used to verify a signature on a second certificate (B), any and all
-   certificates containing the same key as (A) may be used to verify the
-   signature on (B).  Likewise, any certificates that do not contain the
-   same key as (A) cannot be used to verify the signature on (B).  This
-   forward direction method is especially strong for multiply cross-
-   certified CAs after a key rollover has occurred.
-
-3.5.7.  Path Length Constraints
-
-   May be used to eliminate certificates: Yes
-   Number of possible values: Binary
-   Components required: None
-
-   Forward Method:  Certificates with basic constraints present and
-   containing a path length constraint that would invalidate the current
-   path (the current length is known since the software is building from
-   the target certificate) may be eliminated or set to zero priority.
-   Otherwise, the priority is 100%.
-
-   Reverse Method:  This method may be applied in reverse.  To apply it,
-   the builder keeps a current path length constraint variable and then
-   sets zero priority for (or eliminates) certificates that would
-   violate the constraint.
-
-   Justification:  A valid path cannot be built if the path length
-   constraint has been violated.
-
-3.5.8.  Name Constraints
-
-   May be used to eliminate certificates:  Yes
-   Number of possible values:  Binary
-   Components required:  None
-
-   Forward Method:  Certificates that contain nameConstraints that would
-   be violated by certificates already in the path to this point are
-   given zero priority or eliminated.
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 50]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Reverse Method:  Certificates that will allow successful processing
-   of any name constraints present in the path to this point are given
-   higher priority.
-
-   Justification:  A valid path cannot be built if name constraints are
-   violated.
-
-3.5.9.  Certificate Is Not Revoked
-
-   May be used to eliminate certificates: No
-   Number of possible values:  Three
-   Components required:  CRL Cache
-
-   Forward Method:  If a current CRL for a certificate is present in the
-   CRL cache, and the certificate serial number is not on the CRL, the
-   certificate has priority.  If the certificate serial number is
-   present on the CRL, it has zero priority.  If an (acceptably fresh)
-   OCSP response is available for a certificate, and identifies the
-   certificate as valid, the certificate has priority.  If an OCSP
-   response is available for a certificate, and identifies the
-   certificate as invalid, the certificate has zero priority.
-
-   Reverse Method:  Same as Forward.
-
-   Alternately, the certificate may be eliminated if the CRL or OCSP
-   response is verified.  That is, fully verify the CRL or OCSP response
-   signature and relationship to the certificate in question in
-   accordance with [RFC3280].  While this is viable, the signature
-   verification required makes it less attractive as an elimination
-   method.  It is suggested that this method only be used for sorting
-   and that CRLs and OCSP responses are validated post path building.
-
-   Justification:  Certificates known to be not revoked can be
-   considered more likely to be valid than certificates for which the
-   revocation status is unknown.  This is further justified if CRL or
-   OCSP response validation is performed post path validation - CRLs or
-   OCSP responses are only retrieved when complete paths are found.
-
-   NOTE:  Special care should be taken to allow meaningful errors to
-   propagate to the caller, especially in cases where the target
-   certificate is revoked.  If a path builder eliminates certificates
-   using CRLs or OCSP responses, some status information should be
-   preserved so that a meaningful error may be returned in the event no
-   path is found.
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 51]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-3.5.10.  Issuer Found in the Path Cache
-
-   May be used to eliminate certificates: No
-   Number of possible values: Binary
-   Components required:  Certification Path Cache
-
-   Forward Method:  A certificate whose issuer has an entry (or entries)
-   in the path cache has priority.
-
-   Reverse Method:  Does not apply.
-
-   Justification:  Since the path cache only contains entries for
-   certificates that were previously validated back to a trust anchor,
-   it is more likely than not that the same or a new path may be built
-   from that point to the (or one of the) trust anchor(s).  For
-   certificates whose issuers are not found in the path cache, nothing
-   can be concluded.
-
-   NOTE: This method is not the same as the method named "Certificate
-   Was Previously Validated".  It is possible for this sorting method to
-   evaluate to true while the other method could evaluate to zero.
-
-3.5.11.  Issuer Found in the Application Protocol
-
-   May be used to eliminate certificates: No
-   Number of possible values: Binary
-   Components required:  Certification Path Cache
-
-   Forward Method:  If the issuer of a certificate sent by the target
-   through the application protocol (SSL/TLS, S/MIME, etc.), matches the
-   signer of the certificate you are looking at, then that certificate
-   has priority.
-
-   Reverse Method:  If the subject of a certificate matches the issuer
-   of a certificate sent by the target through the application protocol
-   (SSL/TLS, S/MIME, etc.), then that certificate has priority.
-
-   Justification:  The application protocol may contain certificates
-   that the sender considers valuable to certification path building,
-   and are more likely to lead to a path to the target certificate.
-
-3.5.12.  Matching Key Identifiers (KIDs)
-
-   May be used to eliminate certificates:  No
-   Number of possible values:  Three
-   Components required:  None
-
-   Forward Method:  Certificates whose subject key identifier (SKID)
-
-
-
-Cooper, et al.               Informational                     [Page 52]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   matches the current certificate's authority key identifier (AKID)
-   have highest priority.  Certificates without a SKID have medium
-   priority.  Certificates whose SKID does not match the current
-   certificate's AKID (if both are present) have zero priority.  If the
-   current certificate expresses the issuer name and serial number in
-   the AKID, certificates that match both these identifiers have highest
-   priority.  Certificates that match only the issuer name in the AKID
-   have medium priority.
-
-   Reverse Method:  Certificates whose AKID matches the current
-   certificate's SKID have highest priority.  Certificates without an
-   AKID have medium priority.  Certificates whose AKID does not match
-   the current certificate's SKID (if both are present) have zero
-   priority.  If the certificate expresses the issuer name and serial
-   number in the AKID, certificates that match both these identifiers in
-   the current certificate have highest priority.  Certificates that
-   match only the issuer name in the AKID have medium priority.
-
-   Justification:  Key Identifier (KID) matching is a very useful
-   mechanism for guiding path building (that is their purpose in the
-   certificate) and should therefore be assigned a heavy weight.
-
-   NOTE:  Although required to be present by [RFC3280], it is extremely
-   important that KIDs be used only as sorting criteria or as hints
-   during certification path building.  KIDs are not required to match
-   during certification path validation and cannot be used to eliminate
-   certificates.  This is of critical importance for interoperating
-   across domains and multi-vendor implementations where the KIDs may
-   not be calculated in the same fashion.
-
-3.5.13.  Policy Processing
-
-   May be used to eliminate certificates: Yes
-   Number of possible values: Three
-   Components required: None
-
-   Forward Method:  Certificates that satisfy Forward Policy Chaining
-   have priority.  (See Section 4 entitled "Forward Policy Chaining" for
-   details.)  If the caller provided an initial-policy-set and did not
-   set the initial-require-explicit flag, the weight of this sorting
-   method should be increased.  If the initial-require-explicit-policy
-   flag was set by the caller or by a certificate, certificates may be
-   eliminated.
-
-   Reverse Method:  Certificates that contain policies/policy mappings
-   that will allow successful policy processing of the path to this
-   point have priority.  If the caller provided an initial-policy-set
-   and did not set the initial-require-explicit flag, the weight of this
-
-
-
-Cooper, et al.               Informational                     [Page 53]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   sorting method should be increased.  Certificates may be eliminated
-   only if initial-require-explicit was set by the caller or if
-   require-explicit-policy was set by a certificate in the path to this
-   point.
-
-   Justification:  In a policy-using environment, certificates that
-   successfully propagate policies are more likely part of an intended
-   certification path than those that do not.
-
-   When building in the forward direction, it is always possible that a
-   certificate closer to the trust anchor will set the require-
-   explicit-policy indicator; so giving preference to certification
-   paths that propagate policies may increase the probability of finding
-   a valid path first.  If the caller (or a certificate in the current
-   path) has specified or set the initial-require-explicit-policy
-   indicator as true, this sorting method can also be used to eliminate
-   certificates when building in the forward direction.
-
-   If building in reverse, it is always possible that a certificate
-   farther along the path will set the require-explicit-policy
-   indicator; so giving preference to those certificates that propagate
-   policies will serve well in that case.  In the case where require-
-   explicit-policy is set by certificates or the caller, certificates
-   can be eliminated with this method.
-
-3.5.14.  Policies Intersect the Sought Policy Set
-
-   May be used to eliminate certificates: No
-   Number of possible values: Additive
-   Components required: None
-
-   Forward Method:  Certificates that assert policies found in the
-   initial-acceptable-policy-set have priority.  Each additional
-   matching policy could have an additive affect on the total score.
-
-   Alternately, this could be binary; it matches 1 or more, or matches
-   none.
-
-   Reverse Method:  Certificates that assert policies found in the
-   target certificate or map policies to those found in the target
-   certificate have priority.  Each additional matching policy could
-   have an additive affect on the total score.  Alternately, this could
-   be binary; it matches 1 or more, or matches none.
-
-   Justification:  In the forward direction, as the path draws near to
-   the trust anchor in a cross-certified environment, the policies
-   asserted in the CA certificates will match those in the caller's
-   domain.  Since the initial acceptable policy set is specified in the
-
-
-
-Cooper, et al.               Informational                     [Page 54]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   caller's domain, matches may indicate that the path building is
-   drawing nearer to a desired trust anchor.  In the reverse direction,
-   finding policies that match those of the target certificate may
-   indicate that the path is drawing near to the target's domain.
-
-3.5.15.  Endpoint Distinguished Name (DN) Matching
-
-   May be used to eliminate certificates: No
-   Number of possible values: Binary
-   Components required: None
-
-   Forward Method:  Certificates whose issuer exactly matches a trust
-   anchor subject DN have priority.
-
-   Reverse Method:  Certificates whose subject exactly matches the
-   target entity issuer DN have priority.
-
-   Justification:  In the forward direction, if a certificate's issuer
-   DN matches a trust anchor's DN [X.501], then it may complete the
-   path.  In the reverse direction, if the certificate's subject DN
-   matches the issuer DN of the target certificate, it may be the last
-   certificate required to complete the path.
-
-3.5.16.  Relative Distinguished Name (RDN) Matching
-
-   May be used to eliminate certificates: No
-   Number of possible values: Sliding Scale
-   Components required: None
-
-   Forward Method:  Certificates that match more ordered RDNs between
-   the issuer DN and a trust anchor DN have priority.  When all the RDNs
-   match, this yields the highest priority.
-
-   Reverse Method: Certificates with subject DNs that match more RDNs
-   with the target's issuer DN have higher priority.  When all the RDNs
-   match, this yields the highest priority.
-
-   Justification:  In PKIs the DNs are frequently constructed in a tree
-   like fashion.  Higher numbers of matches may indicate that the trust
-   anchor is to be found in that direction within the tree.  Note that
-   in the case where all the RDNs match [X.501], this sorting method
-   appears to mirror the preceding one.  However, this sorting method
-   should be capable of producing a 100% weight even if the issuer DN
-   has more RDNs than the trust anchor.  The Issuer DN need only contain
-   all the RDNs (in order) of the trust anchor.
-
-   NOTE: In the case where all RDNs match, this sorting method mirrors
-   the functionality of the preceding one.  This allows for partial
-
-
-
-Cooper, et al.               Informational                     [Page 55]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   matches to be weighted differently from exact matches.  Additionally,
-   this method can require a lot of processing if many trust anchors are
-   present.
-
-3.5.17.  Certificates are Retrieved from cACertificate Directory
-         Attribute
-
-   May be used to eliminate certificates: No
-   Number of possible values: Binary
-   Components required: Certificate Cache with flags for the attribute
-   from where the certificate was retrieved and Remote Certificate
-   Storage/Retrieval using a directory
-
-   Forward Method:   Certificates retrieved from the cACertificate
-   directory attribute have priority over certificates retrieved from
-   the crossCertificatePair attribute. (See [RFC2587].)
-
-   Reverse Method:  Does not apply.
-
-   Justification:  The cACertificate directory attribute contains
-   certificates issued from local sources and self issued certificates.
-   By using the cACertificate directory attribute before the
-   crossCertificatePair attribute, the path-building algorithm will
-   (depending on the local PKI configuration) tend to demonstrate a
-   preference for the local PKI before venturing to external cross-
-   certified PKIs.  Most of today's PKI applications spend most of their
-   time processing information from the local (user's own) PKI, and the
-   local PKI is usually very efficient to traverse due to proximity and
-   network speed.
-
-3.5.18.  Consistent Public Key and Signature Algorithms
-
-   May be used to eliminate certificates: Yes
-   Number of possible values: Binary
-   Components required: None
-
-   Forward Method:  If the public key in the issuer certificate matches
-   the algorithm used to sign the subject certificate, then it has
-   priority.  (Certificates with unmatched public key and signature
-   algorithms may be eliminated.)
-
-   Reverse Method:  If the public key in the current certificate matches
-   the algorithm used to sign the subject certificate, then it has
-   priority.  (Certificates with unmatched public key and signature
-   algorithms may be eliminated.)
-
-   Justification:  Since the public key and signature algorithms are not
-   consistent, the signature on the subject certificate will not verify
-
-
-
-Cooper, et al.               Informational                     [Page 56]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   successfully.  For example, if the issuer certificate contains an RSA
-   public key, then it could not have issued a subject certificate
-   signed with the DSA-with-SHA-1 algorithm.
-
-3.5.19.  Similar Issuer and Subject Names
-
-   May be used to eliminate certificates:  No
-   Number of possible values:  Sliding Scale
-   Components required:  None
-
-   Forward Method:  Certificates encountered with a subject DN that
-   matches more RDNs with the issuer DN of the target certificate have
-   priority.
-
-   Reverse Method:  Same as forward.
-
-   Justification:  As it is generally more efficient to search the local
-   domain prior to branching to cross-certified domains, using
-   certificates with similar names first tends to make a more efficient
-   path builder.  Cross-certificates issued from external domains will
-   generally match fewer RDNs (if any), whereas certificates in the
-   local domain will frequently match multiple RDNs.
-
-3.5.20.  Certificates in the Certification Cache
-
-   May be used to eliminate certificates:  No
-   Number of possible values:  Three
-   Components required:  Local Certificate Cache and Remote Certificate
-   Storage/Retrieval (e.g., LDAP directory as the repository)
-
-   Forward Method:  A certificate whose issuer certificate is present in
-   the certificate cache and populated with certificates has higher
-   priority.  A certificate whose issuer's entry is fully populated with
-   current data (all certificate attributes have been searched within
-   the timeout period) has higher priority.
-
-   Reverse Method:  If the subject of a certificate is present in the
-   certificate cache and populated with certificates, then it has higher
-   priority.  If the entry is fully populated with current data (all
-   certificate attributes have been searched within the timeout period)
-   then it has higher priority.
-
-   Justification:  The presence of required directory values populated
-   in the cache increases the likelihood that all the required
-   certificates and CRLs needed to complete the path from this
-   certificate to the trust anchor (or target if building in reverse)
-   are present in the cache from a prior path being developed, thereby
-
-
-
-
-Cooper, et al.               Informational                     [Page 57]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   eliminating the need for directory access to complete the path.  In
-   the event no path can be found, the performance cost is low since the
-   certificates were likely not retrieved from the network.
-
-3.5.21.  Current CRL Found in Local Cache
-
-   May be used to eliminate certificates: No
-   Number of possible values:  Binary
-   Components Required:  CRL Cache
-
-   Forward Method:  Certificates have priority if the issuer's CRL entry
-   exists and is populated with current data in the CRL cache.
-
-   Reverse Method:  Certificates have priority if the subject's CRL
-   entry exists and is populated with current data in the CRL cache.
-
-   Justification:  If revocation is checked only after a complete path
-   has been found, this indicates that a complete path has been found
-   through this entity at some past point, so a path still likely
-   exists.  This also helps reduce remote retrievals until necessary.
-
-3.6.  Certificate Sorting Methods for Revocation Signer Certification
-      Paths
-
-   Unless using a locally-configured OCSP responder or some other
-   locally-configured trusted revocation status service, certificate
-   revocation information is expected to be provided by the PKI that
-   issued the certificate.  It follows that when building a
-   certification path for a Revocation Signer certificate, it is
-   desirable to confine the building algorithm to the PKI that issued
-   the certificate.  The following sorting methods seek to order
-   possible paths so that the intended Revocation Signer certification
-   path is found first.
-
-   These sorting methods are not intended to be used in lieu of the ones
-   described in the previous section; they are most effective when used
-   in conjunction with those in Section 3.5. Some sorting criteria below
-   have identical names as those in the preceding section.  This
-   indicates that the sorting criteria described in the preceding
-   section are modified slightly when building the Revocation Signer
-   certification path.
-
-3.6.1.  Identical Trust Anchors
-
-   May be used to eliminate certificates: No
-   Number of possible values: Binary
-   Components required: Is-revocation-signer indicator and the
-   Certification Authority's trust anchor
-
-
-
-Cooper, et al.               Informational                     [Page 58]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Forward Method:  Not applicable.
-
-   Reverse Method:  Path building should begin from the same trust
-   anchor used to validate the Certification Authority before trying any
-   other trust anchors.  If any trust anchors exist with a different
-   public key but an identical subject DN to that of the Certification
-   Authority's trust anchor, they should be tried prior to those with
-   mismatched names.
-
-   Justification:  The revocation information for a given certificate
-   should be produced by the PKI that issues the certificate.
-   Therefore, building a path from a different trust anchor than the
-   Certification Authority's is not desirable.
-
-3.6.2.  Endpoint Distinguished Name (DN) Matching
-
-   May be used to eliminate certificates: No
-   Number of possible values: Binary
-   Components required: Is-revocation-signer indicator and the
-   Certification Authority's trust anchor
-
-   Forward Method:  Operates identically to the sorting method described
-   in 3.5.15, except that instead of performing the matching against all
-   trust anchors, the DN matching is performed only against the trust
-   anchor DN used to validate the CA certificate.
-
-   Reverse Method:  No change for Revocation Signer's certification
-   path.
-
-   Justification:  The revocation information for a given certificate
-   should be produced by the PKI that issues the certificate.
-   Therefore, building a path to a different trust anchor than the CA's
-   is not desirable.  This sorting method helps to guide forward
-   direction path building toward the trust anchor used to validate the
-   CA certificate.
-
-3.6.3.  Relative Distinguished Name (RDN) Matching
-
-   May be used to eliminate certificates: No
-   Number of possible values: Sliding Scale
-   Components required: Is-revocation-signer indicator and the
-   Certification Authority's trust anchor
-
-   Forward Method:  Operates identically to the sorting method described
-   in 3.5.16 except that instead of performing the RDN matching against
-   all trust anchors, the matching is performed only against the trust
-   anchor DN used to validate the CA certificate.
-
-
-
-
-Cooper, et al.               Informational                     [Page 59]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Reverse Method:  No change for Revocation Signer's certification
-   path.
-
-   Justification:  The revocation information for a given certificate
-   should be produced by the PKI that issues the certificate.
-   Therefore, building a path to a different trust anchor than the CA's
-   is not desirable.  This sorting method helps to guide forward
-   direction path building toward the trust anchor used to validate the
-   CA certificate.
-
-3.6.4.  Identical Intermediate Names
-
-   May be used to eliminate certificates: No
-   Number of possible values: Binary
-   Components required: Is-revocation-signer indicator and the
-   Certification Authority's complete certification path
-
-   Forward Method:  If the issuer DN in the certificate matches the
-   issuer DN of a certificate in the Certification Authority's path, it
-   has higher priority.
-
-   Reverse Method:  If the subject DN in the certificate matches the
-   subject DN of a certificate in the Certification Authority's path, it
-   has higher priority.
-
-   Justification:  Following the same path as the Certificate should
-   deter the path-building algorithm from wandering in an inappropriate
-   direction.  Note that this sorting method is indifferent to whether
-   the certificate is self-issued.  This is beneficial in this situation
-   because it would be undesirable to lower the priority of a re-key
-   certificate.
-
-4.  Forward Policy Chaining
-
-   It is tempting to jump to the conclusion that certificate policies
-   offer little assistance to path building when building from the
-   target certificate.  It's easy to understand the "validate as you go"
-   approach from the trust anchor, and much less obvious that any value
-   can be derived in the other direction.  However, since policy
-   validation consists of the intersection of the issuer policy set with
-   the subject policy set and the mapping of policies from the issuer
-   set to the subject set, policy validation can be done while building
-   a path in the forward direction as well as the reverse.  It is simply
-   a matter of reversing the procedure.  That is not to say this is as
-   ideal as policy validation when building from the trust anchor, but
-   it does offer a method that can be used to mostly eliminate what has
-   long been considered a weakness inherent to building in the forward
-   (from the target certificate) direction.
-
-
-
-Cooper, et al.               Informational                     [Page 60]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-4.1.  Simple Intersection
-
-   The most basic form of policy processing is the intersection of the
-   policy sets from the first CA certificate through the target
-   certificate.  Fortunately, the intersection of policy sets will
-   always yield the same final set regardless of the order of
-   intersection.  This allows processing of policy set intersections in
-   either direction.  For example, if the trust anchor issues a CA
-   certificate (A) with policies {X,Y,Z}, and that CA issues another CA
-   certificate (B) with policies {X,Y}, and CA B then issues a third CA
-   certificate (C) with policy set {Y,G}, one normally calculates the
-   policy set from the trust anchor as follows:
-
-   1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
-
-   2) Intersect that result, {X,Y} with C{Y,G} to yield the final set
-      {Y}
-
-   Now it has been shown that certificate C is good for policy Y.
-
-   The other direction is exactly the same procedure, only in reverse:
-
-   1) Intersect C{Y,G} with B{X,Y} to yield the set {Y}
-
-   2) Intersect that result, {Y} with A{X,Y,Z} to yield the final set
-      {Y}
-
-   Just like in the reverse direction, it has been shown that
-   certificate C is good for policy Y, but this time in the forward
-   direction.
-
-   When building in the forward direction, policy processing is handled
-   much like it is in reverse -- the software lends preference to
-   certificates that propagate policies.  Neither approach guarantees
-   that a path with valid policies will be found, but rather both
-   approaches help guide the path in the direction it should go in order
-   for the policies to propagate.
-
-   If the caller has supplied an initial-acceptable-policy set, there is
-   less value in using it when building in the forward direction unless
-   the caller also set inhibit-policy-mapping.  In that case, the path
-   builder can further constrain the path building to propagating
-   policies that exist in the initial-acceptable-policy-set.  However,
-   even if the inhibit-policy-mapping is not set, the initial-policy-set
-   can still be used to guide the path building toward the desired trust
-   anchor.
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 61]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-4.2.  Policy Mapping
-
-   When a CA issues a certificate into another domain, an environment
-   with disparate policy identifiers to its own, the CA may make use of
-   policy mappings to map equivalence from the local domain's policy to
-   the non-local domain's policy.  If in the prior example, A had
-   included a policy mapping that mapped X to G in the certificate it
-   issued to B, C would be good for X and Y:
-
-   1) Intersect A{X,Y,Z} with B{X,Y} to yield the set {X,Y}
-
-   2) Process Policy Mappings in B's certificate (X maps to G) to yield
-      {G,Y} (same as {Y,G})
-
-   3) Intersect that result, {G,Y} with C{Y,G} to yield the final set
-      {G,Y}
-
-   Since policies are always expressed in the relying party's domain,
-   the certificate C is said to be good for {X, Y}, not {Y, G}.  This is
-   because "G" doesn't mean anything in the context of the trust anchor
-   that issued A without the policy mapping.
-
-   When building in the forward direction, policies can be "unmapped" by
-   reversing the mapping procedure.  This procedure is limited by one
-   important aspect: if policy mapping has occurred in the forward
-   direction, there is no mechanism by which it can be known in advance
-   whether or not a future addition to the current path will invalidate
-   the policy chain (assuming one exists) by setting inhibit-policy-
-   mapping.  Fortunately, it is uncommon practice to set this flag.  The
-   following is the procedure for processing policy mapping in the
-   forward direction:
-
-   1) Begin with C's policy set {Y,G}
-
-   2) Apply the policy mapping in B's certificate (X maps to G) in
-      reverse to yield {Y,X} (same as {X,Y})
-
-   3) Intersect the result {X,Y} with B{X,Y} to yield the set {X,Y}
-
-   4) Intersect that result, {X,Y}, with A{X,Y,Z} to yield the final set
-      {X,Y}
-
-   Just like in the reverse direction, it is determined in the forward
-   direction that certificate C is good for policies {X,Y}.  If during
-   this procedure, an inhibit-policy-mapping flag was encountered, what
-   should be done?  This is reasonably easy to keep track of as well.
-   The software simply maintains a flag on any policies that were
-   propagated as a result of a mapping; just a simple Boolean kept with
-
-
-
-Cooper, et al.               Informational                     [Page 62]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   the policies in the set.  Imagine now that the certificate issued to
-   A has the inhibit-policy-mapping constraint expressed with a skip
-   certificates value of zero.
-
-   1) Begin with C's policy set {Y,G}
-
-   2) Apply the policy mapping in B's certificate and mark X as
-      resulting from a mapping. (X maps to G) in reverse to yield {Y,Xm}
-      (same as {Xm,Y})
-
-   3) Intersect the result {Xm,Y} with B{X,Y} to yield the set {Xm,Y}
-
-   4) A's certificate expresses the inhibit policy mapping constraint,
-      so eliminate any policies in the current set that were propagated
-      due to mapping (which is Xm) to yield {Y}
-
-   5) Intersect that result, {Y} with A{X,Y,Z} to yield the final set
-      {Y}
-
-   If in our example, the policy set had gone to empty at any point (and
-   require-explicit-policy was set), the path building would back up and
-   try to traverse another branch of the tree.  This is analogous to the
-   path-building functionality utilized in the reverse direction when
-   the policy set goes to empty.
-
-4.3.  Assigning Scores for Forward Policy Chaining
-
-   Assuming the path-building module is maintaining the current forward
-   policy set, weights may be assigned using the following procedure:
-
-   1) For each CA certificate being scored:
-
-      a. Copy the current forward policy set.
-
-      b. Process policy mappings in the CA certificate in order to
-         "un-map" policies, if any.
-
-      c. Intersect the resulting set with CA certificate's policies.
-
-   The larger the policy set yielded, the larger the score for that CA
-   certificate.
-
-   2) If an initial acceptable set was supplied, intersect this set with
-      the resulting set for each CA certificate from (1).
-
-   The larger the resultant set, the higher the score is for this
-   certificate.
-
-
-
-
-Cooper, et al.               Informational                     [Page 63]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   Other scoring schemes may work better if the operating environment
-   dictates.
-
-5.  Avoiding Path-Building Errors
-
-   This section defines some errors that may occur during the path-
-   building process, as well as ways to avoid these errors when
-   developing path-building functions.
-
-5.1.  Dead Ends
-
-   When building certification paths in a non-hierarchical PKI
-   structure, a simple path-building algorithm could fail prematurely
-   without finding an existing path due to a "dead end".  Consider the
-   example in Figure 14.
-
-            +----+      +---+
-            | TA |      | Z |
-            +----+      +---+
-               |          |
-               |          |
-               V          V
-             +---+      +---+
-             | C |<-----| Y |
-             +---+      +---+
-               |
-               |
-               V
-             +--------+
-             | Target |
-             +--------+
-
-      Figure 14 - Dead End Example
-
-   Note that in the example, C has two certificates: one issued by Y,
-   and the other issued by the Trust Anchor.  Suppose that a simple
-   "find issuer" algorithm is used, and the order in which the path
-   builder found the certificates was Target(C), C(Y), Y(Z), Z(Z).  In
-   this case, Z has no certificates issued by any other entities, and so
-   the simplistic path-building process stops.  Since Z is not the
-   relying party's trust anchor, the certification path is not complete,
-   and will not validate.  This example shows that in anything but the
-   simplest PKI structure, additional path-building logic will need to
-   handle the cases in which entities are issued multiple certificates
-   from different issuers.  The path-building algorithm will also need
-   to have the ability to traverse back up the decision tree and try
-   another path in order to be robust.
-
-
-
-
-Cooper, et al.               Informational                     [Page 64]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-5.2.  Loop Detection
-
-   In a non-hierarchical PKI structure, a path-building algorithm may
-   become caught in a loop without finding an existing path.  Consider
-   the example below:
-
-             +----+
-             | TA |
-             +----+
-               |
-               |
-             +---+      +---+
-             | A |    ->| Z |
-             +---+   /  +---+
-               |    /     |
-               |   /      |
-               V  /       V
-             +---+      +---+
-             | B |<-----| Y |
-             +---+      +---+
-               |
-               |
-               V
-             +--------+
-             | Target |
-             +--------+
-
-      Figure 15 - Loop Example
-
-   Let us suppose that in this example the simplest "find issuer"
-   algorithm is used, and the order in which certificates are retrieved
-   is Target(B), B(Y), Y(Z), Z(B), B(Y), Y(Z), Z(B), B(Y), ... A loop
-   has formed that will cause the correct path (Target, B, A) to never
-   be found.  The certificate processing system will need to recognize
-   loops created by duplicate certificates (which are prohibited in a
-   path by [X.509]) before they form to allow the certification path-
-   building process to continue and find valid paths.  The authors of
-   this document recommend that the loop detection not only detect the
-   repetition of a certificate in the path, but also detect the presence
-   of the same subject name / subject alternative name/ subject public
-   key combination occurring twice in the path.  A name/key pair should
-   only need to appear once in the path.  (See Section 2.4.2 for more
-   information on the reasoning behind this recommendation.)
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 65]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-5.3.  Use of Key Identifiers
-
-   Inconsistent and/or incompatible approaches to computing the subject
-   key identifier and authority key identifier in public key
-   certificates can cause failures in certification path-building
-   algorithms that use those fields to identify certificates, even
-   though otherwise valid certification paths may exist.  Path-building
-   implementations should use existing key identifiers and not attempt
-   to re-compute subject key identifiers.  It is extremely important
-   that Key Identifiers be used only as sorting criteria or hints.  KIDs
-   are not required to match during certification path validation and
-   cannot be used to eliminate certificates.  This is of critical
-   importance for interoperating across domains and multi-vendor
-   implementations where the KIDs may not be calculated in the same
-   fashion.
-
-   Path-building and processing implementations should not rely on the
-   form of authority key identifier that uses the authority DN and
-   serial number as a restrictive matching rule, because cross-
-   certification can lead to this value not being matched by the cross-
-   certificates.
-
-5.4.  Distinguished Name Encoding
-
-   Certification path-building software should not rely on DNs being
-   encoded as PrintableString.  Although frequently encoded as
-   PrintableString, DNs may also appear as other types, including
-   BMPString or UTF8String.  As a result, software systems that are
-   unable to process BMPString and UTF8String encoded DNs may be unable
-   to build and validate some certification paths.
-
-   Furthermore, [RFC3280] compliant certificates are required to encode
-   DNs as UTF8String as of January 1, 2004.  Certification path-building
-   software should be prepared to handle "name rollover" certificates as
-   described in [RFC3280].  Note that the inclusion of a "name rollover"
-   certificate in a certification path does not constitute repetition of
-   a DN and key.  Implementations that include the "name rollover"
-   certificate in the path should ensure that the DNs with differing
-   encoding are regarded as dissimilar.  (Implementations may instead
-   handle matching DNs of different encodings and will therefore not
-   need to include "name rollover" certificates in the path.)
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 66]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-6.  Retrieval Methods
-
-   Building a certification path requires the availability of the
-   certificates and CRLs that make up the path.  There are many
-   different methods for obtaining these certificates and CRLs.  This
-   section lists a few of the common ways to perform this retrieval, as
-   well as some suggested approaches for improving performance.  This
-   section is not intended to provide a complete reference for
-   certificate and CRL retrieval methods or optimizations that would be
-   useful in certification path building.
-
-6.1.  Directories Using LDAP
-
-   Most applications utilize the Lightweight Directory Access Protocol
-   (LDAP) when retrieving data from directories following the X.500
-   model.  Applications may encounter directories which support either
-   LDAP v2 [RFC1777] or LDAP v3 [RFC3377].
-
-   The LDAP v3 specification defines one attribute retrieval option, the
-   "binary" option.  When specified in an LDAP retrieval request, this
-   option was intended to force the directory to ignore any string-based
-   representations of BER-encoded directory information, and send the
-   requested attribute(s) in BER format.  Since all PKI objects of
-   concern are BER-encoded objects, the "binary" option should be used.
-   However, not all directories support the "binary" option.  Therefore,
-   applications should be capable of requesting attributes with and
-   without the "binary" option.  For example, if an application wishes
-   to retrieve the userCertificate attribute, the application should
-   request "userCertificate;binary".  If the desired information is not
-   returned, robust implementations may opt to request "userCertificate"
-   as well.
-
-   The following attributes should be considered by PKI application
-   developers when performing certificate retrieval from LDAP sources:
-
-   userCertificate: contains certificates issued by one or more
-      certification authorities with a subject DN that matches that of
-      the directory entry.  This is a multi-valued attribute and all
-      values should be received and considered during path building.
-      Although typically it is expected that only end entity
-      certificates will be stored in this attribute, (e.g., this is the
-      attribute an application would request to find a person's
-      encryption certificate) implementers may opt to search this
-      attribute when looking in CA entries to make their path builder
-      more robust.  If it is empty, the overhead added by including this
-      attribute when already requesting one or both of the two below is
-      marginal.
-
-
-
-
-Cooper, et al.               Informational                     [Page 67]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   cACertificate: contains self-issued certificates (if any) and any
-      certificates issued to this certification authority by other
-      certification authorities in the same realm.  (Realm is dependent
-      upon local policy.)  This is a multi-valued attribute and all
-      values should be received and considered during path building.
-
-   crossCertificatePair: in conformant implementations, the
-      crossCertificatePair is used to contain all, except self-issued
-      certificates issued to this certification authority, as well as
-      certificates issued by this certification authority to other
-      certification authorities.  Each attribute value is a structure
-      containing two elements.  The issuedToThisCA element contains
-      certificates issued to this certification authority by other
-      certification authorities.  The issuedByThisCA element contains
-      certificates issued by this certification authority to other
-      certification authorities.  Both elements of the
-      crossCertificatePair are labeled optional in the ASN.1 definition.
-      If both elements are present in a single value, the issuer name in
-      one certificate is required to match the subject name in the other
-      and vice versa, and the subject public key in one certificate
-      shall be capable of verifying the digital signature on the other
-      certificate and vice versa.  As this technology has evolved,
-      different standards have had differing requirements on where
-      information could be found.  For example, the LDAP v2 schema
-      [RFC2587] states that the issuedToThisCA (once called 'forward')
-      element of the crossCertificatePair attribute is mandatory and the
-      issuedByThisCA (once called 'reverse') element is optional.  In
-      contrast, Section 11.2.3 of [X.509] requires the issuedByThisCA
-      element to be present if the CA issues a certificate to another CA
-      if the subject is not a subordinate CA in a hierarchy.  Conformant
-      directories behave as required by [X.509], but robust path-
-      building implementations may want to retrieve all certificates
-      from the cACertificate and crossCertificatePair attributes to
-      ensure all possible certification authority certificates are
-      obtained.
-
-   certificateRevocationList: the certificateRevocationList attribute
-      contains a certificate revocation list (CRL).  A CRL is defined in
-      [RFC3280] as a time stamped list identifying revoked certificates,
-      which is signed by a CA or CRL issuer and made freely available in
-      a public repository.  Each revoked certificate is identified in a
-      CRL by its certificate serial number.  There may be one or more
-      CRLs in this attribute, and the values should be processed in
-      accordance with [RFC3280].
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 68]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   authorityRevocationList: the authorityRevocationList attribute also
-      contains CRLs.  These CRLs contain revocation information
-      regarding certificates issued to other CAs.  There may be one or
-      more CRLs in this attribute, and the values should be processed in
-      accordance with [RFC3280].
-
-   Certification path processing systems that plan to interoperate with
-   varying PKI structures and directory designs should at a minimum be
-   able to retrieve and process the userCertificate, cACertificate,
-   crossCertificatePair, certificateRevocationList, and
-   authorityRevocationList attributes from directory entries.
-
-6.2.  Certificate Store Access via HTTP
-
-   Another possible method of certificate retrieval is using HTTP as an
-   interface mechanism for retrieving certificates and CRLs from PKI
-   repositories.  A current PKIX document [CERTSTORE] provides a
-   protocol for a general-purpose interface capability for retrieving
-   certificates and CRLs from PKI repositories.  Since the [CERTSTORE]
-   document is a work in progress as of the writing of this document, no
-   details are given here on how to utilize this mechanism for
-   certificate and CRL retrieval.  Instead, refer to the [CERTSTORE]
-   document or its current version.  Certification path processing
-   systems may wish to implement support for this interface capability,
-   especially if they will be used in environments that will provide
-   HTTP-based access to certificates and CRLs.
-
-6.3.  Authority Information Access
-
-   The authority information access (AIA) extension, defined within
-   [RFC3280], indicates how to access CA information and services for
-   the issuer of the certificate in which the extension appears.  If a
-   certificate with an AIA extension contains an accessMethod defined
-   with the id-ad-caIssuers OID, the AIA may be used to retrieve one or
-   more certificates for the CA that issued the certificate containing
-   the AIA extension.  The AIA will provide a uniform resource
-   identifier (URI) [RFC3986] when certificates can be retrieved via
-   LDAP, HTTP, or FTP.  The AIA will provide a directoryName when
-   certificates can be retrieved via directory access protocol (DAP).
-   The AIA will provide an rfc822Name when certificates can be retrieved
-   via electronic mail.  Additionally, the AIA may specify the location
-   of an OCSP [RFC2560] responder that is able to provide revocation
-   information for the certificate.
-
-   If present, AIA may provide forward path-building implementations
-   with a direct link to a certificate for the issuer of a given
-   certificate.  Therefore, implementations may wish to provide support
-   for decoding the AIA extension and processing the LDAP, HTTP, FTP,
-
-
-
-Cooper, et al.               Informational                     [Page 69]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   DAP, or e-mail locators.  Support for AIA is optional; [RFC3280]
-   compliant implementations are not required to populate the AIA
-   extension.  However, implementers of path-building and validation
-   modules are strongly encouraged to support AIA, especially the HTTP
-   transport; this will provide for usability and interoperability with
-   many existing PKIs.
-
-6.4.  Subject Information Access
-
-   The subject information access (SIA) extension, defined within
-   [RFC3280], indicates how to access information and services for the
-   subject of the certificate in which the extension appears.  If a
-   certificate with an SIA extension contains an accessMethod defined
-   with the id-ad-caRepository OID, the SIA may be used to locate one or
-   more certificates (and possibly CRLs) for entities issued
-   certificates by the subject.  The SIA will provide a uniform resource
-   identifier (URI) [RFC3986] when data can be retrieved via LDAP, HTTP,
-   or FTP.  The SIA will provide a directoryName when data can be
-   retrieved via directory access protocol (DAP).  The SIA will provide
-   an rfc822Name when data can be retrieved via electronic mail.
-
-   If present, the SIA extension may provide reverse path-building
-   implementations with the certificates required to continue building
-   the path.  Therefore, implementations may wish to provide support for
-   decoding the SIA extension and processing the LDAP, HTTP, FTP, DAP,
-   or e-mail locators.  Support for SIA is optional; [RFC3280] compliant
-   implementations are not required to populate the SIA extension.
-   However, implementers of path-building and validation modules are
-   strongly encouraged to support SIA, especially the HTTP transport;
-   this will provide for usability and interoperability with many
-   existing PKIs.
-
-6.5.  CRL Distribution Points
-
-   The CRL distribution points (CRLDP) extension, defined within
-   [RFC3280], indicates how to access CRL information.  If a CRLDP
-   extension appears within a certificate, the CRL(s) to which the CRLDP
-   refer are generally the CRLs that would contain revocation
-   information for the certificate.  The CRLDP extension may point to
-   multiple distribution points from which the CRL information may be
-   obtained; the certificate processing system should process the CRLDP
-   extension in accordance with [RFC3280].  The most common distribution
-   points contain URIs from which the appropriate CRL may be downloaded,
-   and directory names, which can be queried in a directory to retrieve
-   the CRL attributes from the corresponding entry.
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 70]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   If present, CRLDP can provide certificate processing implementations
-   with a link to CRL information for a given certificate.  Therefore,
-   implementations may wish to provide support for decoding the CRLDP
-   extension and using the information to retrieve CRLs.  Support for
-   CRLDP is optional and [RFC3280] compliant implementations need not
-   populate the CRLDP extension.  However, implementers of path-building
-   and validation modules are strongly encouraged to support CRLDPs.  At
-   a minimum, developers are encouraged to consider supporting the LDAP
-   and HTTP transports; this will provide for interoperability across a
-   wide range of existing PKIs.
-
-6.6.  Data Obtained via Application Protocol
-
-   Many application protocols, such as SSL/TLS and S/MIME, allow one
-   party to provide certificates and CRLs to another.  Data provided in
-   this method is generally very valuable to path-building software
-   (will provide direction toward valid paths), and should be stored and
-   used accordingly.  Note: self-signed certificates obtained via
-   application protocol are not trustworthy; implementations should only
-   consider the relying party's trust anchors when building paths.
-
-6.7.  Proprietary Mechanisms
-
-   Some certificate issuing systems and certificate processing systems
-   may utilize proprietary retrieval mechanisms, such as network mapped
-   drives, databases, or other methods that are not directly referenced
-   via the IETF standards.  Certificate processing systems may wish to
-   support other proprietary mechanisms, but should only do so in
-   addition to supporting standard retrieval mechanisms such as LDAP,
-   AIA, and CRLDP (unless functioning in a closed environment).
-
-7.  Improving Retrieval Performance
-
-   Retrieval performance can be improved through a few different
-   mechanisms, including the use of caches and setting a specific
-   retrieval order.  This section discusses a few methods by which the
-   performance of a certificate processing system may be improved during
-   the retrieval of PKI objects.  Certificate processing systems that
-   are consistently very slow during processing will be disliked by
-   users and will be slow to be adopted into organizations.  Certificate
-   processing systems are encouraged to do whatever possible to reduce
-   the delays associated with requesting and retrieving data from
-   external sources.
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 71]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-7.1.  Caching
-
-   Certificate processing systems operating in a non-hierarchical PKI
-   will often need to retrieve certificates and certificate revocation
-   lists (CRLs) from a source outside the application protocol.
-   Typically, these objects are retrieved from an X.500 or LDAP
-   repository, an Internet URI [RFC3986], or some other non-local
-   source.  Due to the delays associated with establishing connections
-   as well as network transfers, certificate processing systems ought to
-   be as efficient as possible when retrieving data from external
-   sources.  Perhaps the best way to improve retrieval efficiency is by
-   using a caching mechanism.  Certificate processing systems can cache
-   data retrieved from external sources for some period of time, but not
-   to exceed the useful period of the data (i.e., an expired certificate
-   need not be cached).  Although this comes at a cost of increased
-   memory/disk consumption by the system, the cost and performance
-   benefit of reducing network transmissions is great.  Also, CRLs are
-   often issued and available in advance of the nextUpdate date in the
-   CRL.  Implementations may wish to obtain these "fresher" CRLs before
-   the nextUpdate date has passed.
-
-   There are a number of different ways in which caching can be
-   implemented; the specifics of these methods can be used as
-   distinguishing characteristics between certificate processing
-   systems.  However, some things that implementers may wish to consider
-   when developing caching systems are as follows:
-
-      - If PKI objects are cached, the certification path-building
-        mechanism should be able to examine and retrieve from the cache
-        during path building.  This will allow the certificate
-        processing system to find or eliminate one or more paths quickly
-        without requiring external contact with a directory or other
-        retrieval mechanism.
-
-      - Sharing caches between multiple users (via a local area network
-        or LAN) may be useful if many users in one organization
-        consistently perform PKI operations with another organization.
-
-      - Caching not only PKI objects (such as certificates and CRLs) but
-        also relationships between PKI objects (storing a link between a
-        certificate and the issuer's certificate) may be useful.  This
-        linking may not always lead to the most correct or best
-        relationship, but could represent a linking that worked in
-        another scenario.
-
-      - Previously built paths and partial paths are quite useful to
-        cache, because they will provide information on previous
-        successes or failures.  Additionally, if the cache is safe from
-
-
-
-Cooper, et al.               Informational                     [Page 72]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-        unauthorized modifications, caching validation and signature
-        checking status for certificates, CRLs, and paths can also be
-        stored.
-
-7.2.  Retrieval Order
-
-   To optimize efficiency, certificate processing systems are encouraged
-   to also consider the order in which different PKI objects are
-   retrieved, as well as the mechanism from which they are retrieved.
-   If caching is utilized, the caches can be consulted for PKI objects
-   before attempting other retrieval mechanisms.  If multiple caches are
-   present (such as local disk and network), the caches can be consulted
-   in the order in which they can be expected to return their result
-   from fastest to slowest.  For example, if a certificate processing
-   system wishes to retrieve a certificate with a particular subject DN,
-   the system might first consult the local cache, then the network
-   cache, and then attempt directory retrieval.  The specifics of the
-   types of retrieval mechanisms and their relative costs are left to
-   the implementer.
-
-   In addition to ordering retrieval mechanisms, the certificate
-   processing system ought to order the relative merits of the different
-   external sources from which a PKI object can be retrieved.  If the
-   AIA is present within a certificate, with a URI [RFC3986] for the
-   issuer's certificate, the certificate processing system (if able) may
-   wish to attempt to retrieve the certificate first from local cache
-   and then by using that URI (because it is expected to point directly
-   to the desired certificate) before attempting to retrieve the
-   certificates that may exist within a directory.
-
-   If a directory is being consulted, it may be desirable to retrieve
-   attributes in a particular order.  A highly cross-certified PKI
-   structure will lead to multiple possibilities for certification
-   paths, which may mean multiple validation attempts before a
-   successful path is retrieved.  Therefore, cACertificate and
-   userCertificate (which typically contain certificates from within the
-   same 'realm') could be consulted before attempting to retrieve the
-   crossCertificatePair values for an entry.  Alternately, all three
-   attributes could be retrieved in one query, but cross-certificates
-   then tagged as such and used only after exhausting the possibilities
-   from the cACertificate attribute.  The best approach will depend on
-   the nature of the application and PKI environment.
-
-7.3.  Parallel Fetching and Prefetching
-
-   Much of this document has focused on a path-building algorithm that
-   minimizes the performance impact of network retrievals, by preventing
-   those retrievals and utilization of caches.  Another way to improve
-
-
-
-Cooper, et al.               Informational                     [Page 73]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   performance would be to allow network retrievals to be performed in
-   advance (prefetching) or at the same time that other operations are
-   performed (parallel fetching).  For example, if an email application
-   receives a signed email message, it could download the required
-   certificates and CRLs prior to the recipient viewing (or attempting
-   to verify) the message.  Implementations that provide the capability
-   of parallel fetching and/or prefetching, along with a robust cache,
-   can lead to greatly improved performance or user experience.
-
-8.  Security Considerations
-
-8.1.  General Considerations for Building a Certification Path
-
-   Although certification path building deals directly with security
-   relevant PKI data, the PKI data itself needs no special handling
-   because its integrity is secured with the digital signature applied
-   to it.  The only exception to this is the appropriate protection of
-   the trust anchor public keys.  These are to be kept safe and obtained
-   out of band (e.g., not from an electronic mail message or a
-   directory) with respect to the path-building module.
-
-   The greatest security risks associated with this document revolve
-   around performing certification path validation while certification
-   paths are built.  It is therefore noted here that fully implemented
-   certification path validation in accordance with [RFC3280] and
-   [X.509] is required in order for certification path building,
-   certification path validation, and the certificate using application
-   to be properly secured.  All of the Security Considerations listed in
-   Section 9 of [RFC3280] apply equally here.
-
-   In addition, as with any application that consumes data from
-   potentially untrusted network locations, certification path-building
-   components should be carefully implemented so as to reduce or
-   eliminate the possibility of network based exploits.  For example, a
-   poorly implemented path-building module may not check the length of
-   the CRLDP URI [RFC3986] before using the C language strcpy() function
-   to place the address in a 1024 byte buffer.  A hacker could use such
-   a flaw to create a buffer overflow exploit by encoding malicious
-   assembly code into the CRLDP of a certificate and then use the
-   certificate to attempt an authentication.  Such an attack could yield
-   system level control to the attacker and expose the sensitive data
-   the PKI was meant to protect.
-
-   Path building may be used to mount a denial of service (DOS) attack.
-   This might occur if multiple simple requests could be performed that
-   cause a server to perform a number of path developments, each taking
-   time and resources from the server.  Servers can help avoid this by
-   limiting the resources they are willing to devote to path building,
-
-
-
-Cooper, et al.               Informational                     [Page 74]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   and being able to further limit those resources when the load is
-   heavy.  Standard DOS protections such as systems that identify and
-   block attackers can also be useful.
-
-   A DOS attack can be also created by presenting spurious CA
-   certificates containing very large public keys.  When the system
-   attempts to use the large public key to verify the digital signature
-   on additional certificates, a long processing delay may occur.  This
-   can be mitigated by either of two strategies.  The first strategy is
-   to perform signature verifications only after a complete path is
-   built, starting from the trust anchor.  This will eliminate the
-   spurious CA certificate from consideration before the large public
-   key is used.  The second strategy is to recognize and simply reject
-   keys longer than a certain size.
-
-   A similar DOS attack can occur with very large public keys in end
-   entity certificates.  If a system uses the public key in a
-   certificate before building and validating that certificate's
-   certification path, long processing delays may occur.  To mitigate
-   this threat, the public key in an end entity certificate should not
-   be used for any purpose until a complete certification path for that
-   certificate is built and validated.
-
-8.2.  Specific Considerations for Building Revocation Signer
-      Certification Paths
-
-   If the CRL Signer certificate (and certification path) is not
-   identical to the Certification Authority certificate (and
-   certification path), special care should be exercised when building
-   the CRL Signer certification path.
-
-   If special consideration is not given to building a CRL Signer
-   certification path, that path could be constructed such that it
-   terminates with a different root or through a different certification
-   path to the same root.  If this behavior is not prevented, the
-   relying party may end up checking the wrong revocation data, or even
-   maliciously substituted data, resulting in denial of service or
-   security breach.
-
-   For example, suppose the following certification path is built for E
-   and is valid for an example "high assurance" policy.
-
-      A->B->C->E
-
-   When the building/validation routine attempts to verify that E is not
-   revoked, C is referred to as the Certification Authority certificate.
-   The path builder finds that the CRL for checking the revocation
-   status of E is issued by C2; a certificate with the subject name "C",
-
-
-
-Cooper, et al.               Informational                     [Page 75]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   but with a different key than the key that was used to sign E.  C2 is
-   referred to as the CRL Signer.  An unrestrictive certification path
-   builder might then build a path such as the following for the CRL
-   Signer C2 certificate:
-
-      X->Y->Z->C2
-
-   If a path such as the one above is permitted, nothing can be
-   concluded about the revocation status of E since C2 is a different CA
-   from C.
-
-   Fortunately, preventing this security problem is not difficult and
-   the solution also makes building CRL Signer certification paths very
-   efficient.  In the event the CRL Signer certificate is identical to
-   the Certification Authority certificate, the Certification Authority
-   certification path should be used to verify the CRL; no additional
-   path building is required.  If the CRL Signer certificate is not
-   identical to the Certification Authority certificate, a second path
-   should be built for the CRL Signer certificate in exactly the same
-   fashion as for any certificate, but with the following additional
-   guidelines:
-
-   1.  Trust Anchor:  The CRL Signer's certification path should start
-       with the same trust anchor as the Certification Authority's
-       certification path.  Any trust anchor certificate with a subject
-       DN matching that of the Certification Authority's trust anchor
-       should be considered acceptable though lower in priority than the
-       one with a matching public key and subject DN.  While different
-       trust anchor public keys are acceptable at the beginning of the
-       CRL signer's certification path and the Certification Authority's
-       certification path, both keys must be trusted by the relying
-       party per the recommendations in Section 8.1.
-
-   2.  CA Name Matching:  The subject DNs for all CA certificates in the
-       two certification paths should match on a one-to-one basis
-       (ignoring self-issued certificates) for the entire length of the
-       shorter of the two paths.
-
-   3.  CRL Signer Certification Path Length:  The length of the CRL
-       Signer certification path (ignoring self-issued certificates)
-       should be equal to or less than the length of the Certification
-       Authority certification path plus (+) one.  This allows a given
-       Certification Authority to issue a certificate to a
-       delegated/subordinate CRL Signer.  The latter configuration
-       represents the maximum certification path length for a CRL Signer
-       certificate.
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 76]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   The reasoning behind the first guideline is readily apparent.
-   Lacking this and the second guideline, any trusted CA could issue
-   CRLs for any other CA, even if the PKIs are not related in any
-   fashion.  For example, one company could revoke certificates issued
-   by another company if the relying party trusted the trust anchors
-   from both companies.  The two guidelines also prevent erroneous CRL
-   checks since Global uniqueness of names is not guaranteed.
-
-   The second guideline prevents roaming certification paths such as the
-   previously described example CRL Signer certification path for
-   A->B->C->E.  It is especially important that the "ignoring self-
-   issued certificates" is implemented properly.  Self-issued
-   certificates are cast out of the one-to-one name comparison in order
-   to allow for key rollover.  The path-building algorithm may be
-   optimized to only consider certificates with the acceptable subject
-   DN for the given point in the CRL Signer certification path while
-   building the path.
-
-   The third and final guideline ensures that the CRL used is the
-   intended one.  Without a restriction on the length of the CRL Signer
-   certification path, the path could roam uncontrolled into another
-   domain and still meet the first two guidelines.  For example, again
-   using the path A->B->C->E, the Certification Authority C, and a CRL
-   Signer C2, a CRL Signer certification path such as the following
-   could pass the first two guidelines:
-
-      A->B->C->D->X->Y->RogueCA->C2
-
-   In the preceding example, the trust anchor is identical for both
-   paths and the one-to-one name matching test passes for A->B->C.
-   However, accepting such a path has obvious security consequences, so
-   the third guideline is used to prevent this situation.  Applying the
-   second and third guideline to the certification path above, the path
-   builder could have immediately detected this path was not acceptable
-   (prior to building it) by examining the issuer DN in C2.  Given the
-   length and name guidelines, the path builder could detect that
-   "RogueCA" is not in the set of possible names by comparing it to the
-   set of possible CRL Signer issuer DNs, specifically, A, B, or C.
-
-   Similar consideration should be given when building the path for the
-   OCSP Responder certificate when the CA is the OCSP Response Signer or
-   the CA has delegated the OCSP Response signing to another entity.
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 77]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-9.  Acknowledgements
-
-   The authors extend their appreciation to David Lemire for his efforts
-   coauthoring "Managing Interoperability in Non-Hierarchical Public Key
-   Infrastructures" from which material was borrowed heavily for use in
-   the introductory sections.
-
-   This document has also greatly benefited from the review and
-   additional technical insight provided by Dr. Santosh Chokhani, Carl
-   Wallace, Denis Pinkas, Steve Hanna, Alice Sturgeon, Russ Housley, and
-   Tim Polk.
-
-10.  Normative References
-
-   [RFC3280]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-               X.509 Public Key Infrastructure Certificate and
-               Certificate Revocation List (CRL) Profile", RFC 3280,
-               April 2002.
-
-11.  Informative References
-
-   [MINHPKIS]  Hesse, P., and D. Lemire, "Managing Interoperability in
-               Non-Hierarchical Public Key Infrastructures", 2002
-               Conference Proceedings of the Internet Society Network
-               and Distributed System Security Symposium, February 2002.
-
-   [RFC1777]   Yeong, W., Howes, T., and S. Kille, "Lightweight
-               Directory Access Protocol", RFC 1777, March 1995.
-
-   [RFC2560]   Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
-               Adams, "X.509 Internet Public Key Infrastructure Online
-               Certificate Status Protocol - OCSP", RFC 2560, June 1999.
-
-   [RFC2587]   Boeyen, S., Howes, T., and P. Richard, "Internet X.509
-               Public Key Infrastructure LDAPv2 Schema", RFC 2587, June
-               1999.
-
-   [RFC3377]   Hodges, J. and R. Morgan, "Lightweight Directory Access
-               Protocol (v3): Technical Specification", RFC 3377,
-               September 2002.
-
-   [RFC3820]   Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M.
-               Thompson, "Internet X.509 Public Key Infrastructure (PKI)
-               Proxy Certificate Profile", RFC 3820, June 2004.
-
-   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-               Resource Identifier (URI): Generic Syntax", STD 66, RFC
-               3986, January 2005.
-
-
-
-Cooper, et al.               Informational                     [Page 78]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-   [X.501]     ITU-T Recommendation X.501: Information Technology - Open
-               Systems Interconnection - The Directory: Models, 1993.
-
-   [X.509]     ITU-T Recommendation X.509 (2000 E): Information
-               Technology - Open Systems Interconnection - The
-               Directory: Authentication Framework, March 2000.
-
-   [PKIXALGS]  Bassham, L., Polk, W. and R. Housley, "Algorithms and
-               Identifiers for the Internet X.509 Public Key
-               Infrastructure Certificate and Certificate Revocation
-               Lists (CRL) Profile", RFC 3279, April 2002.
-
-   [CERTSTORE] P. Gutmann, "Internet X.509 Public Key Infrastructure
-               Operational Protocols: Certificate Store Access via
-               HTTP", Work in Progress, August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 79]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-Authors' Addresses
-
-   Matt Cooper
-   Orion Security Solutions, Inc.
-   1489 Chain Bridge Rd, Ste. 300
-   McLean, VA  22101,  USA
-
-   Phone:  +1-703-917-0060
-   EMail:  mcooper@orionsec.com
-
-
-   Yuriy Dzambasow
-   A&N Associates, Inc.
-   999 Corporate Blvd Ste. 100
-   Linthicum, MD  21090,  USA
-
-   Phone:  +1-410-859-5449 x107
-   EMail:  yuriy@anassoc.com
-
-
-   Peter Hesse
-   Gemini Security Solutions, Inc.
-   4451 Brookfield Corporate Dr. Ste. 200
-   Chantilly, VA  20151,  USA
-
-   Phone:  +1-703-378-5808 x105
-   EMail:  pmhesse@geminisecurity.com
-
-
-   Susan Joseph
-   Van Dyke Technologies
-   6716 Alexander Bell Drive
-   Columbia, MD 21046
-
-   EMail:  susan.joseph@vdtg.com
-
-
-   Richard Nicholas
-   BAE Systems Information Technology
-   141 National Business Parkway, Ste. 210
-   Annapolis Junction, MD  20701,  USA
-
-   Phone:  +1-301-939-2722
-   EMail:  richard.nicholas@it.baesystems.com
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 80]
-
-RFC 4158              Certification Path Building         September 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Cooper, et al.               Informational                     [Page 81]
-
diff --git a/doc/protocol/rfc4162.txt b/doc/protocol/rfc4162.txt
deleted file mode 100644
index c9d6fd97da..0000000000
--- a/doc/protocol/rfc4162.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           H.J. Lee
-Request for Comments: 4162                                     J.H. Yoon
-Category: Standards Track                                       J.I. Lee
-                                                                    KISA
-                                                             August 2005
-
-
-    Addition of SEED Cipher Suites to Transport Layer Security (TLS)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document proposes the addition of new cipher suites to the
-   Transport Layer Security (TLS) protocol to support the SEED
-   encryption algorithm as a bulk cipher algorithm.
-
-1.  Introduction
-
-   This document proposes the addition of new cipher suites to the TLS
-   protocol [TLS] to support the SEED encryption algorithm as a bulk
-   cipher algorithm.
-
-1.1.  SEED
-
-   SEED is a symmetric encryption algorithm that was developed by Korea
-   Information Security Agency (KISA) and a group of experts, beginning
-   in 1998.  The input/output block size of SEED is 128-bit and the key
-   length is also 128-bit.  SEED has the 16-round Feistel structure.  A
-   128-bit input is divided into two 64-bit blocks and the right 64-bit
-   block is an input to the round function with a 64-bit subkey
-   generated from the key scheduling.
-
-
-
-
-
-
-
-
-
-Lee, et al.                 Standards Track                     [Page 1]
-
-RFC 4162               SEED Cipher Suites to TLS             August 2005
-
-
-   SEED is easily implemented in various software and hardware because
-   it is designed to increase the efficiency of memory storage and the
-   simplicity of generating keys without degrading the security of the
-   algorithm.  In particular, it can be effectively adopted in a
-   computing environment that has a restricted resources such as mobile
-   devices, smart cards, and so on.
-
-   SEED is a national industrial association standard [TTASSEED] and is
-   widely used in South Korea for electronic commerce and financial
-   services operated on wired & wireless PKI.
-
-   The algorithm specification and object identifiers are described in
-   [SEED-ALG].  The SEED homepage,
-   http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of
-   information about SEED, including detailed specification, evaluation
-   report, test vectors, and so on.
-
-1.2.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
-   as shown) are to be interpreted as described in [RFC2119].
-
-2.  Proposed Cipher Suites
-
-   The new cipher suites proposed here have the following definitions:
-
-      CipherSuite TLS_RSA_WITH_SEED_CBC_SHA      = { 0x00, 0x96};
-      CipherSuite TLS_DH_DSS_WITH_SEED_CBC_SHA   = { 0x00, 0x97};
-      CipherSuite TLS_DH_RSA_WITH_SEED_CBC_SHA   = { 0x00, 0x98};
-      CipherSuite TLS_DHE_DSS_WITH_SEED_CBC_SHA  = { 0x00, 0x99};
-      CipherSuite TLS_DHE_RSA_WITH_SEED_CBC_SHA  = { 0x00, 0x9A};
-      CipherSuite TLS_DH_anon_WITH_SEED_CBC_SHA  = { 0x00, 0x9B};
-
-3.  Cipher Suite Definitions
-
-3.1.  Cipher
-
-   All the cipher suites described here use SEED in cipher block
-   chaining (CBC) mode as a bulk cipher algorithm.  SEED is a 128-bit
-   block cipher with 128-bit key size.
-
-3.2.  Hash
-
-   All the cipher suites described here use SHA-1 [SHA-1] in an HMAC
-   construction as described in section 5 of [TLS].
-
-
-
-
-
-Lee, et al.                 Standards Track                     [Page 2]
-
-RFC 4162               SEED Cipher Suites to TLS             August 2005
-
-
-3.3.  Key Exchange
-
-   The cipher suites defined here differ in the type of certificate and
-   key exchange method.  They use the following options:
-
-      CipherSuite                         Key Exchange Algorithm
-
-      TLS_RSA_WITH_SEED_CBC_SHA                    RSA
-      TLS_DH_DSS_WITH_SEED_CBC_SHA                 DH_DSS
-      TLS_DH_RSA_WITH_SEED_CBC_SHA                 DH_RSA
-      TLS_DHE_DSS_WITH_SEED_CBC_SHA                DHE_DSS
-      TLS_DHE_RSA_WITH_SEED_CBC_SHA                DHE_RSA
-      TLS_DH_anon_WITH_SEED_CBC_SHA                DH_anon
-
-   For the meanings of the terms RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA,
-   and DH_anon, please refer to sections 7.4.2 and 7.4.3 of [TLS].
-
-4.  Security Considerations
-
-   It is not believed that the new cipher suites are less secure than
-   the corresponding older ones.  No security problem has been found on
-   SEED.  SEED is robust against known attacks, including differential
-   cryptanalysis, linear cryptanalysis, and related key attacks, etc.
-   SEED has gone through wide public scrutinizing procedures.
-   Especially, it has been evaluated and also considered
-   cryptographically secure by trustworthy organizations such as ISO/IEC
-   JTC 1/SC 27 and Japan CRYPTREC (Cryptography Research and Evaluation
-   Committees) [ISOSEED] [CRYPTREC].  SEED has been submitted to several
-   other standardization bodies such as ISO (ISO/IEC 18033-3) and IETF
-   S/MIME Mail Security [SEED-SMIME]; and it is under consideration.
-   For further security considerations, the reader is encouraged to read
-   [SEED-EVAL].
-
-   For other security considerations, please refer to the security of
-   the corresponding older cipher suites described in [TLS] and
-   [AES-TLS].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lee, et al.                 Standards Track                     [Page 3]
-
-RFC 4162               SEED Cipher Suites to TLS             August 2005
-
-
-5.  References
-
-5.1.  Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]        Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-                RFC 2246, January 1999.
-
-   [TTASSEED]   Telecommunications Technology Association (TTA), South
-                Korea, "128-bit Symmetric Block Cipher (SEED)",
-                TTAS.KO-12.0004, September 1998, (In Korean)
-                http://www.tta.or.kr/English/new/main/index.htm.
-
-5.2.  Informative References
-
-   [AES-TLS]    Chown, P., "Advanced Encryption Standard (AES)
-                Ciphersuites for Transport Layer Security (TLS)", RFC
-                3268, June 2002.
-
-   [CRYPTREC]   Information-technology Promotion Agency (IPA), Japan,
-                CRYPTREC. "SEED Evaluation Report", February 2002,
-                http://www.kisa.or.kr/seed/seed_eng.html.
-
-   [ISOSEED]    ISO/IEC JTC 1/SC 27, "National Body contributions on NP
-                18033 'Encryption Algorithms' in Response to SC 27 N2563
-                (ATT.3 Korea Contribution)", ISO/IEC JTC 1/SC 27 N2656r1
-                (n2656_3.zip), October 2000.
-
-   [SEED-EVAL]  KISA, "Self Evaluation Report",
-                http://www.kisa.or.kr/seed/seed_eng.html.
-
-   [SEED-ALG]   Park, J., Lee, S., Kim, J., and J. Lee, "The SEED
-                Encryption Algorithm", RFC 4009, February 2005.
-
-   [SEED-SMIME] Park, J., Lee, S., Kim, J., and J. Lee, "Use of the SEED
-                Encryption Algorithm in Cryptographic Message Syntax
-                (CMS)", RFC 4010, February 2005.
-
-   [SHA-1]      FIPS PUB 180-1, "Secure Hash Standard", National
-                Institute of Standards and Technology, U.S. Department
-                of Commerce, April 17, 1995.
-
-
-
-
-
-
-
-
-Lee, et al.                 Standards Track                     [Page 4]
-
-RFC 4162               SEED Cipher Suites to TLS             August 2005
-
-
-Authors' Addresses
-
-   Hyangjin Lee
-   Korea Information Security Agency
-
-   Phone: +82-2-405-5446
-   Fax  : +82-2-405-5319
-   EMail: jiinii@kisa.or.kr
-
-
-   Jaeho Yoon
-   Korea Information Security Agency
-
-   Phone: +82-2-405-5434
-   Fax  : +82-2-405-5219
-   EMail: jhyoon@kisa.or.kr
-
-
-   Jaeil Lee
-   Korea Information Security Agency
-
-   Phone: +82-2-405-5300
-   Fax  : +82-2-405-5219
-   EMail: jilee@kisa.or.kr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lee, et al.                 Standards Track                     [Page 5]
-
-RFC 4162               SEED Cipher Suites to TLS             August 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Lee, et al.                 Standards Track                     [Page 6]
-
diff --git a/doc/protocol/rfc4279.txt b/doc/protocol/rfc4279.txt
deleted file mode 100644
index dba59ba81d..0000000000
--- a/doc/protocol/rfc4279.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     P. Eronen, Ed.
-Request for Comments: 4279                                         Nokia
-Category: Standards Track                             H. Tschofenig, Ed.
-                                                                 Siemens
-                                                           December 2005
-
-
-     Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document specifies three sets of new ciphersuites for the
-   Transport Layer Security (TLS) protocol to support authentication
-   based on pre-shared keys (PSKs).  These pre-shared keys are symmetric
-   keys, shared in advance among the communicating parties.  The first
-   set of ciphersuites uses only symmetric key operations for
-   authentication.  The second set uses a Diffie-Hellman exchange
-   authenticated with a pre-shared key, and the third set combines
-   public key authentication of the server with pre-shared key
-   authentication of the client.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 1]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Applicability Statement ....................................3
-      1.2. Conventions Used in This Document ..........................4
-   2. PSK Key Exchange Algorithm ......................................4
-   3. DHE_PSK Key Exchange Algorithm ..................................6
-   4. RSA_PSK Key Exchange Algorithm ..................................7
-   5. Conformance Requirements ........................................8
-      5.1. PSK Identity Encoding ......................................8
-      5.2. Identity Hint ..............................................9
-      5.3. Requirements for TLS Implementations .......................9
-      5.4. Requirements for Management Interfaces .....................9
-   6. IANA Considerations ............................................10
-   7. Security Considerations ........................................10
-      7.1. Perfect Forward Secrecy (PFS) .............................10
-      7.2. Brute-Force and Dictionary Attacks ........................10
-      7.3. Identity Privacy ..........................................11
-      7.4. Implementation Notes ......................................11
-   8. Acknowledgements ...............................................11
-   9. References .....................................................12
-      9.1. Normative References ......................................12
-      9.2. Informative References ....................................12
-
-1.  Introduction
-
-   Usually, TLS uses public key certificates [TLS] or Kerberos [KERB]
-   for authentication.  This document describes how to use symmetric
-   keys (later called pre-shared keys or PSKs), shared in advance among
-   the communicating parties, to establish a TLS connection.
-
-   There are basically two reasons why one might want to do this:
-
-   o  First, using pre-shared keys can, depending on the ciphersuite,
-      avoid the need for public key operations.  This is useful if TLS
-      is used in performance-constrained environments with limited CPU
-      power.
-
-   o  Second, pre-shared keys may be more convenient from a key
-      management point of view.  For instance, in closed environments
-      where the connections are mostly configured manually in advance,
-      it may be easier to configure a PSK than to use certificates.
-      Another case is when the parties already have a mechanism for
-      setting up a shared secret key, and that mechanism could be used
-      to "bootstrap" a key for authenticating a TLS connection.
-
-
-
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 2]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   This document specifies three sets of new ciphersuites for TLS.
-   These ciphersuites use new key exchange algorithms, and reuse
-   existing cipher and MAC algorithms from [TLS] and [AES].  A summary
-   of these ciphersuites is shown below.
-
-      CipherSuite                        Key Exchange  Cipher       Hash
-
-      TLS_PSK_WITH_RC4_128_SHA           PSK           RC4_128       SHA
-      TLS_PSK_WITH_3DES_EDE_CBC_SHA      PSK           3DES_EDE_CBC  SHA
-      TLS_PSK_WITH_AES_128_CBC_SHA       PSK           AES_128_CBC   SHA
-      TLS_PSK_WITH_AES_256_CBC_SHA       PSK           AES_256_CBC   SHA
-      TLS_DHE_PSK_WITH_RC4_128_SHA       DHE_PSK       RC4_128       SHA
-      TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA  DHE_PSK       3DES_EDE_CBC  SHA
-      TLS_DHE_PSK_WITH_AES_128_CBC_SHA   DHE_PSK       AES_128_CBC   SHA
-      TLS_DHE_PSK_WITH_AES_256_CBC_SHA   DHE_PSK       AES_256_CBC   SHA
-      TLS_RSA_PSK_WITH_RC4_128_SHA       RSA_PSK       RC4_128       SHA
-      TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA  RSA_PSK       3DES_EDE_CBC  SHA
-      TLS_RSA_PSK_WITH_AES_128_CBC_SHA   RSA_PSK       AES_128_CBC   SHA
-      TLS_RSA_PSK_WITH_AES_256_CBC_SHA   RSA_PSK       AES_256_CBC   SHA
-
-   The ciphersuites in Section 2 (with PSK key exchange algorithm) use
-   only symmetric key algorithms and are thus especially suitable for
-   performance-constrained environments.
-
-   The ciphersuites in Section 3 (with DHE_PSK key exchange algorithm)
-   use a PSK to authenticate a Diffie-Hellman exchange.  These
-   ciphersuites protect against dictionary attacks by passive
-   eavesdroppers (but not active attackers) and also provide Perfect
-   Forward Secrecy (PFS).
-
-   The ciphersuites in Section 4 (with RSA_PSK key exchange algorithm)
-   combine public-key-based authentication of the server (using RSA and
-   certificates) with mutual authentication using a PSK.
-
-1.1.  Applicability Statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid Public-Key Infrastructures (PKIs),
-   another possibility worth considering is using self-signed
-   certificates with public key fingerprints.  Instead of manually
-   configuring a shared secret in, for instance, some configuration
-   file, a fingerprint (hash) of the other party's public key (or
-   certificate) could be placed there instead.
-
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 3]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   It is also possible to use the SRP (Secure Remote Password)
-   ciphersuites for shared secret authentication [SRP].  SRP was
-   designed to be used with passwords, and it incorporates protection
-   against dictionary attacks.  However, it is computationally more
-   expensive than the PSK ciphersuites in Section 2.
-
-1.2.  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 [KEYWORDS].
-
-2.  PSK Key Exchange Algorithm
-
-   This section defines the PSK key exchange algorithm and associated
-   ciphersuites.  These ciphersuites use only symmetric key algorithms.
-
-   It is assumed that the reader is familiar with the ordinary TLS
-   handshake, shown below.  The elements in parenthesis are not included
-   when the PSK key exchange algorithm is used, and "*" indicates a
-   situation-dependent message that is not always sent.
-
-      Client                                               Server
-      ------                                               ------
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                    (Certificate)
-                                               ServerKeyExchange*
-                                             (CertificateRequest)
-                                   <--------      ServerHelloDone
-      (Certificate)
-      ClientKeyExchange
-      (CertificateVerify)
-      ChangeCipherSpec
-      Finished                     -------->
-                                                 ChangeCipherSpec
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-   The client indicates its willingness to use pre-shared key
-   authentication by including one or more PSK ciphersuites in the
-   ClientHello message.  If the TLS server also wants to use pre-shared
-   keys, it selects one of the PSK ciphersuites, places the selected
-   ciphersuite in the ServerHello message, and includes an appropriate
-   ServerKeyExchange message (see below).  The Certificate and
-   CertificateRequest payloads are omitted from the response.
-
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 4]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   Both clients and servers may have pre-shared keys with several
-   different parties.  The client indicates which key to use by
-   including a "PSK identity" in the ClientKeyExchange message (note
-   that unlike in [SHAREDKEYS], the session_id field in ClientHello
-   message keeps its usual meaning).  To help the client in selecting
-   which identity to use, the server can provide a "PSK identity hint"
-   in the ServerKeyExchange message.  If no hint is provided, the
-   ServerKeyExchange message is omitted.  See Section 5 for a more
-   detailed description of these fields.
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The premaster secret is formed as follows: if the PSK is N octets
-   long, concatenate a uint16 with the value N, N zero octets, a second
-   uint16 with the value N, and the PSK itself.
-
-      Note 1: All the ciphersuites in this document share the same
-      general structure for the premaster secret, namely,
-
-         struct {
-             opaque other_secret<0..2^16-1>;
-             opaque psk<0..2^16-1>;
-         };
-
-      Here "other_secret" either is zeroes (plain PSK case) or comes
-      from the Diffie-Hellman or RSA exchange (DHE_PSK and RSA_PSK,
-      respectively).  See Sections 3 and 4 for a more detailed
-      description.
-
-      Note 2: Using zeroes for "other_secret" effectively means that
-      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 5]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-      is used when constructing the master secret.  This was considered
-      more elegant from an analytical viewpoint than, for instance,
-      using the same key for both the HMAC-MD5 and HMAC-SHA1 parts.  See
-      [KRAWCZYK] for a more detailed rationale.
-
-   The TLS handshake is authenticated using the Finished messages as
-   usual.
-
-   If the server does not recognize the PSK identity, it MAY respond
-   with an "unknown_psk_identity" alert message.  Alternatively, if the
-   server wishes to hide the fact that the PSK identity was not known,
-   it MAY continue the protocol as if the PSK identity existed but the
-   key was incorrect: that is, respond with a "decrypt_error" alert.
-
-3.  DHE_PSK Key Exchange Algorithm
-
-   This section defines additional ciphersuites that use a PSK to
-   authenticate a Diffie-Hellman exchange.  These ciphersuites give some
-   additional protection against dictionary attacks and also provide
-   Perfect Forward Secrecy (PFS).  See Section 7 for discussion of
-   related security considerations.
-
-   When these ciphersuites are used, the ServerKeyExchange and
-   ClientKeyExchange messages also include the Diffie-Hellman
-   parameters.  The PSK identity and identity hint fields have the same
-   meaning as in the previous section (note that the ServerKeyExchange
-   message is always sent, even if no PSK identity hint is provided).
-
-   The format of the ServerKeyExchange and ClientKeyExchange messages is
-   shown below.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-                  ServerDHParams params;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case diffie_hellman_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  ClientDiffieHellmanPublic public;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 6]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   The premaster secret is formed as follows.  First, perform the
-   Diffie-Hellman computation in the same way as for other
-   Diffie-Hellman-based ciphersuites in [TLS].  Let Z be the value
-   produced by this computation (with leading zero bytes stripped as in
-   other Diffie-Hellman-based ciphersuites).  Concatenate a uint16
-   containing the length of Z (in octets), Z itself, a uint16 containing
-   the length of the PSK (in octets), and the PSK itself.
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing Z.
-
-4.  RSA_PSK Key Exchange Algorithm
-
-   The ciphersuites in this section use RSA and certificates to
-   authenticate the server, in addition to using a PSK.
-
-   As in normal RSA ciphersuites, the server must send a Certificate
-   message.  The format of the ServerKeyExchange and ClientKeyExchange
-   messages is shown below.  If no PSK identity hint is provided, the
-   ServerKeyExchange message is omitted.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:  /* NEW */
-                  opaque psk_identity_hint<0..2^16-1>;
-          };
-      } ServerKeyExchange;
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              /* other cases for rsa, diffie_hellman, etc. */
-              case rsa_psk:   /* NEW */
-                  opaque psk_identity<0..2^16-1>;
-                  EncryptedPreMasterSecret;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-   The EncryptedPreMasterSecret field sent from the client to the server
-   contains a 2-byte version number and a 46-byte random value,
-   encrypted using the server's RSA public key as described in Section
-   7.4.7.1 of [TLS].  The actual premaster secret is formed by both
-   parties as follows: concatenate a uint16 with the value 48, the
-   2-byte version number and the 46-byte random value, a uint16
-   containing the length of the PSK (in octets), and the PSK itself.
-   (The premaster secret is thus 52 octets longer than the PSK.)
-
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 7]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   This corresponds to the general structure for the premaster secrets
-   (see Note 1 in Section 2) in this document, with "other_secret"
-   containing both the 2-byte version number and the 46-byte random
-   value.
-
-   Neither the normal RSA ciphersuites nor these RSA_PSK ciphersuites
-   themselves specify what the certificates contain (in addition to the
-   RSA public key), or how the certificates are to be validated.  In
-   particular, it is possible to use the RSA_PSK ciphersuites with
-   unvalidated self-signed certificates to provide somewhat similar
-   protection against dictionary attacks, as the DHE_PSK ciphersuites
-   define in Section 3.
-
-5.  Conformance Requirements
-
-   It is expected that different types of identities are useful for
-   different applications running over TLS.  This document does not
-   therefore mandate the use of any particular type of identity (such as
-   IPv4 address or Fully Qualified Domain Name (FQDN)).
-
-   However, the TLS client and server clearly have to agree on the
-   identities and keys to be used.  To improve interoperability, this
-   document places requirements on how the identity is encoded in the
-   protocol, and what kinds of identities and keys implementations have
-   to support.
-
-   The requirements for implementations are divided into two categories,
-   requirements for TLS implementations and management interfaces.  In
-   this context, "TLS implementation" refers to a TLS library or module
-   that is intended to be used for several different purposes, while
-   "management interface" would typically be implemented by a particular
-   application that uses TLS.
-
-   This document does not specify how the server stores the keys and
-   identities, or how exactly it finds the key corresponding to the
-   identity it receives.  For instance, if the identity is a domain
-   name, it might be appropriate to do a case-insensitive lookup.  It is
-   RECOMMENDED that before looking up the key, the server processes the
-   PSK identity with a stringprep profile [STRINGPREP] appropriate for
-   the identity in question (such as Nameprep [NAMEPREP] for components
-   of domain names or SASLprep for usernames [SASLPREP]).
-
-5.1.  PSK Identity Encoding
-
-   The PSK identity MUST be first converted to a character string, and
-   then encoded to octets using UTF-8 [UTF8].  For instance,
-
-
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 8]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   o  IPv4 addresses are sent as dotted-decimal strings (e.g.,
-      "192.0.2.1"), not as 32-bit integers in network byte order.
-
-   o  Domain names are sent in their usual text form [DNS] (e.g.,
-      "www.example.com" or "embedded\.dot.example.net"), not in DNS
-      protocol format.
-
-   o  X.500 Distinguished Names are sent in their string representation
-      [LDAPDN], not as BER-encoded ASN.1.
-
-   This encoding is clearly not optimal for many types of identities.
-   It was chosen to avoid identity-type-specific parsing and encoding
-   code in implementations where the identity is configured by a person
-   using some kind of management interface.  Requiring such identity-
-   type-specific code would also increase the chances for
-   interoperability problems resulting from different implementations
-   supporting different identity types.
-
-5.2.  Identity Hint
-
-   In the absence of an application profile specification specifying
-   otherwise, servers SHOULD NOT provide an identity hint and clients
-   MUST ignore the identity hint field.  Applications that do use this
-   field MUST specify its contents, how the value is chosen by the TLS
-   server, and what the TLS client is expected to do with the value.
-
-5.3.  Requirements for TLS Implementations
-
-   TLS implementations supporting these ciphersuites MUST support
-   arbitrary PSK identities up to 128 octets in length, and arbitrary
-   PSKs up to 64 octets in length.  Supporting longer identities and
-   keys is RECOMMENDED.
-
-5.4.  Requirements for Management Interfaces
-
-   In the absence of an application profile specification specifying
-   otherwise, a management interface for entering the PSK and/or PSK
-   identity MUST support the following:
-
-   o  Entering PSK identities consisting of up to 128 printable Unicode
-      characters.  Supporting as wide a character repertoire and as long
-      identities as feasible is RECOMMENDED.
-
-   o  Entering PSKs up to 64 octets in length as ASCII strings and in
-      hexadecimal encoding.
-
-
-
-
-
-
-Eronen & Tschofenig         Standards Track                     [Page 9]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-6.  IANA Considerations
-
-   IANA does not currently have a registry for TLS ciphersuite or alert
-   numbers, so there are no IANA actions associated with this document.
-
-   For easier reference in the future, the ciphersuite numbers defined
-   in this document are summarized below.
-
-      CipherSuite TLS_PSK_WITH_RC4_128_SHA          = { 0x00, 0x8A };
-      CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA     = { 0x00, 0x8B };
-      CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA      = { 0x00, 0x8C };
-      CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA      = { 0x00, 0x8D };
-      CipherSuite TLS_DHE_PSK_WITH_RC4_128_SHA      = { 0x00, 0x8E };
-      CipherSuite TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x8F };
-      CipherSuite TLS_DHE_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x90 };
-      CipherSuite TLS_DHE_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x91 };
-      CipherSuite TLS_RSA_PSK_WITH_RC4_128_SHA      = { 0x00, 0x92 };
-      CipherSuite TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x93 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_128_CBC_SHA  = { 0x00, 0x94 };
-      CipherSuite TLS_RSA_PSK_WITH_AES_256_CBC_SHA  = { 0x00, 0x95 };
-
-   This document also defines a new TLS alert message,
-   unknown_psk_identity(115).
-
-7.  Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.
-
-7.1.  Perfect Forward Secrecy (PFS)
-
-   The PSK and RSA_PSK ciphersuites defined in this document do not
-   provide Perfect Forward Secrecy (PFS).  That is, if the shared secret
-   key (in PSK ciphersuites), or both the shared secret key and the RSA
-   private key (in RSA_PSK ciphersuites), is somehow compromised, an
-   attacker can decrypt old conversations.
-
-   The DHE_PSK ciphersuites provide Perfect Forward Secrecy if a fresh
-   Diffie-Hellman private key is generated for each handshake.
-
-7.2.  Brute-Force and Dictionary Attacks
-
-   Use of a fixed shared secret of limited entropy (for example, a PSK
-   that is relatively short, or was chosen by a human and thus may
-   contain less entropy than its length would imply) may allow an
-   attacker to perform a brute-force or dictionary attack to recover the
-   secret.  This may be either an off-line attack (against a captured
-
-
-
-Eronen & Tschofenig         Standards Track                    [Page 10]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   TLS handshake messages) or an on-line attack where the attacker
-   attempts to connect to the server and tries different keys.
-
-   For the PSK ciphersuites, an attacker can get the information
-   required for an off-line attack by eavesdropping on a TLS handshake,
-   or by getting a valid client to attempt connection with the attacker
-   (by tricking the client to connect to the wrong address, or by
-   intercepting a connection attempt to the correct address, for
-   instance).
-
-   For the DHE_PSK ciphersuites, an attacker can obtain the information
-   by getting a valid client to attempt connection with the attacker.
-   Passive eavesdropping alone is not sufficient.
-
-   For the RSA_PSK ciphersuites, only the server (authenticated using
-   RSA and certificates) can obtain sufficient information for an
-   off-line attack.
-
-   It is RECOMMENDED that implementations that allow the administrator
-   to manually configure the PSK also provide a functionality for
-   generating a new random PSK, taking [RANDOMNESS] into account.
-
-7.3.  Identity Privacy
-
-   The PSK identity is sent in cleartext.  Although using a user name or
-   other similar string as the PSK identity is the most straightforward
-   option, it may lead to problems in some environments since an
-   eavesdropper is able to identify the communicating parties.  Even
-   when the identity does not reveal any information itself, reusing the
-   same identity over time may eventually allow an attacker to perform
-   traffic analysis to identify the parties.  It should be noted that
-   this is no worse than client certificates, since they are also sent
-   in cleartext.
-
-7.4.  Implementation Notes
-
-   The implementation notes in [TLS11] about correct implementation and
-   use of RSA (including Section 7.4.7.1) and Diffie-Hellman (including
-   Appendix F.1.1.3) apply to the DHE_PSK and RSA_PSK ciphersuites as
-   well.
-
-8.  Acknowledgements
-
-   The protocol defined in this document is heavily based on work by Tim
-   Dierks and Peter Gutmann, and borrows some text from [SHAREDKEYS] and
-   [AES].  The DHE_PSK and RSA_PSK ciphersuites are based on earlier
-   work in [KEYEX].
-
-
-
-
-Eronen & Tschofenig         Standards Track                    [Page 11]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   Valuable feedback was also provided by Bernard Aboba, Lakshminath
-   Dondeti, Philip Ginzboorg, Peter Gutmann, Sam Hartman, Russ Housley,
-   David Jablon, Nikos Mavroyanopoulos, Bodo Moeller, Eric Rescorla, and
-   Mika Tervonen.
-
-   When the first version of this document was almost ready, the authors
-   learned that something similar had been proposed already in 1996
-   [PASSAUTH].  However, this document is not intended for web password
-   authentication, but rather for other uses of TLS.
-
-9.  References
-
-9.1.  Normative References
-
-   [AES]        Chown, P., "Advanced Encryption Standard (AES)
-                Ciphersuites for Transport Layer Security (TLS)", RFC
-                3268, June 2002.
-
-   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RANDOMNESS] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-                "Randomness Requirements for Security", BCP 106, RFC
-                4086, June 2005.
-
-   [TLS]        Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-                RFC 2246, January 1999.
-
-   [UTF8]       Yergeau, F., "UTF-8, a transformation format of ISO
-                10646", STD 63, RFC 3629, November 2003.
-
-9.2.  Informative References
-
-   [DNS]        Mockapetris, P., "Domain names - implementation and
-                specification", STD 13, RFC 1035, November 1987.
-
-   [KERB]       Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-                Suites to Transport Layer Security (TLS)", RFC 2712,
-                October 1999.
-
-   [KEYEX]      Badra, M., Cherkaoui, O., Hajjeh, I. and A. Serhrouchni,
-                "Pre-Shared-Key key Exchange methods for TLS", Work in
-                Progress, August 2004.
-
-   [KRAWCZYK]   Krawczyk, H., "Re: TLS shared keys PRF", message on
-                ietf-tls@lists.certicom.com mailing list 2004-01-13,
-                http://www.imc.org/ietf-tls/mail-archive/msg04098.html.
-
-
-
-
-Eronen & Tschofenig         Standards Track                    [Page 12]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   [LDAPDN]     Zeilenga, K., "LDAP: String Representation of
-                Distinguished Names", Work in Progress, February 2005.
-
-   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [PASSAUTH]   Simon, D., "Addition of Shared Key Authentication to
-                Transport Layer Security (TLS)", Work in Progress,
-                November 1996.
-
-   [SASLPREP]   Zeilenga, K., "SASLprep: Stringprep Profile for User
-                Names and Passwords", RFC 4013, February 2005.
-
-   [SHAREDKEYS] Gutmann, P., "Use of Shared Keys in the TLS Protocol",
-                Work in Progress, October 2003.
-
-   [SRP]        Taylor, D., Wu, T., Mavroyanopoulos, N. and T. Perrin,
-                "Using SRP for TLS Authentication", Work in Progress,
-                March 2005.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [TLS11]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
-                1.1", Work in Progress, June 2005.
-
-Authors' and Contributors' Addresses
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   EMail: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   EMail: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-Eronen & Tschofenig         Standards Track                    [Page 13]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-   Mohamad Badra
-   ENST Paris
-   46 rue Barrault
-   75634 Paris
-   France
-
-   EMail: Mohamad.Badra@enst.fr
-
-
-   Omar Cherkaoui
-   UQAM University
-   Montreal (Quebec)
-   Canada
-
-   EMail: cherkaoui.omar@uqam.ca
-
-
-   Ibrahim Hajjeh
-   ESRGroups
-   17 passage Barrault
-   75013 Paris
-   France
-
-   EMail: Ibrahim.Hajjeh@esrgroups.org
-
-
-   Ahmed Serhrouchni
-   ENST Paris
-   46 rue Barrault
-   75634 Paris
-   France
-
-   EMail: Ahmed.Serhrouchni@enst.fr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig         Standards Track                    [Page 14]
-
-RFC 4279                PSK Ciphersuites for TLS           December 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at ietf-
-   ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Eronen & Tschofenig         Standards Track                    [Page 15]
-
diff --git a/doc/protocol/rfc4346.txt b/doc/protocol/rfc4346.txt
deleted file mode 100644
index 9a960d2057..0000000000
--- a/doc/protocol/rfc4346.txt
+++ /dev/null
@@ -1,4875 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          T. Dierks
-Request for Comments: 4346                                   Independent
-Obsoletes: 2246                                              E. Rescorla
-Category: Standards Track                                     RTFM, Inc.
-                                                              April 2006
-
-
-              The Transport Layer Security (TLS) Protocol
-                              Version 1.1
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document specifies Version 1.1 of the Transport Layer Security
-   (TLS) protocol.  The TLS protocol provides communications security
-   over the Internet.  The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 1]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................4
-      1.1. Differences from TLS 1.0 ...................................5
-      1.2. Requirements Terminology ...................................5
-   2. Goals ...........................................................5
-   3. Goals of This Document ..........................................6
-   4. Presentation Language ...........................................6
-      4.1. Basic Block Size ...........................................7
-      4.2. Miscellaneous ..............................................7
-      4.3. Vectors ....................................................7
-      4.4. Numbers ....................................................8
-      4.5. Enumerateds ................................................8
-      4.6. Constructed Types ..........................................9
-           4.6.1. Variants ...........................................10
-      4.7. Cryptographic Attributes ..................................11
-      4.8. Constants .................................................12
-   5. HMAC and the Pseudorandom Function .............................12
-   6. The TLS Record Protocol ........................................14
-      6.1. Connection States .........................................15
-      6.2. Record layer ..............................................17
-           6.2.1. Fragmentation ......................................17
-           6.2.2. Record Compression and Decompression ...............19
-           6.2.3. Record Payload Protection ..........................19
-                  6.2.3.1. Null or Standard Stream Cipher ............20
-                  6.2.3.2. CBC Block Cipher ..........................21
-      6.3. Key Calculation ...........................................24
-   7. The TLS Handshaking Protocols ..................................24
-      7.1. Change Cipher Spec Protocol ...............................25
-      7.2. Alert Protocol ............................................26
-           7.2.1. Closure Alerts .....................................27
-           7.2.2. Error Alerts .......................................28
-      7.3. Handshake Protocol Overview ...............................31
-      7.4. Handshake Protocol ........................................34
-           7.4.1. Hello Messages .....................................35
-                  7.4.1.1. Hello request .............................35
-                  7.4.1.2. Client Hello ..............................36
-                  7.4.1.3. Server Hello ..............................39
-           7.4.2. Server Certificate .................................40
-           7.4.3. Server Key Exchange Message ........................42
-           7.4.4. Certificate request ................................44
-           7.4.5. Server Hello Done ..................................46
-           7.4.6. Client certificate .................................46
-           7.4.7. Client Key Exchange Message ........................47
-                  7.4.7.1. RSA Encrypted Premaster Secret Message ....47
-                  7.4.7.2. Client Diffie-Hellman Public Value ........50
-           7.4.8. Certificate verify .................................50
-           7.4.9. Finished ...........................................51
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 2]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   8. Cryptographic Computations .....................................52
-      8.1. Computing the Master Secret ...............................52
-           8.1.1. RSA ................................................53
-           8.1.2. Diffie-Hellman .....................................53
-   9. Mandatory Cipher Suites ........................................53
-   10. Application Data Protocol .....................................53
-   11. Security Considerations .......................................53
-   12. IANA Considerations ...........................................54
-   A. Appendix - Protocol constant values ............................55
-           A.1. Record layer .........................................55
-           A.2. Change cipher specs message ..........................56
-           A.3. Alert messages .......................................56
-           A.4. Handshake protocol ...................................57
-           A.4.1. Hello messages .....................................57
-           A.4.2. Server authentication and key exchange messages ....58
-           A.4.3. Client authentication and key exchange messages ....59
-           A.4.4.Handshake finalization message ......................60
-           A.5. The CipherSuite ......................................60
-           A.6. The Security Parameters ..............................63
-   B. Appendix - Glossary ............................................64
-   C. Appendix - CipherSuite definitions .............................68
-   D. Appendix - Implementation Notes ................................69
-           D.1 Random Number Generation and Seeding ..................70
-           D.2 Certificates and authentication .......................70
-           D.3 CipherSuites ..........................................70
-   E. Appendix - Backward Compatibility With SSL .....................71
-           E.1. Version 2 client hello ...............................72
-           E.2. Avoiding man-in-the-middle version rollback ..........74
-   F. Appendix - Security analysis ...................................74
-           F.1. Handshake protocol ...................................74
-           F.1.1. Authentication and key exchange ....................74
-           F.1.1.1. Anonymous key exchange ...........................75
-           F.1.1.2. RSA key exchange and authentication ..............75
-           F.1.1.3. Diffie-Hellman key exchange with authentication ..76
-           F.1.2. Version rollback attacks ...........................77
-           F.1.3. Detecting attacks against the handshake protocol ...77
-           F.1.4. Resuming sessions ..................................78
-           F.1.5. MD5 and SHA ........................................78
-           F.2. Protecting application data ..........................78
-           F.3. Explicit IVs .........................................79
-           F.4  Security of Composite Cipher Modes ...................79
-           F.5  Denial of Service ....................................80
-           F.6. Final notes ..........................................80
-   Normative References ..............................................81
-   Informative References ............................................82
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 3]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-1. Introduction
-
-   The primary goal of the TLS Protocol is to provide privacy and data
-   integrity between two communicating applications.  The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol.  At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol.  The
-   TLS Record Protocol provides connection security that has two basic
-   properties:
-
-   -  The connection is private.  Symmetric cryptography is used for
-      data encryption (e.g., DES [DES], RC4 [SCH] etc.).  The keys for
-      this symmetric encryption are generated uniquely for each
-      connection and are based on a secret negotiated by another
-      protocol (such as the TLS Handshake Protocol).  The Record
-      Protocol can also be used without encryption.
-
-   -  The connection is reliable.  Message transport includes a message
-      integrity check using a keyed MAC.  Secure hash functions (e.g.,
-      SHA, MD5, etc.) are used for MAC computations.  The Record
-      Protocol can operate without a MAC, but is generally only used in
-      this mode while another protocol is using the Record Protocol as a
-      transport for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols.  One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data.  The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-   -  The peer's identity can be authenticated using asymmetric, or
-      public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
-      authentication can be made optional, but is generally required for
-      at least one of the peers.
-
-   -  The negotiation of a shared secret is secure: the negotiated
-      secret is unavailable to eavesdroppers, and for any authenticated
-      connection the secret cannot be obtained, even by an attacker who
-      can place himself in the middle of the connection.
-
-   -  The negotiation is reliable: no attacker can modify the
-      negotiation communication without being detected by the parties to
-      the communication.
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher level protocols can layer on top of the TLS Protocol
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 4]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   transparently.  The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-   of protocols that run on top of TLS.
-
-1.1. Differences from TLS 1.0
-
-   This document is a revision of the TLS 1.0 [TLS1.0] protocol, and
-   contains some small security improvements, clarifications, and
-   editorial improvements.  The major changes are:
-
-   -  The implicit Initialization Vector (IV) is replaced with an
-      explicit IV to protect against CBC attacks [CBCATT].
-
-   -  Handling of padding errors is changed to use the bad_record_mac
-      alert rather than the decryption_failed alert to protect against
-      CBC attacks.
-
-   -  IANA registries are defined for protocol parameters.
-
-   -  Premature closes no longer cause a session to be nonresumable.
-
-   -  Additional informational notes were added for various new attacks
-      on TLS.
-
-   In addition, a number of minor clarifications and editorial
-   improvements were made.
-
-1.2. Requirements Terminology
-
-   In this document, the keywords "MUST", "MUST NOT", "REQUIRED",
-   "SHOULD", "SHOULD NOT" and "MAY" are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Goals
-
-   The goals of TLS Protocol, in order of their priority, are as
-   follows:
-
-   1. Cryptographic security: TLS should be used to establish a secure
-      connection between two parties.
-
-   2. Interoperability: Independent programmers should be able to
-      develop applications utilizing TLS that can successfully exchange
-      cryptographic parameters without knowledge of one another's code.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 5]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   3. Extensibility: TLS seeks to provide a framework into which new
-      public key and bulk encryption methods can be incorporated as
-      necessary.  This will also accomplish two sub-goals: preventing
-      the need to create a new protocol (and risking the introduction of
-      possible new weaknesses) and avoiding the need to implement an
-      entire new security library.
-
-   4. Relative efficiency: Cryptographic operations tend to be highly
-      CPU intensive, particularly public key operations.  For this
-      reason, the TLS protocol has incorporated an optional session
-      caching scheme to reduce the number of connections that need to be
-      established from scratch.  Additionally, care has been taken to
-      reduce network activity.
-
-3. Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape.  The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that TLS 1.1, TLS 1.0, and SSL 3.0 do not
-   interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down prior versions).  This document
-   is intended primarily for readers who will be implementing the
-   protocol and for those doing cryptographic analysis of it.  The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups.  For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4. Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation.  The following very basic and somewhat casually
-   defined presentation syntax will be used.  The syntax draws from
-   several sources in its structure.  Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels.  The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 6]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-4.1. Basic Block Size
-
-   The representation of all data items is explicitly specified.  The
-   basic data block size is one byte (i.e., 8 bits).  Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom.  From the bytestream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-       value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-               ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big endian format.
-
-4.2. Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3. Vectors
-
-   A vector (single dimensioned array) is a stream of homogeneous data
-   elements.  The size of the vector may be specified at documentation
-   time or left unspecified until runtime.  In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector.  The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-       T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T.  The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-       opaque Datum[3];      /* three uninterpreted bytes */
-       Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 7]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream.  The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length.  A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-       T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque.  It can never be empty.
-   The actual length field consumes two bytes, a uint16, sufficient to
-   represent the value 400 (see Section 4.4).  On the other hand, longer
-   can represent up to 800 bytes of data, or 400 uint16 elements, and it
-   may be empty.  Its encoding will include a two-byte actual length
-   field prepended to the vector.  The length of an encoded vector must
-   be an even multiple of the length of a single element (for example, a
-   17-byte vector of uint16 would be illegal).
-
-       opaque mandatory<300..400>;
-             /* length field is 2 bytes, cannot be empty */
-       uint16 longer<0..800>;
-             /* zero to 400 16-bit unsigned integers */
-
-4.4. Numbers
-
-   The basic numeric data type is an unsigned byte (uint8).  All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned.  The
-   following numeric types are predefined.
-
-       uint8 uint16[2];
-       uint8 uint24[3];
-       uint8 uint32[4];
-       uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   "network" or "big-endian" order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-4.5. Enumerateds
-
-   An additional sparse data type is available called enum.  A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type.  Only enumerateds of the same
-   type may be assigned or compared.  Every element of an enumerated
-   must be assigned a value, as demonstrated in the following example.
-   Since the elements of the enumerated are not ordered, they can be
-   assigned any unique value, in any order.
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 8]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-       enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   Enumerateds occupy as much space in the byte stream as would its
-   maximal defined ordinal value.  The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-       enum { red(3), blue(5), white(7) } Color;
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-       enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type.  In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue.  Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-       Color color = Color.blue;     /* overspecified, legal */
-       Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-       enum { low, medium, high } Amount;
-
-4.6. Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience.  Each specification declares a new, unique type.  The
-   syntax for definition is much like that of C.
-
-       struct {
-         T1 f1;
-         T2 f2;
-         ...
-         Tn fn;
-       } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds.  For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 9]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-4.6.1. Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment.  The selector must be an enumerated
-   type that defines the possible variants the structure defines.  There
-   must be a case arm for every element of the enumeration declared in
-   the select.  The body of the variant structure may be given a label
-   for reference.  The mechanism by which the variant is selected at
-   runtime is not prescribed by the presentation language.
-
-       struct {
-           T1 f1;
-           T2 f2;
-           ....
-           Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               ....
-               case en: Ten;
-           } [[fv]];
-       } [[Tv]];
-
-   For example:
-
-       enum { apple, orange } VariantTag;
-       struct {
-           uint16 number;
-           opaque string<0..10>; /* variable length */
-       } V1;
-       struct {
-           uint32 number;
-           opaque string[10];    /* fixed length */
-       } V2;
-       struct {
-           select (VariantTag) { /* value of selector is implicit */
-               case apple: V1;   /* VariantBody, tag = apple */
-               case orange: V2;  /* VariantBody, tag = orange */
-           } variant_body;       /* optional label on variant */
-       } VariantRecord;
-
-   Variant structures may be qualified (narrowed) by specifying a value
-   for the selector prior to the type.  For example, an
-
-       orange VariantRecord
-
-   is a narrowed type of a VariantRecord containing a variant_body of
-   type V2.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 10]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-4.7. Cryptographic Attributes
-
-   The four cryptographic operations digital signing, stream cipher
-   encryption, block cipher encryption, and public key encryption are
-   designated digitally-signed, stream-ciphered, block-ciphered, and
-   public-key-encrypted, respectively.  A field's cryptographic
-   processing is specified by prepending an appropriate key word
-   designation before the field's type specification.  Cryptographic
-   keys are implied by the current session state (see Section 6.1).
-
-   In digital signing, one-way hash functions are used as input for a
-   signing algorithm.  A digitally-signed element is encoded as an
-   opaque vector <0..2^16-1>, where the length is specified by the
-   signing algorithm and key.
-
-   In RSA signing, a 36-byte structure of two hashes (one SHA and one
-   MD5) is signed (encrypted with the private key).  It is encoded with
-   PKCS #1 block type 1, as described in [PKCS1A].
-
-   Note: The standard reference for PKCS#1 is now RFC 3447 [PKCS1B].
-         However, to minimize differences with TLS 1.0 text, we are
-         using the terminology of RFC 2313 [PKCS1A].
-
-   In DSS, the 20 bytes of the SHA hash are run directly through the
-   Digital Signing Algorithm with no additional hashing.  This produces
-   two values, r and s.  The DSS signature is an opaque vector, as
-   above, the contents of which are the DER encoding of:
-
-       Dss-Sig-Value  ::=  SEQUENCE  {
-            r       INTEGER,
-            s       INTEGER
-       }
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext.  All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key.  A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the signing
-   algorithm and key.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 11]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   An RSA-encrypted value is encoded with PKCS #1 block type 2, as
-   described in [PKCS1A].
-
-   In the following example,
-
-       stream-ciphered struct {
-           uint8 field1;
-           uint8 field2;
-           digitally-signed opaque hash[20];
-       } UserType;
-
-   the contents of hash are used as input for the signing algorithm, and
-   then the entire structure is encrypted with a stream cipher.  The
-   length of this structure, in bytes, would be equal to two bytes for
-   field1 and field2, plus two bytes for the length of the signature,
-   plus the length of the output of the signing algorithm.  This is
-   known because the algorithm and key used for the signing are known
-   prior to encoding or decoding this structure.
-
-4.8. Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-   Under-specified types (opaque, variable length vectors, and
-   structures that contain opaque) cannot be assigned values.  No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-       struct {
-           uint8 f1;
-           uint8 f2;
-       } Example1;
-
-       Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5. HMAC and the Pseudorandom Function
-
-   A number of operations in the TLS record and handshake layer require
-   a keyed MAC; this is a secure digest of some data protected by a
-   secret.  Forging the MAC is infeasible without knowledge of the MAC
-   secret.  The construction we use for this operation is known as HMAC,
-   and is described in [HMAC].
-
-   HMAC can be used with a variety of different hash algorithms.  TLS
-   uses it in the handshake with two different algorithms, MD5 and SHA-
-   1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
-   data).  Additional hash algorithms can be defined by cipher suites
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 12]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   and used to protect record data, but MD5 and SHA-1 are hard coded
-   into the description of the handshaking for this version of the
-   protocol.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudo-random function (PRF) takes as input a secret, a seed,
-   and an identifying label and produces an output of arbitrary length.
-
-   In order to make the PRF as secure as possible, it uses two hash
-   algorithms in a way that should guarantee its security if either
-   algorithm remains secure.
-
-   First, we define a data expansion function, P_hash(secret, data) that
-   uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                              HMAC_hash(secret, A(2) + seed) +
-                              HMAC_hash(secret, A(3) + seed) + ...
-
-   Where + indicates concatenation.
-
-   A() is defined as:
-
-       A(0) = seed
-       A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as is necessary to produce the
-   required quantity of data.  For example, if P_SHA-1 is being used to
-   create 64 bytes of data, it will have to be iterated 4 times (through
-   A(4)), creating 80 bytes of output data; the last 16 bytes of the
-   final iteration will then be discarded, leaving 64 bytes of output
-   data.
-
-   TLS's PRF is created by splitting the secret into two halves and
-   using one half to generate data with P_MD5 and the other half to
-   generate data with P_SHA-1, then exclusive-ORing the outputs of these
-   two expansion functions together.
-
-   S1 and S2 are the two halves of the secret, and each is the same
-   length.  S1 is taken from the first half of the secret, S2 from the
-   second half.  Their length is created by rounding up the length of
-   the overall secret, divided by two; thus, if the original secret is
-   an odd number of bytes long, the last byte of S1 will be the same as
-   the first byte of S2.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 13]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-       L_S = length in bytes of secret;
-       L_S1 = L_S2 = ceil(L_S / 2);
-
-
-   The secret is partitioned into two halves (with the possibility of
-   one shared byte) as described above, S1 taking the first L_S1 bytes,
-   and S2 the last L_S2 bytes.
-
-   The PRF is then defined as the result of mixing the two pseudorandom
-   streams by exclusive-ORing them together.
-
-       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
-                                  P_SHA-1(S2, label + seed);
-
-   The label is an ASCII string.  It should be included in the exact
-   form it is given without a length byte or trailing null character.
-   For example, the label "slithy toves" would be processed by hashing
-   the following bytes:
-
-       73 6C 69 74 68 79 20 74 6F 76 65 73
-
-   Note that because MD5 produces 16-byte outputs and SHA-1 produces
-   20-byte outputs, the boundaries of their internal iterations will not
-   be aligned.  Generating an 80-byte output will require that P_MD5
-   iterate through A(5), while P_SHA-1 will only iterate through A(4).
-
-6. The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol.  At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result.  Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-   higher-level clients.
-
-   Four record protocol clients are described in this document: the
-   handshake protocol, the alert protocol, the change cipher spec
-   protocol, and the application data protocol.  In order to allow
-   extension of the TLS protocol, additional record types can be
-   supported by the record protocol.  Any new record types SHOULD
-   allocate type values immediately beyond the ContentType values for
-   the four record types described here (see Appendix A.1).  All such
-   values must be defined by RFC 2434 Standards Action.  See Section 11
-   for IANA Considerations for ContentType values.
-
-   If a TLS implementation receives a record type it does not
-   understand, it SHOULD just ignore it.  Any protocol designed for use
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 14]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   over TLS MUST be carefully designed to deal with all possible attacks
-   against it.  Note that because the type and length of a record are
-   not protected by encryption, care SHOULD be taken to minimize the
-   value of traffic analysis of these values.
-
-6.1. Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol.  It specifies a compression algorithm, and encryption
-   algorithm, and a MAC algorithm.  In addition, the parameters for
-   these algorithms are known: the MAC secret and the bulk encryption
-   keys for the connection in both the read and the write directions.
-   Logically, there are always four connection states outstanding: the
-   current read and write states, and the pending read and write states.
-   All records are processed under the current read and write states.
-   The security parameters for the pending states can be set by the TLS
-   Handshake Protocol, and the Change Cipher Spec can selectively make
-   either of the pending states current, in which case the appropriate
-   current state is disposed of and replaced with the pending state; the
-   pending state is then reinitialized to an empty state.  It is illegal
-   to make a state that has not been initialized with security
-   parameters a current state.  The initial current state always
-   specifies that no encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-      Whether this entity is considered the "client" or the "server" in
-      this connection.
-
-   bulk encryption algorithm
-      An algorithm to be used for bulk encryption.  This specification
-      includes the key size of this algorithm, how much of that key is
-      secret, whether it is a block or stream cipher, and the block size
-      of the cipher (if appropriate).
-
-   MAC algorithm
-      An algorithm to be used for message authentication.  This
-      specification includes the size of the hash returned by the MAC
-      algorithm.
-
-   compression algorithm
-      An algorithm to be used for data compression.  This specification
-      must include all information the algorithm requires compression.
-
-   master secret
-      A 48-byte secret shared between the two peers in the connection.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 15]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   client random
-      A 32-byte value provided by the client.
-
-   server random
-      A 32-byte value provided by the server.
-
-   These parameters are defined in the presentation language as:
-
-       enum { server, client } ConnectionEnd;
-
-       enum { null, rc4, rc2, des, 3des, des40, idea, aes }
-       BulkCipherAlgorithm;
-
-       enum { stream, block } CipherType;
-
-       enum { null, md5, sha } MACAlgorithm;
-
-       enum { null(0), (255) } CompressionMethod;
-
-       /* The algorithms specified in CompressionMethod,
-          BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-       struct {
-           ConnectionEnd          entity;
-           BulkCipherAlgorithm    bulk_cipher_algorithm;
-           CipherType             cipher_type;
-           uint8                  key_size;
-           uint8                  key_material_length;
-           MACAlgorithm           mac_algorithm;
-           uint8                  hash_size;
-           CompressionMethod      compression_algorithm;
-           opaque                 master_secret[48];
-           opaque                 client_random[32];
-           opaque                 server_random[32];
-       } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following four items:
-
-       client write MAC secret
-       server write MAC secret
-       client write key
-       server write key
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice-versa.  The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 16]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states.  These current states MUST be updated for each
-   record processed.  Each connection state includes the following
-   elements:
-
-   compression state
-      The current state of the compression algorithm.
-
-   cipher state
-      The current state of the encryption algorithm.  This will consist
-      of the scheduled key for that connection.  For stream ciphers,
-      this will also contain whatever state information is necessary to
-      allow the stream to continue to encrypt or decrypt data.
-
-   MAC secret
-      The MAC secret for this connection, as generated above.
-
-   sequence number
-      Each connection state contains a sequence number, which is
-      maintained separately for read and write states.  The sequence
-      number MUST be set to zero whenever a connection state is made the
-      active state.  Sequence numbers are of type uint64 and may not
-      exceed 2^64-1.  Sequence numbers do not wrap.  If a TLS
-      implementation would need to wrap a sequence number, it must
-      renegotiate instead.  A sequence number is incremented after each
-      record: specifically, the first record transmitted under a
-      particular connection state MUST use sequence number 0.
-
-6.2. Record layer
-
-   The TLS Record Layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1. Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less.  Client
-   message boundaries are not preserved in the record layer (i.e.,
-   multiple client messages of the same ContentType MAY be coalesced
-   into a single TLSPlaintext record, or a single message MAY be
-   fragmented across several records).
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 17]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-       struct {
-           uint8 major, minor;
-       } ProtocolVersion;
-
-       enum {
-           change_cipher_spec(20), alert(21), handshake(22),
-           application_data(23), (255)
-       } ContentType;
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           opaque fragment[TLSPlaintext.length];
-       } TLSPlaintext;
-
-   type
-      The higher-level protocol used to process the enclosed fragment.
-
-   version
-      The version of the protocol being employed.  This document
-      describes TLS Version 1.1, which uses the version { 3, 2 }.  The
-      version value 3.2 is historical: TLS version 1.1 is a minor
-      modification to the TLS 1.0 protocol, which was itself a minor
-      modification to the SSL 3.0 protocol, which bears the version
-      value 3.0.  (See Appendix A.1.)
-
-   length
-      The length (in bytes) of the following TLSPlaintext.fragment.  The
-      length should not exceed 2^14.
-
-   fragment
-      The application data.  This data is transparent and is treated as
-      an independent block to be dealt with by the higher-level protocol
-      specified by the type field.
-
-   Note: Data of different TLS Record layer content types MAY be
-   interleaved.  Application data is generally of lower precedence for
-   transmission than other content types.  However, records MUST be
-   delivered to the network in the same order as they are protected by
-   the record layer.  Recipients MUST receive and process interleaved
-   application layer traffic during handshakes subsequent to the first
-   one on a connection.
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 18]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-6.2.2. Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state.  There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null.  The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure.  Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes.  If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it should report a fatal decompression failure error.
-
-       struct {
-           ContentType type;       /* same as TLSPlaintext.type */
-           ProtocolVersion version;/* same as TLSPlaintext.version */
-           uint16 length;
-           opaque fragment[TLSCompressed.length];
-       } TLSCompressed;
-
-   length
-      The length (in bytes) of the following TLSCompressed.fragment.
-      The length should not exceed 2^14 + 1024.
-
-   fragment
-      The compressed form of TLSPlaintext.fragment.
-
-   Note: A CompressionMethod.null operation is an identity operation; no
-         fields are altered.
-
-   Implementation note: Decompression functions are responsible for
-                        ensuring that messages cannot cause internal
-                        buffer overflows.
-
-6.2.3. Record Payload Protection
-
-   The encryption and MAC functions translate a TLSCompressed structure
-   into a TLSCiphertext.  The decryption functions reverse the process.
-   The MAC of the record also includes a sequence number so that
-   missing, extra, or repeated messages are detectable.
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 19]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-       struct {
-           ContentType type;
-           ProtocolVersion version;
-           uint16 length;
-           select (CipherSpec.cipher_type) {
-               case stream: GenericStreamCipher;
-               case block: GenericBlockCipher;
-           } fragment;
-       } TLSCiphertext;
-
-   type
-      The type field is identical to TLSCompressed.type.
-
-   version
-      The version field is identical to TLSCompressed.version.
-
-   length
-      The length (in bytes) of the following TLSCiphertext.fragment.
-      The length may not exceed 2^14 + 2048.
-
-   fragment
-      The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1. Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null, see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-       stream-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-       } GenericStreamCipher;
-
-   The MAC is generated as:
-
-       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
-                     TLSCompressed.version + TLSCompressed.length +
-                     TLSCompressed.fragment));
-
-   where "+" denotes concatenation.
-
-   seq_num
-      The sequence number for this record.
-
-   hash
-      The hashing algorithm specified by
-      SecurityParameters.mac_algorithm.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 20]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Note that the MAC is computed before encryption.  The stream cipher
-   encrypts the entire block, including the MAC.  For stream ciphers
-   that do not use a synchronization vector (such as RC4), the stream
-   cipher state from the end of one record is simply used on the
-   subsequent packet.  If the CipherSuite is TLS_NULL_WITH_NULL_NULL,
-   encryption consists of the identity operation (i.e., the data is not
-   encrypted, and the MAC size is zero, implying that no MAC is used).
-   TLSCiphertext.length is TLSCompressed.length plus
-   CipherSpec.hash_size.
-
-6.2.3.2. CBC Block Cipher
-
-   For block ciphers (such as RC2, DES, or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-       block-ciphered struct {
-           opaque IV[CipherSpec.block_length];
-           opaque content[TLSCompressed.length];
-           opaque MAC[CipherSpec.hash_size];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-      Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-      IV in order to prevent the attacks described by [CBCATT].  We
-      recommend the following equivalently strong procedures.  For
-      clarity we use the following notation.
-
-      IV
-         The transmitted value of the IV field in the GenericBlockCipher
-         structure.
-
-      CBC residue
-         The last ciphertext block of the previous record.
-
-      mask
-         The actual value that the cipher XORs with the plaintext prior
-         to encryption of the first cipher block of the record.
-
-      In prior versions of TLS, there was no IV field and the CBC
-      residue and mask were one and the same.  See Sections 6.1,
-      6.2.3.2, and 6.3, of [TLS1.0] for details of TLS 1.0 IV handling.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 21]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      One of the following two algorithms SHOULD be used to generate the
-      per-record IV:
-
-      (1) Generate a cryptographically strong random string R of length
-          CipherSpec.block_length.  Place R in the IV field.  Set the
-          mask to R.  Thus, the first cipher block will be encrypted as
-          E(R XOR Data).
-
-      (2) Generate a cryptographically strong random number R of length
-          CipherSpec.block_length and prepend it to the plaintext prior
-          to encryption.  In this case either:
-
-          (a) The cipher may use a fixed mask such as zero.
-          (b) The CBC residue from the previous record may be used as
-              the mask.  This preserves maximum code compatibility with
-              TLS 1.0 and SSL 3.  It also has the advantage that it does
-              not require the ability to quickly reset the IV, which is
-              known to be a problem on some systems.
-
-          In either (2)(a) or (2)(b) the data (R || data) is fed into
-          the encryption process.  The first cipher block (containing
-          E(mask XOR R) is placed in the IV field.  The first block of
-          content contains E(IV XOR data).
-
-      The following alternative procedure MAY be used; however, it has
-      not been demonstrated to be as cryptographically strong as the
-      above procedures.  The sender prepends a fixed block F to the
-      plaintext (or, alternatively, a block generated with a weak PRNG).
-      He then encrypts as in (2), above, using the CBC residue from the
-      previous block as the mask for the prepended block.  Note that in
-      this case the mask for the first record transmitted by the
-      application (the Finished) MUST be generated using a
-      cryptographically strong PRNG.
-
-      The decryption operation for all three alternatives is the same.
-      The receiver decrypts the entire GenericBlockCipher structure and
-      then discards the first cipher block, corresponding to the IV
-      component.
-
-   padding
-      Padding that is added to force the length of the plaintext to be
-      an integral multiple of the block cipher's block length.  The
-      padding MAY be any length up to 255 bytes, as long as it results
-      in the TLSCiphertext.length being an integral multiple of the
-      block length.  Lengths longer than necessary might be desirable to
-      frustrate attacks on a protocol that are based on analysis of the
-      lengths of exchanged messages.  Each uint8 in the padding data
-      vector MUST be filled with the padding length value.  The receiver
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 22]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      MUST check this padding and SHOULD use the bad_record_mac alert to
-      indicate padding errors.
-
-   padding_length
-      The padding length MUST be such that the total size of the
-      GenericBlockCipher structure is a multiple of the cipher's block
-      length.  Legal values range from zero to 255, inclusive.  This
-      length specifies the length of the padding field exclusive of the
-      padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of CipherSpec.block_length, TLSCompressed.length,
-   CipherSpec.hash_size, and padding_length.
-
-   Example: If the block length is 8 bytes, the content length
-            (TLSCompressed.length) is 61 bytes, and the MAC length is 20
-            bytes, then the length before padding is 82 bytes (this does
-            not include the IV, which may or may not be encrypted, as
-            discussed above).  Thus, the padding length modulo 8 must be
-            equal to 6 in order to make the total length an even
-            multiple of 8 bytes (the block length).  The padding length
-            can be 6, 14, 22, and so on, through 254.  If the padding
-            length were the minimum necessary, 6, the padding would be 6
-            bytes, each containing the value 6.  Thus, the last 8 octets
-            of the GenericBlockCipher before block encryption would be
-            xx 06 06 06 06 06 06 06, where xx is the last octet of the
-            MAC.
-
-   Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
-         critical that the entire plaintext of the record be known
-         before any ciphertext is transmitted.  Otherwise, it is
-         possible for the attacker to mount the attack described in
-         [CBCATT].
-
-   Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
-                        timing attack on CBC padding based on the time
-                        required to compute the MAC.  In order to defend
-                        against this attack, implementations MUST ensure
-                        that record processing time is essentially the
-                        same whether or not the padding is correct.  In
-                        general, the best way to do this is to compute
-                        the MAC even if the padding is incorrect, and
-                        only then reject the packet.  For instance, if
-                        the pad appears to be incorrect, the
-                        implementation might assume a zero-length pad
-                        and then compute the MAC.  This leaves a small
-                        timing channel, since MAC performance depends to
-                        some extent on the size of the data fragment,
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 23]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-                        but it is not believed to be large enough to be
-                        exploitable, due to the large block size of
-                        existing MACs and the small size of the timing
-                        signal.
-
-6.3. Key Calculation
-
-   The Record Protocol requires an algorithm to generate keys, and MAC
-   secrets from the security parameters provided by the handshake
-   protocol.
-
-   The master secret is hashed into a sequence of secure bytes, which
-   are assigned to the MAC secrets and keys required by the current
-   connection state (see Appendix A.6).  CipherSpecs require a client
-   write MAC secret, a server write MAC secret, a client write key, and
-   a server write key, each of which is generated from the master secret
-   in that order.  Unused values are empty.
-
-   When keys and MAC secrets are generated, the master secret is used as
-   an entropy source.
-
-   To generate the key material, compute
-
-       key_block = PRF(SecurityParameters.master_secret,
-                          "key expansion",
-                          SecurityParameters.server_random +
-             SecurityParameters.client_random);
-
-   until enough output has been generated.  Then the key_block is
-   partitioned as follows:
-
-       client_write_MAC_secret[SecurityParameters.hash_size]
-       server_write_MAC_secret[SecurityParameters.hash_size]
-       client_write_key[SecurityParameters.key_material_length]
-       server_write_key[SecurityParameters.key_material_length]
-
-   Implementation note: The currently defined cipher suite that requires
-   the most material is AES_256_CBC_SHA, defined in [TLSAES].  It
-   requires 2 x 32 byte keys, 2 x 20 byte MAC secrets, and 2 x 16 byte
-   Initialization Vectors, for a total of 136 bytes of key material.
-
-7. The TLS Handshaking Protocols
-
-   TLS has three subprotocols that are used to allow peers to agree upon
-   security parameters for the record layer, to authenticate themselves,
-   to instantiate negotiated security parameters, and to report error
-   conditions to each other.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 24]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   The Handshake Protocol is responsible for negotiating a session,
-   which consists of the following items:
-
-   session identifier
-      An arbitrary byte sequence chosen by the server to identify an
-      active or resumable session state.
-
-   peer certificate
-      X509v3 [X509] certificate of the peer.  This element of the state
-      may be null.
-
-   compression method
-      The algorithm used to compress data prior to encryption.
-
-   cipher spec
-      Specifies the bulk data encryption algorithm (such as null, DES,
-      etc.) and a MAC algorithm (such as MD5 or SHA).  It also defines
-      cryptographic attributes such as the hash_size.  (See Appendix A.6
-      for formal definition.)
-
-   master secret
-      48-byte secret shared between the client and server.
-
-   is resumable
-      A flag indicating whether the session can be used to initiate new
-      connections.
-
-   These items are then used to create security parameters for use by
-   the Record Layer when protecting application data.  Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1. Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies.  The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state.  The message consists of a single byte of value 1.
-
-       struct {
-           enum { change_cipher_spec(1), (255) } type;
-       } ChangeCipherSpec;
-
-   The change cipher spec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys.  Reception
-   of this message causes the receiver to instruct the Record Layer to
-   immediately copy the read pending state into the read current state.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 25]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-   (See Section 6.1.)  The change cipher spec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying finished message is sent (see Section 7.4.9).
-
-   Note: If a rehandshake occurs while data is flowing on a connection,
-         the communicating parties may continue to send data using the
-         old CipherSpec.  However, once the ChangeCipherSpec has been
-         sent, the new CipherSpec MUST be used.  The first side to send
-         the ChangeCipherSpec does not know that the other side has
-         finished computing the new keying material (e.g., if it has to
-         perform a time consuming public key operation).  Thus, a small
-         window of time, during which the recipient must buffer the
-         data, MAY exist.  In practice, with modern machines this
-         interval is likely to be fairly short.
-
-7.2. Alert Protocol
-
-         One of the content types supported by the TLS Record layer is
-         the alert type.  Alert messages convey the severity of the
-         message and a description of the alert.  Alert messages with a
-         level of fatal result in the immediate termination of the
-         connection.  In this case, other connections corresponding to
-         the session may continue, but the session identifier MUST be
-         invalidated, preventing the failed session from being used to
-         establish new connections.  Like other messages, alert messages
-         are encrypted and compressed, as specified by the current
-         connection state.
-
-             enum { warning(1), fatal(2), (255) } AlertLevel;
-
-             enum {
-                 close_notify(0),
-                 unexpected_message(10),
-                 bad_record_mac(20),
-                 decryption_failed(21),
-                 record_overflow(22),
-                 decompression_failure(30),
-                 handshake_failure(40),
-                 no_certificate_RESERVED (41),
-                 bad_certificate(42),
-                 unsupported_certificate(43),
-                 certificate_revoked(44),
-                 certificate_expired(45),
-                 certificate_unknown(46),
-                 illegal_parameter(47),
-                 unknown_ca(48),
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 26]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-                 access_denied(49),
-                 decode_error(50),
-                 decrypt_error(51),
-                 export_restriction_RESERVED(60),
-                 protocol_version(70),
-                 insufficient_security(71),
-                 internal_error(80),
-                 user_canceled(90),
-                 no_renegotiation(100),
-                 (255)
-             } AlertDescription;
-
-             struct {
-                 AlertLevel level;
-                 AlertDescription description;
-             } Alert;
-
-7.2.1. Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack.  Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-      This message notifies the recipient that the sender will not send
-      any more messages on this connection.  Note that as of TLS 1.1,
-      failure to properly close a connection no longer requires that a
-      session not be resumed.  This is a change from TLS 1.0 to conform
-      with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection.  The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes.  It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended.  If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 27]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   transport without waiting for the responding close_notify.  No part
-   of this standard should be taken to dictate the manner in which a
-   usage profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-         pending data before destroying the transport.
-
-7.2.2. Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple.  When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection.  Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection.  Thus, any connection terminated with a fatal
-   alert MUST NOT be resumed.  The following error alerts are defined:
-
-   unexpected_message
-      An inappropriate message was received.  This alert is always fatal
-      and should never be observed in communication between proper
-      implementations.
-
-   bad_record_mac
-      This alert is returned if a record is received with an incorrect
-      MAC.  This alert also MUST be returned if an alert is sent because
-      a TLSCiphertext decrypted in an invalid way: either it wasn't an
-      even multiple of the block length, or its padding values, when
-      checked, weren't correct.  This message is always fatal.
-
-   decryption_failed
-      This alert MAY be returned if a TLSCiphertext decrypted in an
-      invalid way: either it wasn't an even multiple of the block
-      length, or its padding values, when checked, weren't correct.
-      This message is always fatal.
-
-   Note: Differentiating between bad_record_mac and decryption_failed
-         alerts may permit certain attacks against CBC mode as used in
-         TLS [CBCATT].  It is preferable to uniformly use the
-         bad_record_mac alert to hide the specific type of the error.
-
-   record_overflow
-         A TLSCiphertext record was received that had a length more than
-         2^14+2048 bytes, or a record decrypted to a TLSCompressed
-         record with more than 2^14+1024 bytes.  This message is always
-         fatal.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 28]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   decompression_failure
-         The decompression function received improper input (e.g., data
-         that would expand to excessive length).  This message is always
-         fatal.
-
-   handshake_failure
-         Reception of a handshake_failure alert message indicates that
-         the sender was unable to negotiate an acceptable set of
-         security parameters given the options available.  This is a
-         fatal error.
-
-   no_certificate_RESERVED
-         This alert was used in SSLv3 but not in TLS.  It should not be
-         sent by compliant implementations.
-
-   bad_certificate
-         A certificate was corrupt, contained signatures that did not
-         verify correctly, etc.
-
-   unsupported_certificate
-         A certificate was of an unsupported type.
-
-   certificate_revoked
-         A certificate was revoked by its signer.
-
-   certificate_expired
-         A certificate has expired or is not currently valid.
-
-   certificate_unknown
-         Some other (unspecified) issue arose in processing the
-         certificate, rendering it unacceptable.
-
-   illegal_parameter
-         A field in the handshake was out of range or inconsistent with
-         other fields.  This is always fatal.
-
-   unknown_ca
-         A valid certificate chain or partial chain was received, but
-         the certificate was not accepted because the CA certificate
-         could not be located or couldn't be matched with a known,
-         trusted CA.  This message is always fatal.
-
-   access_denied
-         A valid certificate was received, but when access control was
-         applied, the sender decided not to proceed with negotiation.
-         This message is always fatal.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 29]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   decode_error
-         A message could not be decoded because some field was out of
-         the specified range or the length of the message was incorrect.
-         This message is always fatal.
-
-   decrypt_error
-         A handshake cryptographic operation failed, including being
-         unable to correctly verify a signature, decrypt a key exchange,
-         or validate a finished message.
-
-   export_restriction_RESERVED
-         This alert was used in TLS 1.0 but not TLS 1.1.
-
-   protocol_version
-         The protocol version the client has attempted to negotiate is
-         recognized but not supported.  (For example, old protocol
-         versions might be avoided for security reasons).  This message
-         is always fatal.
-
-   insufficient_security
-         Returned instead of handshake_failure when a negotiation has
-         failed specifically because the server requires ciphers more
-         secure than those supported by the client.  This message is
-         always fatal.
-
-   internal_error
-         An internal error unrelated to the peer or the correctness of
-         the protocol (such as a memory allocation failure) makes it
-         impossible to continue.  This message is always fatal.
-
-   user_canceled
-         This handshake is being canceled for some reason unrelated to a
-         protocol failure.  If the user cancels an operation after the
-         handshake is complete, just closing the connection by sending a
-         close_notify is more appropriate.  This alert should be
-         followed by a close_notify.  This message is generally a
-         warning.
-
-   no_renegotiation
-         Sent by the client in response to a hello request or by the
-         server in response to a client hello after initial handshaking.
-         Either of these would normally lead to renegotiation; when that
-         is not appropriate, the recipient should respond with this
-         alert.  At that point, the original requester can decide
-         whether to proceed with the connection.  One case where this
-         would be appropriate is where a server has spawned a process to
-         satisfy a request; the process might receive security
-         parameters (key length, authentication, etc.) at startup and it
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 30]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-         might be difficult to communicate changes to these parameters
-         after that point.  This message is always a warning.
-
-   For all errors where an alert level is not explicitly specified, the
-   sending party MAY determine at its discretion whether this is a fatal
-   error or not; if an alert with a level of warning is received, the
-   receiving party MAY decide at its discretion whether to treat this as
-   a fatal error or not.  However, all messages that are transmitted
-   with a level of fatal MUST be treated as fatal messages.
-
-   New alert values MUST be defined by RFC 2434 Standards Action.  See
-   Section 11 for IANA Considerations for alert values.
-
-7.3. Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS Record
-   Layer.  When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-   The TLS Handshake Protocol involves the following steps:
-
-   -  Exchange hello messages to agree on algorithms, exchange random
-      values, and check for session resumption.
-
-   -  Exchange the necessary cryptographic parameters to allow the
-      client and server to agree on a premaster secret.
-
-   -  Exchange certificates and cryptographic information to allow the
-      client and server to authenticate themselves.
-
-   -  Generate a master secret from the premaster secret and exchanged
-      random values.
-
-   -  Provide security parameters to the record layer.
-
-   -  Allow the client and server to verify that their peer has
-      calculated the same security parameters and that the handshake
-      occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man-in-the-middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support.  The protocol has been designed to
-   minimize this risk, but there are still attacks available.  For
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 31]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection.  The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require.  The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024 bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   However, one SHOULD never send data over a link encrypted with 40-bit
-   security unless one feels that data is worth no more than the effort
-   required to break that encryption.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a client hello message to
-   which the server must respond with a server hello message, or else a
-   fatal error will occur and the connection will fail.  The client
-   hello and server hello are used to establish security enhancement
-   capabilities between client and server.  The client hello and server
-   hello establish the following attributes: Protocol Version, Session
-   ID, Cipher Suite, and Compression Method.  Additionally, two random
-   values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-   The actual key exchange uses up to four messages: the server
-   certificate, the server key exchange, the client certificate, and the
-   client key exchange.  New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret.  This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 48 to 128 bytes in
-   length.
-
-   Following the hello messages, the server will send its certificate,
-   if it is to be authenticated.  Additionally, a server key exchange
-   message may be sent, if it is required (e.g., if the server has no
-   certificate, or if its certificate is for signing only).  If the
-   server is authenticated, it may request a certificate from the
-   client, if that is appropriate to the cipher suite selected.  Next,
-   the server will send the server hello done message, indicating that
-   the hello-message phase of the handshake is complete.  The server
-   will then wait for a client response.  If the server has sent a
-   certificate request message, the client must send the certificate
-   message.  The client key exchange message is now sent, and the
-   content of that message will depend on the public key algorithm
-   selected between the client hello and the server hello.  If the
-   client has sent a certificate with signing ability, a digitally-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 32]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   signed certificate verify message is sent to explicitly verify the
-   certificate.
-
-
-   At this point, a change cipher spec message is sent by the client,
-   and the client copies the pending Cipher Spec into the current Cipher
-   Spec.  The client then immediately sends the finished message under
-   the new algorithms, keys, and secrets.  In response, the server will
-   send its own change cipher spec message, transfer the pending to the
-   current Cipher Spec, and send its finished message under the new
-   Cipher Spec.  At this point, the handshake is complete, and the
-   client and server may begin to exchange application layer data.  (See
-   flow chart below.)  Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other
-   TLS_NULL_WITH_NULL_NULL is established).
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Fig. 1. Message flow for a full handshake
-
-      * Indicates optional or situation-dependent messages that are not
-        always sent.
-
-   Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-         independent TLS Protocol content type, and is not actually a
-         TLS handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed.  The server then checks its session cache for a match.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 33]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   If a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value.  At this point, both
-   client and server MUST send change cipher spec messages and proceed
-   directly to finished messages.  Once the re-establishment is
-   complete, the client and server MAY begin to exchange application
-   layer data.  (See flow chart below.)  If a Session ID match is not
-   found, the server generates a new session ID and the TLS client and
-   server perform a full handshake.
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Fig. 2. Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4. Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol.  This protocol is used to negotiate the
-   secure attributes of a session.  Handshake messages are supplied to
-   the TLS Record Layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 34]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-          } body;
-      } Handshake;
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error.  Unneeded handshake messages can be
-   omitted, however.  Note one exception to the ordering: the
-   Certificate message is used twice in the handshake (from server to
-   client, then from client to server), but is described only in its
-   first position.  The one message that is not bound by these ordering
-   rules is the Hello Request message, which can be sent at any time,
-   but which should be ignored by the client if it arrives in the middle
-   of a handshake.
-
-   New Handshake message type values MUST be defined via RFC 2434
-   Standards Action.  See Section 11 for IANA Considerations for these
-   values.
-
-7.4.1. Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server.  When a new session
-   begins, the Record Layer's connection state encryption, hash, and
-   compression algorithms are initialized to null.  The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1. Hello request
-
-   When this message will be sent:
-
-      The hello request message MAY be sent by the server at any time.
-
-   Meaning of this message:
-
-      Hello request is a simple notification that the client should
-      begin the negotiation process anew by sending a client hello
-      message when convenient.  This message will be ignored by the
-      client if the client is currently negotiating a session.  This
-      message may be ignored by the client if it does not wish to
-      renegotiate a session, or the client may, if it wishes, respond
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 35]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      with a no_renegotiation alert.  Since handshake messages are
-      intended to have transmission precedence over application data, it
-      is expected that the negotiation will begin before no more than a
-      few records are received from the client.  If the server sends a
-      hello request but does not receive a client hello in response, it
-      may close the connection with a fatal alert.
-
-      After sending a hello request, servers SHOULD not repeat the
-      request until the subsequent handshake negotiation is complete.
-
-         Structure of this message:
-
-             struct { } HelloRequest;
-
-   Note: This message MUST NOT be included in the message hashes that
-         are maintained throughout the handshake and used in the
-         finished messages and the certificate verify message.
-
-7.4.1.2. Client Hello
-
-   When this message will be sent:
-
-      When a client first connects to a server it is required to send
-      the client hello as its first message.  The client can also send a
-      client hello in response to a hello request or on its own
-      initiative in order to renegotiate the security parameters in an
-      existing connection.
-
-   Structure of this message:
-
-      The client hello message includes a random structure, which is
-      used later in the protocol.
-
-      struct {
-         uint32 gmt_unix_time;
-         opaque random_bytes[28];
-      } Random;
-
-   gmt_unix_time The current time and date in standard UNIX 32-bit
-      format (seconds since the midnight starting Jan 1, 1970, GMT,
-      ignoring leap seconds) according to the sender's internal clock.
-      Clocks are not required to be set correctly by the basic TLS
-      Protocol; higher-level or application protocols may define
-      additional requirements.
-
-         random_bytes
-             28 bytes generated by a secure random number generator.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 36]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   The client hello message includes a variable-length session
-   identifier.  If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse.  The session identifier MAY be from an earlier connection,
-   from this connection, or from another currently active connection.
-   The second option is useful if the client only wishes to update the
-   random structures and derived values of a connection, and the third
-   option makes it possible to establish several independent secure
-   connections without repeating the full handshake protocol.  These
-   independent connections may occur sequentially or simultaneously; a
-   SessionID becomes valid when the handshake negotiating it completes
-   with the exchange of Finished messages and persists until it is
-   removed due to aging or because a fatal error was encountered on a
-   connection associated with the session.  The actual contents of the
-   SessionID are defined by the server.
-
-      opaque SessionID<0..32>;
-
-   Warning: Because the SessionID is transmitted without encryption or
-            immediate MAC protection, servers MUST not place
-            confidential information in session identifiers or let the
-            contents of fake session identifiers cause any breach of
-            security.  (Note that the content of the handshake as a
-            whole, including the SessionID, is protected by the Finished
-            messages exchanged at the end of the handshake.)
-
-   The CipherSuite list, passed from the client to the server in the
-   client hello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first).  Each CipherSuite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), and a MAC algorithm.  The server will select a cipher suite
-   or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.
-
-      uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The client hello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 37]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      enum { null(0), (255) } CompressionMethod;
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-1>;
-          CompressionMethod compression_methods<1..2^8-1>;
-      } ClientHello;
-
-   client_version
-      The version of the TLS protocol by which the client wishes to
-      communicate during this session.  This SHOULD be the latest
-      (highest valued) version supported by the client.  For this
-      version of the specification, the version will be 3.2.  (See
-      Appendix E for details about backward compatibility.)
-
-   random
-      A client-generated random structure.
-
-   session_id
-      The ID of a session the client wishes to use for this connection.
-      This field should be empty if no session_id is available or if the
-      client wishes to generate new security parameters.
-
-   cipher_suites
-      This is a list of the cryptographic options supported by the
-      client, with the client's first preference first.  If the
-      session_id field is not empty (implying a session resumption
-      request) this vector MUST include at least the cipher_suite from
-      that session.  Values are defined in Appendix A.5.
-
-   compression_methods
-      This is a list of the compression methods supported by the client,
-      sorted by client preference.  If the session_id field is not empty
-      (implying a session resumption request) it MUST include the
-      compression_method from that session.  This vector MUST contain,
-      and all implementations MUST support, CompressionMethod.null.
-      Thus, a client and server will always be able to agree on a
-      compression method.
-
-   After sending the client hello message, the client waits for a server
-   hello message.  Any other handshake message returned by the server
-   except for a hello request is treated as a fatal error.
-
-   Forward compatibility note:  In the interests of forward
-   compatibility, it is permitted that a client hello message include
-   extra data after the compression methods.  This data MUST be included
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 38]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   in the handshake hashes, but must otherwise be ignored.  This is the
-   only handshake message for which this is legal; for all other
-   messages, the amount of data in the message MUST match the
-   description of the message precisely.
-
-      Note: For the intended use of trailing data in the ClientHello,
-         see RFC 3546 [TLSEXT].
-
-7.4.1.3. Server Hello
-
-   The server will send this message in response to a client hello
-   message when it was able to find an acceptable set of algorithms.  If
-   it cannot find such a match, it will respond with a handshake failure
-   alert.
-
-   Structure of this message:
-
-       struct {
-           ProtocolVersion server_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suite;
-           CompressionMethod compression_method;
-       } ServerHello;
-
-   server_version
-      This field will contain the lower of that suggested by the client
-      in the client hello and the highest supported by the server.  For
-      this version of the specification, the version is 3.2.  (See
-      Appendix E for details about backward compatibility.)
-
-   random
-      This structure is generated by the server and MUST be
-      independently generated from the ClientHello.random.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 39]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   session_id
-      This is the identity of the session corresponding to this
-      connection.  If the ClientHello.session_id was non-empty, the
-      server will look in its session cache for a match.  If a match is
-      found and the server is willing to establish the new connection
-      using the specified session state, the server will respond with
-      the same value as was supplied by the client.  This indicates a
-      resumed session and dictates that the parties must proceed
-      directly to the finished messages.  Otherwise this field will
-      contain a different value identifying the new session.  The server
-      may return an empty session_id to indicate that the session will
-      not be cached and therefore cannot be resumed.  If a session is
-      resumed, it must be resumed using the same cipher suite it was
-      originally negotiated with.
-
-   cipher_suite
-      The single cipher suite selected by the server from the list in
-      ClientHello.cipher_suites.  For resumed sessions, this field is
-      the value from the state of the session being resumed.
-
-   compression_method The single compression algorithm selected by the
-      server from the list in ClientHello.compression_methods.  For
-      resumed sessions this field is the value from the resumed session
-      state.
-
-7.4.2. Server Certificate
-
-   When this message will be sent:
-
-      The server MUST send a certificate whenever the agreed-upon key
-      exchange method is not an anonymous one.  This message will always
-      immediately follow the server hello message.
-
-   Meaning of this message:
-
-      The certificate type MUST be appropriate for the selected cipher
-      suite's key exchange algorithm, and is generally an X.509v3
-      certificate.  It MUST contain a key that matches the key exchange
-      method, as follows.  Unless otherwise specified, the signing
-      algorithm for the certificate MUST be the same as the algorithm
-      for the certificate key.  Unless otherwise specified, the public
-      key MAY be of any length.
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 40]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      Key Exchange Algorithm  Certificate Key Type
-
-      RSA                     RSA public key; the certificate MUST
-                              allow the key to be used for encryption.
-
-      DHE_DSS                 DSS public key.
-
-      DHE_RSA                 RSA public key that can be used for
-                              signing.
-
-      DH_DSS                  Diffie-Hellman key. The algorithm used
-                              to sign the certificate MUST be DSS.
-
-      DH_RSA                  Diffie-Hellman key. The algorithm used
-                              to sign the certificate MUST be RSA.
-
-   All certificate profiles and key and cryptographic formats are
-   defined by the IETF PKIX working group [PKIX].  When a key usage
-   extension is present, the digitalSignature bit MUST be set for the
-   key to be eligible for signing, as described above, and the
-   keyEncipherment bit MUST be present to allow encryption, as described
-   above.  The keyAgreement bit must be set on Diffie-Hellman
-   certificates.
-
-   As CipherSuites that specify new key exchange methods are specified
-   for the TLS Protocol, they will imply certificate format and the
-   required encoded keying information.
-
-   Structure of this message:
-
-      opaque ASN.1Cert<1..2^24-1>;
-
-      struct {
-          ASN.1Cert certificate_list<0..2^24-1>;
-      } Certificate;
-
-   certificate_list
-      This is a sequence (chain) of X.509v3 certificates.  The sender's
-      certificate must come first in the list.  Each following
-      certificate must directly certify the one preceding it.  Because
-      certificate validation requires that root keys be distributed
-      independently, the self-signed certificate that specifies the root
-      certificate authority may optionally be omitted from the chain,
-      under the assumption that the remote end must already possess it
-      in order to validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message.  Note that a client MAY
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 41]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
-      Note: PKCS #7 [PKCS7] is not used as the format for the
-         certificate vector because PKCS #6 [PKCS6] extended
-         certificates are not used.  Also, PKCS #7 defines a SET rather
-         than a SEQUENCE, making the task of parsing the list more
-         difficult.
-
-7.4.3. Server Key Exchange Message
-
-   When this message will be sent:
-
-      This message will be sent immediately after the server certificate
-      message (or the server hello message, if this is an anonymous
-      negotiation).
-
-      The server key exchange message is sent by the server only when
-      the server certificate message (if sent) does not contain enough
-      data to allow the client to exchange a premaster secret.  This is
-      true for the following key exchange methods:
-
-           DHE_DSS
-           DHE_RSA
-           DH_anon
-
-      It is not legal to send the server key exchange message for the
-      following key exchange methods:
-
-           RSA
-           DH_DSS
-           DH_RSA
-
-   Meaning of this message:
-
-      This message conveys cryptographic information to allow the client
-      to communicate the premaster secret: either an RSA public key with
-      which to encrypt the premaster secret, or a Diffie-Hellman public
-      key with which the client can complete a key exchange (with the
-      result being the premaster secret).
-
-   As additional CipherSuites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 42]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Structure of this message:
-
-      enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-      struct {
-          opaque rsa_modulus<1..2^16-1>;
-          opaque rsa_exponent<1..2^16-1>;
-      } ServerRSAParams;
-
-      rsa_modulus
-          The modulus of the server's temporary RSA key.
-
-      rsa_exponent
-          The public exponent of the server's temporary RSA key.
-
-      struct {
-          opaque dh_p<1..2^16-1>;
-          opaque dh_g<1..2^16-1>;
-          opaque dh_Ys<1..2^16-1>;
-      } ServerDHParams;     /* Ephemeral DH parameters */
-
-      dh_p
-          The prime modulus used for the Diffie-Hellman operation.
-
-      dh_g
-          The generator used for the Diffie-Hellman operation.
-
-      dh_Ys
-        The server's Diffie-Hellman public value (g^X mod p).
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                  ServerDHParams params;
-                  Signature signed_params;
-              case rsa:
-                  ServerRSAParams params;
-                  Signature signed_params;
-          };
-      } ServerKeyExchange;
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 43]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                  ServerDHParams params;
-              case rsa:
-                  ServerRSAParams params;
-          };
-       } ServerParams;
-
-      params
-          The server's key exchange parameters.
-
-      signed_params
-          For non-anonymous key exchanges, a hash of the corresponding
-          params value, with the signature appropriate to that hash
-          applied.
-
-      md5_hash
-          MD5(ClientHello.random + ServerHello.random + ServerParams);
-
-      sha_hash
-          SHA(ClientHello.random + ServerHello.random + ServerParams);
-
-      enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-
-      struct {
-          select (SignatureAlgorithm) {
-              case anonymous: struct { };
-              case rsa:
-                  digitally-signed struct {
-                      opaque md5_hash[16];
-                      opaque sha_hash[20];
-                  };
-              case dsa:
-                  digitally-signed struct {
-                      opaque sha_hash[20];
-                  };
-              };
-          };
-      } Signature;
-
-7.4.4. Certificate request
-
-   When this message will be sent:
-
-      A non-anonymous server can optionally request a certificate from
-      the client, if it is appropriate for the selected cipher suite.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 44]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      This message, if sent, will immediately follow the Server Key
-      Exchange message (if it is sent; otherwise, the Server Certificate
-      message).
-
-   Structure of this message:
-
-      enum {
-          rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-       fortezza_dms_RESERVED(20),
-          (255)
-
-      } ClientCertificateType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-      struct {
-          ClientCertificateType certificate_types<1..2^8-1>;
-          DistinguishedName certificate_authorities<0..2^16-1>;
-      } CertificateRequest;
-
-      certificate_types
-         This field is a list of the types of certificates requested,
-         sorted in order of the server's preference.
-
-      certificate_authorities
-         A list of the distinguished names of acceptable certificate
-         authorities.  These distinguished names may specify a desired
-         distinguished name for a root CA or for a subordinate CA; thus,
-         this message can be used to describe both known roots and a
-         desired authorization space.  If the certificate_authorities
-         list is empty then the client MAY send any certificate of the
-         appropriate ClientCertificateType, unless there is some
-         external arrangement to the contrary.
-
-   ClientCertificateType values are divided into three groups:
-
-      1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
-         reserved for IETF Standards Track protocols.
-
-      2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
-         inclusive are reserved for assignment for non-Standards Track
-         methods.
-
-      3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
-         inclusive are reserved for private use.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 45]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Additional information describing the role of IANA in the allocation
-   of ClientCertificateType code points is described in Section 11.
-
-   Note: Values listed as RESERVED may not be used.  They were used in
-         SSLv3.
-
-   Note: DistinguishedName is derived from [X501].  DistinguishedNames
-         are represented in DER-encoded format.
-
-   Note: It is a fatal handshake_failure alert for an anonymous server
-         to request client authentication.
-
-7.4.5. Server Hello Done
-
-   When this message will be sent:
-
-      The server hello done message is sent by the server to indicate
-      the end of the server hello and associated messages.  After
-      sending this message, the server will wait for a client response.
-
-   Meaning of this message:
-
-      This message means that the server is done sending messages to
-      support the key exchange, and the client can proceed with its
-      phase of the key exchange.
-
-      Upon receipt of the server hello done message, the client SHOULD
-      verify that the server provided a valid certificate, if required
-      and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-
-      struct { } ServerHelloDone;
-
-7.4.6. Client certificate
-
-   When this message will be sent:
-
-      This is the first message the client can send after receiving a
-      server hello done message.  This message is only sent if the
-      server requests a certificate.  If no suitable certificate is
-      available, the client SHOULD send a certificate message containing
-      no certificates.  That is, the certificate_list structure has a
-      length of zero.  If client authentication is required by the
-      server for the handshake to continue, it may respond with a fatal
-      handshake failure alert.  Client certificates are sent using the
-      Certificate structure defined in Section 7.4.2.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 46]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Note: When using a static Diffie-Hellman based key exchange method
-      (DH_DSS or DH_RSA), if client authentication is requested, the
-      Diffie-Hellman group and generator encoded in the client's
-      certificate MUST match the server specified Diffie-Hellman
-      parameters if the client's parameters are to be used for the key
-      exchange.
-
-7.4.7. Client Key Exchange Message
-
-   When this message will be sent:
-
-      This message is always sent by the client.  It MUST immediately
-      follow the client certificate message, if it is sent.  Otherwise
-      it MUST be the first message sent by the client after it receives
-      the server hello done message.
-
-   Meaning of this message:
-
-      With this message, the premaster secret is set, either though
-      direct transmission of the RSA-encrypted secret or by the
-      transmission of Diffie-Hellman parameters that will allow each
-      side to agree upon the same premaster secret.  When the key
-      exchange method is DH_RSA or DH_DSS, client certification has been
-      requested, and the client was able to respond with a certificate
-      that contained a Diffie-Hellman public key whose parameters (group
-      and generator) matched those specified by the server in its
-      certificate, this message MUST not contain any data.
-
-   Structure of this message:
-
-      The choice of messages depends on which key exchange method has
-      been selected.  See Section 7.4.3 for the KeyExchangeAlgorithm
-      definition.
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-7.4.7.1. RSA Encrypted Premaster Secret Message
-
-   Meaning of this message:
-
-      If RSA is being used for key agreement and authentication, the
-      client generates a 48-byte premaster secret, encrypts it using the
-      public key from the server's certificate or the temporary RSA key
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 47]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      provided in a server key exchange message, and sends the result in
-      an encrypted premaster secret message.  This structure is a
-      variant of the client key exchange message and is not a message in
-      itself.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion client_version;
-          opaque random[46];
-      } PreMasterSecret;
-
-      client_version The latest (newest) version supported by the
-         client.  This is used to detect version roll-back attacks.
-         Upon receiving the premaster secret, the server SHOULD check
-         that this value matches the value transmitted by the client in
-         the client hello message.
-
-      random
-          46 securely-generated random bytes.
-
-      struct {
-          public-key-encrypted PreMasterSecret pre_master_secret;
-      } EncryptedPreMasterSecret;
-
-      pre_master_secret
-          This random value is generated by the client and is used to
-          generate the master secret, as specified in Section 8.1.
-
-   Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be
-         used to attack a TLS server that is using PKCS#1 v 1.5 encoded
-         RSA.  The attack takes advantage of the fact that, by failing
-         in different ways, a TLS server can be coerced into revealing
-         whether a particular message, when decrypted, is properly
-         PKCS#1 v1.5 formatted or not.
-
-         The best way to avoid vulnerability to this attack is to treat
-         incorrectly formatted messages in a manner indistinguishable
-         from correctly formatted RSA blocks.  Thus, when a server
-         receives an incorrectly formatted RSA block, it should generate
-         a random 48-byte value and proceed using it as the premaster
-         secret.  Thus, the server will act identically whether the
-         received RSA block is correctly encoded or not.
-
-         [PKCS1B] defines a newer version of PKCS#1 encoding that is
-         more secure against the Bleichenbacher attack.  However, for
-         maximal compatibility with TLS 1.0, TLS 1.1 retains the
-         original encoding.  No variants of the Bleichenbacher attack
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 48]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-         are known to exist provided that the above recommendations are
-         followed.
-
-   Implementation Note: Public-key-encrypted data is represented as an
-                        opaque vector <0..2^16-1> (see Section 4.7).
-                        Thus, the RSA-encrypted PreMasterSecret in a
-                        ClientKeyExchange is preceded by two length
-                        bytes.  These bytes are redundant in the case of
-                        RSA because the EncryptedPreMasterSecret is the
-                        only data in the ClientKeyExchange and its
-                        length can therefore be unambiguously
-                        determined.  The SSLv3 specification was not
-                        clear about the encoding of public-key-encrypted
-                        data, and therefore many SSLv3 implementations
-                        do not include the length bytes, encoding the
-                        RSA encrypted data directly in the
-                        ClientKeyExchange message.
-
-                        This specification requires correct encoding of
-                        the EncryptedPreMasterSecret complete with
-                        length bytes.  The resulting PDU is incompatible
-                        with many SSLv3 implementations.  Implementors
-                        upgrading from SSLv3 must modify their
-                        implementations to generate and accept the
-                        correct encoding.  Implementors who wish to be
-                        compatible with both SSLv3 and TLS should make
-                        their implementation's behavior dependent on the
-                        protocol version.
-
-   Implementation Note: It is now known that remote timing-based attacks
-                        on SSL are possible, at least when the client
-                        and server are on the same LAN.  Accordingly,
-                        implementations that use static RSA keys SHOULD
-                        use RSA blinding or some other anti-timing
-                        technique, as described in [TIMING].
-
-   Note: The version number in the PreMasterSecret MUST be the version
-         offered by the client in the ClientHello, not the version
-         negotiated for the connection.  This feature is designed to
-         prevent rollback attacks.  Unfortunately, many implementations
-         use the negotiated version instead, and therefore checking the
-         version number may lead to failure to interoperate with such
-         incorrect client implementations.  Client implementations, MUST
-         and Server implementations MAY, check the version number.  In
-         practice, since the TLS handshake MACs prevent downgrade and no
-         good attacks are known on those MACs, ambiguity is not
-         considered a serious security risk.  Note that if servers
-         choose to check the version number, they should randomize the
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 49]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-         PreMasterSecret in case of error, rather than generate an
-         alert, in order to avoid variants on the Bleichenbacher attack.
-         [KPR03]
-
-7.4.7.2. Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-
-      This structure conveys the client's Diffie-Hellman public value
-      (Yc) if it was not already included in the client's certificate.
-      The encoding used for Yc is determined by the enumerated
-      PublicValueEncoding.  This structure is a variant of the client
-      key exchange message and not a message in itself.
-
-   Structure of this message:
-
-      enum { implicit, explicit } PublicValueEncoding;
-
-      implicit
-          If the client certificate already contains a suitable Diffie-
-          Hellman key, then Yc is implicit and does not need to be sent
-          again.  In this case, the client key exchange message will be
-          sent, but it MUST be empty.
-
-      explicit
-          Yc needs to be sent.
-
-      struct {
-          select (PublicValueEncoding) {
-              case implicit: struct { };
-              case explicit: opaque dh_Yc<1..2^16-1>;
-          } dh_public;
-      } ClientDiffieHellmanPublic;
-
-      dh_Yc
-          The client's Diffie-Hellman public value (Yc).
-
-7.4.8. Certificate verify
-
-   When this message will be sent:
-
-      This message is used to provide explicit verification of a client
-      certificate.  This message is only sent following a client
-      certificate that has signing capability (i.e., all certificates
-      except those containing fixed Diffie-Hellman parameters).  When
-      sent, it MUST immediately follow the client key exchange message.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 50]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Structure of this message:
-
-      struct {
-           Signature signature;
-      } CertificateVerify;
-
-      The Signature type is defined in 7.4.3.
-
-      CertificateVerify.signature.md5_hash
-          MD5(handshake_messages);
-
-      CertificateVerify.signature.sha_hash
-          SHA(handshake_messages);
-
-   Here handshake_messages refers to all handshake messages sent or
-   received starting at client hello up to but not including this
-   message, including the type and length fields of the handshake
-   messages.  This is the concatenation of all the Handshake structures,
-   as defined in 7.4, exchanged thus far.
-
-7.4.9. Finished
-
-   When this message will be sent:
-
-      A finished message is always sent immediately after a change
-      cipher spec message to verify that the key exchange and
-      authentication processes were successful.  It is essential that a
-      change cipher spec message be received between the other handshake
-      messages and the Finished message.
-
-   Meaning of this message:
-
-      The finished message is the first protected with the just-
-      negotiated algorithms, keys, and secrets.  Recipients of finished
-      messages MUST verify that the contents are correct.  Once a side
-      has sent its Finished message and received and validated the
-      Finished message from its peer, it may begin to send and receive
-      application data over the connection.
-
-      struct {
-          opaque verify_data[12];
-      } Finished;
-
-      verify_data
-          PRF(master_secret, finished_label, MD5(handshake_messages) +
-          SHA-1(handshake_messages)) [0..11];
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 51]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-      finished_label
-          For Finished messages sent by the client, the string "client
-          finished".  For Finished messages sent by the server, the
-          string "server finished".
-
-      handshake_messages
-          All of the data from all messages in this handshake (not
-          including any HelloRequest messages) up to but not including
-          this message.  This is only data visible at the handshake
-          layer and does not include record layer headers.  This is the
-          concatenation of all the Handshake structures, as defined in
-          7.4, exchanged thus far.
-
-   It is a fatal error if a finished message is not preceded by a change
-   cipher spec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at client hello up to, but not including, this finished message.
-   This may be different from handshake_messages in Section 7.4.8
-   because it would include the certificate verify message (if sent).
-   Also, the handshake_messages for the finished message sent by the
-   client will be different from that for the finished message sent by
-   the server, because the one that is sent second will include the
-   prior one.
-
-   Note: Change cipher spec messages, alerts, and any other record types
-         are not handshake messages and are not included in the hash
-         computations.  Also, Hello Request messages are omitted from
-         handshake hashes.
-
-8. Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values.  The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the server hello message.  The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages.  All that remains is to
-   calculate the master secret.
-
-8.1. Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret.  The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 52]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-       master_secret = PRF(pre_master_secret, "master secret",
-                           ClientHello.random + ServerHello.random)
-       [0..47];
-
-   The master secret is always exactly 48 bytes in length.  The length
-   of the premaster secret will vary depending on key exchange method.
-
-8.1.1. RSA
-
-   When RSA is used for server authentication and key exchange, a 48-
-   byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server.  The server uses its
-   private key to decrypt the pre_master_secret.  Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
-   1. RSA public key encryption is performed using PKCS #1 block type 2.
-
-8.1.2. Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed.  The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
-   Note: Diffie-Hellman parameters are specified by the server and may
-         be either ephemeral or contained within the server's
-         certificate.
-
-9. Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
-
-10. Application Data Protocol
-
-   Application data messages are carried by the Record Layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state.  The messages are treated as transparent data to the record
-   layer.
-
-11. Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 53]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-12. IANA Considerations
-
-   This document describes a number of new registries that have been
-   created by IANA.  We recommended that they be placed as individual
-   registries items under a common TLS category.
-
-   Section 7.4.3 describes a TLS ClientCertificateType Registry to be
-   maintained by the IANA, defining a number of such code point
-   identifiers.  ClientCertificateType identifiers with values in the
-   range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
-   Action.  Values from the range 64-223 (decimal) inclusive are
-   assigned via [RFC2434] Specification Required.  Identifier values
-   from 224-255 (decimal) inclusive are reserved for RFC 2434 Private
-   Use.  The registry will initially be populated with the values in
-   this document, Section 7.4.4.
-
-   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
-   the IANA, and it defines a number of such cipher suite identifiers.
-   Cipher suite values with the first byte in the range 0-191 (decimal)
-   inclusive are assigned via RFC 2434 Standards Action.  Values with
-   the first byte in the range 192-254 (decimal) are assigned via RFC
-   2434 Specification Required.  Values with the first byte 255
-   (decimal) are reserved for RFC 2434 Private Use.  The registry will
-   initially be populated with the values from Section A.5 of this
-   document, [TLSAES], and from Section 3 of [TLSKRB].
-
-   Section 6 requires that all ContentType values be defined by RFC 2434
-   Standards Action.  IANA has created a TLS ContentType registry,
-   initially populated with values from Section 6.2.1 of this document.
-   Future values MUST be allocated via Standards Action as described in
-   [RFC2434].
-
-   Section 7.2.2 requires that all Alert values be defined by RFC 2434
-   Standards Action.  IANA has created a TLS Alert registry, initially
-   populated with values from Section 7.2 of this document and from
-   Section 4 of [TLSEXT].  Future values MUST be allocated via Standards
-   Action as described in [RFC2434].
-
-   Section 7.4 requires that all HandshakeType values be defined by RFC
-   2434 Standards Action.  IANA has created a TLS HandshakeType
-   registry, initially populated with values from Section 7.4 of this
-   document and from Section 2.4 of [TLSEXT].  Future values MUST be
-   allocated via Standards Action as described in [RFC2434].
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 54]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-Appendix A. Protocol Constant Values
-
-   This section describes protocol types and constants.
-
-A.1. Record Layer
-
-   struct {
-       uint8 major, minor;
-   } ProtocolVersion;
-
-   ProtocolVersion version = { 3, 2 };     /* TLS v1.1 */
-
-   enum {
-       change_cipher_spec(20), alert(21), handshake(22),
-       application_data(23), (255)
-   } ContentType;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSPlaintext.length];
-   } TLSPlaintext;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSCompressed.length];
-   } TLSCompressed;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       select (CipherSpec.cipher_type) {
-           case stream: GenericStreamCipher;
-           case block:  GenericBlockCipher;
-       } fragment;
-   } TLSCiphertext;
-
-   stream-ciphered struct {
-       opaque content[TLSCompressed.length];
-       opaque MAC[CipherSpec.hash_size];
-   } GenericStreamCipher;
-
-   block-ciphered struct {
-       opaque IV[CipherSpec.block_length];
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 55]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-       opaque content[TLSCompressed.length];
-       opaque MAC[CipherSpec.hash_size];
-       uint8 padding[GenericBlockCipher.padding_length];
-       uint8 padding_length;
-   } GenericBlockCipher;
-
-A.2. Change Cipher Specs Message
-
-   struct {
-       enum { change_cipher_spec(1), (255) } type;
-   } ChangeCipherSpec;
-
-A.3. Alert Messages
-
-   enum { warning(1), fatal(2), (255) } AlertLevel;
-
-       enum {
-           close_notify(0),
-           unexpected_message(10),
-           bad_record_mac(20),
-           decryption_failed(21),
-           record_overflow(22),
-           decompression_failure(30),
-           handshake_failure(40),
-           no_certificate_RESERVED (41),
-           bad_certificate(42),
-           unsupported_certificate(43),
-           certificate_revoked(44),
-           certificate_expired(45),
-           certificate_unknown(46),
-           illegal_parameter(47),
-           unknown_ca(48),
-           access_denied(49),
-           decode_error(50),
-           decrypt_error(51),
-           export_restriction_RESERVED(60),
-           protocol_version(70),
-           insufficient_security(71),
-           internal_error(80),
-           user_canceled(90),
-           no_renegotiation(100),
-           (255)
-       } AlertDescription;
-
-   struct {
-       AlertLevel level;
-       AlertDescription description;
-   } Alert;
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 56]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-A.4. Handshake Protocol
-
-   enum {
-       hello_request(0), client_hello(1), server_hello(2),
-       certificate(11), server_key_exchange (12),
-       certificate_request(13), server_hello_done(14),
-       certificate_verify(15), client_key_exchange(16),
-       finished(20), (255)
-   } HandshakeType;
-
-   struct {
-       HandshakeType msg_type;
-       uint24 length;
-       select (HandshakeType) {
-           case hello_request:       HelloRequest;
-           case client_hello:        ClientHello;
-           case server_hello:        ServerHello;
-           case certificate:         Certificate;
-           case server_key_exchange: ServerKeyExchange;
-           case certificate_request: CertificateRequest;
-           case server_hello_done:   ServerHelloDone;
-           case certificate_verify:  CertificateVerify;
-           case client_key_exchange: ClientKeyExchange;
-           case finished:            Finished;
-       } body;
-   } Handshake;
-
-A.4.1. Hello messages
-
-   struct { } HelloRequest;
-
-   struct {
-       uint32 gmt_unix_time;
-       opaque random_bytes[28];
-   } Random;
-
-   opaque SessionID<0..32>;
-
-   uint8 CipherSuite[2];
-
-   enum { null(0), (255) } CompressionMethod;
-
-   struct {
-       ProtocolVersion client_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suites<2..2^16-1>;
-       CompressionMethod compression_methods<1..2^8-1>;
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 57]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   } ClientHello;
-
-   struct {
-       ProtocolVersion server_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suite;
-       CompressionMethod compression_method;
-   } ServerHello;
-
-A.4.2. Server Authentication and Key Exchange Messages
-
-   opaque ASN.1Cert<2^24-1>;
-
-   struct {
-       ASN.1Cert certificate_list<0..2^24-1>;
-   } Certificate;
-
-   enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
-
-   struct {
-       opaque rsa_modulus<1..2^16-1>;
-       opaque rsa_exponent<1..2^16-1>;
-   } ServerRSAParams;
-
-   struct {
-       opaque dh_p<1..2^16-1>;
-       opaque dh_g<1..2^16-1>;
-       opaque dh_Ys<1..2^16-1>;
-   } ServerDHParams;
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case diffie_hellman:
-               ServerDHParams params;
-               Signature signed_params;
-           case rsa:
-               ServerRSAParams params;
-               Signature signed_params;
-       };
-   } ServerKeyExchange;
-
-   enum { anonymous, rsa, dsa } SignatureAlgorithm;
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case diffie_hellman:
-               ServerDHParams params;
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 58]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-           case rsa:
-               ServerRSAParams params;
-       };
-   } ServerParams;
-
-   struct {
-       select (SignatureAlgorithm) {
-           case anonymous: struct { };
-           case rsa:
-               digitally-signed struct {
-                   opaque md5_hash[16];
-                   opaque sha_hash[20];
-               };
-           case dsa:
-               digitally-signed struct {
-                   opaque sha_hash[20];
-               };
-           };
-       };
-   } Signature;
-
-   enum {
-       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-    rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-    fortezza_dms_RESERVED(20),
-    (255)
-   } ClientCertificateType;
-
-   opaque DistinguishedName<1..2^16-1>;
-
-   struct {
-       ClientCertificateType certificate_types<1..2^8-1>;
-       DistinguishedName certificate_authorities<0..2^16-1>;
-   } CertificateRequest;
-
-   struct { } ServerHelloDone;
-
-A.4.3. Client Authentication and Key Exchange Messages
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa: EncryptedPreMasterSecret;
-           case diffie_hellman: ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 59]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   }
-   PreMasterSecret;
-
-   struct {
-       public-key-encrypted PreMasterSecret pre_master_secret;
-   } EncryptedPreMasterSecret;
-
-   enum { implicit, explicit } PublicValueEncoding;
-
-   struct {
-       select (PublicValueEncoding) {
-           case implicit: struct {};
-           case explicit: opaque DH_Yc<1..2^16-1>;
-       } dh_public;
-   } ClientDiffieHellmanPublic;
-
-   struct {
-       Signature signature;
-   } CertificateVerify;
-
-A.4.4. Handshake Finalization Message
-
-   struct {
-       opaque verify_data[12];
-   } Finished;
-
-A.5. The CipherSuite
-
-   The following values define the CipherSuite codes used in the client
-   hello and server hello messages.
-
-   A CipherSuite defines a cipher specification supported in TLS Version
-   1.1.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but must
-   not be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-    CipherSuite TLS_NULL_WITH_NULL_NULL                = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange.  The server may
-   request either an RSA or a DSS signature-capable certificate in the
-   certificate request message.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 60]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-    CipherSuite TLS_RSA_WITH_NULL_MD5                  = { 0x00,0x01 };
-    CipherSuite TLS_RSA_WITH_NULL_SHA                  = { 0x00,0x02 };
-    CipherSuite TLS_RSA_WITH_RC4_128_MD5               = { 0x00,0x04 };
-    CipherSuite TLS_RSA_WITH_RC4_128_SHA               = { 0x00,0x05 };
-    CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA              = { 0x00,0x07 };
-    CipherSuite TLS_RSA_WITH_DES_CBC_SHA               = { 0x00,0x09 };
-    CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA          = { 0x00,0x0A };
-
-   The following CipherSuite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA).  DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a DSS or RSA certificate that has been
-   signed by the CA.  The signing algorithm used is specified after the
-   DH or DHE parameter.  The server can request an RSA or DSS
-   signature-capable certificate from the client for client
-   authentication or it may request a Diffie-Hellman certificate.  Any
-   Diffie-Hellman certificate provided by the client must use the
-   parameters (group and generator) described by the server.
-
-    CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA            = { 0x00,0x0C };
-    CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x0D };
-    CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA            = { 0x00,0x0F };
-    CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x10 };
-    CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA           = { 0x00,0x12 };
-    CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x13 };
-    CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA           = { 0x00,0x15 };
-    CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };
-
-   The following cipher suites are used for completely anonymous
-   Diffie-Hellman communications in which neither party is
-   authenticated.  Note that this mode is vulnerable to man-in-the-
-   middle attacks and is therefore deprecated.
-
-    CipherSuite TLS_DH_anon_WITH_RC4_128_MD5           = { 0x00,0x18 };
-    CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA           = { 0x00,0x1A };
-    CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1B };
-
-   When SSLv3 and TLS 1.0 were designed, the United States restricted
-   the export of cryptographic software containing certain strong
-   encryption algorithms.  A series of cipher suites were designed to
-   operate at reduced key lengths in order to comply with those
-   regulations.  Due to advances in computer performance, these
-   algorithms are now unacceptably weak, and export restrictions have
-   since been loosened.  TLS 1.1 implementations MUST NOT negotiate
-   these cipher suites in TLS 1.1 mode.  However, for backward
-   compatibility they may be offered in the ClientHello for use with TLS
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 61]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
-   server did not choose one of these cipher suites during the
-   handshake.  These ciphersuites are listed below for informational
-   purposes and to reserve the numbers.
-
-    CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5         = { 0x00,0x03 };
-    CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5     = { 0x00,0x06 };
-    CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA      = { 0x00,0x08 };
-    CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0B };
-    CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA   = { 0x00,0x0E };
-    CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x11 };
-    CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x14 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5     = { 0x00,0x17 };
-    CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA  = { 0x00,0x19 };
-
-   The following cipher suites were defined in [TLSKRB] and are included
-   here for completeness.  See [TLSKRB] for details:
-
-    CipherSuite    TLS_KRB5_WITH_DES_CBC_SHA           = { 0x00,0x1E }:
-    CipherSuite    TLS_KRB5_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x1F };
-    CipherSuite    TLS_KRB5_WITH_RC4_128_SHA           = { 0x00,0x20 };
-    CipherSuite    TLS_KRB5_WITH_IDEA_CBC_SHA          = { 0x00,0x21 };
-    CipherSuite    TLS_KRB5_WITH_DES_CBC_MD5           = { 0x00,0x22 };
-    CipherSuite    TLS_KRB5_WITH_3DES_EDE_CBC_MD5      = { 0x00,0x23 };
-    CipherSuite    TLS_KRB5_WITH_RC4_128_MD5           = { 0x00,0x24 };
-    CipherSuite    TLS_KRB5_WITH_IDEA_CBC_MD5          = { 0x00,0x25 };
-
-   The following exportable cipher suites were defined in [TLSKRB] and
-   are included here for completeness.  TLS 1.1 implementations MUST NOT
-   negotiate these cipher suites.
-
-    CipherSuite  TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA    = { 0x00,0x26};
-    CipherSuite  TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA    = { 0x00,0x27};
-    CipherSuite  TLS_KRB5_EXPORT_WITH_RC4_40_SHA        = { 0x00,0x28};
-    CipherSuite  TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5    = { 0x00,0x29};
-    CipherSuite  TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5    = { 0x00,0x2A};
-    CipherSuite  TLS_KRB5_EXPORT_WITH_RC4_40_MD5        = { 0x00,0x2B};
-
-
-   The following cipher suites were defined in [TLSAES] and are included
-   here for completeness.  See [TLSAES] for details:
-
-         CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA      = { 0x00, 0x2F };
-         CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA   = { 0x00, 0x30 };
-         CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA   = { 0x00, 0x31 };
-         CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA  = { 0x00, 0x32 };
-         CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA  = { 0x00, 0x33 };
-         CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA  = { 0x00, 0x34 };
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 62]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-         CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA      = { 0x00, 0x35 };
-         CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA   = { 0x00, 0x36 };
-         CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA   = { 0x00, 0x37 };
-         CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA  = { 0x00, 0x38 };
-         CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA  = { 0x00, 0x39 };
-         CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA  = { 0x00, 0x3A };
-
-    The cipher suite space is divided into three regions:
-
-      1. Cipher suite values with first byte 0x00 (zero) through decimal
-         191 (0xBF) inclusive are reserved for the IETF Standards Track
-         protocols.
-
-      2. Cipher suite values with first byte decimal 192 (0xC0) through
-         decimal 254 (0xFE) inclusive are reserved for assignment for
-         non-Standards Track methods.
-
-      3. Cipher suite values with first byte 0xFF are reserved for
-         private use.
-
-   Additional information describing the role of IANA in the allocation
-   of cipher suite code points is described in Section 11.
-
-   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-         reserved to avoid collision with Fortezza-based cipher suites
-         in SSL 3.
-
-A.6. The Security Parameters
-
-         These security parameters are determined by the TLS Handshake
-         Protocol and provided as parameters to the TLS Record Layer in
-         order to initialize a connection state.  SecurityParameters
-         includes:
-
-            enum { null(0), (255) } CompressionMethod;
-
-            enum { server, client } ConnectionEnd;
-
-            enum { null, rc4, rc2, des, 3des, des40, aes, idea }
-            BulkCipherAlgorithm;
-
-            enum { stream, block } CipherType;
-
-            enum { null, md5, sha } MACAlgorithm;
-
-         /* The algorithms specified in CompressionMethod,
-         BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 63]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-            struct {
-                ConnectionEnd entity;
-                BulkCipherAlgorithm bulk_cipher_algorithm;
-                CipherType cipher_type;
-                uint8 key_size;
-                uint8 key_material_length;
-                MACAlgorithm mac_algorithm;
-                uint8 hash_size;
-                CompressionMethod compression_algorithm;
-                opaque master_secret[48];
-                opaque client_random[32];
-                opaque server_random[32];
-            } SecurityParameters;
-
-Appendix B. Glossary
-
-   Advanced Encryption Standard (AES)
-      AES is a widely used symmetric encryption algorithm.  AES is a
-      block cipher with a 128, 192, or 256 bit keys and a 16 byte block
-      size. [AES] TLS currently only supports the 128 and 256 bit key
-      sizes.
-
-   application protocol
-      An application protocol is a protocol that normally layers
-      directly on top of the transport layer (e.g., TCP/IP).  Examples
-      include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-      See public key cryptography.
-
-   authentication
-      Authentication is the ability of one entity to determine the
-      identity of another entity.
-
-   block cipher
-      A block cipher is an algorithm that operates on plaintext in
-      groups of bits, called blocks. 64 bits is a common block size.
-
-   bulk cipher
-      A symmetric encryption algorithm used to encrypt large quantities
-      of data.
-
-   cipher block chaining (CBC)
-      CBC is a mode in which every plaintext block encrypted with a
-      block cipher is first exclusive-ORed with the previous ciphertext
-      block (or, in the case of the first block, with the initialization
-      vector).  For decryption, every block is first decrypted, then
-      exclusive-ORed with the previous ciphertext block (or IV).
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 64]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   certificate
-      As part of the X.509 protocol (a.k.a. ISO Authentication
-      framework), certificates are assigned by a trusted Certificate
-      Authority and provide a strong binding between a party's identity
-      or some other attributes and its public key.
-
-   client
-      The application entity that initiates a TLS connection to a
-      server.  This may or may not imply that the client initiated the
-      underlying transport connection.  The primary operational
-      difference between the server and client is that the server is
-      generally authenticated, while the client is only optionally
-      authenticated.
-
-   client write key
-      The key used to encrypt data written by the client.
-
-   client write MAC secret
-      The secret data used to authenticate data written by the client.
-
-   connection
-      A connection is a transport (in the OSI layering model definition)
-      that provides a suitable type of service.  For TLS, such
-      connections are peer-to-peer relationships.  The connections are
-      transient.  Every connection is associated with one session.
-
-   Data Encryption Standard
-      DES is a very widely used symmetric encryption algorithm.  DES is
-      a block cipher with a 56 bit key and an 8 byte block size.  Note
-      that in TLS, for key generation purposes, DES is treated as having
-      an 8 byte key length (64 bits), but it still only provides 56 bits
-      of protection.  (The low bit of each key byte is presumed to be
-      set to produce odd parity in that key byte.)  DES can also be
-      operated in a mode where three independent keys and three
-      encryptions are used for each block of data; this uses 168 bits of
-      key (24 bytes in the TLS key generation method) and provides the
-      equivalent of 112 bits of security.  [DES], [3DES]
-
-   Digital Signature Standard (DSS)
-      A standard for digital signing, including the Digital Signing
-      Algorithm, approved by the National Institute of Standards and
-      Technology, defined in NIST FIPS PUB 186, "Digital Signature
-      Standard," published May 1994 by the U.S. Dept. of Commerce.
-      [DSS]
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 65]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   digital signatures
-      Digital signatures utilize public key cryptography and one-way
-      hash functions to produce a signature of the data that can be
-      authenticated, and is difficult to forge or repudiate.
-
-   handshake
-      An initial negotiation between client and server that establishes
-      the parameters of their transactions.
-
-   Initialization Vector (IV)
-      When a block cipher is used in CBC mode, the initialization vector
-      is exclusive-ORed with the first plaintext block prior to
-      encryption.
-
-   IDEA
-      A 64-bit block cipher designed by Xuejia Lai and James Massey.
-      [IDEA]
-
-   Message Authentication Code (MAC)
-      A Message Authentication Code is a one-way hash computed from a
-      message and some secret data.  It is difficult to forge without
-      knowing the secret data.  Its purpose is to detect if the message
-      has been altered.
-
-   master secret
-      Secure secret data used for generating encryption keys, MAC
-      secrets, and IVs.
-
-   MD5
-      MD5 is a secure hashing function that converts an arbitrarily long
-      data stream into a digest of fixed size (16 bytes).  [MD5]
-
-   public key cryptography
-      A class of cryptographic techniques employing two-key ciphers.
-      Messages encrypted with the public key can only be decrypted with
-      the associated private key.  Conversely, messages signed with the
-      private key can be verified with the public key.
-
-   one-way hash function
-      A one-way transformation that converts an arbitrary amount of data
-      into a fixed-length hash.  It is computationally hard to reverse
-      the transformation or to find collisions.  MD5 and SHA are
-      examples of one-way hash functions.
-
-   RC2
-      A block cipher developed by Ron Rivest at RSA Data Security, Inc.
-      [RSADSI] described in [RC2].
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 66]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   RC4
-      A stream cipher invented by Ron Rivest.  A compatible cipher is
-      described in [SCH].
-
-   RSA
-      A very widely used public-key algorithm that can be used for
-      either encryption or digital signing.  [RSA]
-
-   server
-      The server is the application entity that responds to requests for
-      connections from clients.  See also under client.
-
-   session
-      A TLS session is an association between a client and a server.
-      Sessions are created by the handshake protocol.  Sessions define a
-      set of cryptographic security parameters that can be shared among
-      multiple connections.  Sessions are used to avoid the expensive
-      negotiation of new security parameters for each connection.
-
-   session identifier
-      A session identifier is a value generated by a server that
-      identifies a particular session.
-
-   server write key
-      The key used to encrypt data written by the server.
-
-   server write MAC secret
-      The secret data used to authenticate data written by the server.
-
-   SHA
-      The Secure Hash Algorithm is defined in FIPS PUB 180-2.  It
-      produces a 20-byte output.  Note that all references to SHA
-      actually use the modified SHA-1 algorithm.  [SHA]
-
-   SSL
-      Netscape's Secure Socket Layer protocol [SSL3].  TLS is based on
-      SSL Version 3.0
-
-   stream cipher
-      An encryption algorithm that converts a key into a
-      cryptographically strong keystream, which is then exclusive-ORed
-      with the plaintext.
-
-   symmetric cipher
-      See bulk cipher.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 67]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Transport Layer Security (TLS)
-      This protocol; also, the Transport Layer Security working group of
-      the Internet Engineering Task Force (IETF).  See "Comments" at the
-      end of this document.
-
-Appendix C. CipherSuite Definitions
-
-CipherSuite                           Key Exchange   Cipher      Hash
-
-TLS_NULL_WITH_NULL_NULL               NULL           NULL        NULL
-TLS_RSA_WITH_NULL_MD5                 RSA            NULL         MD5
-TLS_RSA_WITH_NULL_SHA                 RSA            NULL         SHA
-TLS_RSA_WITH_RC4_128_MD5              RSA            RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA              RSA            RC4_128      SHA
-TLS_RSA_WITH_IDEA_CBC_SHA             RSA            IDEA_CBC     SHA
-TLS_RSA_WITH_DES_CBC_SHA              RSA            DES_CBC      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA         RSA            3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_DES_CBC_SHA           DH_DSS         DES_CBC      SHA
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      DH_DSS         3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_DES_CBC_SHA           DH_RSA         DES_CBC      SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      DH_RSA         3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_DES_CBC_SHA          DHE_DSS        DES_CBC      SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     DHE_DSS        3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_DES_CBC_SHA          DHE_RSA        DES_CBC      SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     DHE_RSA        3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5          DH_anon        RC4_128      MD5
-TLS_DH_anon_WITH_DES_CBC_SHA          DH_anon        DES_CBC      SHA
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     DH_anon        3DES_EDE_CBC SHA
-
-      Key
-      Exchange
-      Algorithm     Description                        Key size limit
-
-      DHE_DSS       Ephemeral DH with DSS signatures   None
-      DHE_RSA       Ephemeral DH with RSA signatures   None
-      DH_anon       Anonymous DH, no signatures        None
-      DH_DSS        DH with DSS-based certificates     None
-      DH_RSA        DH with RSA-based certificates     None
-                                                       RSA = none
-      NULL          No key exchange                    N/A
-      RSA           RSA key exchange                   None
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 68]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-                         Key      Expanded     IV    Block
-    Cipher       Type  Material Key Material   Size   Size
-
-    NULL         Stream   0          0         0     N/A
-    IDEA_CBC     Block   16         16         8      8
-    RC2_CBC_40   Block    5         16         8      8
-    RC4_40       Stream   5         16         0     N/A
-    RC4_128      Stream  16         16         0     N/A
-    DES40_CBC    Block    5          8         8      8
-    DES_CBC      Block    8          8         8      8
-    3DES_EDE_CBC Block   24         24         8      8
-
-   Type
-      Indicates whether this is a stream cipher or a block cipher
-      running in CBC mode.
-
-   Key Material
-      The number of bytes from the key_block that are used for
-      generating the write keys.
-
-   Expanded Key Material
-      The number of bytes actually fed into the encryption algorithm.
-
-   IV Size
-      The amount of data needed to be generated for the initialization
-      vector.  Zero for stream ciphers; equal to the block size for
-      block ciphers.
-
-   Block Size
-      The amount of data a block cipher enciphers in one chunk; a block
-      cipher running in CBC mode can only encrypt an even multiple of
-      its block size.
-
-         Hash      Hash      Padding
-       function    Size       Size
-         NULL       0          0
-         MD5        16         48
-         SHA        20         40
-
-Appendix D. Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes.  This
-   section provides several recommendations to assist implementors.
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 69]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-D.1. Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG).  Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably MD5 and/or SHA, are
-   acceptable, but cannot provide more security than the size of the
-   random number generator state.  (For example, MD5-based PRNGs usually
-   provide 128 bits of state.)
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte.  For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more.  Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2 Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages.  Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA).  The selection and
-   addition of trusted CAs should be done very carefully.  Users should
-   be able to view information about the certificate and root CA.
-
-D.3 CipherSuites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security.  A proper implementation will
-   probably not support many cipher suites.  For example, 40-bit
-   encryption is easily broken, so implementations requiring strong
-   security should not allow 40-bit keys.  Similarly, anonymous Diffie-
-   Hellman is strongly discouraged because it cannot prevent man-in-
-   the-middle attacks.  Applications should also enforce minimum and
-   maximum key sizes.  For example, certificate chains containing 512-
-   bit RSA keys or signatures are not appropriate for high-security
-   applications.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 70]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-Appendix E. Backward Compatibility with SSL
-
-   For historical reasons and in order to avoid a profligate consumption
-   of reserved port numbers, application protocols that are secured by
-   TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same
-   connection port.  For example, the https protocol (HTTP secured by
-   SSL or TLS) uses port 443 regardless of which security protocol it is
-   using.  Thus, some mechanism must be determined to distinguish and
-   negotiate among the various protocols.
-
-   TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus,
-   supporting both is easy.  TLS clients who wish to negotiate with such
-   older servers SHOULD send client hello messages using the SSL 3.0
-   record format and client hello structure, sending {3, 2} for the
-   version field to note that they support TLS 1.1. If the server
-   supports only TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0
-   server hello; if it supports TLS 1.1 it will respond with a TLS 1.1
-   server hello.  The negotiation then proceeds as appropriate for the
-   negotiated protocol.
-
-   Similarly, a TLS 1.1  server that wishes to interoperate with TLS 1.0
-   or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and
-   respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a
-   version field of {3, 0} is received, denoting that this client does
-   not support TLS.  Similarly, if a SSL 3.0 or TLS 1.0 hello with a
-   version field of {3, 1} is received, the server SHOULD respond with a
-   TLS 1.0 hello with a version field of {3, 1}.
-
-   Whenever a client already knows the highest protocol known to a
-   server (for example, when resuming a session), it SHOULD initiate the
-   connection in that native protocol.
-
-   TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
-   Version 2.0 client hello messages [SSL2].  TLS servers SHOULD accept
-   either client hello format if they wish to support SSL 2.0 clients on
-   the same connection port.  The only deviations from the Version 2.0
-   specification are the ability to specify a version with a value of
-   three and the support for more ciphering types in the CipherSpec.
-
-  Warning: The ability to send Version 2.0 client hello messages will be
-       phased out with all due haste.  Implementors SHOULD make every
-       effort to move forward as quickly as possible.  Version 3.0
-       provides better mechanisms for moving to newer versions.
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 71]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-       The following cipher specifications are carryovers from SSL
-       Version 2.0. These are assumed to use RSA for key exchange and
-       authentication.
-
-        V2CipherSpec TLS_RC4_128_WITH_MD5          = { 0x01,0x00,0x80 };
-        V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
-        V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5  = { 0x03,0x00,0x80 };
-        V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
-                                                   = { 0x04,0x00,0x80 };
-        V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5     = { 0x05,0x00,0x80 };
-        V2CipherSpec TLS_DES_64_CBC_WITH_MD5       = { 0x06,0x00,0x40 };
-        V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
-
-       Cipher specifications native to TLS can be included in Version
-       2.0 client hello messages using the syntax below.  Any
-       V2CipherSpec element with its first byte equal to zero will be
-       ignored by Version 2.0 servers.  Clients sending any of the above
-       V2CipherSpecs SHOULD also include the TLS equivalent (see
-       Appendix A.5):
-
-        V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
-
-   Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in
-       handshakes for backward compatibility but MUST NOT negotiate them
-       in TLS 1.1 mode.
-
-E.1. Version 2 Client Hello
-
-   The Version 2.0 client hello message is presented below using this
-   document's presentation model.  The true definition is still assumed
-   to be the SSL Version 2.0 specification.  Note that this message MUST
-   be sent directly on the wire, not wrapped as an SSLv3 record
-
-     uint8 V2CipherSpec[3];
-
-     struct {
-         uint16 msg_length;
-         uint8 msg_type;
-         Version version;
-         uint16 cipher_spec_length;
-         uint16 session_id_length;
-         uint16 challenge_length;
-         V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-         opaque session_id[V2ClientHello.session_id_length];
-         opaque challenge[V2ClientHello.challenge_length;
-     } V2ClientHello;
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 72]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   msg_length
-      This field is the length of the following data in bytes.  The high
-      bit MUST be 1 and is not part of the length.
-
-   msg_type
-      This field, in conjunction with the version field, identifies a
-      version 2 client hello message.  The value SHOULD be one (1).
-
-   version
-      The highest version of the protocol supported by the client
-      (equals ProtocolVersion.version; see Appendix A.1).
-
-   cipher_spec_length
-      This field is the total length of the field cipher_specs.  It
-      cannot be zero and MUST be a multiple of the V2CipherSpec length
-      (3).
-
-   session_id_length
-      This field MUST have a value of zero.
-
-   challenge_length
-      The length in bytes of the client's challenge to the server to
-      authenticate itself.  When using the SSLv2 backward compatible
-      handshake the client MUST use a 32-byte challenge.
-
-   cipher_specs
-      This is a list of all CipherSpecs the client is willing and able
-      to use.  There MUST be at least one CipherSpec acceptable to the
-      server.
-
-   session_id
-      This field MUST be empty.
-
-   challenge The client challenge to the server for the server to
-      identify itself is a (nearly) arbitrary-length random.  The TLS
-      server will right-justify the challenge data to become the
-      ClientHello.random data (padded with leading zeroes, if
-      necessary), as specified in this protocol specification.  If the
-      length of the challenge is greater than 32 bytes, only the last 32
-      bytes are used.  It is legitimate (but not necessary) for a V3
-      server to reject a V2 ClientHello that has fewer than 16 bytes of
-      challenge data.
-
-      Note: Requests to resume a TLS session MUST use a TLS client
-            hello.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 73]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-E.2. Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   SHOULD use special PKCS #1 block formatting.  This is done so that
-   TLS servers will reject Version 2.0 sessions with TLS-capable
-   clients.
-
-   When TLS clients are in Version 2.0 compatibility mode, they set the
-   right-hand (least significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).  After decrypting the
-   ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
-   error if these eight padding bytes are 0x03.  Version 2.0 servers
-   receiving blocks padded in this manner will proceed normally.
-
-Appendix F. Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel.  This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol.  Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1. Handshake Protocol
-
-   The handshake protocol is responsible for selecting a CipherSpec and
-   generating a Master Secret, which together comprise the primary
-   cryptographic parameters associated with a secure session.  The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1. Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity.  Whenever the server is authenticated, the channel
-   is secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients.  If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 74]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   server.  Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers.  The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1).  The master_secret is required to
-   generate the finished messages, encryption keys, and MAC secrets (see
-   Sections 7.4.8, 7.4.9, and 6.3).  By sending a correct finished
-   message, parties thus prove that they know the correct
-   pre_master_secret.
-
-F.1.1.1. Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using RSA or Diffie-
-   Hellman for key exchange.  With anonymous RSA, the client encrypts a
-   pre_master_secret with the server's uncertified public key extracted
-   from the server key exchange message.  The result is sent in a client
-   key exchange message.  Since eavesdroppers do not know the server's
-   private key, it will be infeasible for them to decode the
-   pre_master_secret.
-
-   Note: No anonymous RSA Cipher Suites are defined in this document.
-
-   With Diffie-Hellman, the server's public parameters are contained in
-   the server key exchange message and the client's are sent in the
-   client key exchange message.  Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e., the pre_master_secret).
-
-   Warning: Completely anonymous connections only provide protection
-            against passive eavesdropping.  Unless an independent
-            tamper-proof channel is used to verify that the finished
-            messages were not replaced by an attacker, server
-            authentication is required in environments where active
-            man-in-the-middle attacks are a concern.
-
-F.1.1.2. RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined.  The
-   public key either may be contained in the server's certificate or may
-   be a temporary RSA key sent in a server key exchange message.  When
-   temporary RSA keys are used, they are signed by the server's RSA
-   certificate.  The signature includes the current ClientHello.random,
-   so old signatures and temporary keys cannot be replayed.  Servers may
-   use a single temporary RSA key for multiple negotiation sessions.
-
-   Note: The temporary RSA key option is useful if servers need large
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 75]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-         certificates but must comply with government-imposed size
-         limits on keys used for key exchange.
-
-   Note that if ephemeral RSA is not used, compromise of the server's
-   static RSA key results in a loss of confidentiality for all sessions
-   protected under that static key.  TLS users desiring Perfect Forward
-   Secrecy should use DHE cipher suites.  The damage done by exposure of
-   a private key can be limited by changing one's private key (and
-   certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key.  By successfully
-   decoding the pre_master_secret and producing a correct finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.8).  The client signs
-   a value derived from the master_secret and all preceding handshake
-   messages.  These handshake messages include the server certificate,
-   which binds the signature to the server, and ServerHello.random,
-   which binds the signature to the current handshake process.
-
-F.1.1.3. Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSS or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters.  In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange.  Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-   pre_master_secret) every time they communicate.  To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSS or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 76]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks.  Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE ciphersuites and generating a fresh DH private key (X) for each
-   handshake.  If a suitable base (such as 2) is chosen, g^X mod p can
-   be computed very quickly, therefore the performance cost is
-   minimized.  Additionally, using a fresh key for each handshake
-   provides Perfect Forward Secrecy.  Implementations SHOULD generate a
-   new X for each handshake when using DHE ciphersuites.
-
-F.1.2. Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0. This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack.  This solution is not secure
-   against attackers who can brute force the key and substitute a new
-   ENCRYPTED-KEY-DATA message containing the same key (but with normal
-   padding) before the application specified wait threshold has expired.
-   Parties concerned about attacks of this scale should not use 40-bit
-   encryption keys.  Altering the padding of the least-significant 8
-   bytes of the PKCS padding does not impact security for the size of
-   the signed hashes and RSA key lengths used in the protocol, since
-   this is essentially equivalent to increasing the input block size by
-   8 bytes.
-
-F.1.3. Detecting Attacks against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally chooses.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages.  If this occurs, the client and server will
-   compute different values for the handshake message hashes.  As a
-   result, the parties will not accept each others' finished messages.
-   Without the master_secret, the attacker cannot repair the finished
-   messages, so the attack will be discovered.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 77]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-F.1.4. Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret.  Provided that the master_secret has not
-   been compromised and that the secure hash operations used to produce
-   the encryption keys and MAC secrets are secure, the connection should
-   be secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations (which use both SHA and MD5).
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake.  An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired.  Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.1.5. MD5 and SHA
-
-   TLS uses hash functions very conservatively.  Where possible, both
-   MD5 and SHA are used in tandem to ensure that non-catastrophic flaws
-   in one algorithm will not break the overall protocol.
-
-F.2. Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission.  To
-   prevent message replay or modification attacks, the MAC is computed
-   from the MAC secret, the sequence number, the message length, the
-   message contents, and two fixed character strings.  The message type
-   field is necessary to ensure that messages intended for one TLS
-   Record Layer client are not redirected to another.  The sequence
-   number ensures that attempts to delete or reorder messages will be
-   detected.  Since sequence numbers are 64 bits long, they should never
-   overflow.  Messages from one party cannot be inserted into the
-   other's output, since they use independent MAC secrets.  Similarly,
-   the server-write and client-write keys are independent, so stream
-   cipher keys are used only once.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 78]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read.  Similarly, compromise of a MAC key can make
-   message modification attacks possible.  Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
-   Note: MAC secrets may be larger than encryption keys, so messages can
-         remain tamper resistant even if encryption keys are broken.
-
-F.3. Explicit IVs
-
-   [CBCATT] describes a chosen plaintext attack on TLS that depends on
-   knowing the IV for a record.  Previous versions of TLS [TLS1.0] used
-   the CBC residue of the previous record as the IV and therefore
-   enabled this attack.  This version uses an explicit IV in order to
-   protect against this attack.
-
-F.4. Security of Composite Cipher Modes
-
-   TLS secures transmitted application data via the use of symmetric
-   encryption and authentication functions defined in the negotiated
-   ciphersuite.  The objective is to protect both the integrity and
-   confidentiality of the transmitted data from malicious actions by
-   active attackers in the network.  It turns out that the order in
-   which encryption and authentication functions are applied to the data
-   plays an important role for achieving this goal [ENCAUTH].
-
-   The most robust method, called encrypt-then-authenticate, first
-   applies encryption to the data and then applies a MAC to the
-   ciphertext.  This method ensures that the integrity and
-   confidentiality goals are obtained with ANY pair of encryption and
-   MAC functions, provided that the former is secure against chosen
-   plaintext attacks and that the MAC is secure against chosen-message
-   attacks.  TLS uses another method, called authenticate-then-encrypt,
-   in which first a MAC is computed on the plaintext and then the
-   concatenation of plaintext and MAC is encrypted.  This method has
-   been proven secure for CERTAIN combinations of encryption functions
-   and MAC functions, but it is not guaranteed to be secure in general.
-   In particular, it has been shown that there exist perfectly secure
-   encryption functions (secure even in the information-theoretic sense)
-   that combined with any secure MAC function, fail to provide the
-   confidentiality goal against an active attack.  Therefore, new
-   ciphersuites and operation modes adopted into TLS need to be analyzed
-   under the authenticate-then-encrypt method to verify that they
-   achieve the stated integrity and confidentiality goals.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 79]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Currently, the security of the authenticate-then-encrypt method has
-   been proven for some important cases.  One is the case of stream
-   ciphers in which a computationally unpredictable pad of the length of
-   the message, plus the length of the MAC tag, is produced using a
-   pseudo-random generator and this pad is xor-ed with the concatenation
-   of plaintext and MAC tag.  The other is the case of CBC mode using a
-   secure block cipher.  In this case, security can be shown if one
-   applies one CBC encryption pass to the concatenation of plaintext and
-   MAC and uses a new, independent, and unpredictable IV for each new
-   pair of plaintext and MAC.  In previous versions of SSL, CBC mode was
-   used properly EXCEPT that it used a predictable IV in the form of the
-   last block of the previous ciphertext.  This made TLS open to chosen
-   plaintext attacks.  This version of the protocol is immune to those
-   attacks.  For exact details in the encryption modes proven secure,
-   see [ENCAUTH].
-
-F.5. Denial of Service
-
-   TLS is susceptible to a number of denial of service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU doing
-   RSA decryption.  However, because TLS is generally used over TCP, it
-   is difficult for the attacker to hide his point of origin if proper
-   TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of
-   denial of service attacks on individual connections.  In particular,
-   attackers can forge RSTs, thereby terminating connections, or forge
-   partial TLS records, thereby causing the connection to stall.  These
-   attacks cannot in general be defended against by a TCP-using
-   protocol.  Implementors or users who are concerned with this class of
-   attack should use IPsec AH [AH-ESP] or ESP [AH-ESP].
-
-F.6. Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure.  In
-   addition, the implementation must be free of security errors.
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used.  Short public keys, 40-bit
-   bulk encryption keys, and anonymous servers should be used with great
-   caution.  Implementations and users must be careful when deciding
-   which certificates and certificate authorities are acceptable; a
-   dishonest certificate authority can do tremendous damage.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 80]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-Normative References
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard (AES)"
-              FIPS 197.  November 26, 2001.
-
-   [3DES]     W. Tuchman, "Hellman Presents No Shortcut Solutions To
-              DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
-
-   [DES]      ANSI X3.106, "American National Standard for Information
-              Systems-Data Link Encryption," American National Standards
-              Institute, 1983.
-
-   [DSS]      NIST FIPS PUB 186-2, "Digital Signature Standard,"
-              National Institute of Standards and Technology, U.S.
-              Department of Commerce, 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-
-              Hashing for Message Authentication", RFC 2104, February
-              1997.
-
-   [IDEA]     X. Lai, "On the Design and Security of Block Ciphers," ETH
-              Series in Information Processing, v. 1, Konstanz:
-              Hartung-Gorre Verlag, 1992.
-
-   [MD5]      Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321,
-              April 1992.
-
-   [PKCS1A]   B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
-              RSA Cryptography Specifications Version 1.5", RFC 2313,
-              March 1998.
-
-   [PKCS1B]   J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
-              (PKCS) #1: RSA Cryptography Specifications Version 2.1",
-              RFC 3447, February 2003.
-
-   [PKIX]     Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [RC2]      Rivest, R., "A Description of the RC2(r) Encryption
-              Algorithm", RFC 2268, March 1998.
-
-   [SCH]      B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-              and Source Code in C, 2ed", Published by John Wiley &
-              Sons, Inc. 1996.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 81]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   [SHA]      NIST FIPS PUB 180-2, "Secure Hash Standard," National
-              Institute of Standards and Technology, U.S. Department of
-              Commerce., August 2001.
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 3546, June 2003.
-
-   [TLSKRB]   Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-Informative References
-
-   [AH-ESP]   Kent, S., "IP Authentication Header", RFC 4302, December
-              2005.
-
-              Eastlake 3rd, D., "Cryptographic Algorithm Implementation
-              Requirements for Encapsulating Security Payload (ESP) and
-              Authentication Header (AH)", RFC 4305, December 2005.
-
-   [BLEI]     Bleichenbacher D., "Chosen Ciphertext Attacks against
-              Protocols Based on RSA Encryption Standard PKCS #1" in
-              Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462,
-              pages:  1-12, 1998.
-
-   [CBCATT]   Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-              Problems and Countermeasures",
-              http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME]  Canvel, B., "Password Interception in a SSL/TLS Channel",
-              http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
-
-   [ENCAUTH]  Krawczyk, H., "The Order of Encryption and Authentication
-              for Protecting Communications (Or: How Secure is SSL?)",
-              Crypto 2001.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 82]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   [KPR03]    Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-              Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-              March 2003.
-
-   [PKCS6]    RSA Laboratories, "PKCS #6: RSA Extended Certificate
-              Syntax Standard," version 1.5, November 1993.
-
-   [PKCS7]    RSA Laboratories, "PKCS #7: RSA Cryptographic Message
-              Syntax Standard," version 1.5, November 1993.
-
-   [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-              "Randomness Requirements for Security", BCP 106, RFC 4086,
-              June 2005.
-
-   [RSA]      R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-              Obtaining Digital Signatures and Public-Key
-              Cryptosystems," Communications of the ACM, v. 21, n. 2,
-              Feb 1978, pp.  120-126.
-
-   [SEQNUM]   Bellovin, S., "Defending Against Sequence Number Attacks",
-              RFC 1948, May 1996.
-
-   [SSL2]     Hickman, Kipp, "The SSL Protocol", Netscape Communications
-              Corp., Feb 9, 1995.
-
-   [SSL3]     A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0
-              Protocol", Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-              Attacks on the Diffie-Hellman Key Agreement Method for
-              S/MIME", RFC 2785, March 2000.
-
-   [TCP]      Hellstrom, G. and P. Jones, "RTP Payload for Text
-              Conversation", RFC 4103, June 2005.
-
-   [TIMING]   Boneh, D., Brumley, D., "Remote timing attacks are
-              practical", USENIX Security Symposium 2003.
-
-   [TLS1.0]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [X501]     ITU-T Recommendation X.501: Information Technology - Open
-              Systems Interconnection - The Directory: Models, 1993.
-
-   [X509]     ITU-T Recommendation X.509 (1997 E): Information
-              Technology - Open Systems Interconnection - "The Directory
-              - Authentication Framework". 1988.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 83]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   [XDR]      Srinivasan, R., "XDR: External Data Representation
-              Standard", RFC 1832, August 1995.
-
-Authors' Addresses
-
-   Working Group Chairs
-
-   Win Treese
-
-   EMail: treese@acm.org
-
-
-   Eric Rescorla
-
-   EMail: ekr@rtfm.com
-
-Editors
-
-   Tim Dierks
-   Independent
-
-   EMail: tim@dierks.org
-
-
-   Eric Rescorla
-   RTFM, Inc.
-
-   EMail: ekr@rtfm.com
-
-Other Contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   EMail: ChristopherA@AlacrityManagement.com
-
-
-   Martin Abadi
-   University of California, Santa Cruz
-   EMail: abadi@cs.ucsc.edu
-
-
-   Ran Canetti
-   IBM
-   EMail: canetti@watson.ibm.com
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 84]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-   Taher Elgamal
-   Securify
-   EMail: taher@securify.com
-
-
-   Anil Gangolli
-   EMail: anil@busybuddha.org
-
-
-   Kipp Hickman
-
-
-   Phil Karlton (co-author of SSLv3)
-
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   EMail: paul@cryptography.com
-
-
-   Hugo Krawczyk
-   Technion Israel Institute of Technology
-   EMail: hugo@ee.technion.ac.il
-
-
-   Robert Relyea
-   Netscape Communications
-   EMail: relyea@netscape.com
-
-
-   Jim Roskind
-   Netscape Communications
-   EMail: jar@netscape.com
-
-
-   Michael Sabin
-
-
-   Dan Simon
-   Microsoft, Inc.
-   EMail: dansimon@microsoft.com
-
-
-   Tom Weinstein
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 85]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-Comments
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <ietf-tls@lists.consensus.com>. Information on the
-   group and information on how to subscribe to the list is at
-   <http://lists.consensus.com/>.
-
-   Archives of the list can be found at:
-       <http://www.imc.org/ietf-tls/mail-archive/>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 86]
-
-RFC 4346                    The TLS Protocol                  April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 87]
-
diff --git a/doc/protocol/rfc4347.txt b/doc/protocol/rfc4347.txt
deleted file mode 100644
index 7231bb7cd2..0000000000
--- a/doc/protocol/rfc4347.txt
+++ /dev/null
@@ -1,1403 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        E. Rescorla
-Request for Comments: 4347                                    RTFM, Inc.
-Category: Standards Track                                    N. Modadugu
-                                                     Stanford University
-                                                              April 2006
-
-
-                   Datagram Transport Layer Security
-
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document specifies Version 1.0 of the Datagram Transport Layer
-   Security (DTLS) protocol.  The DTLS protocol provides communications
-   privacy for datagram protocols.  The protocol allows client/server
-   applications to communicate in a way that is designed to prevent
-   eavesdropping, tampering, or message forgery.  The DTLS protocol is
-   based on the Transport Layer Security (TLS) protocol and provides
-   equivalent security guarantees.  Datagram semantics of the underlying
-   transport are preserved by the DTLS protocol.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Requirements Terminology ...................................3
-   2. Usage Model .....................................................3
-   3. Overview of DTLS ................................................4
-      3.1. Loss-Insensitive Messaging .................................4
-      3.2. Providing Reliability for Handshake ........................4
-           3.2.1. Packet Loss .........................................5
-           3.2.2. Reordering ..........................................5
-           3.2.3. Message Size ........................................5
-      3.3. Replay Detection ...........................................6
-   4. Differences from TLS ............................................6
-      4.1. Record Layer ...............................................6
-           4.1.1. Transport Layer Mapping .............................7
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 1]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-                  4.1.1.1. PMTU Discovery .............................8
-           4.1.2. Record Payload Protection ...........................9
-                  4.1.2.1. MAC ........................................9
-                  4.1.2.2. Null or Standard Stream Cipher .............9
-                  4.1.2.3. Block Cipher ..............................10
-                  4.1.2.4. New Cipher Suites .........................10
-                  4.1.2.5. Anti-replay ...............................10
-      4.2. The DTLS Handshake Protocol ...............................11
-           4.2.1. Denial of Service Countermeasures ..................11
-           4.2.2. Handshake Message Format ...........................13
-           4.2.3. Message Fragmentation and Reassembly ...............15
-           4.2.4. Timeout and Retransmission .........................15
-                  4.2.4.1. Timer Values ..............................18
-           4.2.5. ChangeCipherSpec ...................................19
-           4.2.6. Finished Messages ..................................19
-           4.2.7. Alert Messages .....................................19
-      4.3. Summary of new syntax .....................................19
-           4.3.1. Record Layer .......................................20
-           4.3.2. Handshake Protocol .................................20
-   5. Security Considerations ........................................21
-   6. Acknowledgements ...............................................22
-   7. IANA Considerations ............................................22
-   8. References .....................................................22
-      8.1. Normative References ......................................22
-      8.2. Informative References ....................................23
-
-1. Introduction
-
-   TLS [TLS] is the most widely deployed protocol for securing network
-   traffic.  It is widely used for protecting Web traffic and for e-mail
-   protocols such as IMAP [IMAP] and POP [POP].  The primary advantage
-   of TLS is that it provides a transparent connection-oriented channel.
-   Thus, it is easy to secure an application protocol by inserting TLS
-   between the application layer and the transport layer.  However, TLS
-   must run over a reliable transport channel -- typically TCP [TCP].
-   It therefore cannot be used to secure unreliable datagram traffic.
-
-   However, over the past few years an increasing number of application
-   layer protocols have been designed that use UDP transport.  In
-   particular protocols such as the Session Initiation Protocol (SIP)
-   [SIP] and electronic gaming protocols are increasingly popular.
-   (Note that SIP can run over both TCP and UDP, but that there are
-   situations in which UDP is preferable).  Currently, designers of
-   these applications are faced with a number of unsatisfactory choices.
-   First, they can use IPsec [RFC2401].  However, for a number of
-   reasons detailed in [WHYIPSEC], this is only suitable for some
-   applications.  Second, they can design a custom application layer
-   security protocol.  SIP, for instance, uses a subset of S/MIME to
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 2]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   secure its traffic.  Unfortunately, although application layer
-   security protocols generally provide superior security properties
-   (e.g., end-to-end security in the case of S/MIME), they typically
-   requires a large amount of effort to design -- in contrast to the
-   relatively small amount of effort required to run the protocol over
-   TLS.
-
-   In many cases, the most desirable way to secure client/server
-   applications would be to use TLS; however, the requirement for
-   datagram semantics automatically prohibits use of TLS.  Thus, a
-   datagram-compatible variant of TLS would be very desirable.  This
-   memo describes such a protocol: Datagram Transport Layer Security
-   (DTLS).  DTLS is deliberately designed to be as similar to TLS as
-   possible, both to minimize new security invention and to maximize the
-   amount of code and infrastructure reuse.
-
-1.1. Requirements Terminology
-
-   In this document, the keywords "MUST", "MUST NOT", "REQUIRED",
-   "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described
-   in RFC 2119 [REQ].
-
-2. Usage Model
-
-   The DTLS protocol is designed to secure data between communicating
-   applications.  It is designed to run in application space, without
-   requiring any kernel modifications.
-
-   Datagram transport does not require or provide reliable or in-order
-   delivery of data.  The DTLS protocol preserves this property for
-   payload data.  Applications such as media streaming, Internet
-   telephony, and online gaming use datagram transport for communication
-   due to the delay-sensitive nature of transported data.  The behavior
-   of such applications is unchanged when the DTLS protocol is used to
-   secure communication, since the DTLS protocol does not compensate for
-   lost or re-ordered data traffic.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 3]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-3. Overview of DTLS
-
-   The basic design philosophy of DTLS is to construct "TLS over
-   datagram".  The reason that TLS cannot be used directly in datagram
-   environments is simply that packets may be lost or reordered.  TLS
-   has no internal facilities to handle this kind of unreliability, and
-   therefore TLS implementations break when rehosted on datagram
-   transport.  The purpose of DTLS is to make only the minimal changes
-   to TLS required to fix this problem.  To the greatest extent
-   possible, DTLS is identical to TLS.  Whenever we need to invent new
-   mechanisms, we attempt to do so in such a way that preserves the
-   style of TLS.
-
-   Unreliability creates problems for TLS at two levels:
-
-      1. TLS's traffic encryption layer does not allow independent
-      decryption of individual records.  If record N is not received,
-      then record N+1 cannot be decrypted.
-
-      2. The TLS handshake layer assumes that handshake messages are
-      delivered reliably and breaks if those messages are lost.
-
-   The rest of this section describes the approach that DTLS uses to
-   solve these problems.
-
-3.1. Loss-Insensitive Messaging
-
-   In TLS's traffic encryption layer (called the TLS Record Layer),
-   records are not independent.  There are two kinds of inter-record
-   dependency:
-
-      1. Cryptographic context (CBC state, stream cipher key stream) is
-      chained between records.
-
-      2. Anti-replay and message reordering protection are provided by a
-      MAC that includes a sequence number, but the sequence numbers are
-      implicit in the records.
-
-   The fix for both of these problems is straightforward and well known
-   from IPsec ESP [ESP]: add explicit state to the records.  TLS 1.1
-   [TLS11] is already adding explicit CBC state to TLS records.  DTLS
-   borrows that mechanism and adds explicit sequence numbers.
-
-3.2. Providing Reliability for Handshake
-
-   The TLS handshake is a lockstep cryptographic handshake.  Messages
-   must be transmitted and received in a defined order, and any other
-   order is an error.  Clearly, this is incompatible with reordering and
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 4]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   message loss.  In addition, TLS handshake messages are potentially
-   larger than any given datagram, thus creating the problem of
-   fragmentation.  DTLS must provide fixes for both of these problems.
-
-3.2.1. Packet Loss
-
-   DTLS uses a simple retransmission timer to handle packet loss.  The
-   following figure demonstrates the basic concept, using the first
-   phase of the DTLS handshake:
-
-      Client                                   Server
-      ------                                   ------
-      ClientHello           ------>
-
-                              X<-- HelloVerifyRequest
-                                               (lost)
-
-      [Timer Expires]
-
-      ClientHello           ------>
-      (retransmit)
-
-   Once the client has transmitted the ClientHello message, it expects
-   to see a HelloVerifyRequest from the server.  However, if the
-   server's message is lost the client knows that either the ClientHello
-   or the HelloVerifyRequest has been lost and retransmits.  When the
-   server receives the retransmission, it knows to retransmit.  The
-   server also maintains a retransmission timer and retransmits when
-   that timer expires.
-
-   Note: timeout and retransmission do not apply to the
-   HelloVerifyRequest, because this requires creating state on the
-   server.
-
-3.2.2. Reordering
-
-   In DTLS, each handshake message is assigned a specific sequence
-   number within that handshake.  When a peer receives a handshake
-   message, it can quickly determine whether that message is the next
-   message it expects.  If it is, then it processes it.  If not, it
-   queues it up for future handling once all previous messages have been
-   received.
-
-3.2.3. Message Size
-
-   TLS and DTLS handshake messages can be quite large (in theory up to
-   2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
-   datagrams are often limited to <1500 bytes if fragmentation is not
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 5]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   desired.  In order to compensate for this limitation, each DTLS
-   handshake message may be fragmented over several DTLS records.  Each
-   DTLS handshake message contains both a fragment offset and a fragment
-   length.  Thus, a recipient in possession of all bytes of a handshake
-   message can reassemble the original unfragmented message.
-
-3.3. Replay Detection
-
-   DTLS optionally supports record replay detection.  The technique used
-   is the same as in IPsec AH/ESP, by maintaining a bitmap window of
-   received records.  Records that are too old to fit in the window and
-   records that have previously been received are silently discarded.
-   The replay detection feature is optional, since packet duplication is
-   not always malicious, but can also occur due to routing errors.
-   Applications may conceivably detect duplicate packets and accordingly
-   modify their data transmission strategy.
-
-4. Differences from TLS
-
-   As mentioned in Section 3, DTLS is intentionally very similar to TLS.
-   Therefore, instead of presenting DTLS as a new protocol, we present
-   it as a series of deltas from TLS 1.1 [TLS11].  Where we do not
-   explicitly call out differences, DTLS is the same as in [TLS11].
-
-4.1. Record Layer
-
-   The DTLS record layer is extremely similar to that of TLS 1.1.  The
-   only change is the inclusion of an explicit sequence number in the
-   record.  This sequence number allows the recipient to correctly
-   verify the TLS MAC.  The DTLS record format is shown below:
-
-       struct {
-         ContentType type;
-         ProtocolVersion version;
-         uint16 epoch;                                    // New field
-         uint48 sequence_number;                          // New field
-         uint16 length;
-         opaque fragment[DTLSPlaintext.length];
-       } DTLSPlaintext;
-
-      type
-       Equivalent to the type field in a TLS 1.1 record.
-
-      version
-       The version of the protocol being employed.  This document
-       describes DTLS Version 1.0, which uses the version { 254, 255
-       }.  The version value of 254.255 is the 1's complement of DTLS
-       Version 1.0. This maximal spacing between TLS and DTLS version
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 6]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-       numbers ensures that records from the two protocols can be
-       easily distinguished.  It should be noted that future on-the-wire
-       version numbers of DTLS are decreasing in value (while the true
-       version number is increasing in value.)
-
-      epoch
-       A counter value that is incremented on every cipher state
-       change.
-
-      sequence_number
-       The sequence number for this record.
-
-      length
-       Identical to the length field in a TLS 1.1 record.  As in TLS
-       1.1, the length should not exceed 2^14.
-
-      fragment
-       Identical to the fragment field of a TLS 1.1 record.
-
-   DTLS uses an explicit sequence number, rather than an implicit one,
-   carried in the sequence_number field of the record.  As with TLS, the
-   sequence number is set to zero after each ChangeCipherSpec message is
-   sent.
-
-   If several handshakes are performed in close succession, there might
-   be multiple records on the wire with the same sequence number but
-   from different cipher states.  The epoch field allows recipients to
-   distinguish such packets.  The epoch number is initially zero and is
-   incremented each time the ChangeCipherSpec messages is sent.  In
-   order to ensure that any given sequence/epoch pair is unique,
-   implementations MUST NOT allow the same epoch value to be reused
-   within two times the TCP maximum segment lifetime.  In practice, TLS
-   implementations rarely rehandshake and we therefore do not expect
-   this to be a problem.
-
-4.1.1. Transport Layer Mapping
-
-   Each DTLS record MUST fit within a single datagram.  In order to
-   avoid IP fragmentation [MOGUL], DTLS implementations SHOULD determine
-   the MTU and send records smaller than the MTU.  DTLS implementations
-   SHOULD provide a way for applications to determine the value of the
-   PMTU (or, alternately, the maximum application datagram size, which
-   is the PMTU minus the DTLS per-record overhead).  If the application
-   attempts to send a record larger than the MTU, the DTLS
-   implementation SHOULD generate an error, thus avoiding sending a
-   packet which will be fragmented.
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 7]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   Note that unlike IPsec, DTLS records do not contain any association
-   identifiers.  Applications must arrange to multiplex between
-   associations.  With UDP, this is presumably done with host/port
-   number.
-
-   Multiple DTLS records may be placed in a single datagram.  They are
-   simply encoded consecutively.  The DTLS record framing is sufficient
-   to determine the boundaries.  Note, however, that the first byte of
-   the datagram payload must be the beginning of a record.  Records may
-   not span datagrams.
-
-   Some transports, such as DCCP [DCCP] provide their own sequence
-   numbers.  When carried over those transports, both the DTLS and the
-   transport sequence numbers will be present.  Although this introduces
-   a small amount of inefficiency, the transport layer and DTLS sequence
-   numbers serve different purposes, and therefore for conceptual
-   simplicity it is superior to use both sequence numbers.  In the
-   future, extensions to DTLS may be specified that allow the use of
-   only one set of sequence numbers for deployment in constrained
-   environments.
-
-   Some transports, such as DCCP, provide congestion control for traffic
-   carried over them.  If the congestion window is sufficiently narrow,
-   DTLS handshake retransmissions may be held rather than transmitted
-   immediately, potentially leading to timeouts and spurious
-   retransmission.  When DTLS is used over such transports, care should
-   be taken not to overrun the likely congestion window.  In the future,
-   a DTLS-DCCP mapping may be specified to provide optimal behavior for
-   this interaction.
-
-4.1.1.1. PMTU Discovery
-
-   In general, DTLS's philosophy is to avoid dealing with PMTU issues.
-   The general strategy is to start with a conservative MTU and then
-   update it if events during the handshake or actual application data
-   transport phase require it.
-
-   The PMTU SHOULD be initialized from the interface MTU that will be
-   used to send packets.  If the DTLS implementation receives an RFC
-   1191 [RFC1191] ICMP Destination Unreachable message with the
-   "fragmentation needed and DF set" Code (otherwise known as Datagram
-   Too Big), it should decrease its PMTU estimate to that given in the
-   ICMP message.  A DTLS implementation SHOULD allow the application to
-   occasionally reset its PMTU estimate.  The DTLS implementation SHOULD
-   also allow applications to control the status of the DF bit.  These
-   controls allow the application to perform PMTU discovery.  RFC 1981
-   [RFC1981] procedures SHOULD be followed for IPv6.
-
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 8]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   One special case is the DTLS handshake system.  Handshake messages
-   should be set with DF set.  Because some firewalls and routers screen
-   out ICMP messages, it is difficult for the handshake layer to
-   distinguish packet loss from an overlarge PMTU estimate.  In order to
-   allow connections under these circumstances, DTLS implementations
-   SHOULD back off handshake packet size during the retransmit backoff
-   described in Section 4.2.4. For instance, if a large packet is being
-   sent, after 3 retransmits the handshake layer might choose to
-   fragment the handshake message on retransmission.  In general, choice
-   of a conservative initial MTU will avoid this problem.
-
-4.1.2. Record Payload Protection
-
-   Like TLS, DTLS transmits data as a series of protected records.  The
-   rest of this section describes the details of that format.
-
-4.1.2.1. MAC
-
-   The DTLS MAC is the same as that of TLS 1.1. However, rather than
-   using TLS's implicit sequence number, the sequence number used to
-   compute the MAC is the 64-bit value formed by concatenating the epoch
-   and the sequence number in the order they appear on the wire.  Note
-   that the DTLS epoch + sequence number is the same length as the TLS
-   sequence number.
-
-   TLS MAC calculation is parameterized on the protocol version number,
-   which, in the case of DTLS, is the on-the-wire version, i.e., {254,
-   255 } for DTLS 1.0.
-
-   Note that one important difference between DTLS and TLS MAC handling
-   is that in TLS MAC errors must result in connection termination.  In
-   DTLS, the receiving implementation MAY simply discard the offending
-   record and continue with the connection.  This change is possible
-   because DTLS records are not dependent on each other in the way that
-   TLS records are.
-
-   In general, DTLS implementations SHOULD silently discard data with
-   bad MACs.  If a DTLS implementation chooses to generate an alert when
-   it receives a message with an invalid MAC, it MUST generate
-   bad_record_mac alert with level fatal and terminate its connection
-   state.
-
-4.1.2.2. Null or Standard Stream Cipher
-
-   The DTLS NULL cipher is performed exactly as the TLS 1.1 NULL cipher.
-
-   The only stream cipher described in TLS 1.1 is RC4, which cannot be
-   randomly accessed.  RC4 MUST NOT be used with DTLS.
-
-
-
-Rescorla & Modadugu         Standards Track                     [Page 9]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-4.1.2.3. Block Cipher
-
-   DTLS block cipher encryption and decryption are performed exactly as
-   with TLS 1.1.
-
-4.1.2.4. New Cipher Suites
-
-   Upon registration, new TLS cipher suites MUST indicate whether they
-   are suitable for DTLS usage and what, if any, adaptations must be
-   made.
-
-4.1.2.5. Anti-replay
-
-   DTLS records contain a sequence number to provide replay protection.
-   Sequence number verification SHOULD be performed using the following
-   sliding window procedure, borrowed from Section 3.4.3 of [RFC 2402].
-
-   The receiver packet counter for this session MUST be initialized to
-   zero when the session is established.  For each received record, the
-   receiver MUST verify that the record contains a Sequence Number that
-   does not duplicate the Sequence Number of any other record received
-   during the life of this session.  This SHOULD be the first check
-   applied to a packet after it has been matched to a session, to speed
-   rejection of duplicate records.
-
-   Duplicates are rejected through the use of a sliding receive window.
-   (How the window is implemented is a local matter, but the following
-   text describes the functionality that the implementation must
-   exhibit.)  A minimum window size of 32 MUST be supported, but a
-   window size of 64 is preferred and SHOULD be employed as the default.
-   Another window size (larger than the minimum) MAY be chosen by the
-   receiver.  (The receiver does not notify the sender of the window
-   size.)
-
-   The "right" edge of the window represents the highest validated
-   Sequence Number value received on this session.  Records that contain
-   Sequence Numbers lower than the "left" edge of the window are
-   rejected.  Packets falling within the window are checked against a
-   list of received packets within the window.  An efficient means for
-   performing this check, based on the use of a bit mask, is described
-   in Appendix C of [RFC 2401].
-
-   If the received record falls within the window and is new, or if the
-   packet is to the right of the window, then the receiver proceeds to
-   MAC verification.  If the MAC validation fails, the receiver MUST
-   discard the received record as invalid.  The receive window is
-   updated only if the MAC verification succeeds.
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 10]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-4.2. The DTLS Handshake Protocol
-
-   DTLS uses all of the same handshake messages and flows as TLS, with
-   three principal changes:
-
-      1. A stateless cookie exchange has been added to prevent denial of
-      service attacks.
-
-      2. Modifications to the handshake header to handle message loss,
-      reordering, and fragmentation.
-
-      3. Retransmission timers to handle message loss.
-
-   With these exceptions, the DTLS message formats, flows, and logic are
-   the same as those of TLS 1.1.
-
-4.2.1. Denial of Service Countermeasures
-
-   Datagram security protocols are extremely susceptible to a variety of
-   denial of service (DoS) attacks.  Two attacks are of particular
-   concern:
-
-      1. An attacker can consume excessive resources on the server by
-      transmitting a series of handshake initiation requests, causing
-      the server to allocate state and potentially to perform expensive
-      cryptographic operations.
-
-      2. An attacker can use the server as an amplifier by sending
-      connection initiation messages with a forged source of the victim.
-      The server then sends its next message (in DTLS, a Certificate
-      message, which can be quite large) to the victim machine, thus
-      flooding it.
-
-   In order to counter both of these attacks, DTLS borrows the stateless
-   cookie technique used by Photuris [PHOTURIS] and IKE [IKE].  When the
-   client sends its ClientHello message to the server, the server MAY
-   respond with a HelloVerifyRequest message.  This message contains a
-   stateless cookie generated using the technique of [PHOTURIS].  The
-   client MUST retransmit the ClientHello with the cookie added.  The
-   server then verifies the cookie and proceeds with the handshake only
-   if it is valid.  This mechanism forces the attacker/client to be able
-   to receive the cookie, which makes DoS attacks with spoofed IP
-   addresses difficult.  This mechanism does not provide any defense
-   against DoS attacks mounted from valid IP addresses.
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 11]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   The exchange is shown below:
-
-         Client                                   Server
-         ------                                   ------
-         ClientHello           ------>
-
-                               <----- HelloVerifyRequest
-                                      (contains cookie)
-
-         ClientHello           ------>
-         (with cookie)
-
-         [Rest of handshake]
-
-   DTLS therefore modifies the ClientHello message to add the cookie
-   value.
-
-      struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        opaque cookie<0..32>;                             // New field
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-      } ClientHello;
-
-   When sending the first ClientHello, the client does not have a cookie
-   yet; in this case, the Cookie field is left empty (zero length).
-
-   The definition of HelloVerifyRequest is as follows:
-
-      struct {
-        ProtocolVersion server_version;
-        opaque cookie<0..32>;
-      } HelloVerifyRequest;
-
-   The HelloVerifyRequest message type is hello_verify_request(3).
-
-   The server_version field is defined as in TLS.
-
-   When responding to a HelloVerifyRequest the client MUST use the same
-   parameter values (version, random, session_id, cipher_suites,
-   compression_method) as it did in the original ClientHello.  The
-   server SHOULD use those values to generate its cookie and verify that
-   they are correct upon cookie receipt.  The server MUST use the same
-   version number in the HelloVerifyRequest that it would use when
-   sending a ServerHello.  Upon receipt of the ServerHello, the client
-   MUST verify that the server version values match.
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 12]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   The DTLS server SHOULD generate cookies in such a way that they can
-   be verified without retaining any per-client state on the server.
-   One technique is to have a randomly generated secret and generate
-   cookies as:  Cookie = HMAC(Secret, Client-IP, Client-Parameters)
-
-   When the second ClientHello is received, the server can verify that
-   the Cookie is valid and that the client can receive packets at the
-   given IP address.
-
-   One potential attack on this scheme is for the attacker to collect a
-   number of cookies from different addresses and then reuse them to
-   attack the server.  The server can defend against this attack by
-   changing the Secret value frequently, thus invalidating those
-   cookies.  If the server wishes that legitimate clients be able to
-   handshake through the transition (e.g., they received a cookie with
-   Secret 1 and then sent the second ClientHello after the server has
-   changed to Secret 2), the server can have a limited window during
-   which it accepts both secrets. [IKEv2] suggests adding a version
-   number to cookies to detect this case.  An alternative approach is
-   simply to try verifying with both secrets.
-
-   DTLS servers SHOULD perform a cookie exchange whenever a new
-   handshake is being performed.  If the server is being operated in an
-   environment where amplification is not a problem, the server MAY be
-   configured not to perform a cookie exchange.  The default SHOULD be
-   that the exchange is performed, however.  In addition, the server MAY
-   choose not to do a cookie exchange when a session is resumed.
-   Clients MUST be prepared to do a cookie exchange with every
-   handshake.
-
-   If HelloVerifyRequest is used, the initial ClientHello and
-   HelloVerifyRequest are not included in the calculation of the
-   verify_data for the Finished message.
-
-4.2.2. Handshake Message Format
-
-   In order to support message loss, reordering, and fragmentation, DTLS
-   modifies the TLS 1.1 handshake header:
-
-      struct {
-        HandshakeType msg_type;
-        uint24 length;
-        uint16 message_seq;                               // New field
-        uint24 fragment_offset;                           // New field
-        uint24 fragment_length;                           // New field
-        select (HandshakeType) {
-          case hello_request: HelloRequest;
-          case client_hello:  ClientHello;
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 13]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-          case hello_verify_request: HelloVerifyRequest;  // New type
-          case server_hello:  ServerHello;
-          case certificate:Certificate;
-          case server_key_exchange: ServerKeyExchange;
-          case certificate_request: CertificateRequest;
-          case server_hello_done:ServerHelloDone;
-          case certificate_verify:  CertificateVerify;
-          case client_key_exchange: ClientKeyExchange;
-          case finished:Finished;
-        } body;
-      } Handshake;
-
-   The first message each side transmits in each handshake always has
-   message_seq = 0.  Whenever each new message is generated, the
-   message_seq value is incremented by one.  When a message is
-   retransmitted, the same message_seq value is used.  For example:
-
-      Client                             Server
-      ------                             ------
-      ClientHello (seq=0)  ------>
-
-                              X<-- HelloVerifyRequest (seq=0)
-                                              (lost)
-
-      [Timer Expires]
-
-      ClientHello (seq=0)  ------>
-      (retransmit)
-
-                           <------ HelloVerifyRequest (seq=0)
-
-      ClientHello (seq=1)  ------>
-      (with cookie)
-
-                           <------        ServerHello (seq=1)
-                           <------        Certificate (seq=2)
-                           <------    ServerHelloDone (seq=3)
-
-      [Rest of handshake]
-
-   Note, however, that from the perspective of the DTLS record layer,
-   the retransmission is a new record.  This record will have a new
-   DTLSPlaintext.sequence_number value.
-
-   DTLS implementations maintain (at least notionally) a
-   next_receive_seq counter.  This counter is initially set to zero.
-   When a message is received, if its sequence number matches
-   next_receive_seq, next_receive_seq is incremented and the message is
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 14]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   processed.  If the sequence number is less than next_receive_seq, the
-   message MUST be discarded.  If the sequence number is greater than
-   next_receive_seq, the implementation SHOULD queue the message but MAY
-   discard it.  (This is a simple space/bandwidth tradeoff).
-
-4.2.3. Message Fragmentation and Reassembly
-
-   As noted in Section 4.1.1, each DTLS message MUST fit within a single
-   transport layer datagram.  However, handshake messages are
-   potentially bigger than the maximum record size.  Therefore, DTLS
-   provides a mechanism for fragmenting a handshake message over a
-   number of records.
-
-   When transmitting the handshake message, the sender divides the
-   message into a series of N contiguous data ranges.  These ranges MUST
-   NOT be larger than the maximum handshake fragment size and MUST
-   jointly contain the entire handshake message.  The ranges SHOULD NOT
-   overlap.  The sender then creates N handshake messages, all with the
-   same message_seq value as the original handshake message.  Each new
-   message is labelled with the fragment_offset (the number of bytes
-   contained in previous fragments) and the fragment_length (the length
-   of this fragment).  The length field in all messages is the same as
-   the length field of the original message.  An unfragmented message is
-   a degenerate case with fragment_offset=0 and fragment_length=length.
-
-   When a DTLS implementation receives a handshake message fragment, it
-   MUST buffer it until it has the entire handshake message.  DTLS
-   implementations MUST be able to handle overlapping fragment ranges.
-   This allows senders to retransmit handshake messages with smaller
-   fragment sizes during path MTU discovery.
-
-   Note that as with TLS, multiple handshake messages may be placed in
-   the same DTLS record, provided that there is room and that they are
-   part of the same flight.  Thus, there are two acceptable ways to pack
-   two DTLS messages into the same datagram: in the same record or in
-   separate records.
-
-4.2.4. Timeout and Retransmission
-
-   DTLS messages are grouped into a series of message flights, according
-   to the diagrams below.  Although each flight of messages may consist
-   of a number of messages, they should be viewed as monolithic for the
-   purpose of timeout and retransmission.
-
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 15]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-    Client                                          Server
-    ------                                          ------
-
-    ClientHello             -------->                           Flight 1
-
-                            <-------    HelloVerifyRequest      Flight 2
-
-   ClientHello              -------->                           Flight 3
-
-                                               ServerHello    \
-                                              Certificate*     \
-                                        ServerKeyExchange*      Flight 4
-                                       CertificateRequest*     /
-                            <--------      ServerHelloDone    /
-
-    Certificate*                                              \
-    ClientKeyExchange                                          \
-    CertificateVerify*                                          Flight 5
-    [ChangeCipherSpec]                                         /
-    Finished                -------->                         /
-
-                                        [ChangeCipherSpec]    \ Flight 6
-                            <--------             Finished    /
-
-          Figure 1. Message flights for full handshake
-
-
-    Client                                           Server
-    ------                                           ------
-
-    ClientHello             -------->                          Flight 1
-
-                                               ServerHello    \
-                                        [ChangeCipherSpec]     Flight 2
-                             <--------             Finished    /
-
-    [ChangeCipherSpec]                                         \Flight 3
-    Finished                 -------->                         /
-
-   Figure 2. Message flights for session-resuming handshake
-                           (no cookie exchange)
-
-   DTLS uses a simple timeout and retransmission scheme with the
-   following state machine.  Because DTLS clients send the first message
-   (ClientHello), they start in the PREPARING state.  DTLS servers start
-   in the WAITING state, but with empty buffers and no retransmit timer.
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 16]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-                   +-----------+
-                   | PREPARING |
-             +---> |           | <--------------------+
-             |     |           |                      |
-             |     +-----------+                      |
-             |           |                            |
-             |           |                            |
-             |           | Buffer next flight         |
-             |           |                            |
-             |          \|/                           |
-             |     +-----------+                      |
-             |     |           |                      |
-             |     |  SENDING  |<------------------+  |
-             |     |           |                   |  | Send
-             |     +-----------+                   |  | HelloRequest
-     Receive |           |                         |  |
-        next |           | Send flight             |  | or
-      flight |  +--------+                         |  |
-             |  |        | Set retransmit timer    |  | Receive
-             |  |       \|/                        |  | HelloRequest
-             |  |  +-----------+                   |  | Send
-             |  |  |           |                   |  | ClientHello
-             +--)--|  WAITING  |-------------------+  |
-             |  |  |           |   Timer expires   |  |
-             |  |  +-----------+                   |  |
-             |  |         |                        |  |
-             |  |         |                        |  |
-             |  |         +------------------------+  |
-             |  |                Read retransmit      |
-     Receive |  |                                     |
-        last |  |                                     |
-      flight |  |                                     |
-             |  |                                     |
-            \|/\|/                                    |
-                                                      |
-         +-----------+                                |
-         |           |                                |
-         | FINISHED  | -------------------------------+
-         |           |
-         +-----------+
-
-        Figure 3. DTLS timeout and retransmission state machine
-
-   The state machine has three basic states.
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 17]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   In the PREPARING state the implementation does whatever computations
-   are necessary to prepare the next flight of messages.  It then
-   buffers them up for transmission (emptying the buffer first) and
-   enters the SENDING state.
-
-   In the SENDING state, the implementation transmits the buffered
-   flight of messages.  Once the messages have been sent, the
-   implementation then enters the FINISHED state if this is the last
-   flight in the handshake.  Or, if the implementation expects to
-   receive more messages, it sets a retransmit timer and then enters the
-   WAITING state.
-
-   There are three ways to exit the WAITING state:
-
-      1. The retransmit timer expires: the implementation transitions to
-      the SENDING state, where it retransmits the flight, resets the
-      retransmit timer, and returns to the WAITING state.
-
-      2. The implementation reads a retransmitted flight from the peer:
-      the implementation transitions to the SENDING state, where it
-      retransmits the flight, resets the retransmit timer, and returns
-      to the WAITING state.  The rationale here is that the receipt of a
-      duplicate message is the likely result of timer expiry on the peer
-      and therefore suggests that part of one's previous flight was
-      lost.
-
-      3. The implementation receives the next flight of messages:  if
-      this is the final flight of messages, the implementation
-      transitions to FINISHED.  If the implementation needs to send a
-      new flight, it transitions to the PREPARING state.  Partial reads
-      (whether partial messages or only some of the messages in the
-      flight) do not cause state transitions or timer resets.
-
-   Because DTLS clients send the first message (ClientHello), they start
-   in the PREPARING state.  DTLS servers start in the WAITING state, but
-   with empty buffers and no retransmit timer.
-
-   When the server desires a rehandshake, it transitions from the
-   FINISHED state to the PREPARING state to transmit the HelloRequest.
-   When the client receives a HelloRequest it transitions from FINISHED
-   to PREPARING to transmit the ClientHello.
-
-4.2.4.1. Timer Values
-
-   Though timer values are the choice of the implementation, mishandling
-   of the timer can lead to serious congestion problems; for example, if
-   many instances of a DTLS time out early and retransmit too quickly on
-   a congested link.  Implementations SHOULD use an initial timer value
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 18]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   of 1 second (the minimum defined in RFC 2988 [RFC2988]) and double
-   the value at each retransmission, up to no less than the RFC 2988
-   maximum of 60 seconds.  Note that we recommend a 1-second timer
-   rather than the 3-second RFC 2988 default in order to improve latency
-   for time-sensitive applications.  Because DTLS only uses
-   retransmission for handshake and not dataflow, the effect on
-   congestion should be minimal.
-
-   Implementations SHOULD retain the current timer value until a
-   transmission without loss occurs, at which time the value may be
-   reset to the initial value.  After a long period of idleness, no less
-   than 10 times the current timer value, implementations may reset the
-   timer to the initial value.  One situation where this might occur is
-   when a rehandshake is used after substantial data transfer.
-
-4.2.5. ChangeCipherSpec
-
-   As with TLS, the ChangeCipherSpec message is not technically a
-   handshake message but MUST be treated as part of the same flight as
-   the associated Finished message for the purposes of timeout and
-   retransmission.
-
-4.2.6. Finished Messages
-
-   Finished messages have the same format as in TLS.  However, in order
-   to remove sensitivity to fragmentation, the Finished MAC MUST be
-   computed as if each handshake message had been sent as a single
-   fragment.  Note that in cases where the cookie exchange is used, the
-   initial ClientHello and HelloVerifyRequest MUST NOT be included in
-   the Finished MAC.
-
-4.2.7. Alert Messages
-
-   Note that Alert messages are not retransmitted at all, even when they
-   occur in the context of a handshake.  However, a DTLS implementation
-   SHOULD generate a new alert message if the offending record is
-   received again (e.g., as a retransmitted handshake message).
-   Implementations SHOULD detect when a peer is persistently sending bad
-   messages and terminate the local connection state after such
-   misbehavior is detected.
-
-4.3. Summary of new syntax
-
-   This section includes specifications for the data structures that
-   have changed between TLS 1.1 and DTLS.
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 19]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-4.3.1. Record Layer
-
-      struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 epoch;                                     // New field
-        uint48 sequence_number;                           // New field
-        uint16 length;
-        opaque fragment[DTLSPlaintext.length];
-      } DTLSPlaintext;
-
-      struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 epoch;                                     // New field
-        uint48 sequence_number;                           // New field
-        uint16 length;
-        opaque fragment[DTLSCompressed.length];
-      } DTLSCompressed;
-
-      struct {
-        ContentType type;
-        ProtocolVersion version;
-        uint16 epoch;                                     // New field
-        uint48 sequence_number;                           // New field
-        uint16 length;
-        select (CipherSpec.cipher_type) {
-          case block:  GenericBlockCipher;
-        } fragment;
-      } DTLSCiphertext;
-
-4.3.2. Handshake Protocol
-
-      enum {
-        hello_request(0), client_hello(1), server_hello(2),
-        hello_verify_request(3),                          // New field
-        certificate(11), server_key_exchange (12),
-        certificate_request(13), server_hello_done(14),
-        certificate_verify(15), client_key_exchange(16),
-        finished(20), (255)
-      } HandshakeType;
-
-      struct {
-        HandshakeType msg_type;
-        uint24 length;
-        uint16 message_seq;                               // New field
-        uint24 fragment_offset;                           // New field
-        uint24 fragment_length;                           // New field
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 20]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-        select (HandshakeType) {
-          case hello_request: HelloRequest;
-          case client_hello:  ClientHello;
-          case server_hello:  ServerHello;
-          case hello_verify_request: HelloVerifyRequest;  // New field
-          case certificate:Certificate;
-          case server_key_exchange: ServerKeyExchange;
-          case certificate_request: CertificateRequest;
-          case server_hello_done:ServerHelloDone;
-          case certificate_verify:  CertificateVerify;
-          case client_key_exchange: ClientKeyExchange;
-          case finished:Finished;
-        } body;
-      } Handshake;
-
-      struct {
-        ProtocolVersion client_version;
-        Random random;
-        SessionID session_id;
-        opaque cookie<0..32>;                             // New field
-        CipherSuite cipher_suites<2..2^16-1>;
-        CompressionMethod compression_methods<1..2^8-1>;
-      } ClientHello;
-
-      struct {
-        ProtocolVersion server_version;
-        opaque cookie<0..32>;
-      } HelloVerifyRequest;
-
-5. Security Considerations
-
-   This document describes a variant of TLS 1.1 and therefore most of
-   the security considerations are the same as those of TLS 1.1 [TLS11],
-   described in Appendices D, E, and F.
-
-   The primary additional security consideration raised by DTLS is that
-   of denial of service.  DTLS includes a cookie exchange designed to
-   protect against denial of service.  However, implementations which do
-   not use this cookie exchange are still vulnerable to DoS.  In
-   particular, DTLS servers which do not use the cookie exchange may be
-   used as attack amplifiers even if they themselves are not
-   experiencing DoS.  Therefore, DTLS servers SHOULD use the cookie
-   exchange unless there is good reason to believe that amplification is
-   not a threat in their environment.  Clients MUST be prepared to do a
-   cookie exchange with every handshake.
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 21]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-6. Acknowledgements
-
-   The authors would like to thank Dan Boneh, Eu-Jin Goh, Russ Housley,
-   Constantine Sapuntzakis, and Hovav Shacham for discussions and
-   comments on the design of DTLS.  Thanks to the anonymous NDSS
-   reviewers of our original NDSS paper on DTLS [DTLS] for their
-   comments.  Also, thanks to Steve Kent for feedback that helped
-   clarify many points.  The section on PMTU was cribbed from the DCCP
-   specification [DCCP].  Pasi Eronen provided a detailed review of this
-   specification.  Helpful comments on the document were also received
-   from Mark Allman, Jari Arkko, Joel Halpern, Ted Hardie, and Allison
-   Mankin.
-
-7. IANA Considerations
-
-   This document uses the same identifier space as TLS [TLS11], so no
-   new IANA registries are required.  When new identifiers are assigned
-   for TLS, authors MUST specify whether they are suitable for DTLS.
-
-   This document defines a new handshake message, hello_verify_request,
-   whose value has been allocated from the TLS HandshakeType registry
-   defined in [TLS11].  The value "3" has been assigned by the IANA.
-
-8. References
-
-8.1. Normative References
-
-   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
-              November 1990.
-
-   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
-              for IP version 6", RFC 1981, August 1996.
-
-   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
-              Internet Protocol", RFC 2401, November 1998.
-
-   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
-              Timer", RFC 2988, November 2000.
-
-   [TCP]      Postel, J., "Transmission Control Protocol", STD 7, RFC
-              793, September 1981.
-
-   [TLS11]    Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 22]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-8.2. Informative References
-
-   [AESCACHE] Bernstein, D.J., "Cache-timing attacks on AES"
-              http://cr.yp.to/antiforgery/cachetiming-20050414.pdf.
-
-   [AH]       Kent, S. and R. Atkinson, "IP Authentication Header", RFC
-              2402, November 1998.
-
-   [DCCP]     Kohler, E., Handley, M., Floyd, S., Padhye, J., "Datagram
-              Congestion Control Protocol", Work in Progress, 10 March
-              2005.
-
-   [DNS]      Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-   [DTLS]     Modadugu, N., Rescorla, E., "The Design and Implementation
-              of Datagram TLS", Proceedings of ISOC NDSS 2004, February
-              2004.
-
-   [ESP]      Kent, S. and R. Atkinson, "IP Encapsulating Security
-              Payload (ESP)", RFC 2406, November 1998.
-
-   [IKE]      Harkins, D. and D. Carrel, "The Internet Key Exchange
-              (IKE)", RFC 2409, November 1998.
-
-   Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
-              December 2005.
-
-   [IMAP]     Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
-              4rev1", RFC 3501, March 2003.
-
-   [PHOTURIS] Karn, P. and W. Simpson, "ICMP Security Failures
-              Messages", RFC 2521, March 1999.
-
-   [POP]      Myers, J. and M. Rose, "Post Office Protocol - Version 3",
-              STD 53, RFC 1939, May 1996.
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [SCTP]     Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
-              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
-              Zhang, L., and V. Paxson, "Stream Control Transmission
-              Protocol", RFC 2960, October 2000.
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 23]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-   [SIP]      Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
-              A., Peterson, J., Sparks, R., Handley, M., and E.
-              Schooler, "SIP:  Session Initiation Protocol", RFC 3261,
-              June 2002.
-
-   [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
-              Work in Progress, October 2003.
-
-Authors' Addresses
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto, CA 94303
-
-   EMail: ekr@rtfm.com
-
-
-   Nagendra Modadugu
-   Computer Science Department
-   Stanford University
-   353 Serra Mall
-   Stanford, CA 94305
-
-   EMail: nagendra@cs.stanford.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 24]
-
-RFC 4347           Datagram Transport Layer Security          April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Rescorla & Modadugu         Standards Track                    [Page 25]
-
diff --git a/doc/protocol/rfc4366.txt b/doc/protocol/rfc4366.txt
deleted file mode 100644
index c7f7f97b6a..0000000000
--- a/doc/protocol/rfc4366.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    S. Blake-Wilson
-Request for Comments: 4366                                           BCI
-Obsoletes: 3546                                               M. Nystrom
-Updates: 4346                                               RSA Security
-Category: Standards Track                                     D. Hopwood
-                                                  Independent Consultant
-                                                            J. Mikkelsen
-                                                         Transactionware
-                                                               T. Wright
-                                                                Vodafone
-                                                              April 2006
-
-
-               Transport Layer Security (TLS) Extensions
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   The extensions may be used by TLS clients and servers.  The
-   extensions are backwards compatible: communication is possible
-   between TLS clients that support the extensions and TLS servers that
-   do not support the extensions, and vice versa.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 1]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. Conventions Used in This Document ..........................5
-   2. General Extension Mechanisms ....................................5
-      2.1. Extended Client Hello ......................................5
-      2.2. Extended Server Hello ......................................6
-      2.3. Hello Extensions ...........................................6
-      2.4. Extensions to the Handshake Protocol .......................8
-   3. Specific Extensions .............................................8
-      3.1.  Server Name Indication ....................................9
-      3.2.  Maximum Fragment Length Negotiation ......................11
-      3.3.  Client Certificate URLs ..................................12
-      3.4.  Trusted CA Indication ....................................15
-      3.5. Truncated HMAC ............................................16
-      3.6. Certificate Status Request ................................17
-   4. Error Alerts ...................................................19
-   5. Procedure for Defining New Extensions ..........................20
-   6. Security Considerations ........................................21
-      6.1. Security of server_name ...................................22
-      6.2. Security of max_fragment_length ...........................22
-      6.3. Security of client_certificate_url ........................22
-      6.4. Security of trusted_ca_keys ...............................24
-      6.5. Security of truncated_hmac ................................24
-      6.6. Security of status_request ................................25
-   7. Internationalization Considerations ............................25
-   8. IANA Considerations ............................................25
-   9. Acknowledgements ...............................................27
-   10. Normative References ..........................................27
-   11. Informative References ........................................28
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 2]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-1.  Introduction
-
-   This document describes extensions that may be used to add
-   functionality to Transport Layer Security (TLS).  It provides both
-   generic extension mechanisms for the TLS handshake client and server
-   hellos, and specific extensions using these generic mechanisms.
-
-   TLS is now used in an increasing variety of operational environments,
-   many of which were not envisioned when the original design criteria
-   for TLS were determined.  The extensions introduced in this document
-   are designed to enable TLS to operate as effectively as possible in
-   new environments such as wireless networks.
-
-   Wireless environments often suffer from a number of constraints not
-   commonly present in wired environments.  These constraints may
-   include bandwidth limitations, computational power limitations,
-   memory limitations, and battery life limitations.
-
-   The extensions described here focus on extending the functionality
-   provided by the TLS protocol message formats.  Other issues, such as
-   the addition of new cipher suites, are deferred.
-
-   Specifically, the extensions described in this document:
-
-   -  Allow TLS clients to provide to the TLS server the name of the
-      server they are contacting.  This functionality is desirable in
-      order to facilitate secure connections to servers that host
-      multiple 'virtual' servers at a single underlying network address.
-
-   -  Allow TLS clients and servers to negotiate the maximum fragment
-      length to be sent.  This functionality is desirable as a result of
-      memory constraints among some clients, and bandwidth constraints
-      among some access networks.
-
-   -  Allow TLS clients and servers to negotiate the use of client
-      certificate URLs.  This functionality is desirable in order to
-      conserve memory on constrained clients.
-
-   -  Allow TLS clients to indicate to TLS servers which CA root keys
-      they possess.  This functionality is desirable in order to prevent
-      multiple handshake failures involving TLS clients that are only
-      able to store a small number of CA root keys due to memory
-      limitations.
-
-   -  Allow TLS clients and servers to negotiate the use of truncated
-      MACs.  This functionality is desirable in order to conserve
-      bandwidth in constrained access networks.
-
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 3]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   -  Allow TLS clients and servers to negotiate that the server sends
-      the client certificate status information (e.g., an Online
-      Certificate Status Protocol (OCSP) [OCSP] response) during a TLS
-      handshake.  This functionality is desirable in order to avoid
-      sending a Certificate Revocation List (CRL) over a constrained
-      access network and therefore save bandwidth.
-
-   In order to support the extensions above, general extension
-   mechanisms for the client hello message and the server hello message
-   are introduced.
-
-   The extensions described in this document may be used by TLS clients
-   and servers.  The extensions are designed to be backwards compatible,
-   meaning that TLS clients that support the extensions can talk to TLS
-   servers that do not support the extensions, and vice versa.  The
-   document therefore updates TLS 1.0 [TLS] and TLS 1.1 [TLSbis].
-
-   Backwards compatibility is primarily achieved via two considerations:
-
-   -  Clients typically request the use of extensions via the extended
-      client hello message described in Section 2.1. TLS requires
-      servers to accept extended client hello messages, even if the
-      server does not "understand" the extension.
-
-   -  For the specific extensions described here, no mandatory server
-      response is required when clients request extended functionality.
-
-   Essentially, backwards compatibility is achieved based on the TLS
-   requirement that servers that are not "extensions-aware" ignore data
-   added to client hellos that they do not recognize; for example, see
-   Section 7.4.1.2 of [TLS].
-
-   Note, however, that although backwards compatibility is supported,
-   some constrained clients may be forced to reject communications with
-   servers that do not support the extensions as a result of the limited
-   capabilities of such clients.
-
-   This document is a revision of the RFC3546 [RFC3546].  The only major
-   change concerns the definition of new extensions.  New extensions can
-   now be defined via the IETF Consensus Process (rather than requiring
-   a standards track RFC).  In addition, a few minor clarifications and
-   editorial improvements were made.
-
-   The remainder of this document is organized as follows.  Section 2
-   describes general extension mechanisms for the client hello and
-   server hello handshake messages.  Section 3 describes specific
-   extensions to TLS.  Section 4 describes new error alerts for use with
-
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 4]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   the TLS extensions.  The final sections of the document address IPR,
-   security considerations, registration of the application/pkix-pkipath
-   MIME type, acknowledgements, and references.
-
-1.1.  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 BCP 14, RFC 2119
-   [KEYWORDS].
-
-2.  General Extension Mechanisms
-
-   This section presents general extension mechanisms for the TLS
-   handshake client hello and server hello messages.
-
-   These general extension mechanisms are necessary in order to enable
-   clients and servers to negotiate whether to use specific extensions,
-   and how to use specific extensions.  The extension formats described
-   are based on [MAILINGLIST].
-
-   Section 2.1 specifies the extended client hello message format,
-   Section 2.2 specifies the extended server hello message format, and
-   Section 2.3 describes the actual extension format used with the
-   extended client and server hellos.
-
-2.1.  Extended Client Hello
-
-   Clients MAY request extended functionality from servers by sending
-   the extended client hello message format in place of the client hello
-   message format.  The extended client hello message format is:
-
-         struct {
-             ProtocolVersion client_version;
-             Random random;
-             SessionID session_id;
-             CipherSuite cipher_suites<2..2^16-1>;
-             CompressionMethod compression_methods<1..2^8-1>;
-             Extension client_hello_extension_list<0..2^16-1>;
-         } ClientHello;
-
-   Here the new "client_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   In the event that a client requests additional functionality using
-   the extended client hello, and this functionality is not supplied by
-   the server, the client MAY abort the handshake.
-
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 5]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   Note that [TLS], Section 7.4.1.2, allows additional information to be
-   added to the client hello message.  Thus, the use of the extended
-   client hello defined above should not "break" existing TLS servers.
-
-   A server that supports the extensions mechanism MUST accept only
-   client hello messages in either the original or extended ClientHello
-   format and (as for all other messages) MUST check that the amount of
-   data in the message precisely matches one of these formats.  If it
-   does not, then it MUST send a fatal "decode_error" alert.  This
-   overrides the "Forward compatibility note" in [TLS].
-
-2.2.  Extended Server Hello
-
-   The extended server hello message format MAY be sent in place of the
-   server hello message when the client has requested extended
-   functionality via the extended client hello message specified in
-   Section 2.1.  The extended server hello message format is:
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          Extension server_hello_extension_list<0..2^16-1>;
-      } ServerHello;
-
-   Here the new "server_hello_extension_list" field contains a list of
-   extensions.  The actual "Extension" format is defined in Section 2.3.
-
-   Note that the extended server hello message is only sent in response
-   to an extended client hello message.  This prevents the possibility
-   that the extended server hello message could "break" existing TLS
-   clients.
-
-2.3.  Hello Extensions
-
-   The extension format for extended client hellos and extended server
-   hellos is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 6]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   Here:
-
-   - "extension_type" identifies the particular extension type.
-
-   - "extension_data" contains information specific to the particular
-     extension type.
-
-   The extension types defined in this document are:
-
-      enum {
-          server_name(0), max_fragment_length(1),
-          client_certificate_url(2), trusted_ca_keys(3),
-          truncated_hmac(4), status_request(5), (65535)
-      } ExtensionType;
-
-   The list of defined extension types is maintained by the IANA.  The
-   current list can be found at:
-   http://www.iana.org/assignments/tls-extensiontype-values.  See
-   Sections 5 and 8 for more information on how new values are added.
-
-   Note that for all extension types (including those defined in the
-   future), the extension type MUST NOT appear in the extended server
-   hello unless the same extension type appeared in the corresponding
-   client hello.  Thus clients MUST abort the handshake if they receive
-   an extension type in the extended server hello that they did not
-   request in the associated (extended) client hello.
-
-   Nonetheless, "server-oriented" extensions may be provided in the
-   future within this framework.  Such an extension (say, of type x)
-   would require the client to first send an extension of type x in the
-   (extended) client hello with empty extension_data to indicate that it
-   supports the extension type.  In this case, the client is offering
-   the capability to understand the extension type, and the server is
-   taking the client up on its offer.
-
-   Also note that when multiple extensions of different types are
-   present in the extended client hello or the extended server hello,
-   the extensions may appear in any order.  There MUST NOT be more than
-   one extension of the same type.
-
-   Finally, note that an extended client hello may be sent both when
-   starting a new session and when requesting session resumption.
-   Indeed, a client that requests resumption of a session does not in
-   general know whether the server will accept this request, and
-   therefore it SHOULD send an extended client hello if it would
-   normally do so for a new session.  In general the specification of
-   each extension type must include a discussion of the effect of the
-   extension both during new sessions and during resumed sessions.
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 7]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-2.4.  Extensions to the Handshake Protocol
-
-   This document suggests the use of two new handshake messages,
-   "CertificateURL" and "CertificateStatus".  These messages are
-   described in Section 3.3 and Section 3.6, respectively.  The new
-   handshake message structure therefore becomes:
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), certificate_url(21), certificate_status(22),
-          (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case certificate_url:     CertificateURL;
-              case certificate_status:  CertificateStatus;
-          } body;
-      } Handshake;
-
-3.  Specific Extensions
-
-   This section describes the specific TLS extensions specified in this
-   document.
-
-   Note that any messages associated with these extensions that are sent
-   during the TLS handshake MUST be included in the hash calculations
-   involved in "Finished" messages.
-
-   Note also that all the extensions defined in this section are
-   relevant only when a session is initiated.  When a client includes
-   one or more of the defined extension types in an extended client
-   hello while requesting session resumption:
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 8]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   -  If the resumption request is denied, the use of the extensions is
-      negotiated as normal.
-
-   -  If, on the other hand, the older session is resumed, then the
-      server MUST ignore the extensions and send a server hello
-      containing none of the extension types.  In this case, the
-      functionality of these extensions negotiated during the original
-      session initiation is applied to the resumed session.
-
-   Section 3.1 describes the extension of TLS to allow a client to
-   indicate which server it is contacting.  Section 3.2 describes the
-   extension that provides maximum fragment length negotiation.  Section
-   3.3 describes the extension that allows client certificate URLs.
-   Section 3.4 describes the extension that allows a client to indicate
-   which CA root keys it possesses.  Section 3.5 describes the extension
-   that allows the use of truncated HMAC.  Section 3.6 describes the
-   extension that supports integration of certificate status information
-   messages into TLS handshakes.
-
-3.1.  Server Name Indication
-
-   TLS does not provide a mechanism for a client to tell a server the
-   name of the server it is contacting.  It may be desirable for clients
-   to provide this information to facilitate secure connections to
-   servers that host multiple 'virtual' servers at a single underlying
-   network address.
-
-   In order to provide the server name, clients MAY include an extension
-   of type "server_name" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "ServerNameList" where:
-
-      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;
-
-
-
-Blake-Wilson, et al.        Standards Track                     [Page 9]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   Currently, the only server names supported are DNS hostnames;
-   however, this does not imply any dependency of TLS on DNS, and other
-   name types may be added in the future (by an RFC that updates this
-   document).  TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
-
-   "HostName" contains the fully qualified DNS hostname of the server,
-   as understood by the client.  The hostname is represented as a byte
-   string using UTF-8 encoding [UTF8], without a trailing dot.
-
-   If the hostname labels contain only US-ASCII characters, then the
-   client MUST ensure that labels are separated only by the byte 0x2E,
-   representing the dot character U+002E (requirement 1 in Section 3.1
-   of [IDNA] notwithstanding).  If the server needs to match the
-   HostName against names that contain non-US-ASCII characters, it MUST
-   perform the conversion operation described in Section 4 of [IDNA],
-   treating the HostName as a "query string" (i.e., the AllowUnassigned
-   flag MUST be set).  Note that IDNA allows labels to be separated by
-   any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
-   therefore, servers MUST accept any of these characters as a label
-   separator.  If the server only needs to match the HostName against
-   names containing exclusively ASCII characters, it MUST compare ASCII
-   names case-insensitively.
-
-   Literal IPv4 and IPv6 addresses are not permitted in "HostName".
-
-   It is RECOMMENDED that clients include an extension of type
-   "server_name" in the client hello whenever they locate a server by a
-   supported name type.
-
-   A server that receives a client hello containing the "server_name"
-   extension MAY use the information contained in the extension to guide
-   its selection of an appropriate certificate to return to the client,
-   and/or other aspects of security policy.  In this event, the server
-   SHALL include an extension of type "server_name" in the (extended)
-   server hello.  The "extension_data" field of this extension SHALL be
-   empty.
-
-   If the server understood the client hello extension but does not
-   recognize the server name, it SHOULD send an "unrecognized_name"
-   alert (which MAY be fatal).
-
-   If an application negotiates a server name using an application
-   protocol and then upgrades to TLS, and if a server_name extension is
-   sent, then the extension SHOULD contain the same name that was
-   negotiated in the application protocol.  If the server_name is
-   established in the TLS session handshake, the client SHOULD NOT
-   attempt to request a different server name at the application layer.
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 10]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-3.2.  Maximum Fragment Length Negotiation
-
-   Without this extension, TLS specifies a fixed maximum plaintext
-   fragment length of 2^14 bytes.  It may be desirable for constrained
-   clients to negotiate a smaller maximum fragment length due to memory
-   limitations or bandwidth limitations.
-
-   In order to negotiate smaller maximum fragment lengths, clients MAY
-   include an extension of type "max_fragment_length" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain:
-
-   enum{
-       2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
-   } MaxFragmentLength;
-
-   whose value is the desired maximum fragment length.  The allowed
-   values for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-   Servers that receive an extended client hello containing a
-   "max_fragment_length" extension MAY accept the requested maximum
-   fragment length by including an extension of type
-   "max_fragment_length" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL contain a
-   "MaxFragmentLength" whose value is the same as the requested maximum
-   fragment length.
-
-   If a server receives a maximum fragment length negotiation request
-   for a value other than the allowed values, it MUST abort the
-   handshake with an "illegal_parameter" alert.  Similarly, if a client
-   receives a maximum fragment length negotiation response that differs
-   from the length it requested, it MUST also abort the handshake with
-   an "illegal_parameter" alert.
-
-   Once a maximum fragment length other than 2^14 has been successfully
-   negotiated, the client and server MUST immediately begin fragmenting
-   messages (including handshake messages), to ensure that no fragment
-   larger than the negotiated length is sent.  Note that TLS already
-   requires clients and servers to support fragmentation of handshake
-   messages.
-
-   The negotiated length applies for the duration of the session
-   including session resumptions.
-
-   The negotiated length limits the input that the record layer may
-   process without fragmentation (that is, the maximum value of
-   TLSPlaintext.length; see [TLS], Section 6.2.1).  Note that the output
-   of the record layer may be larger.  For example, if the negotiated
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 11]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   length is 2^9=512, then for currently defined cipher suites (those
-   defined in [TLS], [KERB], and [AESSUITES]), and when null compression
-   is used, the record layer output can be at most 793 bytes: 5 bytes of
-   headers, 512 bytes of application data, 256 bytes of padding, and 20
-   bytes of MAC.  This means that in this event a TLS record layer peer
-   receiving a TLS record layer message larger than 793 bytes may
-   discard the message and send a "record_overflow" alert, without
-   decrypting the message.
-
-3.3.  Client Certificate URLs
-
-   Without this extension, TLS specifies that when client authentication
-   is performed, client certificates are sent by clients to servers
-   during the TLS handshake.  It may be desirable for constrained
-   clients to send certificate URLs in place of certificates, so that
-   they do not need to store their certificates and can therefore save
-   memory.
-
-   In order to negotiate sending certificate URLs to a server, clients
-   MAY include an extension of type "client_certificate_url" in the
-   (extended) client hello.  The "extension_data" field of this
-   extension SHALL be empty.
-
-   (Note that it is necessary to negotiate use of client certificate
-   URLs in order to avoid "breaking" existing TLS servers.)
-
-   Servers that receive an extended client hello containing a
-   "client_certificate_url" extension MAY indicate that they are willing
-   to accept certificate URLs by including an extension of type
-   "client_certificate_url" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-   After negotiation of the use of client certificate URLs has been
-   successfully completed (by exchanging hellos including
-   "client_certificate_url" extensions), clients MAY send a
-   "CertificateURL" message in place of a "Certificate" message:
-
-      enum {
-          individual_certs(0), pkipath(1), (255)
-      } CertChainType;
-
-      enum {
-          false(0), true(1)
-      } Boolean;
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 12]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-      struct {
-          CertChainType type;
-          URLAndOptionalHash url_and_hash_list<1..2^16-1>;
-      } CertificateURL;
-
-      struct {
-          opaque url<1..2^16-1>;
-          Boolean hash_present;
-          select (hash_present) {
-              case false: struct {};
-              case true: SHA1Hash;
-          } hash;
-      } URLAndOptionalHash;
-
-      opaque SHA1Hash[20];
-
-   Here "url_and_hash_list" contains a sequence of URLs and optional
-   hashes.
-
-   When X.509 certificates are used, there are two possibilities:
-
-   -  If CertificateURL.type is "individual_certs", each URL refers to a
-      single DER-encoded X.509v3 certificate, with the URL for the
-      client's certificate first.
-
-   -  If CertificateURL.type is "pkipath", the list contains a single
-      URL referring to a DER-encoded certificate chain, using the type
-      PkiPath described in Section 8.
-
-   When any other certificate format is used, the specification that
-   describes use of that format in TLS should define the encoding format
-   of certificates or certificate chains, and any constraint on their
-   ordering.
-
-   The hash corresponding to each URL at the client's discretion either
-   is not present or is the SHA-1 hash of the certificate or certificate
-   chain (in the case of X.509 certificates, the DER-encoded certificate
-   or the DER-encoded PkiPath).
-
-   Note that when a list of URLs for X.509 certificates is used, the
-   ordering of URLs is the same as that used in the TLS Certificate
-   message (see [TLS], Section 7.4.2), but opposite to the order in
-   which certificates are encoded in PkiPath.  In either case, the
-   self-signed root certificate MAY be omitted from the chain, under the
-   assumption that the server must already possess it in order to
-   validate it.
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 13]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   Servers receiving "CertificateURL" SHALL attempt to retrieve the
-   client's certificate chain from the URLs and then process the
-   certificate chain as usual.  A cached copy of the content of any URL
-   in the chain MAY be used, provided that a SHA-1 hash is present for
-   that URL and it matches the hash of the cached copy.
-
-   Servers that support this extension MUST support the http: URL scheme
-   for certificate URLs, and MAY support other schemes.  Use of other
-   schemes than "http", "https", or "ftp" may create unexpected
-   problems.
-
-   If the protocol used is HTTP, then the HTTP server can be configured
-   to use the Cache-Control and Expires directives described in [HTTP]
-   to specify whether and for how long certificates or certificate
-   chains should be cached.
-
-   The TLS server is not required to follow HTTP redirects when
-   retrieving the certificates or certificate chain.  The URLs used in
-   this extension SHOULD therefore be chosen not to depend on such
-   redirects.
-
-   If the protocol used to retrieve certificates or certificate chains
-   returns a MIME-formatted response (as HTTP does), then the following
-   MIME Content-Types SHALL be used: when a single X.509v3 certificate
-   is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
-   when a chain of X.509v3 certificates is returned, the Content-Type is
-   "application/pkix-pkipath" (see Section 8).
-
-   If a SHA-1 hash is present for an URL, then the server MUST check
-   that the SHA-1 hash of the contents of the object retrieved from that
-   URL (after decoding any MIME Content-Transfer-Encoding) matches the
-   given hash.  If any retrieved object does not have the correct SHA-1
-   hash, the server MUST abort the handshake with a
-   "bad_certificate_hash_value" alert.
-
-   Note that clients may choose to send either "Certificate" or
-   "CertificateURL" after successfully negotiating the option to send
-   certificate URLs.  The option to send a certificate is included to
-   provide flexibility to clients possessing multiple certificates.
-
-   If a server encounters an unreasonable delay in obtaining
-   certificates in a given CertificateURL, it SHOULD time out and signal
-   a "certificate_unobtainable" error alert.
-
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 14]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-3.4.  Trusted CA Indication
-
-   Constrained clients that, due to memory limitations, possess only a
-   small number of CA root keys may wish to indicate to servers which
-   root keys they possess, in order to avoid repeated handshake
-   failures.
-
-   In order to indicate which CA root keys they possess, clients MAY
-   include an extension of type "trusted_ca_keys" in the (extended)
-   client hello.  The "extension_data" field of this extension SHALL
-   contain "TrustedAuthorities" where:
-
-      struct {
-          TrustedAuthority trusted_authorities_list<0..2^16-1>;
-      } TrustedAuthorities;
-
-      struct {
-          IdentifierType identifier_type;
-          select (identifier_type) {
-              case pre_agreed: struct {};
-              case key_sha1_hash: SHA1Hash;
-              case x509_name: DistinguishedName;
-              case cert_sha1_hash: SHA1Hash;
-          } identifier;
-      } TrustedAuthority;
-
-      enum {
-          pre_agreed(0), key_sha1_hash(1), x509_name(2),
-          cert_sha1_hash(3), (255)
-      } IdentifierType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-   Here "TrustedAuthorities" provides a list of CA root key identifiers
-   that the client possesses.  Each CA root key is identified via
-   either:
-
-   -  "pre_agreed": no CA root key identity supplied.
-
-   -  "key_sha1_hash": contains the SHA-1 hash of the CA root key.  For
-      Digital Signature Algorithm (DSA) and Elliptic Curve Digital
-      Signature Algorithm (ECDSA) keys, this is the hash of the
-      "subjectPublicKey" value.  For RSA keys, the hash is of the big-
-      endian byte string representation of the modulus without any
-      initial 0-valued bytes.  (This copies the key hash formats
-      deployed in other environments.)
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 15]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   -  "x509_name": contains the DER-encoded X.509 DistinguishedName of
-      the CA.
-
-   -  "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
-      Certificate containing the CA root key.
-
-   Note that clients may include none, some, or all of the CA root keys
-   they possess in this extension.
-
-   Note also that it is possible that a key hash or a Distinguished Name
-   alone may not uniquely identify a certificate issuer (for example, if
-   a particular CA has multiple key pairs).  However, here we assume
-   this is the case following the use of Distinguished Names to identify
-   certificate issuers in TLS.
-
-   The option to include no CA root keys is included to allow the client
-   to indicate possession of some pre-defined set of CA root keys.
-
-   Servers that receive a client hello containing the "trusted_ca_keys"
-   extension MAY use the information contained in the extension to guide
-   their selection of an appropriate certificate chain to return to the
-   client.  In this event, the server SHALL include an extension of type
-   "trusted_ca_keys" in the (extended) server hello.  The
-   "extension_data" field of this extension SHALL be empty.
-
-3.5.  Truncated HMAC
-
-   Currently defined TLS cipher suites use the MAC construction HMAC
-   with either MD5 or SHA-1 [HMAC] to authenticate record layer
-   communications.  In TLS, the entire output of the hash function is
-   used as the MAC tag.  However, it may be desirable in constrained
-   environments to save bandwidth by truncating the output of the hash
-   function to 80 bits when forming MAC tags.
-
-   In order to negotiate the use of 80-bit truncated HMAC, clients MAY
-   include an extension of type "truncated_hmac" in the extended client
-   hello.  The "extension_data" field of this extension SHALL be empty.
-
-   Servers that receive an extended hello containing a "truncated_hmac"
-   extension MAY agree to use a truncated HMAC by including an extension
-   of type "truncated_hmac", with empty "extension_data", in the
-   extended server hello.
-
-   Note that if new cipher suites are added that do not use HMAC, and
-   the session negotiates one of these cipher suites, this extension
-   will have no effect.  It is strongly recommended that any new cipher
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 16]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   suites using other MACs consider the MAC size an integral part of the
-   cipher suite definition, taking into account both security and
-   bandwidth considerations.
-
-   If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated cipher suite uses HMAC, both the client
-   and the server pass this fact to the TLS record layer along with the
-   other negotiated security parameters.  Subsequently during the
-   session, clients and servers MUST use truncated HMACs, calculated as
-   specified in [HMAC].  That is, CipherSpec.hash_size is 10 bytes, and
-   only the first 10 bytes of the HMAC output are transmitted and
-   checked.  Note that this extension does not affect the calculation of
-   the pseudo-random function (PRF) as part of handshaking or key
-   derivation.
-
-   The negotiated HMAC truncation size applies for the duration of the
-   session including session resumptions.
-
-3.6.  Certificate Status Request
-
-   Constrained clients may wish to use a certificate-status protocol
-   such as OCSP [OCSP] to check the validity of server certificates, in
-   order to avoid transmission of CRLs and therefore save bandwidth on
-   constrained networks.  This extension allows for such information to
-   be sent in the TLS handshake, saving roundtrips and resources.
-
-   In order to indicate their desire to receive certificate status
-   information, clients MAY include an extension of type
-   "status_request" in the (extended) client hello.  The
-   "extension_data" field of this extension SHALL contain
-   "CertificateStatusRequest" where:
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPStatusRequest;
-          } request;
-      } CertificateStatusRequest;
-
-      enum { ocsp(1), (255) } CertificateStatusType;
-
-      struct {
-          ResponderID responder_id_list<0..2^16-1>;
-          Extensions  request_extensions;
-      } OCSPStatusRequest;
-
-      opaque ResponderID<1..2^16-1>;
-      opaque Extensions<0..2^16-1>;
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 17]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
-   responders that the client trusts.  A zero-length "responder_id_list"
-   sequence has the special meaning that the responders are implicitly
-   known to the server, e.g., by prior arrangement.  "Extensions" is a
-   DER encoding of OCSP request extensions.
-
-   Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [OCSP].  "Extensions" is imported from [PKIX].  A zero-
-   length "request_extensions" value means that there are no extensions
-   (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
-   the "Extensions" type).
-
-   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
-   unclear about its encoding; for clarification, the nonce MUST be a
-   DER-encoded OCTET STRING, which is encapsulated as another OCTET
-   STRING (note that implementations based on an existing OCSP client
-   will need to be checked for conformance to this requirement).
-
-   Servers that receive a client hello containing the "status_request"
-   extension MAY return a suitable certificate status response to the
-   client along with their certificate.  If OCSP is requested, they
-   SHOULD use the information contained in the extension when selecting
-   an OCSP responder and SHOULD include request_extensions in the OCSP
-   request.
-
-   Servers return a certificate response along with their certificate by
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages).  If a server returns a
-
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
-   extended server hello.
-
-      struct {
-          CertificateStatusType status_type;
-          select (status_type) {
-              case ocsp: OCSPResponse;
-          } response;
-      } CertificateStatus;
-
-      opaque OCSPResponse<1..2^24-1>;
-
-   An "ocsp_response" contains a complete, DER-encoded OCSP response
-   (using the ASN.1 type OCSPResponse defined in [OCSP]).  Note that
-   only one OCSP response may be sent.
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 18]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   The "CertificateStatus" message is conveyed using the handshake
-   message type "certificate_status".
-
-   Note that a server MAY also choose not to send a "CertificateStatus"
-   message, even if it receives a "status_request" extension in the
-   client hello message.
-
-   Note in addition that servers MUST NOT send the "CertificateStatus"
-   message unless it received a "status_request" extension in the client
-   hello message.
-
-   Clients requesting an OCSP response and receiving an OCSP response in
-   a "CertificateStatus" message MUST check the OCSP response and abort
-   the handshake if the response is not satisfactory.
-
-4.  Error Alerts
-
-   This section defines new error alerts for use with the TLS extensions
-   defined in this document.
-
-   The following new error alerts are defined.  To avoid "breaking"
-   existing clients and servers, these alerts MUST NOT be sent unless
-   the sending party has received an extended hello message from the
-   party they are communicating with.
-
-   -  "unsupported_extension": this alert is sent by clients that
-      receive an extended server hello containing an extension that they
-      did not put in the corresponding client hello (see Section 2.3).
-      This message is always fatal.
-
-   -  "unrecognized_name": this alert is sent by servers that receive a
-      server_name extension request, but do not recognize the server
-      name.  This message MAY be fatal.
-
-   -  "certificate_unobtainable": this alert is sent by servers who are
-      unable to retrieve a certificate chain from the URL supplied by
-      the client (see Section 3.3).  This message MAY be fatal; for
-      example, if client authentication is required by the server for
-      the handshake to continue and the server is unable to retrieve the
-      certificate chain, it may send a fatal alert.
-
-   -  "bad_certificate_status_response": this alert is sent by clients
-      that receive an invalid certificate status response (see Section
-      3.6).  This message is always fatal.
-
-   -  "bad_certificate_hash_value": this alert is sent by servers when a
-      certificate hash does not match a client-provided
-      certificate_hash.  This message is always fatal.
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 19]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   These error alerts are conveyed using the following syntax:
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          /* 41 is not defined, for historical reasons */
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-          export_restriction(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-          no_renegotiation(100),
-          unsupported_extension(110),           /* new */
-          certificate_unobtainable(111),        /* new */
-          unrecognized_name(112),               /* new */
-          bad_certificate_status_response(113), /* new */
-          bad_certificate_hash_value(114),      /* new */
-          (255)
-      } AlertDescription;
-
-5.  Procedure for Defining New Extensions
-
-   The list of extension types, as defined in Section 2.3, is maintained
-   by the Internet Assigned Numbers Authority (IANA).  Thus, an
-   application needs to be made to the IANA in order to obtain a new
-   extension type value.  Since there are subtle (and not-so-subtle)
-   interactions that may occur in this protocol between new features and
-   existing features that may result in a significant reduction in
-   overall security, new values SHALL be defined only through the IETF
-   Consensus process specified in [IANA].
-
-   (This means that new assignments can be made only via RFCs approved
-   by the IESG.)
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 20]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   The following considerations should be taken into account when
-   designing new extensions:
-
-   -  All of the extensions defined in this document follow the
-      convention that for each extension that a client requests and that
-      the server understands, the server replies with an extension of
-      the same type.
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some simply a refusal to support a particular
-      feature.  In general, error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should as far as possible be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase.  Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example, the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS, particularly since the
-      TLS handshake algorithms have specific protection against version
-      rollback attacks based on the version number.  The possibility of
-      version rollback should be a significant consideration in any
-      major design change.
-
-6.  Security Considerations
-
-   Security considerations for the extension mechanism in general and
-   for the design of new extensions are described in the previous
-   section.  A security analysis of each of the extensions defined in
-   this document is given below.
-
-   In general, implementers should continue to monitor the state of the
-   art and address any weaknesses identified.
-
-   Additional security considerations are described in the TLS 1.0 RFC
-   [TLS] and the TLS 1.1 RFC [TLSbis].
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 21]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-6.1.  Security of server_name
-
-   If a single server hosts several domains, then clearly it is
-   necessary for the owners of each domain to ensure that this satisfies
-   their security needs.  Apart from this, server_name does not appear
-   to introduce significant security issues.
-
-   Implementations MUST ensure that a buffer overflow does not occur,
-   whatever the values of the length fields in server_name.
-
-   Although this document specifies an encoding for internationalized
-   hostnames in the server_name extension, it does not address any
-   security issues associated with the use of internationalized
-   hostnames in TLS (in particular, the consequences of "spoofed" names
-   that are indistinguishable from another name when displayed or
-   printed).  It is recommended that server certificates not be issued
-   for internationalized hostnames unless procedures are in place to
-   mitigate the risk of spoofed hostnames.
-
-6.2.  Security of max_fragment_length
-
-   The maximum fragment length takes effect immediately, including for
-   handshake messages.  However, that does not introduce any security
-   complications that are not already present in TLS, since TLS requires
-   implementations to be able to handle fragmented handshake messages.
-
-   Note that as described in Section 3.2, once a non-null cipher suite
-   has been activated, the effective maximum fragment length depends on
-   the cipher suite and compression method, as well as on the negotiated
-   max_fragment_length.  This must be taken into account when sizing
-   buffers, and checking for buffer overflow.
-
-6.3.  Security of client_certificate_url
-
-   There are two major issues with this extension.
-
-   The first major issue is whether or not clients should include
-   certificate hashes when they send certificate URLs.
-
-   When client authentication is used *without* the
-   client_certificate_url extension, the client certificate chain is
-   covered by the Finished message hashes.  The purpose of including
-   hashes and checking them against the retrieved certificate chain is
-   to ensure that the same property holds when this extension is used,
-   i.e., that all of the information in the certificate chain retrieved
-   by the server is as the client intended.
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 22]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   On the other hand, omitting certificate hashes enables functionality
-   that is desirable in some circumstances; for example, clients can be
-   issued daily certificates that are stored at a fixed URL and need not
-   be provided to the client.  Clients that choose to omit certificate
-   hashes should be aware of the possibility of an attack in which the
-   attacker obtains a valid certificate on the client's key that is
-   different from the certificate the client intended to provide.
-   Although TLS uses both MD5 and SHA-1 hashes in several other places,
-   this was not believed to be necessary here.  The property required of
-   SHA-1 is second pre-image resistance.
-
-   The second major issue is that support for client_certificate_url
-   involves the server's acting as a client in another URL protocol.
-   The server therefore becomes subject to many of the same security
-   concerns that clients of the URL scheme are subject to, with the
-   added concern that the client can attempt to prompt the server to
-   connect to some (possibly weird-looking) URL.
-
-   In general, this issue means that an attacker might use the server to
-   indirectly attack another host that is vulnerable to some security
-   flaw.  It also introduces the possibility of denial of service
-   attacks in which an attacker makes many connections to the server,
-   each of which results in the server's attempting a connection to the
-   target of the attack.
-
-   Note that the server may be behind a firewall or otherwise able to
-   access hosts that would not be directly accessible from the public
-   Internet.  This could exacerbate the potential security and denial of
-   service problems described above, as well as allow the existence of
-   internal hosts to be confirmed when they would otherwise be hidden.
-
-   The detailed security concerns involved will depend on the URL
-   schemes supported by the server.  In the case of HTTP, the concerns
-   are similar to those that apply to a publicly accessible HTTP proxy
-   server.  In the case of HTTPS, loops and deadlocks may be created,
-   and this should be addressed.  In the case of FTP, attacks arise that
-   are similar to FTP bounce attacks.
-
-   As a result of this issue, it is RECOMMENDED that the
-   client_certificate_url extension should have to be specifically
-   enabled by a server administrator, rather than be enabled by default.
-   It is also RECOMMENDED that URI protocols be enabled by the
-   administrator individually, and only a minimal set of protocols be
-   enabled.  Unusual protocols that offer limited security or whose
-   security is not well-understood SHOULD be avoided.
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 23]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   As discussed in [URI], URLs that specify ports other than the default
-   may cause problems, as may very long URLs (which are more likely to
-   be useful in exploiting buffer overflow bugs).
-
-   Also note that HTTP caching proxies are common on the Internet, and
-   some proxies do not check for the latest version of an object
-   correctly.  If a request using HTTP (or another caching protocol)
-   goes through a misconfigured or otherwise broken proxy, the proxy may
-   return an out-of-date response.
-
-6.4.  Security of trusted_ca_keys
-
-   It is possible that which CA root keys a client possesses could be
-   regarded as confidential information.  As a result, the CA root key
-   indication extension should be used with care.
-
-   The use of the SHA-1 certificate hash alternative ensures that each
-   certificate is specified unambiguously.  As for the previous
-   extension, it was not believed necessary to use both MD5 and SHA-1
-   hashes.
-
-6.5.  Security of truncated_hmac
-
-   It is possible that truncated MACs are weaker than "un-truncated"
-   MACs.  However, no significant weaknesses are currently known or
-   expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
-
-   Note that the output length of a MAC need not be as long as the
-   length of a symmetric cipher key, since forging of MAC values cannot
-   be done off-line: in TLS, a single failed MAC guess will cause the
-   immediate termination of the TLS session.
-
-   Since the MAC algorithm only takes effect after all handshake
-   messages that affect extension parameters have been authenticated by
-   the hashes in the Finished messages, it is not possible for an active
-   attacker to force negotiation of the truncated HMAC extension where
-   it would not otherwise be used (to the extent that the handshake
-   authentication is secure).  Therefore, in the event that any security
-   problem were found with truncated HMAC in the future, if either the
-   client or the server for a given session were updated to take the
-   problem into account, it would be able to veto use of this extension.
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 24]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-6.6.  Security of status_request
-
-   If a client requests an OCSP response, it must take into account that
-   an attacker's server using a compromised key could (and probably
-   would) pretend not to support the extension.  In this case, a client
-   that requires OCSP validation of certificates SHOULD either contact
-   the OCSP server directly or abort the handshake.
-
-   Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
-   improve security against attacks that attempt to replay OCSP
-   responses; see Section 4.4.1 of [OCSP] for further details.
-
-7.  Internationalization Considerations
-
-   None of the extensions defined here directly use strings subject to
-   localization.  Domain Name System (DNS) hostnames are encoded using
-   UTF-8.  If future extensions use text strings, then
-   internationalization should be considered in their design.
-
-8.  IANA Considerations
-
-   Sections 2.3 and 5 describe a registry of ExtensionType values to be
-   maintained by the IANA.  ExtensionType values are to be assigned via
-   IETF Consensus as defined in RFC 2434 [IANA].  The initial registry
-   corresponds to the definition of "ExtensionType" in Section 2.3.
-
-   The MIME type "application/pkix-pkipath" has been registered by the
-   IANA with the following template:
-
-   To: ietf-types@iana.org
-   Subject: Registration of MIME media type application/pkix-pkipath
-
-   MIME media type name: application
-   MIME subtype name: pkix-pkipath
-   Required parameters: none
-
-   Optional parameters: version (default value is "1")
-
-   Encoding considerations:
-      This MIME type is a DER encoding of the ASN.1 type PkiPath,
-      defined as follows:
-        PkiPath ::= SEQUENCE OF Certificate
-        PkiPath is used to represent a certification path.  Within the
-        sequence, the order of certificates is such that the subject of
-        the first certificate is the issuer of the second certificate,
-        etc.
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 25]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-      This is identical to the definition published in [X509-4th-TC1];
-      note that it is different from that in [X509-4th].
-
-      All Certificates MUST conform to [PKIX].  (This should be
-      interpreted as a requirement to encode only PKIX-conformant
-      certificates using this type.  It does not necessarily require
-      that all certificates that are not strictly PKIX-conformant must
-      be rejected by relying parties, although the security consequences
-      of accepting any such certificates should be considered
-      carefully.)
-
-      DER (as opposed to BER) encoding MUST be used.  If this type is
-      sent over a 7-bit transport, base64 encoding SHOULD be used.
-
-   Security considerations:
-      The security considerations of [X509-4th] and [PKIX] (or any
-      updates to them) apply, as well as those of any protocol that uses
-      this type (e.g., TLS).
-
-      Note that this type only specifies a certificate chain that can be
-      assessed for validity according to the relying party's existing
-      configuration of trusted CAs; it is not intended to be used to
-      specify any change to that configuration.
-
-   Interoperability considerations:
-      No specific interoperability problems are known with this type,
-      but for recommendations relating to X.509 certificates in general,
-      see [PKIX].
-
-   Published specification: RFC 4366 (this memo), and [PKIX].
-
-   Applications which use this media type: TLS.  It may also be used by
-      other protocols, or for general interchange of PKIX certificate
-      chains.
-
-   Additional information:
-      Magic number(s): DER-encoded ASN.1 can be easily recognized.
-        Further parsing is required to distinguish it from other ASN.1
-        types.
-      File extension(s): .pkipath
-      Macintosh File Type Code(s): not specified
-
-   Person & email address to contact for further information:
-      Magnus Nystrom <magnus@rsasecurity.com>
-
-   Intended usage: COMMON
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 26]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   Change controller:
-      IESG <iesg@ietf.org>
-
-9.  Acknowledgements
-
-   The authors wish to thank the TLS Working Group and the WAP Security
-   Group.  This document is based on discussion within these groups.
-
-10.  Normative References
-
-   [HMAC]         Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
-                  Keyed-Hashing for Message Authentication", RFC 2104,
-                  February 1997.
-
-   [HTTP]         Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
-                  Masinter, L., Leach, P., and T. Berners-Lee,
-                  "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
-                  June 1999.
-
-   [IANA]         Narten, T. and H. Alvestrand, "Guidelines for Writing
-                  an IANA Considerations Section in RFCs", BCP 26, RFC
-                  2434, October 1998.
-
-   [IDNA]         Faltstrom, P., Hoffman, P., and A. Costello,
-                  "Internationalizing Domain Names in Applications
-                  (IDNA)", RFC 3490, March 2003.
-
-   [KEYWORDS]     Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [OCSP]         Myers, M., Ankney, R., Malpani, A., Galperin, S., and
-                  C. Adams, "X.509 Internet Public Key Infrastructure
-                  Online Certificate Status Protocol - OCSP", RFC 2560,
-                  June 1999.
-
-   [PKIOP]        Housley, R. and P. Hoffman, "Internet X.509 Public Key
-                  Infrastructure Operational Protocols: FTP and HTTP",
-                  RFC 2585, May 1999.
-
-   [PKIX]         Housley, R., Polk, W., Ford, W., and D. Solo,
-                  "Internet X.509 Public Key Infrastructure Certificate
-                  and Certificate Revocation List (CRL) Profile", RFC
-                  3280, April 2002.
-
-   [TLS]          Dierks, T. and C. Allen, "The TLS Protocol Version
-                  1.0", RFC 2246, January 1999.
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 27]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-   [TLSbis]       Dierks, T. and E. Rescorla, "The Transport Layer
-                  Security (TLS) Protocol Version 1.1", RFC 4346, April
-                  2006.
-
-   [URI]          Berners-Lee, T., Fielding, R., and L. Masinter,
-                  "Uniform Resource Identifier (URI): Generic Syntax",
-                  STD 66, RFC 3986, January 2005.
-
-   [UTF8]         Yergeau, F., "UTF-8, a transformation format of ISO
-                  10646", STD 63, RFC 3629, November 2003.
-
-   [X509-4th]     ITU-T Recommendation X.509 (2000) | ISO/IEC
-                  9594-8:2001, "Information Systems - Open Systems
-                  Interconnection - The Directory:  Public key and
-                  attribute certificate frameworks."
-
-   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
-                  ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
-                  1 to ISO/IEC 9594:8:2001.
-
-11.  Informative References
-
-   [AESSUITES]    Chown, P., "Advanced Encryption Standard (AES)
-                  Ciphersuites for Transport Layer Security (TLS)", RFC
-                  3268, June 2002.
-
-   [KERB]         Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-                  Suites to Transport Layer Security (TLS)", RFC 2712,
-                  October 1999.
-
-   [MAILINGLIST]  J. Mikkelsen, R. Eberhard, and J. Kistler, "General
-                  ClientHello extension mechanism and virtual hosting,"
-                  ietf-tls mailing list posting, August 14, 2000.
-
-   [RFC3546]      Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
-                  J., and T. Wright, "Transport Layer Security (TLS)
-                  Extensions", RFC 3546, June 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 28]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-Authors' Addresses
-
-   Simon Blake-Wilson
-   BCI
-
-   EMail: sblakewilson@bcisse.com
-
-
-   Magnus Nystrom
-   RSA Security
-
-   EMail: magnus@rsasecurity.com
-
-
-   David Hopwood
-   Independent Consultant
-
-   EMail: david.hopwood@blueyonder.co.uk
-
-
-   Jan Mikkelsen
-   Transactionware
-
-   EMail: janm@transactionware.com
-
-
-   Tim Wright
-   Vodafone
-
-   EMail: timothy.wright@vodafone.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 29]
-
-RFC 4366                     TLS Extensions                   April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Blake-Wilson, et al.        Standards Track                    [Page 30]
-
diff --git a/doc/protocol/rfc4507.txt b/doc/protocol/rfc4507.txt
deleted file mode 100644
index d66223a90c..0000000000
--- a/doc/protocol/rfc4507.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Salowey
-Request for Comments: 4507                                       H. Zhou
-Category: Standards Track                                  Cisco Systems
-                                                               P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                                 Siemens
-                                                                May 2006
-
-
-                 Transport Layer Security (TLS) Session
-                  Resumption without Server-Side State
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a mechanism that enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-   ticket and forwards it to the client.  The client can subsequently
-   resume a session using the obtained ticket.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 1]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Terminology .....................................................3
-   3. Protocol ........................................................3
-      3.1. Overview ...................................................4
-      3.2. SessionTicket TLS Extension ................................6
-      3.3. NewSessionTicket Handshake Message .........................7
-      3.4. Interaction with TLS Session ID ............................8
-   4. Recommended Ticket Construction .................................9
-   5. Security Considerations ........................................10
-      5.1. Invalidating Sessions .....................................11
-      5.2. Stolen Tickets ............................................11
-      5.3. Forged Tickets ............................................11
-      5.4. Denial of Service Attacks .................................11
-      5.5. Ticket Protection Key Management ..........................12
-      5.6. Ticket Lifetime ...........................................12
-      5.7. Alternate Ticket Formats and Distribution Schemes .........12
-      5.8. Identity Privacy, Anonymity, and Unlinkability ............12
-   6. Acknowledgements ...............................................13
-   7. IANA Considerations ............................................13
-   8. References .....................................................14
-      8.1. Normative References ......................................14
-      8.2. Informative References ....................................14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 2]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) session without requiring session-specific state at the TLS
-   server.  This mechanism may be used with any TLS ciphersuite.  This
-   document applies to both TLS 1.0 defined in [RFC2246] and TLS 1.1
-   defined in [RFC4346].  The mechanism makes use of TLS extensions
-   defined in [RFC4366] and defines a new TLS message type.
-
-   This mechanism is useful in the following situations:
-
-   1.  servers that handle a large number of transactions from different
-       users
-   2.  servers that desire to cache sessions for a long time
-   3.  ability to load balance requests across servers
-   4.  embedded servers with little memory
-
-2.  Terminology
-
-   Within this document, the term 'ticket' refers to a cryptographically
-   protected data structure that is created by the server and consumed
-   by the server to rebuild session-specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-   This specification describes a mechanism to distribute encrypted
-   session-state information in the form of a ticket.  The ticket is
-   created by a TLS server and sent to a TLS client.  The TLS client
-   presents the ticket to the TLS server to resume a session.
-   Implementations of this specification are expected to support both
-   mechanisms.  Other specifications can take advantage of the session
-   tickets, perhaps specifying alternative means for distribution or
-   selection.  For example, a separate specification may describe an
-   alternate way to distribute a ticket and use the TLS extension in
-   this document to resume the session.  This behavior is beyond the
-   scope of the document and would need to be described in a separate
-   specification.
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 3]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-3.1.  Overview
-
-   The client indicates that it supports this mechanism by including a
-   SessionTicket TLS extension in the ClientHello message.  The
-   extension will be empty if the client does not already possess a
-   ticket for the server.  The extension is described in Section 3.2.
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   TLS handshake message described in Section 3.3.  This message is sent
-   during the TLS handshake before the ChangeCipherSpec message, after
-   the server has successfully verified the client's Finished message.
-
-      Client                                               Server
-
-      ClientHello
-      (empty SessionTicket extension)------->
-                                                      ServerHello
-                                  (empty SessionTicket extension)
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                                 NewSessionTicket
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-   Figure 1: Message flow for full handshake issuing new session ticket
-
-   The client caches this ticket along with the master secret and other
-   parameters associated with the current session.  When the client
-   wishes to resume the session, it includes the ticket in the
-   SessionTicket extension within the ClientHello message.  The server
-   then decrypts the received ticket, verifies the ticket's validity,
-   retrieves the session state from the contents of the ticket, and uses
-   this state to resume the session.  The interaction with the TLS
-   Session ID is described in Section 3.4.  If the server successfully
-   verifies the client's ticket, then it may renew the ticket by
-   including a NewSessionTicket handshake message after the ServerHello.
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 4]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-      Client                                                Server
-
-      ClientHello
-      (SessionTicket extension)      -------->
-                                                       ServerHello
-                                   (empty SessionTicket extension)
-                                                  NewSessionTicket
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-        Figure 2: Message flow for abbreviated handshake using new
-                              session ticket
-
-   A recommended ticket format is given in Section 4.
-
-   If the server cannot or does not want to honor the ticket, then it
-   can initiate a full handshake with the client.
-
-   In the case that the server does not wish to issue a new ticket at
-   this time, it just completes the handshake without including a
-   SessionTicket extension or NewSessionTicket handshake message.  This
-   is shown below (this flow is identical to Figure 1 in RFC 2246,
-   except for the session ticket extension in the first message):
-
-      Client                                               Server
-
-      ClientHello
-      (SessionTicket extension)    -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-       Figure 3: Message flow for server completing full handshake
-                    without issuing new session ticket
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 5]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-   If the server rejects the ticket, it may still wish to issue a new
-   ticket after performing the full handshake as shown below (this flow
-   is identical to Figure 1, except the SessionTicket extension in the
-   Client Hello is not empty):
-
-      Client                                               Server
-
-      ClientHello
-      (SessionTicket extension) -------->
-                                                      ServerHello
-                                  (empty SessionTicket extension)
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                               <--------          ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                 -------->
-                                                 NewSessionTicket
-                                               [ChangeCipherSpec]
-                               <--------                 Finished
-      Application Data         <------->         Application Data
-
-   Figure 4: Message flow for server rejecting ticket, performing full
-                 handshake and issuing new session ticket
-
-3.2.  SessionTicket TLS Extension
-
-   The SessionTicket TLS extension is based on [RFC4366].  The format of
-   the ticket is an opaque structure used to carry session-specific
-   state information.  This extension may be sent in the ClientHello and
-   ServerHello.
-
-   If the client possesses a ticket that it wants to use to resume a
-   session, then it includes the ticket in the SessionTicket extension
-   in the ClientHello.  If the client does not have a ticket and is
-   prepared to receive one in the NewSessionTicket handshake message,
-   then it MUST include a zero-length ticket in the SessionTicket
-   extension.  If the client is not prepared to receive a ticket in the
-   NewSessionTicket handshake message then it MUST NOT include a
-   SessionTicket extension unless it is sending a non-empty ticket it
-   received through some other means from the server.
-
-   The server uses an zero length SessionTicket extension to indicate to
-   the client that it will send a new session ticket using the
-   NewSessionTicket handshake message described in Section 3.3.  The
-
-
-
-Salowey, et al.             Standards Track                     [Page 6]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-   server MUST send this extension in the ServerHello if it wishes to
-   issue a new ticket to the client using the NewSessionTicket handshake
-   message.  The server MUST NOT send this extension if it does not
-   receive one in the ClientHello.
-
-   If the server fails to verify the ticket, then it falls back to
-   performing a full handshake.  If the ticket is accepted by the server
-   but the handshake fails, the client SHOULD delete the ticket.
-
-   The SessionTicket extension has been assigned the number 35.  The
-   format of the SessionTicket extension is given at the end of this
-   section.
-
-      struct {
-          opaque ticket<0..2^16-1>;
-      } SessionTicket;
-
-3.3.  NewSessionTicket Handshake Message
-
-   This message is sent by the server during the TLS handshake before
-   the ChangeCipherSpec message.  This message MUST be sent if the
-   server included a SessionTicket extension in the ServerHello.  This
-   message MUST NOT be sent if the server did not include a
-   SessionTicket extension in the ServerHello.  In the case of a full
-   handshake, the server MUST verify the client's Finished message
-   before sending the ticket.  The client MUST NOT treat the ticket as
-   valid until it has verified the server's Finished message.  If the
-   server determines that it does not want to include a ticket after it
-   has included the SessionTicket extension in the ServerHello, then it
-   sends a zero-length ticket in the NewSessionTicket handshake message.
-
-   If the server successfully verifies the client's ticket, then it MAY
-   renew the ticket by including a NewSessionTicket handshake message
-   after the ServerHello in the abbreviated handshake.  The client
-   should start using the new ticket as soon as possible after it
-   verifies the server's Finished message for new connections.  Note
-   that since the updated ticket is issued before the handshake
-   completes, it is possible that the client may not put the new ticket
-   into use before it initiates new connections.  The server MUST NOT
-   assume that the client actually received the updated ticket until it
-   successfully verifies the client's Finished message.
-
-   The NewSessionTicket handshake message has been assigned the number 4
-   and its definition is given at the end of this section.  The
-   ticket_lifetime_hint field contains a hint from the server about how
-   long the ticket should be stored.  The value indicates the lifetime
-   in seconds as a 32-bit unsigned integer in network byte order.  A
-   value of zero is reserved to indicate that the lifetime of the ticket
-
-
-
-Salowey, et al.             Standards Track                     [Page 7]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-   is unspecified.  A client SHOULD delete the ticket and associated
-   state when the time expires.  It MAY delete the ticket earlier based
-   on local policy.  A server MAY treat a ticket as valid for a shorter
-   or longer period of time than what is stated in the
-   ticket_lifetime_hint.
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case session_ticket:      NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          uint32 ticket_lifetime_hint;
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-3.4.  Interaction with TLS Session ID
-
-   If a server is planning on issuing a SessionTicket to a client that
-   does not present one, it SHOULD include an empty Session ID in the
-   ServerHello.  If the server includes a non-empty session ID, then it
-   is indicating intent to use stateful session resume.  If the client
-   receives a SessionTicket from the server, then it discards any
-   Session ID that was sent in the ServerHello.
-
-   When presenting a ticket, the client MAY generate and include a
-   Session ID in the TLS ClientHello.  If the server accepts the ticket
-   and the Session ID is not empty, then it MUST respond with the same
-   Session ID present in the ClientHello.  This allows the client to
-   easily differentiate when the server is resuming a session from when
-   it is falling back to a full handshake.  Since the client generates a
-   Session ID, the server MUST NOT rely upon the Session ID having a
-   particular value when validating the ticket.  If a ticket is
-   presented by the client, the server MUST NOT attempt to use the
-
-
-
-Salowey, et al.             Standards Track                     [Page 8]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-   Session ID in the ClientHello for stateful session resume.
-   Alternatively, the client MAY include an empty Session ID in the
-   ClientHello.  In this case, the client ignores the Session ID sent in
-   the ServerHello and determines if the server is resuming a session by
-   the subsequent handshake messages.
-
-4.  Recommended Ticket Construction
-
-   This section describes a recommended format and protection for the
-   ticket.  Note that the ticket is opaque to the client, so the
-   structure is not subject to interoperability concerns, and
-   implementations may diverge from this format.  If implementations do
-   diverge from this format, they must take security concerns seriously.
-   Clients MUST NOT examine the ticket under the assumption that it
-   complies with this document.
-
-   The server uses two different keys: one 128-bit key for AES [AES] in
-   CBC mode [CBC] encryption and one 128-bit key for HMAC-SHA1 [RFC2104]
-   [SHA1].
-
-   The ticket is structured as follows:
-
-      struct {
-          opaque key_name[16];
-          opaque iv[16];
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[20];
-      } ticket;
-
-   Here, key_name serves to identify a particular set of keys used to
-   protect the ticket.  It enables the server to easily recognize
-   tickets it has issued.  The key_name should be randomly generated to
-   avoid collisions between servers.  One possibility is to generate new
-   random keys and key_name every time the server is started.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The MAC is calculated
-   using HMAC-SHA1 over key_name (16 octets)and IV (16 octets), followed
-   by the length of the encrypted_state field (2 octets) and its
-   contents (variable length).
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 9]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ClientIdentity client_identity;
-          uint32 timestamp;
-      } StatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ClientAuthenticationType;
-
-      struct {
-          ClientAuthenticationType client_authentication_type;
-          select (ClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>; /* from [RFC4279] */
-
-          }
-       } ClientIdentity;
-
-   The structure StatePlaintext stores the TLS session state including
-   the master_secret.  The timestamp within this structure allows the
-   TLS server to expire tickets.  To cover the authentication and key
-   exchange protocols provided by TLS, the ClientIdentity structure
-   contains the authentication type of the client used in the initial
-   exchange (see ClientAuthenticationType).  To offer the TLS server
-   with the same capabilities for authentication and authorization, a
-   certificate list is included in case of public-key-based
-   authentication.  The TLS server is therefore able to inspect a number
-   of different attributes within these certificates.  A specific
-   implementation might choose to store a subset of this information or
-   additional information.  Other authentication mechanisms, such as
-   Kerberos [RFC2712], would require different client identity data.
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be authenticated and encrypted to prevent
-   modification or eavesdropping by an attacker.  Several attacks
-   described below will be possible if this is not carefully done.
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 10]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of service as
-   described below.
-
-5.1.  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis in this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used, the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure that an attacker cannot invalidate a chosen
-   session.
-
-5.2.  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use the ticket to establish a session with the server;
-   however, since the ticket is encrypted and the attacker does not know
-   the secret key, a stolen ticket does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the ticket's contents.
-
-5.3.  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate as another user, or
-   to gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC-SHA1.
-
-5.4.  Denial of Service Attacks
-
-   The key_name field defined in the recommended ticket format helps the
-   server efficiently reject tickets that it did not issue.  However, an
-   adversary could store or generate a large number of tickets to send
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service, the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 11]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-5.5.  Ticket Protection Key Management
-
-   A full description of the management of the keys used to protect the
-   ticket is beyond the scope of this document.  A list of RECOMMENDED
-   practices is given below.
-
-   o  The keys should be generated securely following the randomness
-      recommendations in [RFC4086].
-   o  The keys and cryptographic protection algorithms should be at
-      least 128 bits in strength.
-   o  The keys should not be used for any other purpose than generating
-      and verifying tickets.
-   o  The keys should be changed regularly.
-   o  The keys should be changed if the ticket format or cryptographic
-      protection algorithms change.
-
-5.6.  Ticket Lifetime
-
-   The TLS server controls the lifetime of the ticket.  Servers
-   determine the acceptable lifetime based on the operational and
-   security requirements of the environments in which they are deployed.
-   The ticket lifetime may be longer than the 24-hour lifetime
-   recommended in [RFC2246].  TLS clients may be given a hint of the
-   lifetime of the ticket.  Since the lifetime of a ticket may be
-   unspecified, a client has its own local policy that determines when
-   it discards tickets.
-
-5.7.  Alternate Ticket Formats and Distribution Schemes
-
-   If the ticket format or distribution scheme defined in this document
-   is not used, then great care must be taken in analyzing the security
-   of the solution.  In particular, if confidential information, such as
-   a secret key, is transferred to the client, it MUST be done using
-   secure communication so as to prevent attackers from obtaining or
-   modifying the key.  Also, the ticket MUST have its integrity and
-   confidentiality protected with strong cryptographic techniques to
-   prevent a breach in the security of the system.
-
-5.8.  Identity Privacy, Anonymity, and Unlinkability
-
-   This document mandates that the content of the ticket is
-   confidentiality protected in order to avoid leakage of its content,
-   such as user-relevant information.  As such, it prevents disclosure
-   of potentially sensitive information carried within the ticket.
-
-   The initial handshake exchange, which was used to obtain the ticket,
-   might not provide identity confidentiality of the client based on the
-   properties of TLS.  Another relevant security threat is the ability
-
-
-
-Salowey, et al.             Standards Track                    [Page 12]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-   for an on-path adversary to observe multiple TLS handshakes where the
-   same ticket is used and therefore to conclude that they belong to the
-   same communication endpoints.  Application designers that use the
-   ticket mechanism described in this document should consider that
-   unlinkability [ANON] is not necessarily provided.
-
-   While a full discussion of these topics is beyond the scope of this
-   document, it should be noted that it is possible to issue a ticket
-   using a TLS renegotiation handshake that occurs after a secure tunnel
-   has been established by a previous handshake.  This may help address
-   some privacy and unlinkability issues in some environments.
-
-6.  Acknowledgements
-
-   The authors would like to thank the following people for their help
-   with preparing and reviewing this document: Eric Rescorla, Mohamad
-   Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
-   Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of
-   the TLS working group.
-
-   [CSSC] describes a solution that is very similar to the one described
-   in this document and gives a detailed analysis of the security
-   considerations involved.  [RFC2712] describes a mechanism for using
-   Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
-   of tickets to avoid server state.  [EAP-FAST] makes use of a similar
-   mechanism to avoid maintaining server state for the cryptographic
-   tunnel.  [SC97] also investigates the concept of stateless sessions.
-
-7.  IANA Considerations
-
-   IANA has assigned a TLS extension number of 35 to the SessionTicket
-   TLS extension from the TLS registry of ExtensionType values defined
-   in [RFC4366].
-
-   IANA has assigned a TLS HandshakeType number 4 to the
-   NewSessionTicket handshake type from the TLS registry of
-   HandshakeType values defined in [RFC4346].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 13]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-               RFC 2246, January 1999.
-
-   [RFC4346]   Dierks, T. and E. Rescorla, "The Transport Layer Security
-               (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4366]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
-               J., and T. Wright, "Transport Layer Security (TLS)
-               Extensions", RFC 4366, April 2006.
-
-8.2.  Informative References
-
-   [AES]       National Institute of Standards and Technology, "Advanced
-               Encryption Standard (AES)", Federal Information
-               Processing Standards (FIPS) Publication 197,
-               November 2001.
-
-   [ANON]      Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
-               Unobservability, Pseudonymity, and Identity Management -
-               A Consolidated Proposal for Terminology",
-               http://dud.inf.tu-dresden.de/literatur/
-               Anon_Terminology_v0.26-1.pdf, Draft 0.26, December 2005.
-
-   [CBC]       National Institute of Standards and Technology,
-               "Recommendation for Block Cipher Modes of Operation -
-               Methods and Techniques", NIST Special Publication 800-
-               38A, December 2001.
-
-   [CSSC]      Shacham, H., Boneh, D., and E. Rescorla, "Client-side
-               caching for TLS", Transactions on Information and System
-               Security (TISSEC) , Volume 7, Issue 4, November 2004.
-
-   [EAP-FAST]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
-               "EAP Flexible Authentication via Secure Tunneling (EAP-
-               FAST)", Work in Progress, April 2005.
-
-   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-               Hashing for Message Authentication", RFC 2104,
-               February 1997.
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 14]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-   [RFC2712]   Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-               Suites to Transport Layer Security (TLS)", RFC 2712,
-               October 1999.
-
-   [RFC4086]   Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-               Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4120]   Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-               Kerberos Network Authentication Service (V5)", RFC 4120,
-               July 2005.
-
-   [RFC4279]   Eronen, P. and H. Tschofenig, "Pre-Shared Key
-               Ciphersuites for Transport Layer Security (TLS)",
-               RFC 4279, December 2005.
-
-   [SC97]      Aura, T. and P. Nikander, "Stateless Connections",
-               Proceedings of the First International Conference on
-               Information and Communication Security (ICICS '97), 1997.
-
-   [SHA1]      National Institute of Standards and Technology, "Secure
-               Hash Standard (SHS)", Federal Information Processing
-               Standards (FIPS) Publication 180-2, August 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 15]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   EMail: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   EMail: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   EMail: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Siemens
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   EMail: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 16]
-
-RFC 4507            Stateless TLS Session Resumption            May 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 17]
-
diff --git a/doc/protocol/rfc4680.txt b/doc/protocol/rfc4680.txt
deleted file mode 100644
index 464e73cc9d..0000000000
--- a/doc/protocol/rfc4680.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Santesson
-Request for Comments: 4680                                     Microsoft
-Updates: 4346                                             September 2006
-Category: Standards Track
-
-
-              TLS Handshake Message for Supplemental Data
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This specification defines a TLS handshake message for exchange of
-   supplemental application data.  TLS hello message extensions are used
-   to determine which supplemental data types are supported by both the
-   TLS client and the TLS server.  Then, the supplemental data handshake
-   message is used to exchange the data.  Other documents will define
-   the syntax of these extensions and the syntax of the associated
-   supplemental data types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 1]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-1.  Introduction
-
-   Recent standards activities have proposed different mechanisms for
-   transmitting supplemental application data in the TLS handshake
-   message.  For example, recent proposals transfer data that is not
-   processed by the TLS protocol itself, but assist the TLS-protected
-   application in the authentication and authorization decisions.  One
-   proposal transfers user name hints for locating credentials, and
-   another proposal transfers attribute certificates and Security
-   Assertions Markup Language (SAML) assertions for authorization
-   checks.
-
-   In order to avoid definition of multiple handshake messages, one for
-   each new type of application-specific supplemental data, this
-   specification defines a new handshake message type that bundles
-   together all data objects that are to be delivered to the TLS-
-   protected application and sends them in a single handshake message.
-
-1.1.  Terminology
-
-   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 [N1].
-
-   The syntax for the supplemental_data handshake message is defined
-   using the TLS Presentation Language, which is specified in Section 4
-   of [N2].
-
-2.  Supplemental Data Handshake Message
-
-   The new supplemental_data handshake message type is defined to
-   accommodate communication of supplemental data objects as agreed
-   during the exchange of extensions in the client and server hello
-   messages.  See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3]
-   for other handshake message types.
-
-   Information provided in a supplemental data object MUST be intended
-   to be used exclusively by applications and protocols above the TLS
-   protocol layer.  Any such data MUST NOT need to be processed by the
-   TLS protocol.
-
-
-
-
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 2]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-      enum {
-             supplemental_data(23), (255)
-         } HandshakeType;
-
-      struct {
-             HandshakeType msg_type;    /* handshake type */
-             uint24 length;             /* octets in message */
-             select (HandshakeType) {
-                    case supplemental_data:   SupplementalData;
-               } body;
-          } Handshake;
-
-      struct {
-            SupplementalDataEntry supp_data<1..2^24-1>;
-         } SupplementalData;
-
-      struct {
-            SupplementalDataType supp_data_type;
-            uint16 supp_data_length;
-            select(SupplementalDataType) { }
-         } SupplementalDataEntry;
-
-      enum {
-            (65535)
-        } SupplementalDataType;
-
-   supp_data_length
-      This field is the length (in bytes) of the data selected by
-      SupplementalDataType.
-
-   The client MUST NOT send more than one SupplementalData handshake
-   message, and the server MUST NOT send more than one SupplementalData
-   handshake message.  Receiving more than one SupplementalData
-   handshake message results in a fatal error, and the receiver MUST
-   close the connection with a fatal unexpected_message alert.
-
-   If present, the SupplementalData handshake message MUST contain a
-   non-empty SupplementalDataEntry structure carrying data associated
-   with at least one defined SupplementalDataType.  An explicit
-   agreement that governs presence of any supplemental data MUST be
-   concluded between client and server for each SupplementalDataType
-   using the TLS extensions [N4] in the client and server hello
-   messages.  Receiving an unexpected SupplementalData handshake message
-   results in a fatal error, and the receiver MUST close the connection
-   with a fatal unexpected_message alert.
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 3]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-   Other documents will define specific SupplementalDataTypes and their
-   associated data syntax and processing.  These same specifications
-   must also specify the client and server hello message extensions that
-   are used to negotiate the support for the specified supplemental data
-   type.  This document simply specifies the TLS Handshake Protocol
-   message that will carry the supplemental data objects.
-
-   Different situations require the transfer of supplemental data from
-   the client to the server, require the transfer of supplemental data
-   from the server to the client, or both ways.  All three situations
-   are fully supported.
-
-3.  Message Flow
-
-   The SupplementalData handshake message, if exchanged, MUST be sent as
-   the first handshake message as illustrated in Figure 1 below.
-
-     Client                                               Server
-
-     ClientHello (with extensions) -------->
-
-                                    ServerHello(with extensions)
-                                               SupplementalData*
-                                                    Certificate*
-                                              ServerKeyExchange*
-                                             CertificateRequest*
-                                  <--------      ServerHelloDone
-
-     SupplementalData*
-     Certificate*
-     ClientKeyExchange
-     CertificateVerify*
-     [ChangeCipherSpec]
-     Finished                     -------->
-                                              [ChangeCipherSpec]
-                                  <--------             Finished
-     Application Data             <------->     Application Data
-
-       *  Indicates optional or situation-dependent messages.
-
-               Figure 1.  Message Flow with SupplementalData
-
-
-
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 4]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-4.  Security Considerations
-
-   Each SupplementalDataType included in the handshake message defined
-   in this specification introduces its own unique set of security
-   properties and related considerations.  Security considerations must
-   therefore be defined in each document that defines a supplemental
-   data type.
-
-   In some cases, the SupplementalData information may be sensitive.
-   The double handshake technique can be used to provide protection for
-   the SupplementalData information.  Figure 2 illustrates the double
-   handshake, where the initial handshake does not include any
-   extensions, but it does result in protected communications.  Then, a
-   second handshake that includes the SupplementalData information is
-   performed using the protected communications.  In Figure 2, the
-   number on the right side indicates the amount of protection for the
-   TLS message on that line.  A zero (0) indicates that there is no
-   communication protection; a one (1) indicates that protection is
-   provided by the first TLS session; and a two (2) indicates that
-   protection is provided by both TLS sessions.
-
-   The placement of the SupplementalData message in the TLS Handshake
-   results in the server providing its SupplementalData information
-   before the client is authenticated.  In many situations, servers will
-   not want to provide authorization information until the client is
-   authenticated.  The double handshake illustrated in Figure 2 provides
-   a technique to ensure that the parties are mutually authenticated
-   before either party provides SupplementalData information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 5]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-   Client                                                   Server
-
-   ClientHello (no extensions) -------->                            |0
-                                       ServerHello (no extensions)  |0
-                                                      Certificate*  |0
-                                                ServerKeyExchange*  |0
-                                               CertificateRequest*  |0
-                               <--------           ServerHelloDone  |0
-   Certificate*                                                     |0
-   ClientKeyExchange                                                |0
-   CertificateVerify*                                               |0
-   [ChangeCipherSpec]                                               |0
-   Finished                    -------->                            |1
-                                                [ChangeCipherSpec]  |0
-                               <--------                  Finished  |1
-   ClientHello (w/ extensions) -------->                            |1
-                                       ServerHello (w/ extensions)  |1
-                                                 SupplementalData*  |1
-                                                      Certificate*  |1
-                                                ServerKeyExchange*  |1
-                                               CertificateRequest*  |1
-                               <--------           ServerHelloDone  |1
-   SupplementalData*                                                |1
-   Certificate*                                                     |1
-   ClientKeyExchange                                                |1
-   CertificateVerify*                                               |1
-   [ChangeCipherSpec]                                               |1
-   Finished                    -------->                            |2
-                                                [ChangeCipherSpec]  |1
-                               <--------                  Finished  |2
-   Application Data            <------->          Application Data  |2
-
-   *  Indicates optional or situation-dependent messages.
-
-         Figure 2.  Double Handshake to Protect Supplemental Data
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 6]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-5.  IANA Considerations
-
-   IANA has taken the following actions:
-
-   1) Created an entry, supplemental_data(23), in the existing registry
-      for HandshakeType (defined in RFC 2246 [N2]).
-
-   2) Established a registry for TLS Supplemental Data Formats
-      (SupplementalDataType).  Values in the inclusive range 0-16385
-      (decimal) are assigned via RFC 2434 [N5] Standards Action.  Values
-      from the inclusive range 16386-65279 (decimal) are assigned via
-      RFC 2434 IETF Consensus.  Values from the inclusive range
-      65280-65535 (decimal) are reserved for RFC 2434 Private Use.
-
-6.  Normative References
-
-   [N1]   Bradner, S., "Key words for use in RFCs to Indicate
-          Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-          2246, January 1999.
-
-   [N3]   Dierks, T. and E. Rescorla, "The Transport Layer Security
-          (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [N4]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-          T. Wright, "Transport Layer Security (TLS) Extensions", RFC
-          4366, April 2006.
-
-   [N5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-          Considerations Section in RFCs", BCP 26, RFC 2434, October
-          1998.
-
-7.  Acknowledgements
-
-   The fundamental architectural idea for the supplemental data
-   handshake message was provided by Russ Housley and Eric Rescorla.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 7]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-Author's Address
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 8]
-
-RFC 4680      TLS Handshake Message for Supplemental Data September 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Santesson                   Standards Track                     [Page 9]
-
diff --git a/doc/protocol/rfc4681.txt b/doc/protocol/rfc4681.txt
deleted file mode 100644
index cc09cebfa1..0000000000
--- a/doc/protocol/rfc4681.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Santesson
-Request for Comments: 4681                                  A. Medvinsky
-Updates: 4346                                                    J. Ball
-Category: Standards Track                                      Microsoft
-                                                            October 2006
-
-
-                       TLS User Mapping Extension
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document specifies a TLS extension that enables clients to send
-   generic user mapping hints in a supplemental data handshake message
-   defined in RFC 4680.  One such mapping hint is defined in an
-   informative section, the UpnDomainHint, which may be used by a server
-   to locate a user in a directory database.  Other mapping hints may be
-   defined in other documents in the future.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Terminology ................................................2
-      1.2. Design Considerations ......................................2
-   2. User Mapping Extension ..........................................3
-   3. User Mapping Handshake Exchange .................................3
-   4. Message Flow ....................................................5
-   5. Security Considerations .........................................6
-   6. UPN Domain Hint (Informative) ...................................7
-   7. IANA Considerations .............................................8
-   8. Normative References ............................................9
-   9. Acknowledgements ................................................9
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 1]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-1.  Introduction
-
-   This document has a normative part and an informative part.  Sections
-   2-5 are normative.  Section 6 is informative.
-
-   This specification defines a TLS extension and a payload for the
-   SupplementalData handshake message, defined in RFC 4680 [N6], to
-   accommodate mapping of users to their user accounts when using TLS
-   client authentication as the authentication method.
-
-   The new TLS extension (user_mapping) is sent in the client hello
-   message.  Per convention defined in RFC 4366 [N4], the server places
-   the same extension (user_mapping) in the server hello message, to
-   inform the client that the server understands this extension.  If the
-   server does not understand the extension, it will respond with a
-   server hello omitting this extension, and the client will proceed as
-   normal, ignoring the extension, and not include the
-   UserMappingDataList data in the TLS handshake.
-
-   If the new extension is understood, the client will inject
-   UserMappingDataList data in the SupplementalData handshake message
-   prior to the Client's Certificate message.  The server will then
-   parse this message, extracting the client's domain, and store it in
-   the context for use when mapping the certificate to the user's
-   directory account.
-
-   No other modifications to the protocol are required.  The messages
-   are detailed in the following sections.
-
-1.1.  Terminology
-
-   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 [N1].
-
-   The syntax for the TLS User Mapping extension is defined using the
-   TLS Presentation Language, which is specified in Section 4 of [N2].
-
-1.2.  Design Considerations
-
-   The reason the mapping data itself is not placed in the extension
-   portion of the client hello is to prevent broadcasting this
-   information to servers that don't understand the extension.
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 2]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-2.  User Mapping Extension
-
-   A new extension type (user_mapping(6)) is added to the Extension used
-   in both the client hello and server hello messages.  The extension
-   type is specified as follows.
-
-      enum {
-           user_mapping(6), (65535)
-      } ExtensionType;
-
-   The "extension_data" field of this extension SHALL contain
-   "UserMappingTypeList" with a list of supported hint types where:
-
-      struct {
-            UserMappingType user_mapping_types<1..2^8-1>;
-      } UserMappingTypeList;
-
-   Enumeration of hint types (user_mapping_types) defined in this
-   document is provided in Section 3.
-
-   The list of user_mapping_types included in a client hello SHALL
-   signal the hint types supported by the client.  The list of
-   user_mapping_types included in the server hello SHALL signal the hint
-   types preferred by the server.
-
-   If none of the hint types listed by the client is supported by the
-   server, the server SHALL omit the user_mapping extension in the
-   server hello.
-
-   When the user_mapping extension is included in the server hello, the
-   list of hint types in "UserMappingTypeList" SHALL be either equal to,
-   or a subset of, the list provided by the client.
-
-3.  User Mapping Handshake Exchange
-
-   The underlying structure of the SupplementalData handshake message,
-   used to carry information defined in this section, is defined in RFC
-   4680 [N6].
-
-   A new SupplementalDataType [N6] is defined to accommodate
-   communication of generic user mapping data.  See RFC 2246 (TLS 1.0)
-   [N2] and RFC 4346 (TLS 1.1) [N3] for other handshake types.
-
-   The information in this data type carries one or more unauthenticated
-   hints, UserMappingDataList, inserted by the client side.  Upon
-   receipt and successful completion of the TLS handshake, the server
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 3]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-   MAY use this hint to locate the user's account from which user
-   information and credentials MAY be retrieved to support
-   authentication based on the client certificate.
-
-      struct {
-            SupplementalDataType supp_data_type;
-            uint16 supp_data_length;
-            select(SupplementalDataType) {
-               case user_mapping_data: UserMappingDataList;
-               }
-      } SupplementalDataEntry;
-
-      enum {
-            user_mapping_data(0), (65535)
-      } SupplementalDataType;
-
-   The user_mapping_data(0) enumeration results in a new supplemental
-   data type UserMappingDataList with the following structure:
-
-      enum {
-            (255)
-      } UserMappingType;
-
-      struct {
-             UserMappingType user_mapping_version;
-             uint16 user_mapping_length;
-             select(UserMappingType) { }
-      } UserMappingData;
-
-      struct{
-         UserMappingData user_mapping_data_list<1..2^16-1>;
-      }UserMappingDataList;
-
-   user_mapping_length
-      This field is the length (in bytes) of the data selected by
-      UserMappingType.
-
-   The UserMappingData structure contains a single mapping of type
-   UserMappingType.  This structure can be leveraged to define new types
-   of user mapping hints in the future.  The UserMappingDataList MAY
-   carry multiple hints; it is defined as a vector of UserMappingData
-   structures.
-
-   No preference is given to the order in which hints are specified in
-   this vector.  If the client sends more than one hint, then the Server
-   SHOULD use the applicable mapping supported by the server.
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 4]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-   Implementations MAY support the UPN domain hint as specified in
-   Section 6 of this document.  Implementations MAY also support other
-   user mapping types as they are defined.  Definitions of standards-
-   track user mapping types must include a discussion of
-   internationalization considerations.
-
-4.  Message Flow
-
-   In order to negotiate sending user mapping data to a server in
-   accordance with this specification, clients MUST include an extension
-   of type "user_mapping" in the (extended) client hello, which SHALL
-   contain a list of supported hint types.
-
-   Servers that receive an extended client hello containing a
-   "user_mapping" extension MAY indicate that they are willing to accept
-   user mapping data by including an extension of type "user_mapping" in
-   the (extended) server hello, which SHALL contain a list of preferred
-   hint types.
-
-   After negotiation of the use of user mapping has been successfully
-   completed (by exchanging hello messages including "user_mapping"
-   extensions), clients MAY send a "SupplementalData" message containing
-   the "UserMappingDataList" before the "Certificate" message.  The
-   message flow is illustrated in Figure 1 below.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 5]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-      Client                                               Server
-
-      ClientHello
-       /* with user_mapping ext */ -------->
-                                                      ServerHello
-                                      /* with user-mapping ext */
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-
-      SupplementalData
-       /* with UserMappingDataList */
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-   * Indicates optional or situation-dependent messages that are not
-     always sent according to RFC 2246 [N2] and RFC 4346 [N3].
-
-              Figure 1.  Message Flow with User Mapping Data
-
-   The server MUST expect and gracefully handle the case where the
-   client chooses not to send any supplementalData handshake message
-   even after successful negotiation of extensions.  The client MAY at
-   its own discretion decide that the user mapping hint it initially
-   intended to send no longer is relevant for this session.  One such
-   reason could be that the server certificate fails to meet certain
-   requirements.
-
-5.  Security Considerations
-
-   The user mapping hint sent in the UserMappingDataList is
-   unauthenticated data that MUST NOT be treated as a trusted
-   identifier.  Authentication of the user represented by that user
-   mapping hint MUST rely solely on validation of the client
-   certificate.  One way to do this is to use the user mapping hint to
-   locate and extract a certificate of the claimed user from the trusted
-   directory and subsequently match this certificate against the
-   validated client certificate from the TLS handshake.
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 6]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-   As the client is the initiator of this TLS extension, it needs to
-   determine when it is appropriate to send the User Mapping
-   Information.  It may not be prudent to broadcast a user mapping hint
-   to just any server at any time.
-
-   To avoid superfluously sending user mapping hints, clients SHOULD
-   only send this information if it recognizes the server as a
-   legitimate recipient.  Recognition of the server can be done in many
-   ways.  One way to do this could be to recognize the name and address
-   of the server.
-
-   In some cases, the user mapping hint may itself be regarded as
-   sensitive.  In such cases, the double handshake technique described
-   in [N6] can be used to provide protection for the user mapping hint
-   information.
-
-6.  UPN Domain Hint (Informative)
-
-   This specification provides an informative description of one user
-   mapping hint type for Domain Name hints and User Principal Name
-   hints.  Other hint types may be defined in other documents in the
-   future.
-
-   The User Principal Name (UPN) in this hint type represents a name
-   that specifies a user's entry in a directory in the form
-   userName@domainName.  Traditionally, Microsoft has relied on the
-   presence of such a name form to be present in the client certificate
-   when logging on to a domain account.  However, this has several
-   drawbacks since it prevents the use of certificates with an absent
-   UPN and also requires re-issuance of certificates or issuance of
-   multiple certificates to reflect account changes or creation of new
-   accounts.  The TLS extension, in combination with the defined hint
-   type, provides 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.
-
-   The domain_name field MAY be used when only domain information is
-   needed, e.g., where a user have accounts in multiple domains using
-   the same username name, where that user name is known from another
-   source (e.g., from the client certificate).  When the user name is
-   also needed, the user_principal_name field MAY be used to indicate
-   both username and domain name.  If both fields are present, then the
-   server can make use of whichever one it chooses.
-
-      enum {
-             upn_domain_hint(64), (255)
-      } UserMappingType;
-
-
-
-Santesson, et al.           Standards Track                     [Page 7]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-      struct {
-             opaque user_principal_name<0..2^16-1>;
-             opaque domain_name<0..2^16-1>;
-      } UpnDomainHint;
-
-      struct {
-             UserMappingType user_mapping_version;
-             uint16 user_mapping_length;
-             select(UserMappingType) {
-                   case upn_domain_hint: UpnDomainHint;
-             }
-      } UserMappingData;
-
-   The user_principal_name field, when specified, SHALL be of the form
-   "user@domain", where "user" is a UTF-8 encoded Unicode string that
-   does not contain the "@" character, and "domain" is a domain name
-   meeting the requirements in the following paragraph.
-
-   The domain_name field, when specified, SHALL contain a domain name
-   [N5] in the usual text form; in other words, a sequence of one or
-   more domain labels separated by ".", each domain label starting and
-   ending with an alphanumeric character and possibly also containing
-   "-" characters.  This field is an "IDN-unaware domain name slot" as
-   defined in RFC 3490 [N7], and therefore, domain names containing
-   non-ASCII characters have to be processed as described in RFC 3490
-   before being stored in this field.
-
-   The UpnDomainHint MUST at least contain a non-empty
-   user_principal_name or a non-empty domain_name.  The UpnDomainHint
-   MAY contain both user_principal_name and domain_name.
-
-7.  IANA Considerations
-
-   IANA has taken the following actions:
-
-   1) Created an entry, user_mapping(6), in the existing registry for
-      ExtensionType (defined in RFC 4366 [N4]).
-
-   2) Created an entry, user_mapping_data(0), in the new registry for
-      SupplementalDataType (defined in RFC 4680).
-
-   3) Established a registry for TLS UserMappingType values.  The first
-      entry in the registry is upn_domain_hint(64).  TLS UserMappingType
-      values in the inclusive range 0-63 (decimal) are assigned via RFC
-      2434 [N8] Standards Action.  Values from the inclusive range
-      64-223 (decimal) are assigned via RFC 2434 Specification Required.
-      Values from the inclusive range 224-255 (decimal) are reserved for
-      RFC 2434 Private Use.
-
-
-
-Santesson, et al.           Standards Track                     [Page 8]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-8.  Normative References
-
-   [N1]   Bradner, S., "Key words for use in RFCs to Indicate
-          Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [N2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
-          2246, January 1999.
-
-   [N3]   Dierks, T. and E. Rescorla, "The Transport Layer Security
-          (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [N4]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-          T. Wright, "Transport Layer Security (TLS) Extensions", RFC
-          4366, April 2006.
-
-   [N5]   Mockapetris, P., "Domain names - concepts and facilities", STD
-          13, RFC 1034, November 1987.
-
-   [N6]   Santesson, S., "TLS Handshake Message for Supplemental Data",
-          RFC 4680, October 2006.
-
-   [N7]   Faltstrom, P., Hoffman, P., and A. Costello,
-          "Internationalizing Domain Names in Applications (IDNA)", RFC
-          3490, March 2003.
-
-   [N8]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-          Considerations Section in RFCs", BCP 26, RFC 2434, October
-          1998.
-
-9.  Acknowledgements
-
-   The authors extend a special thanks to Russ Housley, Eric Resocorla,
-   and Paul Leach for their substantial contributions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                     [Page 9]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-Authors' Addresses
-
-   Stefan Santesson
-   Microsoft
-   Finlandsgatan 30
-   164 93 KISTA
-   Sweden
-
-   EMail: stefans@microsoft.com
-
-
-   Ari Medvinsky
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   EMail: arimed@microsoft.com
-
-
-   Joshua Ball
-   Microsoft
-   One Microsoft Way
-   Redmond, WA 98052-6399
-   USA
-
-   EMail: joshball@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 10]
-
-RFC 4681               TLS User Mapping Extension           October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Santesson, et al.           Standards Track                    [Page 11]
-
diff --git a/doc/protocol/rfc4785.txt b/doc/protocol/rfc4785.txt
deleted file mode 100644
index e3aefd89ec..0000000000
--- a/doc/protocol/rfc4785.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      U. Blumenthal
-Request for Comments: 4785                                       P. Goel
-Category: Standards Track                              Intel Corporation
-                                                            January 2007
-
-
-      Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
-                    Transport Layer Security (TLS)
-
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2007).
-
-Abstract
-
-   This document specifies authentication-only ciphersuites (with no
-   encryption) for the Pre-Shared Key (PSK) based Transport Layer
-   Security (TLS) protocol.  These ciphersuites are useful when
-   authentication and integrity protection is desired, but
-   confidentiality is not needed or not permitted.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Applicability Statement ....................................2
-   2. Conventions Used in This Document ...............................2
-   3. Cipher Usage ....................................................3
-   4. Security Considerations .........................................3
-   5. IANA Considerations .............................................3
-   6. Acknowledgments .................................................3
-   7. References ......................................................4
-      7.1. Normative References .......................................4
-      7.2. Informative References .....................................4
-
-
-
-
-
-
-
-
-
-Blumenthal & Goel           Standards Track                     [Page 1]
-
-RFC 4785        PSK NULL Encryption Ciphersuites for TLS    January 2007
-
-
-1.  Introduction
-
-   The RFC for Pre-Shared Key (PSK) based Transport Layer Security (TLS)
-   [TLS-PSK] specifies ciphersuites for supporting TLS using pre-shared
-   symmetric keys.  However, all the ciphersuites defined in [TLS-PSK]
-   require encryption.  However there are cases when only authentication
-   and integrity protection is required, and confidentiality is not
-   needed.  There are also cases when confidentiality is not permitted -
-   e.g., for implementations that must meet import restrictions in some
-   countries.  Even though no encryption is used, these ciphersuites
-   support authentication of the client and server to each other, and
-   message integrity.  This document augments [TLS-PSK] by adding three
-   more ciphersuites (PSK, DHE_PSK, RSA_PSK) with authentication and
-   integrity only - no encryption.  The reader is expected to become
-   familiar with [TLS-PSK] standards prior to studying this document.
-
-1.1.  Applicability Statement
-
-   The ciphersuites defined in this document are intended for a rather
-   limited set of applications, usually involving only a very small
-   number of clients and servers.  Even in such environments, other
-   alternatives may be more appropriate.
-
-   If the main goal is to avoid Public-key Infrastructures (PKIs),
-   another possibility worth considering is using self-signed
-   certificates with public key fingerprints.  Instead of manually
-   configuring a shared secret in, for instance, some configuration
-   file, a fingerprint (hash) of the other party's public key (or
-   certificate) could be placed there instead.
-
-   It is also possible to use the Secure Remote Password (SRP)
-   ciphersuites for shared secret authentication [SRP].  SRP was
-   designed to be used with passwords, and it incorporates protection
-   against dictionary attacks.  However, it is computationally more
-   expensive than the PSK ciphersuites in [TLS-PSK].
-
-2.  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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-Blumenthal & Goel           Standards Track                     [Page 2]
-
-RFC 4785        PSK NULL Encryption Ciphersuites for TLS    January 2007
-
-
-3.  Cipher Usage
-
-   The three new ciphersuites proposed here match the three cipher
-   suites defined in [TLS-PSK], except that we define suites with null
-   encryption.
-
-   The ciphersuites defined here use the following options for key
-   exchange and hash part of the protocol:
-
-   CipherSuite                     Key Exchange   Cipher      Hash
-
-   TLS_PSK_WITH_NULL_SHA           PSK            NULL        SHA
-   TLS_DHE_PSK_WITH_NULL_SHA       DHE_PSK        NULL        SHA
-   TLS_RSA_PSK_WITH_NULL_SHA       RSA_PSK        NULL        SHA
-
-   For the meaning of the terms PSK, please refer to section 1 in [TLS-
-   PSK].  For the meaning of the terms DHE, RSA, and SHA, please refer
-   to appendixes A.5 and B in [TLS].
-
-4.  Security Considerations
-
-   As with all schemes involving shared keys, special care should be
-   taken to protect the shared values and to limit their exposure over
-   time.  As this document augments [TLS-PSK], everything stated in its
-   Security Consideration section applies here.  In addition, as cipher
-   suites defined here do not support confidentiality, care should be
-   taken not to send sensitive information (such as passwords) over
-   connections protected with one of the ciphersuites defined in this
-   document.
-
-5.  IANA Considerations
-
-   This document defines three new ciphersuites whose values are in the
-   TLS Cipher Suite registry defined in [TLS].
-
-   CipherSuite   TLS_PSK_WITH_NULL_SHA      = { 0x00, 0x2C };
-   CipherSuite   TLS_DHE_PSK_WITH_NULL_SHA  = { 0x00, 0x2D };
-   CipherSuite   TLS_RSA_PSK_WITH_NULL_SHA  = { 0x00, 0x2E };
-
-6.  Acknowledgments
-
-   The ciphersuites defined in this document are an augmentation to and
-   based on [TLS-PSK].
-
-
-
-
-
-
-
-
-Blumenthal & Goel           Standards Track                     [Page 3]
-
-RFC 4785        PSK NULL Encryption Ciphersuites for TLS    January 2007
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]     Dierks, T. and E. Rescorla, "The Transport Layer Security
-             (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-             for Transport Layer Security (TLS)", RFC 4279, December
-             2005.
-
-7.2.  Informative References
-
-   [SRP]     Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
-             "Using SRP for TLS Authentication", Work in Progress,
-             December 2006.
-
-Authors' Addresses
-
-   Uri Blumenthal
-   Intel Corporation
-   1515 State Route 10,
-   PY2-1 10-4
-   Parsippany, NJ 07054
-   USA
-
-   EMail: urimobile@optonline.net
-
-
-   Purushottam Goel
-   Intel Corporation
-   2111 N.E. 25 Ave.
-   JF3-414
-   Hillsboro, OR 97124
-   USA
-
-   EMail: Purushottam.Goel@intel.com
-
-
-
-
-
-
-
-
-
-
-
-Blumenthal & Goel           Standards Track                     [Page 4]
-
-RFC 4785        PSK NULL Encryption Ciphersuites for TLS    January 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Blumenthal & Goel           Standards Track                     [Page 5]
-
diff --git a/doc/protocol/rfc5054.txt b/doc/protocol/rfc5054.txt
deleted file mode 100644
index 86e391cf77..0000000000
--- a/doc/protocol/rfc5054.txt
+++ /dev/null
@@ -1,1347 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Taylor
-Request for Comments: 5054                                   Independent
-Category: Informational                                            T. Wu
-                                                                   Cisco
-                                                    N. Mavrogiannopoulos
-                                                               T. Perrin
-                                                             Independent
-                                                           November 2007
-
-
- Using the Secure Remote Password (SRP) Protocol for TLS Authentication
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Abstract
-
-   This memo presents a technique for using the Secure Remote Password
-   protocol as an authentication method for the Transport Layer Security
-   protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                      [Page 1]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  SRP Authentication in TLS  . . . . . . . . . . . . . . . . . .  3
-     2.1.  Notation and Terminology . . . . . . . . . . . . . . . . .  3
-     2.2.  Handshake Protocol Overview  . . . . . . . . . . . . . . .  4
-     2.3.  Text Preparation . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  SRP Verifier Creation  . . . . . . . . . . . . . . . . . .  5
-     2.5.  Changes to the Handshake Message Contents  . . . . . . . .  5
-       2.5.1.  Client Hello . . . . . . . . . . . . . . . . . . . . .  6
-       2.5.2.  Server Certificate . . . . . . . . . . . . . . . . . .  7
-       2.5.3.  Server Key Exchange  . . . . . . . . . . . . . . . . .  7
-       2.5.4.  Client Key Exchange  . . . . . . . . . . . . . . . . .  8
-     2.6.  Calculating the Premaster Secret . . . . . . . . . . . . .  8
-     2.7.  Ciphersuite Definitions  . . . . . . . . . . . . . . . . .  9
-     2.8.  New Message Structures . . . . . . . . . . . . . . . . . .  9
-       2.8.1.  Client Hello . . . . . . . . . . . . . . . . . . . . . 10
-       2.8.2.  Server Key Exchange  . . . . . . . . . . . . . . . . . 10
-       2.8.3.  Client Key Exchange  . . . . . . . . . . . . . . . . . 11
-     2.9.  Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
-   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-     3.1.  General Considerations for Implementors  . . . . . . . . . 12
-     3.2.  Accepting Group Parameters . . . . . . . . . . . . . . . . 12
-     3.3.  Protocol Characteristics . . . . . . . . . . . . . . . . . 12
-     3.4.  Hash Function Considerations . . . . . . . . . . . . . . . 13
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
-     5.2.  Informative References . . . . . . . . . . . . . . . . . . 15
-   Appendix A.  SRP Group Parameters  . . . . . . . . . . . . . . . . 16
-   Appendix B.  SRP Test Vectors  . . . . . . . . . . . . . . . . . . 21
-   Appendix C.  Acknowledgements  . . . . . . . . . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                      [Page 2]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-1.  Introduction
-
-   At the time of writing TLS [TLS] uses public key certificates, pre-
-   shared keys, or Kerberos for authentication.
-
-   These authentication methods do not seem well suited to certain
-   applications now being adapted to use TLS ([IMAP], for example).
-   Given that many protocols are designed to use the user name and
-   password method of authentication, being able to safely use user
-   names and passwords provides an easier route to additional security.
-
-   SRP ([SRP], [SRP-6]) is an authentication method that allows the use
-   of user names and passwords over unencrypted channels without
-   revealing the password to an eavesdropper.  SRP also supplies a
-   shared secret at the end of the authentication sequence that can be
-   used to generate encryption keys.
-
-   This document describes the use of the SRP authentication method for
-   TLS.
-
-   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 [REQ].
-
-2.  SRP Authentication in TLS
-
-2.1.  Notation and Terminology
-
-   The version of SRP used here is sometimes referred to as "SRP-6"
-   [SRP-6].  This version is a slight improvement over "SRP-3", which
-   was described in [SRP] and [SRP-RFC].  For convenience, this document
-   and [SRP-RFC] include the details necessary to implement SRP-6;
-   [SRP-6] is cited for informative purposes only.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                      [Page 3]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   This document uses the variable names defined in [SRP-6]:
-
-      N, g: group parameters (prime and generator)
-
-      s: salt
-
-      B, b: server's public and private values
-
-      A, a: client's public and private values
-
-      I: user name (aka "identity")
-
-      P: password
-
-      v: verifier
-
-      k: SRP-6 multiplier
-
-   The | symbol indicates string concatenation, the ^ operator is the
-   exponentiation operation, and the % operator is the integer remainder
-   operation.
-
-   Conversion between integers and byte-strings assumes the most
-   significant bytes are stored first, as per [TLS] and [SRP-RFC].  In
-   the following text, if a conversion from integer to byte-string is
-   implicit, the most significant byte in the resultant byte-string MUST
-   be non-zero.  If a conversion is explicitly specified with the
-   operator PAD(), the integer will first be implicitly converted, then
-   the resultant byte-string will be left-padded with zeros (if
-   necessary) until its length equals the implicitly-converted length of
-   N.
-
-2.2.  Handshake Protocol Overview
-
-   The advent of [SRP-6] allows the SRP protocol to be implemented using
-   the standard sequence of handshake messages defined in [TLS].
-
-   The parameters to various messages are given in the following
-   diagram.
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                      [Page 4]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   Client                                            Server
-
-   Client Hello (I)        -------->
-                                               Server Hello
-                                               Certificate*
-                                        Server Key Exchange (N, g, s, B)
-                           <--------      Server Hello Done
-   Client Key Exchange (A) -------->
-   [Change cipher spec]
-   Finished                -------->
-                                       [Change cipher spec]
-                           <--------               Finished
-
-   Application Data        <------->       Application Data
-
-   * Indicates an optional message that is not always sent.
-
-                                 Figure 1
-
-2.3.  Text Preparation
-
-   The user name and password strings SHALL be UTF-8 encoded Unicode,
-   prepared using the [SASLPREP] profile of [STRINGPREP].
-
-2.4.  SRP Verifier Creation
-
-   The verifier is calculated as described in Section 3 of [SRP-RFC].
-   We give the algorithm here for convenience.
-
-   The verifier (v) is computed based on the salt (s), user name (I),
-   password (P), and group parameters (N, g).  The computation uses the
-   [SHA1] hash algorithm:
-
-        x = SHA1(s | SHA1(I | ":" | P))
-        v = g^x % N
-
-2.5.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when SRP is being used for authentication.  The definitions
-   of the new message contents and the on-the-wire changes are given in
-   Section 2.8.
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                      [Page 5]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-2.5.1.  Client Hello
-
-   The user name is appended to the standard client hello message using
-   the extension mechanism defined in [TLSEXT] (see Section 2.8.1).
-   This user name extension is henceforth called the "SRP extension".
-   The following subsections give details of its use.
-
-2.5.1.1.  Session Resumption
-
-   When a client attempts to resume a session that uses SRP
-   authentication, the client MUST include the SRP extension in the
-   client hello message, in case the server cannot or will not allow
-   session resumption, meaning a full handshake is required.
-
-   If the server does agree to resume an existing session, the server
-   MUST ignore the information in the SRP extension of the client hello
-   message, except for its inclusion in the finished message hashes.
-   This is to ensure that attackers cannot replace the authenticated
-   identity without supplying the proper authentication information.
-
-2.5.1.2.  Missing SRP Extension
-
-   The client may offer SRP cipher suites in the hello message but omit
-   the SRP extension.  If the server would like to select an SRP cipher
-   suite in this case, the server SHOULD return a fatal
-   "unknown_psk_identity" alert (see Section 2.9) immediately after
-   processing the client hello message.
-
-   A client receiving this alert MAY choose to reconnect and resend the
-   hello message, this time with the SRP extension.  This allows the
-   client to advertise that it supports SRP, but not have to prompt the
-   user for his user name and password, nor expose the user name in the
-   clear, unless necessary.
-
-2.5.1.3.  Unknown SRP         User Name
-
-   If the server doesn't have a verifier for the user name in the SRP
-   extension, the server MAY abort the handshake with an
-   "unknown_psk_identity" alert (see Section 2.9).  Alternatively, if
-   the server wishes to hide the fact that this user name doesn't have a
-   verifier, the server MAY simulate the protocol as if a verifier
-   existed, but then reject the client's finished message with a
-   "bad_record_mac" alert, as if the password was incorrect.
-
-   To simulate the existence of an entry for each user name, the server
-   must consistently return the same salt (s) and group (N, g) values
-   for the same user name.  For example, the server could store a secret
-   "seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
-
-
-
-Taylor, et al.               Informational                      [Page 6]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   generate the salts [HMAC].  For B, the server can return a random
-   value between 1 and N-1 inclusive.  However, the server should take
-   care to simulate computation delays.  One way to do this is to
-   generate a fake verifier using the "seed key" approach, and then
-   proceed with the protocol as usual.
-
-2.5.2.  Server Certificate
-
-   The server MUST send a certificate if it agrees to an SRP cipher
-   suite that requires the server to provide additional authentication
-   in the form of a digital signature.  See Section 2.7 for details of
-   which cipher suites defined in this document require a server
-   certificate to be sent.
-
-2.5.3.  Server Key Exchange
-
-   The server key exchange message contains the prime (N), the generator
-   (g), and the salt value (s) read from the SRP password file based on
-   the user name (I) received in the client hello extension.
-
-   The server key exchange message also contains the server's public
-   value (B).  The server calculates this value as B = k*v + g^b % N,
-   where b is a random number that SHOULD be at least 256 bits in length
-   and k = SHA1(N | PAD(g)).
-
-   If the server has sent a certificate message, the server key exchange
-   message MUST be signed.
-
-   The group parameters (N, g) sent in this message MUST have N as a
-   safe prime (a prime of the form N=2q+1, where q is also prime).  The
-   integers from 1 to N-1 will form a group under multiplication % N,
-   and g MUST be a generator of this group.  In addition, the group
-   parameters MUST NOT be specially chosen to allow efficient
-   computation of discrete logarithms.
-
-   The SRP group parameters in Appendix A satisfy the above
-   requirements, so the client SHOULD accept any parameters from this
-   appendix that have large enough N values to meet her security
-   requirements.
-
-   The client MAY accept other group parameters from the server, if the
-   client has reason to believe that these parameters satisfy the above
-   requirements, and the parameters have large enough N values.  For
-   example, if the parameters transmitted by the server match parameters
-   on a "known-good" list, the client may choose to accept them.  See
-   Section 3 for additional security considerations relevant to the
-   acceptance of the group parameters.
-
-
-
-
-Taylor, et al.               Informational                      [Page 7]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   Group parameters that are not accepted via one of the above methods
-   MUST be rejected with an "insufficient_security" alert (see
-   Section 2.9).
-
-   The client MUST abort the handshake with an "illegal_parameter" alert
-   if B % N = 0.
-
-2.5.4.  Client Key Exchange
-
-   The client key exchange message carries the client's public value
-   (A).  The client calculates this value as A = g^a % N, where a is a
-   random number that SHOULD be at least 256 bits in length.
-
-   The server MUST abort the handshake with an "illegal_parameter" alert
-   if A % N = 0.
-
-2.6.  Calculating the Premaster Secret
-
-   The premaster secret is calculated by the client as follows:
-
-        I, P = <read from user>
-        N, g, s, B = <read from server>
-        a = random()
-        A = g^a % N
-        u = SHA1(PAD(A) | PAD(B))
-        k = SHA1(N | PAD(g))
-        x = SHA1(s | SHA1(I | ":" | P))
-        <premaster secret> = (B - (k * g^x)) ^ (a + (u * x)) % N
-
-   The premaster secret is calculated by the server as follows:
-
-        N, g, s, v = <read from password file>
-        b = random()
-        k = SHA1(N | PAD(g))
-        B = k*v + g^b % N
-        A = <read from client>
-        u = SHA1(PAD(A) | PAD(B))
-        <premaster secret> = (A * v^u) ^ b % N
-
-   The finished messages perform the same function as the client and
-   server evidence messages (M1 and M2) specified in [SRP-RFC].  If
-   either the client or the server calculates an incorrect premaster
-   secret, the finished messages will fail to decrypt properly, and the
-   other party will return a "bad_record_mac" alert.
-
-   If a client application receives a "bad_record_mac" alert when
-   performing an SRP handshake, it should inform the user that the
-   entered user name and password are incorrect.
-
-
-
-Taylor, et al.               Informational                      [Page 8]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-2.7.  Ciphersuite Definitions
-
-   The following cipher suites are added by this document.  The usage of
-   Advanced Encryption Standard (AES) cipher suites is as defined in
-   [AESCIPH].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
-
-   Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
-   require the server to send a certificate message containing a
-   certificate with the specified type of public key, and to sign the
-   server key exchange message using a matching private key.
-
-   Cipher suites that do not include a digital signature algorithm
-   identifier assume that the server is authenticated by its possession
-   of the SRP verifier.
-
-   Implementations conforming to this specification MUST implement the
-   TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA cipher suite, SHOULD implement the
-   TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
-   cipher suites, and MAY implement the remaining cipher suites.
-
-2.8.  New Message Structures
-
-   This section shows the structure of the messages passed during a
-   handshake that uses SRP for authentication.  The representation
-   language used is the same as that used in [TLS].
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                      [Page 9]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-2.8.1.  Client Hello
-
-   A new extension "srp", with value 12, has been added to the
-   enumerated ExtensionType defined in [TLSEXT].  This value MUST be
-   used as the extension number for the SRP extension.
-
-   The "extension_data" field of the SRP extension SHALL contain:
-
-        opaque srp_I<1..2^8-1>;
-
-   where srp_I is the user name, encoded per Section 2.3.
-
-2.8.2.  Server Key Exchange
-
-   A new value, "srp", has been added to the enumerated
-   KeyExchangeAlgorithm originally defined in [TLS].
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the server's
-   SRP parameters are sent in the server key exchange message, encoded
-   in a ServerSRPParams structure.
-
-   If a certificate is sent to the client, the server key exchange
-   message must be signed.
-
-        enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case diffie_hellman:
-                 ServerDHParams params;
-                 Signature signed_params;
-              case rsa:
-                 ServerRSAParams params;
-                 Signature signed_params;
-              case srp:   /* new entry */
-                 ServerSRPParams params;
-                 Signature signed_params;
-           };
-        } ServerKeyExchange;
-
-        struct {
-           opaque srp_N<1..2^16-1>;
-           opaque srp_g<1..2^16-1>;
-           opaque srp_s<1..2^8-1>;
-           opaque srp_B<1..2^16-1>;
-        } ServerSRPParams;     /* SRP parameters */
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 10]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-2.8.3.  Client Key Exchange
-
-   When the value of KeyExchangeAlgorithm is set to "srp", the client's
-   public value (A) is sent in the client key exchange message, encoded
-   in a ClientSRPPublic structure.
-
-        struct {
-           select (KeyExchangeAlgorithm) {
-              case rsa: EncryptedPreMasterSecret;
-              case diffie_hellman: ClientDiffieHellmanPublic;
-              case srp: ClientSRPPublic;   /* new entry */
-           } exchange_keys;
-        } ClientKeyExchange;
-
-        struct {
-           opaque srp_A<1..2^16-1>;
-        } ClientSRPPublic;
-
-2.9.  Error Alerts
-
-   This document introduces four new uses of alerts:
-
-   o  "unknown_psk_identity" (115) - this alert MAY be sent by a server
-      that would like to select an offered SRP cipher suite, if the SRP
-      extension is absent from the client's hello message.  This alert
-      is always fatal.  See Section 2.5.1.2 for details.
-
-   o  "unknown_psk_identity" (115) - this alert MAY be sent by a server
-      that receives an unknown user name.  This alert is always fatal.
-      See Section 2.5.1.3 for details.
-
-   o  "insufficient_security" (71) - this alert MUST be sent by a client
-      that receives unknown or untrusted (N, g) values.  This alert is
-      always fatal.  See Section 2.5.3 for details.
-
-   o  "illegal_parameter" (47) - this alert MUST be sent by a client or
-      server that receives a key exchange message with A % N = 0 or B %
-      N = 0.  This alert is always fatal.  See Section 2.5.3 and
-      Section 2.5.4 and for details.
-
-   The "insufficient_security" and "illegal_parameter" alerts are
-   defined in [TLS].  The "unknown_psk_identity" alert is defined in
-   [PSK].
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 11]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-3.  Security Considerations
-
-3.1.  General Considerations for Implementors
-
-   The checks described in Section 2.5.3 and Section 2.5.4 on the
-   received values for A and B are CRUCIAL for security and MUST be
-   performed.
-
-   The private values a and b SHOULD be at least 256-bit random numbers,
-   to give approximately 128 bits of security against certain methods of
-   calculating discrete logarithms.  See [TLS], Section D.1, for advice
-   on choosing cryptographically secure random numbers.
-
-3.2.  Accepting Group Parameters
-
-   An attacker who could calculate discrete logarithms % N could
-   compromise user passwords, and could also compromise the
-   confidentiality and integrity of TLS sessions.  Clients MUST ensure
-   that the received parameter N is large enough to make calculating
-   discrete logarithms computationally infeasible.
-
-   An attacker may try to send a prime value N that is large enough to
-   be secure, but that has a special form for which the attacker can
-   more easily compute discrete logarithms (e.g., using the algorithm
-   discussed in [TRAPDOOR]).  If the client executes the protocol using
-   such a prime, the client's password could be compromised.  Because of
-   the difficulty of checking for such primes in real time, clients
-   SHOULD only accept group parameters that come from a trusted source,
-   such as those listed in Appendix A, or parameters configured locally
-   by a trusted administrator.
-
-3.3.  Protocol Characteristics
-
-   If an attacker learns a user's SRP verifier (e.g., by gaining access
-   to a server's password file), the attacker can masquerade as the real
-   server to that user, and can also attempt a dictionary attack to
-   recover that user's password.
-
-   An attacker could repeatedly contact an SRP server and try to guess a
-   legitimate user's password.  Servers SHOULD take steps to prevent
-   this, such as limiting the rate of authentication attempts from a
-   particular IP address or against a particular user name.
-
-   The client's user name is sent in the clear in the Client Hello
-   message.  To avoid sending the user name in the clear, the client
-   could first open a conventional anonymous or server-authenticated
-   connection, then renegotiate an SRP-authenticated connection with the
-   handshake protected by the first connection.
-
-
-
-Taylor, et al.               Informational                     [Page 12]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   If the client receives an "unknown_psk_identity" alert in response to
-   a client hello, this alert may have been inserted by an attacker.
-   The client should be careful about making any decisions, or forming
-   any conclusions, based on receiving this alert.
-
-   It is possible to choose a (user name, password) pair such that the
-   resulting verifier will also match other, related, (user name,
-   password) pairs.  Thus, anyone using verifiers should be careful not
-   to assume that only a single (user name, password) pair matches the
-   verifier.
-
-3.4.  Hash Function Considerations
-
-   This protocol uses SHA-1 to derive several values:
-
-   o  u prevents an attacker who learns a user's verifier from being
-      able to authenticate as that user (see [SRP-6]).
-
-   o  k prevents an attacker who can select group parameters from being
-      able to launch a 2-for-1 guessing attack (see [SRP-6]).
-
-   o  x contains the user's password mixed with a salt.
-
-   Cryptanalytic attacks against SHA-1 that only affect its collision-
-   resistance do not compromise these uses.  If attacks against SHA-1
-   are discovered that do compromise these uses, new cipher suites
-   should be specified to use a different hash algorithm.
-
-   In this situation, clients could send a Client Hello message
-   containing new and/or old SRP cipher suites along with a single SRP
-   extension.  The server could then select the appropriate cipher suite
-   based on the type of verifier it has stored for this user.
-
-4.  IANA Considerations
-
-   This document defines a new TLS extension "srp" (value 12), whose
-   value has been assigned from the TLS ExtensionType Registry defined
-   in [TLSEXT].
-
-   This document defines nine new cipher suites, whose values have been
-   assigned from the TLS Ciphersuite registry defined in [TLS].
-
-      CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
-
-
-
-
-Taylor, et al.               Informational                     [Page 13]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
-
-      CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
-
-      CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
-
-      CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
-
-5.  References
-
-5.1.  Normative References
-
-   [REQ]         Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TLS]         Dierks, T. and E. Rescorla, "The TLS Protocol version
-                 1.1", RFC 4346, April 2006.
-
-   [TLSEXT]      Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
-                 J., and T. Wright, "Transport Layer Security (TLS)
-                 Extensions", RFC 4366, April 2006.
-
-   [STRINGPREP]  Hoffman, P. and M. Blanchet, "Preparation of
-                 Internationalized Strings ("stringprep")", RFC 3454,
-                 December 2002.
-
-   [SASLPREP]    Zeilenga, K., "SASLprep: Stringprep profile for user
-                 names and passwords", RFC 4013, February 2005.
-
-   [SRP-RFC]     Wu, T., "The SRP Authentication and Key Exchange
-                 System", RFC 2945, September 2000.
-
-   [SHA1]        "Secure Hash Standard (SHS)", FIPS 180-2, August 2002.
-
-   [HMAC]        Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
-                 Keyed-Hashing for Message Authentication", RFC 2104,
-                 February 1997.
-
-   [AESCIPH]     Chown, P., "Advanced Encryption Standard (AES)
-                 Ciphersuites for Transport Layer Security (TLS)",
-                 RFC 3268, June 2002.
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 14]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   [PSK]         Eronen, P. and H. Tschofenig, "Pre-Shared Key
-                 Ciphersuites for Transport Layer Security (TLS)",
-                 RFC 4279, December 2005.
-
-   [MODP]        Kivinen, T. and M. Kojo, "More Modular Exponentiation
-                 (MODP) Diffie-Hellman groups for Internet Key Exchange
-                 (IKE)", RFC 3526, May 2003.
-
-5.2.  Informative References
-
-   [IMAP]        Newman, C., "Using TLS with IMAP, POP3 and ACAP",
-                 RFC 2595, June 1999.
-
-   [SRP-6]       Wu, T., "SRP-6: Improvements and Refinements to the
-                 Secure Remote Password Protocol", Submission to IEEE
-                 P1363.2 working group, October 2002,
-                 <http://grouper.ieee.org/groups/1363/>.
-
-   [SRP]         Wu, T., "The Secure Remote Password Protocol",
-                 Proceedings of the 1998 Internet Society Network and
-                 Distributed System Security Symposium pp. 97-111,
-                 March 1998.
-
-   [TRAPDOOR]    Gordon, D., "Designing and Detecting Trapdoors for
-                 Discrete Log Cryptosystems", Springer-Verlag Advances
-                 in Cryptology - Crypto '92, pp. 66-75, 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 15]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-Appendix A.  SRP Group Parameters
-
-   The 1024-, 1536-, and 2048-bit groups are taken from software
-   developed by Tom Wu and Eugene Jhong for the Stanford SRP
-   distribution, and subsequently proven to be prime.  The larger primes
-   are taken from [MODP], but generators have been calculated that are
-   primitive roots of N, unlike the generators in [MODP].
-
-   The 1024-bit and 1536-bit groups MUST be supported.
-
-   1.  1024-bit Group
-
-       The hexadecimal value for the prime is:
-
-          EEAF0AB9 ADB38DD6 9C33F80A FA8FC5E8 60726187 75FF3C0B 9EA2314C
-          9C256576 D674DF74 96EA81D3 383B4813 D692C6E0 E0D5D8E2 50B98BE4
-          8E495C1D 6089DAD1 5DC7D7B4 6154D6B6 CE8EF4AD 69B15D49 82559B29
-          7BCF1885 C529F566 660E57EC 68EDBC3C 05726CC0 2FD4CBF4 976EAA9A
-          FD5138FE 8376435B 9FC61D2F C0EB06E3
-
-       The generator is: 2.
-
-   2.  1536-bit Group
-
-       The hexadecimal value for the prime is:
-
-          9DEF3CAF B939277A B1F12A86 17A47BBB DBA51DF4 99AC4C80 BEEEA961
-          4B19CC4D 5F4F5F55 6E27CBDE 51C6A94B E4607A29 1558903B A0D0F843
-          80B655BB 9A22E8DC DF028A7C EC67F0D0 8134B1C8 B9798914 9B609E0B
-          E3BAB63D 47548381 DBC5B1FC 764E3F4B 53DD9DA1 158BFD3E 2B9C8CF5
-          6EDF0195 39349627 DB2FD53D 24B7C486 65772E43 7D6C7F8C E442734A
-          F7CCB7AE 837C264A E3A9BEB8 7F8A2FE9 B8B5292E 5A021FFF 5E91479E
-          8CE7A28C 2442C6F3 15180F93 499A234D CF76E3FE D135F9BB
-
-       The generator is: 2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 16]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   3.  2048-bit Group
-
-       The hexadecimal value for the prime is:
-
-          AC6BDB41 324A9A9B F166DE5E 1389582F AF72B665 1987EE07 FC319294
-          3DB56050 A37329CB B4A099ED 8193E075 7767A13D D52312AB 4B03310D
-          CD7F48A9 DA04FD50 E8083969 EDB767B0 CF609517 9A163AB3 661A05FB
-          D5FAAAE8 2918A996 2F0B93B8 55F97993 EC975EEA A80D740A DBF4FF74
-          7359D041 D5C33EA7 1D281E44 6B14773B CA97B43A 23FB8016 76BD207A
-          436C6481 F1D2B907 8717461A 5B9D32E6 88F87748 544523B5 24B0D57D
-          5EA77A27 75D2ECFA 032CFBDB F52FB378 61602790 04E57AE6 AF874E73
-          03CE5329 9CCC041C 7BC308D8 2A5698F3 A8D0C382 71AE35F8 E9DBFBB6
-          94B5C803 D89F7AE4 35DE236D 525F5475 9B65E372 FCD68EF2 0FA7111F
-          9E4AFF73
-
-       The generator is: 2.
-
-   4.  3072-bit Group
-
-       This prime is: 2^3072 - 2^3008 - 1 + 2^64 * { [2^2942 pi] +
-       1690314 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A93AD2CA FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 17]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   5.  4096-bit Group
-
-       This prime is: 2^4096 - 2^4032 - 1 + 2^64 * { [2^3966 pi] +
-       240904 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
-          FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 18]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   6.  6144-bit Group
-
-       This prime is: 2^6144 - 2^6080 - 1 + 2^64 * { [2^6014 pi] +
-       929484 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DCC4024 FFFFFFFF FFFFFFFF
-
-       The generator is: 5.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 19]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-   7.  8192-bit Group
-
-       This prime is: 2^8192 - 2^8128 - 1 + 2^64 * { [2^8062 pi] +
-       4743158 }
-
-       Its hexadecimal value is:
-
-          FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
-          8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
-          302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
-          A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
-          49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8
-          FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-          670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B E39E772C
-          180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9 DE2BCBF6 95581718
-          3995497C EA956AE5 15D22618 98FA0510 15728E5A 8AAAC42D AD33170D
-          04507A33 A85521AB DF1CBA64 ECFB8504 58DBEF0A 8AEA7157 5D060C7D
-          B3970F85 A6E1E4C7 ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226
-          1AD2EE6B F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
-          BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31 43DB5BFC
-          E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7 88719A10 BDBA5B26
-          99C32718 6AF4E23C 1A946834 B6150BDA 2583E9CA 2AD44CE8 DBBBC2DB
-          04DE8EF9 2E8EFC14 1FBECAA6 287C5947 4E6BC05D 99B2964F A090C3A2
-          233BA186 515BE7ED 1F612970 CEE2D7AF B81BDD76 2170481C D0069127
-          D5B05AA9 93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34028492
-          36C3FAB4 D27C7026 C1D4DCB2 602646DE C9751E76 3DBA37BD F8FF9406
-          AD9E530E E5DB382F 413001AE B06A53ED 9027D831 179727B0 865A8918
-          DA3EDBEB CF9B14ED 44CE6CBA CED4BB1B DB7F1447 E6CC254B 33205151
-          2BD7AF42 6FB8F401 378CD2BF 5983CA01 C64B92EC F032EA15 D1721D03
-          F482D7CE 6E74FEF6 D55E702F 46980C82 B5A84031 900B1C9E 59E7C97F
-          BEC7E8F3 23A97A7E 36CC88BE 0F1D45B7 FF585AC5 4BD407B2 2B4154AA
-          CC8F6D7E BF48E1D8 14CC5ED2 0F8037E0 A79715EE F29BE328 06A1D58B
-          B7C5DA76 F550AA3D 8A1FBFF0 EB19CCB1 A313D55C DA56C9EC 2EF29632
-          387FE8D7 6E3C0468 043E8F66 3F4860EE 12BF2D5B 0B7474D6 E694F91E
-          6DBE1159 74A3926F 12FEE5E4 38777CB6 A932DF8C D8BEC4D0 73B931BA
-          3BC832B6 8D9DD300 741FA7BF 8AFC47ED 2576F693 6BA42466 3AAB639C
-          5AE4F568 3423B474 2BF1C978 238F16CB E39D652D E3FDB8BE FC848AD9
-          22222E04 A4037C07 13EB57A8 1A23F0C7 3473FC64 6CEA306B 4BCBC886
-          2F8385DD FA9D4B7F A2C087E8 79683303 ED5BDD3A 062B3CF5 B3A278A6
-          6D2A13F8 3F44F82D DF310EE0 74AB6A36 4597E899 A0255DC1 64F31CC5
-          0846851D F9AB4819 5DED7EA1 B1D510BD 7EE74D73 FAF36BC3 1ECFA268
-          359046F4 EB879F92 4009438B 481C6CD7 889A002E D5EE382B C9190DA6
-          FC026E47 9558E447 5677E9AA 9E3050E2 765694DF C81F56E8 80B96E71
-          60C980DD 98EDD3DF FFFFFFFF FFFFFFFF
-
-       The generator is: 19 (decimal).
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 20]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-Appendix B.  SRP Test Vectors
-
-   The following test vectors demonstrate calculation of the verifier
-   and premaster secret.
-
-      I = "alice"
-
-      P = "password123"
-
-      s = BEB25379 D1A8581E B5A72767 3A2441EE
-
-      N, g = <1024-bit parameters from Appendix A>
-
-      k = 7556AA04 5AEF2CDD 07ABAF0F 665C3E81 8913186F
-
-      x = 94B7555A ABE9127C C58CCF49 93DB6CF8 4D16C124
-
-      v =
-
-         7E273DE8 696FFC4F 4E337D05 B4B375BE B0DDE156 9E8FA00A 9886D812
-         9BADA1F1 822223CA 1A605B53 0E379BA4 729FDC59 F105B478 7E5186F5
-         C671085A 1447B52A 48CF1970 B4FB6F84 00BBF4CE BFBB1681 52E08AB5
-         EA53D15C 1AFF87B2 B9DA6E04 E058AD51 CC72BFC9 033B564E 26480D78
-         E955A5E2 9E7AB245 DB2BE315 E2099AFB
-
-      a =
-
-         60975527 035CF2AD 1989806F 0407210B C81EDC04 E2762A56 AFD529DD
-         DA2D4393
-
-      b =
-
-         E487CB59 D31AC550 471E81F0 0F6928E0 1DDA08E9 74A004F4 9E61F5D1
-         05284D20
-
-      A =
-
-         61D5E490 F6F1B795 47B0704C 436F523D D0E560F0 C64115BB 72557EC4
-         4352E890 3211C046 92272D8B 2D1A5358 A2CF1B6E 0BFCF99F 921530EC
-         8E393561 79EAE45E 42BA92AE ACED8251 71E1E8B9 AF6D9C03 E1327F44
-         BE087EF0 6530E69F 66615261 EEF54073 CA11CF58 58F0EDFD FE15EFEA
-         B349EF5D 76988A36 72FAC47B 0769447B
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 21]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-      B =
-
-         BD0C6151 2C692C0C B6D041FA 01BB152D 4916A1E7 7AF46AE1 05393011
-         BAF38964 DC46A067 0DD125B9 5A981652 236F99D9 B681CBF8 7837EC99
-         6C6DA044 53728610 D0C6DDB5 8B318885 D7D82C7F 8DEB75CE 7BD4FBAA
-         37089E6F 9C6059F3 88838E7A 00030B33 1EB76840 910440B1 B27AAEAE
-         EB4012B7 D7665238 A8E3FB00 4B117B58
-
-      u =
-
-         CE38B959 3487DA98 554ED47D 70A7AE5F 462EF019
-
-      <premaster secret> =
-
-         B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
-         233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
-         41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
-         3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
-         C346D7E4 74B29EDE 8A469FFE CA686E5A
-
-Appendix C.  Acknowledgements
-
-   Thanks to all on the IETF TLS mailing list for ideas and analysis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 22]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-Authors' Addresses
-
-   David Taylor
-   Independent
-
-   EMail: dtaylor@gnutls.org
-
-
-   Tom Wu
-   Cisco
-
-   EMail: thomwu@cisco.com
-
-
-   Nikos Mavrogiannopoulos
-   Independent
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-   Trevor Perrin
-   Independent
-
-   EMail: trevp@trevp.net
-   URI:   http://trevp.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 23]
-
-RFC 5054            Using SRP for TLS Authentication       November 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Taylor, et al.               Informational                     [Page 24]
-
diff --git a/doc/protocol/rfc5077.txt b/doc/protocol/rfc5077.txt
deleted file mode 100644
index 13e7abe66e..0000000000
--- a/doc/protocol/rfc5077.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Salowey
-Request for Comments: 5077                                       H. Zhou
-Obsoletes: 4507                                            Cisco Systems
-Category: Standards Track                                      P. Eronen
-                                                                   Nokia
-                                                           H. Tschofenig
-                                                  Nokia Siemens Networks
-                                                            January 2008
-
-
-       Transport Layer Security (TLS) Session Resumption without
-                           Server-Side State
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes a mechanism that enables the Transport Layer
-   Security (TLS) server to resume sessions and avoid keeping per-client
-   session state.  The TLS server encapsulates the session state into a
-   ticket and forwards it to the client.  The client can subsequently
-   resume a session using the obtained ticket.  This document obsoletes
-   RFC 4507.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 1]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.2.  SessionTicket TLS Extension  . . . . . . . . . . . . . . .  7
-     3.3.  NewSessionTicket Handshake Message . . . . . . . . . . . .  8
-     3.4.  Interaction with TLS Session ID  . . . . . . . . . . . . .  9
-   4.  Recommended Ticket Construction  . . . . . . . . . . . . . . . 10
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Invalidating Sessions  . . . . . . . . . . . . . . . . . . 12
-     5.2.  Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 12
-     5.3.  Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 12
-     5.4.  Denial of Service Attacks  . . . . . . . . . . . . . . . . 12
-     5.5.  Ticket Protection Key Management . . . . . . . . . . . . . 13
-     5.6.  Ticket Lifetime  . . . . . . . . . . . . . . . . . . . . . 13
-     5.7.  Alternate Ticket Formats and Distribution Schemes  . . . . 13
-     5.8.  Identity Privacy, Anonymity, and Unlinkability . . . . . . 14
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
-   Appendix A.  Discussion of Changes to RFC 4507 . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 2]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-1.  Introduction
-
-   This document defines a way to resume a Transport Layer Security
-   (TLS) session without requiring session-specific state at the TLS
-   server.  This mechanism may be used with any TLS ciphersuite.  This
-   document applies to both TLS 1.0 defined in [RFC2246], and TLS 1.1
-   defined in [RFC4346].  The mechanism makes use of TLS extensions
-   defined in [RFC4366] and defines a new TLS message type.
-
-   This mechanism is useful in the following situations:
-
-   1.  servers that handle a large number of transactions from different
-       users
-
-   2.  servers that desire to cache sessions for a long time
-
-   3.  ability to load balance requests across servers
-
-   4.  embedded servers with little memory
-
-   This document obsoletes RFC 4507 [RFC4507] to correct an error in the
-   encoding that caused the specification to differ from deployed
-   implementations.  At the time of this writing, there are no known
-   implementations that follow the encoding specified in RFC 4507.  This
-   update to RFC 4507 aligns the document with currently deployed
-   implementations.  More details of the change are given in Appendix A.
-
-2.  Terminology
-
-   Within this document, the term 'ticket' refers to a cryptographically
-   protected data structure that is created and consumed by the server
-   to rebuild session-specific state.
-
-   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 [RFC2119].
-
-3.  Protocol
-
-   This specification describes a mechanism to distribute encrypted
-   session-state information to the client in the form of a ticket and a
-   mechanism to present the ticket back to the server.  The ticket is
-   created by a TLS server and sent to a TLS client.  The TLS client
-   presents the ticket to the TLS server to resume a session.
-   Implementations of this specification are expected to support both
-   mechanisms.  Other specifications can take advantage of the session
-   tickets, perhaps specifying alternative means for distribution or
-   selection.  For example, a separate specification may describe an
-
-
-
-Salowey, et al.             Standards Track                     [Page 3]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   alternate way to distribute a ticket and use the TLS extension in
-   this document to resume the session.  This behavior is beyond the
-   scope of the document and would need to be described in a separate
-   specification.
-
-3.1.  Overview
-
-   The client indicates that it supports this mechanism by including a
-   SessionTicket TLS extension in the ClientHello message.  The
-   extension will be empty if the client does not already possess a
-   ticket for the server.  The server sends an empty SessionTicket
-   extension to indicate that it will send a new session ticket using
-   the NewSessionTicket handshake message.  The extension is described
-   in Section 3.2.
-
-   If the server wants to use this mechanism, it stores its session
-   state (such as ciphersuite and master secret) to a ticket that is
-   encrypted and integrity-protected by a key known only to the server.
-   The ticket is distributed to the client using the NewSessionTicket
-   TLS handshake message described in Section 3.3.  This message is sent
-   during the TLS handshake before the ChangeCipherSpec message, after
-   the server has successfully verified the client's Finished message.
-
-         Client                                               Server
-
-         ClientHello
-        (empty SessionTicket extension)-------->
-                                                         ServerHello
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                    NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-   Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 4]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   The client caches this ticket along with the master secret and other
-   parameters associated with the current session.  When the client
-   wishes to resume the session, it includes the ticket in the
-   SessionTicket extension within the ClientHello message.  Appendix A
-   provides a detailed description of the encoding of the extension and
-   changes from RFC 4507.  The server then decrypts the received ticket,
-   verifies the ticket's validity, retrieves the session state from the
-   contents of the ticket, and uses this state to resume the session.
-   The interaction with the TLS Session ID is described in Section 3.4.
-   If the server successfully verifies the client's ticket, then it may
-   renew the ticket by including a NewSessionTicket handshake message
-   after the ServerHello.
-
-         Client                                                Server
-         ClientHello
-         (SessionTicket extension)      -------->
-                                                          ServerHello
-                                      (empty SessionTicket extension)
-                                                     NewSessionTicket
-                                                   [ChangeCipherSpec]
-                                       <--------             Finished
-         [ChangeCipherSpec]
-         Finished                      -------->
-         Application Data              <------->     Application Data
-
-    Figure 2: Message Flow for Abbreviated Handshake Using New Session
-                                  Ticket
-
-   A recommended ticket format is given in Section 4.
-
-   If the server cannot or does not want to honor the ticket, then it
-   can initiate a full handshake with the client.
-
-   In the case that the server does not wish to issue a new ticket at
-   this time, it just completes the handshake without including a
-   SessionTicket extension or NewSessionTicket handshake message.  This
-   is shown below (this flow is identical to Figure 1 in RFC 4346,
-   except for the SessionTicket extension in the first message):
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 5]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-         Client                                               Server
-
-         ClientHello
-         (SessionTicket extension)    -------->
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-    Figure 3: Message Flow for Server Completing Full Handshake Without
-                        Issuing New Session Ticket
-
-   It is also permissible to have an exchange similar to Figure 3 using
-   the abbreviated handshake defined in Figure 2 of RFC 4346, where the
-   client uses the SessionTicket extension to resume the session, but
-   the server does not wish to issue a new ticket, and therefore does
-   not send a SessionTicket extension.
-
-   If the server rejects the ticket, it may still wish to issue a new
-   ticket after performing the full handshake as shown below (this flow
-   is identical to Figure 1, except the SessionTicket extension in the
-   ClientHello is not empty):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 6]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-         Client                                               Server
-
-         ClientHello
-         (SessionTicket extension) -------->
-                                                         ServerHello
-                                     (empty SessionTicket extension)
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                  <--------          ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                 -------->
-                                                    NewSessionTicket
-                                                  [ChangeCipherSpec]
-                                  <--------                 Finished
-         Application Data         <------->         Application Data
-
-    Figure 4: Message Flow for Server Rejecting Ticket, Performing Full
-                 Handshake, and Issuing New Session Ticket
-
-3.2.  SessionTicket TLS Extension
-
-   The SessionTicket TLS extension is based on [RFC4366].  The format of
-   the ticket is an opaque structure used to carry session-specific
-   state information.  This extension may be sent in the ClientHello and
-   ServerHello.
-
-   If the client possesses a ticket that it wants to use to resume a
-   session, then it includes the ticket in the SessionTicket extension
-   in the ClientHello.  If the client does not have a ticket and is
-   prepared to receive one in the NewSessionTicket handshake message,
-   then it MUST include a zero-length ticket in the SessionTicket
-   extension.  If the client is not prepared to receive a ticket in the
-   NewSessionTicket handshake message, then it MUST NOT include a
-   SessionTicket extension unless it is sending a non-empty ticket it
-   received through some other means from the server.
-
-   The server uses a zero-length SessionTicket extension to indicate to
-   the client that it will send a new session ticket using the
-   NewSessionTicket handshake message described in Section 3.3.  The
-   server MUST send this extension in the ServerHello if it wishes to
-   issue a new ticket to the client using the NewSessionTicket handshake
-   message.  The server MUST NOT send this extension if it does not
-   receive one in the ClientHello.
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 7]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   If the server fails to verify the ticket, then it falls back to
-   performing a full handshake.  If the ticket is accepted by the server
-   but the handshake fails, the client SHOULD delete the ticket.
-
-   The SessionTicket extension has been assigned the number 35.  The
-   extension_data field of SessionTicket extension contains the ticket.
-
-3.3.  NewSessionTicket Handshake Message
-
-   This message is sent by the server during the TLS handshake before
-   the ChangeCipherSpec message.  This message MUST be sent if the
-   server included a SessionTicket extension in the ServerHello.  This
-   message MUST NOT be sent if the server did not include a
-   SessionTicket extension in the ServerHello.  This message is included
-   in the hash used to create and verify the Finished message.  In the
-   case of a full handshake, the server MUST verify the client's
-   Finished message before sending the ticket.  The client MUST NOT
-   treat the ticket as valid until it has verified the server's Finished
-   message.  If the server determines that it does not want to include a
-   ticket after it has included the SessionTicket extension in the
-   ServerHello, then it sends a zero-length ticket in the
-   NewSessionTicket handshake message.
-
-   If the server successfully verifies the client's ticket, then it MAY
-   renew the ticket by including a NewSessionTicket handshake message
-   after the ServerHello in the abbreviated handshake.  The client
-   should start using the new ticket as soon as possible after it
-   verifies the server's Finished message for new connections.  Note
-   that since the updated ticket is issued before the handshake
-   completes, it is possible that the client may not put the new ticket
-   into use before it initiates new connections.  The server MUST NOT
-   assume that the client actually received the updated ticket until it
-   successfully verifies the client's Finished message.
-
-   The NewSessionTicket handshake message has been assigned the number 4
-   and its definition is given at the end of this section.  The
-   ticket_lifetime_hint field contains a hint from the server about how
-   long the ticket should be stored.  The value indicates the lifetime
-   in seconds as a 32-bit unsigned integer in network byte order
-   relative to when the ticket is received.  A value of zero is reserved
-   to indicate that the lifetime of the ticket is unspecified.  A client
-   SHOULD delete the ticket and associated state when the time expires.
-   It MAY delete the ticket earlier based on local policy.  A server MAY
-   treat a ticket as valid for a shorter or longer period of time than
-   what is stated in the ticket_lifetime_hint.
-
-
-
-
-
-
-Salowey, et al.             Standards Track                     [Page 8]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-      struct {
-          HandshakeType msg_type;
-          uint24 length;
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-              case session_ticket:      NewSessionTicket; /* NEW */
-          } body;
-      } Handshake;
-
-
-      struct {
-          uint32 ticket_lifetime_hint;
-          opaque ticket<0..2^16-1>;
-      } NewSessionTicket;
-
-3.4.  Interaction with TLS Session ID
-
-   If a server is planning on issuing a session ticket to a client that
-   does not present one, it SHOULD include an empty Session ID in the
-   ServerHello.  If the server rejects the ticket and falls back to the
-   full handshake then it may include a non-empty Session ID to indicate
-   its support for stateful session resumption.  If the client receives
-   a session ticket from the server, then it discards any Session ID
-   that was sent in the ServerHello.
-
-   When presenting a ticket, the client MAY generate and include a
-   Session ID in the TLS ClientHello.  If the server accepts the ticket
-   and the Session ID is not empty, then it MUST respond with the same
-   Session ID present in the ClientHello.  This allows the client to
-   easily differentiate when the server is resuming a session from when
-   it is falling back to a full handshake.  Since the client generates a
-   Session ID, the server MUST NOT rely upon the Session ID having a
-   particular value when validating the ticket.  If a ticket is
-   presented by the client, the server MUST NOT attempt to use the
-   Session ID in the ClientHello for stateful session resumption.
-   Alternatively, the client MAY include an empty Session ID in the
-   ClientHello.  In this case, the client ignores the Session ID sent in
-   the ServerHello and determines if the server is resuming a session by
-   the subsequent handshake messages.
-
-
-
-Salowey, et al.             Standards Track                     [Page 9]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-4.  Recommended Ticket Construction
-
-   This section describes a recommended format and protection for the
-   ticket.  Note that the ticket is opaque to the client, so the
-   structure is not subject to interoperability concerns, and
-   implementations may diverge from this format.  If implementations do
-   diverge from this format, they must take security concerns seriously.
-   Clients MUST NOT examine the ticket under the assumption that it
-   complies with this document.
-
-   The server uses two different keys: one 128-bit key for Advanced
-   Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode
-   [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634].
-
-   The ticket is structured as follows:
-
-      struct {
-          opaque key_name[16];
-          opaque iv[16];
-          opaque encrypted_state<0..2^16-1>;
-          opaque mac[32];
-      } ticket;
-
-   Here, key_name serves to identify a particular set of keys used to
-   protect the ticket.  It enables the server to easily recognize
-   tickets it has issued.  The key_name should be randomly generated to
-   avoid collisions between servers.  One possibility is to generate new
-   random keys and key_name every time the server is started.
-
-   The actual state information in encrypted_state is encrypted using
-   128-bit AES in CBC mode with the given IV.  The Message
-   Authentication Code (MAC) is calculated using HMAC-SHA-256 over
-   key_name (16 octets) and IV (16 octets), followed by the length of
-   the encrypted_state field (2 octets) and its contents (variable
-   length).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 10]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-      struct {
-          ProtocolVersion protocol_version;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          opaque master_secret[48];
-          ClientIdentity client_identity;
-          uint32 timestamp;
-      } StatePlaintext;
-
-      enum {
-         anonymous(0),
-         certificate_based(1),
-         psk(2)
-     } ClientAuthenticationType;
-
-      struct {
-          ClientAuthenticationType client_authentication_type;
-          select (ClientAuthenticationType) {
-              case anonymous: struct {};
-              case certificate_based:
-                  ASN.1Cert certificate_list<0..2^24-1>;
-              case psk:
-                  opaque psk_identity<0..2^16-1>;   /* from [RFC4279] */
-          };
-       } ClientIdentity;
-
-   The structure StatePlaintext stores the TLS session state including
-   the master_secret.  The timestamp within this structure allows the
-   TLS server to expire tickets.  To cover the authentication and key
-   exchange protocols provided by TLS, the ClientIdentity structure
-   contains the authentication type of the client used in the initial
-   exchange (see ClientAuthenticationType).  To offer the TLS server
-   with the same capabilities for authentication and authorization, a
-   certificate list is included in case of public-key-based
-   authentication.  The TLS server is therefore able to inspect a number
-   of different attributes within these certificates.  A specific
-   implementation might choose to store a subset of this information or
-   additional information.  Other authentication mechanisms, such as
-   Kerberos [RFC2712], would require different client identity data.
-   Other TLS extensions may require the inclusion of additional data in
-   the StatePlaintext structure.
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 11]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-5.  Security Considerations
-
-   This section addresses security issues related to the usage of a
-   ticket.  Tickets must be authenticated and encrypted to prevent
-   modification or eavesdropping by an attacker.  Several attacks
-   described below will be possible if this is not carefully done.
-
-   Implementations should take care to ensure that the processing of
-   tickets does not increase the chance of denial of service as
-   described below.
-
-5.1.  Invalidating Sessions
-
-   The TLS specification requires that TLS sessions be invalidated when
-   errors occur.  [CSSC] discusses the security implications of this in
-   detail.  In the analysis within this paper, failure to invalidate
-   sessions does not pose a security risk.  This is because the TLS
-   handshake uses a non-reversible function to derive keys for a session
-   so information about one session does not provide an advantage to
-   attack the master secret or a different session.  If a session
-   invalidation scheme is used, the implementation should verify the
-   integrity of the ticket before using the contents to invalidate a
-   session to ensure that an attacker cannot invalidate a chosen
-   session.
-
-5.2.  Stolen Tickets
-
-   An eavesdropper or man-in-the-middle may obtain the ticket and
-   attempt to use it to establish a session with the server; however,
-   since the ticket is encrypted and the attacker does not know the
-   secret key, a stolen ticket does not help an attacker resume a
-   session.  A TLS server MUST use strong encryption and integrity
-   protection for the ticket to prevent an attacker from using a brute
-   force mechanism to obtain the ticket's contents.
-
-5.3.  Forged Tickets
-
-   A malicious user could forge or alter a ticket in order to resume a
-   session, to extend its lifetime, to impersonate another user, or to
-   gain additional privileges.  This attack is not possible if the
-   ticket is protected using a strong integrity protection algorithm
-   such as a keyed HMAC-SHA-256.
-
-5.4.  Denial of Service Attacks
-
-   The key_name field defined in the recommended ticket format helps the
-   server efficiently reject tickets that it did not issue.  However, an
-   adversary could store or generate a large number of tickets to send
-
-
-
-Salowey, et al.             Standards Track                    [Page 12]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   to the TLS server for verification.  To minimize the possibility of a
-   denial of service, the verification of the ticket should be
-   lightweight (e.g., using efficient symmetric key cryptographic
-   algorithms).
-
-5.5.  Ticket Protection Key Management
-
-   A full description of the management of the keys used to protect the
-   ticket is beyond the scope of this document.  A list of RECOMMENDED
-   practices is given below.
-
-   o  The keys should be generated securely following the randomness
-      recommendations in [RFC4086].
-
-   o  The keys and cryptographic protection algorithms should be at
-      least 128 bits in strength.  Some ciphersuites and applications
-      may require cryptographic protection greater than 128 bits in
-      strength.
-
-   o  The keys should not be used for any purpose other than generating
-      and verifying tickets.
-
-   o  The keys should be changed regularly.
-
-   o  The keys should be changed if the ticket format or cryptographic
-      protection algorithms change.
-
-5.6.  Ticket Lifetime
-
-   The TLS server controls the lifetime of the ticket.  Servers
-   determine the acceptable lifetime based on the operational and
-   security requirements of the environments in which they are deployed.
-   The ticket lifetime may be longer than the 24-hour lifetime
-   recommended in [RFC4346].  TLS clients may be given a hint of the
-   lifetime of the ticket.  Since the lifetime of a ticket may be
-   unspecified, a client has its own local policy that determines when
-   it discards tickets.
-
-5.7.  Alternate Ticket Formats and Distribution Schemes
-
-   If the ticket format or distribution scheme defined in this document
-   is not used, then great care must be taken in analyzing the security
-   of the solution.  In particular, if confidential information, such as
-   a secret key, is transferred to the client, it MUST be done using
-   secure communication so as to prevent attackers from obtaining or
-   modifying the key.  Also, the ticket MUST have its integrity and
-   confidentiality protected with strong cryptographic techniques to
-   prevent a breach in the security of the system.
-
-
-
-Salowey, et al.             Standards Track                    [Page 13]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-5.8.  Identity Privacy, Anonymity, and Unlinkability
-
-   This document mandates that the content of the ticket is
-   confidentiality protected in order to avoid leakage of its content,
-   such as user-relevant information.  As such, it prevents disclosure
-   of potentially sensitive information carried within the ticket.
-
-   The initial handshake exchange, which was used to obtain the ticket,
-   might not provide identity confidentiality of the client based on the
-   properties of TLS.  Another relevant security threat is the ability
-   for an on-path adversary to observe multiple TLS handshakes where the
-   same ticket is used, therefore concluding they belong to the same
-   communication endpoints.  Application designers that use the ticket
-   mechanism described in this document should consider that
-   unlinkability [ANON] is not necessarily provided.
-
-   While a full discussion of these topics is beyond the scope of this
-   document, it should be noted that it is possible to issue a ticket
-   using a TLS renegotiation handshake that occurs after a secure tunnel
-   has been established by a previous handshake.  This may help address
-   some privacy and unlinkability issues in some environments.
-
-6.  Acknowledgements
-
-   The authors would like to thank the following people for their help
-   with preparing and reviewing this document: Eric Rescorla, Mohamad
-   Badra, Tim Dierks, Nelson Bolyard, Nancy Cam-Winget, David McGrew,
-   Rob Dugal, Russ Housley, Amir Herzberg, Bernard Aboba, and members of
-   the TLS working group.
-
-   [CSSC] describes a solution that is very similar to the one described
-   in this document and gives a detailed analysis of the security
-   considerations involved.  [RFC2712] describes a mechanism for using
-   Kerberos [RFC4120] in TLS ciphersuites, which helped inspire the use
-   of tickets to avoid server state.  [RFC4851] makes use of a similar
-   mechanism to avoid maintaining server state for the cryptographic
-   tunnel.  [SC97] also investigates the concept of stateless sessions.
-
-   The authors would also like to thank Jan Nordqvist, who found the
-   encoding error in RFC 4507, corrected by this document.  In addition
-   Nagendra Modadugu, Wan-Teh Chang, and Michael D'Errico provided
-   useful feedback during the review of this document.
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 14]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-7.  IANA Considerations
-
-   IANA has assigned a TLS extension number of 35 to the SessionTicket
-   TLS extension from the TLS registry of ExtensionType values defined
-   in [RFC4366].
-
-   IANA has assigned a TLS HandshakeType number 4 to the
-   NewSessionTicket handshake type from the TLS registry of
-   HandshakeType values defined in [RFC4346].
-
-   This document does not require any actions or assignments from IANA.
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC4507]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
-              "Transport Layer Security (TLS) Session Resumption without
-              Server-Side State", RFC 4507, May 2006.
-
-8.2.  Informative References
-
-   [AES]      National Institute of Standards and Technology, "Advanced
-              Encryption Standard (AES)", Federal Information Processing
-              Standards (FIPS) Publication 197, November 2001.
-
-   [ANON]     Pfitzmann, A. and M. Hansen, "Anonymity, Unlinkability,
-              Unobservability, Pseudonymity, and Identity Management - A
-              Consolidated Proposal for Terminology", http://
-              dud.inf.tu-dresden.de/literatur/
-              Anon_Terminology_v0.26-1.pdf Version 0.26, December 2005.
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 15]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   [CBC]      National Institute of Standards and Technology,
-              "Recommendation for Block Cipher Modes of Operation -
-              Methods and Techniques", NIST Special Publication 800-38A,
-              December 2001.
-
-   [CSSC]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
-              caching for TLS", Transactions on Information and System
-              Security (TISSEC) , Volume 7, Issue 4, November 2004.
-
-   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
-              Suites to Transport Layer Security (TLS)", RFC 2712,
-              October 1999.
-
-   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-              Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
-              Kerberos Network Authentication Service (V5)", RFC 4120,
-              July 2005.
-
-   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
-              for Transport Layer Security (TLS)", RFC 4279,
-              December 2005.
-
-   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
-              (SHA and HMAC-SHA)", RFC 4634, July 2006.
-
-   [RFC4851]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
-              Flexible Authentication via Secure Tunneling Extensible
-              Authentication Protocol Method (EAP-FAST)", RFC 4851,
-              May 2007.
-
-   [SC97]     Aura, T. and P. Nikander, "Stateless Connections",
-              Proceedings of the First International Conference on
-              Information and Communication Security (ICICS '97) , 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 16]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-Appendix A.  Discussion of Changes to RFC 4507
-
-   RFC 4507 [RFC4507] defines a mechanism to resume a TLS session
-   without maintaining server side state by specifying an encrypted
-   ticket that is maintained on the client.  The client presents this
-   ticket to the server in a SessionTicket hello extension.  The
-   encoding in RFC 4507 used the XDR style encoding specified in TLS
-   [RFC4346].
-
-   An error in the encoding caused the specification to differ from
-   deployed implementations.  At the time of this writing there are no
-   known implementations that follow the encoding specified in RFC 4507.
-   This update to RFC 4507 aligns the document with these currently
-   deployed implementations.
-
-   Erroneous encoding in RFC 4507 resulted in two length fields; one for
-   the extension contents and one for the ticket itself.  Hence, for a
-   ticket that is 256 bytes long and begins with the hex value FF FF,
-   the encoding of the extension would be as follows according to RFC
-   4507:
-
-        00 23          Ticket Extension type 35
-        01 02          Length of extension contents
-        01 00          Length of ticket
-        FF FF .. ..    Actual ticket
-
-   The update proposed in this document reflects what implementations
-   actually encode, namely it removes the redundant length field.  So,
-   for a ticket that is 256 bytes long and begins with the hex value FF
-   FF, the encoding of the extension would be as follows according to
-   this update:
-
-        00 23          Extension type 35
-        01 00          Length of extension contents (ticket)
-        FF FF .. ..    Actual ticket
-
-   A server implemented according to RFC 4507 receiving a ticket
-   extension from a client conforming to this document would interpret
-   the first two bytes of the ticket as the length of this ticket.  This
-   will result in either an inconsistent length field or in the
-   processing of a ticket missing the first two bytes.  In the first
-   case, the server should reject the request based on a malformed
-   length.  In the second case, the server should reject the ticket
-   based on a malformed ticket, incorrect key version, or failed
-   decryption.  A server implementation based on this update receiving
-   an RFC 4507 extension would interpret the first length field as the
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 17]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-   length of the ticket and include the second two length bytes as the
-   first bytes in the ticket, resulting in the ticket being rejected
-   based on a malformed ticket, incorrect key version, or failed
-   decryption.
-
-   Note that the encoding of an empty SessionTicket extension was
-   ambiguous in RFC 4507.  An RFC 4507 implementation may have encoded
-   it as:
-
-        00 23      Extension type 35
-        00 02      Length of extension contents
-        00 00      Length of ticket
-
-   or it may have encoded it the same way as this update:
-
-        00 23      Extension type 35
-        00 00      Length of extension contents
-
-   A server wishing to support RFC 4507 clients should respond to an
-   empty SessionTicket extension encoded the same way as it received it.
-
-   A server implementation can construct tickets such that it can detect
-   an RFC 4507 implementation, if one existed, by including a cookie at
-   the beginning of the tickets that can be differentiated from a valid
-   length.  For example, if an implementation constructed tickets to
-   start with the hex values FF FF, then it could determine where the
-   ticket begins and determine the length correctly from the type of
-   length fields present.
-
-   This document makes a few additional changes to RFC 4507 listed
-   below.
-
-   o  Clarifying that the server can allow session resumption using a
-      ticket without issuing a new ticket in Section 3.1.
-
-   o  Clarifying that the lifetime is relative to when the ticket is
-      received in section 3.3.
-
-   o  Clarifying that the NewSessionTicket handshake message is included
-      in the hash generated for the Finished messages in Section 3.3.
-
-   o  Clarifying the interaction with TLS Session ID in Section 3.4.
-
-   o  Recommending the use of SHA-256 for the integrity protection of
-      the ticket in Section 4.
-
-   o  Clarifying that additional data can be included in the
-      StatePlaintext structure in Section 4.
-
-
-
-Salowey, et al.             Standards Track                    [Page 18]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-Authors' Addresses
-
-   Joseph Salowey
-   Cisco Systems
-   2901 3rd Ave
-   Seattle, WA  98121
-   US
-
-   EMail: jsalowey@cisco.com
-
-
-   Hao Zhou
-   Cisco Systems
-   4125 Highlander Parkway
-   Richfield, OH  44286
-   US
-
-   EMail: hzhou@cisco.com
-
-
-   Pasi Eronen
-   Nokia Research Center
-   P.O. Box 407
-   FIN-00045 Nokia Group
-   Finland
-
-   EMail: pasi.eronen@nokia.com
-
-
-   Hannes Tschofenig
-   Nokia Siemens Networks
-   Otto-Hahn-Ring 6
-   Munich, Bayern  81739
-   Germany
-
-   EMail: Hannes.Tschofenig@nsn.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 19]
-
-RFC 5077            Stateless TLS Session Resumption        January 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Salowey, et al.             Standards Track                    [Page 20]
-
diff --git a/doc/protocol/rfc5081.txt b/doc/protocol/rfc5081.txt
deleted file mode 100644
index 0d2be0997d..0000000000
--- a/doc/protocol/rfc5081.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                               N. Mavrogiannopoulos
-Request for Comments: 5081                                   Independent
-Category: Experimental                                     November 2007
-
-
-  Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
-
-Status of This Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo proposes extensions to the Transport Layer Security (TLS)
-   protocol to support the OpenPGP key format.  The extensions discussed
-   here include a certificate type negotiation mechanism, and the
-   required modifications to the TLS Handshake Protocol.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Terminology .....................................................2
-   3. Changes to the Handshake Message Contents .......................2
-      3.1. Client Hello ...............................................2
-      3.2. Server Hello ...............................................3
-      3.3. Server Certificate .........................................3
-      3.4. Certificate Request ........................................4
-      3.5. Client Certificate .........................................5
-      3.6. Other Handshake Messages ...................................5
-   4. Security Considerations .........................................5
-   5. IANA Considerations .............................................6
-   6. Acknowledgements ................................................6
-   7. References ......................................................6
-      7.1. Normative References .......................................6
-      7.2. Informative References .....................................7
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 1]
-
-RFC 5081                   Using OpenPGP Keys              November 2007
-
-
-1.  Introduction
-
-   The IETF has two sets of standards for public key certificates, one
-   set for use of X.509 certificates [PKIX] and one for OpenPGP
-   certificates [OpenPGP].  At the time of writing, TLS [TLS] standards
-   are defined to use only X.509 certificates.  This document specifies
-   a way to negotiate use of OpenPGP certificates for a TLS session, and
-   specifies how to transport OpenPGP certificates via TLS.  The
-   proposed extensions are backward compatible with the current TLS
-   specification, so that existing client and server implementations
-   that make use of X.509 certificates are not affected.
-
-2.  Terminology
-
-   The term "OpenPGP key" is used in this document as in the OpenPGP
-   specification [OpenPGP].  We use the term "OpenPGP certificate" to
-   refer to OpenPGP keys that are enabled for authentication.
-
-   This document uses the same notation and terminology used in the TLS
-   Protocol specification [TLS].
-
-   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 [RFC2119].
-
-3.  Changes to the Handshake Message Contents
-
-   This section describes the changes to the TLS handshake message
-   contents when OpenPGP certificates are to be used for authentication.
-
-3.1.  Client Hello
-
-   In order to indicate the support of multiple certificate types,
-   clients MUST include an extension of type "cert_type" (see Section 5)
-   to the extended client hello message.  The hello extension mechanism
-   is described in [TLSEXT].
-
-   This extension carries a list of supported certificate types the
-   client can use, sorted by client preference.  This extension MUST be
-   omitted if the client only supports X.509 certificates.  The
-   "extension_data" field of this extension contains a
-   CertificateTypeExtension structure.
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 2]
-
-RFC 5081                   Using OpenPGP Keys              November 2007
-
-
-      enum { client, server } ClientOrServerExtension;
-
-      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
-
-      struct {
-         select(ClientOrServerExtension) {
-            case client:
-               CertificateType certificate_types<1..2^8-1>;
-            case server:
-               CertificateType certificate_type;
-         }
-      } CertificateTypeExtension;
-
-   No new cipher suites are required to use OpenPGP certificates.  All
-   existing cipher suites that support a compatible, with the key, key
-   exchange method can be used in combination with OpenPGP certificates.
-
-3.2.  Server Hello
-
-   If the server receives a client hello that contains the "cert_type"
-   extension and chooses a cipher suite that requires a certificate,
-   then two outcomes are possible.  The server MUST either select a
-   certificate type from the certificate_types field in the extended
-   client hello or terminate the connection with a fatal alert of type
-   "unsupported_certificate".
-
-   The certificate type selected by the server is encoded in a
-   CertificateTypeExtension structure, which is included in the extended
-   server hello message using an extension of type "cert_type".  Servers
-   that only support X.509 certificates MAY omit including the
-   "cert_type" extension in the extended server hello.
-
-3.3.  Server Certificate
-
-   The contents of the certificate message sent from server to client
-   and vice versa are determined by the negotiated certificate type and
-   the selected cipher suite's key exchange algorithm.
-
-   If the OpenPGP certificate type is negotiated, then it is required to
-   present an OpenPGP certificate in the certificate message.  The
-   certificate must contain a public key that matches the selected key
-   exchange algorithm, as shown below.
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 3]
-
-RFC 5081                   Using OpenPGP Keys              November 2007
-
-
-      Key Exchange Algorithm  OpenPGP Certificate Type
-
-      RSA                     RSA public key that can be used for
-                              encryption.
-
-      DHE_DSS                 DSS public key that can be used for
-                              authentication.
-
-      DHE_RSA                 RSA public key that can be used for
-                              authentication.
-
-   An OpenPGP certificate appearing in the certificate message is sent
-   using the binary OpenPGP format.  The certificate MUST contain all
-   the elements required by Section 11.1 of [OpenPGP].
-
-   The option is also available to send an OpenPGP fingerprint, instead
-   of sending the entire certificate.  The process of fingerprint
-   generation is described in Section 12.2 of [OpenPGP].  The peer shall
-   respond with a "certificate_unobtainable" fatal alert if the
-   certificate with the given fingerprint cannot be found.  The
-   "certificate_unobtainable" fatal alert is defined in Section 4 of
-   [TLSEXT].
-
-      enum {
-           cert_fingerprint (0), cert (1), (255)
-      } OpenPGPCertDescriptorType;
-
-      opaque OpenPGPCertFingerprint<16..20>;
-
-      opaque OpenPGPCert<0..2^24-1>;
-
-      struct {
-           OpenPGPCertDescriptorType descriptorType;
-           select (descriptorType) {
-                case cert_fingerprint: OpenPGPCertFingerprint;
-                case cert: OpenPGPCert;
-           }
-      } Certificate;
-
-3.4.  Certificate Request
-
-   The semantics of this message remain the same as in the TLS
-   specification.  However, if this message is sent, and the negotiated
-   certificate type is OpenPGP, the "certificate_authorities" list MUST
-   be empty.
-
-
-
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 4]
-
-RFC 5081                   Using OpenPGP Keys              November 2007
-
-
-3.5.  Client Certificate
-
-   This message is only sent in response to the certificate request
-   message.  The client certificate message is sent using the same
-   formatting as the server certificate message, and it is also required
-   to present a certificate that matches the negotiated certificate
-   type.  If OpenPGP certificates have been selected and no certificate
-   is available from the client, then a certificate structure that
-   contains an empty OpenPGPCert vector MUST be sent.  The server SHOULD
-   respond with a "handshake_failure" fatal alert if client
-   authentication is required.
-
-3.6.  Other Handshake Messages
-
-   All the other handshake messages are identical to the TLS
-   specification.
-
-4.  Security Considerations
-
-   All security considerations discussed in [TLS], [TLSEXT], and
-   [OpenPGP] apply to this document.  Considerations about the use of
-   the web of trust or identity and certificate verification procedure
-   are outside the scope of this document.  These are considered issues
-   to be handled by the application layer protocols.
-
-   The protocol for certificate type negotiation is identical in
-   operation to ciphersuite negotiation of the [TLS] specification with
-   the addition of default values when the extension is omitted.  Since
-   those omissions have a unique meaning and the same protection is
-   applied to the values as with ciphersuites, it is believed that the
-   security properties of this negotiation are the same as with
-   ciphersuite negotiation.
-
-   When using OpenPGP fingerprints instead of the full certificates, the
-   discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs"
-   applies, especially when external servers are used to retrieve keys.
-   However, a major difference is that although the
-   "client_certificate_url" extension allows identifying certificates
-   without including the certificate hashes, this is not possible in the
-   protocol proposed here.  In this protocol, the certificates, when not
-   sent, are always identified by their fingerprint, which serves as a
-   cryptographic hash of the certificate (see Section 12.2 of
-   [OpenPGP]).
-
-   The information that is available to participating parties and
-   eavesdroppers (when confidentiality is not available through a
-   previous handshake) is the number and the types of certificates they
-   hold, plus the contents of certificates.
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 5]
-
-RFC 5081                   Using OpenPGP Keys              November 2007
-
-
-5.  IANA Considerations
-
-   This document defines a new TLS extension, "cert_type", assigned a
-   value of 9 from the TLS ExtensionType registry defined in [TLSEXT].
-   This value is used as the extension number for the extensions in both
-   the client hello message and the server hello message.  The new
-   extension type is used for certificate type negotiation.
-
-   The "cert_type" extension contains an 8-bit CertificateType field,
-   for which a new registry, named "TLS Certificate Types", is
-   established in this document, to be maintained by IANA.  The registry
-   is segmented in the following way:
-
-   1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
-
-   2.  Values from 2 through 223 decimal inclusive are assigned via IETF
-       Consensus [RFC2434].
-
-   3.  Values from 224 decimal through 255 decimal inclusive are
-       reserved for Private Use [RFC2434].
-
-6.  Acknowledgements
-
-   This document was based on earlier work made by Will Price and
-   Michael Elkins.
-
-   The author wishes to thank Werner Koch, David Taylor, Timo Schulz,
-   Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie
-   Orman for their suggestions on improving this document.
-
-7.  References
-
-7.1.  Normative References
-
-   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
-              1.1", RFC 4346, April 2006.
-
-   [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R.
-              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
-
-   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", RFC 2434,
-              October 1998.
-
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 6]
-
-RFC 5081                   Using OpenPGP Keys              November 2007
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, March 1997.
-
-7.2.  Informative References
-
-   [PKIX]     Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-Author's Address
-
-   Nikos Mavrogiannopoulos
-   Independent
-   Arkadias 8
-   Halandri, Attiki  15234
-   Greece
-
-   EMail: nmav@gnutls.org
-   URI:   http://www.gnutls.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 7]
-
-RFC 5081                   Using OpenPGP Keys              November 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Mavrogiannopoulos             Experimental                      [Page 8]
-
diff --git a/doc/protocol/rfc5246.txt b/doc/protocol/rfc5246.txt
deleted file mode 100644
index 869c345054..0000000000
--- a/doc/protocol/rfc5246.txt
+++ /dev/null
@@ -1,5827 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          T. Dierks
-Request for Comments: 5246                                   Independent
-Obsoletes: 3268, 4346, 4366                                  E. Rescorla
-Updates: 4492                                                 RTFM, Inc.
-Category: Standards Track                                    August 2008
-
-
-              The Transport Layer Security (TLS) Protocol
-                              Version 1.2
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document specifies Version 1.2 of the Transport Layer Security
-   (TLS) protocol.  The TLS protocol provides communications security
-   over the Internet.  The protocol allows client/server applications to
-   communicate in a way that is designed to prevent eavesdropping,
-   tampering, or message forgery.
-
-Table of Contents
-
-   1. Introduction ....................................................4
-      1.1. Requirements Terminology ...................................5
-      1.2. Major Differences from TLS 1.1 .............................5
-   2. Goals ...........................................................6
-   3. Goals of This Document ..........................................7
-   4. Presentation Language ...........................................7
-      4.1. Basic Block Size ...........................................7
-      4.2. Miscellaneous ..............................................8
-      4.3. Vectors ....................................................8
-      4.4. Numbers ....................................................9
-      4.5. Enumerateds ................................................9
-      4.6. Constructed Types .........................................10
-           4.6.1. Variants ...........................................10
-      4.7. Cryptographic Attributes ..................................12
-      4.8. Constants .................................................14
-   5. HMAC and the Pseudorandom Function .............................14
-   6. The TLS Record Protocol ........................................15
-      6.1. Connection States .........................................16
-      6.2. Record Layer ..............................................19
-           6.2.1. Fragmentation ......................................19
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 1]
-
-RFC 5246                          TLS                        August 2008
-
-
-           6.2.2. Record Compression and Decompression ...............20
-           6.2.3. Record Payload Protection ..........................21
-                  6.2.3.1. Null or Standard Stream Cipher ............22
-                  6.2.3.2. CBC Block Cipher ..........................22
-                  6.2.3.3. AEAD Ciphers ..............................24
-      6.3. Key Calculation ...........................................25
-   7. The TLS Handshaking Protocols ..................................26
-      7.1. Change Cipher Spec Protocol ...............................27
-      7.2. Alert Protocol ............................................28
-           7.2.1. Closure Alerts .....................................29
-           7.2.2. Error Alerts .......................................30
-      7.3. Handshake Protocol Overview ...............................33
-      7.4. Handshake Protocol ........................................37
-           7.4.1. Hello Messages .....................................38
-                  7.4.1.1. Hello Request .............................38
-                  7.4.1.2. Client Hello ..............................39
-                  7.4.1.3. Server Hello ..............................42
-                  7.4.1.4. Hello Extensions ..........................44
-                           7.4.1.4.1. Signature Algorithms ...........45
-           7.4.2. Server Certificate .................................47
-           7.4.3. Server Key Exchange Message ........................50
-           7.4.4. Certificate Request ................................53
-           7.4.5. Server Hello Done ..................................55
-           7.4.6. Client Certificate .................................55
-           7.4.7. Client Key Exchange Message ........................57
-                  7.4.7.1. RSA-Encrypted Premaster Secret Message ....58
-                  7.4.7.2. Client Diffie-Hellman Public Value ........61
-           7.4.8. Certificate Verify .................................62
-           7.4.9. Finished ...........................................63
-   8. Cryptographic Computations .....................................64
-      8.1. Computing the Master Secret ...............................64
-           8.1.1. RSA ................................................65
-           8.1.2. Diffie-Hellman .....................................65
-   9. Mandatory Cipher Suites ........................................65
-   10. Application Data Protocol .....................................65
-   11. Security Considerations .......................................65
-   12. IANA Considerations ...........................................65
-   Appendix A. Protocol Data Structures and Constant Values ..........68
-      A.1. Record Layer ..............................................68
-      A.2. Change Cipher Specs Message ...............................69
-      A.3. Alert Messages ............................................69
-      A.4. Handshake Protocol ........................................70
-           A.4.1. Hello Messages .....................................71
-           A.4.2. Server Authentication and Key Exchange Messages ....72
-           A.4.3. Client Authentication and Key Exchange Messages ....74
-           A.4.4. Handshake Finalization Message .....................74
-      A.5. The Cipher Suite ..........................................75
-      A.6. The Security Parameters ...................................77
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 2]
-
-RFC 5246                          TLS                        August 2008
-
-
-      A.7. Changes to RFC 4492 .......................................78
-   Appendix B. Glossary ..............................................78
-   Appendix C. Cipher Suite Definitions ..............................83
-   Appendix D. Implementation Notes ..................................85
-      D.1. Random Number Generation and Seeding ......................85
-      D.2. Certificates and Authentication ...........................85
-      D.3. Cipher Suites .............................................85
-      D.4. Implementation Pitfalls ...................................85
-   Appendix E. Backward Compatibility ................................87
-      E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87
-      E.2. Compatibility with SSL 2.0 ................................88
-      E.3. Avoiding Man-in-the-Middle Version Rollback ...............90
-   Appendix F. Security Analysis .....................................91
-      F.1. Handshake Protocol ........................................91
-           F.1.1. Authentication and Key Exchange ....................91
-                  F.1.1.1. Anonymous Key Exchange ....................91
-                  F.1.1.2. RSA Key Exchange and Authentication .......92
-                  F.1.1.3. Diffie-Hellman Key Exchange with
-                           Authentication ............................92
-           F.1.2. Version Rollback Attacks ...........................93
-           F.1.3. Detecting Attacks Against the Handshake Protocol ...94
-           F.1.4. Resuming Sessions ..................................94
-      F.2. Protecting Application Data ...............................94
-      F.3. Explicit IVs ..............................................95
-      F.4. Security of Composite Cipher Modes ........................95
-      F.5. Denial of Service .........................................96
-      F.6. Final Notes ...............................................96
-   Normative References ..............................................97
-   Informative References ............................................98
-   Working Group Information ........................................101
-   Contributors .....................................................101
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 3]
-
-RFC 5246                          TLS                        August 2008
-
-
-1.  Introduction
-
-   The primary goal of the TLS protocol is to provide privacy and data
-   integrity between two communicating applications.  The protocol is
-   composed of two layers: the TLS Record Protocol and the TLS Handshake
-   Protocol.  At the lowest level, layered on top of some reliable
-   transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol.
-   The TLS Record Protocol provides connection security that has two
-   basic properties:
-
-   -  The connection is private.  Symmetric cryptography is used for
-      data encryption (e.g., AES [AES], RC4 [SCH], etc.).  The keys for
-      this symmetric encryption are generated uniquely for each
-      connection and are based on a secret negotiated by another
-      protocol (such as the TLS Handshake Protocol).  The Record
-      Protocol can also be used without encryption.
-
-   -  The connection is reliable.  Message transport includes a message
-      integrity check using a keyed MAC.  Secure hash functions (e.g.,
-      SHA-1, etc.) are used for MAC computations.  The Record Protocol
-      can operate without a MAC, but is generally only used in this mode
-      while another protocol is using the Record Protocol as a transport
-      for negotiating security parameters.
-
-   The TLS Record Protocol is used for encapsulation of various higher-
-   level protocols.  One such encapsulated protocol, the TLS Handshake
-   Protocol, allows the server and client to authenticate each other and
-   to negotiate an encryption algorithm and cryptographic keys before
-   the application protocol transmits or receives its first byte of
-   data.  The TLS Handshake Protocol provides connection security that
-   has three basic properties:
-
-   -  The peer's identity can be authenticated using asymmetric, or
-      public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.).  This
-      authentication can be made optional, but is generally required for
-      at least one of the peers.
-
-   -  The negotiation of a shared secret is secure: the negotiated
-      secret is unavailable to eavesdroppers, and for any authenticated
-      connection the secret cannot be obtained, even by an attacker who
-      can place himself in the middle of the connection.
-
-   -  The negotiation is reliable: no attacker can modify the
-      negotiation communication without being detected by the parties to
-      the communication.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 4]
-
-RFC 5246                          TLS                        August 2008
-
-
-   One advantage of TLS is that it is application protocol independent.
-   Higher-level protocols can layer on top of the TLS protocol
-   transparently.  The TLS standard, however, does not specify how
-   protocols add security with TLS; the decisions on how to initiate TLS
-   handshaking and how to interpret the authentication certificates
-   exchanged are left to the judgment of the designers and implementors
-   of protocols that run on top of TLS.
-
-1.1.  Requirements Terminology
-
-   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 [REQ].
-
-1.2.  Major Differences from TLS 1.1
-
-   This document is a revision of the TLS 1.1 [TLS1.1] protocol which
-   contains improved flexibility, particularly for negotiation of
-   cryptographic algorithms.  The major changes are:
-
-   -  The MD5/SHA-1 combination in the pseudorandom function (PRF) has
-      been replaced with cipher-suite-specified PRFs.  All cipher suites
-      in this document use P_SHA256.
-
-   -  The MD5/SHA-1 combination in the digitally-signed element has been
-      replaced with a single hash.  Signed elements now include a field
-      that explicitly specifies the hash algorithm used.
-
-   -  Substantial cleanup to the client's and server's ability to
-      specify which hash and signature algorithms they will accept.
-      Note that this also relaxes some of the constraints on signature
-      and hash algorithms from previous versions of TLS.
-
-   -  Addition of support for authenticated encryption with additional
-      data modes.
-
-   -  TLS Extensions definition and AES Cipher Suites were merged in
-      from external [TLSEXT] and [TLSAES].
-
-   -  Tighter checking of EncryptedPreMasterSecret version numbers.
-
-   -  Tightened up a number of requirements.
-
-   -  Verify_data length now depends on the cipher suite (default is
-      still 12).
-
-   -  Cleaned up description of Bleichenbacher/Klima attack defenses.
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 5]
-
-RFC 5246                          TLS                        August 2008
-
-
-   -  Alerts MUST now be sent in many cases.
-
-   -  After a certificate_request, if no certificates are available,
-      clients now MUST send an empty certificate list.
-
-   -  TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement
-      cipher suite.
-
-   -  Added HMAC-SHA256 cipher suites.
-
-   -  Removed IDEA and DES cipher suites.  They are now deprecated and
-      will be documented in a separate document.
-
-   -  Support for the SSLv2 backward-compatible hello is now a MAY, not
-      a SHOULD, with sending it a SHOULD NOT.  Support will probably
-      become a SHOULD NOT in the future.
-
-   -  Added limited "fall-through" to the presentation language to allow
-      multiple case arms to have the same encoding.
-
-   -  Added an Implementation Pitfalls sections
-
-   -  The usual clarifications and editorial work.
-
-2.  Goals
-
-   The goals of the TLS protocol, in order of priority, are as follows:
-
-   1. Cryptographic security: TLS should be used to establish a secure
-      connection between two parties.
-
-   2. Interoperability: Independent programmers should be able to
-      develop applications utilizing TLS that can successfully exchange
-      cryptographic parameters without knowledge of one another's code.
-
-   3. Extensibility: TLS seeks to provide a framework into which new
-      public key and bulk encryption methods can be incorporated as
-      necessary.  This will also accomplish two sub-goals: preventing
-      the need to create a new protocol (and risking the introduction of
-      possible new weaknesses) and avoiding the need to implement an
-      entire new security library.
-
-   4. Relative efficiency: Cryptographic operations tend to be highly
-      CPU intensive, particularly public key operations.  For this
-      reason, the TLS protocol has incorporated an optional session
-      caching scheme to reduce the number of connections that need to be
-      established from scratch.  Additionally, care has been taken to
-      reduce network activity.
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 6]
-
-RFC 5246                          TLS                        August 2008
-
-
-3.  Goals of This Document
-
-   This document and the TLS protocol itself are based on the SSL 3.0
-   Protocol Specification as published by Netscape.  The differences
-   between this protocol and SSL 3.0 are not dramatic, but they are
-   significant enough that the various versions of TLS and SSL 3.0 do
-   not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down to prior versions).  This
-   document is intended primarily for readers who will be implementing
-   the protocol and for those doing cryptographic analysis of it.  The
-   specification has been written with this in mind, and it is intended
-   to reflect the needs of those two groups.  For that reason, many of
-   the algorithm-dependent data structures and rules are included in the
-   body of the text (as opposed to in an appendix), providing easier
-   access to them.
-
-   This document is not intended to supply any details of service
-   definition or of interface definition, although it does cover select
-   areas of policy as they are required for the maintenance of solid
-   security.
-
-4.  Presentation Language
-
-   This document deals with the formatting of data in an external
-   representation.  The following very basic and somewhat casually
-   defined presentation syntax will be used.  The syntax draws from
-   several sources in its structure.  Although it resembles the
-   programming language "C" in its syntax and XDR [XDR] in both its
-   syntax and intent, it would be risky to draw too many parallels.  The
-   purpose of this presentation language is to document TLS only; it has
-   no general application beyond that particular goal.
-
-4.1.  Basic Block Size
-
-   The representation of all data items is explicitly specified.  The
-   basic data block size is one byte (i.e., 8 bits).  Multiple byte data
-   items are concatenations of bytes, from left to right, from top to
-   bottom.  From the byte stream, a multi-byte item (a numeric in the
-   example) is formed (using C notation) by:
-
-      value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
-              ... | byte[n-1];
-
-   This byte ordering for multi-byte values is the commonplace network
-   byte order or big-endian format.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 7]
-
-RFC 5246                          TLS                        August 2008
-
-
-4.2.  Miscellaneous
-
-   Comments begin with "/*" and end with "*/".
-
-   Optional components are denoted by enclosing them in "[[ ]]" double
-   brackets.
-
-   Single-byte entities containing uninterpreted data are of type
-   opaque.
-
-4.3.  Vectors
-
-   A vector (single-dimensioned array) is a stream of homogeneous data
-   elements.  The size of the vector may be specified at documentation
-   time or left unspecified until runtime.  In either case, the length
-   declares the number of bytes, not the number of elements, in the
-   vector.  The syntax for specifying a new type, T', that is a fixed-
-   length vector of type T is
-
-      T T'[n];
-
-   Here, T' occupies n bytes in the data stream, where n is a multiple
-   of the size of T.  The length of the vector is not included in the
-   encoded stream.
-
-   In the following example, Datum is defined to be three consecutive
-   bytes that the protocol does not interpret, while Data is three
-   consecutive Datum, consuming a total of nine bytes.
-
-      opaque Datum[3];      /* three uninterpreted bytes */
-      Datum Data[9];        /* 3 consecutive 3 byte vectors */
-
-   Variable-length vectors are defined by specifying a subrange of legal
-   lengths, inclusively, using the notation <floor..ceiling>.  When
-   these are encoded, the actual length precedes the vector's contents
-   in the byte stream.  The length will be in the form of a number
-   consuming as many bytes as required to hold the vector's specified
-   maximum (ceiling) length.  A variable-length vector with an actual
-   length field of zero is referred to as an empty vector.
-
-      T T'<floor..ceiling>;
-
-   In the following example, mandatory is a vector that must contain
-   between 300 and 400 bytes of type opaque.  It can never be empty.
-   The actual length field consumes two bytes, a uint16, which is
-   sufficient to represent the value 400 (see Section 4.4).  On the
-   other hand, longer can represent up to 800 bytes of data, or 400
-   uint16 elements, and it may be empty.  Its encoding will include a
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 8]
-
-RFC 5246                          TLS                        August 2008
-
-
-   two-byte actual length field prepended to the vector.  The length of
-   an encoded vector must be an even multiple of the length of a single
-   element (for example, a 17-byte vector of uint16 would be illegal).
-
-      opaque mandatory<300..400>;
-            /* length field is 2 bytes, cannot be empty */
-      uint16 longer<0..800>;
-            /* zero to 400 16-bit unsigned integers */
-
-4.4.  Numbers
-
-   The basic numeric data type is an unsigned byte (uint8).  All larger
-   numeric data types are formed from fixed-length series of bytes
-   concatenated as described in Section 4.1 and are also unsigned.  The
-   following numeric types are predefined.
-
-      uint8 uint16[2];
-      uint8 uint24[3];
-      uint8 uint32[4];
-      uint8 uint64[8];
-
-   All values, here and elsewhere in the specification, are stored in
-   network byte (big-endian) order; the uint32 represented by the hex
-   bytes 01 02 03 04 is equivalent to the decimal value 16909060.
-
-   Note that in some cases (e.g., DH parameters) it is necessary to
-   represent integers as opaque vectors.  In such cases, they are
-   represented as unsigned integers (i.e., leading zero octets are not
-   required even if the most significant bit is set).
-
-4.5.  Enumerateds
-
-   An additional sparse data type is available called enum.  A field of
-   type enum can only assume the values declared in the definition.
-   Each definition is a different type.  Only enumerateds of the same
-   type may be assigned or compared.  Every element of an enumerated
-   must be assigned a value, as demonstrated in the following example.
-   Since the elements of the enumerated are not ordered, they can be
-   assigned any unique value, in any order.
-
-      enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
-
-   An enumerated occupies as much space in the byte stream as would its
-   maximal defined ordinal value.  The following definition would cause
-   one byte to be used to carry fields of type Color.
-
-      enum { red(3), blue(5), white(7) } Color;
-
-
-
-
-Dierks & Rescorla           Standards Track                     [Page 9]
-
-RFC 5246                          TLS                        August 2008
-
-
-   One may optionally specify a value without its associated tag to
-   force the width definition without defining a superfluous element.
-
-   In the following example, Taste will consume two bytes in the data
-   stream but can only assume the values 1, 2, or 4.
-
-      enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
-
-   The names of the elements of an enumeration are scoped within the
-   defined type.  In the first example, a fully qualified reference to
-   the second element of the enumeration would be Color.blue.  Such
-   qualification is not required if the target of the assignment is well
-   specified.
-
-      Color color = Color.blue;     /* overspecified, legal */
-      Color color = blue;           /* correct, type implicit */
-
-   For enumerateds that are never converted to external representation,
-   the numerical information may be omitted.
-
-      enum { low, medium, high } Amount;
-
-4.6.  Constructed Types
-
-   Structure types may be constructed from primitive types for
-   convenience.  Each specification declares a new, unique type.  The
-   syntax for definition is much like that of C.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ...
-          Tn fn;
-      } [[T]];
-
-   The fields within a structure may be qualified using the type's name,
-   with a syntax much like that available for enumerateds.  For example,
-   T.f2 refers to the second field of the previous declaration.
-   Structure definitions may be embedded.
-
-4.6.1.  Variants
-
-   Defined structures may have variants based on some knowledge that is
-   available within the environment.  The selector must be an enumerated
-   type that defines the possible variants the structure defines.  There
-   must be a case arm for every element of the enumeration declared in
-   the select.  Case arms have limited fall-through: if two case arms
-   follow in immediate succession with no fields in between, then they
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 10]
-
-RFC 5246                          TLS                        August 2008
-
-
-   both contain the same fields.  Thus, in the example below, "orange"
-   and "banana" both contain V2.  Note that this is a new piece of
-   syntax in TLS 1.2.
-
-   The body of the variant structure may be given a label for reference.
-   The mechanism by which the variant is selected at runtime is not
-   prescribed by the presentation language.
-
-      struct {
-          T1 f1;
-          T2 f2;
-          ....
-          Tn fn;
-           select (E) {
-               case e1: Te1;
-               case e2: Te2;
-               case e3: case e4: Te3;
-               ....
-               case en: Ten;
-           } [[fv]];
-      } [[Tv]];
-
-   For example:
-
-      enum { apple, orange, banana } VariantTag;
-
-      struct {
-          uint16 number;
-          opaque string<0..10>; /* variable length */
-      } V1;
-
-      struct {
-          uint32 number;
-          opaque string[10];    /* fixed length */
-      } V2;
-
-      struct {
-          select (VariantTag) { /* value of selector is implicit */
-              case apple:
-                V1;   /* VariantBody, tag = apple */
-              case orange:
-              case banana:
-                V2;   /* VariantBody, tag = orange or banana */
-          } variant_body;       /* optional label on variant */
-      } VariantRecord;
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 11]
-
-RFC 5246                          TLS                        August 2008
-
-
-4.7.  Cryptographic Attributes
-
-   The five cryptographic operations -- digital signing, stream cipher
-   encryption, block cipher encryption, authenticated encryption with
-   additional data (AEAD) encryption, and public key encryption -- are
-   designated digitally-signed, stream-ciphered, block-ciphered, aead-
-   ciphered, and public-key-encrypted, respectively.  A field's
-   cryptographic processing is specified by prepending an appropriate
-   key word designation before the field's type specification.
-   Cryptographic keys are implied by the current session state (see
-   Section 6.1).
-
-   A digitally-signed element is encoded as a struct DigitallySigned:
-
-      struct {
-         SignatureAndHashAlgorithm algorithm;
-         opaque signature<0..2^16-1>;
-      } DigitallySigned;
-
-   The algorithm field specifies the algorithm used (see Section
-   7.4.1.4.1 for the definition of this field).  Note that the
-   introduction of the algorithm field is a change from previous
-   versions.  The signature is a digital signature using those
-   algorithms over the contents of the element.  The contents themselves
-   do not appear on the wire but are simply calculated.  The length of
-   the signature is specified by the signing algorithm and key.
-
-   In RSA signing, the opaque vector contains the signature generated
-   using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1].  As
-   discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680]
-   [X690].  For hash algorithms without parameters (which includes
-   SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be
-   NULL, but implementations MUST accept both without parameters and
-   with NULL parameters.  Note that earlier versions of TLS used a
-   different RSA signature scheme that did not include a DigestInfo
-   encoding.
-
-   In DSA, the 20 bytes of the SHA-1 hash are run directly through the
-   Digital Signing Algorithm with no additional hashing.  This produces
-   two values, r and s.  The DSA signature is an opaque vector, as
-   above, the contents of which are the DER encoding of:
-
-      Dss-Sig-Value ::= SEQUENCE {
-          r INTEGER,
-          s INTEGER
-      }
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 12]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Note: In current terminology, DSA refers to the Digital Signature
-   Algorithm and DSS refers to the NIST standard.  In the original SSL
-   and TLS specs, "DSS" was used universally.  This document uses "DSA"
-   to refer to the algorithm, "DSS" to refer to the standard, and it
-   uses "DSS" in the code point definitions for historical continuity.
-
-   In stream cipher encryption, the plaintext is exclusive-ORed with an
-   identical amount of output generated from a cryptographically secure
-   keyed pseudorandom number generator.
-
-   In block cipher encryption, every block of plaintext encrypts to a
-   block of ciphertext.  All block cipher encryption is done in CBC
-   (Cipher Block Chaining) mode, and all items that are block-ciphered
-   will be an exact multiple of the cipher block length.
-
-   In AEAD encryption, the plaintext is simultaneously encrypted and
-   integrity protected.  The input may be of any length, and aead-
-   ciphered output is generally larger than the input in order to
-   accommodate the integrity check value.
-
-   In public key encryption, a public key algorithm is used to encrypt
-   data in such a way that it can be decrypted only with the matching
-   private key.  A public-key-encrypted element is encoded as an opaque
-   vector <0..2^16-1>, where the length is specified by the encryption
-   algorithm and key.
-
-   RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme
-   defined in [PKCS1].
-
-   In the following example
-
-      stream-ciphered struct {
-          uint8 field1;
-          uint8 field2;
-          digitally-signed opaque {
-            uint8 field3<0..255>;
-            uint8 field4;
-          };
-      } UserType;
-
-   The contents of the inner struct (field3 and field4) are used as
-   input for the signature/hash algorithm, and then the entire structure
-   is encrypted with a stream cipher.  The length of this structure, in
-   bytes, would be equal to two bytes for field1 and field2, plus two
-   bytes for the signature and hash algorithm, plus two bytes for the
-   length of the signature, plus the length of the output of the signing
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 13]
-
-RFC 5246                          TLS                        August 2008
-
-
-   algorithm.  The length of the signature is known because the
-   algorithm and key used for the signing are known prior to encoding or
-   decoding this structure.
-
-4.8.  Constants
-
-   Typed constants can be defined for purposes of specification by
-   declaring a symbol of the desired type and assigning values to it.
-
-   Under-specified types (opaque, variable-length vectors, and
-   structures that contain opaque) cannot be assigned values.  No fields
-   of a multi-element structure or vector may be elided.
-
-   For example:
-
-      struct {
-          uint8 f1;
-          uint8 f2;
-      } Example1;
-
-      Example1 ex1 = {1, 4};  /* assigns f1 = 1, f2 = 4 */
-
-5.  HMAC and the Pseudorandom Function
-
-   The TLS record layer uses a keyed Message Authentication Code (MAC)
-   to protect message integrity.  The cipher suites defined in this
-   document use a construction known as HMAC, described in [HMAC], which
-   is based on a hash function.  Other cipher suites MAY define their
-   own MAC constructions, if needed.
-
-   In addition, a construction is required to do expansion of secrets
-   into blocks of data for the purposes of key generation or validation.
-   This pseudorandom function (PRF) takes as input a secret, a seed, and
-   an identifying label and produces an output of arbitrary length.
-
-   In this section, we define one PRF, based on HMAC.  This PRF with the
-   SHA-256 hash function is used for all cipher suites defined in this
-   document and in TLS documents published prior to this document when
-   TLS 1.2 is negotiated.  New cipher suites MUST explicitly specify a
-   PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
-   stronger standard hash function.
-
-   First, we define a data expansion function, P_hash(secret, data),
-   that uses a single hash function to expand a secret and seed into an
-   arbitrary quantity of output:
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 14]
-
-RFC 5246                          TLS                        August 2008
-
-
-      P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
-                             HMAC_hash(secret, A(2) + seed) +
-                             HMAC_hash(secret, A(3) + seed) + ...
-
-   where + indicates concatenation.
-
-   A() is defined as:
-
-      A(0) = seed
-      A(i) = HMAC_hash(secret, A(i-1))
-
-   P_hash can be iterated as many times as necessary to produce the
-   required quantity of data.  For example, if P_SHA256 is being used to
-   create 80 bytes of data, it will have to be iterated three times
-   (through A(3)), creating 96 bytes of output data; the last 16 bytes
-   of the final iteration will then be discarded, leaving 80 bytes of
-   output data.
-
-   TLS's PRF is created by applying P_hash to the secret as:
-
-      PRF(secret, label, seed) = P_<hash>(secret, label + seed)
-
-   The label is an ASCII string.  It should be included in the exact
-   form it is given without a length byte or trailing null character.
-   For example, the label "slithy toves" would be processed by hashing
-   the following bytes:
-
-      73 6C 69 74 68 79 20 74 6F 76 65 73
-
-6.  The TLS Record Protocol
-
-   The TLS Record Protocol is a layered protocol.  At each layer,
-   messages may include fields for length, description, and content.
-   The Record Protocol takes messages to be transmitted, fragments the
-   data into manageable blocks, optionally compresses the data, applies
-   a MAC, encrypts, and transmits the result.  Received data is
-   decrypted, verified, decompressed, reassembled, and then delivered to
-   higher-level clients.
-
-   Four protocols that use the record protocol are described in this
-   document: the handshake protocol, the alert protocol, the change
-   cipher spec protocol, and the application data protocol.  In order to
-   allow extension of the TLS protocol, additional record content types
-   can be supported by the record protocol.  New record content type
-   values are assigned by IANA in the TLS Content Type Registry as
-   described in Section 12.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 15]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Implementations MUST NOT send record types not defined in this
-   document unless negotiated by some extension.  If a TLS
-   implementation receives an unexpected record type, it MUST send an
-   unexpected_message alert.
-
-   Any protocol designed for use over TLS must be carefully designed to
-   deal with all possible attacks against it.  As a practical matter,
-   this means that the protocol designer must be aware of what security
-   properties TLS does and does not provide and cannot safely rely on
-   the latter.
-
-   Note in particular that type and length of a record are not protected
-   by encryption.  If this information is itself sensitive, application
-   designers may wish to take steps (padding, cover traffic) to minimize
-   information leakage.
-
-6.1.  Connection States
-
-   A TLS connection state is the operating environment of the TLS Record
-   Protocol.  It specifies a compression algorithm, an encryption
-   algorithm, and a MAC algorithm.  In addition, the parameters for
-   these algorithms are known: the MAC key and the bulk encryption keys
-   for the connection in both the read and the write directions.
-   Logically, there are always four connection states outstanding: the
-   current read and write states, and the pending read and write states.
-   All records are processed under the current read and write states.
-   The security parameters for the pending states can be set by the TLS
-   Handshake Protocol, and the ChangeCipherSpec can selectively make
-   either of the pending states current, in which case the appropriate
-   current state is disposed of and replaced with the pending state; the
-   pending state is then reinitialized to an empty state.  It is illegal
-   to make a state that has not been initialized with security
-   parameters a current state.  The initial current state always
-   specifies that no encryption, compression, or MAC will be used.
-
-   The security parameters for a TLS Connection read and write state are
-   set by providing the following values:
-
-   connection end
-      Whether this entity is considered the "client" or the "server" in
-      this connection.
-
-   PRF algorithm
-      An algorithm used to generate keys from the master secret (see
-      Sections 5 and 6.3).
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 16]
-
-RFC 5246                          TLS                        August 2008
-
-
-   bulk encryption algorithm
-      An algorithm to be used for bulk encryption.  This specification
-      includes the key size of this algorithm, whether it is a block,
-      stream, or AEAD cipher, the block size of the cipher (if
-      appropriate), and the lengths of explicit and implicit
-      initialization vectors (or nonces).
-
-   MAC algorithm
-      An algorithm to be used for message authentication.  This
-      specification includes the size of the value returned by the MAC
-      algorithm.
-
-   compression algorithm
-      An algorithm to be used for data compression.  This specification
-      must include all information the algorithm requires to do
-      compression.
-
-   master secret
-      A 48-byte secret shared between the two peers in the connection.
-
-   client random
-      A 32-byte value provided by the client.
-
-   server random
-      A 32-byte value provided by the server.
-
-      These parameters are defined in the presentation language as:
-
-      enum { server, client } ConnectionEnd;
-
-      enum { tls_prf_sha256 } PRFAlgorithm;
-
-      enum { null, rc4, 3des, aes }
-        BulkCipherAlgorithm;
-
-      enum { stream, block, aead } CipherType;
-
-      enum { null, hmac_md5, hmac_sha1, hmac_sha256,
-           hmac_sha384, hmac_sha512} MACAlgorithm;
-
-      enum { null(0), (255) } CompressionMethod;
-
-      /* The algorithms specified in CompressionMethod, PRFAlgorithm,
-         BulkCipherAlgorithm, and MACAlgorithm may be added to. */
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 17]
-
-RFC 5246                          TLS                        August 2008
-
-
-      struct {
-          ConnectionEnd          entity;
-          PRFAlgorithm           prf_algorithm;
-          BulkCipherAlgorithm    bulk_cipher_algorithm;
-          CipherType             cipher_type;
-          uint8                  enc_key_length;
-          uint8                  block_length;
-          uint8                  fixed_iv_length;
-          uint8                  record_iv_length;
-          MACAlgorithm           mac_algorithm;
-          uint8                  mac_length;
-          uint8                  mac_key_length;
-          CompressionMethod      compression_algorithm;
-          opaque                 master_secret[48];
-          opaque                 client_random[32];
-          opaque                 server_random[32];
-      } SecurityParameters;
-
-   The record layer will use the security parameters to generate the
-   following six items (some of which are not required by all ciphers,
-   and are thus empty):
-
-      client write MAC key
-      server write MAC key
-      client write encryption key
-      server write encryption key
-      client write IV
-      server write IV
-
-   The client write parameters are used by the server when receiving and
-   processing records and vice versa.  The algorithm used for generating
-   these items from the security parameters is described in Section 6.3.
-
-   Once the security parameters have been set and the keys have been
-   generated, the connection states can be instantiated by making them
-   the current states.  These current states MUST be updated for each
-   record processed.  Each connection state includes the following
-   elements:
-
-   compression state
-      The current state of the compression algorithm.
-
-   cipher state
-      The current state of the encryption algorithm.  This will consist
-      of the scheduled key for that connection.  For stream ciphers,
-      this will also contain whatever state information is necessary to
-      allow the stream to continue to encrypt or decrypt data.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 18]
-
-RFC 5246                          TLS                        August 2008
-
-
-   MAC key
-      The MAC key for this connection, as generated above.
-
-   sequence number
-      Each connection state contains a sequence number, which is
-      maintained separately for read and write states.  The sequence
-      number MUST be set to zero whenever a connection state is made the
-      active state.  Sequence numbers are of type uint64 and may not
-      exceed 2^64-1.  Sequence numbers do not wrap.  If a TLS
-      implementation would need to wrap a sequence number, it must
-      renegotiate instead.  A sequence number is incremented after each
-      record: specifically, the first record transmitted under a
-      particular connection state MUST use sequence number 0.
-
-6.2.  Record Layer
-
-   The TLS record layer receives uninterpreted data from higher layers
-   in non-empty blocks of arbitrary size.
-
-6.2.1.  Fragmentation
-
-   The record layer fragments information blocks into TLSPlaintext
-   records carrying data in chunks of 2^14 bytes or less.  Client
-   message boundaries are not preserved in the record layer (i.e.,
-   multiple client messages of the same ContentType MAY be coalesced
-   into a single TLSPlaintext record, or a single message MAY be
-   fragmented across several records).
-
-      struct {
-          uint8 major;
-          uint8 minor;
-      } ProtocolVersion;
-
-      enum {
-          change_cipher_spec(20), alert(21), handshake(22),
-          application_data(23), (255)
-      } ContentType;
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          opaque fragment[TLSPlaintext.length];
-      } TLSPlaintext;
-
-   type
-      The higher-level protocol used to process the enclosed fragment.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 19]
-
-RFC 5246                          TLS                        August 2008
-
-
-   version
-      The version of the protocol being employed.  This document
-      describes TLS Version 1.2, which uses the version { 3, 3 }.  The
-      version value 3.3 is historical, deriving from the use of {3, 1}
-      for TLS 1.0.  (See Appendix A.1.)  Note that a client that
-      supports multiple versions of TLS may not know what version will
-      be employed before it receives the ServerHello.  See Appendix E
-      for discussion about what record layer version number should be
-      employed for ClientHello.
-
-   length
-      The length (in bytes) of the following TLSPlaintext.fragment.  The
-      length MUST NOT exceed 2^14.
-
-   fragment
-      The application data.  This data is transparent and treated as an
-      independent block to be dealt with by the higher-level protocol
-      specified by the type field.
-
-   Implementations MUST NOT send zero-length fragments of Handshake,
-   Alert, or ChangeCipherSpec content types.  Zero-length fragments of
-   Application data MAY be sent as they are potentially useful as a
-   traffic analysis countermeasure.
-
-   Note: Data of different TLS record layer content types MAY be
-   interleaved.  Application data is generally of lower precedence for
-   transmission than other content types.  However, records MUST be
-   delivered to the network in the same order as they are protected by
-   the record layer.  Recipients MUST receive and process interleaved
-   application layer traffic during handshakes subsequent to the first
-   one on a connection.
-
-6.2.2.  Record Compression and Decompression
-
-   All records are compressed using the compression algorithm defined in
-   the current session state.  There is always an active compression
-   algorithm; however, initially it is defined as
-   CompressionMethod.null.  The compression algorithm translates a
-   TLSPlaintext structure into a TLSCompressed structure.  Compression
-   functions are initialized with default state information whenever a
-   connection state is made active.  [RFC3749] describes compression
-   algorithms for TLS.
-
-   Compression must be lossless and may not increase the content length
-   by more than 1024 bytes.  If the decompression function encounters a
-   TLSCompressed.fragment that would decompress to a length in excess of
-   2^14 bytes, it MUST report a fatal decompression failure error.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 20]
-
-RFC 5246                          TLS                        August 2008
-
-
-      struct {
-          ContentType type;       /* same as TLSPlaintext.type */
-          ProtocolVersion version;/* same as TLSPlaintext.version */
-          uint16 length;
-          opaque fragment[TLSCompressed.length];
-      } TLSCompressed;
-
-   length
-      The length (in bytes) of the following TLSCompressed.fragment.
-      The length MUST NOT exceed 2^14 + 1024.
-
-   fragment
-      The compressed form of TLSPlaintext.fragment.
-
-      Note: A CompressionMethod.null operation is an identity operation;
-      no fields are altered.
-
-      Implementation note: Decompression functions are responsible for
-      ensuring that messages cannot cause internal buffer overflows.
-
-6.2.3.  Record Payload Protection
-
-      The encryption and MAC functions translate a TLSCompressed
-      structure into a TLSCiphertext.  The decryption functions reverse
-      the process.  The MAC of the record also includes a sequence
-      number so that missing, extra, or repeated messages are
-      detectable.
-
-      struct {
-          ContentType type;
-          ProtocolVersion version;
-          uint16 length;
-          select (SecurityParameters.cipher_type) {
-              case stream: GenericStreamCipher;
-              case block:  GenericBlockCipher;
-              case aead:   GenericAEADCipher;
-          } fragment;
-      } TLSCiphertext;
-
-   type
-      The type field is identical to TLSCompressed.type.
-
-   version
-      The version field is identical to TLSCompressed.version.
-
-   length
-      The length (in bytes) of the following TLSCiphertext.fragment.
-      The length MUST NOT exceed 2^14 + 2048.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 21]
-
-RFC 5246                          TLS                        August 2008
-
-
-   fragment
-      The encrypted form of TLSCompressed.fragment, with the MAC.
-
-6.2.3.1.  Null or Standard Stream Cipher
-
-   Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.6)
-   convert TLSCompressed.fragment structures to and from stream
-   TLSCiphertext.fragment structures.
-
-      stream-ciphered struct {
-          opaque content[TLSCompressed.length];
-          opaque MAC[SecurityParameters.mac_length];
-      } GenericStreamCipher;
-
-   The MAC is generated as:
-
-      MAC(MAC_write_key, seq_num +
-                            TLSCompressed.type +
-                            TLSCompressed.version +
-                            TLSCompressed.length +
-                            TLSCompressed.fragment);
-
-   where "+" denotes concatenation.
-
-   seq_num
-      The sequence number for this record.
-
-   MAC
-      The MAC algorithm specified by SecurityParameters.mac_algorithm.
-
-   Note that the MAC is computed before encryption.  The stream cipher
-   encrypts the entire block, including the MAC.  For stream ciphers
-   that do not use a synchronization vector (such as RC4), the stream
-   cipher state from the end of one record is simply used on the
-   subsequent packet.  If the cipher suite is TLS_NULL_WITH_NULL_NULL,
-   encryption consists of the identity operation (i.e., the data is not
-   encrypted, and the MAC size is zero, implying that no MAC is used).
-   For both null and stream ciphers, TLSCiphertext.length is
-   TLSCompressed.length plus SecurityParameters.mac_length.
-
-6.2.3.2.  CBC Block Cipher
-
-   For block ciphers (such as 3DES or AES), the encryption and MAC
-   functions convert TLSCompressed.fragment structures to and from block
-   TLSCiphertext.fragment structures.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 22]
-
-RFC 5246                          TLS                        August 2008
-
-
-      struct {
-          opaque IV[SecurityParameters.record_iv_length];
-          block-ciphered struct {
-              opaque content[TLSCompressed.length];
-              opaque MAC[SecurityParameters.mac_length];
-              uint8 padding[GenericBlockCipher.padding_length];
-              uint8 padding_length;
-          };
-      } GenericBlockCipher;
-
-   The MAC is generated as described in Section 6.2.3.1.
-
-   IV
-      The Initialization Vector (IV) SHOULD be chosen at random, and
-      MUST be unpredictable.  Note that in versions of TLS prior to 1.1,
-      there was no IV field, and the last ciphertext block of the
-      previous record (the "CBC residue") was used as the IV.  This was
-      changed to prevent the attacks described in [CBCATT].  For block
-      ciphers, the IV length is of length
-      SecurityParameters.record_iv_length, which is equal to the
-      SecurityParameters.block_size.
-
-   padding
-      Padding that is added to force the length of the plaintext to be
-      an integral multiple of the block cipher's block length.  The
-      padding MAY be any length up to 255 bytes, as long as it results
-      in the TLSCiphertext.length being an integral multiple of the
-      block length.  Lengths longer than necessary might be desirable to
-      frustrate attacks on a protocol that are based on analysis of the
-      lengths of exchanged messages.  Each uint8 in the padding data
-      vector MUST be filled with the padding length value.  The receiver
-      MUST check this padding and MUST use the bad_record_mac alert to
-      indicate padding errors.
-
-   padding_length
-      The padding length MUST be such that the total size of the
-      GenericBlockCipher structure is a multiple of the cipher's block
-      length.  Legal values range from zero to 255, inclusive.  This
-      length specifies the length of the padding field exclusive of the
-      padding_length field itself.
-
-   The encrypted data length (TLSCiphertext.length) is one more than the
-   sum of SecurityParameters.block_length, TLSCompressed.length,
-   SecurityParameters.mac_length, and padding_length.
-
-   Example: If the block length is 8 bytes, the content length
-   (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,
-   then the length before padding is 82 bytes (this does not include the
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 23]
-
-RFC 5246                          TLS                        August 2008
-
-
-   IV.  Thus, the padding length modulo 8 must be equal to 6 in order to
-   make the total length an even multiple of 8 bytes (the block length).
-   The padding length can be 6, 14, 22, and so on, through 254.  If the
-   padding length were the minimum necessary, 6, the padding would be 6
-   bytes, each containing the value 6.  Thus, the last 8 octets of the
-   GenericBlockCipher before block encryption would be xx 06 06 06 06 06
-   06 06, where xx is the last octet of the MAC.
-
-   Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
-   critical that the entire plaintext of the record be known before any
-   ciphertext is transmitted.  Otherwise, it is possible for the
-   attacker to mount the attack described in [CBCATT].
-
-   Implementation note: Canvel et al. [CBCTIME] have demonstrated a
-   timing attack on CBC padding based on the time required to compute
-   the MAC.  In order to defend against this attack, implementations
-   MUST ensure that record processing time is essentially the same
-   whether or not the padding is correct.  In general, the best way to
-   do this is to compute the MAC even if the padding is incorrect, and
-   only then reject the packet.  For instance, if the pad appears to be
-   incorrect, the implementation might assume a zero-length pad and then
-   compute the MAC.  This leaves a small timing channel, since MAC
-   performance depends to some extent on the size of the data fragment,
-   but it is not believed to be large enough to be exploitable, due to
-   the large block size of existing MACs and the small size of the
-   timing signal.
-
-6.2.3.3.  AEAD Ciphers
-
-   For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function
-   converts TLSCompressed.fragment structures to and from AEAD
-   TLSCiphertext.fragment structures.
-
-      struct {
-         opaque nonce_explicit[SecurityParameters.record_iv_length];
-         aead-ciphered struct {
-             opaque content[TLSCompressed.length];
-         };
-      } GenericAEADCipher;
-
-   AEAD ciphers take as input a single key, a nonce, a plaintext, and
-   "additional data" to be included in the authentication check, as
-   described in Section 2.1 of [AEAD].  The key is either the
-   client_write_key or the server_write_key.  No MAC key is used.
-
-   Each AEAD cipher suite MUST specify how the nonce supplied to the
-   AEAD operation is constructed, and what is the length of the
-   GenericAEADCipher.nonce_explicit part.  In many cases, it is
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 24]
-
-RFC 5246                          TLS                        August 2008
-
-
-   appropriate to use the partially implicit nonce technique described
-   in Section 3.2.1 of [AEAD]; with record_iv_length being the length of
-   the explicit part.  In this case, the implicit part SHOULD be derived
-   from key_block as client_write_iv and server_write_iv (as described
-   in Section 6.3), and the explicit part is included in
-   GenericAEAEDCipher.nonce_explicit.
-
-   The plaintext is the TLSCompressed.fragment.
-
-   The additional authenticated data, which we denote as
-   additional_data, is defined as follows:
-
-      additional_data = seq_num + TLSCompressed.type +
-                        TLSCompressed.version + TLSCompressed.length;
-
-   where "+" denotes concatenation.
-
-   The aead_output consists of the ciphertext output by the AEAD
-   encryption operation.  The length will generally be larger than
-   TLSCompressed.length, but by an amount that varies with the AEAD
-   cipher.  Since the ciphers might incorporate padding, the amount of
-   overhead could vary with different TLSCompressed.length values.  Each
-   AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.
-   Symbolically,
-
-      AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext,
-                                   additional_data)
-
-   In order to decrypt and verify, the cipher takes as input the key,
-   nonce, the "additional_data", and the AEADEncrypted value.  The
-   output is either the plaintext or an error indicating that the
-   decryption failed.  There is no separate integrity check.  That is:
-
-      TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce,
-                                            AEADEncrypted,
-                                            additional_data)
-
-   If the decryption fails, a fatal bad_record_mac alert MUST be
-   generated.
-
-6.3.  Key Calculation
-
-   The Record Protocol requires an algorithm to generate keys required
-   by the current connection state (see Appendix A.6) from the security
-   parameters provided by the handshake protocol.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 25]
-
-RFC 5246                          TLS                        August 2008
-
-
-   The master secret is expanded into a sequence of secure bytes, which
-   is then split to a client write MAC key, a server write MAC key, a
-   client write encryption key, and a server write encryption key.  Each
-   of these is generated from the byte sequence in that order.  Unused
-   values are empty.  Some AEAD ciphers may additionally require a
-   client write IV and a server write IV (see Section 6.2.3.3).
-
-   When keys and MAC keys are generated, the master secret is used as an
-   entropy source.
-
-   To generate the key material, compute
-
-      key_block = PRF(SecurityParameters.master_secret,
-                      "key expansion",
-                      SecurityParameters.server_random +
-                      SecurityParameters.client_random);
-
-   until enough output has been generated.  Then, the key_block is
-   partitioned as follows:
-
-      client_write_MAC_key[SecurityParameters.mac_key_length]
-      server_write_MAC_key[SecurityParameters.mac_key_length]
-      client_write_key[SecurityParameters.enc_key_length]
-      server_write_key[SecurityParameters.enc_key_length]
-      client_write_IV[SecurityParameters.fixed_iv_length]
-      server_write_IV[SecurityParameters.fixed_iv_length]
-
-   Currently, the client_write_IV and server_write_IV are only generated
-   for implicit nonce techniques as described in Section 3.2.1 of
-   [AEAD].
-
-   Implementation note: The currently defined cipher suite which
-   requires the most material is AES_256_CBC_SHA256.  It requires 2 x 32
-   byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key
-   material.
-
-7.  The TLS Handshaking Protocols
-
-   TLS has three subprotocols that are used to allow peers to agree upon
-   security parameters for the record layer, to authenticate themselves,
-   to instantiate negotiated security parameters, and to report error
-   conditions to each other.
-
-   The Handshake Protocol is responsible for negotiating a session,
-   which consists of the following items:
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 26]
-
-RFC 5246                          TLS                        August 2008
-
-
-   session identifier
-      An arbitrary byte sequence chosen by the server to identify an
-      active or resumable session state.
-
-   peer certificate
-      X509v3 [PKIX] certificate of the peer.  This element of the state
-      may be null.
-
-   compression method
-      The algorithm used to compress data prior to encryption.
-
-   cipher spec
-      Specifies the pseudorandom function (PRF) used to generate keying
-      material, the bulk data encryption algorithm (such as null, AES,
-      etc.) and the MAC algorithm (such as HMAC-SHA1).  It also defines
-      cryptographic attributes such as the mac_length.  (See Appendix
-      A.6 for formal definition.)
-
-   master secret
-      48-byte secret shared between the client and server.
-
-   is resumable
-      A flag indicating whether the session can be used to initiate new
-      connections.
-
-   These items are then used to create security parameters for use by
-   the record layer when protecting application data.  Many connections
-   can be instantiated using the same session through the resumption
-   feature of the TLS Handshake Protocol.
-
-7.1.  Change Cipher Spec Protocol
-
-   The change cipher spec protocol exists to signal transitions in
-   ciphering strategies.  The protocol consists of a single message,
-   which is encrypted and compressed under the current (not the pending)
-   connection state.  The message consists of a single byte of value 1.
-
-      struct {
-          enum { change_cipher_spec(1), (255) } type;
-      } ChangeCipherSpec;
-
-   The ChangeCipherSpec message is sent by both the client and the
-   server to notify the receiving party that subsequent records will be
-   protected under the newly negotiated CipherSpec and keys.  Reception
-   of this message causes the receiver to instruct the record layer to
-   immediately copy the read pending state into the read current state.
-   Immediately after sending this message, the sender MUST instruct the
-   record layer to make the write pending state the write active state.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 27]
-
-RFC 5246                          TLS                        August 2008
-
-
-   (See Section 6.1.)  The ChangeCipherSpec message is sent during the
-   handshake after the security parameters have been agreed upon, but
-   before the verifying Finished message is sent.
-
-   Note: If a rehandshake occurs while data is flowing on a connection,
-   the communicating parties may continue to send data using the old
-   CipherSpec.  However, once the ChangeCipherSpec has been sent, the
-   new CipherSpec MUST be used.  The first side to send the
-   ChangeCipherSpec does not know that the other side has finished
-   computing the new keying material (e.g., if it has to perform a
-   time-consuming public key operation).  Thus, a small window of time,
-   during which the recipient must buffer the data, MAY exist.  In
-   practice, with modern machines this interval is likely to be fairly
-   short.
-
-7.2.  Alert Protocol
-
-   One of the content types supported by the TLS record layer is the
-   alert type.  Alert messages convey the severity of the message
-   (warning or fatal) and a description of the alert.  Alert messages
-   with a level of fatal result in the immediate termination of the
-   connection.  In this case, other connections corresponding to the
-   session may continue, but the session identifier MUST be invalidated,
-   preventing the failed session from being used to establish new
-   connections.  Like other messages, alert messages are encrypted and
-   compressed, as specified by the current connection state.
-
-      enum { warning(1), fatal(2), (255) } AlertLevel;
-
-      enum {
-          close_notify(0),
-          unexpected_message(10),
-          bad_record_mac(20),
-          decryption_failed_RESERVED(21),
-          record_overflow(22),
-          decompression_failure(30),
-          handshake_failure(40),
-          no_certificate_RESERVED(41),
-          bad_certificate(42),
-          unsupported_certificate(43),
-          certificate_revoked(44),
-          certificate_expired(45),
-          certificate_unknown(46),
-          illegal_parameter(47),
-          unknown_ca(48),
-          access_denied(49),
-          decode_error(50),
-          decrypt_error(51),
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 28]
-
-RFC 5246                          TLS                        August 2008
-
-
-          export_restriction_RESERVED(60),
-          protocol_version(70),
-          insufficient_security(71),
-          internal_error(80),
-          user_canceled(90),
-          no_renegotiation(100),
-          unsupported_extension(110),
-          (255)
-      } AlertDescription;
-
-      struct {
-          AlertLevel level;
-          AlertDescription description;
-      } Alert;
-
-7.2.1.  Closure Alerts
-
-   The client and the server must share knowledge that the connection is
-   ending in order to avoid a truncation attack.  Either party may
-   initiate the exchange of closing messages.
-
-   close_notify
-      This message notifies the recipient that the sender will not send
-      any more messages on this connection.  Note that as of TLS 1.1,
-      failure to properly close a connection no longer requires that a
-      session not be resumed.  This is a change from TLS 1.0 to conform
-      with widespread implementation practice.
-
-   Either party may initiate a close by sending a close_notify alert.
-   Any data received after a closure alert is ignored.
-
-   Unless some other fatal alert has been transmitted, each party is
-   required to send a close_notify alert before closing the write side
-   of the connection.  The other party MUST respond with a close_notify
-   alert of its own and close down the connection immediately,
-   discarding any pending writes.  It is not required for the initiator
-   of the close to wait for the responding close_notify alert before
-   closing the read side of the connection.
-
-   If the application protocol using TLS provides that any data may be
-   carried over the underlying transport after the TLS connection is
-   closed, the TLS implementation must receive the responding
-   close_notify alert before indicating to the application layer that
-   the TLS connection has ended.  If the application protocol will not
-   transfer any additional data, but will only close the underlying
-   transport connection, then the implementation MAY choose to close the
-   transport without waiting for the responding close_notify.  No part
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 29]
-
-RFC 5246                          TLS                        August 2008
-
-
-   of this standard should be taken to dictate the manner in which a
-   usage profile for TLS manages its data transport, including when
-   connections are opened or closed.
-
-   Note: It is assumed that closing a connection reliably delivers
-   pending data before destroying the transport.
-
-7.2.2.  Error Alerts
-
-   Error handling in the TLS Handshake protocol is very simple.  When an
-   error is detected, the detecting party sends a message to the other
-   party.  Upon transmission or receipt of a fatal alert message, both
-   parties immediately close the connection.  Servers and clients MUST
-   forget any session-identifiers, keys, and secrets associated with a
-   failed connection.  Thus, any connection terminated with a fatal
-   alert MUST NOT be resumed.
-
-   Whenever an implementation encounters a condition which is defined as
-   a fatal alert, it MUST send the appropriate alert prior to closing
-   the connection.  For all errors where an alert level is not
-   explicitly specified, the sending party MAY determine at its
-   discretion whether to treat this as a fatal error or not.  If the
-   implementation chooses to send an alert but intends to close the
-   connection immediately afterwards, it MUST send that alert at the
-   fatal alert level.
-
-   If an alert with a level of warning is sent and received, generally
-   the connection can continue normally.  If the receiving party decides
-   not to proceed with the connection (e.g., after having received a
-   no_renegotiation alert that it is not willing to accept), it SHOULD
-   send a fatal alert to terminate the connection.  Given this, the
-   sending party cannot, in general, know how the receiving party will
-   behave.  Therefore, warning alerts are not very useful when the
-   sending party wants to continue the connection, and thus are
-   sometimes omitted.  For example, if a peer decides to accept an
-   expired certificate (perhaps after confirming this with the user) and
-   wants to continue the connection, it would not generally send a
-   certificate_expired alert.
-
-   The following error alerts are defined:
-
-   unexpected_message
-      An inappropriate message was received.  This alert is always fatal
-      and should never be observed in communication between proper
-      implementations.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 30]
-
-RFC 5246                          TLS                        August 2008
-
-
-   bad_record_mac
-      This alert is returned if a record is received with an incorrect
-      MAC.  This alert also MUST be returned if an alert is sent because
-      a TLSCiphertext decrypted in an invalid way: either it wasn't an
-      even multiple of the block length, or its padding values, when
-      checked, weren't correct.  This message is always fatal and should
-      never be observed in communication between proper implementations
-      (except when messages were corrupted in the network).
-
-   decryption_failed_RESERVED
-      This alert was used in some earlier versions of TLS, and may have
-      permitted certain attacks against the CBC mode [CBCATT].  It MUST
-      NOT be sent by compliant implementations.
-
-   record_overflow
-      A TLSCiphertext record was received that had a length more than
-      2^14+2048 bytes, or a record decrypted to a TLSCompressed record
-      with more than 2^14+1024 bytes.  This message is always fatal and
-      should never be observed in communication between proper
-      implementations (except when messages were corrupted in the
-      network).
-
-   decompression_failure
-      The decompression function received improper input (e.g., data
-      that would expand to excessive length).  This message is always
-      fatal and should never be observed in communication between proper
-      implementations.
-
-   handshake_failure
-      Reception of a handshake_failure alert message indicates that the
-      sender was unable to negotiate an acceptable set of security
-      parameters given the options available.  This is a fatal error.
-
-   no_certificate_RESERVED
-      This alert was used in SSLv3 but not any version of TLS.  It MUST
-      NOT be sent by compliant implementations.
-
-   bad_certificate
-      A certificate was corrupt, contained signatures that did not
-      verify correctly, etc.
-
-   unsupported_certificate
-      A certificate was of an unsupported type.
-
-   certificate_revoked
-      A certificate was revoked by its signer.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 31]
-
-RFC 5246                          TLS                        August 2008
-
-
-   certificate_expired
-      A certificate has expired or is not currently valid.
-
-   certificate_unknown
-      Some other (unspecified) issue arose in processing the
-      certificate, rendering it unacceptable.
-
-   illegal_parameter
-      A field in the handshake was out of range or inconsistent with
-      other fields.  This message is always fatal.
-
-   unknown_ca
-      A valid certificate chain or partial chain was received, but the
-      certificate was not accepted because the CA certificate could not
-      be located or couldn't be matched with a known, trusted CA.  This
-      message is always fatal.
-
-   access_denied
-      A valid certificate was received, but when access control was
-      applied, the sender decided not to proceed with negotiation.  This
-      message is always fatal.
-
-   decode_error
-      A message could not be decoded because some field was out of the
-      specified range or the length of the message was incorrect.  This
-      message is always fatal and should never be observed in
-      communication between proper implementations (except when messages
-      were corrupted in the network).
-
-   decrypt_error
-      A handshake cryptographic operation failed, including being unable
-      to correctly verify a signature or validate a Finished message.
-      This message is always fatal.
-
-   export_restriction_RESERVED
-      This alert was used in some earlier versions of TLS.  It MUST NOT
-      be sent by compliant implementations.
-
-   protocol_version
-      The protocol version the client has attempted to negotiate is
-      recognized but not supported.  (For example, old protocol versions
-      might be avoided for security reasons.)  This message is always
-      fatal.
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 32]
-
-RFC 5246                          TLS                        August 2008
-
-
-   insufficient_security
-      Returned instead of handshake_failure when a negotiation has
-      failed specifically because the server requires ciphers more
-      secure than those supported by the client.  This message is always
-      fatal.
-
-   internal_error
-      An internal error unrelated to the peer or the correctness of the
-      protocol (such as a memory allocation failure) makes it impossible
-      to continue.  This message is always fatal.
-
-   user_canceled
-      This handshake is being canceled for some reason unrelated to a
-      protocol failure.  If the user cancels an operation after the
-      handshake is complete, just closing the connection by sending a
-      close_notify is more appropriate.  This alert should be followed
-      by a close_notify.  This message is generally a warning.
-
-   no_renegotiation
-      Sent by the client in response to a hello request or by the server
-      in response to a client hello after initial handshaking.  Either
-      of these would normally lead to renegotiation; when that is not
-      appropriate, the recipient should respond with this alert.  At
-      that point, the original requester can decide whether to proceed
-      with the connection.  One case where this would be appropriate is
-      where a server has spawned a process to satisfy a request; the
-      process might receive security parameters (key length,
-      authentication, etc.) at startup, and it might be difficult to
-      communicate changes to these parameters after that point.  This
-      message is always a warning.
-
-   unsupported_extension
-      sent by clients that receive an extended server hello containing
-      an extension that they did not put in the corresponding client
-      hello.  This message is always fatal.
-
-   New Alert values are assigned by IANA as described in Section 12.
-
-7.3.  Handshake Protocol Overview
-
-   The cryptographic parameters of the session state are produced by the
-   TLS Handshake Protocol, which operates on top of the TLS record
-   layer.  When a TLS client and server first start communicating, they
-   agree on a protocol version, select cryptographic algorithms,
-   optionally authenticate each other, and use public-key encryption
-   techniques to generate shared secrets.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 33]
-
-RFC 5246                          TLS                        August 2008
-
-
-   The TLS Handshake Protocol involves the following steps:
-
-   -  Exchange hello messages to agree on algorithms, exchange random
-      values, and check for session resumption.
-
-   -  Exchange the necessary cryptographic parameters to allow the
-      client and server to agree on a premaster secret.
-
-   -  Exchange certificates and cryptographic information to allow the
-      client and server to authenticate themselves.
-
-   -  Generate a master secret from the premaster secret and exchanged
-      random values.
-
-   -  Provide security parameters to the record layer.
-
-   -  Allow the client and server to verify that their peer has
-      calculated the same security parameters and that the handshake
-      occurred without tampering by an attacker.
-
-   Note that higher layers should not be overly reliant on whether TLS
-   always negotiates the strongest possible connection between two
-   peers.  There are a number of ways in which a man-in-the-middle
-   attacker can attempt to make two entities drop down to the least
-   secure method they support.  The protocol has been designed to
-   minimize this risk, but there are still attacks available: for
-   example, an attacker could block access to the port a secure service
-   runs on, or attempt to get the peers to negotiate an unauthenticated
-   connection.  The fundamental rule is that higher levels must be
-   cognizant of what their security requirements are and never transmit
-   information over a channel less secure than what they require.  The
-   TLS protocol is secure in that any cipher suite offers its promised
-   level of security: if you negotiate 3DES with a 1024-bit RSA key
-   exchange with a host whose certificate you have verified, you can
-   expect to be that secure.
-
-   These goals are achieved by the handshake protocol, which can be
-   summarized as follows: The client sends a ClientHello message to
-   which the server must respond with a ServerHello message, or else a
-   fatal error will occur and the connection will fail.  The ClientHello
-   and ServerHello are used to establish security enhancement
-   capabilities between client and server.  The ClientHello and
-   ServerHello establish the following attributes: Protocol Version,
-   Session ID, Cipher Suite, and Compression Method.  Additionally, two
-   random values are generated and exchanged: ClientHello.random and
-   ServerHello.random.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 34]
-
-RFC 5246                          TLS                        August 2008
-
-
-   The actual key exchange uses up to four messages: the server
-   Certificate, the ServerKeyExchange, the client Certificate, and the
-   ClientKeyExchange.  New key exchange methods can be created by
-   specifying a format for these messages and by defining the use of the
-   messages to allow the client and server to agree upon a shared
-   secret.  This secret MUST be quite long; currently defined key
-   exchange methods exchange secrets that range from 46 bytes upwards.
-
-   Following the hello messages, the server will send its certificate in
-   a Certificate message if it is to be authenticated.  Additionally, a
-   ServerKeyExchange message may be sent, if it is required (e.g., if
-   the server has no certificate, or if its certificate is for signing
-   only).  If the server is authenticated, it may request a certificate
-   from the client, if that is appropriate to the cipher suite selected.
-   Next, the server will send the ServerHelloDone message, indicating
-   that the hello-message phase of the handshake is complete.  The
-   server will then wait for a client response.  If the server has sent
-   a CertificateRequest message, the client MUST send the Certificate
-   message.  The ClientKeyExchange message is now sent, and the content
-   of that message will depend on the public key algorithm selected
-   between the ClientHello and the ServerHello.  If the client has sent
-   a certificate with signing ability, a digitally-signed
-   CertificateVerify message is sent to explicitly verify possession of
-   the private key in the certificate.
-
-   At this point, a ChangeCipherSpec message is sent by the client, and
-   the client copies the pending Cipher Spec into the current Cipher
-   Spec.  The client then immediately sends the Finished message under
-   the new algorithms, keys, and secrets.  In response, the server will
-   send its own ChangeCipherSpec message, transfer the pending to the
-   current Cipher Spec, and send its Finished message under the new
-   Cipher Spec.  At this point, the handshake is complete, and the
-   client and server may begin to exchange application layer data.  (See
-   flow chart below.)  Application data MUST NOT be sent prior to the
-   completion of the first handshake (before a cipher suite other than
-   TLS_NULL_WITH_NULL_NULL is established).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 35]
-
-RFC 5246                          TLS                        August 2008
-
-
-      Client                                               Server
-
-      ClientHello                  -------->
-                                                      ServerHello
-                                                     Certificate*
-                                               ServerKeyExchange*
-                                              CertificateRequest*
-                                   <--------      ServerHelloDone
-      Certificate*
-      ClientKeyExchange
-      CertificateVerify*
-      [ChangeCipherSpec]
-      Finished                     -------->
-                                               [ChangeCipherSpec]
-                                   <--------             Finished
-      Application Data             <------->     Application Data
-
-             Figure 1.  Message flow for a full handshake
-
-   * Indicates optional or situation-dependent messages that are not
-   always sent.
-
-   Note: To help avoid pipeline stalls, ChangeCipherSpec is an
-   independent TLS protocol content type, and is not actually a TLS
-   handshake message.
-
-   When the client and server decide to resume a previous session or
-   duplicate an existing session (instead of negotiating new security
-   parameters), the message flow is as follows:
-
-   The client sends a ClientHello using the Session ID of the session to
-   be resumed.  The server then checks its session cache for a match.
-   If a match is found, and the server is willing to re-establish the
-   connection under the specified session state, it will send a
-   ServerHello with the same Session ID value.  At this point, both
-   client and server MUST send ChangeCipherSpec messages and proceed
-   directly to Finished messages.  Once the re-establishment is
-   complete, the client and server MAY begin to exchange application
-   layer data.  (See flow chart below.)  If a Session ID match is not
-   found, the server generates a new session ID, and the TLS client and
-   server perform a full handshake.
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 36]
-
-RFC 5246                          TLS                        August 2008
-
-
-      Client                                                Server
-
-      ClientHello                   -------->
-                                                       ServerHello
-                                                [ChangeCipherSpec]
-                                    <--------             Finished
-      [ChangeCipherSpec]
-      Finished                      -------->
-      Application Data              <------->     Application Data
-
-          Figure 2.  Message flow for an abbreviated handshake
-
-   The contents and significance of each message will be presented in
-   detail in the following sections.
-
-7.4.  Handshake Protocol
-
-   The TLS Handshake Protocol is one of the defined higher-level clients
-   of the TLS Record Protocol.  This protocol is used to negotiate the
-   secure attributes of a session.  Handshake messages are supplied to
-   the TLS record layer, where they are encapsulated within one or more
-   TLSPlaintext structures, which are processed and transmitted as
-   specified by the current active session state.
-
-      enum {
-          hello_request(0), client_hello(1), server_hello(2),
-          certificate(11), server_key_exchange (12),
-          certificate_request(13), server_hello_done(14),
-          certificate_verify(15), client_key_exchange(16),
-          finished(20), (255)
-      } HandshakeType;
-
-      struct {
-          HandshakeType msg_type;    /* handshake type */
-          uint24 length;             /* bytes in message */
-          select (HandshakeType) {
-              case hello_request:       HelloRequest;
-              case client_hello:        ClientHello;
-              case server_hello:        ServerHello;
-              case certificate:         Certificate;
-              case server_key_exchange: ServerKeyExchange;
-              case certificate_request: CertificateRequest;
-              case server_hello_done:   ServerHelloDone;
-              case certificate_verify:  CertificateVerify;
-              case client_key_exchange: ClientKeyExchange;
-              case finished:            Finished;
-          } body;
-      } Handshake;
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 37]
-
-RFC 5246                          TLS                        August 2008
-
-
-   The handshake protocol messages are presented below in the order they
-   MUST be sent; sending handshake messages in an unexpected order
-   results in a fatal error.  Unneeded handshake messages can be
-   omitted, however.  Note one exception to the ordering: the
-   Certificate message is used twice in the handshake (from server to
-   client, then from client to server), but described only in its first
-   position.  The one message that is not bound by these ordering rules
-   is the HelloRequest message, which can be sent at any time, but which
-   SHOULD be ignored by the client if it arrives in the middle of a
-   handshake.
-
-   New handshake message types are assigned by IANA as described in
-   Section 12.
-
-7.4.1.  Hello Messages
-
-   The hello phase messages are used to exchange security enhancement
-   capabilities between the client and server.  When a new session
-   begins, the record layer's connection state encryption, hash, and
-   compression algorithms are initialized to null.  The current
-   connection state is used for renegotiation messages.
-
-7.4.1.1.  Hello Request
-
-   When this message will be sent:
-
-      The HelloRequest message MAY be sent by the server at any time.
-
-   Meaning of this message:
-
-      HelloRequest is a simple notification that the client should begin
-      the negotiation process anew.  In response, the client should send
-      a ClientHello message when convenient.  This message is not
-      intended to establish which side is the client or server but
-      merely to initiate a new negotiation.  Servers SHOULD NOT send a
-      HelloRequest immediately upon the client's initial connection.  It
-      is the client's job to send a ClientHello at that time.
-
-      This message will be ignored by the client if the client is
-      currently negotiating a session.  This message MAY be ignored by
-      the client if it does not wish to renegotiate a session, or the
-      client may, if it wishes, respond with a no_renegotiation alert.
-      Since handshake messages are intended to have transmission
-      precedence over application data, it is expected that the
-      negotiation will begin before no more than a few records are
-      received from the client.  If the server sends a HelloRequest but
-      does not receive a ClientHello in response, it may close the
-      connection with a fatal alert.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 38]
-
-RFC 5246                          TLS                        August 2008
-
-
-      After sending a HelloRequest, servers SHOULD NOT repeat the
-      request until the subsequent handshake negotiation is complete.
-
-   Structure of this message:
-
-      struct { } HelloRequest;
-
-   This message MUST NOT be included in the message hashes that are
-   maintained throughout the handshake and used in the Finished messages
-   and the certificate verify message.
-
-7.4.1.2.  Client Hello
-
-   When this message will be sent:
-
-      When a client first connects to a server, it is required to send
-      the ClientHello as its first message.  The client can also send a
-      ClientHello in response to a HelloRequest or on its own initiative
-      in order to renegotiate the security parameters in an existing
-      connection.
-
-   Structure of this message:
-
-      The ClientHello message includes a random structure, which is used
-      later in the protocol.
-
-         struct {
-             uint32 gmt_unix_time;
-             opaque random_bytes[28];
-         } Random;
-
-      gmt_unix_time
-         The current time and date in standard UNIX 32-bit format
-         (seconds since the midnight starting Jan 1, 1970, UTC, ignoring
-         leap seconds) according to the sender's internal clock.  Clocks
-         are not required to be set correctly by the basic TLS protocol;
-         higher-level or application protocols may define additional
-         requirements.  Note that, for historical reasons, the data
-         element is named using GMT, the predecessor of the current
-         worldwide time base, UTC.
-
-      random_bytes
-         28 bytes generated by a secure random number generator.
-
-   The ClientHello message includes a variable-length session
-   identifier.  If not empty, the value identifies a session between the
-   same client and server whose security parameters the client wishes to
-   reuse.  The session identifier MAY be from an earlier connection,
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 39]
-
-RFC 5246                          TLS                        August 2008
-
-
-   this connection, or from another currently active connection.  The
-   second option is useful if the client only wishes to update the
-   random structures and derived values of a connection, and the third
-   option makes it possible to establish several independent secure
-   connections without repeating the full handshake protocol.  These
-   independent connections may occur sequentially or simultaneously; a
-   SessionID becomes valid when the handshake negotiating it completes
-   with the exchange of Finished messages and persists until it is
-   removed due to aging or because a fatal error was encountered on a
-   connection associated with the session.  The actual contents of the
-   SessionID are defined by the server.
-
-      opaque SessionID<0..32>;
-
-   Warning: Because the SessionID is transmitted without encryption or
-   immediate MAC protection, servers MUST NOT place confidential
-   information in session identifiers or let the contents of fake
-   session identifiers cause any breach of security.  (Note that the
-   content of the handshake as a whole, including the SessionID, is
-   protected by the Finished messages exchanged at the end of the
-   handshake.)
-
-   The cipher suite list, passed from the client to the server in the
-   ClientHello message, contains the combinations of cryptographic
-   algorithms supported by the client in order of the client's
-   preference (favorite choice first).  Each cipher suite defines a key
-   exchange algorithm, a bulk encryption algorithm (including secret key
-   length), a MAC algorithm, and a PRF.  The server will select a cipher
-   suite or, if no acceptable choices are presented, return a handshake
-   failure alert and close the connection.  If the list contains cipher
-   suites the server does not recognize, support, or wish to use, the
-   server MUST ignore those cipher suites, and process the remaining
-   ones as usual.
-
-      uint8 CipherSuite[2];    /* Cryptographic suite selector */
-
-   The ClientHello includes a list of compression algorithms supported
-   by the client, ordered according to the client's preference.
-
-      enum { null(0), (255) } CompressionMethod;
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 40]
-
-RFC 5246                          TLS                        August 2008
-
-
-      struct {
-          ProtocolVersion client_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suites<2..2^16-2>;
-          CompressionMethod compression_methods<1..2^8-1>;
-          select (extensions_present) {
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ClientHello;
-
-   TLS allows extensions to follow the compression_methods field in an
-   extensions block.  The presence of extensions can be detected by
-   determining whether there are bytes following the compression_methods
-   at the end of the ClientHello.  Note that this method of detecting
-   optional data differs from the normal TLS method of having a
-   variable-length field, but it is used for compatibility with TLS
-   before extensions were defined.
-
-   client_version
-      The version of the TLS protocol by which the client wishes to
-      communicate during this session.  This SHOULD be the latest
-      (highest valued) version supported by the client.  For this
-      version of the specification, the version will be 3.3 (see
-      Appendix E for details about backward compatibility).
-
-   random
-      A client-generated random structure.
-
-   session_id
-      The ID of a session the client wishes to use for this connection.
-      This field is empty if no session_id is available, or if the
-      client wishes to generate new security parameters.
-
-   cipher_suites
-      This is a list of the cryptographic options supported by the
-      client, with the client's first preference first.  If the
-      session_id field is not empty (implying a session resumption
-      request), this vector MUST include at least the cipher_suite from
-      that session.  Values are defined in Appendix A.5.
-
-   compression_methods
-      This is a list of the compression methods supported by the client,
-      sorted by client preference.  If the session_id field is not empty
-      (implying a session resumption request), it MUST include the
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 41]
-
-RFC 5246                          TLS                        August 2008
-
-
-      compression_method from that session.  This vector MUST contain,
-      and all implementations MUST support, CompressionMethod.null.
-      Thus, a client and server will always be able to agree on a
-      compression method.
-
-   extensions
-      Clients MAY request extended functionality from servers by sending
-      data in the extensions field.  The actual "Extension" format is
-      defined in Section 7.4.1.4.
-
-   In the event that a client requests additional functionality using
-   extensions, and this functionality is not supplied by the server, the
-   client MAY abort the handshake.  A server MUST accept ClientHello
-   messages both with and without the extensions field, and (as for all
-   other messages) it MUST check that the amount of data in the message
-   precisely matches one of these formats; if not, then it MUST send a
-   fatal "decode_error" alert.
-
-   After sending the ClientHello message, the client waits for a
-   ServerHello message.  Any handshake message returned by the server,
-   except for a HelloRequest, is treated as a fatal error.
-
-7.4.1.3.  Server Hello
-
-   When this message will be sent:
-
-      The server will send this message in response to a ClientHello
-      message when it was able to find an acceptable set of algorithms.
-      If it cannot find such a match, it will respond with a handshake
-      failure alert.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion server_version;
-          Random random;
-          SessionID session_id;
-          CipherSuite cipher_suite;
-          CompressionMethod compression_method;
-          select (extensions_present) {
-              case false:
-                  struct {};
-              case true:
-                  Extension extensions<0..2^16-1>;
-          };
-      } ServerHello;
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 42]
-
-RFC 5246                          TLS                        August 2008
-
-
-   The presence of extensions can be detected by determining whether
-   there are bytes following the compression_method field at the end of
-   the ServerHello.
-
-   server_version
-      This field will contain the lower of that suggested by the client
-      in the client hello and the highest supported by the server.  For
-      this version of the specification, the version is 3.3.  (See
-      Appendix E for details about backward compatibility.)
-
-   random
-      This structure is generated by the server and MUST be
-      independently generated from the ClientHello.random.
-
-   session_id
-      This is the identity of the session corresponding to this
-      connection.  If the ClientHello.session_id was non-empty, the
-      server will look in its session cache for a match.  If a match is
-      found and the server is willing to establish the new connection
-      using the specified session state, the server will respond with
-      the same value as was supplied by the client.  This indicates a
-      resumed session and dictates that the parties must proceed
-      directly to the Finished messages.  Otherwise, this field will
-      contain a different value identifying the new session.  The server
-      may return an empty session_id to indicate that the session will
-      not be cached and therefore cannot be resumed.  If a session is
-      resumed, it must be resumed using the same cipher suite it was
-      originally negotiated with.  Note that there is no requirement
-      that the server resume any session even if it had formerly
-      provided a session_id.  Clients MUST be prepared to do a full
-      negotiation -- including negotiating new cipher suites -- during
-      any handshake.
-
-   cipher_suite
-      The single cipher suite selected by the server from the list in
-      ClientHello.cipher_suites.  For resumed sessions, this field is
-      the value from the state of the session being resumed.
-
-   compression_method
-      The single compression algorithm selected by the server from the
-      list in ClientHello.compression_methods.  For resumed sessions,
-      this field is the value from the resumed session state.
-
-   extensions
-      A list of extensions.  Note that only extensions offered by the
-      client can appear in the server's list.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 43]
-
-RFC 5246                          TLS                        August 2008
-
-
-7.4.1.4.  Hello Extensions
-
-   The extension format is:
-
-      struct {
-          ExtensionType extension_type;
-          opaque extension_data<0..2^16-1>;
-      } Extension;
-
-      enum {
-          signature_algorithms(13), (65535)
-      } ExtensionType;
-
-   Here:
-
-   -  "extension_type" identifies the particular extension type.
-
-   -  "extension_data" contains information specific to the particular
-      extension type.
-
-   The initial set of extensions is defined in a companion document
-   [TLSEXT].  The list of extension types is maintained by IANA as
-   described in Section 12.
-
-   An extension type MUST NOT appear in the ServerHello unless the same
-   extension type appeared in the corresponding ClientHello.  If a
-   client receives an extension type in ServerHello that it did not
-   request in the associated ClientHello, it MUST abort the handshake
-   with an unsupported_extension fatal alert.
-
-   Nonetheless, "server-oriented" extensions may be provided in the
-   future within this framework.  Such an extension (say, of type x)
-   would require the client to first send an extension of type x in a
-   ClientHello with empty extension_data to indicate that it supports
-   the extension type.  In this case, the client is offering the
-   capability to understand the extension type, and the server is taking
-   the client up on its offer.
-
-   When multiple extensions of different types are present in the
-   ClientHello or ServerHello messages, the extensions MAY appear in any
-   order.  There MUST NOT be more than one extension of the same type.
-
-   Finally, note that extensions can be sent both when starting a new
-   session and when requesting session resumption.  Indeed, a client
-   that requests session resumption does not in general know whether the
-   server will accept this request, and therefore it SHOULD send the
-   same extensions as it would send if it were not attempting
-   resumption.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 44]
-
-RFC 5246                          TLS                        August 2008
-
-
-   In general, the specification of each extension type needs to
-   describe the effect of the extension both during full handshake and
-   session resumption.  Most current TLS extensions are relevant only
-   when a session is initiated: when an older session is resumed, the
-   server does not process these extensions in Client Hello, and does
-   not include them in Server Hello.  However, some extensions may
-   specify different behavior during session resumption.
-
-   There are subtle (and not so subtle) interactions that may occur in
-   this protocol between new features and existing features which may
-   result in a significant reduction in overall security.  The following
-   considerations should be taken into account when designing new
-   extensions:
-
-   -  Some cases where a server does not agree to an extension are error
-      conditions, and some are simply refusals to support particular
-      features.  In general, error alerts should be used for the former,
-      and a field in the server extension response for the latter.
-
-   -  Extensions should, as far as possible, be designed to prevent any
-      attack that forces use (or non-use) of a particular feature by
-      manipulation of handshake messages.  This principle should be
-      followed regardless of whether the feature is believed to cause a
-      security problem.
-
-      Often the fact that the extension fields are included in the
-      inputs to the Finished message hashes will be sufficient, but
-      extreme care is needed when the extension changes the meaning of
-      messages sent in the handshake phase.  Designers and implementors
-      should be aware of the fact that until the handshake has been
-      authenticated, active attackers can modify messages and insert,
-      remove, or replace extensions.
-
-   -  It would be technically possible to use extensions to change major
-      aspects of the design of TLS; for example the design of cipher
-      suite negotiation.  This is not recommended; it would be more
-      appropriate to define a new version of TLS -- particularly since
-      the TLS handshake algorithms have specific protection against
-      version rollback attacks based on the version number, and the
-      possibility of version rollback should be a significant
-      consideration in any major design change.
-
-7.4.1.4.1.  Signature Algorithms
-
-   The client uses the "signature_algorithms" extension to indicate to
-   the server which signature/hash algorithm pairs may be used in
-   digital signatures.  The "extension_data" field of this extension
-   contains a "supported_signature_algorithms" value.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 45]
-
-RFC 5246                          TLS                        August 2008
-
-
-      enum {
-          none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
-          sha512(6), (255)
-      } HashAlgorithm;
-
-      enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
-        SignatureAlgorithm;
-
-      struct {
-            HashAlgorithm hash;
-            SignatureAlgorithm signature;
-      } SignatureAndHashAlgorithm;
-
-      SignatureAndHashAlgorithm
-        supported_signature_algorithms<2..2^16-2>;
-
-   Each SignatureAndHashAlgorithm value lists a single hash/signature
-   pair that the client is willing to verify.  The values are indicated
-   in descending order of preference.
-
-   Note: Because not all signature algorithms and hash algorithms may be
-   accepted by an implementation (e.g., DSA with SHA-1, but not
-   SHA-256), algorithms here are listed in pairs.
-
-   hash
-      This field indicates the hash algorithm which may be used.  The
-      values indicate support for unhashed data, MD5 [MD5], SHA-1,
-      SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively.  The
-      "none" value is provided for future extensibility, in case of a
-      signature algorithm which does not require hashing before signing.
-
-   signature
-      This field indicates the signature algorithm that may be used.
-      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
-      [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively.  The
-      "anonymous" value is meaningless in this context but used in
-      Section 7.4.3.  It MUST NOT appear in this extension.
-
-   The semantics of this extension are somewhat complicated because the
-   cipher suite indicates permissible signature algorithms but not hash
-   algorithms.  Sections 7.4.2 and 7.4.3 describe the appropriate rules.
-
-   If the client supports only the default hash and signature algorithms
-   (listed in this section), it MAY omit the signature_algorithms
-   extension.  If the client does not support the default algorithms, or
-   supports other hash and signature algorithms (and it is willing to
-   use them for verifying messages sent by the server, i.e., server
-   certificates and server key exchange), it MUST send the
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 46]
-
-RFC 5246                          TLS                        August 2008
-
-
-   signature_algorithms extension, listing the algorithms it is willing
-   to accept.
-
-   If the client does not send the signature_algorithms extension, the
-   server MUST do the following:
-
-   -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
-      DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
-      sent the value {sha1,rsa}.
-
-   -  If the negotiated key exchange algorithm is one of (DHE_DSS,
-      DH_DSS), behave as if the client had sent the value {sha1,dsa}.
-
-   -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
-      ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
-
-   Note: this is a change from TLS 1.1 where there are no explicit
-   rules, but as a practical matter one can assume that the peer
-   supports MD5 and SHA-1.
-
-   Note: this extension is not meaningful for TLS versions prior to 1.2.
-   Clients MUST NOT offer it if they are offering prior versions.
-   However, even if clients do offer it, the rules specified in [TLSEXT]
-   require servers to ignore extensions they do not understand.
-
-   Servers MUST NOT send this extension.  TLS servers MUST support
-   receiving this extension.
-
-   When performing session resumption, this extension is not included in
-   Server Hello, and the server ignores the extension in Client Hello
-   (if present).
-
-7.4.2.  Server Certificate
-
-   When this message will be sent:
-
-      The server MUST send a Certificate message whenever the agreed-
-      upon key exchange method uses certificates for authentication
-      (this includes all key exchange methods defined in this document
-      except DH_anon).  This message will always immediately follow the
-      ServerHello message.
-
-   Meaning of this message:
-
-      This message conveys the server's certificate chain to the client.
-
-      The certificate MUST be appropriate for the negotiated cipher
-      suite's key exchange algorithm and any negotiated extensions.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 47]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Structure of this message:
-
-      opaque ASN.1Cert<1..2^24-1>;
-
-      struct {
-          ASN.1Cert certificate_list<0..2^24-1>;
-      } Certificate;
-
-   certificate_list
-      This is a sequence (chain) of certificates.  The sender's
-      certificate MUST come first in the list.  Each following
-      certificate MUST directly certify the one preceding it.  Because
-      certificate validation requires that root keys be distributed
-      independently, the self-signed certificate that specifies the root
-      certificate authority MAY be omitted from the chain, under the
-      assumption that the remote end must already possess it in order to
-      validate it in any case.
-
-   The same message type and structure will be used for the client's
-   response to a certificate request message.  Note that a client MAY
-   send no certificates if it does not have an appropriate certificate
-   to send in response to the server's authentication request.
-
-   Note: PKCS #7 [PKCS7] is not used as the format for the certificate
-   vector because PKCS #6 [PKCS6] extended certificates are not used.
-   Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
-   of parsing the list more difficult.
-
-   The following rules apply to the certificates sent by the server:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g., [TLSPGP]).
-
-   -  The end entity certificate's public key (and associated
-      restrictions) MUST be compatible with the selected key exchange
-      algorithm.
-
-      Key Exchange Alg.  Certificate Key Type
-
-      RSA                RSA public key; the certificate MUST allow the
-      RSA_PSK            key to be used for encryption (the
-                         keyEncipherment bit MUST be set if the key
-                         usage extension is present).
-                         Note: RSA_PSK is defined in [TLSPSK].
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 48]
-
-RFC 5246                          TLS                        August 2008
-
-
-      DHE_RSA            RSA public key; the certificate MUST allow the
-      ECDHE_RSA          key to be used for signing (the
-                         digitalSignature bit MUST be set if the key
-                         usage extension is present) with the signature
-                         scheme and hash algorithm that will be employed
-                         in the server key exchange message.
-                         Note: ECDHE_RSA is defined in [TLSECC].
-
-      DHE_DSS            DSA public key; the certificate MUST allow the
-                         key to be used for signing with the hash
-                         algorithm that will be employed in the server
-                         key exchange message.
-
-      DH_DSS             Diffie-Hellman public key; the keyAgreement bit
-      DH_RSA             MUST be set if the key usage extension is
-                         present.
-
-      ECDH_ECDSA         ECDH-capable public key; the public key MUST
-      ECDH_RSA           use a curve and point format supported by the
-                         client, as described in [TLSECC].
-
-      ECDHE_ECDSA        ECDSA-capable public key; the certificate MUST
-                         allow the key to be used for signing with the
-                         hash algorithm that will be employed in the
-                         server key exchange message.  The public key
-                         MUST use a curve and point format supported by
-                         the client, as described in  [TLSECC].
-
-   -  The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are
-      used to guide certificate selection.
-
-   If the client provided a "signature_algorithms" extension, then all
-   certificates provided by the server MUST be signed by a
-   hash/signature algorithm pair that appears in that extension.  Note
-   that this implies that a certificate containing a key for one
-   signature algorithm MAY be signed using a different signature
-   algorithm (for instance, an RSA key signed with a DSA key).  This is
-   a departure from TLS 1.1, which required that the algorithms be the
-   same.  Note that this also implies that the DH_DSS, DH_RSA,
-   ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the
-   algorithm used to sign the certificate.  Fixed DH certificates MAY be
-   signed with any hash/signature algorithm pair appearing in the
-   extension.  The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are
-   historical.
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 49]
-
-RFC 5246                          TLS                        August 2008
-
-
-   If the server has multiple certificates, it chooses one of them based
-   on the above-mentioned criteria (in addition to other criteria, such
-   as transport layer endpoint, local configuration and preferences,
-   etc.).  If the server has a single certificate, it SHOULD attempt to
-   validate that it meets these criteria.
-
-   Note that there are certificates that use algorithms and/or algorithm
-   combinations that cannot be currently used with TLS.  For example, a
-   certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
-   SubjectPublicKeyInfo) cannot be used because TLS defines no
-   corresponding signature algorithm.
-
-   As cipher suites that specify new key exchange methods are specified
-   for the TLS protocol, they will imply the certificate format and the
-   required encoded keying information.
-
-7.4.3.  Server Key Exchange Message
-
-   When this message will be sent:
-
-      This message will be sent immediately after the server Certificate
-      message (or the ServerHello message, if this is an anonymous
-      negotiation).
-
-      The ServerKeyExchange message is sent by the server only when the
-      server Certificate message (if sent) does not contain enough data
-      to allow the client to exchange a premaster secret.  This is true
-      for the following key exchange methods:
-
-         DHE_DSS
-         DHE_RSA
-         DH_anon
-
-      It is not legal to send the ServerKeyExchange message for the
-      following key exchange methods:
-
-         RSA
-         DH_DSS
-         DH_RSA
-
-      Other key exchange algorithms, such as those defined in [TLSECC],
-      MUST specify whether the ServerKeyExchange message is sent or not;
-      and if the message is sent, its contents.
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 50]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Meaning of this message:
-
-      This message conveys cryptographic information to allow the client
-      to communicate the premaster secret: a Diffie-Hellman public key
-      with which the client can complete a key exchange (with the result
-      being the premaster secret) or a public key for some other
-      algorithm.
-
-   Structure of this message:
-
-      enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
-            /* may be extended, e.g., for ECDH -- see [TLSECC] */
-           } KeyExchangeAlgorithm;
-
-      struct {
-          opaque dh_p<1..2^16-1>;
-          opaque dh_g<1..2^16-1>;
-          opaque dh_Ys<1..2^16-1>;
-      } ServerDHParams;     /* Ephemeral DH parameters */
-
-      dh_p
-         The prime modulus used for the Diffie-Hellman operation.
-
-      dh_g
-         The generator used for the Diffie-Hellman operation.
-
-      dh_Ys
-         The server's Diffie-Hellman public value (g^X mod p).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 51]
-
-RFC 5246                          TLS                        August 2008
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case dh_anon:
-                  ServerDHParams params;
-              case dhe_dss:
-              case dhe_rsa:
-                  ServerDHParams params;
-                  digitally-signed struct {
-                      opaque client_random[32];
-                      opaque server_random[32];
-                      ServerDHParams params;
-                  } signed_params;
-              case rsa:
-              case dh_dss:
-              case dh_rsa:
-                  struct {} ;
-                 /* message is omitted for rsa, dh_dss, and dh_rsa */
-              /* may be extended, e.g., for ECDH -- see [TLSECC] */
-          };
-      } ServerKeyExchange;
-
-      params
-         The server's key exchange parameters.
-
-      signed_params
-         For non-anonymous key exchanges, a signature over the server's
-         key exchange parameters.
-
-   If the client has offered the "signature_algorithms" extension, the
-   signature algorithm and hash algorithm MUST be a pair listed in that
-   extension.  Note that there is a possibility for inconsistencies
-   here.  For instance, the client might offer DHE_DSS key exchange but
-   omit any DSA pairs from its "signature_algorithms" extension.  In
-   order to negotiate correctly, the server MUST check any candidate
-   cipher suites against the "signature_algorithms" extension before
-   selecting them.  This is somewhat inelegant but is a compromise
-   designed to minimize changes to the original cipher suite design.
-
-   In addition, the hash and signature algorithms MUST be compatible
-   with the key in the server's end-entity certificate.  RSA keys MAY be
-   used with any permitted hash algorithm, subject to restrictions in
-   the certificate, if any.
-
-   Because DSA signatures do not contain any secure indication of hash
-   algorithm, there is a risk of hash substitution if multiple hashes
-   may be used with any key.  Currently, DSA [DSS] may only be used with
-   SHA-1.  Future revisions of DSS [DSS-3] are expected to allow the use
-   of other digest algorithms with DSA, as well as guidance as to which
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 52]
-
-RFC 5246                          TLS                        August 2008
-
-
-   digest algorithms should be used with each key size.  In addition,
-   future revisions of [PKIX] may specify mechanisms for certificates to
-   indicate which digest algorithms are to be used with DSA.
-
-   As additional cipher suites are defined for TLS that include new key
-   exchange algorithms, the server key exchange message will be sent if
-   and only if the certificate type associated with the key exchange
-   algorithm does not provide enough information for the client to
-   exchange a premaster secret.
-
-7.4.4.  Certificate Request
-
-   When this message will be sent:
-
-       A non-anonymous server can optionally request a certificate from
-       the client, if appropriate for the selected cipher suite.  This
-       message, if sent, will immediately follow the ServerKeyExchange
-       message (if it is sent; otherwise, this message follows the
-       server's Certificate message).
-
-   Structure of this message:
-
-      enum {
-          rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-          rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-          fortezza_dms_RESERVED(20), (255)
-      } ClientCertificateType;
-
-      opaque DistinguishedName<1..2^16-1>;
-
-      struct {
-          ClientCertificateType certificate_types<1..2^8-1>;
-          SignatureAndHashAlgorithm
-            supported_signature_algorithms<2^16-1>;
-          DistinguishedName certificate_authorities<0..2^16-1>;
-      } CertificateRequest;
-
-   certificate_types
-      A list of the types of certificate types that the client may
-      offer.
-
-         rsa_sign        a certificate containing an RSA key
-         dss_sign        a certificate containing a DSA key
-         rsa_fixed_dh    a certificate containing a static DH key.
-         dss_fixed_dh    a certificate containing a static DH key
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 53]
-
-RFC 5246                          TLS                        August 2008
-
-
-   supported_signature_algorithms
-      A list of the hash/signature algorithm pairs that the server is
-      able to verify, listed in descending order of preference.
-
-   certificate_authorities
-      A list of the distinguished names [X501] of acceptable
-      certificate_authorities, represented in DER-encoded format.  These
-      distinguished names may specify a desired distinguished name for a
-      root CA or for a subordinate CA; thus, this message can be used to
-      describe known roots as well as a desired authorization space.  If
-      the certificate_authorities list is empty, then the client MAY
-      send any certificate of the appropriate ClientCertificateType,
-      unless there is some external arrangement to the contrary.
-
-   The interaction of the certificate_types and
-   supported_signature_algorithms fields is somewhat complicated.
-   certificate_types has been present in TLS since SSLv3, but was
-   somewhat underspecified.  Much of its functionality is superseded by
-   supported_signature_algorithms.  The following rules apply:
-
-   -  Any certificates provided by the client MUST be signed using a
-      hash/signature algorithm pair found in
-      supported_signature_algorithms.
-
-   -  The end-entity certificate provided by the client MUST contain a
-      key that is compatible with certificate_types.  If the key is a
-      signature key, it MUST be usable with some hash/signature
-      algorithm pair in supported_signature_algorithms.
-
-   -  For historical reasons, the names of some client certificate types
-      include the algorithm used to sign the certificate.  For example,
-      in earlier versions of TLS, rsa_fixed_dh meant a certificate
-      signed with RSA and containing a static DH key.  In TLS 1.2, this
-      functionality has been obsoleted by the
-      supported_signature_algorithms, and the certificate type no longer
-      restricts the algorithm used to sign the certificate.  For
-      example, if the server sends dss_fixed_dh certificate type and
-      {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply
-      with a certificate containing a static DH key, signed with RSA-
-      SHA1.
-
-   New ClientCertificateType values are assigned by IANA as described in
-   Section 12.
-
-   Note: Values listed as RESERVED may not be used.  They were used in
-   SSLv3.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 54]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Note: It is a fatal handshake_failure alert for an anonymous server
-   to request client authentication.
-
-7.4.5.  Server Hello Done
-
-   When this message will be sent:
-
-      The ServerHelloDone message is sent by the server to indicate the
-      end of the ServerHello and associated messages.  After sending
-      this message, the server will wait for a client response.
-
-   Meaning of this message:
-
-      This message means that the server is done sending messages to
-      support the key exchange, and the client can proceed with its
-      phase of the key exchange.
-
-      Upon receipt of the ServerHelloDone message, the client SHOULD
-      verify that the server provided a valid certificate, if required,
-      and check that the server hello parameters are acceptable.
-
-   Structure of this message:
-
-      struct { } ServerHelloDone;
-
-7.4.6.  Client Certificate
-
-   When this message will be sent:
-
-      This is the first message the client can send after receiving a
-      ServerHelloDone message.  This message is only sent if the server
-      requests a certificate.  If no suitable certificate is available,
-      the client MUST send a certificate message containing no
-      certificates.  That is, the certificate_list structure has a
-      length of zero.  If the client does not send any certificates, the
-      server MAY at its discretion either continue the handshake without
-      client authentication, or respond with a fatal handshake_failure
-      alert.  Also, if some aspect of the certificate chain was
-      unacceptable (e.g., it was not signed by a known, trusted CA), the
-      server MAY at its discretion either continue the handshake
-      (considering the client unauthenticated) or send a fatal alert.
-
-      Client certificates are sent using the Certificate structure
-      defined in Section 7.4.2.
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 55]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Meaning of this message:
-
-      This message conveys the client's certificate chain to the server;
-      the server will use it when verifying the CertificateVerify
-      message (when the client authentication is based on signing) or
-      calculating the premaster secret (for non-ephemeral Diffie-
-      Hellman).  The certificate MUST be appropriate for the negotiated
-      cipher suite's key exchange algorithm, and any negotiated
-      extensions.
-
-   In particular:
-
-   -  The certificate type MUST be X.509v3, unless explicitly negotiated
-      otherwise (e.g., [TLSPGP]).
-
-   -  The end-entity certificate's public key (and associated
-      restrictions) has to be compatible with the certificate types
-      listed in CertificateRequest:
-
-      Client Cert. Type   Certificate Key Type
-
-      rsa_sign            RSA public key; the certificate MUST allow the
-                          key to be used for signing with the signature
-                          scheme and hash algorithm that will be
-                          employed in the certificate verify message.
-
-      dss_sign            DSA public key; the certificate MUST allow the
-                          key to be used for signing with the hash
-                          algorithm that will be employed in the
-                          certificate verify message.
-
-      ecdsa_sign          ECDSA-capable public key; the certificate MUST
-                          allow the key to be used for signing with the
-                          hash algorithm that will be employed in the
-                          certificate verify message; the public key
-                          MUST use a curve and point format supported by
-                          the server.
-
-      rsa_fixed_dh        Diffie-Hellman public key; MUST use the same
-      dss_fixed_dh        parameters as server's key.
-
-      rsa_fixed_ecdh      ECDH-capable public key; MUST use the
-      ecdsa_fixed_ecdh    same curve as the server's key, and MUST use a
-                          point format supported by the server.
-
-   -  If the certificate_authorities list in the certificate request
-      message was non-empty, one of the certificates in the certificate
-      chain SHOULD be issued by one of the listed CAs.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 56]
-
-RFC 5246                          TLS                        August 2008
-
-
-   -  The certificates MUST be signed using an acceptable hash/
-      signature algorithm pair, as described in Section 7.4.4.  Note
-      that this relaxes the constraints on certificate-signing
-      algorithms found in prior versions of TLS.
-
-   Note that, as with the server certificate, there are certificates
-   that use algorithms/algorithm combinations that cannot be currently
-   used with TLS.
-
-7.4.7.  Client Key Exchange Message
-
-   When this message will be sent:
-
-      This message is always sent by the client.  It MUST immediately
-      follow the client certificate message, if it is sent.  Otherwise,
-      it MUST be the first message sent by the client after it receives
-      the ServerHelloDone message.
-
-   Meaning of this message:
-
-      With this message, the premaster secret is set, either by direct
-      transmission of the RSA-encrypted secret or by the transmission of
-      Diffie-Hellman parameters that will allow each side to agree upon
-      the same premaster secret.
-
-      When the client is using an ephemeral Diffie-Hellman exponent,
-      then this message contains the client's Diffie-Hellman public
-      value.  If the client is sending a certificate containing a static
-      DH exponent (i.e., it is doing fixed_dh client authentication),
-      then this message MUST be sent but MUST be empty.
-
-   Structure of this message:
-
-      The choice of messages depends on which key exchange method has
-      been selected.  See Section 7.4.3 for the KeyExchangeAlgorithm
-      definition.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 57]
-
-RFC 5246                          TLS                        August 2008
-
-
-      struct {
-          select (KeyExchangeAlgorithm) {
-              case rsa:
-                  EncryptedPreMasterSecret;
-              case dhe_dss:
-              case dhe_rsa:
-              case dh_dss:
-              case dh_rsa:
-              case dh_anon:
-                  ClientDiffieHellmanPublic;
-          } exchange_keys;
-      } ClientKeyExchange;
-
-7.4.7.1.  RSA-Encrypted Premaster Secret Message
-
-   Meaning of this message:
-
-      If RSA is being used for key agreement and authentication, the
-      client generates a 48-byte premaster secret, encrypts it using the
-      public key from the server's certificate, and sends the result in
-      an encrypted premaster secret message.  This structure is a
-      variant of the ClientKeyExchange message and is not a message in
-      itself.
-
-   Structure of this message:
-
-      struct {
-          ProtocolVersion client_version;
-          opaque random[46];
-      } PreMasterSecret;
-
-      client_version
-         The latest (newest) version supported by the client.  This is
-         used to detect version rollback attacks.
-
-      random
-         46 securely-generated random bytes.
-
-      struct {
-          public-key-encrypted PreMasterSecret pre_master_secret;
-      } EncryptedPreMasterSecret;
-
-      pre_master_secret
-         This random value is generated by the client and is used to
-         generate the master secret, as specified in Section 8.1.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 58]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Note: The version number in the PreMasterSecret is the version
-   offered by the client in the ClientHello.client_version, not the
-   version negotiated for the connection.  This feature is designed to
-   prevent rollback attacks.  Unfortunately, some old implementations
-   use the negotiated version instead, and therefore checking the
-   version number may lead to failure to interoperate with such
-   incorrect client implementations.
-
-   Client implementations MUST always send the correct version number in
-   PreMasterSecret.  If ClientHello.client_version is TLS 1.1 or higher,
-   server implementations MUST check the version number as described in
-   the note below.  If the version number is TLS 1.0 or earlier, server
-   implementations SHOULD check the version number, but MAY have a
-   configuration option to disable the check.  Note that if the check
-   fails, the PreMasterSecret SHOULD be randomized as described below.
-
-   Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.
-   [KPR03] can be used to attack a TLS server that reveals whether a
-   particular message, when decrypted, is properly PKCS#1 formatted,
-   contains a valid PreMasterSecret structure, or has the correct
-   version number.
-
-   As described by Klima [KPR03], these vulnerabilities can be avoided
-   by treating incorrectly formatted message blocks and/or mismatched
-   version numbers in a manner indistinguishable from correctly
-   formatted RSA blocks.  In other words:
-
-      1. Generate a string R of 46 random bytes
-
-      2. Decrypt the message to recover the plaintext M
-
-      3. If the PKCS#1 padding is not correct, or the length of message
-         M is not exactly 48 bytes:
-            pre_master_secret = ClientHello.client_version || R
-         else If ClientHello.client_version <= TLS 1.0, and version
-         number check is explicitly disabled:
-            pre_master_secret = M
-         else:
-            pre_master_secret = ClientHello.client_version || M[2..47]
-
-   Note that explicitly constructing the pre_master_secret with the
-   ClientHello.client_version produces an invalid master_secret if the
-   client has sent the wrong version in the original pre_master_secret.
-
-   An alternative approach is to treat a version number mismatch as a
-   PKCS-1 formatting error and randomize the premaster secret
-   completely:
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 59]
-
-RFC 5246                          TLS                        August 2008
-
-
-      1. Generate a string R of 48 random bytes
-
-      2. Decrypt the message to recover the plaintext M
-
-      3. If the PKCS#1 padding is not correct, or the length of message
-         M is not exactly 48 bytes:
-            pre_master_secret = R
-         else If ClientHello.client_version <= TLS 1.0, and version
-         number check is explicitly disabled:
-            premaster secret = M
-         else If M[0..1] != ClientHello.client_version:
-            premaster secret = R
-         else:
-            premaster secret = M
-
-   Although no practical attacks against this construction are known,
-   Klima et al. [KPR03] describe some theoretical attacks, and therefore
-   the first construction described is RECOMMENDED.
-
-   In any case, a TLS server MUST NOT generate an alert if processing an
-   RSA-encrypted premaster secret message fails, or the version number
-   is not as expected.  Instead, it MUST continue the handshake with a
-   randomly generated premaster secret.  It may be useful to log the
-   real cause of failure for troubleshooting purposes; however, care
-   must be taken to avoid leaking the information to an attacker
-   (through, e.g., timing, log files, or other channels.)
-
-   The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure
-   against the Bleichenbacher attack.  However, for maximal
-   compatibility with earlier versions of TLS, this specification uses
-   the RSAES-PKCS1-v1_5 scheme.  No variants of the Bleichenbacher
-   attack are known to exist provided that the above recommendations are
-   followed.
-
-   Implementation note: Public-key-encrypted data is represented as an
-   opaque vector <0..2^16-1> (see Section 4.7).  Thus, the RSA-encrypted
-   PreMasterSecret in a ClientKeyExchange is preceded by two length
-   bytes.  These bytes are redundant in the case of RSA because the
-   EncryptedPreMasterSecret is the only data in the ClientKeyExchange
-   and its length can therefore be unambiguously determined.  The SSLv3
-   specification was not clear about the encoding of public-key-
-   encrypted data, and therefore many SSLv3 implementations do not
-   include the length bytes -- they encode the RSA-encrypted data
-   directly in the ClientKeyExchange message.
-
-   This specification requires correct encoding of the
-   EncryptedPreMasterSecret complete with length bytes.  The resulting
-   PDU is incompatible with many SSLv3 implementations.  Implementors
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 60]
-
-RFC 5246                          TLS                        August 2008
-
-
-   upgrading from SSLv3 MUST modify their implementations to generate
-   and accept the correct encoding.  Implementors who wish to be
-   compatible with both SSLv3 and TLS should make their implementation's
-   behavior dependent on the protocol version.
-
-   Implementation note: It is now known that remote timing-based attacks
-   on TLS are possible, at least when the client and server are on the
-   same LAN.  Accordingly, implementations that use static RSA keys MUST
-   use RSA blinding or some other anti-timing technique, as described in
-   [TIMING].
-
-7.4.7.2.  Client Diffie-Hellman Public Value
-
-   Meaning of this message:
-
-      This structure conveys the client's Diffie-Hellman public value
-      (Yc) if it was not already included in the client's certificate.
-      The encoding used for Yc is determined by the enumerated
-      PublicValueEncoding.  This structure is a variant of the client
-      key exchange message, and not a message in itself.
-
-   Structure of this message:
-
-      enum { implicit, explicit } PublicValueEncoding;
-
-      implicit
-         If the client has sent a certificate which contains a suitable
-         Diffie-Hellman key (for fixed_dh client authentication), then
-         Yc is implicit and does not need to be sent again.  In this
-         case, the client key exchange message will be sent, but it MUST
-         be empty.
-
-      explicit
-         Yc needs to be sent.
-
-      struct {
-          select (PublicValueEncoding) {
-              case implicit: struct { };
-              case explicit: opaque dh_Yc<1..2^16-1>;
-          } dh_public;
-      } ClientDiffieHellmanPublic;
-
-      dh_Yc
-         The client's Diffie-Hellman public value (Yc).
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 61]
-
-RFC 5246                          TLS                        August 2008
-
-
-7.4.8.  Certificate Verify
-
-   When this message will be sent:
-
-      This message is used to provide explicit verification of a client
-      certificate.  This message is only sent following a client
-      certificate that has signing capability (i.e., all certificates
-      except those containing fixed Diffie-Hellman parameters).  When
-      sent, it MUST immediately follow the client key exchange message.
-
-   Structure of this message:
-
-      struct {
-           digitally-signed struct {
-               opaque handshake_messages[handshake_messages_length];
-           }
-      } CertificateVerify;
-
-      Here handshake_messages refers to all handshake messages sent or
-      received, starting at client hello and up to, but not including,
-      this message, including the type and length fields of the
-      handshake messages.  This is the concatenation of all the
-      Handshake structures (as defined in Section 7.4) exchanged thus
-      far.  Note that this requires both sides to either buffer the
-      messages or compute running hashes for all potential hash
-      algorithms up to the time of the CertificateVerify computation.
-      Servers can minimize this computation cost by offering a
-      restricted set of digest algorithms in the CertificateRequest
-      message.
-
-      The hash and signature algorithms used in the signature MUST be
-      one of those present in the supported_signature_algorithms field
-      of the CertificateRequest message.  In addition, the hash and
-      signature algorithms MUST be compatible with the key in the
-      client's end-entity certificate.  RSA keys MAY be used with any
-      permitted hash algorithm, subject to restrictions in the
-      certificate, if any.
-
-      Because DSA signatures do not contain any secure indication of
-      hash algorithm, there is a risk of hash substitution if multiple
-      hashes may be used with any key.  Currently, DSA [DSS] may only be
-      used with SHA-1.  Future revisions of DSS [DSS-3] are expected to
-      allow the use of other digest algorithms with DSA, as well as
-      guidance as to which digest algorithms should be used with each
-      key size.  In addition, future revisions of [PKIX] may specify
-      mechanisms for certificates to indicate which digest algorithms
-      are to be used with DSA.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 62]
-
-RFC 5246                          TLS                        August 2008
-
-
-7.4.9.  Finished
-
-   When this message will be sent:
-
-      A Finished message is always sent immediately after a change
-      cipher spec message to verify that the key exchange and
-      authentication processes were successful.  It is essential that a
-      change cipher spec message be received between the other handshake
-      messages and the Finished message.
-
-   Meaning of this message:
-
-      The Finished message is the first one protected with the just
-      negotiated algorithms, keys, and secrets.  Recipients of Finished
-      messages MUST verify that the contents are correct.  Once a side
-      has sent its Finished message and received and validated the
-      Finished message from its peer, it may begin to send and receive
-      application data over the connection.
-
-   Structure of this message:
-
-      struct {
-          opaque verify_data[verify_data_length];
-      } Finished;
-
-      verify_data
-         PRF(master_secret, finished_label, Hash(handshake_messages))
-            [0..verify_data_length-1];
-
-      finished_label
-         For Finished messages sent by the client, the string
-         "client finished".  For Finished messages sent by the server,
-         the string "server finished".
-
-      Hash denotes a Hash of the handshake messages.  For the PRF
-      defined in Section 5, the Hash MUST be the Hash used as the basis
-      for the PRF.  Any cipher suite which defines a different PRF MUST
-      also define the Hash to use in the Finished computation.
-
-      In previous versions of TLS, the verify_data was always 12 octets
-      long.  In the current version of TLS, it depends on the cipher
-      suite.  Any cipher suite which does not explicitly specify
-      verify_data_length has a verify_data_length equal to 12.  This
-      includes all existing cipher suites.  Note that this
-      representation has the same encoding as with previous versions.
-      Future cipher suites MAY specify other lengths but such length
-      MUST be at least 12 bytes.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 63]
-
-RFC 5246                          TLS                        August 2008
-
-
-      handshake_messages
-         All of the data from all messages in this handshake (not
-         including any HelloRequest messages) up to, but not including,
-         this message.  This is only data visible at the handshake layer
-         and does not include record layer headers.  This is the
-         concatenation of all the Handshake structures as defined in
-         Section 7.4, exchanged thus far.
-
-   It is a fatal error if a Finished message is not preceded by a
-   ChangeCipherSpec message at the appropriate point in the handshake.
-
-   The value handshake_messages includes all handshake messages starting
-   at ClientHello up to, but not including, this Finished message.  This
-   may be different from handshake_messages in Section 7.4.8 because it
-   would include the CertificateVerify message (if sent).  Also, the
-   handshake_messages for the Finished message sent by the client will
-   be different from that for the Finished message sent by the server,
-   because the one that is sent second will include the prior one.
-
-   Note: ChangeCipherSpec messages, alerts, and any other record types
-   are not handshake messages and are not included in the hash
-   computations.  Also, HelloRequest messages are omitted from handshake
-   hashes.
-
-8.  Cryptographic Computations
-
-   In order to begin connection protection, the TLS Record Protocol
-   requires specification of a suite of algorithms, a master secret, and
-   the client and server random values.  The authentication, encryption,
-   and MAC algorithms are determined by the cipher_suite selected by the
-   server and revealed in the ServerHello message.  The compression
-   algorithm is negotiated in the hello messages, and the random values
-   are exchanged in the hello messages.  All that remains is to
-   calculate the master secret.
-
-8.1.  Computing the Master Secret
-
-   For all key exchange methods, the same algorithm is used to convert
-   the pre_master_secret into the master_secret.  The pre_master_secret
-   should be deleted from memory once the master_secret has been
-   computed.
-
-      master_secret = PRF(pre_master_secret, "master secret",
-                          ClientHello.random + ServerHello.random)
-                          [0..47];
-
-   The master secret is always exactly 48 bytes in length.  The length
-   of the premaster secret will vary depending on key exchange method.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 64]
-
-RFC 5246                          TLS                        August 2008
-
-
-8.1.1.  RSA
-
-   When RSA is used for server authentication and key exchange, a 48-
-   byte pre_master_secret is generated by the client, encrypted under
-   the server's public key, and sent to the server.  The server uses its
-   private key to decrypt the pre_master_secret.  Both parties then
-   convert the pre_master_secret into the master_secret, as specified
-   above.
-
-8.1.2.  Diffie-Hellman
-
-   A conventional Diffie-Hellman computation is performed.  The
-   negotiated key (Z) is used as the pre_master_secret, and is converted
-   into the master_secret, as specified above.  Leading bytes of Z that
-   contain all zero bits are stripped before it is used as the
-   pre_master_secret.
-
-   Note: Diffie-Hellman parameters are specified by the server and may
-   be either ephemeral or contained within the server's certificate.
-
-9.  Mandatory Cipher Suites
-
-   In the absence of an application profile standard specifying
-   otherwise, a TLS-compliant application MUST implement the cipher
-   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
-   definition).
-
-10.  Application Data Protocol
-
-   Application data messages are carried by the record layer and are
-   fragmented, compressed, and encrypted based on the current connection
-   state.  The messages are treated as transparent data to the record
-   layer.
-
-11.  Security Considerations
-
-   Security issues are discussed throughout this memo, especially in
-   Appendices D, E, and F.
-
-12.  IANA Considerations
-
-   This document uses several registries that were originally created in
-   [TLS1.1].  IANA has updated these to reference this document.  The
-   registries and their allocation policies (unchanged from [TLS1.1])
-   are listed below.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 65]
-
-RFC 5246                          TLS                        August 2008
-
-
-   -  TLS ClientCertificateType Identifiers Registry: Future values in
-      the range 0-63 (decimal) inclusive are assigned via Standards
-      Action [RFC2434].  Values in the range 64-223 (decimal) inclusive
-      are assigned via Specification Required [RFC2434].  Values from
-      224-255 (decimal) inclusive are reserved for Private Use
-      [RFC2434].
-
-   -  TLS Cipher Suite Registry: Future values with the first byte in
-      the range 0-191 (decimal) inclusive are assigned via Standards
-      Action [RFC2434].  Values with the first byte in the range 192-254
-      (decimal) are assigned via Specification Required [RFC2434].
-      Values with the first byte 255 (decimal) are reserved for Private
-      Use [RFC2434].
-
-   -  This document defines several new HMAC-SHA256-based cipher suites,
-      whose values (in Appendix A.5) have been allocated from the TLS
-      Cipher Suite registry.
-
-   -  TLS ContentType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   -  TLS Alert Registry: Future values are allocated via Standards
-      Action [RFC2434].
-
-   -  TLS HandshakeType Registry: Future values are allocated via
-      Standards Action [RFC2434].
-
-   This document also uses a registry originally created in [RFC4366].
-   IANA has updated it to reference this document.  The registry and its
-   allocation policy (unchanged from [RFC4366]) is listed below:
-
-   -  TLS ExtensionType Registry: Future values are allocated via IETF
-      Consensus [RFC2434].  IANA has updated this registry to include
-      the signature_algorithms extension and its corresponding value
-      (see Section 7.4.1.4).
-
-   In addition, this document defines two new registries to be
-   maintained by IANA:
-
-   -  TLS SignatureAlgorithm Registry: The registry has been initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 66]
-
-RFC 5246                          TLS                        August 2008
-
-
-   -  TLS HashAlgorithm Registry: The registry has been initially
-      populated with the values described in Section 7.4.1.4.1.  Future
-      values in the range 0-63 (decimal) inclusive are assigned via
-      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
-      inclusive are assigned via Specification Required [RFC2434].
-      Values from 224-255 (decimal) inclusive are reserved for Private
-      Use [RFC2434].
-
-      This document also uses the TLS Compression Method Identifiers
-      Registry, defined in [RFC3749].  IANA has allocated value 0 for
-      the "null" compression method.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 67]
-
-RFC 5246                          TLS                        August 2008
-
-
-Appendix A.  Protocol Data Structures and Constant Values
-
-   This section describes protocol types and constants.
-
-A.1.  Record Layer
-
-   struct {
-       uint8 major;
-       uint8 minor;
-   } ProtocolVersion;
-
-   ProtocolVersion version = { 3, 3 };     /* TLS v1.2*/
-
-   enum {
-       change_cipher_spec(20), alert(21), handshake(22),
-       application_data(23), (255)
-   } ContentType;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSPlaintext.length];
-   } TLSPlaintext;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       opaque fragment[TLSCompressed.length];
-   } TLSCompressed;
-
-   struct {
-       ContentType type;
-       ProtocolVersion version;
-       uint16 length;
-       select (SecurityParameters.cipher_type) {
-           case stream: GenericStreamCipher;
-           case block:  GenericBlockCipher;
-           case aead:   GenericAEADCipher;
-       } fragment;
-   } TLSCiphertext;
-
-   stream-ciphered struct {
-       opaque content[TLSCompressed.length];
-       opaque MAC[SecurityParameters.mac_length];
-   } GenericStreamCipher;
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 68]
-
-RFC 5246                          TLS                        August 2008
-
-
-   struct {
-       opaque IV[SecurityParameters.record_iv_length];
-       block-ciphered struct {
-           opaque content[TLSCompressed.length];
-           opaque MAC[SecurityParameters.mac_length];
-           uint8 padding[GenericBlockCipher.padding_length];
-           uint8 padding_length;
-       };
-   } GenericBlockCipher;
-
-   struct {
-      opaque nonce_explicit[SecurityParameters.record_iv_length];
-      aead-ciphered struct {
-          opaque content[TLSCompressed.length];
-      };
-   } GenericAEADCipher;
-
-A.2.  Change Cipher Specs Message
-
-   struct {
-       enum { change_cipher_spec(1), (255) } type;
-   } ChangeCipherSpec;
-
-A.3.  Alert Messages
-
-   enum { warning(1), fatal(2), (255) } AlertLevel;
-
-   enum {
-       close_notify(0),
-       unexpected_message(10),
-       bad_record_mac(20),
-       decryption_failed_RESERVED(21),
-       record_overflow(22),
-       decompression_failure(30),
-       handshake_failure(40),
-       no_certificate_RESERVED(41),
-       bad_certificate(42),
-       unsupported_certificate(43),
-       certificate_revoked(44),
-       certificate_expired(45),
-       certificate_unknown(46),
-       illegal_parameter(47),
-       unknown_ca(48),
-       access_denied(49),
-       decode_error(50),
-       decrypt_error(51),
-       export_restriction_RESERVED(60),
-       protocol_version(70),
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 69]
-
-RFC 5246                          TLS                        August 2008
-
-
-       insufficient_security(71),
-       internal_error(80),
-       user_canceled(90),
-       no_renegotiation(100),
-       unsupported_extension(110),           /* new */
-       (255)
-   } AlertDescription;
-
-   struct {
-       AlertLevel level;
-       AlertDescription description;
-   } Alert;
-
-A.4.  Handshake Protocol
-
-   enum {
-       hello_request(0), client_hello(1), server_hello(2),
-       certificate(11), server_key_exchange (12),
-       certificate_request(13), server_hello_done(14),
-       certificate_verify(15), client_key_exchange(16),
-       finished(20)
-       (255)
-   } HandshakeType;
-
-   struct {
-       HandshakeType msg_type;
-       uint24 length;
-       select (HandshakeType) {
-           case hello_request:       HelloRequest;
-           case client_hello:        ClientHello;
-           case server_hello:        ServerHello;
-           case certificate:         Certificate;
-           case server_key_exchange: ServerKeyExchange;
-           case certificate_request: CertificateRequest;
-           case server_hello_done:   ServerHelloDone;
-           case certificate_verify:  CertificateVerify;
-           case client_key_exchange: ClientKeyExchange;
-           case finished:            Finished;
-       } body;
-   } Handshake;
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 70]
-
-RFC 5246                          TLS                        August 2008
-
-
-A.4.1.  Hello Messages
-
-   struct { } HelloRequest;
-
-   struct {
-       uint32 gmt_unix_time;
-       opaque random_bytes[28];
-   } Random;
-
-   opaque SessionID<0..32>;
-
-   uint8 CipherSuite[2];
-
-   enum { null(0), (255) } CompressionMethod;
-
-   struct {
-       ProtocolVersion client_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suites<2..2^16-2>;
-       CompressionMethod compression_methods<1..2^8-1>;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ClientHello;
-
-   struct {
-       ProtocolVersion server_version;
-       Random random;
-       SessionID session_id;
-       CipherSuite cipher_suite;
-       CompressionMethod compression_method;
-       select (extensions_present) {
-           case false:
-               struct {};
-           case true:
-               Extension extensions<0..2^16-1>;
-       };
-   } ServerHello;
-
-   struct {
-       ExtensionType extension_type;
-       opaque extension_data<0..2^16-1>;
-   } Extension;
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 71]
-
-RFC 5246                          TLS                        August 2008
-
-
-   enum {
-       signature_algorithms(13), (65535)
-   } ExtensionType;
-
-   enum{
-       none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
-       sha512(6), (255)
-   } HashAlgorithm;
-   enum {
-      anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
-   } SignatureAlgorithm;
-
-   struct {
-         HashAlgorithm hash;
-         SignatureAlgorithm signature;
-   } SignatureAndHashAlgorithm;
-
-   SignatureAndHashAlgorithm
-    supported_signature_algorithms<2..2^16-1>;
-
-A.4.2.  Server Authentication and Key Exchange Messages
-
-   opaque ASN.1Cert<2^24-1>;
-
-   struct {
-       ASN.1Cert certificate_list<0..2^24-1>;
-   } Certificate;
-
-   enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
-          /* may be extended, e.g., for ECDH -- see [TLSECC] */
-        } KeyExchangeAlgorithm;
-
-   struct {
-       opaque dh_p<1..2^16-1>;
-       opaque dh_g<1..2^16-1>;
-       opaque dh_Ys<1..2^16-1>;
-   } ServerDHParams;     /* Ephemeral DH parameters */
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 72]
-
-RFC 5246                          TLS                        August 2008
-
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case dh_anon:
-               ServerDHParams params;
-           case dhe_dss:
-           case dhe_rsa:
-               ServerDHParams params;
-               digitally-signed struct {
-                   opaque client_random[32];
-                   opaque server_random[32];
-                   ServerDHParams params;
-               } signed_params;
-           case rsa:
-           case dh_dss:
-           case dh_rsa:
-               struct {} ;
-              /* message is omitted for rsa, dh_dss, and dh_rsa */
-           /* may be extended, e.g., for ECDH -- see [TLSECC] */
-   } ServerKeyExchange;
-
-   enum {
-       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
-       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
-       fortezza_dms_RESERVED(20),
-       (255)
-   } ClientCertificateType;
-
-   opaque DistinguishedName<1..2^16-1>;
-
-   struct {
-       ClientCertificateType certificate_types<1..2^8-1>;
-       DistinguishedName certificate_authorities<0..2^16-1>;
-   } CertificateRequest;
-
-   struct { } ServerHelloDone;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 73]
-
-RFC 5246                          TLS                        August 2008
-
-
-A.4.3.  Client Authentication and Key Exchange Messages
-
-   struct {
-       select (KeyExchangeAlgorithm) {
-           case rsa:
-               EncryptedPreMasterSecret;
-           case dhe_dss:
-           case dhe_rsa:
-           case dh_dss:
-           case dh_rsa:
-           case dh_anon:
-               ClientDiffieHellmanPublic;
-       } exchange_keys;
-   } ClientKeyExchange;
-
-   struct {
-       ProtocolVersion client_version;
-       opaque random[46];
-   } PreMasterSecret;
-
-   struct {
-       public-key-encrypted PreMasterSecret pre_master_secret;
-   } EncryptedPreMasterSecret;
-
-   enum { implicit, explicit } PublicValueEncoding;
-
-   struct {
-       select (PublicValueEncoding) {
-           case implicit: struct {};
-           case explicit: opaque DH_Yc<1..2^16-1>;
-       } dh_public;
-   } ClientDiffieHellmanPublic;
-
-   struct {
-        digitally-signed struct {
-            opaque handshake_messages[handshake_messages_length];
-        }
-   } CertificateVerify;
-
-A.4.4.  Handshake Finalization Message
-
-   struct {
-       opaque verify_data[verify_data_length];
-   } Finished;
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 74]
-
-RFC 5246                          TLS                        August 2008
-
-
-A.5.  The Cipher Suite
-
-   The following values define the cipher suite codes used in the
-   ClientHello and ServerHello messages.
-
-   A cipher suite defines a cipher specification supported in TLS
-   Version 1.2.
-
-   TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
-   TLS connection during the first handshake on that channel, but MUST
-   NOT be negotiated, as it provides no more protection than an
-   unsecured connection.
-
-      CipherSuite TLS_NULL_WITH_NULL_NULL               = { 0x00,0x00 };
-
-   The following CipherSuite definitions require that the server provide
-   an RSA certificate that can be used for key exchange.  The server may
-   request any signature-capable certificate in the certificate request
-   message.
-
-      CipherSuite TLS_RSA_WITH_NULL_MD5                 = { 0x00,0x01 };
-      CipherSuite TLS_RSA_WITH_NULL_SHA                 = { 0x00,0x02 };
-      CipherSuite TLS_RSA_WITH_NULL_SHA256              = { 0x00,0x3B };
-      CipherSuite TLS_RSA_WITH_RC4_128_MD5              = { 0x00,0x04 };
-      CipherSuite TLS_RSA_WITH_RC4_128_SHA              = { 0x00,0x05 };
-      CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA         = { 0x00,0x0A };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x35 };
-      CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256       = { 0x00,0x3C };
-      CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256       = { 0x00,0x3D };
-
-   The following cipher suite definitions are used for server-
-   authenticated (and optionally client-authenticated) Diffie-Hellman.
-   DH denotes cipher suites in which the server's certificate contains
-   the Diffie-Hellman parameters signed by the certificate authority
-   (CA).  DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
-   parameters are signed by a signature-capable certificate, which has
-   been signed by the CA.  The signing algorithm used by the server is
-   specified after the DHE component of the CipherSuite name.  The
-   server can request any signature-capable certificate from the client
-   for client authentication, or it may request a Diffie-Hellman
-   certificate.  Any Diffie-Hellman certificate provided by the client
-   must use the parameters (group and generator) described by the
-   server.
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 75]
-
-RFC 5246                          TLS                        August 2008
-
-
-      CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x0D };
-      CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x10 };
-      CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x13 };
-      CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x16 };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x36 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x37 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };
-      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00,0x3E };
-      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00,0x3F };
-      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00,0x40 };
-      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00,0x67 };
-      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256    = { 0x00,0x68 };
-      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256    = { 0x00,0x69 };
-      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   = { 0x00,0x6A };
-      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   = { 0x00,0x6B };
-
-   The following cipher suites are used for completely anonymous
-   Diffie-Hellman communications in which neither party is
-   authenticated.  Note that this mode is vulnerable to man-in-the-
-   middle attacks.  Using this mode therefore is of limited use: These
-   cipher suites MUST NOT be used by TLS 1.2 implementations unless the
-   application layer has specifically requested to allow anonymous key
-   exchange.  (Anonymous key exchange may sometimes be acceptable, for
-   example, to support opportunistic encryption when no set-up for
-   authentication is in place, or when TLS is used as part of more
-   complex security protocols that have other means to ensure
-   authentication.)
-
-      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
-      CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x1B };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x3A };
-      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,0x6C };
-      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00,0x6D };
-
-   Note that using non-anonymous key exchange without actually verifying
-   the key exchange is essentially equivalent to anonymous key exchange,
-   and the same precautions apply.  While non-anonymous key exchange
-   will generally involve a higher computational and communicational
-   cost than anonymous key exchange, it may be in the interest of
-   interoperability not to disable non-anonymous key exchange when the
-   application layer is allowing anonymous key exchange.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 76]
-
-RFC 5246                          TLS                        August 2008
-
-
-   New cipher suite values have been assigned by IANA as described in
-   Section 12.
-
-   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
-   reserved to avoid collision with Fortezza-based cipher suites in
-   SSL 3.
-
-A.6.  The Security Parameters
-
-   These security parameters are determined by the TLS Handshake
-   Protocol and provided as parameters to the TLS record layer in order
-   to initialize a connection state.  SecurityParameters includes:
-
-   enum { null(0), (255) } CompressionMethod;
-
-   enum { server, client } ConnectionEnd;
-
-   enum { tls_prf_sha256 } PRFAlgorithm;
-
-   enum { null, rc4, 3des, aes } BulkCipherAlgorithm;
-
-   enum { stream, block, aead } CipherType;
-
-   enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
-     hmac_sha512} MACAlgorithm;
-
-   /* Other values may be added to the algorithms specified in
-   CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and
-   MACAlgorithm. */
-
-   struct {
-       ConnectionEnd          entity;
-       PRFAlgorithm           prf_algorithm;
-       BulkCipherAlgorithm    bulk_cipher_algorithm;
-       CipherType             cipher_type;
-       uint8                  enc_key_length;
-       uint8                  block_length;
-       uint8                  fixed_iv_length;
-       uint8                  record_iv_length;
-       MACAlgorithm           mac_algorithm;
-       uint8                  mac_length;
-       uint8                  mac_key_length;
-       CompressionMethod      compression_algorithm;
-       opaque                 master_secret[48];
-       opaque                 client_random[32];
-       opaque                 server_random[32];
-   } SecurityParameters;
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 77]
-
-RFC 5246                          TLS                        August 2008
-
-
-A.7.  Changes to RFC 4492
-
-   RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS.  This
-   document changes some of the structures used in that document.  This
-   section details the required changes for implementors of both RFC
-   4492 and TLS 1.2.  Implementors of TLS 1.2 who are not implementing
-   RFC 4492 do not need to read this section.
-
-   This document adds a "signature_algorithm" field to the digitally-
-   signed element in order to identify the signature and digest
-   algorithms used to create a signature.  This change applies to
-   digital signatures formed using ECDSA as well, thus allowing ECDSA
-   signatures to be used with digest algorithms other than SHA-1,
-   provided such use is compatible with the certificate and any
-   restrictions imposed by future revisions of [PKIX].
-
-   As described in Sections 7.4.2 and 7.4.6, the restrictions on the
-   signature algorithms used to sign certificates are no longer tied to
-   the cipher suite (when used by the server) or the
-   ClientCertificateType (when used by the client).  Thus, the
-   restrictions on the algorithm used to sign certificates specified in
-   Sections 2 and 3 of RFC 4492 are also relaxed.  As in this document,
-   the restrictions on the keys in the end-entity certificate remain.
-
-Appendix B.  Glossary
-
-   Advanced Encryption Standard (AES)
-      AES [AES] is a widely used symmetric encryption algorithm.  AES is
-      a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte
-      block size.  TLS currently only supports the 128- and 256-bit key
-      sizes.
-
-   application protocol
-      An application protocol is a protocol that normally layers
-      directly on top of the transport layer (e.g., TCP/IP).  Examples
-      include HTTP, TELNET, FTP, and SMTP.
-
-   asymmetric cipher
-      See public key cryptography.
-
-   authenticated encryption with additional data (AEAD)
-      A symmetric encryption algorithm that simultaneously provides
-      confidentiality and message integrity.
-
-   authentication
-      Authentication is the ability of one entity to determine the
-      identity of another entity.
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 78]
-
-RFC 5246                          TLS                        August 2008
-
-
-   block cipher
-      A block cipher is an algorithm that operates on plaintext in
-      groups of bits, called blocks.  64 bits was, and 128 bits is, a
-      common block size.
-
-   bulk cipher
-      A symmetric encryption algorithm used to encrypt large quantities
-      of data.
-
-   cipher block chaining (CBC)
-      CBC is a mode in which every plaintext block encrypted with a
-      block cipher is first exclusive-ORed with the previous ciphertext
-      block (or, in the case of the first block, with the initialization
-      vector).  For decryption, every block is first decrypted, then
-      exclusive-ORed with the previous ciphertext block (or IV).
-
-   certificate
-      As part of the X.509 protocol (a.k.a. ISO Authentication
-      framework), certificates are assigned by a trusted Certificate
-      Authority and provide a strong binding between a party's identity
-      or some other attributes and its public key.
-
-   client
-      The application entity that initiates a TLS connection to a
-      server.  This may or may not imply that the client initiated the
-      underlying transport connection.  The primary operational
-      difference between the server and client is that the server is
-      generally authenticated, while the client is only optionally
-      authenticated.
-
-   client write key
-      The key used to encrypt data written by the client.
-
-   client write MAC key
-      The secret data used to authenticate data written by the client.
-
-   connection
-      A connection is a transport (in the OSI layering model definition)
-      that provides a suitable type of service.  For TLS, such
-      connections are peer-to-peer relationships.  The connections are
-      transient.  Every connection is associated with one session.
-
-   Data Encryption Standard
-      DES [DES] still is a very widely used symmetric encryption
-      algorithm although it is considered as rather weak now.  DES is a
-      block cipher with a 56-bit key and an 8-byte block size.  Note
-      that in TLS, for key generation purposes, DES is treated as having
-      an 8-byte key length (64 bits), but it still only provides 56 bits
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 79]
-
-RFC 5246                          TLS                        August 2008
-
-
-      of protection.  (The low bit of each key byte is presumed to be
-      set to produce odd parity in that key byte.)  DES can also be
-      operated in a mode [3DES] where three independent keys and three
-      encryptions are used for each block of data; this uses 168 bits of
-      key (24 bytes in the TLS key generation method) and provides the
-      equivalent of 112 bits of security.
-
-   Digital Signature Standard (DSS)
-      A standard for digital signing, including the Digital Signing
-      Algorithm, approved by the National Institute of Standards and
-      Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
-      Standard", published January 2000 by the U.S. Department of
-      Commerce [DSS].  A significant update [DSS-3] has been drafted and
-      was published in March 2006.
-
-   digital signatures
-      Digital signatures utilize public key cryptography and one-way
-      hash functions to produce a signature of the data that can be
-      authenticated, and is difficult to forge or repudiate.
-
-   handshake An initial negotiation between client and server that
-      establishes the parameters of their transactions.
-
-   Initialization Vector (IV)
-      When a block cipher is used in CBC mode, the initialization vector
-      is exclusive-ORed with the first plaintext block prior to
-      encryption.
-
-   Message Authentication Code (MAC)
-      A Message Authentication Code is a one-way hash computed from a
-      message and some secret data.  It is difficult to forge without
-      knowing the secret data.  Its purpose is to detect if the message
-      has been altered.
-
-   master secret
-      Secure secret data used for generating encryption keys, MAC
-      secrets, and IVs.
-
-   MD5
-      MD5 [MD5] is a hashing function that converts an arbitrarily long
-      data stream into a hash of fixed size (16 bytes).  Due to
-      significant progress in cryptanalysis, at the time of publication
-      of this document, MD5 no longer can be considered a 'secure'
-      hashing function.
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 80]
-
-RFC 5246                          TLS                        August 2008
-
-
-   public key cryptography
-      A class of cryptographic techniques employing two-key ciphers.
-      Messages encrypted with the public key can only be decrypted with
-      the associated private key.  Conversely, messages signed with the
-      private key can be verified with the public key.
-
-   one-way hash function
-      A one-way transformation that converts an arbitrary amount of data
-      into a fixed-length hash.  It is computationally hard to reverse
-      the transformation or to find collisions.  MD5 and SHA are
-      examples of one-way hash functions.
-
-   RC4
-      A stream cipher invented by Ron Rivest.  A compatible cipher is
-      described in [SCH].
-
-   RSA
-      A very widely used public key algorithm that can be used for
-      either encryption or digital signing.  [RSA]
-
-   server
-      The server is the application entity that responds to requests for
-      connections from clients.  See also "client".
-
-   session
-      A TLS session is an association between a client and a server.
-      Sessions are created by the handshake protocol.  Sessions define a
-      set of cryptographic security parameters that can be shared among
-      multiple connections.  Sessions are used to avoid the expensive
-      negotiation of new security parameters for each connection.
-
-   session identifier
-      A session identifier is a value generated by a server that
-      identifies a particular session.
-
-   server write key
-      The key used to encrypt data written by the server.
-
-   server write MAC key
-      The secret data used to authenticate data written by the server.
-
-   SHA
-      The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2.  It
-      produces a 20-byte output.  Note that all references to SHA
-      (without a numerical suffix) actually use the modified SHA-1
-      algorithm.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 81]
-
-RFC 5246                          TLS                        August 2008
-
-
-   SHA-256
-      The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2.
-      It produces a 32-byte output.
-
-   SSL
-      Netscape's Secure Socket Layer protocol [SSL3].  TLS is based on
-      SSL Version 3.0.
-
-   stream cipher
-      An encryption algorithm that converts a key into a
-      cryptographically strong keystream, which is then exclusive-ORed
-      with the plaintext.
-
-   symmetric cipher
-      See bulk cipher.
-
-   Transport Layer Security (TLS)
-      This protocol; also, the Transport Layer Security working group of
-      the Internet Engineering Task Force (IETF).  See "Working Group
-      Information" at the end of this document (see page 99).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 82]
-
-RFC 5246                          TLS                        August 2008
-
-
-Appendix C.  Cipher Suite Definitions
-
-Cipher Suite                            Key        Cipher         Mac
-                                        Exchange
-
-TLS_NULL_WITH_NULL_NULL                 NULL         NULL         NULL
-TLS_RSA_WITH_NULL_MD5                   RSA          NULL         MD5
-TLS_RSA_WITH_NULL_SHA                   RSA          NULL         SHA
-TLS_RSA_WITH_NULL_SHA256                RSA          NULL         SHA256
-TLS_RSA_WITH_RC4_128_MD5                RSA          RC4_128      MD5
-TLS_RSA_WITH_RC4_128_SHA                RSA          RC4_128      SHA
-TLS_RSA_WITH_3DES_EDE_CBC_SHA           RSA          3DES_EDE_CBC SHA
-TLS_RSA_WITH_AES_128_CBC_SHA            RSA          AES_128_CBC  SHA
-TLS_RSA_WITH_AES_256_CBC_SHA            RSA          AES_256_CBC  SHA
-TLS_RSA_WITH_AES_128_CBC_SHA256         RSA          AES_128_CBC  SHA256
-TLS_RSA_WITH_AES_256_CBC_SHA256         RSA          AES_256_CBC  SHA256
-TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA        DH_DSS       3DES_EDE_CBC SHA
-TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA        DH_RSA       3DES_EDE_CBC SHA
-TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       DHE_DSS      3DES_EDE_CBC SHA
-TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE_RSA      3DES_EDE_CBC SHA
-TLS_DH_anon_WITH_RC4_128_MD5            DH_anon      RC4_128      MD5
-TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       DH_anon      3DES_EDE_CBC SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH_DSS       AES_128_CBC  SHA
-TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH_RSA       AES_128_CBC  SHA
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE_DSS      AES_128_CBC  SHA
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE_RSA      AES_128_CBC  SHA
-TLS_DH_anon_WITH_AES_128_CBC_SHA        DH_anon      AES_128_CBC  SHA
-TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH_DSS       AES_256_CBC  SHA
-TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH_RSA       AES_256_CBC  SHA
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE_DSS      AES_256_CBC  SHA
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE_RSA      AES_256_CBC  SHA
-TLS_DH_anon_WITH_AES_256_CBC_SHA        DH_anon      AES_256_CBC  SHA
-TLS_DH_DSS_WITH_AES_128_CBC_SHA256      DH_DSS       AES_128_CBC  SHA256
-TLS_DH_RSA_WITH_AES_128_CBC_SHA256      DH_RSA       AES_128_CBC  SHA256
-TLS_DHE_DSS_WITH_AES_128_CBC_SHA256     DHE_DSS      AES_128_CBC  SHA256
-TLS_DHE_RSA_WITH_AES_128_CBC_SHA256     DHE_RSA      AES_128_CBC  SHA256
-TLS_DH_anon_WITH_AES_128_CBC_SHA256     DH_anon      AES_128_CBC  SHA256
-TLS_DH_DSS_WITH_AES_256_CBC_SHA256      DH_DSS       AES_256_CBC  SHA256
-TLS_DH_RSA_WITH_AES_256_CBC_SHA256      DH_RSA       AES_256_CBC  SHA256
-TLS_DHE_DSS_WITH_AES_256_CBC_SHA256     DHE_DSS      AES_256_CBC  SHA256
-TLS_DHE_RSA_WITH_AES_256_CBC_SHA256     DHE_RSA      AES_256_CBC  SHA256
-TLS_DH_anon_WITH_AES_256_CBC_SHA256     DH_anon      AES_256_CBC  SHA256
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 83]
-
-RFC 5246                          TLS                        August 2008
-
-
-                        Key      IV   Block
-Cipher        Type    Material  Size  Size
-------------  ------  --------  ----  -----
-NULL          Stream      0       0    N/A
-RC4_128       Stream     16       0    N/A
-3DES_EDE_CBC  Block      24       8      8
-AES_128_CBC   Block      16      16     16
-AES_256_CBC   Block      32      16     16
-
-
-MAC       Algorithm    mac_length  mac_key_length
---------  -----------  ----------  --------------
-NULL      N/A              0             0
-MD5       HMAC-MD5        16            16
-SHA       HMAC-SHA1       20            20
-SHA256    HMAC-SHA256     32            32
-
-   Type
-      Indicates whether this is a stream cipher or a block cipher
-      running in CBC mode.
-
-   Key Material
-      The number of bytes from the key_block that are used for
-      generating the write keys.
-
-   IV Size
-      The amount of data needed to be generated for the initialization
-      vector.  Zero for stream ciphers; equal to the block size for
-      block ciphers (this is equal to
-      SecurityParameters.record_iv_length).
-
-   Block Size
-      The amount of data a block cipher enciphers in one chunk; a block
-      cipher running in CBC mode can only encrypt an even multiple of
-      its block size.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 84]
-
-RFC 5246                          TLS                        August 2008
-
-
-Appendix D.  Implementation Notes
-
-   The TLS protocol cannot prevent many common security mistakes.  This
-   section provides several recommendations to assist implementors.
-
-D.1.  Random Number Generation and Seeding
-
-   TLS requires a cryptographically secure pseudorandom number generator
-   (PRNG).  Care must be taken in designing and seeding PRNGs.  PRNGs
-   based on secure hash operations, most notably SHA-1, are acceptable,
-   but cannot provide more security than the size of the random number
-   generator state.
-
-   To estimate the amount of seed material being produced, add the
-   number of bits of unpredictable information in each seed byte.  For
-   example, keystroke timing values taken from a PC compatible's 18.2 Hz
-   timer provide 1 or 2 secure bits each, even though the total size of
-   the counter value is 16 bits or more.  Seeding a 128-bit PRNG would
-   thus require approximately 100 such timer values.
-
-   [RANDOM] provides guidance on the generation of random values.
-
-D.2.  Certificates and Authentication
-
-   Implementations are responsible for verifying the integrity of
-   certificates and should generally support certificate revocation
-   messages.  Certificates should always be verified to ensure proper
-   signing by a trusted Certificate Authority (CA).  The selection and
-   addition of trusted CAs should be done very carefully.  Users should
-   be able to view information about the certificate and root CA.
-
-D.3.  Cipher Suites
-
-   TLS supports a range of key sizes and security levels, including some
-   that provide no or minimal security.  A proper implementation will
-   probably not support many cipher suites.  For instance, anonymous
-   Diffie-Hellman is strongly discouraged because it cannot prevent man-
-   in-the-middle attacks.  Applications should also enforce minimum and
-   maximum key sizes.  For example, certificate chains containing 512-
-   bit RSA keys or signatures are not appropriate for high-security
-   applications.
-
-D.4.  Implementation Pitfalls
-
-   Implementation experience has shown that certain parts of earlier TLS
-   specifications are not easy to understand, and have been a source of
-   interoperability and security problems.  Many of these areas have
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 85]
-
-RFC 5246                          TLS                        August 2008
-
-
-   been clarified in this document, but this appendix contains a short
-   list of the most important things that require special attention from
-   implementors.
-
-   TLS protocol issues:
-
-   -  Do you correctly handle handshake messages that are fragmented to
-      multiple TLS records (see Section 6.2.1)? Including corner cases
-      like a ClientHello that is split to several small fragments? Do
-      you fragment handshake messages that exceed the maximum fragment
-      size? In particular, the certificate and certificate request
-      handshake messages can be large enough to require fragmentation.
-
-   -  Do you ignore the TLS record layer version number in all TLS
-      records before ServerHello (see Appendix E.1)?
-
-   -  Do you handle TLS extensions in ClientHello correctly, including
-      omitting the extensions field completely?
-
-   -  Do you support renegotiation, both client and server initiated?
-      While renegotiation is an optional feature, supporting it is
-      highly recommended.
-
-   -  When the server has requested a client certificate, but no
-      suitable certificate is available, do you correctly send an empty
-      Certificate message, instead of omitting the whole message (see
-      Section 7.4.6)?
-
-   Cryptographic details:
-
-   -  In the RSA-encrypted Premaster Secret, do you correctly send and
-      verify the version number? When an error is encountered, do you
-      continue the handshake to avoid the Bleichenbacher attack (see
-      Section 7.4.7.1)?
-
-   -  What countermeasures do you use to prevent timing attacks against
-      RSA decryption and signing operations (see Section 7.4.7.1)?
-
-   -  When verifying RSA signatures, do you accept both NULL and missing
-      parameters (see Section 4.7)? Do you verify that the RSA padding
-      doesn't have additional data after the hash value?  [FI06]
-
-   -  When using Diffie-Hellman key exchange, do you correctly strip
-      leading zero bytes from the negotiated key (see Section 8.1.2)?
-
-   -  Does your TLS client check that the Diffie-Hellman parameters sent
-      by the server are acceptable (see Section F.1.1.3)?
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 86]
-
-RFC 5246                          TLS                        August 2008
-
-
-   -  How do you generate unpredictable IVs for CBC mode ciphers (see
-      Section 6.2.3.2)?
-
-   -  Do you accept long CBC mode padding (up to 255 bytes; see Section
-      6.2.3.2)?
-
-   -  How do you address CBC mode timing attacks (Section 6.2.3.2)?
-
-   -  Do you use a strong and, most importantly, properly seeded random
-      number generator (see Appendix D.1) for generating the premaster
-      secret (for RSA key exchange), Diffie-Hellman private values, the
-      DSA "k" parameter, and other security-critical values?
-
-Appendix E.  Backward Compatibility
-
-E.1.  Compatibility with TLS 1.0/1.1 and SSL 3.0
-
-   Since there are various versions of TLS (1.0, 1.1, 1.2, and any
-   future versions) and SSL (2.0 and 3.0), means are needed to negotiate
-   the specific protocol version to use.  The TLS protocol provides a
-   built-in mechanism for version negotiation so as not to bother other
-   protocol components with the complexities of version selection.
-
-   TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
-   compatible ClientHello messages; thus, supporting all of them is
-   relatively easy.  Similarly, servers can easily handle clients trying
-   to use future versions of TLS as long as the ClientHello format
-   remains compatible, and the client supports the highest protocol
-   version available in the server.
-
-   A TLS 1.2 client who wishes to negotiate with such older servers will
-   send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
-   ClientHello.client_version.  If the server does not support this
-   version, it will respond with a ServerHello containing an older
-   version number.  If the client agrees to use this version, the
-   negotiation will proceed as appropriate for the negotiated protocol.
-
-   If the version chosen by the server is not supported by the client
-   (or not acceptable), the client MUST send a "protocol_version" alert
-   message and close the connection.
-
-   If a TLS server receives a ClientHello containing a version number
-   greater than the highest version supported by the server, it MUST
-   reply according to the highest version supported by the server.
-
-   A TLS server can also receive a ClientHello containing a version
-   number smaller than the highest supported version.  If the server
-   wishes to negotiate with old clients, it will proceed as appropriate
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 87]
-
-RFC 5246                          TLS                        August 2008
-
-
-   for the highest version supported by the server that is not greater
-   than ClientHello.client_version.  For example, if the server supports
-   TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
-   proceed with a TLS 1.0 ServerHello.  If server supports (or is
-   willing to use) only versions greater than client_version, it MUST
-   send a "protocol_version" alert message and close the connection.
-
-   Whenever a client already knows the highest protocol version known to
-   a server (for example, when resuming a session), it SHOULD initiate
-   the connection in that native protocol.
-
-   Note: some server implementations are known to implement version
-   negotiation incorrectly.  For example, there are buggy TLS 1.0
-   servers that simply close the connection when the client offers a
-   version newer than TLS 1.0.  Also, it is known that some servers will
-   refuse the connection if any TLS extensions are included in
-   ClientHello.  Interoperability with such buggy servers is a complex
-   topic beyond the scope of this document, and may require multiple
-   connection attempts by the client.
-
-   Earlier versions of the TLS specification were not fully clear on
-   what the record layer version number (TLSPlaintext.version) should
-   contain when sending ClientHello (i.e., before it is known which
-   version of the protocol will be employed).  Thus, TLS servers
-   compliant with this specification MUST accept any value {03,XX} as
-   the record layer version number for ClientHello.
-
-   TLS clients that wish to negotiate with older servers MAY send any
-   value {03,XX} as the record layer version number.  Typical values
-   would be {03,00}, the lowest version number supported by the client,
-   and the value of ClientHello.client_version.  No single value will
-   guarantee interoperability with all old servers, but this is a
-   complex topic beyond the scope of this document.
-
-E.2.  Compatibility with SSL 2.0
-
-   TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
-   version 2.0 CLIENT-HELLO messages defined in [SSL2].  The message
-   MUST contain the same version number as would be used for ordinary
-   ClientHello, and MUST encode the supported TLS cipher suites in the
-   CIPHER-SPECS-DATA field as described below.
-
-   Warning: The ability to send version 2.0 CLIENT-HELLO messages will
-   be phased out with all due haste, since the newer ClientHello format
-   provides better mechanisms for moving to newer versions and
-   negotiating extensions.  TLS 1.2 clients SHOULD NOT support SSL 2.0.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 88]
-
-RFC 5246                          TLS                        August 2008
-
-
-   However, even TLS servers that do not support SSL 2.0 MAY accept
-   version 2.0 CLIENT-HELLO messages.  The message is presented below in
-   sufficient detail for TLS server implementors; the true definition is
-   still assumed to be [SSL2].
-
-   For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same
-   way as a ClientHello with a "null" compression method and no
-   extensions.  Note that this message MUST be sent directly on the
-   wire, not wrapped as a TLS record.  For the purposes of calculating
-   Finished and CertificateVerify, the msg_length field is not
-   considered to be a part of the handshake message.
-
-      uint8 V2CipherSpec[3];
-      struct {
-          uint16 msg_length;
-          uint8 msg_type;
-          Version version;
-          uint16 cipher_spec_length;
-          uint16 session_id_length;
-          uint16 challenge_length;
-          V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
-          opaque session_id[V2ClientHello.session_id_length];
-          opaque challenge[V2ClientHello.challenge_length;
-      } V2ClientHello;
-
-   msg_length
-      The highest bit MUST be 1; the remaining bits contain the length
-      of the following data in bytes.
-
-   msg_type
-      This field, in conjunction with the version field, identifies a
-      version 2 ClientHello message.  The value MUST be 1.
-
-   version
-      Equal to ClientHello.client_version.
-
-   cipher_spec_length
-      This field is the total length of the field cipher_specs.  It
-      cannot be zero and MUST be a multiple of the V2CipherSpec length
-      (3).
-
-   session_id_length
-      This field MUST have a value of zero for a client that claims to
-      support TLS 1.2.
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 89]
-
-RFC 5246                          TLS                        August 2008
-
-
-   challenge_length
-      The length in bytes of the client's challenge to the server to
-      authenticate itself.  Historically, permissible values are between
-      16 and 32 bytes inclusive.  When using the SSLv2 backward-
-      compatible handshake the client SHOULD use a 32-byte challenge.
-
-   cipher_specs
-      This is a list of all CipherSpecs the client is willing and able
-      to use.  In addition to the 2.0 cipher specs defined in [SSL2],
-      this includes the TLS cipher suites normally sent in
-      ClientHello.cipher_suites, with each cipher suite prefixed by a
-      zero byte.  For example, the TLS cipher suite {0x00,0x0A} would be
-      sent as {0x00,0x00,0x0A}.
-
-   session_id
-      This field MUST be empty.
-
-   challenge
-      Corresponds to ClientHello.random.  If the challenge length is
-      less than 32, the TLS server will pad the data with leading (note:
-      not trailing) zero bytes to make it 32 bytes long.
-
-   Note: Requests to resume a TLS session MUST use a TLS client hello.
-
-E.3.  Avoiding Man-in-the-Middle Version Rollback
-
-   When TLS clients fall back to Version 2.0 compatibility mode, they
-   MUST use special PKCS#1 block formatting.  This is done so that TLS
-   servers will reject Version 2.0 sessions with TLS-capable clients.
-
-   When a client negotiates SSL 2.0 but also supports TLS, it MUST set
-   the right-hand (least-significant) 8 random bytes of the PKCS padding
-   (not including the terminal null of the padding) for the RSA
-   encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY
-   to 0x03 (the other padding bytes are random).
-
-   When a TLS-capable server negotiates SSL 2.0 it SHOULD, after
-   decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding
-   bytes are 0x03.  If they are not, the server SHOULD generate a random
-   value for SECRET-KEY-DATA, and continue the handshake (which will
-   eventually fail since the keys will not match).  Note that reporting
-   the error situation to the client could make the server vulnerable to
-   attacks described in [BLEI].
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 90]
-
-RFC 5246                          TLS                        August 2008
-
-
-Appendix F.  Security Analysis
-
-   The TLS protocol is designed to establish a secure connection between
-   a client and a server communicating over an insecure channel.  This
-   document makes several traditional assumptions, including that
-   attackers have substantial computational resources and cannot obtain
-   secret information from sources outside the protocol.  Attackers are
-   assumed to have the ability to capture, modify, delete, replay, and
-   otherwise tamper with messages sent over the communication channel.
-   This appendix outlines how TLS has been designed to resist a variety
-   of attacks.
-
-F.1.  Handshake Protocol
-
-   The handshake protocol is responsible for selecting a cipher spec and
-   generating a master secret, which together comprise the primary
-   cryptographic parameters associated with a secure session.  The
-   handshake protocol can also optionally authenticate parties who have
-   certificates signed by a trusted certificate authority.
-
-F.1.1.  Authentication and Key Exchange
-
-   TLS supports three authentication modes: authentication of both
-   parties, server authentication with an unauthenticated client, and
-   total anonymity.  Whenever the server is authenticated, the channel
-   is secure against man-in-the-middle attacks, but completely anonymous
-   sessions are inherently vulnerable to such attacks.  Anonymous
-   servers cannot authenticate clients.  If the server is authenticated,
-   its certificate message must provide a valid certificate chain
-   leading to an acceptable certificate authority.  Similarly,
-   authenticated clients must supply an acceptable certificate to the
-   server.  Each party is responsible for verifying that the other's
-   certificate is valid and has not expired or been revoked.
-
-   The general goal of the key exchange process is to create a
-   pre_master_secret known to the communicating parties and not to
-   attackers.  The pre_master_secret will be used to generate the
-   master_secret (see Section 8.1).  The master_secret is required to
-   generate the Finished messages, encryption keys, and MAC keys (see
-   Sections 7.4.9 and 6.3).  By sending a correct Finished message,
-   parties thus prove that they know the correct pre_master_secret.
-
-F.1.1.1.  Anonymous Key Exchange
-
-   Completely anonymous sessions can be established using Diffie-Hellman
-   for key exchange.  The server's public parameters are contained in
-   the server key exchange message, and the client's are sent in the
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 91]
-
-RFC 5246                          TLS                        August 2008
-
-
-   client key exchange message.  Eavesdroppers who do not know the
-   private values should not be able to find the Diffie-Hellman result
-   (i.e., the pre_master_secret).
-
-   Warning: Completely anonymous connections only provide protection
-   against passive eavesdropping.  Unless an independent tamper-proof
-   channel is used to verify that the Finished messages were not
-   replaced by an attacker, server authentication is required in
-   environments where active man-in-the-middle attacks are a concern.
-
-F.1.1.2.  RSA Key Exchange and Authentication
-
-   With RSA, key exchange and server authentication are combined.  The
-   public key is contained in the server's certificate.  Note that
-   compromise of the server's static RSA key results in a loss of
-   confidentiality for all sessions protected under that static key.
-   TLS users desiring Perfect Forward Secrecy should use DHE cipher
-   suites.  The damage done by exposure of a private key can be limited
-   by changing one's private key (and certificate) frequently.
-
-   After verifying the server's certificate, the client encrypts a
-   pre_master_secret with the server's public key.  By successfully
-   decoding the pre_master_secret and producing a correct Finished
-   message, the server demonstrates that it knows the private key
-   corresponding to the server certificate.
-
-   When RSA is used for key exchange, clients are authenticated using
-   the certificate verify message (see Section 7.4.8).  The client signs
-   a value derived from all preceding handshake messages.  These
-   handshake messages include the server certificate, which binds the
-   signature to the server, and ServerHello.random, which binds the
-   signature to the current handshake process.
-
-F.1.1.3.  Diffie-Hellman Key Exchange with Authentication
-
-   When Diffie-Hellman key exchange is used, the server can either
-   supply a certificate containing fixed Diffie-Hellman parameters or
-   use the server key exchange message to send a set of temporary
-   Diffie-Hellman parameters signed with a DSA or RSA certificate.
-   Temporary parameters are hashed with the hello.random values before
-   signing to ensure that attackers do not replay old parameters.  In
-   either case, the client can verify the certificate or signature to
-   ensure that the parameters belong to the server.
-
-   If the client has a certificate containing fixed Diffie-Hellman
-   parameters, its certificate contains the information required to
-   complete the key exchange.  Note that in this case the client and
-   server will generate the same Diffie-Hellman result (i.e.,
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 92]
-
-RFC 5246                          TLS                        August 2008
-
-
-   pre_master_secret) every time they communicate.  To prevent the
-   pre_master_secret from staying in memory any longer than necessary,
-   it should be converted into the master_secret as soon as possible.
-   Client Diffie-Hellman parameters must be compatible with those
-   supplied by the server for the key exchange to work.
-
-   If the client has a standard DSA or RSA certificate or is
-   unauthenticated, it sends a set of temporary parameters to the server
-   in the client key exchange message, then optionally uses a
-   certificate verify message to authenticate itself.
-
-   If the same DH keypair is to be used for multiple handshakes, either
-   because the client or server has a certificate containing a fixed DH
-   keypair or because the server is reusing DH keys, care must be taken
-   to prevent small subgroup attacks.  Implementations SHOULD follow the
-   guidelines found in [SUBGROUP].
-
-   Small subgroup attacks are most easily avoided by using one of the
-   DHE cipher suites and generating a fresh DH private key (X) for each
-   handshake.  If a suitable base (such as 2) is chosen, g^X mod p can
-   be computed very quickly; therefore, the performance cost is
-   minimized.  Additionally, using a fresh key for each handshake
-   provides Perfect Forward Secrecy.  Implementations SHOULD generate a
-   new X for each handshake when using DHE cipher suites.
-
-   Because TLS allows the server to provide arbitrary DH groups, the
-   client should verify that the DH group is of suitable size as defined
-   by local policy.  The client SHOULD also verify that the DH public
-   exponent appears to be of adequate size.  [KEYSIZ] provides a useful
-   guide to the strength of various group sizes.  The server MAY choose
-   to assist the client by providing a known group, such as those
-   defined in [IKEALG] or [MODP].  These can be verified by simple
-   comparison.
-
-F.1.2.  Version Rollback Attacks
-
-   Because TLS includes substantial improvements over SSL Version 2.0,
-   attackers may try to make TLS-capable clients and servers fall back
-   to Version 2.0.  This attack can occur if (and only if) two TLS-
-   capable parties use an SSL 2.0 handshake.
-
-   Although the solution using non-random PKCS #1 block type 2 message
-   padding is inelegant, it provides a reasonably secure way for Version
-   3.0 servers to detect the attack.  This solution is not secure
-   against attackers who can brute-force the key and substitute a new
-   ENCRYPTED-KEY-DATA message containing the same key (but with normal
-   padding) before the application-specified wait threshold has expired.
-   Altering the padding of the least-significant 8 bytes of the PKCS
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 93]
-
-RFC 5246                          TLS                        August 2008
-
-
-   padding does not impact security for the size of the signed hashes
-   and RSA key lengths used in the protocol, since this is essentially
-   equivalent to increasing the input block size by 8 bytes.
-
-F.1.3.  Detecting Attacks Against the Handshake Protocol
-
-   An attacker might try to influence the handshake exchange to make the
-   parties select different encryption algorithms than they would
-   normally choose.
-
-   For this attack, an attacker must actively change one or more
-   handshake messages.  If this occurs, the client and server will
-   compute different values for the handshake message hashes.  As a
-   result, the parties will not accept each others' Finished messages.
-   Without the master_secret, the attacker cannot repair the Finished
-   messages, so the attack will be discovered.
-
-F.1.4.  Resuming Sessions
-
-   When a connection is established by resuming a session, new
-   ClientHello.random and ServerHello.random values are hashed with the
-   session's master_secret.  Provided that the master_secret has not
-   been compromised and that the secure hash operations used to produce
-   the encryption keys and MAC keys are secure, the connection should be
-   secure and effectively independent from previous connections.
-   Attackers cannot use known encryption keys or MAC secrets to
-   compromise the master_secret without breaking the secure hash
-   operations.
-
-   Sessions cannot be resumed unless both the client and server agree.
-   If either party suspects that the session may have been compromised,
-   or that certificates may have expired or been revoked, it should
-   force a full handshake.  An upper limit of 24 hours is suggested for
-   session ID lifetimes, since an attacker who obtains a master_secret
-   may be able to impersonate the compromised party until the
-   corresponding session ID is retired.  Applications that may be run in
-   relatively insecure environments should not write session IDs to
-   stable storage.
-
-F.2.  Protecting Application Data
-
-   The master_secret is hashed with the ClientHello.random and
-   ServerHello.random to produce unique data encryption keys and MAC
-   secrets for each connection.
-
-   Outgoing data is protected with a MAC before transmission.  To
-   prevent message replay or modification attacks, the MAC is computed
-   from the MAC key, the sequence number, the message length, the
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 94]
-
-RFC 5246                          TLS                        August 2008
-
-
-   message contents, and two fixed character strings.  The message type
-   field is necessary to ensure that messages intended for one TLS
-   record layer client are not redirected to another.  The sequence
-   number ensures that attempts to delete or reorder messages will be
-   detected.  Since sequence numbers are 64 bits long, they should never
-   overflow.  Messages from one party cannot be inserted into the
-   other's output, since they use independent MAC keys.  Similarly, the
-   server write and client write keys are independent, so stream cipher
-   keys are used only once.
-
-   If an attacker does break an encryption key, all messages encrypted
-   with it can be read.  Similarly, compromise of a MAC key can make
-   message-modification attacks possible.  Because MACs are also
-   encrypted, message-alteration attacks generally require breaking the
-   encryption algorithm as well as the MAC.
-
-   Note: MAC keys may be larger than encryption keys, so messages can
-   remain tamper resistant even if encryption keys are broken.
-
-F.3.  Explicit IVs
-
-   [CBCATT] describes a chosen plaintext attack on TLS that depends on
-   knowing the IV for a record.  Previous versions of TLS [TLS1.0] used
-   the CBC residue of the previous record as the IV and therefore
-   enabled this attack.  This version uses an explicit IV in order to
-   protect against this attack.
-
-F.4.  Security of Composite Cipher Modes
-
-   TLS secures transmitted application data via the use of symmetric
-   encryption and authentication functions defined in the negotiated
-   cipher suite.  The objective is to protect both the integrity and
-   confidentiality of the transmitted data from malicious actions by
-   active attackers in the network.  It turns out that the order in
-   which encryption and authentication functions are applied to the data
-   plays an important role for achieving this goal [ENCAUTH].
-
-   The most robust method, called encrypt-then-authenticate, first
-   applies encryption to the data and then applies a MAC to the
-   ciphertext.  This method ensures that the integrity and
-   confidentiality goals are obtained with ANY pair of encryption and
-   MAC functions, provided that the former is secure against chosen
-   plaintext attacks and that the MAC is secure against chosen-message
-   attacks.  TLS uses another method, called authenticate-then-encrypt,
-   in which first a MAC is computed on the plaintext and then the
-   concatenation of plaintext and MAC is encrypted.  This method has
-   been proven secure for CERTAIN combinations of encryption functions
-   and MAC functions, but it is not guaranteed to be secure in general.
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 95]
-
-RFC 5246                          TLS                        August 2008
-
-
-   In particular, it has been shown that there exist perfectly secure
-   encryption functions (secure even in the information-theoretic sense)
-   that combined with any secure MAC function, fail to provide the
-   confidentiality goal against an active attack.  Therefore, new cipher
-   suites and operation modes adopted into TLS need to be analyzed under
-   the authenticate-then-encrypt method to verify that they achieve the
-   stated integrity and confidentiality goals.
-
-   Currently, the security of the authenticate-then-encrypt method has
-   been proven for some important cases.  One is the case of stream
-   ciphers in which a computationally unpredictable pad of the length of
-   the message, plus the length of the MAC tag, is produced using a
-   pseudorandom generator and this pad is exclusive-ORed with the
-   concatenation of plaintext and MAC tag.  The other is the case of CBC
-   mode using a secure block cipher.  In this case, security can be
-   shown if one applies one CBC encryption pass to the concatenation of
-   plaintext and MAC and uses a new, independent, and unpredictable IV
-   for each new pair of plaintext and MAC.  In versions of TLS prior to
-   1.1, CBC mode was used properly EXCEPT that it used a predictable IV
-   in the form of the last block of the previous ciphertext.  This made
-   TLS open to chosen plaintext attacks.  This version of the protocol
-   is immune to those attacks.  For exact details in the encryption
-   modes proven secure, see [ENCAUTH].
-
-F.5.  Denial of Service
-
-   TLS is susceptible to a number of denial-of-service (DoS) attacks.
-   In particular, an attacker who initiates a large number of TCP
-   connections can cause a server to consume large amounts of CPU for
-   doing RSA decryption.  However, because TLS is generally used over
-   TCP, it is difficult for the attacker to hide his point of origin if
-   proper TCP SYN randomization is used [SEQNUM] by the TCP stack.
-
-   Because TLS runs over TCP, it is also susceptible to a number of DoS
-   attacks on individual connections.  In particular, attackers can
-   forge RSTs, thereby terminating connections, or forge partial TLS
-   records, thereby causing the connection to stall.  These attacks
-   cannot in general be defended against by a TCP-using protocol.
-   Implementors or users who are concerned with this class of attack
-   should use IPsec AH [AH] or ESP [ESP].
-
-F.6.  Final Notes
-
-   For TLS to be able to provide a secure connection, both the client
-   and server systems, keys, and applications must be secure.  In
-   addition, the implementation must be free of security errors.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 96]
-
-RFC 5246                          TLS                        August 2008
-
-
-   The system is only as strong as the weakest key exchange and
-   authentication algorithm supported, and only trustworthy
-   cryptographic functions should be used.  Short public keys and
-   anonymous servers should be used with great caution.  Implementations
-   and users must be careful when deciding which certificates and
-   certificate authorities are acceptable; a dishonest certificate
-   authority can do tremendous damage.
-
-Normative References
-
-   [AES]      National Institute of Standards and Technology,
-              "Specification for the Advanced Encryption Standard (AES)"
-              FIPS 197.  November 26, 2001.
-
-   [3DES]     National Institute of Standards and Technology,
-              "Recommendation for the Triple Data Encryption Algorithm
-              (TDEA) Block Cipher", NIST Special Publication 800-67, May
-              2004.
-
-   [DSS]      NIST FIPS PUB 186-2, "Digital Signature Standard",
-              National Institute of Standards and Technology, U.S.
-              Department of Commerce, 2000.
-
-   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-              Hashing for Message Authentication", RFC 2104, February
-              1997.
-
-   [MD5]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [PKCS1]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
-              Standards (PKCS) #1: RSA Cryptography Specifications
-              Version 2.1", RFC 3447, February 2003.
-
-   [PKIX]     Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and
-              Certificate Revocation List (CRL) Profile", RFC 3280,
-              April 2002.
-
-   [SCH]      B. Schneier. "Applied Cryptography: Protocols, Algorithms,
-              and Source Code in C, 2nd ed.", Published by John Wiley &
-              Sons, Inc. 1996.
-
-   [SHS]      NIST FIPS PUB 180-2, "Secure Hash Standard", National
-              Institute of Standards and Technology, U.S. Department of
-              Commerce, August 2002.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 97]
-
-RFC 5246                          TLS                        August 2008
-
-
-   [REQ]      Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [X680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
-              Information technology - Abstract Syntax Notation One
-              (ASN.1): Specification of basic notation.
-
-   [X690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
-              Information technology - ASN.1 encoding Rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER).
-
-Informative References
-
-   [AEAD]     McGrew, D., "An Interface and Algorithms for Authenticated
-              Encryption", RFC 5116, January 2008.
-
-   [AH]       Kent, S., "IP Authentication Header", RFC 4302, December
-              2005.
-
-   [BLEI]     Bleichenbacher D., "Chosen Ciphertext Attacks against
-              Protocols Based on RSA Encryption Standard PKCS #1" in
-              Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462,
-              pages:  1-12, 1998.
-
-   [CBCATT]   Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
-              Problems and Countermeasures",
-              http://www.openssl.org/~bodo/tls-cbc.txt.
-
-   [CBCTIME]  Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
-              "Password Interception in a SSL/TLS Channel", Advances in
-              Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
-
-   [CCM]      "NIST Special Publication 800-38C: The CCM Mode for
-              Authentication and Confidentiality",
-              http://csrc.nist.gov/publications/nistpubs/800-38C/
-              SP800-38C.pdf
-
-   [DES]      National Institute of Standards and Technology, "Data
-              Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 98]
-
-RFC 5246                          TLS                        August 2008
-
-
-   [DSS-3]    NIST FIPS PUB 186-3 Draft, "Digital Signature Standard",
-              National Institute of Standards and Technology, U.S.
-              Department of Commerce, 2006.
-
-   [ECDSA]    American National Standards Institute, "Public Key
-              Cryptography for the Financial Services Industry: The
-              Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS
-              X9.62-2005, November 2005.
-
-   [ENCAUTH]  Krawczyk, H., "The Order of Encryption and Authentication
-              for Protecting Communications (Or: How Secure is SSL?)",
-              Crypto 2001.
-
-   [ESP]      Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
-              4303, December 2005.
-
-   [FI06]     Hal Finney, "Bleichenbacher's RSA signature forgery based
-              on implementation error", ietf-openpgp@imc.org mailing
-              list, 27 August 2006, http://www.imc.org/ietf-openpgp/
-              mail-archive/msg14307.html.
-
-   [GCM]      Dworkin, M., NIST Special Publication 800-38D,
-              "Recommendation for Block Cipher Modes of Operation:
-              Galois/Counter Mode (GCM) and GMAC", November 2007.
-
-   [IKEALG]   Schiller, J., "Cryptographic Algorithms for Use in the
-              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
-              December 2005.
-
-   [KEYSIZ]   Orman, H. and P. Hoffman, "Determining Strengths For
-              Public Keys Used For Exchanging Symmetric Keys", BCP 86,
-              RFC 3766, April 2004.
-
-   [KPR03]    Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
-              Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
-              March 2003.
-
-   [MODP]     Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
-              Diffie-Hellman groups for Internet Key Exchange (IKE)",
-              RFC 3526, May 2003.
-
-   [PKCS6]    RSA Laboratories, "PKCS #6: RSA Extended Certificate
-              Syntax Standard", version 1.5, November 1993.
-
-   [PKCS7]    RSA Laboratories, "PKCS #7: RSA Cryptographic Message
-              Syntax Standard", version 1.5, November 1993.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                    [Page 99]
-
-RFC 5246                          TLS                        August 2008
-
-
-   [RANDOM]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-              "Randomness Requirements for Security", BCP 106, RFC 4086,
-              June 2005.
-
-   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
-              Compression Methods", RFC 3749, May 2004.
-
-   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
-              and T. Wright, "Transport Layer Security (TLS)
-              Extensions", RFC 4366, April 2006.
-
-   [RSA]      R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
-              Obtaining Digital Signatures and Public-Key
-              Cryptosystems", Communications of the ACM, v. 21, n. 2,
-              Feb 1978, pp. 120-126.
-
-   [SEQNUM]   Bellovin, S., "Defending Against Sequence Number Attacks",
-              RFC 1948, May 1996.
-
-   [SSL2]     Hickman, Kipp, "The SSL Protocol", Netscape Communications
-              Corp., Feb 9, 1995.
-
-   [SSL3]     A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0
-              Protocol", Netscape Communications Corp., Nov 18, 1996.
-
-   [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup"
-              Attacks on the Diffie-Hellman Key Agreement Method for
-              S/MIME", RFC 2785, March 2000.
-
-   [TCP]      Postel, J., "Transmission Control Protocol", STD 7, RFC
-              793, September 1981.
-
-   [TIMING]   Boneh, D., Brumley, D., "Remote timing attacks are
-              practical", USENIX Security Symposium 2003.
-
-   [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              3268, June 2002.
-
-   [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
-              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
-              for Transport Layer Security (TLS)", RFC 4492, May 2006.
-
-   [TLSEXT]   Eastlake, D., 3rd, "Transport Layer Security (TLS)
-              Extensions:  Extension Definitions", Work in Progress,
-              February 2008.
-
-
-
-
-
-Dierks & Rescorla           Standards Track                   [Page 100]
-
-RFC 5246                          TLS                        August 2008
-
-
-   [TLSPGP]   Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
-              Layer Security (TLS) Authentication", RFC 5081, November
-              2007.
-
-   [TLSPSK]   Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
-              Ciphersuites for Transport Layer Security (TLS)", RFC
-              4279, December 2005.
-
-   [TLS1.0]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-              RFC 2246, January 1999.
-
-   [TLS1.1]   Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [X501]     ITU-T Recommendation X.501: Information Technology - Open
-              Systems Interconnection - The Directory: Models, 1993.
-
-   [XDR]      Eisler, M., Ed., "XDR: External Data Representation
-              Standard", STD 67, RFC 4506, May 2006.
-
-Working Group Information
-
-   The discussion list for the IETF TLS working group is located at the
-   e-mail address <tls@ietf.org>. Information on the group and
-   information on how to subscribe to the list is at
-   <https://www1.ietf.org/mailman/listinfo/tls>
-
-   Archives of the list can be found at:
-   <http://www.ietf.org/mail-archive/web/tls/current/index.html>
-
-Contributors
-
-   Christopher Allen (co-editor of TLS 1.0)
-   Alacrity Ventures
-   ChristopherA@AlacrityManagement.com
-
-   Martin Abadi
-   University of California, Santa Cruz
-   abadi@cs.ucsc.edu
-
-   Steven M. Bellovin
-   Columbia University
-   smb@cs.columbia.edu
-
-   Simon Blake-Wilson
-   BCI
-   sblakewilson@bcisse.com
-
-
-
-
-Dierks & Rescorla           Standards Track                   [Page 101]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Ran Canetti
-   IBM
-   canetti@watson.ibm.com
-
-   Pete Chown
-   Skygate Technology Ltd
-   pc@skygate.co.uk
-
-   Taher Elgamal
-   taher@securify.com
-   Securify
-
-   Pasi Eronen
-   pasi.eronen@nokia.com
-   Nokia
-
-   Anil Gangolli
-   anil@busybuddha.org
-
-   Kipp Hickman
-
-   Alfred Hoenes
-
-   David Hopwood
-   Independent Consultant
-   david.hopwood@blueyonder.co.uk
-
-   Phil Karlton (co-author of SSLv3)
-
-   Paul Kocher (co-author of SSLv3)
-   Cryptography Research
-   paul@cryptography.com
-
-   Hugo Krawczyk
-   IBM
-   hugo@ee.technion.ac.il
-
-   Jan Mikkelsen
-   Transactionware
-   janm@transactionware.com
-
-   Magnus Nystrom
-   RSA Security
-   magnus@rsasecurity.com
-
-   Robert Relyea
-   Netscape Communications
-   relyea@netscape.com
-
-
-
-Dierks & Rescorla           Standards Track                   [Page 102]
-
-RFC 5246                          TLS                        August 2008
-
-
-   Jim Roskind
-   Netscape Communications
-   jar@netscape.com
-
-   Michael Sabin
-
-   Dan Simon
-   Microsoft, Inc.
-   dansimon@microsoft.com
-
-   Tom Weinstein
-
-   Tim Wright
-   Vodafone
-   timothy.wright@vodafone.com
-
-Editors' Addresses
-
-   Tim Dierks
-   Independent
-   EMail: tim@dierks.org
-
-   Eric Rescorla
-   RTFM, Inc.
-   EMail: ekr@rtfm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                   [Page 103]
-
-RFC 5246                          TLS                        August 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-Dierks & Rescorla           Standards Track                   [Page 104]
-
diff --git a/doc/protocol/rfc5764.txt b/doc/protocol/rfc5764.txt
deleted file mode 100644
index 6633f0083d..0000000000
--- a/doc/protocol/rfc5764.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Internet Engineering Task Force (IETF)                         D. McGrew
-Request for Comments: 5764                                 Cisco Systems
-Category: Standards Track                                    E. Rescorla
-ISSN: 2070-1721                                               RTFM, Inc.
-                                                                May 2010
-
-
-  Datagram Transport Layer Security (DTLS) Extension to Establish Keys
-           for the Secure Real-time Transport Protocol (SRTP)
-
-Abstract
-
-   This document describes a Datagram Transport Layer Security (DTLS)
-   extension to establish keys for Secure RTP (SRTP) and Secure RTP
-   Control Protocol (SRTCP) flows.  DTLS keying happens on the media
-   path, independent of any out-of-band signalling channel present.
-
-Status of This Memo
-
-   This is an Internet Standards Track document.
-
-   This document is a product of the Internet Engineering Task Force
-   (IETF).  It represents the consensus of the IETF community.  It has
-   received public review and has been approved for publication by the
-   Internet Engineering Steering Group (IESG).  Further information on
-   Internet Standards is available in Section 2 of RFC 5741.
-
-   Information about the current status of this document, any errata,
-   and how to provide feedback on it may be obtained at
-   http://www.rfc-editor.org/info/rfc5764.
-
-Copyright Notice
-
-   Copyright (c) 2010 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 1]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   This document may contain material from IETF Documents or IETF
-   Contributions published or made publicly available before November
-   10, 2008.  The person(s) controlling the copyright in some of this
-   material may not have granted the IETF Trust the right to allow
-   modifications of such material outside the IETF Standards Process.
-   Without obtaining an adequate license from the person(s) controlling
-   the copyright in such materials, this document may not be modified
-   outside the IETF Standards Process, and derivative works of it may
-   not be created outside the IETF Standards Process, except to format
-   it for publication as an RFC or to translate it into languages other
-   than English.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Conventions Used In This Document  . . . . . . . . . . . . . .  3
-   3.  Overview of DTLS-SRTP Operation  . . . . . . . . . . . . . . .  4
-   4.  DTLS Extensions for SRTP Key Establishment . . . . . . . . . .  5
-     4.1.  The use_srtp Extension . . . . . . . . . . . . . . . . . .  5
-       4.1.1.  use_srtp Extension Definition  . . . . . . . . . . . .  7
-       4.1.2.  SRTP Protection Profiles . . . . . . . . . . . . . . .  8
-       4.1.3.  srtp_mki value . . . . . . . . . . . . . . . . . . . .  9
-     4.2.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . 10
-     4.3.  Key Scope  . . . . . . . . . . . . . . . . . . . . . . . . 12
-     4.4.  Key Usage Limitations  . . . . . . . . . . . . . . . . . . 12
-   5.  Use of RTP and RTCP over a DTLS-SRTP Channel . . . . . . . . . 13
-     5.1.  Data Protection  . . . . . . . . . . . . . . . . . . . . . 13
-       5.1.1.  Transmission . . . . . . . . . . . . . . . . . . . . . 13
-       5.1.2.  Reception  . . . . . . . . . . . . . . . . . . . . . . 13
-     5.2.  Rehandshake and Rekey  . . . . . . . . . . . . . . . . . . 16
-   6.  Multi-Party RTP Sessions . . . . . . . . . . . . . . . . . . . 17
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
-     7.1.  Security of Negotiation  . . . . . . . . . . . . . . . . . 17
-     7.2.  Framing Confusion  . . . . . . . . . . . . . . . . . . . . 17
-     7.3.  Sequence Number Interactions . . . . . . . . . . . . . . . 18
-       7.3.1.  Alerts . . . . . . . . . . . . . . . . . . . . . . . . 18
-       7.3.2.  Renegotiation  . . . . . . . . . . . . . . . . . . . . 18
-     7.4.  Decryption Cost  . . . . . . . . . . . . . . . . . . . . . 19
-   8.  Session Description for RTP/SAVP over DTLS . . . . . . . . . . 19
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
-   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
-   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-     11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
-     11.2. Informative References . . . . . . . . . . . . . . . . . . 21
-   Appendix A.  Overview of DTLS  . . . . . . . . . . . . . . . . . . 23
-   Appendix B.  Performance of Multiple DTLS Handshakes . . . . . . . 24
-
-
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 2]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-1.  Introduction
-
-   The Secure RTP (SRTP) profile [RFC3711] can provide confidentiality,
-   message authentication, and replay protection to RTP data and RTP
-   Control (RTCP) traffic.  SRTP does not provide key management
-   functionality, but instead depends on external key management to
-   exchange secret master keys, and to negotiate the algorithms and
-   parameters for use with those keys.
-
-   Datagram Transport Layer Security (DTLS) [RFC4347] is a channel
-   security protocol that offers integrated key management, parameter
-   negotiation, and secure data transfer.  Because DTLS data transfer
-   protocol is generic, it is less highly optimized for use with RTP
-   than is SRTP, which has been specifically tuned for that purpose.
-
-   This document describes DTLS-SRTP, a SRTP extension for DTLS that
-   combines the performance and encryption flexibility benefits of SRTP
-   with the flexibility and convenience of DTLS-integrated key and
-   association management.  DTLS-SRTP can be viewed in two equivalent
-   ways: as a new key management method for SRTP, and a new RTP-specific
-   data format for DTLS.
-
-   The key points of DTLS-SRTP are that:
-
-   o  application data is protected using SRTP,
-
-   o  the DTLS handshake is used to establish keying material,
-      algorithms, and parameters for SRTP,
-
-   o  a DTLS extension is used to negotiate SRTP algorithms, and
-
-   o  other DTLS record-layer content types are protected using the
-      ordinary DTLS record format.
-
-   The remainder of this memo is structured as follows.  Section 2
-   describes conventions used to indicate normative requirements.
-   Section 3 provides an overview of DTLS-SRTP operation.  Section 4
-   specifies the DTLS extensions, while Section 5 discusses how RTP and
-   RTCP are transported over a DTLS-SRTP channel.  Section 6 describes
-   use with multi-party sessions.  Section 7 and Section 9 describe
-   Security and IANA considerations.
-
-2.  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 [RFC2119].
-
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 3]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-3.  Overview of DTLS-SRTP Operation
-
-   DTLS-SRTP is defined for point-to-point media sessions, in which
-   there are exactly two participants.  Each DTLS-SRTP session contains
-   a single DTLS association (called a "connection" in TLS jargon), and
-   either two SRTP contexts (if media traffic is flowing in both
-   directions on the same host/port quartet) or one SRTP context (if
-   media traffic is only flowing in one direction).  All SRTP traffic
-   flowing over that pair in a given direction uses a single SRTP
-   context.  A single DTLS-SRTP session only protects data carried over
-   a single UDP source and destination port pair.
-
-   The general pattern of DTLS-SRTP is as follows.  For each RTP or RTCP
-   flow the peers do a DTLS handshake on the same source and destination
-   port pair to establish a DTLS association.  Which side is the DTLS
-   client and which side is the DTLS server must be established via some
-   out-of-band mechanism such as SDP.  The keying material from that
-   handshake is fed into the SRTP stack.  Once that association is
-   established, RTP packets are protected (becoming SRTP) using that
-   keying material.
-
-   RTP and RTCP traffic is usually sent on two separate UDP ports.  When
-   symmetric RTP [RFC4961] is used, two bidirectional DTLS-SRTP sessions
-   are needed, one for the RTP port, one for the RTCP port.  When RTP
-   flows are not symmetric, four unidirectional DTLS-SRTP sessions are
-   needed (for inbound and outbound RTP, and inbound and outbound RTCP).
-
-   Symmetric RTP [RFC4961] is the case in which there are two RTP
-   sessions that have their source and destination ports and addresses
-   reversed, in a manner similar to the way that a TCP connection uses
-   its ports.  Each participant has an inbound RTP session and an
-   outbound RTP session.  When symmetric RTP is used, a single DTLS-SRTP
-   session can protect both of the RTP sessions.  It is RECOMMENDED that
-   symmetric RTP be used with DTLS-SRTP.
-
-   RTP and RTCP traffic MAY be multiplexed on a single UDP port
-   [RFC5761].  In this case, both RTP and RTCP packets may be sent over
-   the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions
-   needed.  This improves the cryptographic performance of DTLS, but may
-   cause problems when RTCP and RTP are subject to different network
-   treatment (e.g., for bandwidth reservation or scheduling reasons).
-
-   Between a single pair of participants, there may be multiple media
-   sessions.  There MUST be a separate DTLS-SRTP session for each
-   distinct pair of source and destination ports used by a media session
-   (though the sessions can share a single DTLS session and hence
-   amortize the initial public key handshake!).
-
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 4]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   A DTLS-SRTP session may be indicated by an external signaling
-   protocol like SIP.  When the signaling exchange is integrity-
-   protected (e.g., when SIP Identity protection via digital signatures
-   is used), DTLS-SRTP can leverage this integrity guarantee to provide
-   complete security of the media stream.  A description of how to
-   indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to
-   authenticate the endpoints using fingerprints can be found in
-   [RFC5763].
-
-   In a naive implementation, when there are multiple media sessions,
-   there is a new DTLS session establishment (complete with public key
-   cryptography) for each media channel.  For example, a videophone may
-   be sending both an audio stream and a video stream, each of which
-   would use a separate DTLS session establishment exchange, which would
-   proceed in parallel.  As an optimization, the DTLS-SRTP
-   implementation SHOULD use the following strategy: a single DTLS
-   association is established, and all other DTLS associations wait
-   until that connection is established before proceeding with their
-   handshakes.  This strategy allows the later sessions to use DTLS
-   session resumption, which allows the amortization of the expensive
-   public key cryptography operations over multiple DTLS handshakes.
-
-   The SRTP keys used to protect packets originated by the client are
-   distinct from the SRTP keys used to protect packets originated by the
-   server.  All of the RTP sources originating on the client for the
-   same channel use the same SRTP keys, and similarly, all of the RTP
-   sources originating on the server for the same channel use the same
-   SRTP keys.  The SRTP implementation MUST ensure that all of the
-   synchronization source (SSRC) values for all of the RTP sources
-   originating from the same device over the same channel are distinct,
-   in order to avoid the "two-time pad" problem (as described in Section
-   9.1 of RFC 3711).  Note that this is not an issue for separate media
-   streams (on different host/port quartets) that use independent keying
-   material even if an SSRC collision occurs.
-
-4.  DTLS Extensions for SRTP Key Establishment
-
-4.1.  The use_srtp Extension
-
-   In order to negotiate the use of SRTP data protection, clients
-   include an extension of type "use_srtp" in the DTLS extended client
-   hello.  This extension MUST only be used when the data being
-   transported is RTP or RTCP [RFC3550].  The "extension_data" field of
-   this extension contains the list of acceptable SRTP protection
-   profiles, as indicated below.
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 5]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   Servers that receive an extended hello containing a "use_srtp"
-   extension can agree to use SRTP by including an extension of type
-   "use_srtp", with the chosen protection profile in the extended server
-   hello.  This process is shown below.
-
-         Client                                               Server
-
-         ClientHello + use_srtp       -------->
-                                              ServerHello + use_srtp
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         SRTP packets                 <------->      SRTP packets
-
-   Note that '*' indicates messages that are not always sent in DTLS.
-   The CertificateRequest, client and server Certificates, and
-   CertificateVerify will be sent in DTLS-SRTP.
-
-   Once the "use_srtp" extension is negotiated, the RTP or RTCP
-   application data is protected solely using SRTP.  Application data is
-   never sent in DTLS record-layer "application_data" packets.  Rather,
-   complete RTP or RTCP packets are passed to the DTLS stack, which
-   passes them to the SRTP stack, which protects them appropriately.
-   Note that if RTP/RTCP multiplexing [RFC5761] is in use, this means
-   that RTP and RTCP packets may both be passed to the DTLS stack.
-   Because the DTLS layer does not process the packets, it does not need
-   to distinguish them.  The SRTP stack can use the procedures of
-   [RFC5761] to distinguish RTP from RTCP.
-
-   When the "use_srtp" extension is in effect, implementations must not
-   place more than one application data "record" per datagram.  (This is
-   only meaningful from the perspective of DTLS because SRTP is
-   inherently oriented towards one payload per packet, but this is
-   stated purely for clarification.)
-
-   Data other than RTP/RTCP (i.e., TLS control messages) MUST use
-   ordinary DTLS framing and MUST be placed in separate datagrams from
-   SRTP data.
-
-
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 6]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   A DTLS-SRTP handshake establishes one or more SRTP crypto contexts;
-   however, they all have the same SRTP Protection Profile and Master
-   Key Identifier (MKI), if any.  MKIs are used solely to distinguish
-   the keying material and protection profiles between distinct
-   handshakes, for instance, due to rekeying.  When an MKI is
-   established in a DTLS-SRTP session, it MUST apply for all of the
-   SSRCs within that session -- though a single endpoint may negotiate
-   multiple DTLS-SRTP sessions due, for instance, to forking.  (Note
-   that RFC 3711 allows packets within the same session but with
-   different SSRCs to use MKIs differently; in contrast, DTLS-SRTP
-   requires that MKIs and the keys that they are associated with have
-   the same meaning and are uniform across the entire SRTP session.)
-
-4.1.1.  use_srtp Extension Definition
-
-   The client MUST fill the extension_data field of the "use_srtp"
-   extension with an UseSRTPData value (see Section 9 for the
-   registration):
-
-      uint8 SRTPProtectionProfile[2];
-
-      struct {
-         SRTPProtectionProfiles SRTPProtectionProfiles;
-         opaque srtp_mki<0..255>;
-      } UseSRTPData;
-
-      SRTPProtectionProfile SRTPProtectionProfiles<2..2^16-1>;
-
-   The SRTPProtectionProfiles list indicates the SRTP protection
-   profiles that the client is willing to support, listed in descending
-   order of preference.  The srtp_mki value contains the SRTP Master Key
-   Identifier (MKI) value (if any) that the client will use for his SRTP
-   packets.  If this field is of zero length, then no MKI will be used.
-
-   Note: for those unfamiliar with TLS syntax, "srtp_mki<0..255>"
-   indicates a variable-length value with a length between 0 and 255
-   (inclusive).  Thus, the MKI may be up to 255 bytes long.
-
-   If the server is willing to accept the use_srtp extension, it MUST
-   respond with its own "use_srtp" extension in the ExtendedServerHello.
-   The extension_data field MUST contain a UseSRTPData value with a
-   single SRTPProtectionProfile value that the server has chosen for use
-   with this connection.  The server MUST NOT select a value that the
-   client has not offered.  If there is no shared profile, the server
-   SHOULD NOT return the use_srtp extension at which point the
-   connection falls back to the negotiated DTLS cipher suite.  If that
-   is not acceptable, the server SHOULD return an appropriate DTLS
-   alert.
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 7]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-4.1.2.  SRTP Protection Profiles
-
-   A DTLS-SRTP SRTP Protection Profile defines the parameters and
-   options that are in effect for the SRTP processing.  This document
-   defines the following SRTP protection profiles.
-
-      SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_80 = {0x00, 0x01};
-      SRTPProtectionProfile SRTP_AES128_CM_HMAC_SHA1_32 = {0x00, 0x02};
-      SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_80      = {0x00, 0x05};
-      SRTPProtectionProfile SRTP_NULL_HMAC_SHA1_32      = {0x00, 0x06};
-
-   The following list indicates the SRTP transform parameters for each
-   protection profile.  The parameters cipher_key_length,
-   cipher_salt_length, auth_key_length, and auth_tag_length express the
-   number of bits in the values to which they refer.  The
-   maximum_lifetime parameter indicates the maximum number of packets
-   that can be protected with each single set of keys when the parameter
-   profile is in use.  All of these parameters apply to both RTP and
-   RTCP, unless the RTCP parameters are separately specified.
-
-   All of the crypto algorithms in these profiles are from [RFC3711].
-
-   SRTP_AES128_CM_HMAC_SHA1_80
-         cipher: AES_128_CM
-         cipher_key_length: 128
-         cipher_salt_length: 112
-         maximum_lifetime: 2^31
-         auth_function: HMAC-SHA1
-         auth_key_length: 160
-         auth_tag_length: 80
-   SRTP_AES128_CM_HMAC_SHA1_32
-         cipher: AES_128_CM
-         cipher_key_length: 128
-         cipher_salt_length: 112
-         maximum_lifetime: 2^31
-         auth_function: HMAC-SHA1
-         auth_key_length: 160
-         auth_tag_length: 32
-         RTCP auth_tag_length: 80
-   SRTP_NULL_HMAC_SHA1_80
-         cipher: NULL
-         cipher_key_length: 0
-         cipher_salt_length: 0
-         maximum_lifetime: 2^31
-         auth_function: HMAC-SHA1
-         auth_key_length: 160
-         auth_tag_length: 80
-
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 8]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   SRTP_NULL_HMAC_SHA1_32
-         cipher: NULL
-         cipher_key_length: 0
-         cipher_salt_length: 0
-         maximum_lifetime: 2^31
-         auth_function: HMAC-SHA1
-         auth_key_length: 160
-         auth_tag_length: 32
-         RTCP auth_tag_length: 80
-
-   With all of these SRTP Parameter profiles, the following SRTP options
-   are in effect:
-
-   o  The TLS PseudoRandom Function (PRF) is used to generate keys to
-      feed into the SRTP Key Derivation Function (KDF).  When DTLS 1.2
-      [DTLS1.2] is in use, the PRF is the one associated with the cipher
-      suite.  Note that this specification is compatible with DTLS 1.0
-      or DTLS 1.2
-
-   o  The Key Derivation Rate (KDR) is equal to zero.  Thus, keys are
-      not re-derived based on the SRTP sequence number.
-
-   o  The key derivation procedures from Section 4.3 with the AES-CM PRF
-      from RFC 3711 are used.
-
-   o  For all other parameters (in particular, SRTP replay window size
-      and FEC order), the default values are used.
-
-   If values other than the defaults for these parameters are required,
-   they can be enabled by writing a separate specification specifying
-   SDP syntax to signal them.
-
-   Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection
-   Profiles between the DTLS-SRTP session that protects an RTP flow and
-   the DTLS-SRTP session that protects the associated RTCP flow (in
-   those cases in which the RTP and RTCP are not multiplexed over a
-   common port).  In particular, identical ciphers SHOULD be used.
-
-   New SRTPProtectionProfile values must be defined according to the
-   "Specification Required" policy as defined by RFC 5226 [RFC5226].
-   See Section 9 for IANA Considerations.
-
-4.1.3.  srtp_mki value
-
-   The srtp_mki value MAY be used to indicate the capability and desire
-   to use the SRTP Master Key Identifier (MKI) field in the SRTP and
-   SRTCP packets.  The MKI field indicates to an SRTP receiver which key
-   was used to protect the packet that contains that field.  The
-
-
-
-McGrew & Rescorla            Standards Track                    [Page 9]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   srtp_mki field contains the value of the SRTP MKI which is associated
-   with the SRTP master keys derived from this handshake.  Each SRTP
-   session MUST have exactly one master key that is used to protect
-   packets at any given time.  The client MUST choose the MKI value so
-   that it is distinct from the last MKI value that was used, and it
-   SHOULD make these values unique for the duration of the TLS session.
-
-   Upon receipt of a "use_srtp" extension containing a "srtp_mki" field,
-   the server MUST either (assuming it accepts the extension at all):
-
-   1.  include a matching "srtp_mki" value in its "use_srtp" extension
-       to indicate that it will make use of the MKI, or
-   2.  return an empty "srtp_mki" value to indicate that it cannot make
-       use of the MKI.
-
-   If the client detects a nonzero-length MKI in the server's response
-   that is different than the one the client offered, then the client
-   MUST abort the handshake and SHOULD send an invalid_parameter alert.
-   If the client and server agree on an MKI, all SRTP packets protected
-   under the new security parameters MUST contain that MKI.
-
-   Note that any given DTLS-SRTP session only has a single active MKI
-   (if any).  Thus, at any given time, a set of endpoints will generally
-   only be using one MKI (the major exception is during rehandshakes).
-
-4.2.  Key Derivation
-
-   When SRTP mode is in effect, different keys are used for ordinary
-   DTLS record protection and SRTP packet protection.  These keys are
-   generated using a TLS exporter [RFC5705] to generate
-
-   2 * (SRTPSecurityParams.master_key_len +
-        SRTPSecurityParams.master_salt_len) bytes of data
-
-   which are assigned as shown below.  The per-association context value
-   is empty.
-
-   client_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
-   server_write_SRTP_master_key[SRTPSecurityParams.master_key_len];
-   client_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
-   server_write_SRTP_master_salt[SRTPSecurityParams.master_salt_len];
-
-   The exporter label for this usage is "EXTRACTOR-dtls_srtp".  (The
-   "EXTRACTOR" prefix is for historical compatibility.)
-
-   The four keying material values (the master key and master salt for
-   each direction) are provided as inputs to the SRTP key derivation
-   mechanism, as shown in Figure 1 and detailed below.  By default, the
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 10]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   mechanism defined in Section 4.3 of [RFC3711] is used, unless another
-   key derivation mechanism is specified as part of an SRTP Protection
-   Profile.
-
-   The client_write_SRTP_master_key and client_write_SRTP_master_salt
-   are provided to one invocation of the SRTP key derivation function,
-   to generate the SRTP keys used to encrypt and authenticate packets
-   sent by the client.  The server MUST only use these keys to decrypt
-   and to check the authenticity of inbound packets.
-
-   The server_write_SRTP_master_key and server_write_SRTP_master_salt
-   are provided to one invocation of the SRTP key derivation function,
-   to generate the SRTP keys used to encrypt and authenticate packets
-   sent by the server.  The client MUST only use these keys to decrypt
-   and to check the authenticity of inbound packets.
-
-   TLS master
-     secret   label
-      |         |
-      v         v
-   +---------------+
-   | TLS extractor |
-   +---------------+
-          |                                         +------+   SRTP
-          +-> client_write_SRTP_master_key ----+--->| SRTP |-> client
-          |                                    | +->| KDF  |   write
-          |                                    | |  +------+   keys
-          |                                    | |
-          +-> server_write_SRTP_master_key --  | |  +------+   SRTCP
-          |                                  \ \--->|SRTCP |-> client
-          |                                   \  +->| KDF  |   write
-          |                                    | |  +------+   keys
-          +-> client_write_SRTP_master_salt ---|-+
-          |                                    |
-          |                                    |    +------+   SRTP
-          |                                    +--->| SRTP |-> server
-          +-> server_write_SRTP_master_salt -+-|--->| KDF  |   write
-                                             | |    +------+   keys
-                                             | |
-                                             | |    +------+   SRTCP
-                                             | +--->|SRTCP |-> server
-                                             +----->| KDF  |   write
-                                                    +------+   keys
-
-                Figure 1: The derivation of the SRTP keys.
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 11]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   When both RTCP and RTP use the same source and destination ports,
-   then both the SRTP and SRTCP keys are needed.  Otherwise, there are
-   two DTLS-SRTP sessions, one of which protects the RTP packets and one
-   of which protects the RTCP packets; each DTLS-SRTP session protects
-   the part of an SRTP session that passes over a single source/
-   destination transport address pair, as shown in Figure 2, independent
-   of which SSRCs are used on that pair.  When a DTLS-SRTP session is
-   protecting RTP, the SRTCP keys derived from the DTLS handshake are
-   not needed and are discarded.  When a DTLS-SRTP session is protecting
-   RTCP, the SRTP keys derived from the DTLS handshake are not needed
-   and are discarded.
-
-      Client            Server
-     (Sender)         (Receiver)
-   (1)   <----- DTLS ------>    src/dst = a/b and b/a
-         ------ SRTP ------>    src/dst = a/b, uses client write keys
-
-   (2)   <----- DTLS ------>    src/dst = c/d and d/c
-         ------ SRTCP ----->    src/dst = c/d, uses client write keys
-         <----- SRTCP ------    src/dst = d/c, uses server write keys
-
-     Figure 2: A DTLS-SRTP session protecting RTP (1) and another one
-    protecting RTCP (2), showing the transport addresses and keys used.
-
-4.3.  Key Scope
-
-   Because of the possibility of packet reordering, DTLS-SRTP
-   implementations SHOULD store multiple SRTP keys sets during a rekey
-   in order to avoid the need for receivers to drop packets for which
-   they lack a key.
-
-4.4.  Key Usage Limitations
-
-   The maximum_lifetime parameter in the SRTP protection profile
-   indicates the maximum number of packets that can be protected with
-   each single encryption and authentication key.  (Note that, since RTP
-   and RTCP are protected with independent keys, those protocols are
-   counted separately for the purposes of determining when a key has
-   reached the end of its lifetime.)  Each profile defines its own
-   limit.  When this limit is reached, a new DTLS session SHOULD be used
-   to establish replacement keys, and SRTP implementations MUST NOT use
-   the existing keys for the processing of either outbound or inbound
-   traffic.
-
-
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 12]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-5.  Use of RTP and RTCP over a DTLS-SRTP Channel
-
-5.1.  Data Protection
-
-   Once the DTLS handshake has completed, the peers can send RTP or RTCP
-   over the newly created channel.  We describe the transmission process
-   first followed by the reception process.
-
-   Within each RTP session, SRTP processing MUST NOT take place before
-   the DTLS handshake completes.
-
-5.1.1.  Transmission
-
-   DTLS and TLS define a number of record content types.  In ordinary
-   TLS/DTLS, all data is protected using the same record encoding and
-   mechanisms.  When the mechanism described in this document is in
-   effect, this is modified so that data written by upper-level protocol
-   clients of DTLS is assumed to be RTP/RTP and is encrypted using SRTP
-   rather than the standard TLS record encoding.
-
-   When a user of DTLS wishes to send an RTP packet in SRTP mode, it
-   delivers it to the DTLS implementation as an ordinary application
-   data write (e.g., SSL_write()).  The DTLS implementation then invokes
-   the processing described in RFC 3711, Sections 3 and 4.  The
-   resulting SRTP packet is then sent directly on the wire as a single
-   datagram with no DTLS framing.  This provides an encapsulation of the
-   data that conforms to and interoperates with SRTP.  Note that the RTP
-   sequence number rather than the DTLS sequence number is used for
-   these packets.
-
-5.1.2.  Reception
-
-   When DTLS-SRTP is used to protect an RTP session, the RTP receiver
-   needs to demultiplex packets that are arriving on the RTP port.
-   Arriving packets may be of types RTP, DTLS, or STUN [RFC5389].  If
-   these are the only types of packets present, the type of a packet can
-   be determined by looking at its first byte.
-
-   The process for demultiplexing a packet is as follows.  The receiver
-   looks at the first byte of the packet.  If the value of this byte is
-   0 or 1, then the packet is STUN.  If the value is in between 128 and
-   191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and
-   RTP are being multiplexed over the same destination port).  If the
-   value is between 20 and 63 (inclusive), the packet is DTLS.  This
-   process is summarized in Figure 3.
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 13]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-                   +----------------+
-                   | 127 < B < 192 -+--> forward to RTP
-                   |                |
-       packet -->  |  19 < B < 64  -+--> forward to DTLS
-                   |                |
-                   |       B < 2   -+--> forward to STUN
-                   +----------------+
-
-    Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
-         Here the field B denotes the leading byte of the packet.
-
-   If other packet types are to be multiplexed as well, implementors
-   and/or designers SHOULD ensure that they can be demultiplexed from
-   these three packet types.
-
-   In some cases, there will be multiple DTLS-SRTP associations for a
-   given SRTP endpoint.  For instance, if Alice makes a call that is SIP
-   forked to both Bob and Charlie, she will use the same local host/port
-   pair for both of them, as shown in Figure 4, where XXX and YYY
-   represent different DTLS-SRTP associations.  (The SSRCs shown are the
-   ones for data flowing to Alice.)
-
-                                          Bob (192.0.2.1:6666)
-                                         /
-                                        /
-                                       / SSRC=1
-                                      /  DTLS-SRTP=XXX
-                                     /
-                                    v
-               Alice (192.0.2.0:5555)
-                                    ^
-                                     \
-                                      \  SSRC=2
-                                       \ DTLS-SRTP=YYY
-                                        \
-                                         \
-                                          Charlie (192.0.2.2:6666)
-
-                 Figure 4: RTP sessions with SIP forking.
-
-   Because DTLS operates on the host/port quartet, the DTLS association
-   will still complete correctly, with the foreign host/port pair being
-   used, to distinguish the associations.  However, in RTP the source
-   host/port is not used and sessions are identified by the destination
-   host/port and the SSRC.  Thus, some mechanism is needed to determine
-   which SSRCs correspond to which DTLS associations.  The following
-   method SHOULD be used.
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 14]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   For each local host/port pair, the DTLS-SRTP implementation maintains
-   a table listing all the SSRCs it knows about and the DTLS-SRTP
-   associations they correspond to.  Initially, this table is empty.
-   When an SRTP packet is received for a given RTP endpoint (destination
-   IP/port pair), the following procedure is used:
-
-   1.  If the SSRC is already known for that endpoint, then the
-       corresponding DTLS-SRTP association and its keying material is
-       used to decrypt and verify the packet.
-   2.  If the SSRC is not known, then the receiver tries to decrypt it
-       with the keying material corresponding to each DTLS-SRTP
-       association for that endpoint.
-   3.  If the decryption and verification succeeds (the authentication
-       tag verifies), then an entry is placed in the table mapping the
-       SSRC to that association.
-   4.  If the decryption and verification fails, then the packet is
-       silently discarded.
-   5.  When a DTLS-SRTP association is closed (for instance, because the
-       fork is abandoned), its entries MUST be removed from the mapping
-       table.
-
-   The average cost of this algorithm for a single SSRC is the
-   decryption and verification time of a single packet times the number
-   of valid DTLS-SRTP associations corresponding to a single receiving
-   port on the host.  In practice, this means the number of forks; so in
-   the case shown in Figure 4, that would be two.  This cost is only
-   incurred once for any given SSRC, since afterwards that SSRC is
-   placed in the map table and looked up immediately.  As with normal
-   RTP, this algorithm allows new SSRCs to be introduced by the source
-   at any time.  They will automatically be mapped to the correct DTLS
-   association.
-
-   Note that this algorithm explicitly allows multiple SSRCs to be sent
-   from the same address/port pair.  One way in which this can happen is
-   an RTP translator.  This algorithm will automatically assign the
-   SSRCs to the correct associations.  Note that because the SRTP
-   packets are cryptographically protected, such a translator must
-   either share keying material with one endpoint or refrain from
-   modifying the packets in a way which would cause the integrity check
-   to fail.  This is a general property of SRTP and is not specific to
-   DTLS-SRTP.
-
-   There are two error cases that should be considered.  First, if an
-   SSRC collision occurs, then only the packets from the first source
-   will be processed.  When the packets from the second source arrive,
-   the DTLS association with the first source will be used for
-   decryption and verification, which will fail, and the packet will be
-   discarded.  This is consistent with [RFC3550], which permits the
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 15]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   receiver to keep the packets from one source and discard those from
-   the other.  Of course the RFC 3550 SSRC collision detection and
-   handling procedures MUST also be followed.
-
-   Second, there may be cases where a malfunctioning source is sending
-   corrupt packets that cannot be decrypted and verified.  In this case,
-   the SSRC will never be entered into the mapping table because the
-   decryption and verification always fails.  Receivers MAY keep records
-   of unmapped SSRCs that consistently fail decryption and verification
-   and abandon attempts to process them once they reach some limit.
-   That limit MUST be large enough to account for the effects of
-   transmission errors.  Entries MUST be pruned from this table when the
-   relevant SRTP endpoint is deleted (e.g., the call ends) and SHOULD
-   time out faster than that (we do not offer a hard recommendation but
-   10 to 30 seconds seems appropriate) in order to allow for the
-   possibility that the peer implementation has been corrected.
-
-5.2.  Rehandshake and Rekey
-
-   Rekeying in DTLS is accomplished by performing a new handshake over
-   the existing DTLS channel.  That is, the handshake messages are
-   protected by the existing DTLS cipher suite.  This handshake can be
-   performed in parallel with data transport, so no interruption of the
-   data flow is required.  Once the handshake is finished, the newly
-   derived set of keys is used to protect all outbound packets, both
-   DTLS and SRTP.
-
-   Because of packet reordering, packets protected by the previous set
-   of keys can appear on the wire after the handshake has completed.  To
-   compensate for this fact, receivers SHOULD maintain both sets of keys
-   for some time in order to be able to decrypt and verify older
-   packets.  The keys should be maintained for the duration of the
-   maximum segment lifetime (MSL).
-
-   If an MKI is used, then the receiver should use the corresponding set
-   of keys to process an incoming packet.  If no matching MKI is
-   present, the packet MUST be rejected.  Otherwise, when a packet
-   arrives after the handshake completed, a receiver SHOULD use the
-   newly derived set of keys to process that packet unless there is an
-   MKI.  (If the packet was protected with the older set of keys, this
-   fact will become apparent to the receiver as an authentication
-   failure will occur.)  If the authentication check on the packet fails
-   and no MKI is being used, then the receiver MAY process the packet
-   with the older set of keys.  If that authentication check indicates
-   that the packet is valid, the packet should be accepted; otherwise,
-   the packet MUST be discarded and rejected.
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 16]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   Receivers MAY use the SRTP packet sequence number to aid in the
-   selection of keys.  After a packet has been received and
-   authenticated with the new key set, any packets with sequence numbers
-   that are greater will also have been protected with the new key set.
-
-6.  Multi-Party RTP Sessions
-
-   Since DTLS is a point-to-point protocol, DTLS-SRTP is intended only
-   to protect unicast RTP sessions.  This does not preclude its use with
-   RTP mixers.  For example, a conference bridge may use DTLS-SRTP to
-   secure the communication to and from each of the participants in a
-   conference.  However, because each flow between an endpoint and a
-   mixer has its own key, the mixer has to decrypt and then reencrypt
-   the traffic for each recipient.
-
-   A future specification may describe methods for sharing a single key
-   between multiple DTLS-SRTP associations thus allowing conferencing
-   systems to avoid the decrypt/reencrypt stage.  However, any system in
-   which the media is modified (e.g., for level balancing or
-   transcoding) will generally need to be performed on the plaintext and
-   will certainly break the authentication tag, and therefore will
-   require a decrypt/reencrypt stage.
-
-7.  Security Considerations
-
-   The use of multiple data protection framings negotiated in the same
-   handshake creates some complexities, which are discussed here.
-
-7.1.  Security of Negotiation
-
-   One concern here is that attackers might be able to implement a bid-
-   down attack forcing the peers to use ordinary DTLS rather than SRTP.
-   However, because the negotiation of this extension is performed in
-   the DTLS handshake, it is protected by the Finished messages.
-   Therefore, any bid-down attack is automatically detected, which
-   reduces this to a denial-of-service attack -- which can be mounted by
-   any attacker who can control the channel.
-
-7.2.  Framing Confusion
-
-   Because two different framing formats are used, there is concern that
-   an attacker could convince the receiver to treat an SRTP-framed RTP
-   packet as a DTLS record (e.g., a handshake message) or vice versa.
-   This attack is prevented by using different keys for Message
-   Authentication Code (MAC) verification for each type of data.
-   Therefore, this type of attack reduces to being able to forge a
-   packet with a valid MAC, which violates a basic security invariant of
-   both DTLS and SRTP.
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 17]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   As an additional defense against injection into the DTLS handshake
-   channel, the DTLS record type is included in the MAC.  Therefore, an
-   SRTP record would be treated as an unknown type and ignored.  (See
-   Section 6 of [RFC5246].)
-
-7.3.  Sequence Number Interactions
-
-   As described in Section 5.1.1, the SRTP and DTLS sequence number
-   spaces are distinct.  This means that it is not possible to
-   unambiguously order a given DTLS control record with respect to an
-   SRTP packet.  In general, this is relevant in two situations: alerts
-   and rehandshake.
-
-7.3.1.  Alerts
-
-   Because DTLS handshake and change_cipher_spec messages share the same
-   sequence number space as alerts, they can be ordered correctly.
-   Because DTLS alerts are inherently unreliable and SHOULD NOT be
-   generated as a response to data packets, reliable sequencing between
-   SRTP packets and DTLS alerts is not an important feature.  However,
-   implementations that wish to use DTLS alerts to signal problems with
-   the SRTP encoding SHOULD simply act on alerts as soon as they are
-   received and assume that they refer to the temporally contiguous
-   stream.  Such implementations MUST check for alert retransmission and
-   discard retransmitted alerts to avoid overreacting to replay attacks.
-
-7.3.2.  Renegotiation
-
-   Because the rehandshake transition algorithm specified in Section 5.2
-   requires trying multiple sets of keys if no MKI is used, it slightly
-   weakens the authentication.  For instance, if an n-bit MAC is used
-   and k different sets of keys are present, then the MAC is weakened by
-   log_2(k) bits to n - log_2(k).  In practice, since the number of keys
-   used will be very small and the MACs in use are typically strong (the
-   default for SRTP is 80 bits), the decrease in security involved here
-   is minimal.
-
-   Another concern here is that this algorithm slightly increases the
-   work factor on the receiver because it needs to attempt multiple
-   validations.  However, again, the number of potential keys will be
-   very small (and the attacker cannot force it to be larger) and this
-   technique is already used for rollover counter management, so the
-   authors do not consider this to be a serious flaw.
-
-
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 18]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-7.4.  Decryption Cost
-
-   An attacker can impose computational costs on the receiver by sending
-   superficially valid SRTP packets that do not decrypt correctly.  In
-   general, encryption algorithms are so fast that this cost is
-   extremely small compared to the bandwidth consumed.  The SSRC-DTLS
-   mapping algorithm described in Section 5.1.2 gives the attacker a
-   slight advantage here because he can force the receiver to do more
-   then one decryption per packet.  However, this advantage is modest
-   because the number of decryptions that the receiver does is limited
-   by the number of associations he has corresponding to a given
-   destination host/port, which is typically quite small.  For
-   comparison, a single 1024-bit RSA private key operation (the typical
-   minimum cost to establish a DTLS-SRTP association) is hundreds of
-   times as expensive as decrypting an SRTP packet.
-
-   Implementations can detect this form of attack by keeping track of
-   the number of SRTP packets that are observed with unknown SSRCs and
-   that fail the authentication tag check.  If under such attack,
-   implementations SHOULD prioritize decryption and verification of
-   packets that either have known SSRCs or come from source addresses
-   that match those of peers with which it has DTLS-SRTP associations.
-
-8.  Session Description for RTP/SAVP over DTLS
-
-   This specification defines new tokens to describe the protocol used
-   in SDP media descriptions ("m=" lines and their associated
-   parameters).  The new values defined for the proto field are:
-
-   o  When a RTP/SAVP or RTP/SAVPF [RFC5124] stream is transported over
-      DTLS with the Datagram Congestion Control Protocol (DCCP), then
-      the token SHALL be DCCP/TLS/RTP/SAVP or DCCP/TLS/RTP/SAVPF
-      respectively.
-
-   o  When a RTP/SAVP or RTP/SAVPF stream is transported over DTLS with
-      UDP, the token SHALL be UDP/TLS/RTP/SAVP or UDP/TLS/RTP/SAVPF
-      respectively.
-
-   The "fmt" parameter SHALL be as defined for RTP/SAVP.
-
-   See [RFC5763] for how to use offer/answer with DTLS-SRTP.
-
-   This document does not specify how to protect RTP data transported
-   over TCP.  Potential approaches include carrying the RTP over TLS
-   over TCP (see [SRTP-NOT-MAND]) or using a mechanism similar to that
-   in this document over TCP, either via TLS or DTLS, with DTLS being
-   used for consistency between reliable and unreliable transports.  In
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 19]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   the latter case, it would be necessary to profile DTLS so that
-   fragmentation and retransmissions no longer occurred.  In either
-   case, a new document would be required.
-
-9.  IANA Considerations
-
-   This document adds a new extension for DTLS, in accordance with
-   [RFC5246]:
-        enum { use_srtp (14) } ExtensionType;
-
-   This extension MUST only be used with DTLS, and not with TLS
-   [RFC4572], which specifies that TLS can be used over TCP but does not
-   address TCP for RTP/SAVP.
-
-   Section 4.1.2 requires that all SRTPProtectionProfile values be
-   defined by RFC 5226 "Specification Required".  IANA has created a
-   DTLS SRTPProtectionProfile registry initially populated with values
-   from Section 4.1.2 of this document.  Future values MUST be allocated
-   via the "Specification Required" profile of [RFC5226].
-
-   This specification updates the "Session Description Protocol (SDP)
-   Parameters" registry as defined in Section 8.2.2 of [RFC4566].
-   Specifically, it adds the following values to the table for the
-   "proto" field.
-
-           Type            SDP Name                     Reference
-           ----            ------------------           ---------
-           proto           UDP/TLS/RTP/SAVP             [RFC5764]
-           proto           DCCP/TLS/RTP/SAVP            [RFC5764]
-
-           proto           UDP/TLS/RTP/SAVPF            [RFC5764]
-           proto           DCCP/TLS/RTP/SAVPF           [RFC5764]
-
-   IANA has registered the "EXTRACTOR-dtls_srtp" value in the TLS
-   Extractor Label Registry to correspond to this specification.
-
-10.  Acknowledgments
-
-   Special thanks to Flemming Andreasen, Francois Audet, Pasi Eronen,
-   Roni Even, Jason Fischl, Cullen Jennings, Colin Perkins, Dan Wing,
-   and Ben Campbell for input, discussions, and guidance.  Pasi Eronen
-   provided Figure 1.
-
-
-
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 20]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-11.  References
-
-11.1.  Normative References
-
-   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
-                    Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3711]        Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
-                    and K. Norrman, "The Secure Real-time Transport
-                    Protocol (SRTP)", RFC 3711, March 2004.
-
-   [RFC4347]        Rescorla, E. and N. Modadugu, "Datagram Transport
-                    Layer Security", RFC 4347, April 2006.
-
-   [RFC4961]        Wing, D., "Symmetric RTP / RTP Control Protocol
-                    (RTCP)", BCP 131, RFC 4961, July 2007.
-
-   [RFC5246]        Dierks, T. and E. Rescorla, "The Transport Layer
-                    Security (TLS) Protocol Version 1.2", RFC 5246,
-                    August 2008.
-
-   [RFC5705]        Rescorla, E., "Keying Material Exporters for
-                    Transport Layer Security (TLS)", RFC 5705,
-                    March 2010.
-
-   [RFC5761]        Perkins, C. and M. Westerlund, "Multiplexing RTP
-                    Data and Control Packets on a Single Port",
-                    RFC 5761, April 2010.
-
-11.2.  Informative References
-
-   [DTLS1.2]        Rescorla, E. and N. Modadugu, "Datagram Transport
-                    Layer Security version 1.2", Work in Progress,
-                    October 2009.
-
-   [RFC3550]        Schulzrinne, H., Casner, S., Frederick, R., and V.
-                    Jacobson, "RTP: A Transport Protocol for Real-Time
-                    Applications", STD 64, RFC 3550, July 2003.
-
-   [RFC4566]        Handley, M., Jacobson, V., and C. Perkins, "SDP:
-                    Session Description Protocol", RFC 4566, July 2006.
-
-   [RFC4572]        Lennox, J., "Connection-Oriented Media Transport
-                    over the Transport Layer Security (TLS) Protocol in
-                    the Session Description Protocol (SDP)", RFC 4572,
-                    July 2006.
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 21]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   [RFC5124]        Ott, J. and E. Carrara, "Extended Secure RTP Profile
-                    for Real-time Transport Control Protocol (RTCP)-
-                    Based Feedback (RTP/SAVPF)", RFC 5124,
-                    February 2008.
-
-   [RFC5226]        Narten, T. and H. Alvestrand, "Guidelines for
-                    Writing an IANA Considerations Section in RFCs",
-                    BCP 26, RFC 5226, May 2008.
-
-   [RFC5389]        Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
-                    "Session Traversal Utilities for NAT (STUN)",
-                    RFC 5389, October 2008.
-
-   [RFC5763]        Fischl, J., Tschofenig, H., and E. Rescorla,
-                    "Framework for Establishing a Secure Real-time
-                    Transport Protocol (SRTP) Security Context Using
-                    Datagram Transport Layer Security (DTLS)", RFC 5763,
-                    May 2010.
-
-   [SRTP-NOT-MAND]  Perkins, C. and M. Westerlund, "Why RTP Does Not
-                    Mandate a Single Security Mechanism", Work in
-                    Progress, January 2010.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 22]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-Appendix A.  Overview of DTLS
-
-   This section provides a brief overview of Datagram TLS (DTLS) for
-   those who are not familiar with it.  DTLS is a channel security
-   protocol based on the well-known Transport Layer Security (TLS)
-   [RFC5246] protocol.  Where TLS depends on a reliable transport
-   channel (typically TCP), DTLS has been adapted to support unreliable
-   transports such as UDP.  Otherwise, DTLS is nearly identical to TLS
-   and generally supports the same cryptographic mechanisms.
-
-   Each DTLS association begins with a handshake exchange (shown below)
-   during which the peers authenticate each other and negotiate
-   algorithms, modes, and other parameters and establish shared keying
-   material, as shown below.  In order to support unreliable transport,
-   each side maintains retransmission timers to provide reliable
-   delivery of these messages.  Once the handshake is completed,
-   encrypted data may be sent.
-
-         Client                                               Server
-
-         ClientHello                  -------->
-                                                         ServerHello
-                                                        Certificate*
-                                                  ServerKeyExchange*
-                                                 CertificateRequest*
-                                      <--------      ServerHelloDone
-         Certificate*
-         ClientKeyExchange
-         CertificateVerify*
-         [ChangeCipherSpec]
-         Finished                     -------->
-                                                  [ChangeCipherSpec]
-                                      <--------             Finished
-         Application Data             <------->     Application Data
-
-               '*' indicates messages that are not always sent.
-
-        Figure 5: Basic DTLS Handshake Exchange (after [RFC4347]).
-
-   Application data is protected by being sent as a series of DTLS
-   "records".  These records are independent and can be processed
-   correctly even in the face of loss or reordering.  In DTLS-SRTP, this
-   record protocol is replaced with SRTP [RFC3711]
-
-
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 23]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-Appendix B.  Performance of Multiple DTLS Handshakes
-
-   Standard practice for security protocols such as TLS, DTLS, and SSH,
-   which do inline key management, is to create a separate security
-   association for each underlying network channel (TCP connection, UDP
-   host/port quartet, etc.).  This has dual advantages of simplicity and
-   independence of the security contexts for each channel.
-
-   Three concerns have been raised about the overhead of this strategy
-   in the context of RTP security.  The first concern is the additional
-   performance overhead of doing a separate public key operation for
-   each channel.  The conventional procedure here (used in TLS and DTLS)
-   is to establish a master context that can then be used to derive
-   fresh traffic keys for new associations.  In TLS/DTLS, this is called
-   "session resumption" and can be transparently negotiated between the
-   peers.
-
-   The second concern is network bandwidth overhead for the
-   establishment of subsequent connections and for rehandshake (for
-   rekeying) for existing connections.  In particular, there is a
-   concern that the channels will have very narrow capacity requirements
-   allocated entirely to media that will be overflowed by the
-   rehandshake.  Measurements of the size of the rehandshake (with
-   resumption) in TLS indicate that it is about 300-400 bytes if a full
-   selection of cipher suites is offered.  (The size of a full handshake
-   is approximately 1-2 kilobytes larger because of the certificate and
-   keying material exchange.)
-
-   The third concern is the additional round-trips associated with
-   establishing the second, third, ... channels.  In TLS/DTLS, these can
-   all be done in parallel, but in order to take advantage of session
-   resumption they should be done after the first channel is
-   established.  For two channels, this provides a ladder diagram
-   something like this (parenthetical numbers are media channel numbers)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 24]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   Alice                                   Bob
-   -------------------------------------------
-                      <-       ClientHello (1)
-   ServerHello (1)    ->
-   Certificate (1)
-   ServerHelloDone (1)
-                      <- ClientKeyExchange (1)
-                          ChangeCipherSpec (1)
-                                  Finished (1)
-   ChangeCipherSpec (1)->
-   Finished         (1)->
-                                                <--- Channel 1 ready
-
-                      <-       ClientHello (2)
-   ServerHello (2)    ->
-   ChangeCipherSpec(2)->
-   Finished(2)        ->
-                      <-  ChangeCipherSpec (2)
-                                  Finished (2)
-                                                <--- Channel 2 ready
-
-                Figure 6: Parallel DTLS-SRTP negotiations.
-
-   So, there is an additional 1 RTT (round-trip time) after Channel 1 is
-   ready before Channel 2 is ready.  If the peers are potentially
-   willing to forego resumption, they can interlace the handshakes, like
-   so:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 25]
-
-RFC 5764                 SRTP Extension for DTLS                May 2010
-
-
-   Alice                                   Bob
-   -------------------------------------------
-                      <-       ClientHello (1)
-   ServerHello (1)    ->
-   Certificate (1)
-   ServerHelloDone (1)
-                      <- ClientKeyExchange (1)
-                          ChangeCipherSpec (1)
-                                  Finished (1)
-                      <-       ClientHello (2)
-   ChangeCipherSpec (1)->
-   Finished         (1)->
-                                                <--- Channel 1 ready
-   ServerHello (2)    ->
-   ChangeCipherSpec(2)->
-   Finished(2)        ->
-                      <-  ChangeCipherSpec (2)
-                                  Finished (2)
-                                                <--- Channel 2 ready
-
-               Figure 7: Interlaced DTLS-SRTP negotiations.
-
-   In this case, the channels are ready contemporaneously, but if a
-   message in handshake (1) is lost, then handshake (2) requires either
-   a full rehandshake or that Alice be clever and queue the resumption
-   attempt until the first handshake completes.  Note that just dropping
-   the packet works as well, since Bob will retransmit.
-
-Authors' Addresses
-
-   David McGrew
-   Cisco Systems
-   510 McCarthy Blvd.
-   Milpitas, CA  95305
-   USA
-
-   EMail: mcgrew@cisco.com
-
-
-   Eric Rescorla
-   RTFM, Inc.
-   2064 Edgewood Drive
-   Palo Alto, CA  94303
-   USA
-
-   EMail: ekr@rtfm.com
-
-
-
-
-
-McGrew & Rescorla            Standards Track                   [Page 26]
-
diff --git a/doc/protocol/rfc6520.txt b/doc/protocol/rfc6520.txt
deleted file mode 100644
index 19329da225..0000000000
--- a/doc/protocol/rfc6520.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Internet Engineering Task Force (IETF)                     R. Seggelmann
-Request for Comments: 6520                                     M. Tuexen
-Category: Standards Track               Muenster Univ. of Appl. Sciences
-ISSN: 2070-1721                                              M. Williams
-                                                   GWhiz Arts & Sciences
-                                                           February 2012
-
-
-                   Transport Layer Security (TLS) and
-      Datagram Transport Layer Security (DTLS) Heartbeat Extension
-
-Abstract
-
-   This document describes the Heartbeat Extension for the Transport
-   Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
-   protocols.
-
-   The Heartbeat Extension provides a new protocol for TLS/DTLS allowing
-   the usage of keep-alive functionality without performing a
-   renegotiation and a basis for path MTU (PMTU) discovery for DTLS.
-
-Status of This Memo
-
-   This is an Internet Standards Track document.
-
-   This document is a product of the Internet Engineering Task Force
-   (IETF).  It represents the consensus of the IETF community.  It has
-   received public review and has been approved for publication by the
-   Internet Engineering Steering Group (IESG).  Further information on
-   Internet Standards is available in Section 2 of RFC 5741.
-
-   Information about the current status of this document, any errata,
-   and how to provide feedback on it may be obtained at
-   http://www.rfc-editor.org/info/rfc6520.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 1]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-Copyright Notice
-
-   Copyright (c) 2012 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents
-   (http://trustee.ietf.org/license-info) in effect on the date of
-   publication of this document.  Please review these documents
-   carefully, as they describe your rights and restrictions with respect
-   to this document.  Code Components extracted from this document must
-   include Simplified BSD License text as described in Section 4.e of
-   the Trust Legal Provisions and are provided without warranty as
-   described in the Simplified BSD License.
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
-   2.  Heartbeat Hello Extension . . . . . . . . . . . . . . . . . . . 3
-   3.  Heartbeat Protocol  . . . . . . . . . . . . . . . . . . . . . . 4
-   4.  Heartbeat Request and Response Messages . . . . . . . . . . . . 5
-   5.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
-   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
-   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
-   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-
-1.  Introduction
-
-1.1.  Overview
-
-   This document describes the Heartbeat Extension for the Transport
-   Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
-   protocols, as defined in [RFC5246] and [RFC6347] and their
-   adaptations to specific transport protocols described in [RFC3436],
-   [RFC5238], and [RFC6083].
-
-   DTLS is designed to secure traffic running on top of unreliable
-   transport protocols.  Usually, such protocols have no session
-   management.  The only mechanism available at the DTLS layer to figure
-   out if a peer is still alive is a costly renegotiation, particularly
-   when the application uses unidirectional traffic.  Furthermore, DTLS
-   needs to perform path MTU (PMTU) discovery but has no specific
-   message type to realize it without affecting the transfer of user
-   messages.
-
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 2]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-   TLS is based on reliable protocols, but there is not necessarily a
-   feature available to keep the connection alive without continuous
-   data transfer.
-
-   The Heartbeat Extension as described in this document overcomes these
-   limitations.  The user can use the new HeartbeatRequest message,
-   which has to be answered by the peer with a HeartbeartResponse
-   immediately.  To perform PMTU discovery, HeartbeatRequest messages
-   containing padding can be used as probe packets, as described in
-   [RFC4821].
-
-1.2.  Conventions
-
-   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 [RFC2119].
-
-2.  Heartbeat Hello Extension
-
-   The support of Heartbeats is indicated with Hello Extensions.  A peer
-   cannot only indicate that its implementation supports Heartbeats, it
-   can also choose whether it is willing to receive HeartbeatRequest
-   messages and respond with HeartbeatResponse messages or only willing
-   to send HeartbeatRequest messages.  The former is indicated by using
-   peer_allowed_to_send as the HeartbeatMode; the latter is indicated by
-   using peer_not_allowed_to_send as the Heartbeat mode.  This decision
-   can be changed with every renegotiation.  HeartbeatRequest messages
-   MUST NOT be sent to a peer indicating peer_not_allowed_to_send.  If
-   an endpoint that has indicated peer_not_allowed_to_send receives a
-   HeartbeatRequest message, the endpoint SHOULD drop the message
-   silently and MAY send an unexpected_message Alert message.
-
-   The format of the Heartbeat Hello Extension is defined by:
-
-   enum {
-      peer_allowed_to_send(1),
-      peer_not_allowed_to_send(2),
-      (255)
-   } HeartbeatMode;
-
-   struct {
-      HeartbeatMode mode;
-   } HeartbeatExtension;
-
-   Upon reception of an unknown mode, an error Alert message using
-   illegal_parameter as its AlertDescription MUST be sent in response.
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 3]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-3.  Heartbeat Protocol
-
-   The Heartbeat protocol is a new protocol running on top of the Record
-   Layer.  The protocol itself consists of two message types:
-   HeartbeatRequest and HeartbeatResponse.
-
-   enum {
-      heartbeat_request(1),
-      heartbeat_response(2),
-      (255)
-   } HeartbeatMessageType;
-
-   A HeartbeatRequest message can arrive almost at any time during the
-   lifetime of a connection.  Whenever a HeartbeatRequest message is
-   received, it SHOULD be answered with a corresponding
-   HeartbeatResponse message.
-
-   However, a HeartbeatRequest message SHOULD NOT be sent during
-   handshakes.  If a handshake is initiated while a HeartbeatRequest is
-   still in flight, the sending peer MUST stop the DTLS retransmission
-   timer for it.  The receiving peer SHOULD discard the message
-   silently, if it arrives during the handshake.  In case of DTLS,
-   HeartbeatRequest messages from older epochs SHOULD be discarded.
-
-   There MUST NOT be more than one HeartbeatRequest message in flight at
-   a time.  A HeartbeatRequest message is considered to be in flight
-   until the corresponding HeartbeatResponse message is received, or
-   until the retransmit timer expires.
-
-   When using an unreliable transport protocol like the Datagram
-   Congestion Control Protocol (DCCP) or UDP, HeartbeatRequest messages
-   MUST be retransmitted using the simple timeout and retransmission
-   scheme DTLS uses for flights as described in Section 4.2.4 of
-   [RFC6347].  In particular, after a number of retransmissions without
-   receiving a corresponding HeartbeatResponse message having the
-   expected payload, the DTLS connection SHOULD be terminated.  The
-   threshold used for this SHOULD be the same as for DTLS handshake
-   messages.  Please note that after the timer supervising a
-   HeartbeatRequest messages expires, this message is no longer
-   considered in flight.  Therefore, the HeartbeatRequest message is
-   eligible for retransmission.  The retransmission scheme, in
-   combination with the restriction that only one HeartbeatRequest is
-   allowed to be in flight, ensures that congestion control is handled
-   appropriately in case of the transport protocol not providing one,
-   like in the case of DTLS over UDP.
-
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 4]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-   When using a reliable transport protocol like the Stream Control
-   Transmission Protocol (SCTP) or TCP, HeartbeatRequest messages only
-   need to be sent once.  The transport layer will handle
-   retransmissions.  If no corresponding HeartbeatResponse message has
-   been received after some amount of time, the DTLS/TLS connection MAY
-   be terminated by the application that initiated the sending of the
-   HeartbeatRequest message.
-
-4.  Heartbeat Request and Response Messages
-
-   The Heartbeat protocol messages consist of their type and an
-   arbitrary payload and padding.
-
-   struct {
-      HeartbeatMessageType type;
-      uint16 payload_length;
-      opaque payload[HeartbeatMessage.payload_length];
-      opaque padding[padding_length];
-   } HeartbeatMessage;
-
-   The total length of a HeartbeatMessage MUST NOT exceed 2^14 or
-   max_fragment_length when negotiated as defined in [RFC6066].
-
-   type:  The message type, either heartbeat_request or
-      heartbeat_response.
-
-   payload_length:  The length of the payload.
-
-   payload:  The payload consists of arbitrary content.
-
-   padding:  The padding is random content that MUST be ignored by the
-      receiver.  The length of a HeartbeatMessage is TLSPlaintext.length
-      for TLS and DTLSPlaintext.length for DTLS.  Furthermore, the
-      length of the type field is 1 byte, and the length of the
-      payload_length is 2.  Therefore, the padding_length is
-      TLSPlaintext.length - payload_length - 3 for TLS and
-      DTLSPlaintext.length - payload_length - 3 for DTLS.  The
-      padding_length MUST be at least 16.
-
-   The sender of a HeartbeatMessage MUST use a random padding of at
-   least 16 bytes.  The padding of a received HeartbeatMessage message
-   MUST be ignored.
-
-   If the payload_length of a received HeartbeatMessage is too large,
-   the received HeartbeatMessage MUST be discarded silently.
-
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 5]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-   When a HeartbeatRequest message is received and sending a
-   HeartbeatResponse is not prohibited as described elsewhere in this
-   document, the receiver MUST send a corresponding HeartbeatResponse
-   message carrying an exact copy of the payload of the received
-   HeartbeatRequest.
-
-   If a received HeartbeatResponse message does not contain the expected
-   payload, the message MUST be discarded silently.  If it does contain
-   the expected payload, the retransmission timer MUST be stopped.
-
-5.  Use Cases
-
-   Each endpoint sends HeartbeatRequest messages at a rate and with the
-   padding required for the particular use case.  The endpoint should
-   not expect its peer to send HeartbeatRequests.  The directions are
-   independent.
-
-5.1.  Path MTU Discovery
-
-   DTLS performs path MTU discovery as described in Section 4.1.1.1 of
-   [RFC6347].  A detailed description of how to perform path MTU
-   discovery is given in [RFC4821].  The necessary probe packets are the
-   HeartbeatRequest messages.
-
-   This method of using HeartbeatRequest messages for DTLS is similar to
-   the one for the Stream Control Transmission Protocol (SCTP) using the
-   padding chunk (PAD-chunk) defined in [RFC4820].
-
-5.2.  Liveliness Check
-
-   Sending HeartbeatRequest messages allows the sender to make sure that
-   it can reach the peer and the peer is alive.  Even in the case of
-   TLS/TCP, this allows a check at a much higher rate than the TCP keep-
-   alive feature would allow.
-
-   Besides making sure that the peer is still reachable, sending
-   HeartbeatRequest messages refreshes the NAT state of all involved
-   NATs.
-
-   HeartbeatRequest messages SHOULD only be sent after an idle period
-   that is at least multiple round-trip times long.  This idle period
-   SHOULD be configurable up to a period of multiple minutes and down to
-   a period of one second.  A default value for the idle period SHOULD
-   be configurable, but it SHOULD also be tunable on a per-peer basis.
-
-
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 6]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-6.  IANA Considerations
-
-   IANA has assigned the heartbeat content type (24) from the "TLS
-   ContentType Registry" as specified in [RFC5246].  The reference is to
-   RFC 6520.
-
-   IANA has created and now maintains a new registry for Heartbeat
-   Message Types.  The message types are numbers in the range from 0 to
-   255 (decimal).  IANA has assigned the heartbeat_request (1) and the
-   heartbeat_response (2) message types.  The values 0 and 255 should be
-   reserved.  This registry uses the Expert Review policy as described
-   in [RFC5226].  The reference is to RFC 6520.
-
-   IANA has assigned the heartbeat extension type (15) from the TLS
-   "ExtensionType Values" registry as specified in [RFC5246].  The
-   reference is to RFC 6520.
-
-   IANA has created and now maintains a new registry for Heartbeat
-   Modes.  The modes are numbers in the range from 0 to 255 (decimal).
-   IANA has assigned the peer_allowed_to_send (1) and the
-   peer_not_allowed_to_send (2) modes.  The values 0 and 255 should be
-   reserved.  This registry uses the Expert Review policy as described
-   in [RFC5226].  The reference is to RFC 6520.
-
-7.  Security Considerations
-
-   The security considerations of [RFC5246] and [RFC6347] apply to this
-   document.  This document does not introduce any new security
-   considerations.
-
-8.  Acknowledgments
-
-   The authors wish to thank Pasi Eronen, Adrian Farrel, Stephen
-   Farrell, Adam Langley, Nikos Mavrogiannopoulos, Tom Petch, Eric
-   Rescorla, Peter Saint-Andre, and Juho Vaehae-Herttua for their
-   invaluable comments.
-
-9.  References
-
-9.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
-              May 2008.
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 7]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
-
-   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
-              Extension Definitions", RFC 6066, January 2011.
-
-   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
-              Security Version 1.2", RFC 6347, January 2012.
-
-9.2.  Informative References
-
-   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
-              Layer Security over Stream Control Transmission Protocol",
-              RFC 3436, December 2002.
-
-   [RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
-              Parameter for the Stream Control Transmission Protocol
-              (SCTP)", RFC 4820, March 2007.
-
-   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
-              Discovery", RFC 4821, March 2007.
-
-   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over
-              the Datagram Congestion Control Protocol (DCCP)",
-              RFC 5238, May 2008.
-
-   [RFC6083]  Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
-              Transport Layer Security (DTLS) for Stream Control
-              Transmission Protocol (SCTP)", RFC 6083, January 2011.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 8]
-
-RFC 6520              TLS/DTLS Heartbeat Extension         February 2012
-
-
-Authors' Addresses
-
-   Robin Seggelmann
-   Muenster University of Applied Sciences
-   Stegerwaldstr. 39
-   48565 Steinfurt
-   DE
-
-   EMail: seggelmann@fh-muenster.de
-
-
-   Michael Tuexen
-   Muenster University of Applied Sciences
-   Stegerwaldstr. 39
-   48565 Steinfurt
-   DE
-
-   EMail: tuexen@fh-muenster.de
-
-
-   Michael Glenn Williams
-   GWhiz Arts & Sciences
-   2885 Denise Court
-   Newbury Park, CA, 91320
-   USA
-
-   EMail: michael.glenn.williams@gmail.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Seggelmann, et al.           Standards Track                    [Page 9]
-
diff --git a/doc/protocol/rrc2.doc b/doc/protocol/rrc2.doc
deleted file mode 100644
index f93ee003d2..0000000000
--- a/doc/protocol/rrc2.doc
+++ /dev/null
@@ -1,219 +0,0 @@
->From cygnus.mincom.oz.au!minbne.mincom.oz.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!comp.vuw.ac.nz!waikato!auckland.ac.nz!news Mon Feb 12 18:48:17 EST 1996
-Article 23601 of sci.crypt:
-Path: cygnus.mincom.oz.au!minbne.mincom.oz.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!comp.vuw.ac.nz!waikato!auckland.ac.nz!news
->From: pgut01@cs.auckland.ac.nz (Peter Gutmann)
-Newsgroups: sci.crypt
-Subject: Specification for Ron Rivests Cipher No.2
-Date: 11 Feb 1996 06:45:03 GMT
-Organization: University of Auckland
-Lines: 203
-Sender: pgut01@cs.auckland.ac.nz (Peter Gutmann)
-Message-ID: <4fk39f$f70@net.auckland.ac.nz>
-NNTP-Posting-Host: cs26.cs.auckland.ac.nz
-X-Newsreader: NN version 6.5.0 #3 (NOV)
-
-
-
-
-                           Ron Rivest's Cipher No.2
-                           ------------------------
- 
-Ron Rivest's Cipher No.2 (hereafter referred to as RRC.2, other people may
-refer to it by other names) is word oriented, operating on a block of 64 bits
-divided into four 16-bit words, with a key table of 64 words.  All data units
-are little-endian.  This functional description of the algorithm is based in
-the paper "The RC5 Encryption Algorithm" (RC5 is a trademark of RSADSI), using
-the same general layout, terminology, and pseudocode style.
- 
- 
-Notation and RRC.2 Primitive Operations
- 
-RRC.2 uses the following primitive operations:
- 
-1. Two's-complement addition of words, denoted by "+".  The inverse operation,
-   subtraction, is denoted by "-".
-2. Bitwise exclusive OR, denoted by "^".
-3. Bitwise AND, denoted by "&".
-4. Bitwise NOT, denoted by "~".
-5. A left-rotation of words; the rotation of word x left by y is denoted
-   x <<< y.  The inverse operation, right-rotation, is denoted x >>> y.
- 
-These operations are directly and efficiently supported by most processors.
- 
- 
-The RRC.2 Algorithm
- 
-RRC.2 consists of three components, a *key expansion* algorithm, an
-*encryption* algorithm, and a *decryption* algorithm.
- 
- 
-Key Expansion
- 
-The purpose of the key-expansion routine is to expand the user's key K to fill
-the expanded key array S, so S resembles an array of random binary words
-determined by the user's secret key K.
- 
-Initialising the S-box
- 
-RRC.2 uses a single 256-byte S-box derived from the ciphertext contents of
-Beale Cipher No.1 XOR'd with a one-time pad.  The Beale Ciphers predate modern
-cryptography by enough time that there should be no concerns about trapdoors
-hidden in the data.  They have been published widely, and the S-box can be
-easily recreated from the one-time pad values and the Beale Cipher data taken
-from a standard source.  To initialise the S-box:
- 
-  for i = 0 to 255 do
-    sBox[ i ] = ( beale[ i ] mod 256 ) ^ pad[ i ]
- 
-The contents of Beale Cipher No.1 and the necessary one-time pad are given as
-an appendix at the end of this document.  For efficiency, implementors may wish
-to skip the Beale Cipher expansion and store the sBox table directly.
- 
-Expanding the Secret Key to 128 Bytes
- 
-The secret key is first expanded to fill 128 bytes (64 words).  The expansion
-consists of taking the sum of the first and last bytes in the user key, looking
-up the sum (modulo 256) in the S-box, and appending the result to the key.  The
-operation is repeated with the second byte and new last byte of the key until
-all 128 bytes have been generated.  Note that the following pseudocode treats
-the S array as an array of 128 bytes rather than 64 words.
- 
-  for j = 0 to length-1 do
-    S[ j ] = K[ j ]
-  for j = length to 127 do
-    s[ j ] = sBox[ ( S[ j-length ] + S[ j-1 ] ) mod 256 ];
- 
-At this point it is possible to perform a truncation of the effective key
-length to ease the creation of espionage-enabled software products.  However
-since the author cannot conceive why anyone would want to do this, it will not
-be considered further.
- 
-The final phase of the key expansion involves replacing the first byte of S
-with the entry selected from the S-box:
- 
-  S[ 0 ] = sBox[ S[ 0 ] ]
- 
- 
-Encryption
- 
-The cipher has 16 full rounds, each divided into 4 subrounds.  Two of the full
-rounds perform an additional transformation on the data.  Note that the
-following pseudocode treats the S array as an array of 64 words rather than 128
-bytes.
- 
-  for i = 0 to 15 do
-    j = i * 4;
-    word0 = ( word0 + ( word1 & ~word3 ) + ( word2 & word3 ) + S[ j+0 ] ) <<< 1
-    word1 = ( word1 + ( word2 & ~word0 ) + ( word3 & word0 ) + S[ j+1 ] ) <<< 2
-    word2 = ( word2 + ( word3 & ~word1 ) + ( word0 & word1 ) + S[ j+2 ] ) <<< 3
-    word3 = ( word3 + ( word0 & ~word2 ) + ( word1 & word2 ) + S[ j+3 ] ) <<< 5
- 
-In addition the fifth and eleventh rounds add the contents of the S-box indexed
-by one of the data words to another of the data words following the four
-subrounds as follows:
- 
-    word0 = word0 + S[ word3 & 63 ];
-    word1 = word1 + S[ word0 & 63 ];
-    word2 = word2 + S[ word1 & 63 ];
-    word3 = word3 + S[ word2 & 63 ];
- 
- 
-Decryption
- 
-The decryption operation is simply the inverse of the encryption operation.
-Note that the following pseudocode treats the S array as an array of 64 words
-rather than 128 bytes.
- 
-  for i = 15 downto 0 do
-    j = i * 4;
-    word3 = ( word3 >>> 5 ) - ( word0 & ~word2 ) - ( word1 & word2 ) - S[ j+3 ]
-    word2 = ( word2 >>> 3 ) - ( word3 & ~word1 ) - ( word0 & word1 ) - S[ j+2 ]
-    word1 = ( word1 >>> 2 ) - ( word2 & ~word0 ) - ( word3 & word0 ) - S[ j+1 ]
-    word0 = ( word0 >>> 1 ) - ( word1 & ~word3 ) - ( word2 & word3 ) - S[ j+0 ]
- 
-In addition the fifth and eleventh rounds subtract the contents of the S-box
-indexed by one of the data words from another one of the data words following
-the four subrounds as follows:
- 
-    word3 = word3 - S[ word2 & 63 ]
-    word2 = word2 - S[ word1 & 63 ]
-    word1 = word1 - S[ word0 & 63 ]
-    word0 = word0 - S[ word3 & 63 ]
- 
- 
-Test Vectors
- 
-The following test vectors may be used to test the correctness of an RRC.2
-implementation:
- 
-  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-  Cipher:   0x1C, 0x19, 0x8A, 0x83, 0x8D, 0xF0, 0x28, 0xB7
- 
-  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01
-  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-  Cipher:   0x21, 0x82, 0x9C, 0x78, 0xA9, 0xF9, 0xC0, 0x74
- 
-  Key:      0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-            0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-  Plain:    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
-  Cipher:   0x13, 0xDB, 0x35, 0x17, 0xD3, 0x21, 0x86, 0x9E
- 
-  Key:      0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
-            0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F
-  Plain:    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
-  Cipher:   0x50, 0xDC, 0x01, 0x62, 0xBD, 0x75, 0x7F, 0x31
- 
- 
-Appendix: Beale Cipher No.1, "The Locality of the Vault", and One-time Pad for
-          Creating the S-Box
- 
-Beale Cipher No.1.
- 
-  71, 194,  38,1701,  89,  76,  11,  83,1629,  48,  94,  63, 132,  16, 111,  95,
-  84, 341, 975,  14,  40,  64,  27,  81, 139, 213,  63,  90,1120,   8,  15,   3,
- 126,2018,  40,  74, 758, 485, 604, 230, 436, 664, 582, 150, 251, 284, 308, 231,
- 124, 211, 486, 225, 401, 370,  11, 101, 305, 139, 189,  17,  33,  88, 208, 193,
- 145,   1,  94,  73, 416, 918, 263,  28, 500, 538, 356, 117, 136, 219,  27, 176,
- 130,  10, 460,  25, 485,  18, 436,  65,  84, 200, 283, 118, 320, 138,  36, 416,
- 280,  15,  71, 224, 961,  44,  16, 401,  39,  88,  61, 304,  12,  21,  24, 283,
- 134,  92,  63, 246, 486, 682,   7, 219, 184, 360, 780,  18,  64, 463, 474, 131,
- 160,  79,  73, 440,  95,  18,  64, 581,  34,  69, 128, 367, 460,  17,  81,  12,
- 103, 820,  62, 110,  97, 103, 862,  70,  60,1317, 471, 540, 208, 121, 890, 346,
-  36, 150,  59, 568, 614,  13, 120,  63, 219, 812,2160,1780,  99,  35,  18,  21,
- 136, 872,  15,  28, 170,  88,   4,  30,  44, 112,  18, 147, 436, 195, 320,  37,
- 122, 113,   6, 140,   8, 120, 305,  42,  58, 461,  44, 106, 301,  13, 408, 680,
-  93,  86, 116, 530,  82, 568,   9, 102,  38, 416,  89,  71, 216, 728, 965, 818,
-   2,  38, 121, 195,  14, 326, 148, 234,  18,  55, 131, 234, 361, 824,   5,  81,
- 623,  48, 961,  19,  26,  33,  10,1101, 365,  92,  88, 181, 275, 346, 201, 206
- 
-One-time Pad.
- 
- 158, 186, 223,  97,  64, 145, 190, 190, 117, 217, 163,  70, 206, 176, 183, 194,
- 146,  43, 248, 141,   3,  54,  72, 223, 233, 153,  91, 210,  36, 131, 244, 161,
- 105, 120, 113, 191, 113,  86,  19, 245, 213, 221,  43,  27, 242, 157,  73, 213,
- 193,  92, 166,  10,  23, 197, 112, 110, 193,  30, 156,  51, 125,  51, 158,  67,
- 197, 215,  59, 218, 110, 246, 181,   0, 135,  76, 164,  97,  47,  87, 234, 108,
- 144, 127,   6,   6, 222, 172,  80, 144,  22, 245, 207,  70, 227, 182, 146, 134,
- 119, 176,  73,  58, 135,  69,  23, 198,   0, 170,  32, 171, 176, 129,  91,  24,
- 126,  77, 248,   0, 118,  69,  57,  60, 190, 171, 217,  61, 136, 169, 196,  84,
- 168, 167, 163, 102, 223,  64, 174, 178, 166, 239, 242, 195, 249,  92,  59,  38,
- 241,  46, 236,  31,  59, 114,  23,  50, 119, 186,   7,  66, 212,  97, 222, 182,
- 230, 118, 122,  86, 105,  92, 179, 243, 255, 189, 223, 164, 194, 215,  98,  44,
-  17,  20,  53, 153, 137, 224, 176, 100, 208, 114,  36, 200, 145, 150, 215,  20,
-  87,  44, 252,  20, 235, 242, 163, 132,  63,  18,   5, 122,  74,  97,  34,  97,
- 142,  86, 146, 221, 179, 166, 161,  74,  69, 182,  88, 120, 128,  58,  76, 155,
-  15,  30,  77, 216, 165, 117, 107,  90, 169, 127, 143, 181, 208, 137, 200, 127,
- 170, 195,  26,  84, 255, 132, 150,  58, 103, 250, 120, 221, 237,  37,   8,  99
- 
- 
-Implementation
- 
-A non-US based programmer who has never seen any encryption code before will
-shortly be implementing RRC.2 based solely on this specification and not on
-knowledge of any other encryption algorithms.  Stand by.
-
-
-
diff --git a/doc/protocol/ssl-version2.txt b/doc/protocol/ssl-version2.txt
deleted file mode 100644
index 9ce3d2ac5c..0000000000
--- a/doc/protocol/ssl-version2.txt
+++ /dev/null
@@ -1,1486 +0,0 @@
-                              [Documentation]
-
-                       SSL 2.0 PROTOCOL SPECIFICATION
-
-If you have questions about this protocol specification, please ask them in
-Netscape's newsgroup for SSL developers, netscape.dev.ssl. More information
-about the netscape.dev.ssl newsgroup may be found at this URL:
-http://home.netscape.com/eng/ssl3/ssl-talk.html
-  ------------------------------------------------------------------------
-
-THIS PROTOCOL SPECIFICATION WAS REVISED ON NOVEMBER 29TH, 1994:
-
-   * a fundamental correction to the client-certificate authentication
-     protocol,
-   * the removal of the username/password messages,
-   * corrections in some of the cryptographic terminology,
-   * the addition of a MAC to the messages [see section 1.2],
-   * the allowance for different kinds of message digest algorithms.
-
-THIS DOCUMENT WAS REVISED ON DECEMBER 22ND, 1994:
-
-   * The spec now defines the order the clear key data and secret key data
-     are combined to produce the master key.
-   * The spec now explicitly states the size of the MAC instead of making
-     the reader figure it out.
-   * The spec is more clear on the actual values used to produce the session
-     read and write keys.
-   * The spec is more clear on how many bits of the session key are used
-     after they are produced from the hash function.
-
-THIS DOCUMENT WAS REVISED ON JANUARY 17TH, 1995:
-
-   * Defined the category to be informational.
-   * Clarified ordering of data elements in various places.
-   * Defined DES-CBC cipher kind and key construction.
-   * Defined DES-EDE3-CBC cipher kind and key construction.
-
-THIS DOCUMENT WAS REVISED ON JANUARY 24TH, 1995:
-
-   * Fixed bug in definition of CIPHER-CHOICE in CLIENT-MASTER-KEY message.
-     The previous spec erroneously indicated that the CIPHER-CHOICE was an
-     index into the servers CIPHER-SPECS-DATA array, when it was actually
-     supposed to be the CIPHER-KIND value chosen by the client.
-   * Clarified the values of the KEY-ARG-DATA.
-
-THIS DOCUMENT WAS REVISED ON FEBRUARY 9TH, 1995:
-
-     The spec has been clarified to indicate the byte order of sequence
-     numbers when they are being applied to the MAC hash function.
-   * The spec now defines the acceptable length range of the CONNECTION-ID
-     parameter (sent by the server in the SERVER-HELLO message).
-   * Simplified the specification of the CIPHER-KIND data. The spec language
-     has been changed yet the format remains compatible with all existing
-     implementations. The CIPHER-KIND information is now a three byte value
-     which defines the type of cipher and the length of the key. The key
-     length is no longer separable from the CIPHER-KIND.
-   * Explained how the KEY-ARG-DATA is retained with the SESSION-ID when the
-     session-identifier cache is used.
-
-  ------------------------------------------------------------------------
-
-Experimental                                             Kipp E.B. Hickman
-Request For Comments: XXXX                   Netscape Communications Corp.
-Category: Informational                        Last Update: Feb. 9th, 1995
-
-                              The SSL Protocol
-
-Status of this Memo
-
-     This is a DRAFT specification.
-
-     This RFC specifies a security protocol for the Internet community, and
-     requests discussion and suggestions for improvements. Distribution of
-     this memo is unlimited.
-
-Abstract
-
-     This document specifies the Secure Sockets Layer (SSL) protocol, a
-     security protocol that provides privacy over the Internet. The protocol
-     allows client/server applications to communicate in a way that cannot
-     be eavesdropped. Server's are always authenticated and clients are
-     optionally authenticated.
-
-Motivation
-
-     The SSL Protocol is designed to provide privacy between two
-     communicating applications (a client and a server). Second, the
-     protocol is designed to authenticate the server, and optionally the
-     client. SSL requires a reliable transport protocol (e.g. TCP) for data
-     transmission and reception.
-
-     The advantage of the SSL Protocol is that it is application protocol
-     independent. A "higher level" application protocol (e.g. HTTP, FTP,
-     TELNET, etc.) can layer on top of the SSL Protocol transparently. The
-     SSL Protocol can negotiate an encryption algorithm and session key as
-     well as authenticate a server before the application protocol transmits
-     or receives its first byte of data. All of the application protocol
-     data is transmitted encrypted, ensuring privacy.
-
-     The SSL protocol provides "channel security" which has three basic
-     properties:
-
-        * The channel is private. Encryption is used for all messages after
-          a simple handshake is used to define a secret key.
-
-        * The channel is authenticated. The server endpoint of the
-          conversation is always authenticated, while the client endpoint is
-          optionally authenticated.
-
-        * The channel is reliable. The message transport includes a message
-          integrity check (using a MAC).
-
-1. SSL Record Protocol Specification
-
-     1.1 SSL Record Header Format
-
-     In SSL, all data sent is encapsulated in a record, an object which is
-     composed of a header and some non-zero amount of data. Each record
-     header contains a two or three byte length code. If the most
-     significant bit is set in the first byte of the record length code then
-     the record has no padding and the total header length will be 2 bytes,
-     otherwise the record has padding and the total header length will be 3
-     bytes. The record header is transmitted before the data portion of the
-     record.
-
-     Note that in the long header case (3 bytes total), the second most
-     significant bit in the first byte has special meaning. When zero, the
-     record being sent is a data record. When one, the record being sent is
-     a security escape (there are currently no examples of security escapes;
-     this is reserved for future versions of the protocol). In either case,
-     the length code describes how much data is in the record.
-
-     The record length code does not include the number of bytes consumed by
-     the record header (2 or 3). For the 2 byte header, the record length is
-     computed by (using a "C"-like notation):
-
-     RECORD-LENGTH = ((byte[0] & 0x7f) << 8)) | byte[1];
-
-     Where byte[0] represents the first byte received and byte[1] the second
-     byte received. When the 3 byte header is used, the record length is
-     computed as follows (using a "C"-like notation):
-
-     RECORD-LENGTH = ((byte[0] & 0x3f) << 8)) | byte[1];
-     IS-ESCAPE = (byte[0] & 0x40) != 0;
-     PADDING = byte[2];
-
-     The record header defines a value called PADDING. The PADDING value
-     specifies how many bytes of data were appended to the original record
-     by the sender. The padding data is used to make the record length be a
-     multiple of the block ciphers block size when a block cipher is used
-     for encryption.
-
-     The sender of a "padded" record appends the padding data to the end of
-     its normal data and then encrypts the total amount (which is now a
-     multiple of the block cipher's block size). The actual value of the
-     padding data is unimportant, but the encrypted form of it must be
-     transmitted for the receiver to properly decrypt the record. Once the
-     total amount being transmitted is known the header can be properly
-     constructed with the PADDING value set appropriately.
-
-     The receiver of a padded record decrypts the entire record data (sans
-     record length and the optional padding) to get the clear data, then
-     subtracts the PADDING value from the RECORD-LENGTH to determine the
-     final RECORD-LENGTH. The clear form of the padding data must be
-     discarded.
-
-     1.2 SSL Record Data Format
-
-     The data portion of an SSL record is composed of three components
-     (transmitted and received in the order shown):
-
-     MAC-DATA[MAC-SIZE]
-     ACTUAL-DATA[N]
-     PADDING-DATA[PADDING]
-
-     ACTUAL-DATA is the actual data being transmitted (the message payload).
-     PADDING-DATA is the padding data sent when a block cipher is used and
-     padding is needed. Finally, MAC-DATA is the Message Authentication
-     Code.
-
-     When SSL records are sent in the clear, no cipher is used. Consequently
-     the amount of PADDING-DATA will be zero and the amount of MAC-DATA will
-     be zero. When encryption is in effect, the PADDING-DATA will be a
-     function of the cipher block size. The MAC-DATA is a function of the
-     CIPHER-CHOICE (more about that later).
-
-     The MAC-DATA is computed as follows:
-
-     MAC-DATA = HASH[ SECRET, ACTUAL-DATA, PADDING-DATA, SEQUENCE-NUMBER ]
-
-     Where the SECRET data is fed to the hash function first, followed by
-     the ACTUAL-DATA, which is followed by the PADDING-DATA which is finally
-     followed by the SEQUENCE-NUMBER. The SEQUENCE-NUMBER is a 32 bit value
-     which is presented to the hash function as four bytes, with the first
-     byte being the most significant byte of the sequence number, the second
-     byte being the next most significant byte of the sequence number, the
-     third byte being the third most significant byte, and the fourth byte
-     being the least significant byte (that is, in network byte order or
-     "big endian" order).
-
-     MAC-SIZE is a function of the digest algorithm being used. For MD2 and
-     MD5 the MAC-SIZE will be 16 bytes (128 bits).
-
-     The SECRET value is a function of which party is sending the message.
-     If the client is sending the message then the SECRET is the
-     CLIENT-WRITE-KEY (the server will use the SERVER-READ-KEY to verify the
-     MAC). If the client is receiving the message then the SECRET is the
-     CLIENT-READ-KEY (the server will use the SERVER-WRITE-KEY to generate
-     the MAC).
-
-     The SEQUENCE-NUMBER is a counter which is incremented by both the
-     sender and the receiver. For each transmission direction, a pair of
-     counters is kept (one by the sender, one by the receiver). Every time a
-     message is sent by a sender the counter is incremented. Sequence
-     numbers are 32 bit unsigned quantities and must wrap to zero after
-     incrementing past 0xFFFFFFFF.
-
-     The receiver of a message uses the expected value of the sequence
-     number as input into the MAC HASH function (the HASH function is chosen
-     from the CIPHER-CHOICE). The computed MAC-DATA must agree bit for bit
-     with the transmitted MAC-DATA. If the comparison is not identity then
-     the record is considered damaged, and it is to be treated as if an "I/O
-     Error" had occurred (i.e. an unrecoverable error is asserted and the
-     connection is closed).
-
-     A final consistency check is done when a block cipher is used and the
-     protocol is using encryption. The amount of data present in a record
-     (RECORD-LENGTH))must be a multiple of the cipher's block size. If the
-     received record is not a multiple of the cipher's block size then the
-     record is considered damaged, and it is to be treated as if an "I/O
-     Error" had occurred (i.e. an unrecoverable error is asserted and the
-     connection is closed).
-
-     The SSL Record Layer is used for all SSL communications, including
-     handshake messages, security escapes and application data transfers.
-     The SSL Record Layer is used by both the client and the server at all
-     times.
-
-     For a two byte header, the maximum record length is 32767 bytes. For
-     the three byte header, the maximum record length is 16383 bytes. The
-     SSL Handshake Protocol messages are constrained to fit in a single SSL
-     Record Protocol record. Application protocol messages are allowed to
-     consume multiple SSL Record Protocol record's.
-
-     Before the first record is sent using SSL all sequence numbers are
-     initialized to zero. The transmit sequence number is incremented after
-     every message sent, starting with the CLIENT-HELLO and SERVER-HELLO
-     messages.
-
-2. SSL Handshake Protocol Specification
-
-     2.1 SSL Handshake Protocol Flow
-
-          The SSL Handshake Protocol has two major phases. The first phase
-          is used to establish private communications. The second phase is
-          used for client authentication.
-
-          Phase 1
-
-          The first phase is the initial connection phase where both parties
-          communicate their "hello" messages. The client initiates the
-          conversation by sending the CLIENT-HELLO message. The server
-          receives the CLIENT-HELLO message and processes it responding with
-          the SERVER-HELLO message.
-
-          At this point both the client and server have enough information
-          to know whether or not a new master key is needed. When a new
-          master key is not needed, both the client and the server proceed
-          immediately to phase 2.
-
-          When a new master key is needed, the SERVER-HELLO message will
-          contain enough information for the client to generate it. This
-          includes the server's signed certificate (more about that later),
-          a list of bulk cipher specifications (see below), and a
-          connection-id (a connection-id is a randomly generated value
-          generated by the server that is used by the client and server
-          during a single connection). The client generates the master key
-          and responds with a CLIENT-MASTER-KEY message (or an ERROR message
-          if the server information indicates that the client and server
-          cannot agree on a bulk cipher).
-
-          It should be noted here that each SSL endpoint uses a pair of
-          ciphers per connection (for a total of four ciphers). At each
-          endpoint, one cipher is used for outgoing communications, and one
-          is used for incoming communications. When the client or server
-          generate a session key, they actually generate two keys, the
-          SERVER-READ-KEY (also known as the CLIENT-WRITE-KEY) and the
-          SERVER-WRITE-KEY (also known as the CLIENT-READ-KEY). The master
-          key is used by the client and server to generate the various
-          session keys (more about that later).
-
-          Finally, the server sends a SERVER-VERIFY message to the client
-          after the master key has been determined. This final step
-          authenticates the server, because only a server which has the
-          appropriate public key can know the master key.
-
-          Phase 2
-
-          The second phase is the authentication phase. The server has
-          already been authenticated by the client in the first phase, so
-          this phase is primarily used to authenticate the client. In a
-          typical scenario, the server will require something from the
-          client and send a request. The client will answer in the positive
-          if it has the needed information, or send an ERROR message if it
-          does not. This protocol specification does not define the
-          semantics of an ERROR response to a server request (e.g., an
-          implementation can ignore the error, close the connection, etc.
-          and still conform to this specification).
-
-          When a party is done authenticating the other party, it sends its
-          finished message. For the client, the CLIENT-FINISHED message
-          contains the encrypted form of the CONNECTION-ID for the server to
-          verify. If the verification fails, the server sends an ERROR
-          message.
-
-          Once a party has sent its finished message it must continue to
-          listen to its peers messages until it too receives a finished
-          message. Once a party has both sent a finished message and
-          received its peers finished message, the SSL handshake protocol is
-          done. At this point the application protocol begins to operate
-          (Note: the application protocol continues to be layered on the SSL
-          Record Protocol).
-
-     2.2 Typical Protocol Message Flow
-
-          The following sequences define several typical protocol message
-          flows for the SSL Handshake Protocol. In these examples we have
-          two principals in the conversation: the client and the server. We
-          use a notation commonly found in the literature [10]. When
-          something is enclosed in curly braces "{something}key" then the
-          something has been encrypted using "key".
-
-          2.2.1 Assuming no session-identifier
-
-          client-hello         C -> S: challenge, cipher_specs
-          server-hello         S -> C: connection-id,server_certificate,cipher_specs
-          client-master-key    C -> S: {master_key}server_public_key
-          client-finish        C -> S: {connection-id}client_write_key
-          server-verify        S -> C: {challenge}server_write_key
-          server-finish        S -> C: {new_session_id}server_write_key
-
-          2.2.2 Assuming a session-identifier was found by both client &
-          server
-
-          client-hello         C -> S: challenge, session_id, cipher_specs
-          server-hello         S -> C: connection-id, session_id_hit
-          client-finish        C -> S: {connection-id}client_write_key
-          server-verify        S -> C: {challenge}server_write_key
-          server-finish        S -> C: {session_id}server_write_key
-
-          2.2.3 Assuming a session-identifier was used and client
-          authentication is used
-
-          client-hello         C -> S: challenge, session_id, cipher_specs
-          server-hello         S -> C: connection-id, session_id_hit
-          client-finish        C -> S: {connection-id}client_write_key
-          server-verify        S -> C: {challenge}server_write_key
-          request-certificate  S -> C: {auth_type,challenge'}server_write_key
-          client-certificate   C -> S: {cert_type,client_cert,
-                                        response_data}client_write_key
-          server-finish        S -> C: {session_id}server_write_key
-
-          In this last exchange, the response_data is a function of the
-          auth_type.
-
-     2.3 Errors
-
-          Error handling in the SSL connection protocol is very simple. When
-          an error is detected, the detecting party sends a message to the
-          other party. Errors that are not recoverable cause the client and
-          server to abort the secure connection. Servers and client are
-          required to "forget" any session-identifiers associated with a
-          failing connection.
-
-          The SSL Handshake Protocol defines the following errors:
-
-          NO-CIPHER-ERROR
-               This error is returned by the client to the server when it
-               cannot find a cipher or key size that it supports that is
-               also supported by the server. This error is not recoverable.
-
-          NO-CERTIFICATE-ERROR
-               When a REQUEST-CERTIFICATE message is sent, this error may be
-               returned if the client has no certificate to reply with. This
-               error is recoverable (for client authentication only).
-
-          BAD-CERTIFICATE-ERROR
-               This error is returned when a certificate is deemed bad by
-               the receiving party. Bad means that either the signature of
-               the certificate was bad or that the values in the certificate
-               were inappropriate (e.g. a name in the certificate did not
-               match the expected name). This error is recoverable (for
-               client authentication only).
-
-          UNSUPPORTED-CERTIFICATE-TYPE-ERROR
-               This error is returned when a client/server receives a
-               certificate type that it can't support. This error is
-               recoverable (for client authentication only).
-
-     2.4 SSL Handshake Protocol Messages
-
-          The SSL Handshake Protocol messages are encapsulated in the SSL
-          Record Protocol and are composed of two parts: a single byte
-          message type code, and some data. The client and server exchange
-          messages until both ends have sent their "finished" message,
-          indicating that they are satisfied with the SSL Handshake Protocol
-          conversation. While one end may be finished, the other may not,
-          therefore the finished end must continue to receive SSL Handshake
-          Protocol messages until it too receives a "finished" message.
-
-          After the pair of session keys has been determined by each party,
-          the message bodies are encrypted using it. For the client, this
-          happens after it verifies the session-identifier or creates a new
-          session key and has sent it to the server. For the server, this
-          happens after the session-identifier is found to be good, or the
-          server receives the client's session key message.
-
-          The following notation is used for SSLHP messages:
-
-              char MSG-EXAMPLE
-              char FIELD1
-              char FIELD2
-              char THING-MSB
-              char THING-LSB
-              char THING-DATA[(MSB<<8)|LSB];
-              ...
-
-          This notation defines the data in the protocol message, including
-          the message type code. The order is presented top to bottom, with
-          the top most element being transmitted first, and the bottom most
-          element transferred last.
-
-          For the "THING-DATA" entry, the MSB and LSB values are actually
-          THING-MSB and THING-LSB (respectively) and define the number of
-          bytes of data actually present in the message. For example, if
-          THING-MSB were zero and THING-LSB were 8 then the THING-DATA array
-          would be exactly 8 bytes long. This shorthand is used below.
-
-          Length codes are unsigned values, and when the MSB and LSB are
-          combined the result is an unsigned value. Unless otherwise
-          specified lengths values are "length in bytes".
-
-     2.5 Client Only Protocol Messages
-
-          There are several messages that are only generated by clients.
-          These messages are never generated by correctly functioning
-          servers. A client receiving such a message closes the connection
-          to the server and returns an error status to the application
-          through some unspecified mechanism.
-
-          CLIENT-HELLO (Phase 1; Sent in the clear)
-
-              char MSG-CLIENT-HELLO
-              char CLIENT-VERSION-MSB
-              char CLIENT-VERSION-LSB
-              char CIPHER-SPECS-LENGTH-MSB
-              char CIPHER-SPECS-LENGTH-LSB
-              char SESSION-ID-LENGTH-MSB
-              char SESSION-ID-LENGTH-LSB
-              char CHALLENGE-LENGTH-MSB
-              char CHALLENGE-LENGTH-LSB
-              char CIPHER-SPECS-DATA[(MSB<<8)|LSB]
-              char SESSION-ID-DATA[(MSB<<8)|LSB]
-              char CHALLENGE-DATA[(MSB<<8)|LSB]
-
-          When a client first connects to a server it is required to send
-          the CLIENT-HELLO message. The server is expecting this message
-          from the client as its first message. It is an error for a client
-          to send anything else as its first message.
-
-          The client sends to the server its SSL version, its cipher specs
-          (see below), some challenge data, and the session-identifier data.
-          The session-identifier data is only sent if the client found a
-          session-identifier in its cache for the server, and the
-          SESSION-ID-LENGTH will be non-zero. When there is no
-          session-identifier for the server SESSION-ID-LENGTH must be zero.
-          The challenge data is used to authenticate the server. After the
-          client and server agree on a pair of session keys, the server
-          returns a SERVER-VERIFY message with the encrypted form of the
-          CHALLENGE-DATA.
-
-          Also note that the server will not send its SERVER-HELLO message
-          until it has received the CLIENT-HELLO message. This is done so
-          that the server can indicate the status of the client's
-          session-identifier back to the client in the server's first
-          message (i.e. to increase protocol efficiency and reduce the
-          number of round trips required).
-
-          The server examines the CLIENT-HELLO message and will verify that
-          it can support the client version and one of the client cipher
-          specs. The server can optionally edit the cipher specs, removing
-          any entries it doesn't choose to support. The edited version will
-          be returned in the SERVER-HELLO message if the session-identifier
-          is not in the server's cache.
-
-          The CIPHER-SPECS-LENGTH must be greater than zero and a multiple
-          of 3. The SESSION-ID-LENGTH must either be zero or 16. The
-          CHALLENGE-LENGTH must be greater than or equal to 16 and less than
-          or equal to 32.
-
-          This message must be the first message sent by the client to the
-          server. After the message is sent the client waits for a
-          SERVER-HELLO message. Any other message returned by the server
-          (other than ERROR) is disallowed.
-
-          CLIENT-MASTER-KEY (Phase 1; Sent primarily in the clear)
-
-              char MSG-CLIENT-MASTER-KEY
-              char CIPHER-KIND[3]
-              char CLEAR-KEY-LENGTH-MSB
-              char CLEAR-KEY-LENGTH-LSB
-              char ENCRYPTED-KEY-LENGTH-MSB
-              char ENCRYPTED-KEY-LENGTH-LSB
-              char KEY-ARG-LENGTH-MSB
-              char KEY-ARG-LENGTH-LSB
-              char CLEAR-KEY-DATA[MSB<<8|LSB]
-              char ENCRYPTED-KEY-DATA[MSB<<8|LSB]
-              char KEY-ARG-DATA[MSB<<8|LSB]
-
-          The client sends this message when it has determined a master key
-          for the server to use. Note that when a session-identifier has
-          been agreed upon, this message is not sent.
-
-          The CIPHER-KIND field indicates which cipher was chosen from the
-          server's CIPHER-SPECS.
-
-          The CLEAR-KEY-DATA contains the clear portion of the MASTER-KEY.
-          The CLEAR-KEY-DATA is combined with the SECRET-KEY-DATA (described
-          shortly) to form the MASTER-KEY, with the SECRET-KEY-DATA being
-          the least significant bytes of the final MASTER-KEY. The
-          ENCRYPTED-KEY-DATA contains the secret portions of the MASTER-KEY,
-          encrypted using the server's public key. The encryption block is
-          formatted using block type 2 from PKCS#1 [5]. The data portion of
-          the block is formatted as follows:
-
-              char SECRET-KEY-DATA[SECRET-LENGTH]
-
-          SECRET-LENGTH is the number of bytes of each session key that is
-          being transmitted encrypted. The SECRET-LENGTH plus the
-          CLEAR-KEY-LENGTH equals the number of bytes present in the cipher
-          key (as defined by the CIPHER-KIND). It is an error if the
-          SECRET-LENGTH found after decrypting the PKCS#1 formatted
-          encryption block doesn't match the expected value. It is also an
-          error if CLEAR-KEY-LENGTH is non-zero and the CIPHER-KIND is not
-          an export cipher.
-
-          If the key algorithm needs an argument (for example, DES-CBC's
-          initialization vector) then the KEY-ARG-LENGTH fields will be
-          non-zero and the KEY-ARG-DATA will contain the relevant data. For
-          the SSL_CK_RC2_128_CBC_WITH_MD5,
-          SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5,
-          SSL_CK_IDEA_128_CBC_WITH_MD5, SSL_CK_DES_64_CBC_WITH_MD5 and
-          SSL_CK_DES_192_EDE3_CBC_WITH_MD5 algorithms the KEY-ARG data must
-          be present and be exactly 8 bytes long.
-
-          Client and server session key production is a function of the
-          CIPHER-CHOICE:
-
-          SSL_CK_RC4_128_WITH_MD5
-          SSL_CK_RC4_128_EXPORT40_WITH_MD5
-          SSL_CK_RC2_128_CBC_WITH_MD5
-          SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
-          SSL_CK_IDEA_128_CBC_WITH_MD5
-
-               KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
-               KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
-
-               CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]
-               CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]
-
-               Where KEY-MATERIAL-0[0-15] means the first 16 bytes of the
-               KEY-MATERIAL-0 data, with KEY-MATERIAL-0[0] becoming the most
-               significant byte of the CLIENT-READ-KEY.
-
-               Data is fed to the MD5 hash function in the order shown, from
-               left to right: first the MASTER-KEY, then the "0" or "1",
-               then the CHALLENGE and then finally the CONNECTION-ID.
-
-               Note that the "0" means the ascii zero character (0x30), not
-               a zero value. "1" means the ascii 1 character (0x31). MD5
-               produces 128 bits of output data which are used directly as
-               the key to the cipher algorithm (The most significant byte of
-               the MD5 output becomes the most significant byte of the key
-               material).
-
-          SSL_CK_DES_64_CBC_WITH_MD5
-
-               KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]
-
-               CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]
-               CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]
-
-               For DES-CBC, a single 16 bytes of key material are produced
-               using MD5. The first 8 bytes of the MD5 digest are used as
-               the CLIENT-READ-KEY while the remaining 8 bytes are used as
-               the CLIENT-WRITE-KEY. The initialization vector is provided
-               in the KEY-ARG-DATA. Note that the raw key data is not parity
-               adjusted and that this step must be performed before the keys
-               are legitimate DES keys.
-
-          SSL_CK_DES_192_EDE3_CBC_WITH_MD5
-
-               KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]
-               KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]
-               KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]
-
-               CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]
-               CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]
-               CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]
-               CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]
-               CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]
-               CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]
-
-               Data is fed to the MD5 hash function in the order shown, from
-               left to right: first the MASTER-KEY, then the "0", "1" or
-               "2", then the CHALLENGE and then finally the CONNECTION-ID.
-
-               Note that the "0" means the ascii zero character (0x30), not
-               a zero value. "1" means the ascii 1 character (0x31). "2"
-               means the ascii 2 character (0x32).
-
-               A total of 6 keys are produced, 3 for the read side DES-EDE3
-               cipher and 3 for the write side DES-EDE3 function. The
-               initialization vector is provided in the KEY-ARG-DATA. The
-               keys that are produced are not parity adjusted. This step
-               must be performed before proper DES keys are usable.
-
-          Recall that the MASTER-KEY is given to the server in the
-          CLIENT-MASTER-KEY message. The CHALLENGE is given to the server by
-          the client in the CLIENT-HELLO message. The CONNECTION-ID is given
-          to the client by the server in the SERVER-HELLO message. This
-          makes the resulting cipher keys a function of the original session
-          and the current session. Note that the master key is never
-          directly used to encrypt data, and therefore cannot be easily
-          discovered.
-
-          The CLIENT-MASTER-KEY message must be sent after the CLIENT-HELLO
-          message and before the CLIENT-FINISHED message. The
-          CLIENT-MASTER-KEY message must be sent if the SERVER-HELLO message
-          contains a SESSION-ID-HIT value of 0.
-
-          CLIENT-CERTIFICATE (Phase 2; Sent encrypted)
-
-              char MSG-CLIENT-CERTIFICATE
-              char CERTIFICATE-TYPE
-              char CERTIFICATE-LENGTH-MSB
-              char CERTIFICATE-LENGTH-LSB
-              char RESPONSE-LENGTH-MSB
-              char RESPONSE-LENGTH-LSB
-              char CERTIFICATE-DATA[MSB<<8|LSB]
-              char RESPONSE-DATA[MSB<<8|LSB]
-
-          This message is sent by one an SSL client in response to a server
-          REQUEST-CERTIFICATE message. The CERTIFICATE-DATA contains data
-          defined by the CERTIFICATE-TYPE value. An ERROR message is sent
-          with error code NO-CERTIFICATE-ERROR when this request cannot be
-          answered properly (e.g. the receiver of the message has no
-          registered certificate).
-
-          CERTIFICATE-TYPE is one of:
-
-          SSL_X509_CERTIFICATE
-               The CERTIFICATE-DATA contains an X.509 (1988) [3] signed
-               certificate.
-
-          The RESPONSE-DATA contains the authentication response data. This
-          data is a function of the AUTHENTICATION-TYPE value sent by the
-          server.
-
-          When AUTHENTICATION-TYPE is SSL_AT_MD5_WITH_RSA_ENCRYPTION then
-          the RESPONSE-DATA contains a digital signature of the following
-          components (in the order shown):
-
-             * the KEY-MATERIAL-0
-             * the KEY-MATERIAL-1 (only if defined by the cipher kind)
-             * the KEY-MATERIAL-2 (only if defined by the cipher kind)
-             * the CERTIFICATE-CHALLENGE-DATA (from the REQUEST-CERTIFICATE
-               message)
-             * the server's signed certificate (from the SERVER-HELLO
-               message)
-
-          The digital signature is constructed using MD5 and then encrypted
-          using the clients private key, formatted according to PKCS#1's
-          digital signature standard [5]. The server authenticates the
-          client by verifying the digital signature using standard
-          techniques. Note that other digest functions are supported. Either
-          a new AUTHENTICATION-TYPE can be added, or the algorithm-id in the
-          digital signature can be changed.
-
-          This message must be sent by the client only in response to a
-          REQUEST-CERTIFICATE message.
-
-          CLIENT-FINISHED (Phase 2; Sent encrypted)
-
-              char MSG-CLIENT-FINISHED
-              char CONNECTION-ID[N-1]
-
-          The client sends this message when it is satisfied with the
-          server. Note that the client must continue to listen for server
-          messages until it receives a SERVER-FINISHED message. The
-          CONNECTION-ID data is the original connection-identifier the
-          server sent with its SERVER-HELLO message, encrypted using the
-          agreed upon session key.
-
-          "N" is the number of bytes in the message that was sent, so "N-1"
-          is the number of bytes in the message without the message header
-          byte.
-
-          For version 2 of the protocol, the client must send this message
-          after it has received the SERVER-HELLO message. If the
-          SERVER-HELLO message SESSION-ID-HIT flag is non-zero then the
-          CLIENT-FINISHED message is sent immediately, otherwise the
-          CLIENT-FINISHED message is sent after the CLIENT-MASTER-KEY
-          message.
-
-     2.6 Server Only Protocol Messages
-
-          There are several messages that are only generated by servers. The
-          messages are never generated by correctly functioning clients.
-
-          SERVER-HELLO (Phase 1; Sent in the clear)
-
-              char MSG-SERVER-HELLO
-              char SESSION-ID-HIT
-              char CERTIFICATE-TYPE
-              char SERVER-VERSION-MSB
-              char SERVER-VERSION-LSB
-              char CERTIFICATE-LENGTH-MSB
-              char CERTIFICATE-LENGTH-LSB
-              char CIPHER-SPECS-LENGTH-MSB
-              char CIPHER-SPECS-LENGTH-LSB
-              char CONNECTION-ID-LENGTH-MSB
-              char CONNECTION-ID-LENGTH-LSB
-              char CERTIFICATE-DATA[MSB<<8|LSB]
-              char CIPHER-SPECS-DATA[MSB<<8|LSB]
-              char CONNECTION-ID-DATA[MSB<<8|LSB]
-
-          The server sends this message after receiving the clients
-          CLIENT-HELLO message. The server returns the SESSION-ID-HIT flag
-          indicating whether or not the received session-identifier is known
-          by the server (i.e. in the server's session-identifier cache). The
-          SESSION-ID-HIT flag will be non-zero if the client sent the server
-          a session-identifier (in the CLIENT-HELLO message with
-          SESSION-ID-LENGTH != 0) and the server found the client's
-          session-identifier in its cache. If the SESSION-ID-HIT flag is
-          non-zero then the CERTIFICATE-TYPE, CERTIFICATE-LENGTH and
-          CIPHER-SPECS-LENGTH fields will be zero.
-
-          The CERTIFICATE-TYPE value, when non-zero, has one of the values
-          described above (see the information on the CLIENT-CERTIFICATE
-          message).
-
-          When the SESSION-ID-HIT flag is zero, the server packages up its
-          certificate, its cipher specs and a connection-id to send to the
-          client. Using this information the client can generate a session
-          key and return it to the server with the CLIENT-MASTER-KEY
-          message.
-
-          When the SESSION-ID-HIT flag is non-zero, both the server and the
-          client compute a new pair of session keys for the current session
-          derived from the MASTER-KEY that was exchanged when the SESSION-ID
-          was created. The SERVER-READ-KEY and SERVER-WRITE-KEY are derived
-          from the original MASTER-KEY keys in the same manner as the
-          CLIENT-READ-KEY and CLIENT-WRITE-KEY:
-
-          SERVER-READ-KEY = CLIENT-WRITE-KEY
-          SERVER-WRITE-KEY = CLIENT-READ-KEY
-
-          Note that when keys are being derived and the SESSION-ID-HIT flag
-          is set and the server discovers the client's session-identifier in
-          the servers cache, then the KEY-ARG-DATA is used from the time
-          when the SESSION-ID was established. This is because the client
-          does not send new KEY-ARG-DATA (recall that the KEY-ARG-DATA is
-          sent only in the CLIENT-MASTER-KEY message).
-
-          The CONNECTION-ID-DATA is a string of randomly generated bytes
-          used by the server and client at various points in the protocol.
-          The CLIENT-FINISHED message contains an encrypted version of the
-          CONNECTION-ID-DATA. The length of the CONNECTION-ID must be
-          between 16 and than 32 bytes, inclusive.
-
-          The CIPHER-SPECS-DATA define a cipher type and key length (in
-          bits) that the receiving end supports. Each SESSION-CIPHER-SPEC is
-          3 bytes long and looks like this:
-
-              char CIPHER-KIND-0
-              char CIPHER-KIND-1
-              char CIPHER-KIND-2
-
-          Where CIPHER-KIND is one of:
-
-             * SSL_CK_RC4_128_WITH_MD5
-             * SSL_CK_RC4_128_EXPORT40_WITH_MD5
-             * SSL_CK_RC2_128_CBC_WITH_MD5
-             * SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
-             * SSL_CK_IDEA_128_CBC_WITH_MD5
-             * SSL_CK_DES_64_CBC_WITH_MD5
-             * SSL_CK_DES_192_EDE3_CBC_WITH_MD5
-
-          This list is not exhaustive and may be changed in the future.
-
-          The SSL_CK_RC4_128_EXPORT40_WITH_MD5 cipher is an RC4 cipher where
-          some of the session key is sent in the clear and the rest is sent
-          encrypted (exactly 40 bits of it). MD5 is used as the hash
-          function for production of MAC's and session key's. This cipher
-          type is provided to support "export" versions (i.e. versions of
-          the protocol that can be distributed outside of the United States)
-          of the client or server.
-
-          An exportable implementation of the SSL Handshake Protocol will
-          have secret key lengths restricted to 40 bits. For non-export
-          implementations key lengths can be more generous (we recommend at
-          least 128 bits). It is permissible for the client and server to
-          have a non-intersecting set of stream ciphers. This, simply put,
-          means they cannot communicate.
-
-          Version 2 of the SSL Handshake Protocol defines the
-          SSL_CK_RC4_128_WITH_MD5 to have a key length of 128 bits. The
-          SSL_CK_RC4_128_EXPORT40_WITH_MD5 also has a key length of 128
-          bits. However, only 40 of the bits are secret (the other 88 bits
-          are sent in the clear by the client to the server).
-
-          The SERVER-HELLO message is sent after the server receives the
-          CLIENT-HELLO message, and before the server sends the
-          SERVER-VERIFY message.
-
-          SERVER-VERIFY (Phase 1; Sent encrypted)
-
-              char MSG-SERVER-VERIFY
-              char CHALLENGE-DATA[N-1]
-
-          The server sends this message after a pair of session keys
-          (SERVER-READ-KEY and SERVER-WRITE-KEY) have been agreed upon
-          either by a session-identifier or by explicit specification with
-          the CLIENT-MASTER-KEY message. The message contains an encrypted
-          copy of the CHALLENGE-DATA sent by the client in the CLIENT-HELLO
-          message.
-
-          "N" is the number of bytes in the message that was sent, so "N-1"
-          is the number of bytes in the CHALLENGE-DATA without the message
-          header byte.
-
-          This message is used to verify the server as follows. A legitimate
-          server will have the private key that corresponds to the public
-          key contained in the server certificate that was transmitted in
-          the SERVER-HELLO message. Accordingly, the legitimate server will
-          be able to extract and reconstruct the pair of session keys
-          (SERVER-READ-KEY and SERVER-WRITE-KEY). Finally, only a server
-          that has done the extraction and decryption properly can correctly
-          encrypt the CHALLENGE-DATA. This, in essence, "proves" that the
-          server has the private key that goes with the public key in the
-          server's certificate.
-
-          The CHALLENGE-DATA must be the exact same length as originally
-          sent by the client in the CLIENT-HELLO message. Its value must
-          match exactly the value sent in the clear by the client in the
-          CLIENT-HELLO message. The client must decrypt this message and
-          compare the value received with the value sent, and only if the
-          values are identical is the server to be "trusted". If the lengths
-          do not match or the value doesn't match then the connection is to
-          be closed by the client.
-
-          This message must be sent by the server to the client after either
-          detecting a session-identifier hit (and replying with a
-          SERVER-HELLO message with SESSION-ID-HIT not equal to zero) or
-          when the server receives the CLIENT-MASTER-KEY message. This
-          message must be sent before any Phase 2 messages or a
-          SEVER-FINISHED message.
-
-          SERVER-FINISHED (Phase 2; Sent encrypted)
-
-              char MSG-SERVER-FINISHED
-              char SESSION-ID-DATA[N-1]
-
-          The server sends this message when it is satisfied with the
-          clients security handshake and is ready to proceed with
-          transmission/reception of the higher level protocols data. The
-          SESSION-ID-DATA is used by the client and the server at this time
-          to add entries to their respective session-identifier caches. The
-          session-identifier caches must contain a copy of the MASTER-KEY
-          sent in the CLIENT-MASTER-KEY message as the master key is used
-          for all subsequent session key generation.
-
-          "N" is the number of bytes in the message that was sent, so "N-1"
-          is the number of bytes in the SESSION-ID-DATA without the message
-          header byte.
-
-          This message must be sent after the SERVER-VERIFY message.
-
-          REQUEST-CERTIFICATE (Phase 2; Sent encrypted)
-
-              char MSG-REQUEST-CERTIFICATE
-              char AUTHENTICATION-TYPE
-              char CERTIFICATE-CHALLENGE-DATA[N-2]
-
-          A server may issue this request at any time during the second
-          phase of the connection handshake, asking for the client's
-          certificate. The client responds with a CLIENT-CERTIFICATE message
-          immediately if it has one, or an ERROR message (with error code
-          NO-CERTIFICATE-ERROR) if it doesn't. The
-          CERTIFICATE-CHALLENGE-DATA is a short byte string (whose length is
-          greater than or equal to 16 bytes and less than or equal to 32
-          bytes) that the client will use to respond to this message.
-
-          The AUTHENTICATION-TYPE value is used to choose a particular means
-          of authenticating the client. The following types are defined:
-
-             * SSL_AT_MD5_WITH_RSA_ENCRYPTION
-
-          The SSL_AT_MD5_WITH_RSA_ENCRYPTION type requires that the client
-          construct an MD5 message digest using information as described
-          above in the section on the CLIENT-CERTIFICATE message. Once the
-          digest is created, the client encrypts it using its private key
-          (formatted according to the digital signature standard defined in
-          PKCS#1). The server authenticates the client when it receives the
-          CLIENT-CERTIFICATE message.
-
-          This message may be sent after a SERVER-VERIFY message and before
-          a SERVER-FINISHED message.
-
-     2.7 Client/Server Protocol Messages
-
-          These messages are generated by both the client and the server.
-
-          ERROR (Sent clear or encrypted)
-
-              char MSG-ERROR
-              char ERROR-CODE-MSB
-              char ERROR-CODE-LSB
-
-          This message is sent when an error is detected. After the message
-          is sent, the sending party shuts the connection down. The
-          receiving party records the error and then shuts its connection
-          down.
-
-          This message is sent in the clear if an error occurs during
-          session key negotiation. After a session key has been agreed upon,
-          errors are sent encrypted like all other messages.
-
-  ------------------------------------------------------------------------
-
-Appendix A: ASN.1 Syntax For Certificates
-
-     Certificates are used by SSL to authenticate servers and clients. SSL
-     Certificates are based largely on the X.509 [3] certificates. An X.509
-     certificate contains the following information (in ASN.1 [1] notation):
-
-     X.509-Certificate ::= SEQUENCE {
-         certificateInfo CertificateInfo,
-         signatureAlgorithm AlgorithmIdentifier,
-         signature BIT STRING
-     }
-
-     CertificateInfo ::= SEQUENCE {
-         version [0] Version DEFAULT v1988,
-         serialNumber CertificateSerialNumber,
-         signature AlgorithmIdentifier,
-         issuer Name,
-         validity Validity,
-         subject Name,
-         subjectPublicKeyInfo SubjectPublicKeyInfo
-     }
-
-     Version ::= INTEGER { v1988(0) }
-
-     CertificateSerialNumber ::= INTEGER
-
-     Validity ::= SEQUENCE {
-         notBefore UTCTime,
-         notAfter UTCTime
-     }
-
-     SubjectPublicKeyInfo ::= SEQUENCE {
-         algorithm AlgorithmIdentifier,
-         subjectPublicKey BIT STRING
-     }
-
-     AlgorithmIdentifier ::= SEQUENCE {
-         algorithm OBJECT IDENTIFIER,
-         parameters ANY DEFINED BY ALGORITHM OPTIONAL
-     }
-
-     For SSL's purposes we restrict the values of some of the X.509 fields:
-
-        * The X.509-Certificate::signatureAlgorithm and
-          CertificateInfo::signature fields must be identical in value.
-
-        * The issuer name must resolve to a name that is deemed acceptable
-          by the application using SSL. How the application using SSL does
-          this is outside the scope of this memo.
-
-     Certificates are validated using a few straightforward steps. First,
-     the signature on the certificate is checked and if invalid, the
-     certificate is invalid (either a transmission error or an attempted
-     forgery occurred). Next, the CertificateInfo::issuer field is verified
-     to be an issuer that the application trusts (using an unspecified
-     mechanism). The CertificateInfo::validity field is checked against the
-     current date and verified.
-
-     Finally, the CertificateInfo::subject field is checked. This check is
-     optional and depends on the level of trust required by the application
-     using SSL.
-
-Appendix B: Attribute Types and Object Identifiers
-
-     SSL uses a subset of the X.520 selected attribute types as well as a
-     few specific object identifiers. Future revisions of the SSL protocol
-     may include support for more attribute types and more object
-     identifiers.
-
-     B.1 Selected attribute types
-
-     commonName { attributeType 3 }
-          The common name contained in the distinguished name contained
-          within a certificate issuer or certificate subject.
-
-     countryName { attributeType 6 }
-          The country name contained in the distinguished name contained
-          within a certificate issuer or certificate subject.
-
-     localityName { attributeType 7 }
-          The locality name contained in the distinguished name contained
-          within a certificate issuer or certificate subject.
-
-     stateOrProvinceName { attributeType 8 }
-          The state or province name contained in the distinguished name
-          contained within a certificate issuer or certificate subject.
-
-     organizationName { attributeType 10 }
-          The organization name contained in the distinguished name
-          contained within a certificate issuer or certificate subject.
-
-     organizationalUnitName { attributeType 11 }
-          The organizational unit name contained in the distinguished name
-          contained within a certificate issuer or certificate subject.
-
-     B.2 Object identifiers
-
-     md2withRSAEncryption { ... pkcs(1) 1 2 }
-          The object identifier for digital signatures that use both MD2 and
-          RSA encryption. Used by SSL for certificate signature
-          verification.
-
-     md5withRSAEncryption { ... pkcs(1) 1 4 }
-          The object identifier for digital signatures that use both MD5 and
-          RSA encryption. Used by SSL for certificate signature
-          verification.
-
-     rc4 { ... rsadsi(113549) 3 4 }
-          The RC4 symmetric stream cipher algorithm used by SSL for bulk
-          encryption.
-
-Appendix C: Protocol Constant Values
-
-     This section describes various protocol constants. A special value
-     needs mentioning - the IANA reserved port number for "https" (HTTP
-     using SSL). IANA has reserved port number 443 (decimal) for "https".
-
-     C.1 Protocol Version Codes
-
-          #define SSL_CLIENT_VERSION                      0x0002
-          #define SSL_SERVER_VERSION                      0x0002
-
-     C.2 Protocol Message Codes
-
-     The following values define the message codes that are used by version
-     2 of the SSL Handshake Protocol.
-
-          #define SSL_MT_ERROR                            0
-          #define SSL_MT_CLIENT_HELLO                     1
-          #define SSL_MT_CLIENT_MASTER_KEY                2
-          #define SSL_MT_CLIENT_FINISHED                  3
-          #define SSL_MT_SERVER_HELLO                     4
-          #define SSL_MT_SERVER_VERIFY                    5
-          #define SSL_MT_SERVER_FINISHED                  6
-          #define SSL_MT_REQUEST_CERTIFICATE              7
-          #define SSL_MT_CLIENT_CERTIFICATE               8
-
-     C.3 Error Message Codes
-
-     The following values define the error codes used by the ERROR message.
-
-          #define SSL_PE_NO_CIPHER                        0x0001
-          #define SSL_PE_NO_CERTIFICATE                   0x0002
-          #define SSL_PE_BAD_CERTIFICATE                  0x0004
-          #define SSL_PE_UNSUPPORTED_CERTIFICATE_TYPE     0x0006
-
-     C.4 Cipher Kind Values
-
-     The following values define the CIPHER-KIND codes used in the
-     CLIENT-HELLO and SERVER-HELLO messages.
-
-          #define SSL_CK_RC4_128_WITH_MD5                 0x01,0x00,0x80
-          #define SSL_CK_RC4_128_EXPORT40_WITH_MD5        0x02,0x00,0x80
-          #define SSL_CK_RC2_128_CBC_WITH_MD5             0x03,0x00,0x80
-          #define SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5    0x04,0x00,0x80
-          #define SSL_CK_IDEA_128_CBC_WITH_MD5            0x05,0x00,0x80
-          #define SSL_CK_DES_64_CBC_WITH_MD5              0x06,0x00,0x40
-          #define SSL_CK_DES_192_EDE3_CBC_WITH_MD5        0x07,0x00,0xC0
-
-     C.5 Certificate Type Codes
-
-     The following values define the certificate type codes used in the
-     SERVER-HELLO and CLIENT-CERTIFICATE messages.
-
-          #define SSL_CT_X509_CERTIFICATE                 0x01
-
-     C.6 Authentication Type Codes
-
-     The following values define the authentication type codes used in the
-     REQUEST-CERTIFICATE message.
-
-          #define SSL_AT_MD5_WITH_RSA_ENCRYPTION          0x01
-
-     C.7 Upper/Lower Bounds
-
-     The following values define upper/lower bounds for various protocol
-     parameters.
-
-          #define SSL_MAX_MASTER_KEY_LENGTH_IN_BITS       256
-          #define SSL_MAX_SESSION_ID_LENGTH_IN_BYTES      16
-          #define SSL_MIN_RSA_MODULUS_LENGTH_IN_BYTES     64
-          #define SSL_MAX_RECORD_LENGTH_2_BYTE_HEADER     32767
-          #define SSL_MAX_RECORD_LENGTH_3_BYTE_HEADER     16383
-
-     C.8 Recommendations
-
-     Because protocols have to be implemented to be of value, we recommend
-     the following values for various operational parameters. This is only a
-     recommendation, and not a strict requirement for conformance to the
-     protocol.
-
-     Session-identifier Cache Timeout
-
-          Session-identifiers are kept in SSL clients and SSL servers.
-          Session-identifiers should have a lifetime that serves their
-          purpose (namely, reducing the number of expensive public key
-          operations for a single client/server pairing). Consequently, we
-          recommend a maximum session-identifier cache timeout value of 100
-          seconds. Given a server that can perform N private key operations
-          per second, this reduces the server load for a particular client
-          by a factor of 100.
-
-Appendix D: Attacks
-
-     In this section we attempt to describe various attacks that might be
-     used against the SSL protocol. This list is not guaranteed to be
-     exhaustive. SSL was defined to thwart these attacks.
-
-     D.1 Cracking Ciphers
-
-     SSL depends on several cryptographic technologies. RSA Public Key
-     encryption [5] is used for the exchange of the session key and
-     client/server authentication. Various cryptographic algorithms are used
-     for the session cipher. If successful cryptographic attacks are made
-     against these technologies then SSL is no longer secure.
-
-     Attacks against a specific communications session can be made by
-     recording the session, and then spending some large number of compute
-     cycles to crack either the session key or the RSA public key until the
-     communication can be seen in the clear. This approach is easier than
-     cracking the cryptographic technologies for all possible messages. Note
-     that SSL tries to make the cost of such of an attack greater than the
-     benefits gained from a successful attack, thus making it a waste of
-     money/time to perform such an attack.
-
-     There have been many books [9] and papers [10] written on cryptography.
-     This document does not attempt to reference them all.
-
-     D.2 Clear Text Attack
-
-     A clear text attack is done when the attacker has an idea of what kind
-     of message is being sent using encryption. The attacker can generate a
-     data base whose keys are the encrypted value of the known text (or
-     clear text), and whose values are the session cipher key (we call this
-     a "dictionary"). Once this data base is constructed, a simple lookup
-     function identifies the session key that goes with a particular
-     encrypted value. Once the session key is known, the entire message
-     stream can be decrypted. Custom hardware can be used to make this cost
-     effective and very fast.
-
-     Because of the very nature of SSL clear text attacks are possible. For
-     example, the most common byte string sent by an HTTP client application
-     to an HTTP server is "GET". SSL attempts to address this attack by
-     using large session cipher keys. First, the client generates a key
-     which is larger than allowed by export, and sends some of it in the
-     clear to the server (this is allowed by United States government export
-     rules). The clear portion of the key concatenated with the secret
-     portion make a key which is very large (for RC4, exactly 128 bits).
-
-     The way that this "defeats" a clear text attack is by making the amount
-     of custom hardware needed prohibitively large. Every bit added to the
-     length of the session cipher key increases the dictionary size by a
-     factor of 2. By using a 128 bit session cipher key length the size of
-     the dictionary required is beyond the ability of anyone to fabricate
-     (it would require more atoms to construct than exist in the entire
-     universe). Even if a smaller dictionary is to be used, it must first be
-     generated using the clear key bits. This is a time consumptive process
-     and also eliminates many possible custom hardware architectures (e.g.
-     static prom arrays).
-
-     The second way that SSL attacks this problem is by using large key
-     lengths when permissible (e.g. in the non-export version). Large key
-     sizes require larger dictionaries (just one more bit of key size
-     doubles the size of the dictionary). SSL attempts to use keys that are
-     128 bits in length.
-
-     Note that the consequence of the SSL defense is that a brute force
-     attack becomes the cheapest way to attack the key. Brute force attacks
-     have well known space/time tradeoffs and so it becomes possible to
-     define a cost of the attack. For the 128 bit secret key, the known cost
-     is essentially infinite. For the 40 bit secret key, the cost is much
-     smaller, but still outside the range of the "random hacker".
-
-     D.3 Replay
-
-     The replay attack is simple. A bad-guy records a communication session
-     between a client and server. Later, it reconnects to the server, and
-     plays back the previously recorded client messages.
-
-     SSL defeats this attack using a "nonce" (the connection-id) which is
-     "unique" to the connection. In theory the bad-guy cannot predict the
-     nonce in advance as it is based on a set of random events outside the
-     bad-guys control, and therefore the bad-guy cannot respond properly to
-     server requests.
-
-     A bad-guy with large resources can record many sessions between a
-     client and a server, and attempt to choose the right session based on
-     the nonce the server sends initially in its SERVER-HELLO message.
-     However, SSL nonces are at least 128 bits long, so a bad-guy would need
-     to record approximately 2^64 nonces to even have a 50% chance of
-     choosing the right session. This number is sufficiently large that one
-     cannot economically construct a device to record 2^64 messages, and
-     therefore the odds are overwhelmingly against the replay attack ever
-     being successful.
-
-     D.4 The Man In The Middle
-
-     The man in the middle attack works by having three people in a
-     communications session: the client, the server, and the bad guy. The
-     bad guy sits between the client and the server on the network and
-     intercepts traffic that the client sends to the server, and traffic
-     that the server sends to the client.
-
-     The man in the middle operates by pretending to be the real server to
-     the client. With SSL this attack is impossible because of the usage of
-     server certificates. During the security connection handshake the
-     server is required to provide a certificate that is signed by a
-     certificate authority. Contained in the certificate is the server's
-     public key as well as its name and the name of the certificate issuer.
-     The client verifies the certificate by first checking the signature and
-     then verifying that the name of the issuer is somebody that the client
-     trusts.
-
-     In addition, the server must encrypt something with the private key
-     that goes with the public key mentioned in the certificate. This in
-     essence is a single pass "challenge response" mechanism. Only a server
-     that has both the certificate and the private key can respond properly
-     to the challenge.
-
-     If the man in the middle provides a phony certificate, then the
-     signature check will fail. If the certificate provided by the bad guy
-     is legitimate, but for the bad guy instead of for the real server, then
-     the signature will pass but the name check will fail (note that the man
-     in the middle cannot forge certificates without discovering a
-     certificate authority's private key).
-
-     Finally, if the bad guy provides the real server's certificate then the
-     signature check will pass and the name check will pass. However,
-     because the bad guy does not have the real server's private key, the
-     bad guy cannot properly encode the response to the challenge code, and
-     this check will fail.
-
-     In the unlikely case that a bad guy happens to guess the response code
-     to the challenge, the bad guy still cannot decrypt the session key and
-     therefore cannot examine the encrypted data.
-
-Appendix E: Terms
-
-     Application Protocol
-          An application protocol is a protocol that normally layers
-          directly on top of TCP/IP. For example: HTTP, TELNET, FTP, and
-          SMTP.
-
-     Authentication
-          Authentication is the ability of one entity to determine the
-          identity of another entity. Identity is defined by this document
-          to mean the binding between a public key and a name and the
-          implicit ownership of the corresponding private key.
-
-     Bulk Cipher
-          This term is used to describe a cryptographic technique with
-          certain performance properties. Bulk ciphers are used when large
-          quantities of data are to be encrypted/decrypted in a timely
-          manner. Examples include RC2, RC4, and IDEA.
-
-     Client
-          In this document client refers to the application entity that is
-          initiates a connection to a server.
-
-     CLIENT-READ-KEY
-          The session key that the client uses to initialize the client read
-          cipher. This key has the same value as the SERVER-WRITE-KEY.
-
-     CLIENT-WRITE-KEY
-          The session key that the client uses to initialize the client
-          write cipher. This key has the same value as the SERVER-READ-KEY.
-
-     MASTER-KEY
-          The master key that the client and server use for all session key
-          generation. The CLIENT-READ-KEY, CLIENT-WRITE-KEY, SERVER-READ-KEY
-          and SERVER-WRITE-KEY are generated from the MASTER-KEY.
-
-     MD2
-          MD2 [8] is a hashing function that converts an arbitrarily long
-          data stream into a digest of fixed size. This function predates
-          MD5 [7] which is viewed as a more robust hash function [9].
-
-     MD5
-          MD5 [7] is a hashing function that converts an arbitrarily long
-          data stream into a digest of fixed size. The function has certain
-          properties that make it useful for security, the most important of
-          which is it's inability to be reversed.
-
-     Nonce
-          A randomly generated value used to defeat "playback" attacks. One
-          party randomly generates a nonce and sends it to the other party.
-          The receiver encrypts it using the agreed upon secret key and
-          returns it to the sender. Because the nonce was randomly generated
-          by the sender this defeats playback attacks because the replayer
-          can't know in advance the nonce the sender will generate. The
-          receiver denies connections that do not have the correctly
-          encrypted nonce.
-
-     Non-repudiable Information Exchange
-          When two entities exchange information it is sometimes valuable to
-          have a record of the communication that is non-repudiable. Neither
-          party can then deny that the information exchange occurred.
-          Version 2 of the SSL protocol does not support Non-repudiable
-          information exchange.
-
-     Public Key Encryption
-          Public key encryption is a technique that leverages asymmetric
-          ciphers. A public key system consists of two keys: a public key
-          and a private key. Messages encrypted with the public key can only
-          be decrypted with the associated private key. Conversely, messages
-          encrypted with the private key can only be decrypted with the
-          public key. Public key encryption tends to be extremely compute
-          intensive and so is not suitable as a bulk cipher.
-
-     Privacy
-          Privacy is the ability of two entities to communicate without fear
-          of eavesdropping. Privacy is often implemented by encrypting the
-          communications stream between the two entities.
-
-     RC2, RC4
-          Proprietary bulk ciphers invented by RSA (There is no good
-          reference to these as they are unpublished works; however, see
-          [9]). RC2 is block cipher and RC4 is a stream cipher.
-
-     Server
-          The server is the application entity that responds to requests for
-          connections from clients. The server is passive, waiting for
-          requests from clients.
-
-     Session cipher
-          A session cipher is a "bulk" cipher that is capable of encrypting
-          or decrypting arbitrarily large amounts of data. Session ciphers
-          are used primarily for performance reasons. The session ciphers
-          used by this protocol are symmetric. Symmetric ciphers have the
-          property of using a single key for encryption and decryption.
-
-     Session identifier
-          A session identifier is a random value generated by a client that
-          identifies itself to a particular server. The session identifier
-          can be thought of as a handle that both parties use to access a
-          recorded secret key (in our case a session key). If both parties
-          remember the session identifier then the implication is that the
-          secret key is already known and need not be negotiated.
-
-     Session key
-          The key to the session cipher. In SSL there are four keys that are
-          called session keys: CLIENT-READ-KEY, CLIENT-WRITE-KEY,
-          SERVER-READ-KEY, and SERVER-WRITE-KEY.
-
-     SERVER-READ-KEY
-          The session key that the server uses to initialize the server read
-          cipher. This key has the same value as the CLIENT-WRITE-KEY.
-
-     SERVER-WRITE-KEY
-          The session key that the server uses to initialize the server
-          write cipher. This key has the same value as the CLIENT-READ-KEY.
-
-     Symmetric Cipher
-          A symmetric cipher has the property that the same key can be used
-          for decryption and encryption. An asymmetric cipher does not have
-          this behavior. Some examples of symmetric ciphers: IDEA, RC2, RC4.
-
-References
-
-     [1] CCITT. Recommendation X.208: "Specification of Abstract Syntax
-     Notation One (ASN.1). 1988.
-
-     [2] CCITT. Recommendation X.209: "Specification of Basic Encoding Rules
-     for Abstract Syntax Notation One (ASN.1). 1988.
-
-     [3] CCITT. Recommendation X.509: "The Directory - Authentication
-     Framework". 1988.
-
-     [4] CCITT. Recommendation X.520: "The Directory - Selected Attribute
-     Types". 1988.
-
-     [5] RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5,
-     November 1993.
-
-     [6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard,
-     Version 1.5, November 1993.
-
-     [7] R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992.
-
-     [8] R. Rivest. RFC 1319: The MD2 Message Digest Algorithm. April 1992.
-
-     [9] B. Schneier. Applied Cryptography: Protocols, Algorithms, and
-     Source Code in C, Published by John Wiley & Sons, Inc. 1994.
-
-     [10] M. Abadi and R. Needham. Prudent engineering practice for
-     cryptographic protocols. 1994.
-
-Patent Statement
-
-     This version of the SSL protocol relies on the use of patented public
-     key encryption technology for authentication and encryption. The
-     Internet Standards Process as defined in RFC 1310 requires a written
-     statement from the Patent holder that a license will be made available
-     to applicants under reasonable terms and conditions prior to approving
-     a specification as a Proposed, Draft or Internet Standard.
-
-     The Massachusetts Institute of Technology and the Board of Trustees of
-     the Leland Stanford Junior University have granted Public Key Partners
-     (PKP) exclusive sub-licensing rights to the following patents issued in
-     the United States, and all of their corresponding foreign patents:
-
-          Cryptographic Apparatus and Method
-          ("Diffie-Hellman")............................... No. 4,200,770
-
-          Public Key Cryptographic Apparatus
-          and Method ("Hellman-Merkle").................... No. 4,218,582
-
-          Cryptographic Communications System and
-          Method ("RSA")................................... No. 4,405,829
-
-          Exponential Cryptographic Apparatus
-          and Method ("Hellman-Pohlig").................... No. 4,424,414
-
-     These patents are stated by PKP to cover all known methods of
-     practicing the art of Public Key encryption, including the variations
-     collectively known as El Gamal.
-
-     Public Key Partners has provided written assurance to the Internet
-     Society that parties will be able to obtain, under reasonable,
-     nondiscriminatory terms, the right to use the technology covered by
-     these patents. This assurance is documented in RFC 1170 titled "Public
-     Key Standards and Licenses". A copy of the written assurance dated
-     April 20, 1990, may be obtained from the Internet Assigned Number
-     Authority (IANA).
-
-     The Internet Society, Internet Architecture Board, Internet Engineering
-     Steering Group and the Corporation for National Research Initiatives
-     take no position on the validity or scope of the patents and patent
-     applications, nor on the appropriateness of the terms of the assurance.
-     The Internet Society and other groups mentioned above have not made any
-     determination as to any other intellectual property rights which may
-     apply to the practice of this standard. Any further consideration of
-     these matters is the user's own responsibility.
-
-Security Considerations
-
-     This entire document is about security.
-
-Author's Address
-
-     Kipp E.B. Hickman
-     AOL/Netscape Communications Corp.
-     466 Ellis Street
-     Mountain View, CA 94043-4042
-     kipp@netscape.com
diff --git a/doc/protocol/tls-numbers.txt b/doc/protocol/tls-numbers.txt
deleted file mode 100644
index 7816d728af..0000000000
--- a/doc/protocol/tls-numbers.txt
+++ /dev/null
@@ -1,475 +0,0 @@
-TLS numbers used in various places
-Pasi Eronen <pasi.eronen@nokia.com>
-Last updated: November 18, 2005
-
-NOTE: This is a totally unofficial list. The IANA registries 
-for TLS can be found at the following addresses:
-
-http://www.iana.org/assignments/tls-parameters
-http://www.iana.org/assignments/tls-extensiontype-values
-
-
-TLS CLIENT CERTIFICATE TYPES
-============================
-
-   1    rsa_sign                            [RFC2246]
-   2    dss_sign                            [RFC2246]
-   3    rsa_fixed_dh                        [RFC2246]
-   4    dss_fixed_dh                        [RFC2246]
-   5    rsa_ephemeral_dh_RESERVED           [2246bis] [ssl3] [*16]
-   6    dss_ephemeral_dh_RESERVED           [2246bis] [ssl3] [*15]
-   7                                        [*15]
-   8                                        [*11] [*15]
-   9                                        [*11] [*15]
-  20    fortezza_dms_RESERVED               [2246bis] [ssl3]
-  21                                        [cptls-02]
-  22                                        [cptls-02]
-  64                                        [ecc-12]
-  65                                        [ecc-12]
-  66                                        [ecc-12]
-
-
-TLS CIPHERSUITE NUMBERS
-=======================
-
-00,00   TLS_NULL_WITH_NULL_NULL                         [RFC2246]
-00,01   TLS_RSA_WITH_NULL_MD5                           [RFC2246]
-00,02   TLS_RSA_WITH_NULL_SHA                           [RFC2246]
-00,03   TLS_RSA_EXPORT_WITH_RC4_40_MD5                  [RFC2246]
-00,04   TLS_RSA_WITH_RC4_128_MD5                        [RFC2246]
-00,05   TLS_RSA_WITH_RC4_128_SHA                        [RFC2246]
-00,06   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5              [RFC2246]
-00,07   TLS_RSA_WITH_IDEA_CBC_SHA                       [RFC2246]
-00,08   TLS_RSA_EXPORT_WITH_DES40_CBC_SHA               [RFC2246]
-00,09   TLS_RSA_WITH_DES_CBC_SHA                        [RFC2246]
-00,0A   TLS_RSA_WITH_3DES_EDE_CBC_SHA                   [RFC2246]
-00,0B   TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA            [RFC2246]
-00,0C   TLS_DH_DSS_WITH_DES_CBC_SHA                     [RFC2246]
-00,0D   TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA                [RFC2246]
-00,0E   TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA            [RFC2246] 
-00,0F   TLS_DH_RSA_WITH_DES_CBC_SHA                     [RFC2246]
-00,10   TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA                [RFC2246]
-00,11   TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA           [RFC2246]
-00,12   TLS_DHE_DSS_WITH_DES_CBC_SHA                    [RFC2246]
-00,13   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA               [RFC2246]
-00,14   TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA           [RFC2246]
-00,15   TLS_DHE_RSA_WITH_DES_CBC_SHA                    [RFC2246]
-00,16   TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA               [RFC2246]
-00,17   TLS_DH_anon_EXPORT_WITH_RC4_40_MD5              [RFC2246]
-00,18   TLS_DH_anon_WITH_RC4_128_MD5                    [RFC2246]
-00,19   TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA           [RFC2246]
-00,1A   TLS_DH_anon_WITH_DES_CBC_SHA                    [RFC2246]
-00,1B   TLS_DH_anon_WITH_3DES_EDE_CBC_SHA               [RFC2246]
-00,1C   (permanently reserved)                          [2246bis] [ssl3]
-00,1D   (permanently reserved)                          [2246bis] [ssl3]
-00,1E   TLS_KRB5_WITH_DES_CBC_SHA                       [RFC2712] [*1]
-00,1F   TLS_KRB5_WITH_3DES_EDE_CBC_SHA                  [RFC2712] 
-00,20   TLS_KRB5_WITH_RC4_128_SHA                       [RFC2712] 
-00,21   TLS_KRB5_WITH_IDEA_CBC_SHA                      [RFC2712] 
-00,22   TLS_KRB5_WITH_DES_CBC_MD5                       [RFC2712] 
-00,23   TLS_KRB5_WITH_3DES_EDE_CBC_MD5                  [RFC2712] 
-00,24   TLS_KRB5_WITH_RC4_128_MD5                       [RFC2712] 
-00,25   TLS_KRB5_WITH_IDEA_CBC_MD5                      [RFC2712] 
-00,26   TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA             [RFC2712] 
-00,27   TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA             [RFC2712] 
-00,28   TLS_KRB5_EXPORT_WITH_RC4_40_SHA                 [RFC2712] 
-00,29   TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5             [RFC2712] 
-00,2A   TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5             [RFC2712] 
-00,2B   TLS_KRB5_EXPORT_WITH_RC4_40_MD5                 [RFC2712] 
-00,2C                                                   [*8]
-00,2D                                                   [*8]
-00,2E                                                   [*8]
-00,2F   TLS_RSA_WITH_AES_128_CBC_SHA                    [RFC3268]
-00,30   TLS_DH_DSS_WITH_AES_128_CBC_SHA                 [RFC3268]
-00,31   TLS_DH_RSA_WITH_AES_128_CBC_SHA                 [RFC3268]
-00,32   TLS_DHE_DSS_WITH_AES_128_CBC_SHA                [RFC3268]
-00,33   TLS_DHE_RSA_WITH_AES_128_CBC_SHA                [RFC3268]
-00,34   TLS_DH_anon_WITH_AES_128_CBC_SHA                [RFC3268]
-00,35   TLS_RSA_WITH_AES_256_CBC_SHA                    [RFC3268]
-00,36   TLS_DH_DSS_WITH_AES_256_CBC_SHA                 [RFC3268]
-00,37   TLS_DH_RSA_WITH_AES_256_CBC_SHA                 [RFC3268]
-00,38   TLS_DHE_DSS_WITH_AES_256_CBC_SHA                [RFC3268]
-00,39   TLS_DHE_RSA_WITH_AES_256_CBC_SHA                [RFC3268]
-00,3A   TLS_DH_anon_WITH_AES_256_CBC_SHA                [RFC3268]
-00,3B                                                   [*10]
-00,3C                                                   [*10]
-00,3D                                                   [*10]
-00,3E                                                   [*10]
-00,3F                                                   [*10]
-00,40                                                   [*10]
-00,41   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA               [RFC4132]
-00,42   TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA            [RFC4132]
-00,43   TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA            [RFC4132]
-00,44   TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA           [RFC4132]
-00,45   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA           [RFC4132]
-00,46   TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA           [RFC4132]
-00,47                                                   [*2]
-00,48                                                   [*2]
-00,49                                                   [*2]
-00,4A                                                   [*2]
-00,4B                                                   [*2]
-00,4C                                                   [*2]
-00,4D                                                   [*2]
-00,4E                                                   [*2]
-00,4F                                                   [*2]
-00,50   (reserved for ongoing work)                     [srp-10] [*2]
-00,51   (reserved for ongoing work)                     [srp-10] [*2]
-00,52   (reserved for ongoing work)                     [srp-10] [*2]
-00,53   (reserved for ongoing work)                     [srp-10] [*2]
-00,54   (reserved for ongoing work)                     [srp-10] [*2]
-00,55   (reserved for ongoing work)                     [srp-10] [*2]
-00,56   (reserved for ongoing work)                     [srp-10] [*2]
-00,57   (reserved for ongoing work)                     [srp-10] [*2]
-00,58   (reserved for ongoing work)                     [srp-10] [*2]
-00,59                                                   [*2] 
-00,5A                                                   [*2]
-00,5B                                                   [*2]
-00,5C                                                   [*2]
-00,5D
-00,5E
-00,5F
-00,60   TLS_RSA_EXPORT1024_WITH_RC4_56_MD5              [56bit] [*7]
-00,61   TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5          [56bit] [*7] [*12]
-00,62   TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA             [56bit] [*7] [*12]
-00,63   TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA         [56bit] [*7] [*12]
-00,64   TLS_RSA_EXPORT1024_WITH_RC4_56_SHA              [56bit] [*7] [*12]
-00,65   TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA          [56bit] [*7] [*12]
-00,66   TLS_DHE_DSS_WITH_RC4_128_SHA                    [56bit] [*12]
-00,67                                                   [*12]
-00,68                                                   [*12]
-00,69
-00,6A
-00,6B
-00,6C
-00,6D
-00,6E
-00,6F
-00,70                                                   [*16]
-00,71                                                   [*16]
-00,72   (reserved for ongoing work)                     [openpgp-06] [*16]
-00,73   (reserved for ongoing work)                     [openpgp-06] [*16]
-00,74   (reserved for ongoing work)                     [openpgp-06] [*16]
-00,75                                                   [*16]
-00,76                                                   [*16]
-00,77   (reserved for ongoing work)                     [openpgp-06] [*2] [*16]
-00,78   (reserved for ongoing work)                     [openpgp-06] [*2] [*16]
-00,79   (reserved for ongoing work)                     [openpgp-06] [*16]
-00,7A
-00,7B
-00,7C   (reserved for ongoing work)                     [openpgp-06]
-00,7D   (reserved for ongoing work)                     [openpgp-06]
-00,7E   (reserved for ongoing work)                     [openpgp-06]
-00,7F
-00,80   (reserved for ongoing work)                     [cptls-02]
-00,81   (reserved for ongoing work)                     [cptls-02]
-00,82   (reserved for ongoing work)                     [cptls-02]
-00,83   (reserved for ongoing work)                     [cptls-02]
-00,84   TLS_RSA_WITH_CAMELLIA_256_CBC_SHA               [RFC4132]
-00,85   TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA            [RFC4132]
-00,86   TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA            [RFC4132]
-00,87   TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA           [RFC4132]
-00,88   TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA           [RFC4132]
-00,89   TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA           [RFC4132]
-00,8A   TLS_PSK_WITH_RC4_128_SHA                        [psk-09]
-00,8B   TLS_PSK_WITH_3DES_EDE_CBC_SHA                   [psk-09]
-00,8C   TLS_PSK_WITH_AES_128_CBC_SHA                    [psk-09]
-00,8D   TLS_PSK_WITH_AES_256_CBC_SHA                    [psk-09]
-00,8E   TLS_DHE_PSK_WITH_RC4_128_SHA                    [psk-09]
-00,8F   TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA               [psk-09]
-00,90   TLS_DHE_PSK_WITH_AES_128_CBC_SHA                [psk-09]
-00,91   TLS_DHE_PSK_WITH_AES_256_CBC_SHA                [psk-09]
-00,92   TLS_RSA_PSK_WITH_RC4_128_SHA                    [psk-09]
-00,93   TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA               [psk-09]
-00,94   TLS_RSA_PSK_WITH_AES_128_CBC_SHA                [psk-09]
-00,95   TLS_RSA_PSK_WITH_AES_256_CBC_SHA                [psk-09]
-00,96   TLS_RSA_WITH_SEED_CBC_SHA                       [RFC4162]
-00,97   TLS_DH_DSS_WITH_SEED_CBC_SHA                    [RFC4162]
-00,98   TLS_DH_RSA_WITH_SEED_CBC_SHA                    [RFC4162]
-00,99   TLS_DHE_DSS_WITH_SEED_CBC_SHA                   [RFC4162]
-00,9A   TLS_DHE_RSA_WITH_SEED_CBC_SHA                   [RFC4162]
-00,9B   TLS_DH_anon_WITH_SEED_CBC_SHA                   [RFC4162]
-01,01                                                   [*14]
-01,02                                                   [*14]
-01,03                                                   [*14]
-01,04                                                   [*14]
-01,05                                                   [*14]
-01,06                                                   [*14]
-01,10                                                   [*14]
-01,20                                                   [*14]
-01,21                                                   [*14]
-01,22                                                   [*14]
-01,23                                                   [*14]
-01,24                                                   [*14]
-01,25                                                   [*14]
-01,F0                                                   [*14]
-C0,00   (reserved for ongoing work)                     [ecc-12]  
-C0,01   (reserved for ongoing work)                     [ecc-12]  
-C0,02   (reserved for ongoing work)                     [ecc-12]  
-C0,03   (reserved for ongoing work)                     [ecc-12]  
-C0,04   (reserved for ongoing work)                     [ecc-12]  
-C0,05   (reserved for ongoing work)                     [ecc-12]  
-C0,06   (reserved for ongoing work)                     [ecc-12]  
-C0,07   (reserved for ongoing work)                     [ecc-12]  
-C0,08   (reserved for ongoing work)                     [ecc-12]  
-C0,09   (reserved for ongoing work)                     [ecc-12]  
-C0,0A   (reserved for ongoing work)                     [ecc-12]  
-C0,0B   (reserved for ongoing work)                     [ecc-12]  
-C0,0C   (reserved for ongoing work)                     [ecc-12]  
-C0,0D   (reserved for ongoing work)                     [ecc-12]  
-C0,0E   (reserved for ongoing work)                     [ecc-12]  
-C0,0F   (reserved for ongoing work)                     [ecc-12]  
-C0,10   (reserved for ongoing work)                     [ecc-12]  
-C0,11   (reserved for ongoing work)                     [ecc-12]  
-C0,12   (reserved for ongoing work)                     [ecc-12]  
-C0,13   (reserved for ongoing work)                     [ecc-12]  
-C0,14   (reserved for ongoing work)                     [ecc-12]  
-C0,15   (reserved for ongoing work)                     [ecc-12]  
-C0,16   (reserved for ongoing work)                     [ecc-12]  
-C0,17   (reserved for ongoing work)                     [ecc-12]  
-C0,18   (reserved for ongoing work)                     [ecc-12]  
-C0,19   (reserved for ongoing work)                     [ecc-12]  
-FE,FE   (reserved)                                      [fips]
-FE,FF   (reserved)                                      [fips]
-FF,E0   (reserved)                                      [fips]
-FF,E1   (reserved)                                      [fips]
-
-
-TLS CONTENT TYPES
-=================
-
-  20    change_cipher_spec                  [RFC2246]
-  21    alert                               [RFC2246]
-  22    handshake                           [RFC2246]
-  23    application_data                    [RFC2246]
-  24                                        [ia-01] [*9]
-  25                                        [sign-00]
-  26                                        [mtls-00]
-
-
-TLS ALERT DESCRIPTIONS
-======================
-
-   0    close_notify                        [RFC2246]
-  10    unexpected_message                  [RFC2246]
-  20    bad_record_mac                      [RFC2246]
-  21    decryption_failed                   [RFC2246]
-  22    record_overflow                     [RFC2246]
-  30    decompression_failure               [RFC2246]
-  40    handshake_failure                   [RFC2246]
-  41    no_certificate_RESERVED             [2246bis] [ssl3] [*13]
-  42    bad_certificate                     [RFC2246]
-  43    unsupported_certificate             [RFC2246]
-  44    certificate_revoked                 [RFC2246]
-  45    certificate_expired                 [RFC2246]
-  46    certificate_unknown                 [RFC2246]
-  47    illegal_parameter                   [RFC2246]  
-  48    unknown_ca                          [RFC2246]
-  49    access_denied                       [RFC2246]
-  50    decode_error                        [RFC2246]
-  51    decrypt_error                       [RFC2246]
-  60    export_restriction                  [RFC2246]
-  70    protocol_version                    [RFC2246]
-  71    insufficient_security               [RFC2246]
-  80    internal_error                      [RFC2246]
-  90    user_canceled                       [RFC2246]
- 100    no_renegotiation                    [RFC2246]
- 110    unsupported_extension               [RFC3546] [*13]
- 111    certificate_unobtainable            [RFC3546] [*13]
- 112    unrecognized_name                   [RFC3546] [*13]
- 113    bad_certificate_status_response     [RFC3546] [*13]
- 114    bad_certificate_hash_value          [RFC3546]
- 115    unknown_psk_identity                [psk-09]
- 120                                        [srp-10] [*13]
- 121                                        [srp-10]
- 122                                        [srp-10]
- 208                                        [ia-01] 
- 209                                        [ia-01] 
-
-
-TLS HANDSHAKE TYPES
-===================
-
-   0    hello_request                       [RFC2246]
-   1    client_hello                        [RFC2246]
-   2    server_hello                        [RFC2246]   
-   3    hello_verify_request                [dtls-05] [*5]
-   4                                        [*5]
-  11    certificate                         [RFC2246]
-  12    server_key_exchange                 [RFC2246]
-  13    certificate_request                 [RFC2246]
-  14    server_hello_done                   [RFC2246]
-  15    certificate_verify                  [RFC2246]
-  16    client_key_exchange                 [RFC2246]
-  20    finished                            [RFC2246]
-  21    certificate_url                     [RFC3546]
-  22    certificate_status                  [RFC3546]
-  78                                        [*6]
-  79                                        [*6]
-
-
-TLS EXTENSION TYPES
-===================
-        
-    0   server_name                         [RFC3546]
-    1   max_fragment_length                 [RFC3546]
-    2   client_certificate_url              [RFC3546]
-    3   trusted_ca_keys                     [RFC3546]
-    4   truncated_hmac                      [RFC3546]
-    5   status_request                      [RFC3546]
-    6                                       [srp-10] [*5] [*13] [*17]
-    7                                       [openpgp-06] [*5] [*17]
-    8                                       [express-01] 
-    9                                       [prf-00] [*4] 
-   10                                       [ecc-12]
-   11                                       [ecc-12]
-   35                                       [ticket-05] [fast-00] 
-37703                                       [ia-01] 
-60000                                       [*3]
-
-
-REFERENCES AND NOTES
-====================
-
-[ecc-12]        Simon Blake-Wilson, Nelson Bolyard, Vipul Gupta, Chris
-                Hawk, and Bodo Moeller, "ECC Cipher Suites For TLS",
-                draft-ietf-tls-ecc-12, October 2005.
-
-[openpgp-06]    Nikos Mavroyanopoulos, "Using OpenPGP keys for TLS
-                authentication", draft-ietf-tls-openpgp-keys-06,
-                January 2005.
-
-[srp-10]        David Taylor, Tom Wu, Nikos Mavroyanopoulos, and
-                Trevor Perrin, "Using SRP for TLS Authentication",
-                draft-ietf-tls-srp-10, October 2005.
-
-[psk-09]	Pasi Eronen and Hannes Tschofenig, "Pre-Shared Key 
-                Ciphersuites for Transport Layer Security (TLS)",
-                draft-ietf-tls-psk-09, June 2005.
-
-[cptls-02]      Grigorij Chudov and Serguei Leontiev, "GOST 
-                Ciphersuites for Transport Layer Security",
-                draft-chudov-cryptopro-cptls-02, September 2005.
-
-[express-01]    Mohamad Badra, Ahmed Serhrouchni, and Pascal Urien,
-                "TLS Express", draft-badra-tls-express-01, February 2005.
-
-[fast-00]       Nancy Cam-Winget, David McGrew, Joseph Salowey, and
-                Hao Zhou, "EAP Flexible Authentication via Secure
-                Tunneling (EAP-FAST)", draft-cam-winget-eap-fast-00,
-                February 2004.
-
-[ia-01]         Paul Funk, Simon Blake-Wilson, Ned Smith, Hannes
-                Tschofenig, and Thomas Hardjono, "TLS Inner Application 
-                Extension (TLS/IA)", draft-funk-tls-inner-application-
-                extension-01, February 2005.
-
-[ssl3]          Alan O. Freier, Philip Karlton, and Paul C. Kocher,
-                "The SSL Protocol Version 3.0", expired I-D
-                (draft-freier-ssl-version3-02.txt), November 1996.
-
-[dtls-05]       Eric Rescorla and Nagendra Modadugu, "Datagram
-                Transport Layer Security", draft-rescorla-dtls-05, 
-                June 2005.
-
-[sign-00]       Ibrahim Hajjeh, Ahmed Serhrouchni, Mohamad Badra, 
-                and Omar Cherkaoui, "TLS Sign", 
-                draft-hajjeh-tls-sign-00, January 2005.
-
-[prf-00]        Grigorij Chudov, "Hash/PRF negotiation in TLS using 
-                TLS extensions", draft-chudov-cryptopro-tlsprfneg-00,
-                May 2005.
-
-[56bit]         John Banes and Richard Harrington, "56-bit Export
-                Cipher Suites For TLS", expired Internet-Draft
-                draft-ietf-tls-56-bit-ciphersuites-01.txt, July
-                2001 (and version -00, January 1999). Although this  
-                document was never published as RFC, these ciphersuites 
-                are implemented by several vendors. Draft version -00
-                contains ciphersuites 0x60..63; version -01 includes
-                0x62..66.
-
-[fips]          FIPS SSL CipherSuites, http://www.mozilla.org/projects/
-                security/pki/nss/ssl/fips-ssl-ciphersuites.html
-
-[mtls-00]       Mohamad Badra, Ibrahim Hajjeh, "TLS Multiplexing", 
-                draft-badra-hajjeh-mtls-00, October 2005.
-
-[*1]            This number was previously used for 
-                SSL_FORTEZZA_KEA_WITH_RC4_128_SHA in [ssl3]
-
-[*2]            Used by some OpenSSL development snapshots and 
-                NSS 3.8/3.9, obsoleted by [ecc-12].
-
-[*3]            This number was used by an earlier version of [cptls-02],
-                but presumably this work has been superceded by [prf-00],
-                and the number can be reused for other purposes.
-           
-[*4]            This number was used in draft-badra-tls-key-exchange-00
-                (Mohamad Badra, Omar Cherkaoui, Ibrahim Hajjeh, and
-                Ahmed Serhrouchni, "Pre-Shared-Key key Exchange
-                methods for TLS", August 2004), but presumably this
-                work has been superceded by [psk-09] and the number 
-                can be reused for other purposes.
-
-[*5]            These numbers were used in
-                draft-shacham-tls-fast-track-00 (Hovav Shacham and Dan
-                Boneh, "TLS Fast-Track Session Establishment",
-                September 2001), but presumably this work is dead, and
-                the numbers can be used for other purposes.
-
-[*6]		These numbers were used in older versions of [ia-01].
-
-[*7]            These numbers were used by an older, obsolete 
-                version of draft-lee-tls-seed (now RFC4162).
-
-[*8]            These numbers were used in draft-ietf-tls-seedhas-00 
-                (Joo-won Jung and ChangHee Lee, "TLS Extension for SEED
-                and HAS-160", July 2000), but presumably this work is 
-                dead, and the numbers can be used for other purposes.
-
-[*9]            This number was in draft-ietf-tls-delegation-01 
-                (Keith Jackson, Steven Tuecke, and Doug Engert, "TLS
-                Delegation Protocol", February 2002), but presumably
-                this work is dead and the number can be reused for
-                other purposes.
-
-[*10]           These numbers were used in draft-ietf-tls-misty1-01
-                (Hidenori Ohta and Hirosato Tsuji, "Addition of MISTY1
-                to TLS", March 2001), but presumably this work is dead
-                and the numbers can be reused for other purposes.
-
-[*11]           These numbers were used in draft-ietf-tls-ntru-00 (Ari
-                Singer, "NTRU Cipher Suites for TLS", July 2001), but
-                presumably this work is dead and the numbers can be
-                reused for other purposes.
-
-[*12]           These numbers were used in draft-ietf-tls-ntru-00,
-                but presumably this work is dead, and and many of 
-                the numbers are widely used for other purposes anyway.
-
-[*13]           These numbers were used in draft-ietf-tls-pathsec-00
-                (Joseph Hui, "TLS Pathsec Protocol", September 2001),
-                but presumably this work is dead, and the numbers
-                can be used for other purposes.
-
-[*14]           These numbers were used in draft-ietf-tls-openpgp-02
-                (Will Price and Michael Elkins, "Extensions to TLS for
-                OpenPGP keys", February 2002), but presumably this
-                work is dead, and the numbers can be used for other
-                purposes.
-
-[*15]           These numbers were used in draft-madhu-tls-spki-00
-                (H. S. Madhusudhana and V. R. Ramachandran, "SPKI
-                Certificate Integration with Transport Layer Security
-                (TLS) for Client Authentication and Authorization",
-                July 2001), but presumably this work is dead, and the
-                numbers can be used for other purposes.
-
-[*16]           These numbers were used in draft-ietf-tls-kerb-01
-                (Matthew Hur, Joseph Salowey, and Ari Medvinsky,
-                "Kerberos Cipher Suites in Transport Layer Security
-                (TLS)", November 2001), but presumably this work is
-                dead, and the numbers can be used for other purposes.
-                
-[*17]		These numbers were used in older versions of [ecc-12].
-
diff --git a/doc/protocol/x509guide.txt b/doc/protocol/x509guide.txt
deleted file mode 100644
index 4c96aa8f18..0000000000
--- a/doc/protocol/x509guide.txt
+++ /dev/null
@@ -1,3045 +0,0 @@
-                             X.509 Style Guide
-                             =================
-
-                  Peter Gutmann, pgut001@cs.auckland.ac.nz
-                                 October 2000
-
-[This file is frequently cited as a reference on PKI issues, when in fact it
- was really intended as X.509 implementation notes meant mostly for
- developers, to tell them all the things the standards leave out.  If you're
- looking for a general overview of PKI that includes most of what's in here
- but presented in a more accessible manner, you should use "Everything you
- never wanted to know about PKI but have been forced to find out",
- http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf, a less technical
- overview aimed at people charged with implementing and deploying the
- technology.  If you need to know what you're in for when you work with PKI,
- this is definitely the one to read.  Further PKI information and material can
- be found on my home page, http://www.cs.auckland.ac.nz/~pgut001/].
-
-There seems to be a lot of confusion about how to implement and work with X.509
-certificates, either because of ASN.1 encoding issues, or because vagueness in
-the relevant standards means people end up taking guesses at what some of the
-fields are supposed to look like.  For this reason I've put together these
-guidelines to help in creating software to work with X.509 certificates, PKCS
-#10 certification requests, CRLs, and other ASN.1-encoded data types.
-
-                    I knew a guy who set up his own digital ID heirarchy, could
-                    issue his own certificates, sign his own controls, ran SSL
-                    on his servers, etc.  I don't need to pay Verisign a
-                    million bucks a year for keys that expire and expire.  I
-                    just need to turn off the friggen [browser warning]
-                    messages.
-                        -- Mark Bondurant, "Creating My Own Digital ID", in
-                           alt.computer.security.
-
-In addition, anyone who has had to work with X.509 has probably experienced
-what can best be described as ISO water torture, which involves ploughing
-through all sorts of ISO, ANSI, ITU, and IETF standards, amendments, meeting
-notes, draft standards, committee drafts, working drafts, and other
-work-in-progress documents, some of which are best understood when held
-upside-down in front of a mirror (this has lead to people trading hard-to-find
-object identifiers and ASN.1 definitions like baseball cards - "I'll swap you
-the OID for triple DES in exchange for the latest CRL extensions").  This
-document is an attempt at providing a cookbook for certificates which should
-give you everything that you can't easily find anywhere else, as well as
-comments on what you'd typically expect to find in certificates.
-
-                    Given humanity's track record with languages, you wonder
-                    why we bother with standards committies
-                        -- Marcus Leech
-
-Since the original X.509 spec is somewhat vague and open-ended, every
-non-trivial group which has any reason to work with certificates has to produce
-an X.509 profile which nails down many features which are left undefined in
-X.509.
-                    You can't be a real country unless you have a beer and an
-                    airline.  It helps if you have some kind of a football
-                    team, or some nuclear weapons, but at the very least you
-                    need a beer.
-                        -- Frank Zappa
-                    And an X.509 profile.
-                        -- Me
-
-The difference between a specification (X.509) and a profile is that a
-specification doesn't generally set any limitations on combinations what can
-and can't appear in various certificate types, while a profile sets various
-limitations, for example by requiring that signing and confidentiality keys be
-different (the Swedish profile requires this, and the German profile specifies
-exclusive use of certificates for digital signatures).  The major profiles in
-use today are:
-
-    PKIX - Internet PKI profile.
-    FPKI - (US) Federal PKI profile.
-    MISSI - US DoD profile.
-    ISO 15782 - Banking - Certificate Management Part 1: Public Key
-        Certificates.
-    TeleTrust/MailTrusT - German MailTrusT profile for TeleTrusT (it really is
-        capitalised that way).
-    German SigG Profile - Profile to implement the German digital signature law
-		(the certificate profile SigI is particularly good, providing not just
-		the usual specification but also examples of each certificate field and
-		extension including the encoded forms).
-    ISIS Profile - Another German profile.
-    Australian Profile - Profile for the Australian PKAF (this may be the same
-        as DR 98410, which I haven't seen yet).
-    SS 61 43 31 Electronic ID Certificate - Swedish profile.
-    FINEID S3 - Finnish profile.
-    ANX Profile - Automotive Network Exchange profile.
-    Microsoft Profile - This isn't a real profile, but the software is
-        widespread enough and nonstandard enough that it constitutes a
-        significant de facto profile.
-
-                    No standard or clause in a standard has a divine right of
-                    existence
-                        -- A Microsoft PKI architect explaining Microsoft's
-                           position on standards compliance.
-
-Unfortunately the official profiles tend to work like various monotheistic
-religions where you either do what we say or burn in hell (that is, conforming
-to one profile generally excludes you from claiming conformance with any others
-unless they happen to match exactly).  This means that you need to either
-create a chameleon-like implementation which can change its behaviour at a
-whim, or restrict yourself to a single profile which may not be accepted in
-some locales.  There is (currently) no way to mark a certificate to indicate
-that it should be processed in a manner conformant to a particular profile,
-which makes it difficult for a relying party to know how their certificate will
-be processed by a particular implementation.
-
-                    Interoperability Testing.  Conclusion: It doesn't work
-                        -- Richard Lampart, CESG, talking about UK government
-                           PKI experiences
-
-Although I've tried to take into account the various "Use of this feature will
-result in the immediate demise of all small furry animals in an eight-block
-radius"-type warnings contained in various standards documents to find a lowest
-common denominator set of rules which should result in the least pain for all
-concerned if they're adhered to, the existence of conflicting profiles makes
-this a bit difficult.  The idea behind the guide is to at least try to present
-a "If you do this, you should be OK" set of guidelines, rather than a "You're
-theoretically allowed to do this if you can find an implementation which
-supports it" feature list.
-
-Finally, the guide contains a (rather lengthy) list of implementation errors,
-bugs, and problems to look out for with various certificates and the related
-software in order to allow implementors to create workarounds.
-
-The conventions used in the text are:
-
-- All encodings follow the DER unless otherwise noted.
-
-- Most of the formats are ASN.1, or close enough to it to be understandable
-  (the goal was to make it easily understandable, not perfectly grammatically
-  correct).  Occasionally 15 levels of indirection are cut out to make things
-  easier to understand.
-
-                    The resulting type and value of an instance of use of the
-                    new value notation is determined by the value (and the type
-                    of the value) finally assigned to the distinguished local
-                    reference identified by the keyword VALUE, according to the
-                    processing of the macrodefinition for the new type notation
-                    followed by that for the new value notation.
-                        -- ISO 8824:1988, Annex A
-
-Certificate
------------
-
-Certificate ::= SEQUENCE {
-    tbsCertificate          TBSCertificate,
-    signatureAlgorithm      AlgorithmIdentifier,
-    signature               BIT STRING
-    }
-                    The goal of a cert is to identify the holder of the
-                    corresponding private key, in a fashion meaningful to
-                    relying parties.
-                        -- Stephen Kent
-
-                    By the power vested in me, I now declare this text string
-                    and this bit string 'name' and 'key'.  What RSA has joined,
-                    let no man put asunder.
-                        -- Bob Blakley
-
-The encoding of the Certificate may follow the BER rather than the DER.  At
-least one implementation uses the indefinite-length encoding form for the
-SEQUENCE.
-
-
-TBSCertificate
---------------
-
-The default tagging for certificates varies depending on which standard you're
-using.  The original X.509v1 definition used the ASN.1 default of explicit
-tags, with X.509v3 extensions in a separate module with implicit tags.  The
-PKIX definition is quite confusing because the ASN.1 definitions in the
-appendices use TAGS IMPLICIT but mix in X.509v3 definitions which use explicit
-tags.  Appendix A has such a mixture of implied implicit and implied explicit
-tags that it's not really possible to tell what tagging you're supposed to use.
-Appendix B (which first appeared in draft 7, March 1998) is slightly better,
-but still confusing in that it starts with TAGS IMPLICIT, but tries to
-partially switch to TAGS EXPLICIT for some sections (for example the
-TBSCertificate has an 'EXPLICIT' keyword in the definition which is probably
-intended to signify that everything within it has explicit tagging, except that
-it's not valid ASN.1).  The definitions given in the body of the document use
-implicit tags, and the definitions of TBSCertificate and and TBSCertList have
-both EXPLICIT and IMPLICIT tags present.  To resolve this, you can either rely
-entirely on Appendix B with the X.509v1 sections moved into a separate section
-declared without 'IMPLICIT TAGS', or use the X.509v3 definitions.  The SET
-definitions consistently use implicit tags.
-
-                    Zaphod felt he was teetering on the edge of madness and
-                    wondered whether he shouldn't just jump over and have done
-                    with it.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-TBSCertificate ::= SEQUENCE {
-    version          [ 0 ]  Version DEFAULT v1(0),
-    serialNumber            CertificateSerialNumber,
-    signature               AlgorithmIdentifier,
-    issuer                  Name,
-    validity                Validity,
-    subject                 Name,
-    subjectPublicKeyInfo    SubjectPublicKeyInfo,
-    issuerUniqueID    [ 1 ] IMPLICIT UniqueIdentifier OPTIONAL,
-    subjectUniqueID   [ 2 ] IMPLICIT UniqueIdentifier OPTIONAL,
-    extensions        [ 3 ] Extensions OPTIONAL
-    }
-
-
-Version
--------
-
-Version ::= INTEGER { v1(0), v2(1), v3(2) }
-
-This field is used mainly for marketing purposes to claim that software is
-X.509v3 compliant (even when it isn't).  The default version is v1(0), if the
-issuerUniqueID or subjectUniqueID are present than the version must be v2(1) or
-v3(2).  If extensions are present than the version must be v3(2).  An
-implementation should target v3 certificates, which is what everyone is moving
-towards.
-                    I was to learn later in life that we tend to meet any new
-                    situation by reorganizing: and a wonderful method it can be
-                    for creating the illusion of progress, while producing
-                    confusion, inefficiency and demoralization
-                        -- Petronius Arbiter, ~60 A.D
-
-Note that the version numbers are one less than the actual X.509 version
-because in the ASN.1 world you start counting from 0, not 1 (although it's not
-necessary to use sequences of integers for version numbers.  X.420, for
-example, is under the impression that 2 is followed by 22 rather than the more
-generally accepted 3).
-
-If your software generates v1 certificates, it's a good idea to actually mark
-them as such and not just mark everything as v3 whether it is or not. Although
-no standard actually forbids marking a v1 certificate as v3, backwards-
-compatibility (as well as truth-in-advertising) considerations would indicate
-that a v1 certificate should be marked as such.
-
-
-SerialNumber
-------------
-
-CertificateSerialNumber ::= INTEGER
-
-This should be unique for each certificate issued by a CA (typically a CA will
-keep a counter in persistent store somewhere, perhaps a config file under Unix
-and in the registry under Windows).  A better way is to take the current time
-in seconds and subtract some base time like the first time you ran the
-software, to keep the numbers manageable.  This has the further advantage over
-a simple sequential numbering scheme that it doesn't allow tracking of the
-number of certificates which have been signed by a CA, which can have nasty
-consequences both if various braindamaged government regulation attempts ever
-come to fruition, and because by using sequential numbers a CA ends up
-revealing just how few certs it's actually signing (at the cost of a cert per
-week, the competition can find out exactly how many certs are being issued each
-week).
-
-Although this is never mentioned in any standards document, using negative
-serial numbers is probably a bit silly (note the caveat about encoding INTEGER
-values in the section on SubjectPublicKeyInfo).
-
-Serial numbers aren't necessarily restricted to 32-bit quantitues.  For example
-the RSADSI Commercial Certification Authority serial number is 0x0241000016,
-which is larger than 32 bits, and Verisign seem to like using 128 or 160-bit
-hashes as serial numbers.  If you're writing certificate-handling code, just
-treat the serial number as a blob which happens to be an encoded integer (this
-is particularly important for the case of the vendors who have forgotten that
-the high bit of an integer is the sign bit, and generate negative serial
-numbers for their certificates).
-
-
-Signature
----------
-
-This rather misnamed field contains the algorithm identifier for the signature
-algorithm used by the CA to sign the certificate.  There doesn't seem to be
-much use for this field, although you should check that the algorithm
-identifier matches the one of the signature on the cert (if someone can forge
-the signature on the cert then they can also change the inner algorithm
-identifier, it's possible that this was included because of some obscure attack
-where someone who could convince (broken) signature algorithm A to produce the
-same signature value as (secure) algorithm B could change the outer,
-unprotected algorithm identifier from B to A, but couldn't change the inner
-identifier without invalidating the signature.  What this would achieve is
-unclear).
-
-Be very careful with your use of Object Identifiers.  In many cases there are a
-great many OIDs available for the same algorithm, but the exact OID you're
-supposed to use varies somewhat.
-
-                    You see, the conditional modifers depend on certain
-                    variables like the day of the week, the number of players,
-                    chair positions, things like that. [...] There can't be
-                    more than a dozen or two that are pertinent.
-                        -- Robert Asprin, "Little Myth Marker"
-
-Your best bet is to copy the OIDs everyone else uses and/or use the RSADSI or
-X9 OIDs (rather than the OSI or OIW or any other type of OID).  OTOH if you
-want to be proprietary while still pretending to follow a standard, use OSI
-OID's which are often underspecified, so you can do pretty much whatever you
-want with things like block formatting and padding.
-
-Another pitfall to be aware of is that algorithms which have no parameters have
-this specified as a NULL value rather than omitting the parameters field
-entirely.  The reason for this is that when the 1988 syntax for
-AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL
-associated with the AlgorithmIdentifier parameters got lost.  Later it was
-recovered via a defect report, but by then everyone thought that algorithm
-parameters were mandatory.  Because of this the algorithm parameters should be
-specified as NULL, regardless of what you read elsewhere.
-
-                    The trouble is that things *never* get better, they just
-                    stay the same, only more so
-                        -- Terry Pratchett, "Eric"
-
-
-Name
-----
-
-Name ::= SEQUENCE OF RelativeDistinguishedName
-
-RelativeDistinguishedName ::= SET OF AttributeValueAssertion
-
-AttributeValueAssertion ::= SEQUENCE {
-    attributeType           OBJECT IDENTIFIER,
-    attributeValue          ANY
-    }
-
-This is used to encode that wonderful ISO creation, the Distinguished Name
-(DN), a path through an X.500 directory information tree (DIT) which uniquely
-identifies everything on earth.  Although the RelativeDistinguishedName (RDN)
-is given as a SET OF AttributeValueAssertion (AVA) each set should only contain
-one element.  However you may encounter other people's certs which could
-contain more than one AVA per set, there has been a reported sighting of a
-certificate which contained more than one element in the SET.
-
-                    When the X.500 revolution comes, your name will be lined
-                    up against the wall and shot
-                        -- John Gilmore
-                    They can't be read, written, assigned, or routed.  Other
-                    than that, they're perfect
-                        -- Marshall Rose
-
-When encoding sets with cardinality > 1, you need to take care to follow the
-DER rules which say that they should be ordered by their encoded values
-(although ASN.1 says a SET is unordered, the DER adds ordering rules to ensure
-it can be encoded in an unambiguous manner).  What you need to do is encode
-each value in the set, then sort them by the encoded values, and output them
-wrapped up in the SET OF encoding,
-
-                    First things first, but not necessarily in that order.
-                        -- Dr.Who
-
-however your software really shouldn't be producing these sorts of RDN entries.
-
-In theory you don't have to use a Name for the subject name if you don't want
-to; there is a subjectAltName extension which allows use of email addresses or
-URL's.  In theory if you want to do this you can make the Name an empty
-sequence and include a subjectAltName extension and mark it critical, but this
-will break a lot of implementations.  Because it is possible to do this, you
-should be prepared to accept a zero-length sequence for the subject name in
-version 3 certificates.  Since the DN is supposed to encode the location of the
-certificate in a DIT, having a null issuer name would mean you couldn't
-actually locate the certificate, so CAs will need to use proper DNs.  The
-S/MIME certificate spec codifies this by requiring that all issuer DNs be non-
-null (so only an end-user certificate can have a null DN, and even then it's
-not really recommended), and this requirement was back-ported to the PKIX
-profile shortly before it was finalised.  The reason for requiring issuer DNs
-is that S/MIME v2 and several related standards identify certificates by issuer
-and serial number, so all CA certificates must contain an issuer DN (S/MIME v3
-allows subjectKeyIdentifiers, but they're almost never used).
-
-SET provides an eminently sensible definition for DNs:
-
-  Name ::= SEQUENCE SIZE(1..5) OF RelativeDistinguishedName
-
-  RelativeDistinguishedName ::= SET SIZE(1) OF AttributeTypeAndValue
-
-  AttributeTypeAndValue ::= { OID, C | O | OU | CN }
-
-This means that when you see a SET DN it'll be in a fixed, consistent, and
-easy-to-process format (note in particular the fixed maximum size, the
-requirement for a single element per AVA, and the restriction to sensible
-element types).
-
-Note that the (issuer name, serialNumber (with a possible side order of
-issuerUniqueID, issuerAltName, and keyUsage extension)) tuple uniquely
-identifies a certificate and can be used as a key to retrieve certificates
-from an information store.  The subject name alone does not uniquely identify
-a certificate because a subject can own multiple certificates.
-
-You would normally expect to find the following types of AVAs in an X.509
-certificate, starting from the top:
-
-countryName     ::= SEQUENCE { { 2 5 4 6 }, StringType( SIZE( 2 ) ) }
-organization    ::= SEQUENCE { { 2 5 4 10 }, StringType( SIZE( 1...64 ) ) }
-organizationalUnitName
-                ::= SEQUENCE { { 2 5 4 11 }, StringType( SIZE( 1...64 ) ) }
-commonName      ::= SEQUENCE { { 2 5 4 3 }, StringType( SIZE( 1...64 ) ) }
-
-You might also find:
-
-localityName    ::= SEQUENCE { { 2 5 4 7 }, StringType( SIZE( 1...64 ) ) }
-stateOrProvinceName
-                ::= SEQUENCE { { 2 5 4 8 }, StringType( SIZE( 1...64 ) ) }
-
-Some profiles require at least some of these AVAs to be present, for example
-the German profile requires at least a countryName and commonName, and in some
-cases also an organization name.  This is a reasonable requirement, as a
-minimum you should always include the country and common name.
-
-Finally, you'll frequently also run into:
-
-emailAddress    ::= SEQUENCE { { 1 2 840 113549 1 9 1 }, IA5String }
-
-from PKCS #9, although this shouldn't be there.
-
-                    I can't afford to make exceptions.  Once word leaks out that
-                    a pirate has gone soft, people begin to disobey you and
-                    it's nothing but work, work, work all the time
-                        -- The Dread Pirate Roberts, "The Princess Bride"
-
-The reason why oddball components like the emailAddress have no place in a DN
-created as per the original X.500 vision is because the whole DN is intended to
-be a strictly heirarchical construction specifying a path through a DIT.
-Unfortunately the practice adopted by many CAs of tacking on an emailAddress,
-an element which has no subordinate relationship to the other components of the
-DN, creates a meaningless mishmash which doesn't follow this hierarchical
-model.  For this reason the ITU defined the GeneralName, which specifically
-allows for components such as email addresses, URL's, and other non-DN items.
-GeneralNames are discussed in "Extensions" below.
-
-Since the GeneralName provides a proper means of specifying information like
-email addresses, your software shouldn't populate DNs with these components,
-however for compatibility with legacy implementations you need to be able to
-accept existing certificates which contain odd things in the DN.  Currently all
-mailers appear to be able to handle an rfc822Name in an altName, so storing it
-in the correct location shouldn't present any interoperability problems.  One
-problem with email address handling is that many mailers will accept not only
-'J.Random Luser <jrandom@aol.com>' as a valid emailAddress/rfc822Name but will
-be equally happy with 'President William Jefferson Clinton <jrandom@aol.com>'.
-The former is simply invalid, but the latter can be downright dangerous because
-it completely bypasses the stated purpose of email certificates, which is to
-identify the other party in an email exchange.  Both PKIX and S/MIME explicitly
-require that an rfc822Name only contain an RFC 822 addr-spec which is defined
-as local-part@domain, so the mailbox form 'Personal Name <local-part@domain>'
-isn't allowed (many S/MIME implementations don't enforce this though).
-Unfortunately X.509v3 just requires "an Internet electronic mail address
-defined in accordance with Internet RFC 822" without tying it down any further,
-so it could be either an addr-spec or a mailbox.
-
-                    Okay, I'm going home to drink moderately and then pass out.
-                        -- Steve Rhoades, "Married with Children"
-
-The countryName is the ISO 3166 code for the country.  Noone seems to know how
-to specify non-country-aligned organisations, it's possible that 'EU' will be
-used at some point but there isn't any way to encode a non-country code
-although some organisations have tried using 'INT'.  Actually noone really even
-knows what a countryName is supposed to refer to (let alone something as
-ambiguous as "locality"), for example it could be your place of birth, country
-of citizenship, country of current residence, country of incorporation, country
-where corporate HQ is located, country of choice for tax and/or jurisdictional
-issues, or a number of other possibilities (moving from countryName to
-stateOrProvinceName, people in the US military can choose a state as their
-official "residence" for tax purposes even if they don't own any property in
-that state, and politicians are allowed to run for office in one state while
-their wives claim residence and run for office in another state).
-
-The details of the StringType are discussed further down.  It's a good idea to
-actually limit the string lengths to 64 characters as required by X.520
-because, although many implementations will accept longer encoded strings in
-certs, some can't manipulate them once they've been decoded by the software,
-and you'll run into problems with LDAP as well.  This means residents of places
-like Taumatawhakatangihangakoauotamateaturipukakapikimaungahoronukupokai-
-whenuakitanataha are out of luck when it comes to getting X.509 certs.
-
-Comparing two DNs has its own special problems, and is dealt with in the rather
-lengthy "Comparing DNs" section below.
-
-There appears to be some confusion about what format a Name in a certificate
-should take.
-                    Insufficient facts always invite danger
-                        -- Spock, "Space Seed"
-
-In theory it should be a full, proper DN, which traces a path through the X.500
-DIT, eg:
-
-  C=US, L=Area 51, O=Hanger 18, OU=X.500 Standards Designers, CN=John Doe
-
-but since the DIT's usually don't exist, exactly what format the DN should take
-seems open to debate.  A good guideline to follow is to organize the namespace
-around the C, O, OU, and CN attribute types, but this is directed primarily at
-corporate structures.  You may also need to use ST(ate) and L(ocality) RDNs.
-Some implementations seem to let you stuff anything with an OID into a DN,
-which is not good.
-                    There is nothing in any of these standards that would
-                    prevent me from including a 1 gigabit MPEG movie of me
-                    playing with my cat as one of the RDN components of the DN
-                    in my certificate.
-                        -- Bob Jueneman on IETF-PKIX
-                           (There is a certificate of this form available from
-                           http://www.cs.auckland.ac.nz/~pgut001/pubs/
-                           {dave_ca|dave}.der, although the MPEG is limited to
-                           just over 1MB)
-
-With a number of organisations moving towards the use of LDAP-based directory
-services, it may be that we'll actually see X.500 directories in our lifetime,
-
-                    Well, it just so happens that your friend here is only
-                    mostly dead.  There's a big difference between mostly dead
-                    and all dead.  Now, mostly dead is slightly alive.
-                        -- Miracle Max, "The Princess Bride"
-
-which means you should make an attempt to have a valid DN in the certificate.
-LDAP uses the RFC 1779 form of DN, which is the opposite endianness to the ISO
-9594 form used above:
-
-  CN=John Doe, OU=X.500 Standards Designers, O=Hanger 18, L=Area 51, C=US
-
-                    There are always alternatives
-                        -- Spock, "The Galileo Seven"
-
-In order to work with LDAP implementations, you should ensure you only have a
-single AVA per RDN (which also avoids the abovementioned DER-encoding hassle).
-
-As the above text has probably indicated, DNs don't really work - there's no
-clear idea of what they should look like, most users don't know about (and
-don't want to know about) X.500 and its naming conventions, and as a
-consequence of this the DN can end up containing just about anything.  At the
-moment they seem to be heading in two main directions:
-
- - Public CAs typically set C=CA country, O=CA name, OU=certificate type,
-   CN=user name
-   - A small subset of CAs in Europe which issue certs in accordance with
-     various signature laws and profiles with their own peculiar requirements
-     can have all sorts of oddities in the DN.  You won't run into many of
-     these in the wild.
-   - A small subsets of CAs will modify the DN by adding a unique ID value to
-     the CN to make it a truly Distinguished Name.  See the Bugs and
-     Peculiarities sections for more information on this.
- - Private CAs (mostly people or organisations signing their own certs)
-   typically set any DN fields supported by their software to whatever makes
-   sense for them (some software requires all fields in the set
-   {C,O,OU,SP,L,CN} to be filled in, leading to strange or meaningless entries
-   as people try and guess what a Locality is supposed to be).
-
-Generally you'll only run into certs from public CAs, for which the general
-rule is that the cert is identified by the CN and/or email address.  Some CAs
-issue certs with identical CN's and use the email address to disambiguate them,
-others modify the CN to make it unique.  The accepted user interface seems to
-be to let users search on the CN and/or email address (and sometimes also the
-serial number, which doesn't seem terribly useful), display a list of matches,
-and let the user pick the cert they want.  Probably the best strategy for a
-user interface which handles certs is:
-
-  if( email address known )
-    get a cert which matches the email address (any one should do);
-  elseif( name known )
-    search for all certs with CN=name;
-    if( multiple matches )
-      display email addresses for matched certs to user, let them choose;
-  else
-    error;
-
-If you need something unique to use as an identifier (for example for a
-database key) and you know your own software (or more generally software which
-can do something useful with the identifier) will be used, use an X.500
-serialNumber in a subjectAltName directoryName or use a subjectAltName
-otherName (which was explicitly created to allow user-defined identifiers).
-For internal cert lookups, encode the cert issuer and serial number as a PKCS
-#7 issuerAndSerialNumber, hash it down to a fixed size with SHA-1 (you can
-either use the full 20 bytes or some convenient truncated form like 64 bits),
-and use that to identify the cert.  This works because the internal structure
-of the DN is irrelevant anyway, and having a fixed-size unique value makes it
-very easy to perform a lookup in various data structures (for example the
-random hash value generated leads to probabalistically balanced search trees
-without requiring any extra effort).
-
-
-Validity
---------
-
-Validity ::= SEQUENCE {
-    notBefore               UTCTIME,
-    notAfter                UTCTIME
-    }
-
-This field denotes the time at which you have to pay your CA a renewal fee to
-get the certificate reissued.  The IETF originally recommended that all times
-be expressed in GMT and seconds not be encoded, giving:
-
-  YYMMDDHHMMZ
-
-as the time encoding.  This provided an unambiguous encoding because a value of
-00 seconds was never encoded, which meant that if you read a UTCTime value
-generated by an implementation which didn't use seconds and wrote it out again
-with an implementation which did, it would have the same encoding because the
-00 wouldn't be encoded.
-
-However newer standards (starting with the Defence Messaging System (DMS),
-SDN.706), require the format to be:
-
-  YYMMDDHHMMSSZ
-
-even if the seconds are 00.  The ASN.1 encoding rules were in late 1996 amended
-so that seconds are always encoded, with a special note that midnight is
-encoded as ...000000Z and not ...240000Z.  You should therefore be prepared to
-encounter UTCTimes with and without the final 00 seconds field, however all
-newer certificates encode 00 seconds.  If you read and then write out an
-existing object you may need to remember whether the seconds were encoded or
-not in the original because adding the 00 will invalidate the signature (this
-problem is slowly disappearing as pre-00 certificates expire).
-
-A good workaround for this problem when generating certificates is to ensure
-that you never generate a certificate with the seconds set to 00, which means
-that even if other software re-encodes your certificate, it can't get the
-encoding wrong.
-
-At least one widely-used product generated incorrect non-GMT encodings so you
-may want to consider handling the "+/-xxxx" time offset format, but you should
-flag it as a decoding error nonetheless.
-
-In coming up with the worlds least efficient machine-readable time encoding
-format, the ISO nevertheless decided to forgo the encoding of centuries, a
-problem which has been kludged around by redefining the time as UTCTime if the
-date is 2049 or ealier, and GeneralizedTime if the date is 2050 or later (the
-original plan was to cut over in 2015, but it was felt that moving it back to
-2050 would ensure that the designers were either retired or dead by the time
-the issue became a serious problem, leaving someone else to take the blame).
-To decode a date, if it's UTCTime and the year is less than or equal to 49 it's
-20xx, if it's UTCTime and the year is equal to or greater than 50 it's 19xx,
-and if it's GeneralizedTime it's encoded properly (but shouldn't really be used
-for dates before 2050 because you could run into interoperability problems with
-existing software).  Yuck.
-
-To make this even more fun, another spec at one time gave the cutover date as
-2050/2051 rather than 2049/2050, and allowed GeneralizedTime to be used before
-2050 if you felt you could get away with it.  It's likely that a lot of
-conforming systems will briefly become nonconforming systems in about half a
-centuries time, in a kind of security-standards equivalent of the age-old
-paradox in which Christians and Moslems will end up in the other side's version
-of hell.
-                    Confusion now hath made his masterpiece.
-                        -- Macduff, "Macbeth", II.i.
-
-Another issue to be aware of is the problem of issuer certificates which have a
-different validity time than the subject certificates they are used to sign.
-Although this isn't specified in any standard, some software requires validity
-period nesting, in which the subject validity period lies inside the issuer
-validity period.  Most software however performs simple pointwise checking in
-which it checks whether a cert chain is valid at a certain point in time
-(typically the current time).  Maintaining the validity nesting requires that a
-certain amount of care be used in designing overlapping validity periods
-between successive generations of certificates in a hierarchy.  Further
-complications arise when an existing CA is re-rooted or re-parented (for
-example a divisional CA is subordinated to a corporate CA).  Australian and New
-Zealand readers will appreciate the significance of using the term "re-rooted"
-to describe this operation.
-
-Finally, CAs are handling the problem of expiring certificates by reissuing
-current ones with the same name and key but different validity periods.  In
-some cases even CA roots have been reissued with the only different being
-extended validity periods.  This can result in multiple identical-seeming
-certificates being valid at one time (in one case three certificates with the
-same DN and key were valid at once).  The semantics of these certificates/keys
-are unknown.  Perhaps Validity could simply be renamed to RenewalFeeDueDate to
-reflect its actual usage.
-
-An alternative way to avoid expiry problems is to give the certificate an
-expiry date several decades in the future.  This is popular for CA certs which
-don't require an annual renewal fee.
-
-
-SubjectPublicKeyInfo
---------------------
-
-This contains the public key, either a SEQUENCE of values or a single INTEGER.
-Keep in mind that ASN.1 integers are signed, so if any integers you want to
-encode have the high bit set you need to add a single zero octet to the start
-of the encoded value to ensure that the high bit isn't mistaken for a sign bit.
-In addition you are allowed at most a single 0 byte at the start of an encoded
-value (and that only when the high bit is set), if the internal representation
-you use contains zero bytes at the start you have to remove them on encoding.
-This is a bit of a nuisance when encoding signatures which have INTEGER values,
-since you can't tell how big the encoded signature will be without actually
-generating it.
-
-
-UniqueIdentifier
-----------------
-
-UniqueIdentifier ::= BITSTRING
-
-These were added in X509v2 to handle the possible reuse of subject and/or
-issuer names over time.  Their use is deprecated by the IETF, so you shouldn't
-generate these in your certificates.  If you're writing certificate-handling
-code, just treat them as a blob which happens to be an encoded bitstring.
-
-
-Extensions
-----------
-
-Extensions ::= SEQUENCE OF Extension
-
-Extension ::= SEQUENCE {
-    extnid                  OBJECT IDENTIFIER,
-    critical                BOOLEAN DEFAULT FALSE,
-    extnValue               OCTETSTRING
-    }
-
-X.509 certificate extensions are like a LISP property list: an ISO-standardised
-place to store crufties.  Extensions can consist of key and policy information,
-certificate subject and issuer attributes, certificate path constraints, CRL
-distribution points, and private extensions.
-
-X.509v3 and the X.509v4 draft contains the ASN.1 formats for the standard V3
-Certificate, V2 CRL and V2 CRLEntry extensions.  In theory you should be able
-to handle all of these, but there are large numbers of them and some may not be
-in active use, or may be meaningless in some contexts.
-
-                    'It's called a shovel,' said the Senior Wrangler.  'I've
-                    seen the gardeners use them.  You stick the sharp end in
-                    the ground.  Then it gets a bit technical'
-                        -- Terry Pratchett, "Reaper Man"
-
-The extensions are encoded with IMPLICIT tags, it's traditional to specify this
-in some other part of the standard which is at least 20 pages away from the
-section where the extension is actually defined (but see the comments above
-about the mixture of explicit and implicit tags in ASN.1 definitions).
-
-There are a whole series of superseded and deprecated OIDs for extensions,
-often going back through several generations.  Older software and certificates
-(and buggy newer software) will still use obsolete OIDs, any new software
-should try and emit attributes tagged with the OID du jour rather than using
-deprecated OIDs.
-
-We can break extensions into two types, constraint extensions and informational
-extensions.  Constraint extensions limit the way in which the key in a
-certificate, or the certificate itself, can be used.  For example they may
-limit the key usage to digital signatures only, or limit the DNs for which a CA
-may issue certificates.  The most common constraint extensions are basic
-constraints, key usage and extended key usage, certificate policies (modified
-by policy mappings and policy constraints), and name constraints.  In contrast,
-informational extensions contain information which may or may not be useful for
-certificate users, but which doesn't limit the certificate use in any way.  For
-example an informational extension may contain additional information which
-identifies the CA which issued it.  The most common informational extensions
-are key identifiers and alternative names.
-
-The processing of these extensions is mostly specified in three different
-standards, which means that there are three often subtly incompatible ways to
-handle them.  In theory, constraint extensions should be enforced religiously,
-however the three standards which cover certificates sometimes differ both in
-how they specify the interpretation of the critical flag, and how they require
-constraint extensions to be enforced.
-
-                    We could not get it out of our minds that some subtle but
-                    profoundly alien element had been added to the aesthetic
-                    feeling behind the technique.
-                        -- H.P.Lovecraft, "At the Mountains of Madness"
-
-The general idea behind the critical flag is that it is used to protect the
-issuing CA against any assumptions made by software which doesn't implement
-support for a particular extension (none of the X.509-related standards provide
-much of a definition for what a minimally, average, and fully compliant
-implementation needs to support, so it's something of a hit and miss
-proposition for an implementation to rely on the correct handling of a
-particular extension).  One commentator has compared the various certificate
-contraints as serving as the equivalent of a Miranda warning ("You have the
-right to remain silent, you have the right to an attorney, ...") to anyone
-using the certificate.  Without the critical flag, an issuer who believes that
-the information contained in an extension is particularly important has no real
-defence if the end users software chooses to ignore the extension.
-
-The original X.509v3 specification requires that a certificate be regarded as
-invalid if an unrecognised critical extension is encountered.  As for the
-extension itself, if it's non-critical you can use whatever interpretation you
-choose (that is, the extension is specified as being of an advisory nature
-only).  This means that if you encounter constraints which require that a key
-be used only for digital signatures, you're free to use it for encryption
-anyway.  If you encounter a key which is marked as being a non-CA key, you can
-use it as a CA key anyway.  The X.509v3 interpretation of extensions is a bit
-like the recommended 130 km/h speed limit on autobahns, the theoretical limit
-is 130, you're sitting there doing 180, and you're getting overtaken by
-Porsches doing about 250.  The problem with the original X.509v3 definitions is
-that although they specify the action to take when you don't recognise an
-extension, they don't really define the action when you do recognise it.  Using
-this interpretation, it's mostly pointless including non-critical extensions
-because everyone is free to ignore them (for example the text for the keyUsage
-extension says that "it is an advisory field and does not imply that usage of
-the key is restricted to the purpose indicated", which means that the main
-message it conveys is "I want to bloat up the certificate unnecessarily").
-
-The second interpretation of extensions comes from the IETF PKIX profile.  Like
-X.509v3, this also requires that a certificate be regarded as invalid if an
-unrecognised critical extension is encountered.  However it seems to imply that
-a critical extension must be processed, and probably considers non-critical
-extensions to be advisory only.  Unfortunately the wording is ambiguous enough
-that a number of interpretations exist.  Section 4.2 says that "CAs are
-required to support <constraint extensions>", but the degree of support is left
-open, and what non-CAs are supposed to do isn't specified.  The paragraph
-which follows this says that implementations "shall recognise extensions",
-which doesn't imply any requirement to actually act on what you recognise. Even
-the term "process" is somewhat vague, since processing an extension can consist
-of popping up a warning dialog with a message which may or may not make sense
-to the user, with an optional "Don't display this warning again" checkbox.  In
-this case the application certainly recognised the extension and arguably even
-processed it, but it didn't force compliance with the intent of the extension,
-which was probably what was intended by the terms "recognise" and "process".
-
-The third interpretation comes from S/MIME, which requires that implementations
-correctly handle a subset of the constraint and informational extensions.
-However, as with PKIX, "correctly handle" isn't specified, so it's possible to
-"correctly handle" an extension as per X.509v3, as per PKIX (choose the
-interpretation you prefer), or as per S/MIME, which leaves the issue open (it
-specifies that implementations may include various bits and pieces in their
-extensions, but not how they should be enforced).  S/MIME seems to place a
-slightly different interpretation on the critical flag, limiting its use to the
-small subset of extensions which are mentioned in the S/MIME spec, so it's not
-possible to add other critical extensions to an S/MIME certificate.
-
-                    "But it izz written!" bellowed Beelzebub.
-                    "But it might be written differently somewhere else" said
-                        Crowley.  "Where you can't read it".
-                    "In bigger letters" said Aziraphale.
-                    "Underlined" Crowley added.
-                    "Twice" suggested Aziraphale.
-                        -- Neil Gaiman and Terry Pratchett, "Good Omens"
-
-Finally, the waters are further muddied by CA policies, which can add their own
-spin to the above interpretations.  For example the Verisign CPS, section
-2.4.3, says that "all persons shall process the extension [...] or else ignore
-the extension", which would seem to cover all the bases.  Other policies are
-somewhat more specific, for example Netscapes certificate extension
-specification says that the keyUsage extension can be ignored if it's not
-marked critical, but Netscape Navigator does appear to enforce the
-basicConstraints extension in most cases.
-
-The whole issue is complicated by the fact that implementations from a large
-vendor will reject a certificate which contains critical constraint extensions,
-so that even if you interpret the critical flag to mean "this extension must be
-enforced" (rather than just "reject this certificate if you don't recognise the
-extension"), you can't use it because it will render the certificate unusable.
-These implementations provide yet another interpretation of the critical flag,
-"reject this certificate if you encounter a critical extension".  The same
-vendor also has software which ignores the critical flag entirely, making the
-software essentially useless to relying parties who can't rely on it to perform
-as required (the exact behaviour depends on the software and version, so one
-version might reject a certificate with a critical extension while another
-would ignore a critical extension).
-
-                    Zaphod stared at him as if expecting a cuckoo to leap out
-                    of his forehead on a small spring.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-Because of this confusion, it's probably impossible to include a set of
-constraint extensions in a certificate which will be handled properly by
-different implementations.  Because of problems like this, the digital
-signature laws of some countries are requiring certification of the software
-being used as part of compliance with the law, so that you can't just claim
-that your software "supports X.509v3 certificates" (everyone claims this
-whether they actually do or not), you actually have to prove that it supports
-what's required by the particular countries' laws.  If you're in a country
-which has digital signature legislation, make sure the software you're using
-has been certified to conform to the legal requirements.
-
-The best interpretation of constraint extensions is that if a certificate is
-marked as an X.509v3 certificate, constraints should always be enforced.  This
-includes enforcing implied settings if the extension is missing, so that a
-certificate being used in a CA role which has no basicConstraints extension
-present should be regarded as being invalid (note however the problem with
-PKIX-compliant certificates described later on).  However even if one of the
-standards is reworded to precisely define extension handling, there are still
-plenty of other standards and interpretations which can be used.  The only
-solution to this would be to include a critical policy extension which requires
-that all constraint extensions up and down the cert chain be enforced.  Going
-back to the autobahn analogy, this mirrors the situation at the Austrian
-border, where everyone slows down to the strictly enforced speed limit as soon
-as they cross the border.
-
-Currently the only way to include a constraint enforcement extension is to make
-it a critical policy extension.  This is somewhat unfortunate since including
-some other random policy may make the extension unrecognisable, causing it, and
-the entire certificate, to be rejected (as usual, what constitutes an
-unrecognisable extension is open to debate: if you can process all the fields
-in an extension but don't recognise the contents of one of the fields, it's up
-to you whether you count this as being unrecognisable or not).
-
-A better alternative would be to define a new extension, enforceConstraints:
-
-enforceConstraints EXTENSION ::= {
-    SYNTAX EnforceConstraintsSyntax
-    IDENTIFIED BY id-ce-enforceConstraints
-    }
-
-EnforceConstraintsSyntax ::= BOOLEAN DEFAULT FALSE
-
-This makes the default setting compatible with the current "do whatever you
-feel like" enforcement of extensions.  Enforcing constraints is defined as
-enforcing all constraints contained in constraint extensions, incuding implied
-settings if the extension is missing, as part of the certificate chain
-validation process (which means that they should be enforced up and down the
-cert chain).  Recognising/supporting/handling/<whatever other wording is used
-in standards> an extension is defined as processing and acting on all
-components of all fields of an extension in a manner which is compliant with
-the semantic intent of the extension.
-
-                    'Where was I?' said Zaphod Beeblebrox the Fourth.
-                    'Pontificating' said Zaphod Beeblebrox.
-                    'Oh yes'.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-Just to mention a further complication with critical extensions, there are
-instances in which it's possible to create certificates which are always
-regarded as being invalid due to conflicts with extensions.  For example a
-generation n-1 critical extension might be replaced by a generation n critical
-extension, resulting in a mixture of certs with generation n-1 extensions,
-generation n-1 and generation n extensions (for compatibility) and (eventually)
-generation n extensions only.  However until every piece of software is
-upgraded, generation n-1 software will be forced to reject all certs with
-generation n extensions, even the (supposedly) backwards-compatibile certs with
-both generations of extension in them.
-
-                    'Mr.Beeblebrox, sir', said the insect in awed wonder,
-                    'you're so weird you should be in movies'.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-Key Usage, Extended Key Usage, and Netscape cert-type
-
-X.509 and PKIX use keyUsage and extKeyUsage to select the key to use from a
-selection of keys unless the extension is marked critical, in which case it's
-treated as a usage restriction.  Microsoft claims to support key usage
-enforcement, although experimentation with implementations has shown that it's
-mostly ignored (see the entry on Microsoft bugs further on).  In addition if an
-extKeyUsage extension is present, all certificates in the chain up to the CA
-root must also support the same extKeyUsage (so that, for example, a general-
-purpose CA can't sign a server gated crypto certificate - the reasoning behind
-this is obvious).  As it turns out though, extKeyUsage seems to be mostly
-ignored just like keyUsage.  
-
-Netscape uses keyUsage as a key selection mechanism, and uses the Netscape
-cert-type extension in a complex manner described in the Netscape certificate
-extension specification.  Since the cert-type extension includes the equivalent
-of the basicConstraints CA flag, it's possible to specify some types of CA with
-the cert-type extension.  If you do this, you should be careful to synchronise
-the basicConstraints CA flag with the setting of the cert-type extension
-because some implementations (you can probably guess which one) will allow a
-Netscape CA-like usage to override a non-CA keyUsage value, treating the
-certificate as if it were a CA certificate. In addition Netscape also enforces
-the same extKeyUsage chaining as Microsoft. 
-
-Unfortunately the extKeyUsage chaining interpretation is wrong according to
-PKIX, since the settings apply to the key in the certificate (ie the CA's key)
-rather than the keys in the certificates it issues.  In other words an
-extKeyUsage of emailProtection would indicate that the CA's certificate is
-intended for S/MIME encryption, not that the CA can issue S/MIME certificates.
-Both of the major implementators of certificate-handling software use the
-chaining interpretation, but there also exist implementations which use the
-PKIX interpretation, so the two main camps will fail to verify the other side's
-cert chains unless they're in the (smaller) third camp which just ignores
-extKeyUsage.
-
-For keyUsage there is much disagreement over the use of the digitalSignature
-and nonRepuduation bits since there was no clear definition in X.509 of when
-the nonrepudiation flag should be used alongside or in place of the digital
-signature flag.  One school of thought holds that digitalSignature should be
-used for ephemeral authentication (something which occurs automatically and
-frequently) and nonRepuduation for legally binding long-term signatures
-(something which is performed consciously and less frequently).  Another school
-of thought holds that nonRepuduation should act as an additional function for
-the digitalSignature mechanism, with digitalSignature being a mechanism bit and
-nonRepuduation being a service bit.  The different profiles are split roughly
-50:50 on this, with some complicating things by specifying that both bits
-should be set but the certificate not be used for one or the other purpose.
-Probably the best usage is to use digitalSignature for "digital signature for
-authentication purposes" and nonRepudiation for "digital signature for
-nonrepudiation purposes".
-
-                    "I think" said the Metatron, "that I shall need to seek
-                        further instructions".
-                    "I alzzo" said Beelzebub.
-                        -- Neil Gaiman and Terry Pratchett, "Good Omens"
-
-In terms of profiles, MISSI and FPKI follow the above recommendation, PKIX uses
-nonRepudiation strictly for nonrepudiation and digitalSignature for everything
-else, ISO uses digitalSignature for entity authentication and nonRepudiation
-strictly for nonrepudiation (leaving digital signatures for data authentication
-without nonrepudiation hanging), and others use something in between.  When
-this issue was debated on PKI lists in mid-1998, over 100 messages were
-exchanged without anyone really being able to uncontestably define what
-digitalSignature and nonRepudiation really signified.  The issue is further
-confused by the fact that noone can agree on what the term "nonRepudiation"
-actually means, exemplified by a ~200-message debate in mid-1999 which couldn't
-reach any useful conclusion.
-
-                    He had attached the correct colour-coded wires to the
-                    correct pins; he'd checked that it was the right amperage
-                    fuse; he'd screwed it all back together.  So far, no
-                    problems.  He plugged it into the socket.  Then he switched
-                    the socket on.  Every light in the house went out.
-                        -- Neil Gaiman and Terry Pratchett, "Good Omens"
-
-Although everyone has their own interpretation, a good practical definition is
-"Nonrepudiation is anything which fails to go away when you stop believing in
-it".  Put another way, if you can convince a user that it isn't worth trying to
-repudiate a signature then you have nonrepudiation.  This can take the form of
-having them sign a legal agreement saying they won't try to repudiate any of
-their signatures, giving them a smart card and convincing them that it's so
-secure that any attempt to repudiate a signature generated with it would be
-futile, threatening to kill their kids, or any other method which has the
-desired effect.  One advantage (for vendors) is that you can advertise just
-about anything as providing nonrepudiation, since there's sure to be some
-definition which matches whatever it is you're doing (there are
-"nonrepudiation" schemes in use today which employ a MAC using a secret shared
-between the signer and the verifier, which must be relying on a particularly
-creative definition of nonrepudiation).
-
-                    Bei ihnen auf dem Server muesste irgendwie ein Key
-                    rumliegen, den ich mit Netscape vermutlich erzeugt hab.
-                    Wenn da mein Name drin steht, dann wird er das schon sein.
-                    Koennten sie mir den zertifizieren?
-                        -- endergone Zwiebeltuete
-
-                    One might as well add a "crimeFree" (CF) bit with usage
-                    specified as 'The crimeFree bit is asserted when subject
-                    public key is used to verify digital signatures for
-                    transactions that are not a perpetration of fraud or other
-                    illegal activities'
-                        -- Tony Bartoletti on ietf-pkix
-
-                    I did have the idea that we mandate that CAs MUST set this
-                    bit randomly whenever a keyUsage extension is present, just
-                    to stop people who argue that its absence has a meaning.
-                        -- Stephen Farrell on ietf-pkix
-
-
-Basic Constraints
-
-This is used to specify whether a certificate is a CA certificate or not.  You
-should always mark this critical, because otherwise some implementations will
-ignore it and allow a non-CA certificate to act as a CA.
-
-Alternative Names
-
-The subject and issuer alternative names are used to specify all the things
-which aren't suitable for a DN, which for most purposes means practically
-everything of any use on the Internet (X.509v3 defines the alternative names
-(or, more specifically, the GeneralName type) for use in specifying identifying
-information which isn't suited for, or part of, a DN).  This includes email
-addresses, URL's for web pages, server addresses, and other odds and ends like
-X.400 and EDI addresses.  There's also a facility to include your postal
-address, physical address, phone, fax and pager numbers, and of course the
-essential MPEG of your cat.
-
-The alternative names can be used for certificate identification in place of
-the DNs, however the exact usage is somewhat unclear.  In particular if an
-altName is used for certificate chaining purposes, there's a roughly 50/50
-split of opinion as to whether all the items in the altName must match or any
-one of the items must match.  For example if an altName contains three URL's in
-the issuer and one in the client (which matches one of the issuer URL's), noone
-really knows whether this counts as a valid altName match or not.  Eventually
-someone will make a decision one way or the other, probably the S/MIME
-standards group who are rather reliant on altNames for some things (the S/MIME
-group have requested that the PKIX group make DNs mandatory in order to allow
-proper certificate chaining, and the S/MIME specs themselves require DNs for
-CAs).  Until this is sorted out, it's not a good idea to rely on altNames for
-chaining.
-
-This confusion is caused by the fact that an altName is serving two conflicting
-purposes.  The first of these is to provide extra information on the
-certificate owner which can't be specified in the DN, including things like
-their phone number, email address, and physical address.  The second is to
-provide an alternative to the ITU-managed (or, strictly speaking, non-managed)
-DN space.  For example a DNS name or IP address, which falls outside the range
-of ITU (non-)management, is controlled by the IETF, which has jurisdiction over
-the name space of the Internet-related altName components.  However since an
-altName can only specify a collection of names with a single critical attribute
-to cover all of them, there's no way to differentiate between something which
-really is critical (for example an rfc822Name being used in place of DN) and
-something which is merely present to provide extra details on the certificate
-owner (an rfc822Name being provided as a contact address).  One IETF draft
-overloaded this even further by forcing authorityInfoAccess semantics onto some
-of the altName components.
-
-This ambiguity is complicated by the presence of other attributes like path
-processing constraints.  For example does an included or excluded subtree
-constraint containing a DN cover the subjectName DN, the altName directoryName,
-or both?.  More seriously, since a subjectName and altName directoryName have
-the same form, it's possible to specify an identical DN in two different ways
-across an issuer and subject cert, leading to the same problem described below
-in the name constraints section in which it's possible to evade constraint
-checks by using alternative encodings for the same item.
-
-The solution to this problem would be to split the altName into two new
-extensions, a true altName which provides a single alternative to the
-subjectName (for example a single dNSName or rfc822Name) and which is used only
-when the subject DN is empty, and a collection of other information about the
-subject which follows the current altName syntax but which is used strictly for
-informational purposes.  The true altName provides a single alternative for the
-subjectName, and the informational altName provides any extra identification
-information which the subject may want to include with their certificate.
-
-A different (and much uglier) solution is to try and stuff everything
-imaginable into a DN.  The problem with this approach is that it completely
-destroys any hope of interoperability with directories, especially X.500
-directories which rely on search arguments being predefined as a type of
-filter.  Unless you have this predefined filter, you can't easily search the
-directory for a match, so it's necessary to have some limits placed on the
-types of names (or schemas in X.500-speak) which are acceptable.
-Unfortunately the "stuff everything into a DN" approach violates this
-principle, making the result un-searchable within a directory, which voids the
-reason for having the DN in the first place.
-
-Certificate Policies and Policy Mappings and Constraints
-
-The general idea behind the certificate policies extension is simple enough, it
-provides a means for a CA to identify which policy a certificate was issued
-under.  This means that when you check a certificate, you can ensure that each
-certificate in the chain was issued under a policy you feel comfortable with
-(certain security precautions taken, vetting of employees, physical security of
-the premises, no loud ties, that sort of thing).  The certificatePolicies
-extension (in its minimal form) provides a means of identifying the policy a
-certificate was issued under, and the policyMappings extension provides a means
-of mapping one policy to another (that is, for a CA to indicate that policy A,
-under which it is issuing a certificate, is equivalent to policy B, which is
-required by the certificate user).
-
-Unfortunately on top of this there are qualifiers for the certificatePolicies
-and the policyConstraints extension to muddy the waters.  As a result, a
-certificate policy often consists of a sequence of things identified by unknown
-object identifiers, each with another sequence of things identified by
-partially known, partially unknown object identifiers, with optional extra
-attachments containing references to other things which software is expected to
-know about by magic or possibly some form of quantum tunnelling.
-
-                    Marx Brothers fans will possibly recall the scene in "A Day
-                    at the Races" in which Groucho, intending to put his money
-                    on Sun-up, is induced instead to buy a coded tip from Chico
-                    and is able to establish the identity of the horse only, at
-                    some cost in terms of time and money, by successive
-                    purchases from Chico of the code book, the master code
-                    book, the breeders' guide and various other works of
-                    reference, by the end of which the race is over, Sun-up
-                    having won.
-                        -- Unknown, forwarded by Ed Gerck to cert-talk
-
-This makes it rather difficult to make validity decisions for a certificate
-which have anything more complex than a basic policyIdentifier present.
-
-Because of this, you should only use a single policyIdentifier in a
-certificate, and forgo the use of policy qualifiers and other odds and ends.
-Currently noone but Verisign appears to use these, the presence of these
-qualifiers in the PKIX profile may be related to the presence of Verisign in
-the PKIX profiling process.
-
-Name Constraints
-
-The name constraints are used to constrain the certificates' DN to lie inside
-or outside a particular subtree, with the excludedSubtrees field taking
-precedence over the permittedSubtrees field.  The principal use for this
-extension is to allow balkanization of the certificate namespace, so that a CA
-can restrict the ability of any CAs it certifies to issue certificates outside
-a very restricted domain.
-
-Unfortunately if the X.500 string encoding rules are followed, it's always
-possible to avoid the excludedSubtrees by choosing unusual (but perfectly
-valid) string encodings which don't appear to match the excludedSubtrees (see
-the section on string encodings for more details on this problem).  Although
-PKIX constrains the string encodings to allow the nameConstraints to function,
-it's a good idea to rely on permittedSubtrees rather than excludedSubtrees for
-constraint enforcement (actually since virtually nothing supports this
-extension, it's probably not a good idea to rely too much on either type of
-constraint, but when it is supported, use permitted rather than excluded
-subtrees).
-
-Subject and Authority Key Identifiers
-
-These are used to provide additional identification information for a
-certificate.  Unfortunately it's specified in a somewhat complex manner which
-requires additional ASN.1 constraints or text to explain it, you should treat
-it as if it were specified with the almost-ASN.1 of:
-
-AuthorityKeyIdentifier ::= CHOICE {
-    keyIdentifier [ 0 ] OCTET STRING,
-    authorityCert [ 1 ] GeneralNames, authoritySerialNumber [ 2 ] INTEGER
-    }
-
-X.509v3 allows you to use both types of identifier, but other standards and
-profiles either recommend against this or explicitly disallow it, allowing only
-the keyIdentifier.  Various profiles have at various times required the use of
-the SHA-1 hash of the public key (whatever that constitutes), the SHA-1 hash of
-the subjectPublicKeyInfo data (for some reason this has to be done *without*
-the tag and length at the start), the SHA-1 hash of the subjectPublicKey (again
-without the tag, length, and unused bits portion of the BIT STRING, which
-leaves just the raw public key data but omits the algorithm identifier and
-parameters so that two keys for different algorithms with different parameters
-which happen to share the same public key field end up with the same hash), a
-64-bit hash of the subjectPublicKeyInfo (presumably with the tag and length), a
-60-bit hash of the subjectPublicKey (again with tag and length) with the first
-four bits set to various values to indicate MISSI key types, and some sort of
-unique value such as a monotonically increasing sequence.  Several newer
-profiles have pretty much given up on this and simply specify "a unique value".
-RFC 2459 also allows "a monotomically increasing sequence of integers", which
-is a rather bad move since the overall supply of unique small integers is
-somewhat limited and this scheme will break as soon as a second CA decides to
-issue a cert with a "unique" subjectKeyIdentifier of the same value.
-
-To balance the problems caused by this mess of conflicting and incompatible
-standards, it appears that most implementations either ignore the keyIdentifier
-entirely or don't bother decoding it, because in 1997 and 1998 a widely-used CA
-accidentally issued certificates with an incorrect encoding of the
-keyIdentifier (it wasn't even valid ASN.1 data, let alone X.509-conformant
-ASN.1) without anyone noticing.  Although a few standards require that a
-keyIdentifier be used, its absence doesn't seem to cause any problems for
-current implementations.
-
-Recommendation: Don't even try and decode the authorityKeyIdentifier field,
-    just treat everything inside the OCTET STRING hole as an opaque blob.
-    Given that most current implementations seem to ignore this extension,
-    don't create certificate chains which require it to be processed in order
-    for the chaining to work.
-
-The claimed reason for using the keyIdentifier rather than the
-issuerAndSerialNumber is because it allows a certificate chain to be re-rooted
-when an intermediate CA changes in some manner (for example when its
-responsibilities are handed off from one department in an organisation to
-another).  If the certificate is identified through the keyIdentifier, no
-nameConstraints are present, the certificate policies are identical or mapped
-from one to the other, the altNames chain correctly, and no policyConstraints
-are present, then this type of re-rooting is possible (in case anyone missed
-the sarcasm in there, the gist is that it's highly unlikely to work).
-
-Other Extensions
-
-There are a wide variety of other extensions defined in various profiles.
-These are in effect proprietary extensions because unless you can track down
-something which recognises them (typically a single-vendor or small-group-of-
-vendors product), you won't be able to do much with them - most software will
-either ignore them completely or reject the certificate if the extension is
-marked critical and the software behaves as required.  Unless you can mandate
-the use of a given piece of certificate-processing software which you've
-carefully tested to ensure it processes the extension correctly, and you can
-block the use of all other software, you shouldn't rely on these extensions.
-Obviously if you're in a closed, carefully controlled environment (for example
-a closed shop EDI environment which requires the use of certain extensions such
-as reliance limits) the use of specialised extensions isn't a problem, but
-otherwise you're on your own.
-
-In addition to the use of other people's extensions, you may feel the need to
-define your own.  In short if you're someone other than Microsoft (who can
-enforce the acceptance of whatever extensions they feel like), don't do it.
-Not only is it going to be practically impossible to find anything to support
-them (unless you write it yourself), but it's also very easy to stuff all sorts
-of irrelevant, unnecessary, and often downright dangerous information into
-certificates without thinking about it.  The canonical example of something
-which has no place in a certificate is Microsoft's cAKeyCertIndexPair
-extension, which records the state of the CA software running on a Windows 2000
-machine at the time the certificate was generated (in other words it offloads
-the CA backup task from the machine's administrator to anyone using one of the
-certificates).
-                    Only wimps use tape backup: _real_ men just upload their
-                    important stuff on ftp, and let the rest of the world
-                    mirror it.
-                        -- Linus Torvalds
-
-The canonical example of a dangerous certificate extension is one which
-indicates whether the owner is of legal age for some purpose (buying
-alcohol/driving/entry into nightclubs/whatever).  Using something like a
-drivers license for this creates a booming demand for forged licenses which, by
-their very nature, are difficult to create and tied to an individual through a
-photo ID.  Doing the same thing with a certificate creates a demand for those
-over the age limit to make their keys (trivially copied en masse and not tied
-to an individual) available to those under the age limit, or for those under
-the age limit to avail themselves of the keys in a surreptitious manner.  The
-fact that the borrowed key which is being used to buy beer or rent a porn movie
-can also be used to sign a legally binding contract or empty a bank account
-probably won't be of concern until it's too late.  This is a good example of
-the law of unintended consequences in action.
-
-                    If scientists can be counted on for anything, it's for
-                    creating unintended consequences.
-                        -- Michael Dougan
-
-A related concern about age indicators in certificates, which was one of the
-many nails in X.500's coffin, is the fact that giving a third party the
-information needed to query a certificate directory in order to locate, for
-example, all teenage girls in your localityName, probably wouldn't be seen as a
-feature by most certificate holders.  Similar objections were made to the use
-of titles in DNs, for example a search on a title of "Ms" would have allowed
-someone to locate all single women in their localityName, and full-blown X.500
-would have provided their home addresses and probably phone numbers to boot.
-Until early 1999 this type of extension only existed as a hypothetical case,
-but it's now present as a mandatory requirement in at least one digital
-signature law, which also has as a requirement that all CAs publish their
-certificates in some form of openly-accessible directory.
-
-                    I saw, and I heard an eagle, flying in mid heaven, saying
-                    with a loud voice, "Woe! Woe! Woe for those who dwell on
-                    the earth"
-                        -- Revelations 8:15
-
-
-Character Sets
---------------
-
-Character strings are used in various places (most notably in DNs), and are
-encumbered by the fact that ASN.1 defines a whole series of odd subsets of
-ASCII/ISO 646 as character string types, but only provides a few peculiar and
-strange oddball character encodings for anything outside this limited character
-range.
-                    The protruding upper halves of the letters now appear to
-                    read, in the local language, "Go stick your head in a pig",
-                    and are no longer illuminated, except at times of special
-                    celebration.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-To use the example of DNs, the allowed string types are:
-
-DirectoryString ::= CHOICE {
-    teletexString           TeletexString (SIZE (1..maxSize)),
-    printableString         PrintableString (SIZE (1..maxSize)),
-    bmpString               BMPString (SIZE (1..maxSize)),
-    universalString         UniversalString (SIZE (1..maxSize))
-    }
-
-The easiest one to use, if you can get away with it, is IA5String, which is
-basically 7-bit ASCII (including all the control codes), but with the dollar
-sign potentially replaced with a "currency symbol".  A more sensible
-alternative is VisibleString (aka ISO646String), which is IA5String without the
-control codes (this has the advantage that you can't use it to construct macro
-viruses using ANSI control sequences).  In the DirectoryString case, you have
-to make do with PrintableString, which is one of the odd ASCII/ISO 646 subsets
-(for example you can't encode an '@', which makes it rather challenging to
-encode email addresses).
-
-Beyond that there is the T.61/TeletexString, which can select different
-character sets using escape codes (this is one of the aforementioned "peculiar
-and strange oddball encodings").  The character sets are Japanese Kanji (JIS C
-6226-1983, set No. 87), Chinese (GB 2312-80, set No. 58), and Greek, using
-shifting codes specified in T.61 or the international version, ISO 6937
-(strictly speaking T61String isn't defined in T.61 but in X.680, which defines
-it by profiling ISO 2022 character set switching).  Some of the characters have
-a variable-length encoding (so it takes 2 bytes to encode a character, with the
-interpretation being done in a context-specific manner).  The problem isn't
-helped by the fact that the T.61 specification has changed over the years as
-new character sets were added, and since the T.61 spec has now been withdrawn
-by the ITU there's no real way to find out exactly what is supposed to be in
-there (but see the previous comment on T.61 vs T61String - a T61String isn't
-really a T.61 string).  Even using straight 8859-1 in a T61String doesn't
-always work, for example the 8859-1 character code for the Norwegian OE
-(slashed O) is defined using a T.61 escape sequence which, if present in a
-certificate, may cause a directory to reject the certificate.
-
-                    And then there came the crowning horror of all - the
-                    unbelievable, unthinkable, almost unmentionable thing.
-                        -- H.P.Lovecraft, "The Statement of Randolph Carter"
-
-For those who haven't reached for a sick bag yet, one definition of T61String
-is given in ISO 1990 X.208 which indicates that it contains registered
-character sets 87, 102 (a minimalist version of ASCII), 103 (a character set
-with the infamous "floating diacritics" which means things like accented
-characters are encoded as "<add an accent to the next character> + <character>"
-rather than with a single character code), 106 and 107 (two useless sets
-containing control characters which noone would put in a name), SPACE + DELETE.
-The newer ITU-T 1997 and ISO 1998 X.680 adds the character sets 6, 126, 144,
-150, 153, 156, 164, 165, and 168 (the reason for some of these additions is
-because once a character set is registered it can never change except by
-"clarifying" it, which produces a completely new character set with a new
-number (as with sex, once you make a mistake you end up having to support it
-for the rest of your life)).  In fact there are even more definitions of
-T61String than that: The original CCITT 1984 ASN.1 spec defined T61String by
-reference to a real T.61 recommendation (from which finding the actual
-permitted characters is challenging, to put it mildly), then the ISO 1986 spec
-defined them by reference to the international register, then the CCITT 1988
-spec changed them again (the ISO 1990 spec described above may be identical to
-the CCITT 1988 one), and finally they were changed again for ISO/ITU-T 1994
-(this 1994 spec may again be the same as ITU-T 1997 and ISO 1998).  I'm not
-making this up!
-                    The disciples came to him privately, saying, "Tell us, what
-                    is the sign of your coming, and of the end of the world?"
-                    [...] "You will hear of wars and rumors of wars; there will
-                    be famines, plagues, and earthquakes in various places; the
-                    sun will be darkened, the moon will not give her light, the
-                    stars will fall from the sky, the powers of the heavens
-                    will be shaken; certificates will be issued with floating
-                    diacritics in their DNs; and then the end will come".
-                        -- Matthew 24 (mostly)
-
-The encoding for this mess is specified in X.209 which indicates that the
-default character sets at the start of a string are 102, 106 and 107, although
-in theory you can't really make this assumption without the appropriate escape
-sequences to invoke the correct character set.  The general consensus amoung
-the X.500/ISODE directory crowd is that you assume that set 103 is used by
-default, although Microsoft and Netscape had other ideas for their LDAPv2
-products.  In certificates, the common practice seems to be to use straight
-latin-1, which is set numbers 6 and 100, the latter not even being an allowed
-T61String set.
-                    There are those who will say Danforth and I were utterly
-                    mad not to flee for our lives after that; since our
-                    conclusions were now completely fixed, and of a nature I
-                    need not even mention to those who have read my account so
-                    far.
-                        -- H.P.Lovecraft, "At the Mountains of Madness"
-
-Next are the BMPString and UniversalString, with BMPString having 16-bit
-characters (UCS-2) and UniversalString having 32-bit characters (UCS-4), both
-encoded in big-endian format.  BMPString is a subset of UniversalString, being
-the 16-bit character range in the 0/0 plane (ie the UniversalString characters
-in which the 16 high bits are 0), corresponding to straight ISO 10646/Unicode
-characters.  The ASN.1 standard says that UniversalString should only be used
-if the encoding possibilities are constrained, it's better to avoid it entirely
-and only use BMPString/ISO 10646/Unicode.
-
-However, there is a problem with this: at the moment few implementors know how
-to handle or encode BMPStrings, and people have made all sorts of guesses as to
-how Unicode strings should be encoded: with or without Unicode byte order marks
-(BOMs), possibly with a fixed endianness, and with or without the terminating
-null character.
-                    I might as well be frank in stating what we saw; though at
-                    the time we felt that it was not to be admitted even to
-                    each other.  The words reaching the reader can never even
-                    suggest the awfulness of the sight itself.
-                        -- H.P.Lovecraft, "At the Mountains of Madness"
-
-The correct format for BMPStrings is: big-endian 16-bit characters, no Unicode
-byte order marks (BOMs), and no terminating null character (ISO 8825-1 section
-8.20).
-
-An exception to this is PFX/PKCS #12, where the passwords are converted to a
-Unicode BMPString before being hashed.  However both Netscape and Microsoft's
-early implementations treated the terminating null characters as being part of
-the string, so the PKCS #12 standard was retroengineered to specify that the
-null characters be included in the string.
-
-A final string type which is presently only in the PKIX profile but which
-should eventually appear elsewhere is UTF-8, which provides a means of encoding
-7, 8, 16, and 32-bit characters into a single character string.  Since ASN.1
-already provides character string types which cover everything except some of
-the really weird 32-bit characters which noone ever uses,
-
-                    It was covered in symbols that only eight other people in
-                    the world would have been able to comprehend; two of them
-                    had won Nobel prizes, and one of the other six dribbled a
-                    lot and wasn't allowed anything sharp because of what he
-                    might do with it.
-                        -- Neil Gaiman and Terry Pratchett, "Good Omens"
-
-the least general encoding rule means that UTF-8 strings will practically never
-be used.  The original reason they were present in the PKIX profile is because
-of an IETF rule which required that all new IETF standards support UTF-8, but a
-much more compelling argument which recently emerged is that, since most of the
-other ASN.1 character sets are completely unusable, UTF-8 would finally breathe
-a bit of sanity into the ASN.1 character set nightmare.  Unfortunately, because
-it's quite a task to find ASN.1 compilers (let alone certificate handling
-software) which supports UTF-8, you should avoid this string type for now. PKIX
-realised the problems which would arise and specified a cutover date of 1
-January 2004 for UTF-8 use.  Some drafts have appeared which recommend the use
-of RFC 2482 language tags, but these should be avoided since they have little
-value (they're only needed for machine processing, if they appear in a text
-string intended to be read by a human they'll either understand it or they
-won't and a language tag won't help).  In addition UTF-8 language tags are huge
-(about 30 bytes) due to the fact that they're located out in plane 14 in the
-character set (although I don't have the appropriate reference to hand, plane
-14 is probably either Gehenna or Acheron), so the tag would be much larger than
-the string being tagged in most cases.
-
-One final problem with UTF-8 is that it shares some of the T.61 string problems
-in which it's possible for a malicious encoder to evade checks on strings
-either by using different code points which produce identical-looking
-characters when displayed or by using suboptimal encodings (in ASN.1 terms,
-non-distinguished encodings) of a code point. They are aided in this by the
-standard, which says (page 47, section 3.8 of the Unicode 3.0 standard) that
-"when converting from UTF-8 to a Unicode scalar value, implementations do not
-need to check that the shortest encoding is being used. This simplifies the
-conversion algorithm". What this means is that it's possible to encode a
-particular character in a dozen different ways in order to evade a check which
-uses a straight byte-by-byte comparison as specified in RFC 2459.  Although
-some libraries such as glibc 2.2 use "safe" UTF-8 decoders which will reject
-non-distinguished encodings, it's not a good idea to assume that everyone does
-this.
-
-Because of these problems, the SET designers produced their own alternative,
-SETString, for places were DNs weren't required for compatibility purposes.
-The design goals for the SETString were to both provide the best coverage of
-ASCII and national-language character sets, and also to minimise implementation
-pain.  The SETString type is defined as:
-
-SETString ::= CHOICE {
-    visibleString           VisibleString (SIZE (1..maxSIZE)),
-    bmpString               BMPString (SIZE (1..maxSIZE))
-    }
-
-This provides complete ASCII/ISO 646 support using single byte characters, and
-national language support through Unicode, which is in common use by industry.
-
-In addition the SET designers decided to create their own version of the
-DirectoryString which is a proper subset of the X.500 version.  The initial
-version was just an X.500 DirectoryString with a number of constraints applied
-to it, but just before publication this was changed to:
-
-DirectoryString ::= CHOICE {
-    printableString         PrintableString (SIZE(1..maxSIZE)),
-    bmpString               BMPString (SIZE(1..maxSIZE))
-    }
-                    You must unlearn what you have learned.
-                        -- Yoda
-
-It was felt that this improved readablility and interoperability (and sanity).
-T61String was never seriously considered in the design, and UniversalString
-with its four-byte characters had no identifiable industry support and required
-too much overhead.  If you want to produce certs which work for both generic
-X.509 and SET, then using the SET version of the DirectoryString is a good
-idea.  It's trivial to convert an ISO 8859-1 T61String to a BMPString and back
-(just add/subtract a 0 byte every other byte).
-
-MISSI also subsets the string types, allowing only PrintableString and
-T61String in DNs.
-
-When dealing with these character sets you should use the "least inclusive" set
-when trying to determine which encoding to use.  This means trying to encode as
-PrintableString first, then T61String, and finally BMPString/UniversalString.
-SET requires that either PrintableStrings or BMPStrings be used, with
-TeletexStrings and UniversalStrings being forbidden.
-
-From this we can build the following set of recommendations:
-
-- Use PrintableString if possible (or VisibleString or IA5String if this is
-  allowed, because it's rather more useful than PrintableString).
-- If you use a T61String (and assuming you don't require SET compliance), avoid
-  the use of anything involving shifting and escape codes at any cost and just
-  treat it as a pure ISO 8859-1 string.  If you need anything other than
-  8859-1, use a BMPString.
-- If it won't go into one of the above, try for a BMPString.
-- Avoid UniversalStrings.
-
-Version 7 of the PKIX draft dropped the use of T61String altogether (probably
-in response to this writeup :-), but this may be a bit extreme since the
-extremely limited character range allowed by PrintableString will result in
-many simple strings blowing out to BMPStrings, which causes problems on a
-number of systems which have little Unicode support.
-
-In 2004, you can switch to UTF-8 strings and forget about this entire section
-of the guide.
-                    I saw coming out of the mouth of the dragon, and out of the
-                    mouth of the beast, and out of the mouth of the false
-                    prophet, three unclean spirits, something like frogs; for
-                    they are spirits of demons, performing signs
-                        -- Biblical explanation of the origins of character set
-                           problems, Revelations 16:13-14, recommended
-                           rendition: Diamanda Galas, The Plague Mass.
-
-
-Comparing DNs
--------------
-
-This is an issue which is so problematic that it requires a section of its own
-to cover it fully.  According to X.500, to compare a DN:
-
-- The number of RDNs must match.
-- RDNs must have the same number of AVAs.
-- Corresponding AVAs must match for equality:
-  - Leading and trailing spaces are ignored.
-  - Multiple internal spaces are treated as a single internal space.
-  - Characters (not code points, which are a particular encoding of a
-    character) are matched in a case-insensitive manner.
-
-As it turns out, this matching is virtually impossible to perform (more
-specifically, it is virtually impossible to accurately compare two DNs for
-equivalence).
-                    This, many claim, is not merely impossible but clearly
-                    insane, which is why the advertising executives of the star
-                    system of Bastablon came up with this quote: 'If you've
-                    done six impossible things this morning, why not round it
-                    off with breakfast at Milliways, the Restaurant at the End
-                    of the Universe?'.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-The reason for this is that, with the vast number of character sets, encodings,
-and alternative encodings (code points) for the same character, and the often
-very limited support for non-ASCII character sets available on many systems, it
-isn't possible to accurately and portably compare any RDNs other than those
-containing one of the basic ASCII string types.  The best you can probably do
-is to use the strategy outlined below.
-
-First, check whether the number of RDNs is equal.  If they match, break up the
-DNs into RDNs and check that the RDN types match.  If they also match, you need
-to compare the text in each RDN in turn.  This is where it gets tricky.
-
-                    He walked across to the window and suddenly stumbled
-                    because at that moment his Joo-Janta 200 Super-Chromatic
-                    Peril Sensitive sunglasses had turned utterly black.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-First, take both strings and convert them to either ASCII (ISO646String) or
-Unicode (BMPString) using the "least inclusive" rule.  This is quite a task in
-itself, because several implementations aren't too picky about what they'll put
-into a string, and will stuff T61String characters into a PrintableString, or
-(more commonly) Unicode characters into a T61String or anything into a
-BMPString.  Finding a T61String in a PrintableString or an 8-bit character set
-string in a BMPString is relatively easy, but the best guess you can take at
-detecting a Unicode string in a T61String is to check whether either the string
-length is odd or all the characters are ASCII or ASCII with the high bit set.
-If neither are true, it might be a Unicode string disguised as a T61String.
-
-Once this is done, you need to canonicalise the strings into a format in which
-a comparison can be done, either to compare strings of different types (eg
-8-bit character set or DBCS string to BMPString) or strings with the same type
-but different encodings (eg two T61Strings using alternative encodings).  To
-convert ASCII-as-Unicode to ASCII, just drop the odd-numbered bytes. Converting
-a T61String to Unicode is a bit more tricky.  Under Windows 95 and NT, you can
-use MultiByteToWideChar(), although the conversion will depend on the current
-code page in use.  On systems with widechar support, you can use mbstowcs()
-directly if the widechar size is the same as the BMPString char size (which it
-generally isn't), otherwise you need to first convert the string to a widechar
-string with mbstowcs() and then back down again to a BMPString, taking the
-machine endianness into account.  Again, the behaviour of mbstowcs() will
-depend on the current locale in use.  If the system doesn't have widechar
-support, the best you can do is a brute-force conversion to Unicode by hoping
-it's ISO 8859-1 and adding a zero byte every other byte.
-
-Now that you might have the strings in a format where they can be compared, you
-can actually try and compare them.  Again, this often ends up as pure guesswork
-if the system doesn't support the necessary character sets, or if the
-characters use weird encodings which result in identical characters being
-located at different code points.
-
-First, check the converted character sets: If one is Unicode and the other
-isn't, then the strings probably differ (depending on how well the
-canonicalisation step went).  If the types are the same, strip leading,
-trailing, and repeated internal spaces from the string, which isn't as easy as
-it sounds since there are several possible code points allocated to a space.
-
-Once you've had a go at stripping spaces, you can try to compare the strings.
-If the string is a BMPString then under Windows NT (but not Windows 95) you can
-use CompareString(), with the usual caveat that the comparison depends on the
-current locale.  On systems which support towlower() you can extract the
-characters from the string into widechars (taking machine endianness into
-account) and compare the towlower() forms, with the usual caveat about locale
-and the added problem that towlower() implementations vary from bare-bones
-(8859-1 only under Solaris, HPUX, AIX) to vague (Unicode under Win95, OSF/1).
-If there's no support for towlower(), the best you can do is use the normal
-tolower() if the characters have a high byte of zero (some systems will support
-8859-1 for tolower(), the worst which can happen is that the characters will be
-returned unchanged), and compare the code points directly if it isn't an 8-bit
-value.
-                    Zaphods skin was crawling all over his body as if it was
-                    trying to get off.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-Finally, if it's an ASCII string, you can just use a standard case-insensitive
-string comparison function.
-
-As you can see, there's almost no way to reliably compare two RDN elements. In
-particular, no matter what you do:
-
-- Some malicious users will deliberately pass DN checks with weird encodings.
-- Some normal users will accidentally fail DN checks with weird encodings.
-
-This becomes an issue when certain security checks depend on a comparison of
-DNs (for example with excluded subtrees in the Name Constraints extension)
-because it's possible to create multiple strings which are displayed
-identically to the user (especially if you know which platform and/or software
-to target) assuming they get displayed at all, but which compare as different
-strings.  If you want to be absolutely certain about DN comparisons, you might
-need to set a certificate policy of only allowing PrintableStrings in DNs,
-because they're the only ones which can be reliably compared.
-
-
-PKCS #10
---------
-
-According to the PKCS #10 spec, the attributes field is mandatory, so if it's
-empty it's encoded as a zero-length field.  The example however assumes that if
-there are no attributes, the field shouldn't be present, treating it like an
-OPTIONAL field.  A number of vendors conform to the example rather than the
-specification, but just to confuse the issue RSADSI, who produced PKCS #10,
-regard things the other way around, with the spec being right and the example
-being wrong.  The most obvious effect of this is that TIPEM (which was the only
-available toolkit for PKCS#10 for a long time) follows the spec and does it
-"wrong (sense #2)", whereas more recent independant implementations follow the
-example and do it "wrong (sense #1)".
-
-Unfortunately it's difficult to handle certificate requests correctly and be
-lenient on decoding.  Because a request could be reencoded into DER before
-checking the signature, funny things can happen to your request at the remote
-end if the two interpretations of PKCS #10 differ.  Because of this confusion,
-you should be prepared to accept either version when decoding, but at the
-moment it's not possible to provide any recommendation for encoding.  When
-encountering a particularly fascist parser which isn't aware of the PKCS #10
-duality, it may be necessary to submit two versions of the request to determine
-which one works.
-                    No, no.  Yes.  No, I tried that.  Yes, both ways.  No, I
-                    don't know.  No again.  Are there any more questions?
-                        -- Xena, "Been There, Done That"
-
-PKCS #10 also dates from the days of X.509v1 and includes references to
-obsolete and deprecated objects and data formats.  PKCS #6 extended
-certificates are a workaround for the abscence of certificate extensions in
-X.509v1 and shouldn't be used at all, and it's probably a good idea to avoid
-the use of PKCS #9 extended attributes as well (some certification request
-protocols bypass the use of PKCS #9 by wrapping extra protocol layers
-containing PKCS #9 elements around the outside of PKCS #10).  Instead, you
-should use of the CMMF draft, which defines a new attribute identified by the
-OID {pkcs-9 14}, with a value of SEQUENCE OF Extension which allows X.509v3
-attributes to be encoded into a PKCS #10 certification request.  The complete
-encoding used to encode X.509v3 extensions into a PKCS #10 certification
-request is therefore:
-
-  [0] IMPLICIT SET OF {                 -- attributes from PKCS #10
-    SEQUENCE {                          -- Attribute from X.501
-      OBJECT IDENTIFIER,                --   type, {pkcs-9 14}
-      SET OF {                          --   values
-        SEQUENCE OF {                   -- ExtensionReq from CMMF draft
-          <X.509v3 extensions>
-        }
-      }
-    }
-  }
-
-As of late 1998, virtually all CAs ignore this information and at best add a
-few predefined extensions based on the options selected on the web page which
-was used to trigger the certification process.  There are one or two
-implementations which do support it, and these provide a convenient means of
-specifying attributes for a certificate which don't involve kludges via HTML
-requests.  Microsoft started supporting something like it in mid-1999, although
-they used their own incompatible OID in place of the PKCS #9 one to ensure non-
-compatibility with any other implementation (the extensions are encoded in the
-standard format, they're just identified in a way which means nothing else can
-read them).
-
-Unfortunately since PKCS #10 doesn't mention X.509v3 at all, there's no clear
-indication of what is and isn't valid as an attribute for X.509v3, but common
-sense should indicate what you can and can't use.  For example a subjectAltName
-should be treated as a valid attribute, a basicConstraint may or may not be
-treated as valid depending on the CA's certification policy, and an
-authorityKeyIdentifier would definitely be an invalid attribute.
-
-SET provides its own version of PKCS #10 which uses a slightly different
-encoding to the above and handles the X.509v3 extensions keyUsage,
-privateKeyUsagePeriod (whose use is deprecated by PKIX for some reason),
-subjectAltName, and the SET extensions certificateType, tunneling, and
-additionalPolicy.  Correctly handling the SET extensions while at the same time
-avoiding Microsoft's broken extensions which look very similar (see the "Known
-Bugs/Peculiarities" section) provides a particularly entertaining exercise for
-implementors.
-
-
-ASN.1 Design Guidelines
------------------------
-
-This section contains some guidelines on what I consider good ASN.1 style.
-This was motivated both by the apparent lack of such guidelines in existing
-documents covering ASN.1, and by my seeing the ASN.1 definition of the X.400
-ORAddress (Originator/Recipient Address).  Although there are a number of
-documents which explain how to use ASN.1, there doesn't seem to be much around
-on ASN.1 style, or at least nothing which is easily accessible.  Because of
-this I've noted down a few guidelines on good ASN.1 style, tuned towards the
-kind of ASN.1 elements which are used in certificate-related work.  In most
-cases I'll use the X.400 ORAddress as an example of bad style (I usually use
-PFX for this since it's such a target-rich environment, but in this case I'll
-make an exception).  The whole ORAddress definition is far too long to include
-here (it requires pages and pages of definitions just to allow the encoding of
-the equivalent of an email address), but I'll include excerpts where required.
-
-                    If you can't be a good example, then you'll just have to be
-                    a horrible warning.
-                        -- Catherine Aird
-
-To start off, keep your structure as simple as possible.  Everyone always says
-this, but when working with ASN.1 it's particularly important because the
-notation gives you the freedom to design incredibly complicated structures
-which are almost impossible to work with.
-
-                    Bud, if dynamite was dangerous do you think they'd sell it
-                    to an idiot like me?
-                        -- Al Bundy, "Married with Children"
-
-Look at the whole ORAddress for an example.
-
-                    What we did see was something altogether different, and
-                    immeasurably more hideous and detestable.  It was the
-                    utter, objective embodiment of the fantastic novelists
-                    'thing that should not be'.
-                        -- H.P.Lovecraft, "At the Mountains of Madness"
-
-This includes provisions for every imaginable type of field and element which
-anyone could conceivably want to include in an address.  Now although it's easy
-enough to feed the whole thing into an ASN.1 compiler and produce an enormous
-chunk of code which encodes and decodes the whole mess, it's still necessary to
-manually generate the code to interpret the semantic intent of the content.
-This is a complex and error-prone process which isn't helped by the fact that
-the structure contains dozens of little-understood and rarely-used fields, all
-of which need to be handled correctly by a compliant implementation.  Given the
-difficulty of even agreeing on the usage of common fields in certificate
-extensions, the problems which will be raised by obscure fields buried fifteen
-levels deep in some definition aren't hard to imagine.
-
-ASN.1 *WHAM* is not *WHAM* COBOL *WHAM* *WHAM* *WHAM*.  The whole point of an
-abstract syntax notation is that it's not tied to any particular representation
-of the underlying data types.  An extreme example of reverse-engineering data
-type dependancy back into ASN.1 is X9.42's:
-
-  OCTET STRING SIZE(4)  -- (Big-endian) Integer
-
-Artificially restricting an ASN.1 element to fall within the particular
-limitations of the hardware you're using creates all sorts of problems for
-other users, and for the future when people decide that 640K isn't all the
-memory anyone will ever need.  The entire point of ASN.1 is that it not be tied
-to a particular implementation, and that users not have to worry about the
-underlying data types.  It can also create ambiguous encodings which void the
-DER guarantee of identical encodings for identical values: Although the
-ANSI/SET provision for handling currencies which may be present in amounts
-greater than 10e300 (requiring the amtExp10 field to extend the range of the
-ASN.1 INTEGER in the amount field) is laudable, it leads to nondeterministic
-encodings in which a single value can be represented in a multitude of ways,
-making it impossible to produce a guaranteed, repeatable encoding.
-
-Careful with that tagging Eugene!  In recent ASN.1 work it seems to have become
-fashionable to madly tag everything which isn't nailed down, sometimes two or
-three times recursively for good measure (see the next point).
-
-                    The entire set of PDU's are defined using an incredible
-                    amount of gratuitous and unnecessary tagging.  Were the
-                    authors being paid by the tag for this?
-                        -- Peter Gutmann on ietf-pkix
-
-For example consider the following ORAddress ExtensionAttribute:
-
-  ExtensionAttribute ::= SEQUENCE {
-    extension-attribute-type [0] INTEGER,
-    extension-attribute-value [1] ANY DEFINED BY extension-attribute-type
-    }
-
-(this uses the 1988 ASN.1 syntax, more recent versions change this somewhat).
-Both of the tags are completely unnecessary, and do nothing apart from
-complicating the encoding and decoding process.  Another example of this
-problem are extensions like authorityKeyIdentifier, cRLDistributionPoints, and
-issuingDistributionPoint which, after several levels of nesting, have every
-element in a sequence individually tagged even though, since they're all
-distinct, there's no need for any of the tags.
-
-Another type of tagging is used for the ORAddress BuiltInStandardAttributes:
-
-  BuiltInStandardAttributes ::= SEQUENCE {
-    countryName [APPLICATION 1] CHOICE { ... } OPTIONAL,
-    ...
-    }
-
-Note the strange nonstandard tagging - even if there's a need to tag this
-element (there isn't), the tag should be a context-specific tag and not an
-application-specific one (this particular definition mixes context-specific and
-application-specific tags apparently at random).  For tagging fields in
-sequences or sets, you should always use context-specific tags.
-
-Speaking of sequences and sets, if you want to specify a collection of items in
-data which will be signed or otherwise authenticated, use a SEQUENCE rather
-than a SET, since the encoding of sets causes serious problems under the DER.
-You can see the effect of this in newer PKCS #7 revisions, which substitute
-SEQUENCE almost everywhere where the older versions used a SET because it's far
-easier to work with the former even though what's actually being represented is
-really a SET and not a SEQUENCE.
-
-If you have optional elements in a sequence, it's always possible to eliminate
-the tag on the first element (provided it's not itself tagged), since it can be
-uniquely decoded without the tag.  For example consider privateKeyUsagePeriod:
-
-  PrivateKeyUsagePeriod :: = SEQUENCE {
-    notBefore [ 0 ] GeneralizedTime OPTIONAL,
-    notAfter [ 1 ] GeneralizedTime OPTIONAL
-    }
-
-The first tag is unnecessary since it isn't required for the decoding, so it
-could be rewritten:
-
-  PrivateKeyUsagePeriod :: = SEQUENCE {
-    notBefore GeneralizedTime OPTIONAL,
-    notAfter [ 0 ] GeneralizedTime OPTIONAL
-    }
-
-saving an unneeded tag.
-
-Because of the ability to specify arbitrarily nested and redefined elements in
-ASN.1, some of the redundancy built into a definition may not be immediately
-obvious.  For example consider the use of a DN in an IssuingDistributionPoint
-extension, which begins:
-
-  IssuingDistributionPoint ::= SEQUENCE {
-    distributionPoint [0] DistributionPointName OPTIONAL,
-    ...
-    }
-
-  DistributionPointName ::= CHOICE {
-    fullName [0] GeneralNames,
-    ...
-    }
-
-  GeneralNames ::= SEQUENCE OF GeneralName
-
-  GeneralName ::= CHOICE {
-    ...
-    directoryName [4] Name,
-    ...
-    }
-
-  Name ::= CHOICE {
-    rdnSequence RDNSequence
-    }
-
-  RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-  RelativeDistinguishedName ::= SET OF AttributeTypeAndValue
-
-                    [It] was of a baroque monstrosity not often seen outside
-                    the Maximegalon Museum of Diseased Imaginings.
-                        -- Douglas Adams, "The Restaurant at the End of the
-                           Universe"
-
-Once we reach AttributeTypeAndValue we finally get to something which contains
-actual data - everything before that point is just wrapping.
-
-Now consider a typical use of this extension, in which you encode the URL at
-which CA information is to be found.  This is encoded as:
-
-SEQUENCE { [0] { [0] { SEQUENCE { [6] "http://.." } } } }
-
-All this just to specify a URL!
-
-                    It looks like they were trying to stress-test their ASN.1
-                    compilers.
-                        -- Roger Schlafly on stds-p1363
-
-                    It smelled like slow death in there, malaria, nightmares.
-                    This was the end of the river alright.
-                        -- Captain Willard, "Apocalypse Now"
-
-Unfortunately because of the extremely broad definition used (a SEQUENCE OF
-GeneralName can encode arbitrary quantities of almost anything imaginable, for
-example you could include the contents of an entire X.500 directory in this
-extension), producing the code to correctly process every type of field and
-item which could occur is virtually impossible, and indeed the semantics for
-many types of usage are undefined (consider how you would use a physical
-delivery address or a fax number to access a web server).
-
-Because of the potential for creating over-general definitions, once you've
-written down the definition in its full form, also write it out in the
-compressed form I've used above, and alongside this write down the encoded form
-of some typical data.  This will very quickly show up areas in which there's
-unnecessary tagging, nesting, and generality, as the above example does.
-
-An extreme example of the misuse of nesting, tagging, and generality is the
-ORName, which when fully un-nested is:
-
-  ORName ::= [APPLICATION 0] SEQUENCE { [0] { SEQUENCE OF SET OF
-             AttributeTypeAndValue OPTIONAL } }
-
-(it's not even possible to write all of this on a single line).  This uses
-unnecessary tagging, nonstandard tagging, and unnecessary nesting all in a
-single definition.
-                    It will founder upon the rocks of iniquity and sink
-                    headfirst to vanish without trace into the seas of
-                    oblivion.
-                        -- Neil Gaiman and Terry Pratchett, "Good Omens"
-
-The actual effect of the above is pretty close to:
-
-  ORName = Anything
-
-Another warning sign that you've constructed something which is too complex to
-be practical is the manner in which implementations handle its encoding.  If
-you (or others) are treating portions of an object as a blob (without bothering
-to encode or decode the individual fields in it) then that's a sign that it's
-too complex to work with.  An example of this is the policyQualifiers portion
-of the CertificatePolicies extension which, in the two implementations which
-have so far come to light which actually produce qualifiers, treat them as a
-fixed, opaque blob with none of the fields within it actually being encoded or
-decoded.  In this case the entire collection of qualifiers could just as easily
-be replaced by a BOOLEAN DEFAULT FALSE to indicate whether they were there or
-not.
-
-Another warning sign that something is too complex is when your definition
-requires dozens of paragraphs of accompanying text and/or extra constraint
-specifications to explain how the whole thing works or to constrain the usage
-to a subset of what's specified.  If it requires four pages of explanatory text
-to indicate how something is meant to work, it's probably too complex for
-practical use.
-                    No matter how grandiose, how well-planned, how apparently
-                    foolproof an evil plan, the inherent sinfulness will by
-                    definition rebound upon its instigators.
-                        -- Neil Gaiman and Terry Pratchett, "Good Omens"
-
-Finally, stick to standard elements and don't reinvent your own way of doing
-things.  Taking the ORAddress again, it provides no less than three different
-incompatible ways of encoding a type-and-value combination for use in different
-parts of the ORAddress.  The standard way of encoding this (again using the
-simpler 1988 syntax) is:
-
-  Attribute ::= SEQUENCE {
-    type OBJECT IDENTIFIER,
-    value ANY DEFINED BY type
-    }
-
-The standard syntax for field names is to use biCapitalised words, with the
-first letter in lowercase, for example:
-
-  md5WithRSAEncryption
-  certificateHold
-  permittedSubtrees
-
-Let's take an example.  Say you wanted to design an extension for yet another
-online certificate validation protocol which specifies a means of submitting a
-certificate validity check request.  This is used so a certificate user can
-query the certificate issuer about the status of the certificate they're using.
-A first attempt at this might be:
-
-  StatusCheck ::= SEQUENCE {
-    statusCheckLocations  [0] GeneralNames
-    }
-
-Eliminating the unnecessary nesting and tagging we get:
-
-  StatusCheck ::= GeneralNames
-
-However taking a typical encoding (a URL) we see that it comes out as:
-
-  StatusCheck ::= SEQUENCE { [6] "http://..." }
-
-In addition the use of a SEQUENCE OF GeneralName makes the whole thing far to
-vague to be useful (someone would be perfectly within their rights to specify a
-pigeon post address using this definition, and I don't even want to get into
-what it would require for an implementation to claim it could "process" this
-extension).  Since it's an online check it only really makes sense to do it via
-HTTP (or at least something which can be specified through a URL), so we
-simplify it down again to:
-
-  StatusCheck ::= SEQUENCE OF IA5String     -- Contains a URL
-
-We've now reached an optimal way of specifying the status check which is easily
-understandable by anyone reading the definition, and doesn't require enormous
-amounts of additional explanatory text (what to do with the URL and how to
-handle the presence of multiple URL's is presumably specified as part of the
-status-check protocol - all we're interested in is how to specify the
-location(s) at which the status check is performed).
-
-
-base64 Encoding
----------------
-
-Many programs allow certificate objects to be encoded using the base64 format
-popularised in PEM and MIME for transmission of binary data over text-only
-channels.  The format for this is:
-
------BEGIN <object name>-----
-<base64-encoded data>
------END <object name>-----
-
-Unfortunately there is some disagreement over what <object name> should be for
-objects other than certificates (there's no standard for implemetations to be
-non-compliant with).  Everyone seems to agree that for certificates it's
-'CERTIFICATE' (SSLeay can also accept 'X509 CERTIFICATE').  For certificate
-requests, it's generally 'NEW CERTIFICATE REQUEST', although SSLeay can also
-generate 'CERTIFICATE REQUEST' and Microsoft creates an undocumented blob which
-is nothing like a certificate request while still giving it the certificate
-request header.  CRLs are so rare that I haven't been able to collect a large
-enough sample to get a consensus, but 'CRL' would seem to be the logical choice
-(SSLeay uses 'X509 CRL', matching 'X509 CERTIFICATE'). Finally, if you see 'PGP
-...' then you've got the wrong kind of object.
-
-The number of dashes around the text must be exactly five.
-
-                    ... then shalt thou count to three, no more, no less.
-                    Three shalt be the number thou shalt count, and the number
-                    of the counting shalt be three.  Four shalt thou not count,
-                    neither count thou two, excepting that thou then proceed to
-                    three.  Five is right out.
-                        -- Monty Python and the Holy Grail
-
-There are three further object types which aren't covered yet, attribute
-certificates (which are too new to be used), and Netscape cert sequences and
-PKCS #7 cert chains (which are degenerate signed data objects).  The logical
-choice for these would be 'ATTRIBUTE CERTIFICATE', 'NETSCAPE CERTIFICATE
-SEQUENCE' and 'PKCS7 CERTIFICATE CHAIN'.
-
-Recommendation: When encoding objects, for certificates use 'BEGIN
-    CERTIFICATE', for attribute certificates use 'BEGIN ATTRIBUTE CERTIFICATE',
-    for cert requests use 'BEGIN NEW CERTIFICATE REQUEST', for CRLs use 'BEGIN
-    CRL', for Netscape certificate sequences use 'BEGIN NETSCAPE CERTIFICATE
-    SEQUENCE', and for PKCS #7 certificate chains use 'BEGIN PKCS7 CERTIFICATE
-    CHAIN'. When decoding objects, don't make any assumptions about what you
-    might find for <object name> - it's easiest to just look for 'BEGIN' and
-    then work out what's in there from the decoded object.
-
-
-Known Bugs/Peculiarities
-------------------------
-
-The following list of issues cover problems and areas to be aware of in X.509
-implementations and related data objects from different vendors.  The coverage
-extends to objects related to X.509 such as private keys and encrypted/signed
-data.  This section is not intended as a criticism of different vendors, it is
-merely an list of issues which people should be aware of when attempting to
-write interoperable software.  If vendors or users are aware of fixes for these
-problems, could they please notify me of what was fixed, and when or in which
-version it occurred.
-
-One general comment about certificates is that, although you are allowed to
-deconstruct them and then re-encode them, the fact that there are so many
-incorrectly encoded certificates around means that the re-encoded certificates
-will fail their signature check.  For this reason it is strongly advised that
-you always keep a copy of the original on hand rather than trying to recreate
-it from its components as they are stored internally by your software.
-
-An Post
-
-  An Post certificates include an enormously long (nearly four times the
-  maximum allowed size) legal disclaimer in the certificate policy extension
-  (the certificate contains as much legal disclaimer as all other data
-  combined).
-
-Bankgate
-
-  Bankgate certificates specify the country as "INT", which isn't a valid
-  country name (presumably it's meant to be either "International" or
-  "Internet", but as it's used now it means "Limbo").
-
-Belsign
-
-  The Belsign CA incorrectly encodes PKCS #7 certificate chains using a zero-
-  length set of certificates or CRLs if there are none present instead of
-  omitting the field which should contain them.  Since the field is declared as
-  OPTIONAL, it should be omitted if it is empty.
-
-BTG
-
-  BTG certificates contain incorrectly encoded bit strings in key/certificate
-  usage extensions.
-
-CDSA
-
-  CDSA uses a peculiar deprecated DSA OID which appeared in an early,
-  incomplete version of SDN.702 but vanished in later versions (this OID also
-  appears in the German PKI profile).  CDSA also doesn't recognise the
-  recommended X9.57 dsaWithSHA1 OID, causing it to reject DSA certificates
-  which use it.
-
-CompuSource
-
-  This CA has a root cert which has the UTCTime encoded without the seconds
-  (see the section "Validity" above), newer versions encode the time with the
-  seconds.  This isn't an error since the accepted encoding was changed in
-  mid-1996, merely something to be aware of.
-
-COST
-
-  The lengths of some of the fields in CRLs are broken.  Specifically, the
-  lengths of some sequences are calculated incorrectly, so if your code merely
-  nods at things like SET and SEQUENCE tags and lengths as they whiz past and
-  then works with the individual fields it'll work, but if it tries to work
-  with the length values given (for example making sure the lengths of the
-  components of a sequence add up correctly) then it'll break.  The sequence
-  lengths are longer than the amount of data in the sequence, the COST code may
-  be adding the lengths of the elements of the sequence incorrectly (it's a bit
-  hard to tell what's going wrong.  Basically the CRLs are broken).  This was
-  supposed to have been fixed, but there still appear to be problems with CRLs
-  (?).
-
-CRLs
-
-  Some CRLs which contain extensions (which are only valid in v2 CRLs) are
-  marked as v1 CRLs because they don't have a version number field present.
-  These CRLs are (in theory) invalid, but your software should be prepared to
-  encounter them.
-
-DAP
-
-  X.500 directories using DAP return BER-encoded certificates since the DAP
-  PDU's are BER encoded.  This leads to many certificates failing their
-  signature check when they are re-encoded using the DER because they use
-  incorrect or unexpected encodings.  This problem generally requires hacking
-  the directory software to kludge the encoding, since many certificates can't
-  survive the re-encoding process.
-
-Deutsches Forschungsnetz (DFN)
-
-  The DFN CA used the SecuDE software until late-1998, see the SecuDE entry for
-  the quirks present in certificates generated with this software.  These
-  certificates expired at the end of 1998, current certificates are generated
-  using OpenSSL.
-
-Digicert
-
-  (Based on the certificate peculiarities this CA uses the same software as
-   Sweden Post, but some of the quirks of the Sweden Post certificates aren't
-   present so it has its own entry)
-
-  The subjectKeyIdentifier is encoded in a variety of ways ranging in length
-  from 1 to 8 bytes.  In CA certs the subjectKeyIdentifier is the same as the
-  authorityKeyIdentifier (which is valid, but odd) and consists of a text
-  string identifying the CA key (this isn't explicitly disallowed because of
-  the confusion over what's really meant to be in there but it isn't really
-  what's supposed to be in there either).
-
-  CA certs include policy mappings which specify the same issuer and subject
-  domain policy (this is known as a tautology mapping).
-
-Diginotar
-
-  End entity certs tend to be issued with a keyUsage specifying every possible
-  type of key usage, including ones which the algorithm being used is incapable
-  of.
-
-Digital Signature Trust
-
-  The certificate policy contains a longer-than-allowed legal disclaimer,
-  although not quite as excessive as the An Post one.  Just to make sure you
-  don't miss it, the certificate includes the whole thing a second time as a
-  Netscape comment extension.
-
-  End entity certs tend to be issued with a keyUsage specifying every possible
-  type of key usage, including ones which the algorithm being used is incapable
-  of (since this CA operates under the strict Utah law it's possible that this
-  takes precedence over the inability of the RSA algorithm to perform Diffie-
-  Hellman key agreement).
-
-Digitrust Hellas
-
-  The Digitrst Hellas CA incorrectly encodes bit strings in key/certificate
-  usage extensions.
-
-DNs with UniqueIDs
-
-  Given that, in practice, Distinguished Names aren't, some organisations which
-  really require unique names have tried to use unique identifiers as part of
-  whatever's used as the DN in order to make it Distinguished. Unfortunately
-  many applications can't handle multi-AVA RDNs, and those which can generally
-  won't display them to the user, making the use of DN components like
-  dnQualifiers impossible since all the user sees is a collection of certs
-  which all appear to have the same DN.  As a result, some organisations modify
-  the DN by appending a unique identifier value to it.  Examples of these
-  organisations are the US DoD (a very large and highly distributed
-  organisation which needs unique ID's) and AlphaTrust (which specialises in
-  certificates used in transactions which are legally binding regardless of the
-  state of digital signature legislation).
-
-Entrust
-
-  This was formerly a Nortel division, for notes on earlier versions of the
-  software see the entry for Nortel.  Because of their origins, Entrust-
-  specific extensions and attributes are still identified with NSN (Nortel
-  Secure Network) object identifiers.
-
-  The Entrust demo web CA encodes liability statements in the issuer DN, making
-  them unusable with X.500/LDAP directories.  It also issues certificates with
-  a zero-duration validity (start time == end time), limiting their usefulness
-  somewhat.
-
-  Something identified as 'V3.0c' encodes the outer certificate using the BER
-  instead of the DER (which is unusual but legal), however it also omits the
-  final end-of-contents octets (which isn't).  Some of the inner components are
-  also encoded using the BER (which isn't allowed).  This has been fixed in the
-  4.0 release.
-
-  The same software populates the certificate with multiple generations of
-  extensions (for example it contains multiple copies of
-  authorityKeyIdentifier, keyUsage, and cRLDistributionPoints extensions of
-  different levels of deprecation).  Luckily it doesn't mark any of its
-  extensions as critical, avoiding the mutual-exclusion problem documented in
-  the section on extensions.
-
-  The extension which identifies V3.0c contains a GeneralString, which is
-  perfectly legal but may come as a considerable surprise to some decoding
-  software (GeneralStrings get even weirder than the other ASN.1 types, and
-  aren't used in anything certificate-related).
-
-Estonian CLO CA
-Estonian National PCA
-Estonian IOC CA
-Estonian Piirivalveamet CA
-Estonian Politsei CA
-
-  These CAs identify RSA public keys in certificates by a peculiar deprecated
-  X.500 OID for RSA (2 5 8 1 1).
-
-  The Estonian National CA encodes some DN components as PrintableString's
-  containing illegal characters.  I guess the Estonian ASN.1 Politsei will have
-  to look at this.
-
-  These CAs appear to be using the same software, possibly SecuDE, so they may
-  exhibit the same DN encoding bug as the Estonian National CA (I only have one
-  cert from each so it's hard to check this).
-
-First Data
-
-  First Data's CA root certificate is (according to the extKeyUsage extension)
-  used for their SSL server, in SSL clients, and for email encryption.
-
-GeneralName
-
-  Some implementations incorrectly encode the iPAddress (yes, it really is
-  capitalised like that; ASN.1 is bigger than the Internet) as a dotted address
-  rather than a 4-byte (soon to become 16 byte) OCTET STRING, so you might
-  encounter "123.124.125.126" instead of the correct 0x7B7C7D7E.
-
-GIP-CPS
-
-  The software used in the French healthcare card project incorrectly encodes
-  cRLDistributionPoints, encoding the fullName as if it were specified with
-  [0] EXPLICIT GeneralNames, so that the final encoding is [0] + SEQUENCE +
-  GeneralName rather than [0] + GeneralName.
-
-GTE
-
-  Older versions of GTE's software encoded UTCTimes without the seconds (see
-  the section "Validity" above), newer versions encode the time with the
-  seconds.  This isn't an error since the accepted encoding was changed in
-  mid-1996, merely something to be aware of.
-
-HBCI
-
-  The German Home Banking Computer Interface specification contains some
-  unusual requirements for certificates.  Signatures are created by signing the
-  raw, unpadded RIPEMD-160 hash of the data.  Similarly, RSA encryption is
-  performed by encrypting raw, unpadded content-encryption keys.  This provides
-  no semantic security (that is, it's trivial to determine whether a given
-  plaintext corresponds to the ciphertext), and has other problems as well.
-  The IEEE P1363 standard provides further thoughts on this issue.
-
-IBM
-
-  IBM's web CA uses the same peculiar deprecated DSA OID as CDSA and JDK.
-  Since it's based on IBM's Java CryptoFramework it probably ended up in the CA
-  via its use in the JDK.
-
-ICE-TEL
-
-  Early ICE-TEL CRLs are broken, consisting of various portions of full CRLs.
-  See the entry for SECUDE for the explanation, this has been fixed in the
-  ICE-TEL successor project ICE-CAR.
-
-IPSEC
-
-  IPSEC more or less assumes the use of X.509 certificates, however the
-  companies implementing it are usually in the VPN business rather than the PKI
-  business and tend to see certificates as a means to an end rather than an end
-  in itself.  As a result, the state of certificate handling in IPSEC in
-  mid-1999 is something of a free-for-all, with certificates containing
-  whatever seems to work.  For example some IPSEC implementations may place
-  identification information in the subjectName, some ignore the subjectName
-  and use the altName, and some use (even require) both.  In general, you
-  shouldn't make any assumptions about what you'll encounter in certificates
-  designed for or created by IPSEC implementations.
-
-JDK/Java
-
-  JDK 1.1 issues DSA certificates with a signature OID of dsaWithSHA,
-  1.3.14.3.2.13, but the hash algorithm used is SHA-1.  The OID should be
-  dsaWithSHA1 1.3.14.3.2.27.  Since noone ever seems to use SHA, a workaround
-  is to always assume SHA-1 even if the OID says SHA (which is also what the
-  JDK folks are banking on).  JDK also uses the peculiar deprecated DSA OID 1 3
-  14 3 2 12 which appeared in an early, incomplete version of SDN.702 but
-  vanished in later versions (CDSA does this as well, God knows where they're
-  getting these from).  These strange OIDs are duplicated in other Java
-  software as well.  Apparently these OIDs arise from RSADSI's BSAFE 3.0, which
-  is the crypto toolkit which underlies many of these implementations.
-
-Keywitness
-
-  Keywitness encodes an email address as a PrintableString as part of a DN
-  component with an unknown OID registered to Keywitness.  This encoding is
-  invalid since a PrintableString can't contain an '@' character.
-
-  Boolean values are encoded using a non-DER encoding.
-
-LDAP V2/QUIPU
-
-  Some implementations will do strange things when storing signed items. Either
-  the client or the server may modify the objects (for example by uppercasing
-  parts of DNs, or changing time fields based on their interpretation of UTC,
-  or dropping seconds in time fields), which changes the resulting DER encoding
-  and causes the signature check to fail.
-
-Microsoft
-
-  [Microsoft splits development along product lines rather than functionality,
-   so it's not uncommon to find a bug repeated over multiple products from
-   different teams, or to find a bug which has been fixed in one product
-   reappear in another.  Because of this the following descriptions don't
-   usually identify a particular product because it's often a nontrivial
-   exercise identifying in which locations the problems occur]
-
-  Earlier versions of MSIE encoded the emailAddress of a PKCS #10 request
-  incorrectly.  If the string doesn't fit into the range acceptable for a
-  PrintableString it produces a UniversalString (with 32-bit wide characters).
-  Since a PrintableString doesn't include an '@', you always end up with
-  UniversalStrings.  The correct type should be IA5String.
-
-  MS software will often generate components with UniversalStrings in places
-  where they shouldn't really occur.  According to MS, this was necessary
-  because BMPStrings weren't allowed in DirectoryStrings until October 1997,
-  which if true would require another entry in this list, "Some MS software
-  erroneously produced BMPStrings before it was permitted in October 1997".  It
-  also seems to randomly use T61Strings where a PrintableString should be used
-  (there's no discernable pattern to this).  This was fixed in MSIE 4.01 (but
-  not in other MS software as far as I can tell), where it uses either
-  PrintableString or BMPString (skipping T61String completely).
-
-  The same software will dump multiple AVAs into a single RDN, this is most
-  probably an encoding bug since the AVAs consist of a random jumble of
-  components with nothing in common.
-
-  Some Microsoft software will generate negative values about 50% of the time
-  whenever it encodes anything as an INTEGER because it ignores the fact that
-  the top bit of an integer is the sign bit (this is still occurring in
-  programs released as recently as early 1998).
-
-  When MSIE stores certificates, it recodes some components (specifically the
-  various time stamps) which don't include seconds so that they now include
-  seconds, which means that the signatures in the certificates are no longer
-  valid.  The altered encoding is in fact the correct one, but it's probably
-  not worth altering the certificate to the correct form if it means breaking
-  the signature on it.  A workaround for this problem (mentioned in the
-  "Validity" section of this document) is to ensure you never generate a
-  certificate with the seconds field set to 0.
-
-  MS software enforces validity period nesting for certificates, which can
-  cause certificates which are valid everywhere else to appear invalid when
-  loaded into a MS product.
-
-  Although various MS programs give the impression of handling certificate
-  policies, they only have a single hardcoded policy which is the Verisign CPS.
-  To see an example of this, create a certificate with a policy of (for
-  example) "This policy isn't worth the paper it's not written on" and view the
-  cert using Outlook Express.  What's displayed will be the Verisign CPS.
-
-  The entire AuthentiCode certification framework collapsed on 1 July 1997 when
-  the AuthentiCode CA certificates expired (most people never noticed this due
-  to stealth upgrades of security components when other products were
-  installed).  Microsoft issued an update (AuthentiCode 2.0) which includes a
-  partially-documented timestamping mechanism which is supposed to allow
-  signatures to be updated in some manner.  Creating certificates with a
-  lifetime of over four decades (see below) is probably also intended to stop
-  this problem from recurring.
-
-  The MakeCert certificate-generation program gives certificates a default
-  validity of over 40 years (!!!).  This creates three problems: firstly,
-  implementations which use the ANSI/ISO C time_t type for dates (which most
-  implementations do) will, for certificates generated after late 1997, be
-  unable to check the validity period.  Secondly, kids with the next-millenium
-  equivalent of pocket calculators will be breaking the keys for these
-  certificates by the time half the validity period is up.  Finally, because of
-  validity nesting of CA certs which typically expire after a year or two,
-  these certificates will either be treated as invalid as soon as they're
-  issued, or will become invalid a long time before their actual expiry date,
-  depending on how the software enforces validity nesting.
-
-  MakeCert generates certificates with peculiar collections of deprecated and
-  obsolete extensions.  Incredibly, it can be persuaded to generate different
-  incompatible versions of the same extension depending on what options it's
-  given.
-
-  When asked to add a Netscape-style extension to a code-signing certificate,
-  MakeCert adds an extension which marks it as an SSL client certificate,
-  presumably because whoever wrote it got the endianness of the bit strings
-  reversed.  Given that some implementations will allow Netscape extensions to
-  override other extensions which are present (both MSIE and Netscape Navigator
-  seem to treat a Verisign cert with a Netscape extension of "is a CA" and an
-  X.509v3 extension of "isn't a CA" as being a CA certificate), it'll be
-  interesting to see what other implementations make of these certificates.
-
-  In code signing certificates, the displayName (aka agencyInfo) is encoded as
-  an extension identified by the X.509 commonName OID, with the data being an
-  OCTET STRING containing a mostly Unicode representation of an ASCII URL
-  string, winning it the prize for "Most Mangled Extension".
-
-  An ever-changing variety of Microsoft products incorrectly encode bit strings
-  in certificate extensions.
-
-  Outlook Express generates certificates which not only use the GeneralizedTime
-  encoding more than 50 years before they're allowed to, but give the resulting
-  certificate an expiry date in the early 17th century.  A Microsoft spokesman
-  has confirmed that this is deliberate, and not a bug.
-                    How many Microsoft programmers does it take to change a
-                      lightbulb?
-                    None.  They define darkness to be the new industry
-                      standard.
-                        -- Unknown
-
-  The same certificate type is marked as an X.509 v1 certificate even though it
-  contains extensions which aren't allowed in X.509 v1.  To be valid, the
-  certificate should be marked as X.509 v3.
-
-  Some MS software will reject a certificate with certain basic extensions
-  marked critical (this provides one of the nonstandard definitions of the
-  critical flag mentioned earlier, "reject the certificate if you find a
-  critical extension").
-
-  Other MS software, contradicting the previous bug, will ignore the critical
-  flag in extensions, making the software useless to relying parties since they
-  can't rely on it to correctly process critical certificate components.
-
-  Microsoft software seems to mostly ignore the keyUsage bits and extKeyUsage
-  values and use the first certificate it finds for whatever purpose it wants
-  (for example if a subject has a signature and an encryption cert, it will
-  take the first one it finds and use it for both purposes, which will result
-  in the decryption and/or signature check failing).
-
-  Microsoft certificates can include arbitrarily mangled interpretations of
-  what comprises a DN, examples ranging from DNs which consist of a single
-  CommonName through to DNs with the country missing.
-
-  Microsoft's key-handling software assumes that public keys come in a certain
-  fixed format (for example that keys have a certain, set number of bits, that
-  (for RSA) p and q are both the same size, and in some cases that e falls
-  within a certain limited range).  If all these conditions aren't met,
-  encryption and signatures quietly fail.  To avoid this, you need to make the
-  keys a standard, common length (eg 512 bits for exportable crypto), make sure
-  p and q are of the same size, and use a small value for e.
-
-  In extentions which contain URL's, Microsoft software will sometimes produce
-  something which is neither an HTTP URL nor a UNC file URL, but some weird
-  mixture between the two.
-
-  Microsoft certificates contain a peculiar deprecated form of the
-  authorityKeyIdentifier extension.  In this extension, CA certificates
-  sometimes identify themselves, rather than the CA which issued the issuing
-  certificate, which would lead to either endless loops or verification
-  failures if software took this identification literally.
-
-  Extensions in certificate requests are identified using the nonstandard
-  {microsoft 2 1 14} OID instead of the {pkcs-9 14} one, which means that
-  although they're standard extensions, no non-MS software can recognise them.
-
-  After MSIE 5.0, Microsoft partially switched to using the more standard
-  {pkcs-9 14} identifier, but also invented their own format for further
-  extensions alongside the existing one which nothing else can process.  The
-  extensions contain either ASCII or (lengthy) Unicode strings identifying the
-  product which created the cert request.
-
-  Some DNs produced by MS software are encoded with zero-length strings.
-
-  Country codes in DNs created by MS software can contain values other than
-  the allowed two-character ISO code (for example three-character country name
-  abbreviations).
-
-  Code dating from about the MSIE 5.0 and newer stage will chain certificates
-  using the authorityKeyIdentifier even if the issuer name doesn't match, in
-  violation of X.509 and PKIX.  This means that a certificate could claim an
-  issuer of "Verisign Class 1 Public Primary Certification Authority" even
-  though it was actually issued by "Honest Joe's Used Cars and Certificates",
-  and MSIE will accept it as valid.
-
-  Date handling for certificates appears to be completely broken, although it's
-  difficult to determine the real extent and nature of the problems.  For
-  example a certificate which is valid from December 1951 to December 2050 is
-  reported by Windows as being valid from December 1950 to December 1950.
-  Despite this claim, it doesn't recognise the certificate as having expired,
-  indicating multiple levels of date-processing bugs in both the decoding and
-  handling of dates.
-
-  Certificates don't have to contain valid keys or signatures in order to be
-  accepted by Windows, for example a test certificate with an exponent of 1
-  (which means the key has no effect) is accepted as valid.  This is probably
-  required to support an MSDN knowledge base article which tells users how to
-  extract keys from CryptoAPI by encrypting them with a public key with an
-  exponent of 1.
-
-  Some Microsoft products have been spotted which generate things which are
-  claimed to be certificate requests but which actually contain PKCS #7
-  signedData with a payload which is tagged as raw data but which is really a
-  certificate request with Microsoft's gratuitously-incompatible CRMF
-  extensions which aren't CRMF extensions, one of which is a certificate which
-  is used to sign the PKCS #7 signedData.  Needless to say, nothing in
-  existence except for a small subset of other Microsoft products know what to
-  make of this mess.
-
-MISSI
-
-  MISSI certificates use shared DSA parameters, with p, q, and g only being
-  specified in the root CA certificate.  Apart from the risk this introduces
-  (it allows signatures on certificates to be forged under some circumstances),
-  it also complicates certificate processing because the parameters needed to
-  verify a signature are generally held in a certificate held God knows where,
-  so even if a certificate is valid and trusted, it's not possible to use it
-  without having the entire cert chain up to the root on hand.
-
-NASA
-
-  NASA identifies RSA public keys in certificates by a peculiar deprecated
-  X.500 OID for RSA (2 5 8 1 1).
-
-Netlock
-
-  The Netlock CA incorrectly encodes bit strings in key/certificate usage
-  extensions.
-
-Netscape
-
-  Invalid encoding of some (but only some) occurences of the integer value 0 in
-  Commerce Server private keys.  The problem occurs when the integer value 0 in
-  the RSAPrivateKey is encoded as integer, length = 0 rather than integer,
-  length = 1, value = 0.  This was fixed on 20 March 1996 (between the Commerce
-  Server 1.13 and Enterprise 2.0 releases).
-
-  Some unidentified early Netscape CA software would encode an email address as
-  a PrintableString CommonName in a DN.  This encoding is invalid since a
-  PrintableString can't contain an '@' character.  The same CA issued a root
-  certificate with a validity period of zero by encoding the start and end time
-  as the same value.
-
-  Earlier Netscape software encoded the critical flag in extensions
-  incorrectly.  The flag is defined as BOOLEAN DEFAULT FALSE, but it was always
-  encoded even if set to its default value.  This bug was fixed in early 1997.
-
-  Handling of non-PrintableString components of DNs is somewhat ad hoc, at one
-  point the code would take any string which wasn't a PrintableString and
-  encode it as a T61String, whether it was or not.  This may have been fixed
-  now, it results in improper encodings but most products don't care because
-  they don't know what to do with strings that should really be BMPStrings
-  either.  Also, the Cert Server enforces an upper limit on the DN length of
-  255 characters when the DN is encoded as per RFC 1779 (so the actual limit is
-  slightly less than 255 characters).
-
-  The Netscape certificate extensions specification states that the keyUsage
-  extension can be ignored if it's present and non-critical, and lists mappings
-  from keyUsage to Netscape's own cert-type extension.  Some implementations
-  follow these mappings and include both types of extension (notably Thawte),
-  others ignore them and include only the Netscape-specific extension (notably
-  Verisign).
-
-  Navigator can ignore the basicConstraints extension in some instances when it
-  conflicts with other extensions (see the entry for Verisign for details).
-  One way to get it to ignore all extensions is to add the cert as type
-  application/x-x509-ca-cert, in which case it'll accept anything including end
-  entity certificates and certificates with invalid signatures as CA
-  certificates.
-
-  The Netscape CA software incorrectly encodes bit strings in key/certificate
-  usage extensions.
-
-  Adding a new certificate with the same DN as an existing certificate (for
-  example a CA and site certificate with the same DN) can corrupt the Netscape
-  certificate database.
-
-  Encountering a T61String in a certificate will cause versions of Netscape
-  dating from before 1998 to crash with a null pointer dereference.  Current
-  versions will still crash if they encounter a BMPString or UTF8String.
-
-NIST
-
-  NIST has a root CA certificate which the basicConstraints extension
-  identifies as being a non-CA certificate, making it invalid for its intended
-  purpose.  One of these broken certificates was used for several versions of
-  the PKIX X.509 certificate and CRL profile as an example of a CA certificate,
-  which could result in the same problem as the PKCS #10 example vs
-  specification contradiction.
-
-Nortel
-
-  One of Nortel's CA products encodes UTCTime dates using the incorrect non-GMT
-  format.  The software is used by (at least) IBM, the Canadian government
-  (GTIS/PWGCS), and Integrion, and can be identified by the "2.1d" version
-  string in a Nortel-specific attribute attached to the cert.  Nortels WebCA
-  1.0 doesn't have this problem, the fact that the 2.1d software uses a number
-  of old, deprecated OIDs and the WebCA software doesn't would indicate that
-  this is more recent than whatever produced the "2.1d" certs (the "2.1d"
-  refers to a particular release of the infrastructure (Entrust/Manager,
-  Entrust/Officer, and Entrust/Admin) and the corresponding client-side
-  components (toolkits and Entrust/Client) rather than a single product).  This
-  problem was fixed in the Entrust 3.0 infrastructure release.
-
-  Nortel spun off their crypto/security products group as Entrust Technologies
-  in January 1997, for further notes see the entry for Entrust.
-
-PKIX
-
-  PKIX requires that end entity certificates not have a basicConstraints
-  extension, which leaves the handling of the CA status of the certificate to
-  chance.  Several popular applications treat these certificates as CA
-  certificates for backwards-compatibility with X.509v1 CA certificates which
-  didn't include basicConstraints, but in practice it's not really possible to
-  determine how these certificates will be treated.  Because of this, it's not
-  possible to issue a PKIX-compliant end entity certificate and know how it'll
-  be treated once it's in circulation.
-
-  The theory behind this usage is that applications should know that a v3
-  certificate without basicConstraints defaults to being a non-CA certificate,
-  however (even assuming that applications implemented this), if
-  basicConstraints would have been the only extension in the certificate then
-  defaulting to leaving it out would make it a v1 certificate as required by
-  PKIX, so the v1 rules would apply.  To get the required processing, the
-  certificate would have to be marked as v3 even though it's v1 (and the
-  application processing it would have to know about the expected behaviour).
-  In any case it's a somewhat peculiar use of the certificate version number
-  field to convey certificate constraint information.
-
-  One use for this feature is that it may be used as a cryptographically strong
-  random number generator.  For each crypto key an application would issue 128
-  basicConstraint-less certificates, hand them out to different
-  implementations/users, and use their CA/non-CA interpretation as one bit of a
-  session key.  This should yield close to 128 bits of pure entropy in each
-  key.
-
-  In between the draft versions of the standard (which were around for several
-  years) and the RFC, the policy qualifiers display text type was quietly
-  changed to exclude IA5String, which had been present in all the drafts.  As a
-  result, certificates complying with the drafts didn't comply with the RFC.
-  Since noone but Verisign seems to use these fields (see comments elsewhere in
-  this document), it's noticeable by the fact that Verisign certs issued during
-  the lifetime of the drafts appear to contain a string type which is invalid
-  according to the RFC.  This isn't a Verisign problem though, since they
-  complied with the spec at the time the certificates were issued.
-
-Safelayer
-
-  Safelayer have solved the T61String problem by unilaterally extending
-  PrintableString to include latin-1 characters (apparently this was a
-  conscious decision, not an encoding bug).  Since they're in Spain, this
-  results in most of their certs having invalid string encodings.
-
-SECUDE
-
-  The SecuDE software produces certificates with the public key components
-  identified by a peculiar deprecated X.500 OID for RSA (2 5 8 1 1).
-
-  Certificates are hashed with MD2, despite the fact that this algorithm has
-  been deprecated for some time.
-
-  Older versions of SECUDE produced broken CRLs consisting of various portions
-  of full CRLs (the software stored the CRLs in a nonstandard format, this was
-  fixed after 4.x but since this was the last free version it's still in use in
-  some places).
-
-SecureNet
-
-  This CA uses Microsoft software for its certificates, which means they
-  display all the bugs typical of MS-created certificates (see the extensive
-  entry under the Microsoft heading for more details).
-
-Security Domain/Zergo/Certificates Australia
-
-  The authorityKeyIdentifier contains both a keyIdentifier which isn't the
-  required SHA-1 hash (the subjectKeyIdentifier is a hash, it's only the
-  authorityKeyIdentifier which isn't), as well as an authorityCertIssuer
-  represented as a registeredID object identifier.  Other certificates contain
-  an authorityCertIssuer consisting of a single zero byte.  Another cert
-  contains an authorityCertSerialNumber consisting of a single zero byte.
-
-  Bit strings in key/certificate usage extensions are encoded incorrectly.
-
-  The certificatePolicies extension uses incorrect OIDs for the various
-  components such as the CPS and unotice, the CPS URL isn't a valid URL, and
-  the unotice is given as an IA5String rather than a SEQUENCE of assorted
-  components.  A different certificatePolicies contains what looks like another
-  invalid OID which could be an attempt at the one in the previously mentioned
-  certificatePolicies.
-
-  In some cases the issuerName is encoded as 127 bytes of zero-padded
-  registeredID OID.
-
-  (Ugh, this stuff just gets worse and worse - the later attempts at things
-  like PKCS #7 cert chains are so far removed from the real thing that they
-  don't even remotely approach the actual standard.  I'll stop now).
-
-  These issues were resolved in 1999 in a merger with Baltimore by switching to
-  Baltimore's UniCERT product.
-
-SEIS
-
-  The Swedish SEIS project software formerly created UniqueIdentifiers which
-  contained embedded character strings (this is a peculiarity).  In some
-  versions of the software, these were flagged as constructed rather than
-  primitive (this is a bug).  The encoding bug was rectified in later versions.
-  The character strings encode 16-digit numbers, which are apparently used as
-  some form of extra identification which doesn't fit easily into a DN.
-
-  In the EID v2 certificate draft of February 1998, the use of
-  UniqueIdentifiers was deprecated in favour of a DN entry under a SEIS OID
-  which contained the information formerly in the UniqueIdentifiers.
-
-SET
-
-  There is a minor problem which arises from the fact that SET uses the ':'
-  character as a delimiter in commonName components of DNs.  However BMPStrings
-  have more than one character which looks like a ':'.  The correct one to use
-  is the ':' which is common to both PrintableString and BMPString, ASCII
-  character 0x3A.
-
-SHTTP specification
-
-  There is at least one invalid PCKS#7 example in earlier versions of the spec.
-  More recent drafts starting with <draft-ietf-wts-shttp-03.txt>, July 1996,
-  fix this.  Implementors should ensure they are working with corrected
-  versions of the draft.
-
-SI-CA
-
-  The SI-CA incorrectly encodes some bit strings in key/certificate usage
-  extensions.  Unlike other implementations and CAs which have this problem, it
-  doesn't do it consistently, correctly encoding some bitstrings and
-  incorrectly encoding others.
-
-Signet
-
-  [Some of these problems were fixed in late 1998]
-
-  Default fields are encoded when they have the default value rather than being
-  omitted.
-
-  Some basicConstraints extensions are marked as being critical, others in the
-  same chain are marked noncritical (using the incorrect default field
-  encoding mentioned above).
-
-  Bit strings in key/certificate usage extensions are encoded incorrectly.
-
-  Leaf certs are identified by giving the issuing cert a path length constraint
-  of 0 in the basicConstraints extension rather than by marking the cert itself
-  as being a non-CA cert.  This isn't invalid, but is somewhat peculiar, and
-  doesn't work if the leaf cert is implicitly trusted (without the signing cert
-  being present), since there's no indication in the leaf cert itself as to
-  whether it's a CA cert or not.
-
-  BOOLEAN values have non-DER encodings.
-
-  The name constraints extension contains a permittedSubtree with what appears
-  to be an otherName consisting of a single zero byte (no OID or anything
-  else).
-
-South African CA
-
-  This CA has a root cert which has the UTCTime encoded without the seconds
-  (see the section "Validity" above), newer versions encode the time with the
-  seconds.  This isn't an error since the accepted encoding was changed in
-  mid-1996, merely something to be aware of.
-
-SSLeay
-
-  SSLeay incorrectly encoded bit strings in key/certificate usage extensions,
-  this was fixed in late 1998 in version 0.9.1.
-
-Sweden Post/ID2
-
-  Sweden Post certificates incorrectly encode the certificate validity time,
-  omitting the seconds field in the UTCTime field.
-
-  The subjectKeyIdentifier is encoded in a variety of ways ranging in length
-  from 1 to 8 bytes.  In CA certs the subjectKeyIdentifier is the same as the
-  authorityKeyIdentifier (which is valid, but odd) and consists of a text
-  string identifying the CA key (this isn't explicitly disallowed because of
-  the confusion over what's really meant to be in there but it isn't really
-  what's supposed to be in there either).
-
-  Instead of using a common name, the data is encoded as a surname + given name
-  + unique ID, producing DN fields with multiple AVAs per RDN (this isn't a
-  bug, but is definitely a peculiarity, and causes problems for software which
-  expects to use a common name as the identity of the certificate owner).
-
-  CA certs include policy mappings which specify the same issuer and subject
-  domain policy (this is known as a tautology mapping).
-
-  End-entity certs include (deprecated) subjectUniqueIdentifier fields (this is
-  a peculiarity).  The fields contain embedded PrintableString's consisting of
-  variable-length numbers.
-
-SWIFT
-
-  SWIFT certificates have incorrect field lengths for several of the
-  certificate fields, so that the SWIFT CA doesn't even have a valid root CA
-  certificate.
-
-Syscall GbR
-
-  The Syscall GbR CA incorrectly encodes bit strings in key/certificate usage
-  extensions.
-
-TC Trustcenter
-
-  Some certs contain zero-length strings in the DN, this was fixed in early
-  1999.
-
-Telesec/Deutsche Telekom Trustcenter
-
-                    Interoperability considerations merely create uncertainty
-                    and don't serve any useful purpose.  The market for digital
-                    signatures is at hand and it's possible to sell products
-                    without any interoperability
-                        -- Telesec project leader discussing the Telesec
-                           approach to interoperability (translated),
-                           "Digitale Identitaet" workshop, Berlin, May 1999.
-
-  Telesec certificates come in two flavours, general-purpose certificates (for
-  example for S/MIME and SSL use) and PKS (Public Key Service) certificates
-  which are intended for use under the German digital signature law.  The two
-  aren't compatible, and it's not possible to tell which one a given
-  certificate follows because the certificates don't include any policy
-  identification extensions.  An example of the kind of problem this causes is
-  that the Telesec CPS claims certificates will be signed with RSA/MD5, however
-  published end-entity certs have appeared which are signed with
-  RSA/RIPEMD-160.  These aren't invalid, they just follow the PKS profile
-  rather than the PKIX profile or CPS.  Another example of this is the fact
-  that PKS certificates use GeneralizedTime, which is allowed under the PKS
-  profile but not the PKIX/SSL/SMIME/etc ones.
-
-  Some strings are encoded as T61Strings where PrintableStrings should be used
-  (there's no pattern to this).  The strings which really are T61Strings use
-  floating diacritics, which isn't, strictly speaking, illegal, but anyone who
-  does use them should be hung upside down in a bucket of hungry earthworms.
-
-  Common names are encoded in an RDN component with two AVAs, one identified
-  by an unknown Telekom OID and the second identified with the CN OID, however
-  the common name in it is modified by appending extra letters and digits which
-  are intended to distinguish non-unique names in the same manner as the
-  (deprecated) X.509v2 uniqueIdentifiers.  Since even imaginary (guaranteed
-  unique) names are modified in this way, it appears that this alteration is
-  always performed.
-
-  The certificates encode INTEGER values incorrectly by setting the high bit,
-  which makes them negative values.  This is particularly problematic with RSA
-  keys since they use a hardwired exponent of 3,221,225,473 (!!!) which always
-  has the high bit set (0xC0000001), so all the RSA certificates have invalid
-  encodings.  This was corrected in late 1999.
-
-  CA certificates are encoded with no basicConstraints present, which under
-  PKIX rules (which aren't terribly sensible, see an earlier section)
-  explicitly makes them non-CA certificates and under normal conditions makes
-  them highly ambiguous at best.
-
-  [This stuff just gets worse and worse, but I couldn't be bothered going
-   through and figuring out all the broken things they do.  Telesec also
-   hardcode things like certificate parameters into their software (so that,
-   for example, half the info about a user might be stored on a smart card
-   (needed for SigG compliance) and the other half is hardcoded into the driver
-   DLL for the card), guaranteeing that nothing else in existence can work with
-   it.  Ugh].
-
-Thawte
-
-  For a brief while, Thawte encoded email addresses as a PrintableString in a
-  DN's CommonName.  This encoding is invalid since a PrintableString can't
-  contain an '@' character.  This problem has been fixed.
-
-TimeStep/Newbridge/Alcatel
-
-  TimeStep incorrectly encode the DirectoryName in a GeneralName, using an
-  implicit rather than an explicit tag.  The ASN.1 encoding rules require that
-  a tagged CHOICE always have an explicit tag in order to make the underlying
-  CHOICE tag visible.  Timestep were bought by Newbridge who were in turn
-  bought by Alcatel, thus the naming confusion.
-
-UNINETT
-
-  Some certs from this CA identify RSA public keys in certificates by a
-  peculiar deprecated X.500 OID for RSA (2 5 8 1 1).  However in one case a
-  second cert for the same person produced on the same day used rsaEncryption
-  instead.
-
-uniqueIdentifier
-
-  There are at least two incompatible objects called uniqueIdentifier, the
-  first is an attribute defined in 1991 in RFC 1274 with string syntax and an
-  illegal OID (rendering it, in theory, invalid), the second is an attribute
-  defined in 1993 in X.520v2 with BIT STRING syntax.  LDAPv2 used the RFC 1274
-  interpretation, RFC 2256 changed the name for the X.520 version to
-  x500uniqueIdentifier for use with LDAPv3.  There is also a uid attribute
-  defined in RFC 1274, this is different again.
-
-Verisign
-
-  Verisign incorrectly encodes the lengths of fields in the (deprecated)
-  keyUsageRestriction extension, which is used for the Microsoft code signing
-  certificates they issue.  Some software like MSIE will quite happily accept
-  the broken extension, but other software which does proper checking will
-  reject it (actually there are so many weird, unknown critical extensions in
-  the code signing certs that it's unlikely that anything other than MSIE can
-  process them anyway).
-
-  Verisign were, as of March 1998, still issuing certificates with an MD2 hash,
-  despite the fact that this algorithm has been deprecated for some time.  This
-  may be because they have hardware (BBN SafeKeypers) which can only generate
-  the older type of hash.
-
-  Verisign Webpass certificates contain a basicConstraints extension which
-  designate the certificate as a non-CA certificate, and a Netscape cert-type
-  extension which designate the certificate as a CA certificate.  Despite this
-  contradiction, MSIE doesn't seem have any problems with using the
-  certificate, indicating that it's ignoring the basicConstraints entirely.
-  Navigator will load the certificate, but gets an internal error when it tries
-  to use it.  This was fixed in late May 1998.
-
-  Some Verisign certificates mix DER and BER inside the signed portion of the
-  certificate.  Only DER-encoded data is allowed in this part of the
-  certificate.
-
-  For a brief period of time in mid-1998 Verisign issued certificates signed
-  with an MD2 signature block wrapped inside an MD5 signature block.  This was
-  fixed fairly quickly.
-
-  Verisign doesn't mark extensions as critical, even fundamental ones like
-  basicConstraints.  This is because of Microsoft software which rejects
-  certificates with critical extensions.
-
-Y2K/2038 Issues
-
-  Many implementations base their internal time encoding on the Unix/ANSI/ISO C
-  seconds-since-1970 format, and some use 1970 as the rollover date for
-  interpreting two-digit dates instead of xx50.  This includes, as of late
-  1997, Netscape and SSLeay.  In addition the January 2038 limit for seconds
-  expressed as a signed 32-bit quantity means they can't represent dates past
-  this point (which will cause problems with Microsoft's four-decade validity
-  periods).  Implementations should therefore be very careful about keys with
-  very long expiry times, for security as well as date handling reasons,
-
-
-Annex A
--------
-
-The Standards Designer Joke.  I resisted adding this for a long time, but it
-really needs to be present :-).
-
-  An engineer, a chemist, and a standards designer are stranded on a desert
-  island with absolutely nothing on it.  One of them finds a can of spam washed
-  up by the waves.
-
-  The engineer says "Taking the strength of the seams into account, we can
-  calculate that bashing it against a rock with a given force will open it up
-  without destroying the contents".
-
-  The chemist says "Taking the type of metal the can is made of into account,
-  we can calculate that further immersion in salt water will corrode it enough
-  to allow it to be easily opened after a day".
-
-  The standards designer gives the other two a condescending look, gazes into
-  the middle distance, and begins "Assuming we have an electric can opener...".
-
-
-Acknowledgements
-----------------
-
-Anil Gangolli, Deepak Nadig, Eric Young, Harald Alvestrand, John Pawling, Phil
-Griffin, and members of various X.509 and PKI-related mailing lists provided
-useful comments on usage recommendations, encoding issues, and bugs.
-